From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 4 08:01:49 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 IAA13395 for ; Wed, 4 Jun 2003 08:01:48 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h54BxHEl035598; Wed, 4 Jun 2003 12:00:10 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 h54BwFfJ035397; Wed, 4 Jun 2003 11:58:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 4 Jun 2003 11:58:15 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h54BwDEh035386 for ; Wed, 4 Jun 2003 11:58:13 GMT (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13063; Wed, 4 Jun 2003 07:58:10 -0400 (EDT) Message-Id: <200306041158.HAA13063@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapbis@OpenLDAP.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapbis-syntaxes-06.txt Date: Wed, 04 Jun 2003 07:58:06 -0400 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. Title : LDAP: Syntaxes and Matching Rules Author(s) : K. Dally, S. Legg Filename : draft-ietf-ldapbis-syntaxes-06.txt Pages : 49 Date : 2003-6-3 Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, and whose values may be transfered in the LDAP protocol, has a defined syntax which constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-syntaxes-06.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-syntaxes-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapbis-syntaxes-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-3151532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-syntaxes-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-syntaxes-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-3151532.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 4 17:07:15 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 RAA12642 for ; Wed, 4 Jun 2003 17:07:14 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h54L5KEl091383; Wed, 4 Jun 2003 21:05: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 h54L2B8w091244; Wed, 4 Jun 2003 21:02:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 4 Jun 2003 21:02:11 +0000 Received: from cvgmx1.convergys.com (IDENT:mirapoint@cvgmx1.convergys.com [63.210.255.12]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h54L2AEh091231 for ; Wed, 4 Jun 2003 21:02:10 GMT (envelope-from phil.neumiller@convergys.com) Received: from nd.convergys.com (cvgsmtp1.cbis.com [155.90.14.35]) by cvgmx1.convergys.com (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id ALK82048; Wed, 4 Jun 2003 17:01:31 -0400 (EDT) Subject: LDAPv3 over SCTP To: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: phil.neumiller@convergys.com Date: Wed, 4 Jun 2003 17:01:01 -0400 X-MIMETrack: Serialize by Router on CVGSMTP1/SRVR/CVG(Release 5.0.11 |July 24, 2002) at 06/04/2003 05:01:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I searched the archives and did not see anything like this. Has anyone on the list considered putting LDAPv3 over SCTP? If so, why/why not. What might some of the challenges be? Thank you, Phil -- "NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected." From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 4 17:42:30 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 RAA13805 for ; Wed, 4 Jun 2003 17:42:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h54LfKEl093286; Wed, 4 Jun 2003 21:41:31 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 h54LdF6X093141; Wed, 4 Jun 2003 21:39:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 4 Jun 2003 21:39:15 +0000 Received: from nb2.stroeder.com (krl9-d9bb4cea.pool.mediaWays.net [217.187.76.234]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h54Ld8Eh093123 for ; Wed, 4 Jun 2003 21:39:13 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id A1C088D3C0 for ; Wed, 4 Jun 2003 23:38:39 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 3683E59BC0 for ; Wed, 4 Jun 2003 23:38:38 +0200 (CEST) Message-ID: <3EDE66DE.7050301@stroeder.com> Date: Wed, 04 Jun 2003 23:38:38 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: groupOfName (was: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt) References: <1395B4B334FCC143B36AF788E68B63811E3F7C@ausyms21.ca.com> In-Reply-To: <1395B4B334FCC143B36AF788E68B63811E3F7C@ausyms21.ca.com> X-Enigmail-Version: 0.74.3.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 HI! Would it be a big problem or out of scope of ldapbis to change declaration of object class 'groupOfNames' so that attribute 'member' is not required ? I'd like to propose changing it to: ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( cn ) MAY ( businessCategory $ member $ seeAlso $ owner $ ou $ o $ description ) ) Similar change for object class 'groupOfUniqueNames' and attribute 'uniqueMember'. It's rather cumbersome having to add a dummy value for 'member' each time you create a group which does not have members yet. Some server products already ship with a schema like that and personally I can't imagine any problem with this approach. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 4 21:36: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 VAA21487 for ; Wed, 4 Jun 2003 21:36:41 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h551ZeEh007074; Thu, 5 Jun 2003 01:35:40 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 h551C2HS005656; Thu, 5 Jun 2003 01:12:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 5 Jun 2003 01:12:02 +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 h551C1Eh005646 for ; Thu, 5 Jun 2003 01:12:01 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 h551C0c6096619; Thu, 5 Jun 2003 01:12:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030604174241.02998d60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Jun 2003 18:09:01 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: groupOfName (was: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt) Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3EDE66DE.7050301@stroeder.com> References: <1395B4B334FCC143B36AF788E68B63811E3F7C@ausyms21.ca.com> <1395B4B334FCC143B36AF788E68B63811E3F7C@ausyms21.ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h551C2Eh005647 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 02:38 PM 6/4/2003, Michael Ströder wrote: >Would it be a big problem or out of scope of ldapbis to change declaration of object class 'groupOfNames' so that attribute 'member' is not required ? I think redesigning LDAP object class specifications is beyond our scope. (Note that such changes in object class specifications generally requires assignment of a new OID and new short names. See X.501(93).) Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 5 05:55:30 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 FAA13087 for ; Thu, 5 Jun 2003 05:55:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h559rOEp025829; Thu, 5 Jun 2003 09:54: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 h559pl9s025748; Thu, 5 Jun 2003 09:51:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 5 Jun 2003 09:51:47 +0000 Received: from nb2.stroeder.com (krl9-d9bb4e6d.pool.mediaWays.net [217.187.78.109]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h559phEh025662; Thu, 5 Jun 2003 09:51:44 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id E0FA690819; Thu, 5 Jun 2003 11:51:21 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 2D8C3903B1; Thu, 5 Jun 2003 11:51:21 +0200 (CEST) Message-ID: <3EDF1299.5050609@stroeder.com> Date: Thu, 05 Jun 2003 11:51:21 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: groupOfName References: <1395B4B334FCC143B36AF788E68B63811E3F7C@ausyms21.ca.com> <1395B4B334FCC143B36AF788E68B63811E3F7C@ausyms21.ca.com> <5.2.0.9.0.20030604174241.02998d60@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030604174241.02998d60@127.0.0.1> X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h559piEh025685 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Kurt D. Zeilenga wrote: > At 02:38 PM 6/4/2003, Michael Ströder wrote: > >> Would it be a big problem or out of scope of ldapbis to change >> declaration of object class 'groupOfNames' so that attribute 'member' >> is not required ? > > I think redesigning LDAP object class specifications is > beyond our scope. (Note that such changes in object > class specifications generally requires assignment of > a new OID and new short names. See X.501(93).) Is this change really so big? Do you see any incompabilities with existing implementations? IMO it's a security issue that you MUST specify at least one group member during group creation. Admins will tend to add dummy values leading to inconsistent group management. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 5 09:34:53 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 JAA24384 for ; Thu, 5 Jun 2003 09:34:52 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h55DTPEl038917; Thu, 5 Jun 2003 13:33: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 h55DOajm038505; Thu, 5 Jun 2003 13:24:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 5 Jun 2003 13:24:36 +0000 Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h55DOYEh038456 for ; Thu, 5 Jun 2003 13:24:35 GMT (envelope-from c.harding@opengroup.org) Received: from CHRIS-H.opengroup.org (dhcp192-153-166-41.rdg.opengroup.org [192.153.166.41]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id h55DOBv01710 for ; Thu, 5 Jun 2003 14:24:12 +0100 Message-Id: <5.1.0.14.1.20030605141015.00a73618@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Jun 2003 14:25:06 +0100 To: ietf-ldapbis@OpenLDAP.org From: Chris Harding Subject: Values of matchingRules Attribute Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 - We are beta testing The Open Group's VSLDAP test suite, and the following question has been raised. Input from ldapbis experts would be much appreciated. Must a server maintain values of the matchingRules attribute for standard matching rules such as presence or equality? RFC 2252 says: > 5.1 Standard Operational Attributes > Servers MUST maintain values of these attributes in accordance with > the definitions in X.501(93) > ... > 5.1.8 matchingRules > This attribute is typically located in the subschema entry It doesn't specify whether the attribute values must include values for standard attributes. I took a look at X.501, and couldn't find a clear statement there either. I would have assumed, unless it said otherwise, that there would be values for the standard rules - but experience has taught me that such assumptions are dangerous. Please give me your views! Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== Boundaryless Information Flow - Grid Computing Boston, MA, USA, July 21st - 25th http://www.opengroup.org/boston2003 UNIX is a registered trademark of The Open Group in the US and other countries ======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 5 13:15:33 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 NAA06860 for ; Thu, 5 Jun 2003 13:15:32 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h55HBREr058050; Thu, 5 Jun 2003 17:14:29 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 h55H3k8R057422; Thu, 5 Jun 2003 17:03:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 5 Jun 2003 17:03:46 +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 h55H3jEh057412 for ; Thu, 5 Jun 2003 17:03:45 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 h55H3cc6002923; Thu, 5 Jun 2003 17:03:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030605093955.01bdff10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 05 Jun 2003 10:00:38 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: groupOfName Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3EDF1299.5050609@stroeder.com> References: <5.2.0.9.0.20030604174241.02998d60@127.0.0.1> <1395B4B334FCC143B36AF788E68B63811E3F7C@ausyms21.ca.com> <1395B4B334FCC143B36AF788E68B63811E3F7C@ausyms21.ca.com> <5.2.0.9.0.20030604174241.02998d60@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h55H3jEh057413 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 02:51 AM 6/5/2003, Michael Ströder wrote: >Kurt D. Zeilenga wrote: >>At 02:38 PM 6/4/2003, Michael Ströder wrote: >>>Would it be a big problem or out of scope of ldapbis to change >>>declaration of object class 'groupOfNames' so that attribute 'member' >>>is not required ? >>I think redesigning LDAP object class specifications is >>beyond our scope. (Note that such changes in object >>class specifications generally requires assignment of >>a new OID and new short names. See X.501(93).) > >Is this change really so big? I did not attempted to answer this portion of your question. We are only chartered to revise the LDAP technical specification as needed to make it suitable for publication as a Draft Standard. LDAPBIS cannot change the specification simply because we don't like it. >IMO it's a security issue that you MUST specify at least one group member during group creation. Admins will tend to add dummy values leading to inconsistent group management. Sounds like something that can be addressed by a stating a security consideration. If the WG were to actually conclude that the object class was significantly flawed, our best option would be just to remove it. Redesigning LDAP schema is beyond our scope of work. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 5 22:19:58 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 WAA25619 for ; Thu, 5 Jun 2003 22:19:57 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h562HUEl086218; Fri, 6 Jun 2003 02:18:18 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 h562Gm9R086174; Fri, 6 Jun 2003 02:16:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 02:16:48 +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 h562GkEh086109 for ; Fri, 6 Jun 2003 02:16:47 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 05 Jun 2003 20:16:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 05 Jun 2003 20:15:10 -0600 From: "Jim Sermersheim" To: Subject: Re: What Does De-Reference Mean? 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 So, I'm trying to clarify this, and it occurs to me once again that I don't like the semantics of derefInSearching. I can't dereference all aliases in the search scope, yet not dereference aliases while resolving the base. This is limiting. I may want a subtree search to fail if there are aliases somewhere in the middle of the DN, so I choose not to derefFindingBaseObject. Yet, once the base object is found (even if it itself is an alias), I want all aliases in my scope to be dereferenced. AFAIK, LDAPv3 is consistent with X.511, so I guess there's not much we can do about it here. Anyway, I do need to clarify the wording. Right now it says "Dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search". This is invalid if the scope is base. It also doesn't tell me to continue a subtree search in the subtree of a dereferenced object. I'll make those two clarifications if no one sees a problem with them. Jim >>> "Kurt D. Zeilenga" 5/21/03 1:56:53 PM >>> At 05:33 AM 5/20/2003, you wrote: >Kurt, >Going by the same argument, the rest of the search criteria e.g. the >base dn and scope of the search should also be applied after the alias >has been derferenced to the actual entry The base DN is "finding" criteria while the scope and filter are "searching" criteria, so my argument does not apply to the base DN but does apply to scope. I couldn't parse your example, so I won't try to comment as to how my clarification applies to it. Kurt >So in the example below, > > ou=deptB > ou=deptA > | > | > alias_teamA - - - - - - - - - - - - - - - - - - - - - - - >- - - - - >ou= teamA > > | > > ou= DT > > > | > > Computer object (objectClass=computer) > > > > Search Operation: > set search base = deptB > set search scope = subtree search > set deref aliases = always > search for objects of objectClass=computer > >Computer object should not be returned as it does not qualify the scope >criteria for ou=deptb as the base. >Correct ? > >Prasad > >>>> "Kurt D. Zeilenga" 3/28/2003 5:12:53 AM >>> >It should be clear that each and every entry returned in >response to a search request did match the search filter. That >is, if the filter is (CN=foo) than each entry returned has "foo" >as a (not necessarily returned) value of an attribute whose >type is CN or a subtype of CN. > >When dereferencing during searching (by derefInSearching or >derefAlways), the filter should be matched against the entry which >the alias refers to, not the alias itself. > >If the client asks for all alias objects, e.g, (objectClass=alias) >with dereferencing during finding enabled, then no entries should >be returned. Likewise, when requesting (objectClass=*) with >dereferencing during finding enabled, none of entries returned >should belong to the alias objectClass. > >So, to answer your specific question, it is not relevant to >the matching what values of CN the 'alias' has. The values >of the aliased entry are, however, quite relevant. > >Kurt > > >At 11:22 AM 3/26/2003, Chris Harding wrote: >>Hi - >> >>The interpretation of the LDAP RFCs as regards dereferencing has >become an issue for the new certification program that The Open Group >plans to launch for LDAP servers. We have discussed it in the Directory >Interoperability Forum, and agreed that we should ask the experts in the >ldapbis group. Accordingly, I would like to ask your help in clarifying >this issue. >> >>Here's the issue. The requirement in the specification is: >> >> When a server receives a search request with the derefAliases >field >> set to derefInSearching then it will dereference aliases in >subordinates >> of the base object in searching. >> >>We have a test suite for use in the certification program. The suite >includes a test of this requirement (which is in fact derived from a >test in BLITS). The test data includes two entries: Jonathan Adams and >Jonny Adams. The Jonny Adams entry is an alias for Jonathan Adams. >> >>The test should check that Jonny Adams is de-referenced and Jonathan >Adams is returned. The question is, should the test search for Jonny or >for Jonathan. >> >>RFC 2251 does not explain dereferencing but defers to X.501. >Unfortunately, X.501 does not seem to explain it very well. My personal >interpretation after reading it is that, whenever a server encounters an >alias entry in the course of a search and dereferencing has been >requested, the server should dereference the alias and carry on >searching from the entry that the alias points to. Under this >interpretation, a search for Jonny should return the same result as a >search for Jonathan - the Jonathan Adams entry. >> >>I don't claim to be an expert on the interpretation of the >specifications - but I hope that experts in the IETF community can shed >light on this! >> >>Please send your comments to the ldapbis list. I will report the >consensus (assuming that one is reached) to the DIF. >> >>Regards, >> >>Chris >>+++++ >> >>======================================================================== >> Dr. Christopher J. Harding >> T H E Executive Director for the Directory Interoperability >Forum >> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 >> WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >>======================================================================== >> >> The Open Group's Consortia Services - Association >Management For I.T.: >> http://www.opengroup.org/consortia_services >> >>======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 5 22:30:42 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 WAA25905 for ; Thu, 5 Jun 2003 22:30:41 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h562TTEl086549; Fri, 6 Jun 2003 02:29:37 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 h562Q0s3086513; Fri, 6 Jun 2003 02:26:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 02:26:00 +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 h562PwEh086446 for ; Fri, 6 Jun 2003 02:25:59 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 05 Jun 2003 20:25:38 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 05 Jun 2003 20:24:23 -0600 From: "Jim Sermersheim" To: Subject: Re: What Does De-Reference Mean? 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 My proposed text is: derefInSearching: While searching, dereference any alias object subordinate to the base object which is also in the search scope. The filter is applied to the dereferenced object(s). If the search scope is wholeSubtree, the search continues in the subtree of any dereferenced object. Aliases in that subtree are also dereferenced. Servers SHOULD detect looping in this process to prevent denial of service attacks. Jim >>> "Jim Sermersheim" 6/5/03 8:15:10 PM >>> So, I'm trying to clarify this, and it occurs to me once again that I don't like the semantics of derefInSearching. I can't dereference all aliases in the search scope, yet not dereference aliases while resolving the base. This is limiting. I may want a subtree search to fail if there are aliases somewhere in the middle of the DN, so I choose not to derefFindingBaseObject. Yet, once the base object is found (even if it itself is an alias), I want all aliases in my scope to be dereferenced. AFAIK, LDAPv3 is consistent with X.511, so I guess there's not much we can do about it here. Anyway, I do need to clarify the wording. Right now it says "Dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search". This is invalid if the scope is base. It also doesn't tell me to continue a subtree search in the subtree of a dereferenced object. I'll make those two clarifications if no one sees a problem with them. Jim >>> "Kurt D. Zeilenga" 5/21/03 1:56:53 PM >>> At 05:33 AM 5/20/2003, you wrote: >Kurt, >Going by the same argument, the rest of the search criteria e.g. the >base dn and scope of the search should also be applied after the alias >has been derferenced to the actual entry The base DN is "finding" criteria while the scope and filter are "searching" criteria, so my argument does not apply to the base DN but does apply to scope. I couldn't parse your example, so I won't try to comment as to how my clarification applies to it. Kurt >So in the example below, > > ou=deptB > ou=deptA > | > | > alias_teamA - - - - - - - - - - - - - - - - - - - - - - - >- - - - - >ou= teamA > > | > > ou= DT > > > | > > Computer object (objectClass=computer) > > > > Search Operation: > set search base = deptB > set search scope = subtree search > set deref aliases = always > search for objects of objectClass=computer > >Computer object should not be returned as it does not qualify the scope >criteria for ou=deptb as the base. >Correct ? > >Prasad > >>>> "Kurt D. Zeilenga" 3/28/2003 5:12:53 AM >>> >It should be clear that each and every entry returned in >response to a search request did match the search filter. That >is, if the filter is (CN=foo) than each entry returned has "foo" >as a (not necessarily returned) value of an attribute whose >type is CN or a subtype of CN. > >When dereferencing during searching (by derefInSearching or >derefAlways), the filter should be matched against the entry which >the alias refers to, not the alias itself. > >If the client asks for all alias objects, e.g, (objectClass=alias) >with dereferencing during finding enabled, then no entries should >be returned. Likewise, when requesting (objectClass=*) with >dereferencing during finding enabled, none of entries returned >should belong to the alias objectClass. > >So, to answer your specific question, it is not relevant to >the matching what values of CN the 'alias' has. The values >of the aliased entry are, however, quite relevant. > >Kurt > > >At 11:22 AM 3/26/2003, Chris Harding wrote: >>Hi - >> >>The interpretation of the LDAP RFCs as regards dereferencing has >become an issue for the new certification program that The Open Group >plans to launch for LDAP servers. We have discussed it in the Directory >Interoperability Forum, and agreed that we should ask the experts in the >ldapbis group. Accordingly, I would like to ask your help in clarifying >this issue. >> >>Here's the issue. The requirement in the specification is: >> >> When a server receives a search request with the derefAliases >field >> set to derefInSearching then it will dereference aliases in >subordinates >> of the base object in searching. >> >>We have a test suite for use in the certification program. The suite >includes a test of this requirement (which is in fact derived from a >test in BLITS). The test data includes two entries: Jonathan Adams and >Jonny Adams. The Jonny Adams entry is an alias for Jonathan Adams. >> >>The test should check that Jonny Adams is de-referenced and Jonathan >Adams is returned. The question is, should the test search for Jonny or >for Jonathan. >> >>RFC 2251 does not explain dereferencing but defers to X.501. >Unfortunately, X.501 does not seem to explain it very well. My personal >interpretation after reading it is that, whenever a server encounters an >alias entry in the course of a search and dereferencing has been >requested, the server should dereference the alias and carry on >searching from the entry that the alias points to. Under this >interpretation, a search for Jonny should return the same result as a >search for Jonathan - the Jonathan Adams entry. >> >>I don't claim to be an expert on the interpretation of the >specifications - but I hope that experts in the IETF community can shed >light on this! >> >>Please send your comments to the ldapbis list. I will report the >consensus (assuming that one is reached) to the DIF. >> >>Regards, >> >>Chris >>+++++ >> >>======================================================================== >> Dr. Christopher J. Harding >> T H E Executive Director for the Directory Interoperability >Forum >> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 >> WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >>======================================================================== >> >> The Open Group's Consortia Services - Association >Management For I.T.: >> http://www.opengroup.org/consortia_services >> >>======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 5 23:55: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 XAA27349 for ; Thu, 5 Jun 2003 23:55: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 h563rUEl088591; Fri, 6 Jun 2003 03:53: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 h563oGTr088524; Fri, 6 Jun 2003 03:50:16 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 03:50:16 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h563oEEh088510 for ; Fri, 6 Jun 2003 03:50:14 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 13:49:50 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Values of matchingRules Attribute Date: Fri, 6 Jun 2003 13:49:50 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638128BFF0@ausyms21.ca.com> Thread-topic: Values of matchingRules Attribute Thread-index: AcMrZyB4ab4MUU23TkSEqavhlogcwAAdrFvA From: "Ramsay, Ron" To: "Chris Harding" , X-OriginalArrivalTime: 06 Jun 2003 03:49:50.0935 (UTC) FILETIME=[AEA5EE70:01C32BDE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h563oFEh088515 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, The real question however, as regards the tests being performed, is whether a client can EXPECT that the attribute WILL be returned from an (any) entry if requested. I think that RFC 2252 (4.5) is pretty clear that the attribute need only be present if additional (beyond those in RFC 2252) matching rules are supported. Even so, it is not clear whether this should be in each entry or only in subentries. Ron -----Original Message----- From: Chris Harding [mailto:c.harding@opengroup.org] Sent: Thursday, 5 June 2003 23:25 To: ietf-ldapbis@OpenLDAP.org Subject: Values of matchingRules Attribute Hi - We are beta testing The Open Group's VSLDAP test suite, and the following question has been raised. Input from ldapbis experts would be much appreciated. Must a server maintain values of the matchingRules attribute for standard matching rules such as presence or equality? RFC 2252 says: > 5.1 Standard Operational Attributes > Servers MUST maintain values of these attributes in accordance with > the definitions in X.501(93) > ... > 5.1.8 matchingRules > This attribute is typically located in the subschema entry It doesn't specify whether the attribute values must include values for standard attributes. I took a look at X.501, and couldn't find a clear statement there either. I would have assumed, unless it said otherwise, that there would be values for the standard rules - but experience has taught me that such assumptions are dangerous. Please give me your views! Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== Boundaryless Information Flow - Grid Computing Boston, MA, USA, July 21st - 25th http://www.opengroup.org/boston2003 UNIX is a registered trademark of The Open Group in the US and other countries ======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 00:33: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 AAA28291 for ; Fri, 6 Jun 2003 00:33: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 h564TUEl089267; Fri, 6 Jun 2003 04:29:37 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 h564Q08U089222; Fri, 6 Jun 2003 04:26:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 04:26:00 +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 h564PxEh089212 for ; Fri, 6 Jun 2003 04:25:59 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 h564Pqc6009207; Fri, 6 Jun 2003 04:25:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030605212011.01b93ca0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 05 Jun 2003 21:22:51 -0700 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: Values of matchingRules Attribute Cc: "Chris Harding" , In-Reply-To: <1395B4B334FCC143B36AF788E68B638128BFF0@ausyms21.ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:49 PM 6/5/2003, Ramsay, Ron wrote: >The real question however, as regards the tests being performed, is whether a client can EXPECT that the attribute WILL be returned from an (any) entry if requested. If one just wanted to test that the server recognized the attribute type, I suggest using the compare operation instead. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 00:54: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 AAA28568 for ; Fri, 6 Jun 2003 00:54:42 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h564rUEl089786; Fri, 6 Jun 2003 04: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 h564n3jG089710; Fri, 6 Jun 2003 04:49:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 04:49:03 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h564n1Eh089699 for ; Fri, 6 Jun 2003 04:49:01 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 14:48:40 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: What Does De-Reference Mean? Date: Fri, 6 Jun 2003 14:48:40 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638128C11E@ausyms21.ca.com> Thread-topic: What Does De-Reference Mean? Thread-index: AcMr0fnvrVIqS/6hQ9eUXrv+Q/JsyQAE1o/Q From: "Ramsay, Ron" To: "Jim Sermersheim" , X-OriginalArrivalTime: 06 Jun 2003 04:48:40.0655 (UTC) FILETIME=[E68675F0:01C32BE6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h564n2Eh089701 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm sorry, but aren't you actually trying to confuse the issue? A search has only ONE base object. To find that base object is called navigation. You may control dereferencing of aliases in navigation. This is in the commonArguments of X.500 but rolled into a search parameter in LDAP. Having navigated to an actual entry (which may be an alias), you now start returning results. For each result DN, you may dereference aliases or not, depending on a parameter in the search request. Dereferenced aliases are not new base-objects of THE search. Of course, a subtree search in which aliases are dereferenced has two side-effects - a) these entries may not appear to be in the orignal scope (can't be helped!) b) these entries out of scope cause 'new' subtree searches to be included (scary). It seems to be b) which is giving (understandable) grief. But let's not confuse the types of dereferencing going on with this effect. (The problem seems to be that the dereferenced alias may have subordinates - are these logically part of the orinal scope? Yes - because, if the entry were not an alias, the real entry with its subordinates would have to appear in place of the alias; No - because the subordinates are not in scope!) Please don't 'over-explain" aliase dereferencing. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 6 June 2003 12:15 To: ietf-ldapbis@OpenLDAP.org Subject: Re: What Does De-Reference Mean? So, I'm trying to clarify this, and it occurs to me once again that I don't like the semantics of derefInSearching. I can't dereference all aliases in the search scope, yet not dereference aliases while resolving the base. This is limiting. I may want a subtree search to fail if there are aliases somewhere in the middle of the DN, so I choose not to derefFindingBaseObject. Yet, once the base object is found (even if it itself is an alias), I want all aliases in my scope to be dereferenced. AFAIK, LDAPv3 is consistent with X.511, so I guess there's not much we can do about it here. Anyway, I do need to clarify the wording. Right now it says "Dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search". This is invalid if the scope is base. It also doesn't tell me to continue a subtree search in the subtree of a dereferenced object. I'll make those two clarifications if no one sees a problem with them. Jim >>> "Kurt D. Zeilenga" 5/21/03 1:56:53 PM >>> At 05:33 AM 5/20/2003, you wrote: >Kurt, >Going by the same argument, the rest of the search criteria e.g. the >base dn and scope of the search should also be applied after the alias >has been derferenced to the actual entry The base DN is "finding" criteria while the scope and filter are "searching" criteria, so my argument does not apply to the base DN but does apply to scope. I couldn't parse your example, so I won't try to comment as to how my clarification applies to it. Kurt >So in the example below, > > ou=deptB > ou=deptA > | > | > alias_teamA - - - - - - - - - - - - - - - - - - - - - - - >- - - - - >ou= teamA > > | > > ou= DT > > > | > > Computer object (objectClass=computer) > > > > Search Operation: > set search base = deptB > set search scope = subtree search > set deref aliases = always > search for objects of objectClass=computer > >Computer object should not be returned as it does not qualify the scope >criteria for ou=deptb as the base. >Correct ? > >Prasad > >>>> "Kurt D. Zeilenga" 3/28/2003 5:12:53 AM >>> >It should be clear that each and every entry returned in >response to a search request did match the search filter. That >is, if the filter is (CN=foo) than each entry returned has "foo" >as a (not necessarily returned) value of an attribute whose >type is CN or a subtype of CN. > >When dereferencing during searching (by derefInSearching or >derefAlways), the filter should be matched against the entry which >the alias refers to, not the alias itself. > >If the client asks for all alias objects, e.g, (objectClass=alias) >with dereferencing during finding enabled, then no entries should >be returned. Likewise, when requesting (objectClass=*) with >dereferencing during finding enabled, none of entries returned >should belong to the alias objectClass. > >So, to answer your specific question, it is not relevant to >the matching what values of CN the 'alias' has. The values >of the aliased entry are, however, quite relevant. > >Kurt > > >At 11:22 AM 3/26/2003, Chris Harding wrote: >>Hi - >> >>The interpretation of the LDAP RFCs as regards dereferencing has >become an issue for the new certification program that The Open Group >plans to launch for LDAP servers. We have discussed it in the Directory >Interoperability Forum, and agreed that we should ask the experts in the >ldapbis group. Accordingly, I would like to ask your help in clarifying >this issue. >> >>Here's the issue. The requirement in the specification is: >> >> When a server receives a search request with the derefAliases >field >> set to derefInSearching then it will dereference aliases in >subordinates >> of the base object in searching. >> >>We have a test suite for use in the certification program. The suite >includes a test of this requirement (which is in fact derived from a >test in BLITS). The test data includes two entries: Jonathan Adams and >Jonny Adams. The Jonny Adams entry is an alias for Jonathan Adams. >> >>The test should check that Jonny Adams is de-referenced and Jonathan >Adams is returned. The question is, should the test search for Jonny or >for Jonathan. >> >>RFC 2251 does not explain dereferencing but defers to X.501. >Unfortunately, X.501 does not seem to explain it very well. My personal >interpretation after reading it is that, whenever a server encounters an >alias entry in the course of a search and dereferencing has been >requested, the server should dereference the alias and carry on >searching from the entry that the alias points to. Under this >interpretation, a search for Jonny should return the same result as a >search for Jonathan - the Jonathan Adams entry. >> >>I don't claim to be an expert on the interpretation of the >specifications - but I hope that experts in the IETF community can shed >light on this! >> >>Please send your comments to the ldapbis list. I will report the >consensus (assuming that one is reached) to the DIF. >> >>Regards, >> >>Chris >>+++++ >> >>======================================================================== >> Dr. Christopher J. Harding >> T H E Executive Director for the Directory Interoperability >Forum >> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 >> WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >>======================================================================== >> >> The Open Group's Consortia Services - Association >Management For I.T.: >> http://www.opengroup.org/consortia_services >> >>======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 01:13:09 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 BAA28932 for ; Fri, 6 Jun 2003 01:13:04 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h565BVEl090226; Fri, 6 Jun 2003 05:11:36 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 h565B5E4090203; Fri, 6 Jun 2003 05:11:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 05:11:05 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h565B2Eh090187 for ; Fri, 6 Jun 2003 05:11:03 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 15:10:41 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: What Does De-Reference Mean? Date: Fri, 6 Jun 2003 15:10:41 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638128C179@ausyms21.ca.com> Thread-topic: What Does De-Reference Mean? Thread-index: AcMr2Vsa+ZWD5FHCR2SeXozdSWJzHAAEIOuA From: "Ramsay, Ron" To: "Jim Sermersheim" , X-OriginalArrivalTime: 06 Jun 2003 05:10:41.0779 (UTC) FILETIME=[F9F9FC30:01C32BE9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h565B4Eh090194 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 ... and to prevent the return of duplicate entries. OK Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 6 June 2003 12:24 To: ietf-ldapbis@OpenLDAP.org Subject: Re: What Does De-Reference Mean? My proposed text is: derefInSearching: While searching, dereference any alias object subordinate to the base object which is also in the search scope. The filter is applied to the dereferenced object(s). If the search scope is wholeSubtree, the search continues in the subtree of any dereferenced object. Aliases in that subtree are also dereferenced. Servers SHOULD detect looping in this process to prevent denial of service attacks. Jim >>> "Jim Sermersheim" 6/5/03 8:15:10 PM >>> So, I'm trying to clarify this, and it occurs to me once again that I don't like the semantics of derefInSearching. I can't dereference all aliases in the search scope, yet not dereference aliases while resolving the base. This is limiting. I may want a subtree search to fail if there are aliases somewhere in the middle of the DN, so I choose not to derefFindingBaseObject. Yet, once the base object is found (even if it itself is an alias), I want all aliases in my scope to be dereferenced. AFAIK, LDAPv3 is consistent with X.511, so I guess there's not much we can do about it here. Anyway, I do need to clarify the wording. Right now it says "Dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search". This is invalid if the scope is base. It also doesn't tell me to continue a subtree search in the subtree of a dereferenced object. I'll make those two clarifications if no one sees a problem with them. Jim >>> "Kurt D. Zeilenga" 5/21/03 1:56:53 PM >>> At 05:33 AM 5/20/2003, you wrote: >Kurt, >Going by the same argument, the rest of the search criteria e.g. the >base dn and scope of the search should also be applied after the alias >has been derferenced to the actual entry The base DN is "finding" criteria while the scope and filter are "searching" criteria, so my argument does not apply to the base DN but does apply to scope. I couldn't parse your example, so I won't try to comment as to how my clarification applies to it. Kurt >So in the example below, > > ou=deptB > ou=deptA > | > | > alias_teamA - - - - - - - - - - - - - - - - - - - - - - - >- - - - - >ou= teamA > > | > > ou= DT > > > | > > Computer object (objectClass=computer) > > > > Search Operation: > set search base = deptB > set search scope = subtree search > set deref aliases = always > search for objects of objectClass=computer > >Computer object should not be returned as it does not qualify the scope >criteria for ou=deptb as the base. >Correct ? > >Prasad > >>>> "Kurt D. Zeilenga" 3/28/2003 5:12:53 AM >>> >It should be clear that each and every entry returned in >response to a search request did match the search filter. That >is, if the filter is (CN=foo) than each entry returned has "foo" >as a (not necessarily returned) value of an attribute whose >type is CN or a subtype of CN. > >When dereferencing during searching (by derefInSearching or >derefAlways), the filter should be matched against the entry which >the alias refers to, not the alias itself. > >If the client asks for all alias objects, e.g, (objectClass=alias) >with dereferencing during finding enabled, then no entries should >be returned. Likewise, when requesting (objectClass=*) with >dereferencing during finding enabled, none of entries returned >should belong to the alias objectClass. > >So, to answer your specific question, it is not relevant to >the matching what values of CN the 'alias' has. The values >of the aliased entry are, however, quite relevant. > >Kurt > > >At 11:22 AM 3/26/2003, Chris Harding wrote: >>Hi - >> >>The interpretation of the LDAP RFCs as regards dereferencing has >become an issue for the new certification program that The Open Group >plans to launch for LDAP servers. We have discussed it in the Directory >Interoperability Forum, and agreed that we should ask the experts in the >ldapbis group. Accordingly, I would like to ask your help in clarifying >this issue. >> >>Here's the issue. The requirement in the specification is: >> >> When a server receives a search request with the derefAliases >field >> set to derefInSearching then it will dereference aliases in >subordinates >> of the base object in searching. >> >>We have a test suite for use in the certification program. The suite >includes a test of this requirement (which is in fact derived from a >test in BLITS). The test data includes two entries: Jonathan Adams and >Jonny Adams. The Jonny Adams entry is an alias for Jonathan Adams. >> >>The test should check that Jonny Adams is de-referenced and Jonathan >Adams is returned. The question is, should the test search for Jonny or >for Jonathan. >> >>RFC 2251 does not explain dereferencing but defers to X.501. >Unfortunately, X.501 does not seem to explain it very well. My personal >interpretation after reading it is that, whenever a server encounters an >alias entry in the course of a search and dereferencing has been >requested, the server should dereference the alias and carry on >searching from the entry that the alias points to. Under this >interpretation, a search for Jonny should return the same result as a >search for Jonathan - the Jonathan Adams entry. >> >>I don't claim to be an expert on the interpretation of the >specifications - but I hope that experts in the IETF community can shed >light on this! >> >>Please send your comments to the ldapbis list. I will report the >consensus (assuming that one is reached) to the DIF. >> >>Regards, >> >>Chris >>+++++ >> >>======================================================================== >> Dr. Christopher J. Harding >> T H E Executive Director for the Directory Interoperability >Forum >> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 >> WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >>======================================================================== >> >> The Open Group's Consortia Services - Association >Management For I.T.: >> http://www.opengroup.org/consortia_services >> >>======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 05:01: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 FAA14468 for ; Fri, 6 Jun 2003 05:01:02 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h568lWFL098706; Fri, 6 Jun 2003 08:59: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 h568fuWO098440; Fri, 6 Jun 2003 08:41:56 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 08:41:56 +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 h568fsEh098403 for ; Fri, 6 Jun 2003 08:41:54 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 06 Jun 2003 02:41:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 06 Jun 2003 02:40:17 -0600 From: "Jim Sermersheim" To: , Subject: RE: What Does De-Reference Mean? 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 Without trying, I guess I did confuse. You went down different path than the one I intended. My issue (which I will leave alone) is the scenario where while "navigating", we are not dereferencing aliases and the search base happens to be an alias. Now, if this is a subtree search, we *Do not* dereference (one of) the object(s) that we are evaluating (namely the search base). In other words, when we deref when searching, and not when navigating, there is the possibility that the search filter is applied to one alias (the search base). There is the possibility that an alias object will be returned from the search. If a server returns an alias object when derefInSearching is set, it will likely confuse some people (with or without my help). Jim >>> "Ramsay, Ron" 6/5/03 10:48:40 PM >>> I'm sorry, but aren't you actually trying to confuse the issue? A search has only ONE base object. To find that base object is called navigation. You may control dereferencing of aliases in navigation. This is in the commonArguments of X.500 but rolled into a search parameter in LDAP. Having navigated to an actual entry (which may be an alias), you now start returning results. For each result DN, you may dereference aliases or not, depending on a parameter in the search request. Dereferenced aliases are not new base-objects of THE search. Of course, a subtree search in which aliases are dereferenced has two side-effects - a) these entries may not appear to be in the orignal scope (can't be helped!) b) these entries out of scope cause 'new' subtree searches to be included (scary). It seems to be b) which is giving (understandable) grief. But let's not confuse the types of dereferencing going on with this effect. (The problem seems to be that the dereferenced alias may have subordinates - are these logically part of the orinal scope? Yes - because, if the entry were not an alias, the real entry with its subordinates would have to appear in place of the alias; No - because the subordinates are not in scope!) Please don't 'over-explain" aliase dereferencing. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 6 June 2003 12:15 To: ietf-ldapbis@OpenLDAP.org Subject: Re: What Does De-Reference Mean? So, I'm trying to clarify this, and it occurs to me once again that I don't like the semantics of derefInSearching. I can't dereference all aliases in the search scope, yet not dereference aliases while resolving the base. This is limiting. I may want a subtree search to fail if there are aliases somewhere in the middle of the DN, so I choose not to derefFindingBaseObject. Yet, once the base object is found (even if it itself is an alias), I want all aliases in my scope to be dereferenced. AFAIK, LDAPv3 is consistent with X.511, so I guess there's not much we can do about it here. Anyway, I do need to clarify the wording. Right now it says "Dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search". This is invalid if the scope is base. It also doesn't tell me to continue a subtree search in the subtree of a dereferenced object. I'll make those two clarifications if no one sees a problem with them. Jim >>> "Kurt D. Zeilenga" 5/21/03 1:56:53 PM >>> At 05:33 AM 5/20/2003, you wrote: >Kurt, >Going by the same argument, the rest of the search criteria e.g. the >base dn and scope of the search should also be applied after the alias >has been derferenced to the actual entry The base DN is "finding" criteria while the scope and filter are "searching" criteria, so my argument does not apply to the base DN but does apply to scope. I couldn't parse your example, so I won't try to comment as to how my clarification applies to it. Kurt >So in the example below, > > ou=deptB > ou=deptA > | > | > alias_teamA - - - - - - - - - - - - - - - - - - - - - - - >- - - - - >ou= teamA > > | > > ou= DT > > > | > > Computer object (objectClass=computer) > > > > Search Operation: > set search base = deptB > set search scope = subtree search > set deref aliases = always > search for objects of objectClass=computer > >Computer object should not be returned as it does not qualify the scope >criteria for ou=deptb as the base. >Correct ? > >Prasad > >>>> "Kurt D. Zeilenga" 3/28/2003 5:12:53 AM >>> >It should be clear that each and every entry returned in >response to a search request did match the search filter. That >is, if the filter is (CN=foo) than each entry returned has "foo" >as a (not necessarily returned) value of an attribute whose >type is CN or a subtype of CN. > >When dereferencing during searching (by derefInSearching or >derefAlways), the filter should be matched against the entry which >the alias refers to, not the alias itself. > >If the client asks for all alias objects, e.g, (objectClass=alias) >with dereferencing during finding enabled, then no entries should >be returned. Likewise, when requesting (objectClass=*) with >dereferencing during finding enabled, none of entries returned >should belong to the alias objectClass. > >So, to answer your specific question, it is not relevant to >the matching what values of CN the 'alias' has. The values >of the aliased entry are, however, quite relevant. > >Kurt > > >At 11:22 AM 3/26/2003, Chris Harding wrote: >>Hi - >> >>The interpretation of the LDAP RFCs as regards dereferencing has >become an issue for the new certification program that The Open Group >plans to launch for LDAP servers. We have discussed it in the Directory >Interoperability Forum, and agreed that we should ask the experts in the >ldapbis group. Accordingly, I would like to ask your help in clarifying >this issue. >> >>Here's the issue. The requirement in the specification is: >> >> When a server receives a search request with the derefAliases >field >> set to derefInSearching then it will dereference aliases in >subordinates >> of the base object in searching. >> >>We have a test suite for use in the certification program. The suite >includes a test of this requirement (which is in fact derived from a >test in BLITS). The test data includes two entries: Jonathan Adams and >Jonny Adams. The Jonny Adams entry is an alias for Jonathan Adams. >> >>The test should check that Jonny Adams is de-referenced and Jonathan >Adams is returned. The question is, should the test search for Jonny or >for Jonathan. >> >>RFC 2251 does not explain dereferencing but defers to X.501. >Unfortunately, X.501 does not seem to explain it very well. My personal >interpretation after reading it is that, whenever a server encounters an >alias entry in the course of a search and dereferencing has been >requested, the server should dereference the alias and carry on >searching from the entry that the alias points to. Under this >interpretation, a search for Jonny should return the same result as a >search for Jonathan - the Jonathan Adams entry. >> >>I don't claim to be an expert on the interpretation of the >specifications - but I hope that experts in the IETF community can shed >light on this! >> >>Please send your comments to the ldapbis list. I will report the >consensus (assuming that one is reached) to the DIF. >> >>Regards, >> >>Chris >>+++++ >> >>======================================================================== >> Dr. Christopher J. Harding >> T H E Executive Director for the Directory Interoperability >Forum >> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 >> WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >>======================================================================== >> >> The Open Group's Consortia Services - Association >Management For I.T.: >> http://www.opengroup.org/consortia_services >> >>======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 05:39:36 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 FAA15530 for ; Fri, 6 Jun 2003 05:39:35 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h569ZWF7005058; Fri, 6 Jun 2003 09:38:29 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 h569V2oc003841; Fri, 6 Jun 2003 09:31:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 09:31:02 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h569UwEh003793 for ; Fri, 6 Jun 2003 09:30:59 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 19:30:35 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: What Does De-Reference Mean? Date: Fri, 6 Jun 2003 19:30:35 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638128C457@ausyms21.ca.com> Thread-topic: What Does De-Reference Mean? Thread-index: AcMsB3qx+iaaLhHeTIKIgGsmppaqhAAAkiSw From: "Ramsay, Ron" To: "Jim Sermersheim" , X-OriginalArrivalTime: 06 Jun 2003 09:30:35.0760 (UTC) FILETIME=[48B6A700:01C32C0E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h569V0Eh003831 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 OK, so you do not deref when navigating, so the base object is an alias. Now you must return the object but deref aliases while doing it. As it is a subtree search, you must explore the new subtree. Is this it? Hmmmm Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 6 June 2003 18:40 To: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org Subject: RE: What Does De-Reference Mean? Without trying, I guess I did confuse. You went down different path than the one I intended. My issue (which I will leave alone) is the scenario where while "navigating", we are not dereferencing aliases and the search base happens to be an alias. Now, if this is a subtree search, we *Do not* dereference (one of) the object(s) that we are evaluating (namely the search base). In other words, when we deref when searching, and not when navigating, there is the possibility that the search filter is applied to one alias (the search base). There is the possibility that an alias object will be returned from the search. If a server returns an alias object when derefInSearching is set, it will likely confuse some people (with or without my help). Jim >>> "Ramsay, Ron" 6/5/03 10:48:40 PM >>> I'm sorry, but aren't you actually trying to confuse the issue? A search has only ONE base object. To find that base object is called navigation. You may control dereferencing of aliases in navigation. This is in the commonArguments of X.500 but rolled into a search parameter in LDAP. Having navigated to an actual entry (which may be an alias), you now start returning results. For each result DN, you may dereference aliases or not, depending on a parameter in the search request. Dereferenced aliases are not new base-objects of THE search. Of course, a subtree search in which aliases are dereferenced has two side-effects - a) these entries may not appear to be in the orignal scope (can't be helped!) b) these entries out of scope cause 'new' subtree searches to be included (scary). It seems to be b) which is giving (understandable) grief. But let's not confuse the types of dereferencing going on with this effect. (The problem seems to be that the dereferenced alias may have subordinates - are these logically part of the orinal scope? Yes - because, if the entry were not an alias, the real entry with its subordinates would have to appear in place of the alias; No - because the subordinates are not in scope!) Please don't 'over-explain" aliase dereferencing. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 6 June 2003 12:15 To: ietf-ldapbis@OpenLDAP.org Subject: Re: What Does De-Reference Mean? So, I'm trying to clarify this, and it occurs to me once again that I don't like the semantics of derefInSearching. I can't dereference all aliases in the search scope, yet not dereference aliases while resolving the base. This is limiting. I may want a subtree search to fail if there are aliases somewhere in the middle of the DN, so I choose not to derefFindingBaseObject. Yet, once the base object is found (even if it itself is an alias), I want all aliases in my scope to be dereferenced. AFAIK, LDAPv3 is consistent with X.511, so I guess there's not much we can do about it here. Anyway, I do need to clarify the wording. Right now it says "Dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search". This is invalid if the scope is base. It also doesn't tell me to continue a subtree search in the subtree of a dereferenced object. I'll make those two clarifications if no one sees a problem with them. Jim >>> "Kurt D. Zeilenga" 5/21/03 1:56:53 PM >>> At 05:33 AM 5/20/2003, you wrote: >Kurt, >Going by the same argument, the rest of the search criteria e.g. the >base dn and scope of the search should also be applied after the alias >has been derferenced to the actual entry The base DN is "finding" criteria while the scope and filter are "searching" criteria, so my argument does not apply to the base DN but does apply to scope. I couldn't parse your example, so I won't try to comment as to how my clarification applies to it. Kurt >So in the example below, > > ou=deptB > ou=deptA > | > | > alias_teamA - - - - - - - - - - - - - - - - - - - - - - - >- - - - - >ou= teamA > > | > > ou= DT > > > | > > Computer object (objectClass=computer) > > > > Search Operation: > set search base = deptB > set search scope = subtree search > set deref aliases = always > search for objects of objectClass=computer > >Computer object should not be returned as it does not qualify the scope >criteria for ou=deptb as the base. >Correct ? > >Prasad > >>>> "Kurt D. Zeilenga" 3/28/2003 5:12:53 AM >>> >It should be clear that each and every entry returned in >response to a search request did match the search filter. That >is, if the filter is (CN=foo) than each entry returned has "foo" >as a (not necessarily returned) value of an attribute whose >type is CN or a subtype of CN. > >When dereferencing during searching (by derefInSearching or >derefAlways), the filter should be matched against the entry which >the alias refers to, not the alias itself. > >If the client asks for all alias objects, e.g, (objectClass=alias) >with dereferencing during finding enabled, then no entries should >be returned. Likewise, when requesting (objectClass=*) with >dereferencing during finding enabled, none of entries returned >should belong to the alias objectClass. > >So, to answer your specific question, it is not relevant to >the matching what values of CN the 'alias' has. The values >of the aliased entry are, however, quite relevant. > >Kurt > > >At 11:22 AM 3/26/2003, Chris Harding wrote: >>Hi - >> >>The interpretation of the LDAP RFCs as regards dereferencing has >become an issue for the new certification program that The Open Group >plans to launch for LDAP servers. We have discussed it in the Directory >Interoperability Forum, and agreed that we should ask the experts in the >ldapbis group. Accordingly, I would like to ask your help in clarifying >this issue. >> >>Here's the issue. The requirement in the specification is: >> >> When a server receives a search request with the derefAliases >field >> set to derefInSearching then it will dereference aliases in >subordinates >> of the base object in searching. >> >>We have a test suite for use in the certification program. The suite >includes a test of this requirement (which is in fact derived from a >test in BLITS). The test data includes two entries: Jonathan Adams and >Jonny Adams. The Jonny Adams entry is an alias for Jonathan Adams. >> >>The test should check that Jonny Adams is de-referenced and Jonathan >Adams is returned. The question is, should the test search for Jonny or >for Jonathan. >> >>RFC 2251 does not explain dereferencing but defers to X.501. >Unfortunately, X.501 does not seem to explain it very well. My personal >interpretation after reading it is that, whenever a server encounters an >alias entry in the course of a search and dereferencing has been >requested, the server should dereference the alias and carry on >searching from the entry that the alias points to. Under this >interpretation, a search for Jonny should return the same result as a >search for Jonathan - the Jonathan Adams entry. >> >>I don't claim to be an expert on the interpretation of the >specifications - but I hope that experts in the IETF community can shed >light on this! >> >>Please send your comments to the ldapbis list. I will report the >consensus (assuming that one is reached) to the DIF. >> >>Regards, >> >>Chris >>+++++ >> >>======================================================================== >> Dr. Christopher J. Harding >> T H E Executive Director for the Directory Interoperability >Forum >> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 >> WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >>======================================================================== >> >> The Open Group's Consortia Services - Association >Management For I.T.: >> http://www.opengroup.org/consortia_services >> >>======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 08:55:13 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 IAA21731 for ; Fri, 6 Jun 2003 08:55:13 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h56CrXEl021045; Fri, 6 Jun 2003 12:53:56 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 h56Cn3dH020860; Fri, 6 Jun 2003 12:49:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 12:49:03 +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 h56Cn1Eh020847 for ; Fri, 6 Jun 2003 12:49:01 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19OGeS-00054P-00 for ietf-ldapbis@openldap.org; Fri, 6 Jun 2003 14:49:00 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.14) id 19OGcC-00018B-TX for ietf-ldapbis@openldap.org; Fri, 06 Jun 2003 14:46:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19OGc4-0001Df-00 for ietf-ldapbis@openldap.org; Fri, 6 Jun 2003 14:46:32 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19OGc4-00048u-00 for ietf-ldapbis@OpenLDAP.org; Fri, 6 Jun 2003 14:46:32 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: session with expired certificate Date: Fri, 6 Jun 2003 14:46:32 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: The thread about the bindDN being deleted reminded me of something: What happens if the client or server certificate expires during the session? Should the session revert to 'unknown' auth state, as was suggested in the bindDN thread? Should the server or client (depending on which certificate expired) close the TLS session, if any? BTW, is this the same as if the bindDN names a strongAuthenticationUser and binds with its certificate, or is that a third case? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 09:36: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 JAA23047 for ; Fri, 6 Jun 2003 09:36: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 h56DThEl022883; Fri, 6 Jun 2003 13:35:08 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 h56DOqhL022481; Fri, 6 Jun 2003 13:24:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 13:24:52 +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 h56DOoEh022450 for ; Fri, 6 Jun 2003 13:24:50 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 06 Jun 2003 07:24:30 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 06 Jun 2003 07:23:13 -0600 From: "Jim Sermersheim" To: , Subject: RE: What Does De-Reference Mean? 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, but the language in x.511 and ldapv3 prevents this, and only _objects subordinate to the base_ may be dereferenced. >>> "Ramsay, Ron" 6/6/03 3:30:35 AM >>> OK, so you do not deref when navigating, so the base object is an alias. Now you must return the object but deref aliases while doing it. As it is a subtree search, you must explore the new subtree. Is this it? Hmmmm Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 6 June 2003 18:40 To: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org Subject: RE: What Does De-Reference Mean? Without trying, I guess I did confuse. You went down different path than the one I intended. My issue (which I will leave alone) is the scenario where while "navigating", we are not dereferencing aliases and the search base happens to be an alias. Now, if this is a subtree search, we *Do not* dereference (one of) the object(s) that we are evaluating (namely the search base). In other words, when we deref when searching, and not when navigating, there is the possibility that the search filter is applied to one alias (the search base). There is the possibility that an alias object will be returned from the search. If a server returns an alias object when derefInSearching is set, it will likely confuse some people (with or without my help). Jim >>> "Ramsay, Ron" 6/5/03 10:48:40 PM >>> I'm sorry, but aren't you actually trying to confuse the issue? A search has only ONE base object. To find that base object is called navigation. You may control dereferencing of aliases in navigation. This is in the commonArguments of X.500 but rolled into a search parameter in LDAP. Having navigated to an actual entry (which may be an alias), you now start returning results. For each result DN, you may dereference aliases or not, depending on a parameter in the search request. Dereferenced aliases are not new base-objects of THE search. Of course, a subtree search in which aliases are dereferenced has two side-effects - a) these entries may not appear to be in the orignal scope (can't be helped!) b) these entries out of scope cause 'new' subtree searches to be included (scary). It seems to be b) which is giving (understandable) grief. But let's not confuse the types of dereferencing going on with this effect. (The problem seems to be that the dereferenced alias may have subordinates - are these logically part of the orinal scope? Yes - because, if the entry were not an alias, the real entry with its subordinates would have to appear in place of the alias; No - because the subordinates are not in scope!) Please don't 'over-explain" aliase dereferencing. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 6 June 2003 12:15 To: ietf-ldapbis@OpenLDAP.org Subject: Re: What Does De-Reference Mean? So, I'm trying to clarify this, and it occurs to me once again that I don't like the semantics of derefInSearching. I can't dereference all aliases in the search scope, yet not dereference aliases while resolving the base. This is limiting. I may want a subtree search to fail if there are aliases somewhere in the middle of the DN, so I choose not to derefFindingBaseObject. Yet, once the base object is found (even if it itself is an alias), I want all aliases in my scope to be dereferenced. AFAIK, LDAPv3 is consistent with X.511, so I guess there's not much we can do about it here. Anyway, I do need to clarify the wording. Right now it says "Dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search". This is invalid if the scope is base. It also doesn't tell me to continue a subtree search in the subtree of a dereferenced object. I'll make those two clarifications if no one sees a problem with them. Jim >>> "Kurt D. Zeilenga" 5/21/03 1:56:53 PM >>> At 05:33 AM 5/20/2003, you wrote: >Kurt, >Going by the same argument, the rest of the search criteria e.g. the >base dn and scope of the search should also be applied after the alias >has been derferenced to the actual entry The base DN is "finding" criteria while the scope and filter are "searching" criteria, so my argument does not apply to the base DN but does apply to scope. I couldn't parse your example, so I won't try to comment as to how my clarification applies to it. Kurt >So in the example below, > > ou=deptB > ou=deptA > | > | > alias_teamA - - - - - - - - - - - - - - - - - - - - - - - >- - - - - >ou= teamA > > | > > ou= DT > > > | > > Computer object (objectClass=computer) > > > > Search Operation: > set search base = deptB > set search scope = subtree search > set deref aliases = always > search for objects of objectClass=computer > >Computer object should not be returned as it does not qualify the scope >criteria for ou=deptb as the base. >Correct ? > >Prasad > >>>> "Kurt D. Zeilenga" 3/28/2003 5:12:53 AM >>> >It should be clear that each and every entry returned in >response to a search request did match the search filter. That >is, if the filter is (CN=foo) than each entry returned has "foo" >as a (not necessarily returned) value of an attribute whose >type is CN or a subtype of CN. > >When dereferencing during searching (by derefInSearching or >derefAlways), the filter should be matched against the entry which >the alias refers to, not the alias itself. > >If the client asks for all alias objects, e.g, (objectClass=alias) >with dereferencing during finding enabled, then no entries should >be returned. Likewise, when requesting (objectClass=*) with >dereferencing during finding enabled, none of entries returned >should belong to the alias objectClass. > >So, to answer your specific question, it is not relevant to >the matching what values of CN the 'alias' has. The values >of the aliased entry are, however, quite relevant. > >Kurt > > >At 11:22 AM 3/26/2003, Chris Harding wrote: >>Hi - >> >>The interpretation of the LDAP RFCs as regards dereferencing has >become an issue for the new certification program that The Open Group >plans to launch for LDAP servers. We have discussed it in the Directory >Interoperability Forum, and agreed that we should ask the experts in the >ldapbis group. Accordingly, I would like to ask your help in clarifying >this issue. >> >>Here's the issue. The requirement in the specification is: >> >> When a server receives a search request with the derefAliases >field >> set to derefInSearching then it will dereference aliases in >subordinates >> of the base object in searching. >> >>We have a test suite for use in the certification program. The suite >includes a test of this requirement (which is in fact derived from a >test in BLITS). The test data includes two entries: Jonathan Adams and >Jonny Adams. The Jonny Adams entry is an alias for Jonathan Adams. >> >>The test should check that Jonny Adams is de-referenced and Jonathan >Adams is returned. The question is, should the test search for Jonny or >for Jonathan. >> >>RFC 2251 does not explain dereferencing but defers to X.501. >Unfortunately, X.501 does not seem to explain it very well. My personal >interpretation after reading it is that, whenever a server encounters an >alias entry in the course of a search and dereferencing has been >requested, the server should dereference the alias and carry on >searching from the entry that the alias points to. Under this >interpretation, a search for Jonny should return the same result as a >search for Jonathan - the Jonathan Adams entry. >> >>I don't claim to be an expert on the interpretation of the >specifications - but I hope that experts in the IETF community can shed >light on this! >> >>Please send your comments to the ldapbis list. I will report the >consensus (assuming that one is reached) to the DIF. >> >>Regards, >> >>Chris >>+++++ >> >>======================================================================== >> Dr. Christopher J. Harding >> T H E Executive Director for the Directory Interoperability >Forum >> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 >> WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >>======================================================================== >> >> The Open Group's Consortia Services - Association >Management For I.T.: >> http://www.opengroup.org/consortia_services >> >>======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 12:13:29 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 MAA00611 for ; Fri, 6 Jun 2003 12:13:25 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h56GBYEl037660; Fri, 6 Jun 2003 16:12:11 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 h56G7FOH037316; Fri, 6 Jun 2003 16:07:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 6 Jun 2003 16:07:15 +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 h56G7EEh037305 for ; Fri, 6 Jun 2003 16:07:14 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 h56G7Dc6014290; Fri, 6 Jun 2003 16:07:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030606084349.01cb5620@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Jun 2003 09:04:12 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: session with expired certificate Cc: ietf-ldapbis@OpenLDAP.org 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 05:46 AM 6/6/2003, Hallvard B Furuseth wrote: >The thread about the bindDN being deleted reminded me of something: > >What happens if the client or server certificate expires during the >session? Should the session revert to 'unknown' auth state, as was >suggested in the bindDN thread? Should the server or client (depending >on which certificate expired) close the TLS session, if any? I think this is really a TLS issue. From an LDAP perspective, the TLS layer generates a closure alert and we proceed from there. Requirements for implementations to generate a TLS alert in such cases should be stated in TLS specifications. If not adequately covered already, you might comment to the TLS WG. They are currently revising RFC 2246. >BTW, is this the same as if the bindDN names a strongAuthenticationUser >and binds with its certificate, or is that a third case? LDAP does not support the X.511 "strong" method. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 21:31:32 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 VAA20549 for ; Fri, 6 Jun 2003 21:31:31 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h571TcEl068035; Sat, 7 Jun 2003 01:30: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 h571Tam4068027; Sat, 7 Jun 2003 01:29:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 7 Jun 2003 01:29:36 +0000 Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h571TXEh067997; Sat, 7 Jun 2003 01:29:33 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h571TSRG004101; Fri, 6 Jun 2003 18:29:32 -0700 Received: from D-140-142-21-80.dhcp4.washington.edu (D-140-142-21-80.dhcp4.washington.edu [140.142.21.80]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h571TSQ0017988 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 6 Jun 2003 18:29:28 -0700 Date: Fri, 6 Jun 2003 18:29:31 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: "Kurt D. Zeilenga" cc: Hallvard B Furuseth , Subject: Re: session with expired certificate In-Reply-To: <5.2.0.9.0.20030606084349.01cb5620@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: On Fri, 6 Jun 2003, Kurt D. Zeilenga wrote: > At 05:46 AM 6/6/2003, Hallvard B Furuseth wrote: > >The thread about the bindDN being deleted reminded me of something: > > > >What happens if the client or server certificate expires during the > >session? Should the session revert to 'unknown' auth state, as was > >suggested in the bindDN thread? Should the server or client (depending > >on which certificate expired) close the TLS session, if any? > > I think this is really a TLS issue. From an LDAP perspective, the TLS > layer generates a closure alert and we proceed from there. > Requirements for implementations to generate a TLS alert in such cases > should be stated in TLS specifications. If not adequately covered > already, you might comment to the TLS WG. They are currently revising > RFC 2246. I don't think it's something either TLS or LDAP specifications should specify (except maybe as a Security Consideration, please supply text if you want something said). This is really a server (or client) policy issue. In general there is no necessary relation between the duration of a session established with a credential and the validity period of the credential itself. My Kerberos ticket expired an hour ago (which means I've been at work too long), but the IMAP session in which I'm reading this mail continues. - RL "Bob" From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 6 21:36:40 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 VAA20650 for ; Fri, 6 Jun 2003 21:36:40 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h571ZbEl068227; Sat, 7 Jun 2003 01:35: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 h571ZC5l068219; Sat, 7 Jun 2003 01:35:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 7 Jun 2003 01:35:12 +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 h571ZBEh068205 for ; Sat, 7 Jun 2003 01:35:11 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 06 Jun 2003 19:34:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 06 Jun 2003 19:33:36 -0600 From: "Jim Sermersheim" To: Subject: Fwd: Re: StartTLS and referral 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 propose removing the language in [Protocol] that talks about StartTLS returning a referral. Furthermore, I think we need to consider the security ramifications of clients following referrals and state those in the security considerations section. Jim >>> John McMeeking 11/20/02 9:33:49 AM >>> Jim, I the concern was that someone else on the network would maliciously send a referral response to the client while it was negotiating TLS. A correct TLS flow would never involve a referral, and hence the sugegstion that a client never chase a referral received during StartTLS or other similarly sensitive operations. John McMeeking "Jim Sermersheim" To: , Sent by: cc: owner-ietf-ldapbis@O Subject: Re: StartTLS and referral penLDAP.org 11/20/2002 10:09 AM I don't get it. Why would StartTLS return a referral? Start TLS is simply setting up for the TLS handshake. The response is sent to the client before the client presents its certificate. How would the server know, before sending the StartTLS response that another server might be involved? To my mind, referrals are typically only returned when an operation request contains some DN, and during name resolution, that DN is found ot be not local. Jim >>> Mark C Smith 08/09/02 08:50AM >>> Interesting issue. Perhaps servers should not return referrals for startTLS extended ops. and clients should ignore referrals if returned? It seems appropriate to provide some advice in this area. -- Mark Smith AOL Strategic Business Solutions Netscape Directory Product Development My words are my own, not my employer's. Kurt D. Zeilenga wrote: > As anyone thought much about the security considerations > of allowing StartTLS to return a referral. The is no > discussion in RFC2830 that discusses how an attacker, > by injecting a StartTLS response into the stream, > could redirect the client to a server of its choosing > (with a certificate of its choosing). > > Give that many clients auto chase referrals... and > auto-verify certificates, the client might even not notice > that it re-connected to a rogue server with a verifiable > certificate. That is, verifiable with the host name of > the rogue server name. I don't it would make sense > operationally to require the client to verify using the > host name of the original server, but it might sense > security wise. > > Same, I guess, applies to Bind operations... or > initial discovery of security features. > > Anyways, food for thought. > From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 11 05:29:25 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 FAA00379 for ; Wed, 11 Jun 2003 05:29:21 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5B9OCEl013092; Wed, 11 Jun 2003 09:28: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 h5B9Mt6f013024; Wed, 11 Jun 2003 09:22:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 11 Jun 2003 09:22:55 +0000 Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5B9MsEh013014 for ; Wed, 11 Jun 2003 09:22:54 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B9Mnt7023798 for ; Wed, 11 Jun 2003 02:22:53 -0700 Received: from [192.168.1.104] (12-231-112-60.client.attbi.com [12.231.112.60]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B9Mm7k021107 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 11 Jun 2003 02:22:49 -0700 Date: Wed, 11 Jun 2003 02:22:52 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: IETF ldapbis WG Subject: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message initiates a LDAPbis Working Group Last Call on the two documents: LDAP: Syntaxes and Matching Rules draft-ietf-ldapbis-syntaxes-06.txt 3 June 2003 and LDAP: Internationalized String Preparation draft-ietf-ldapbis-strprep-00.txt 26 May 2003 The purpose of this WG Last Call it to ensure that the Working Group has achieved consensus that these documents are suitable for publication as IETF Standards Track RFCs. Please review the documents for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editors. The Last Call period will end on Wednesday, June 25, 2003. Upon completion of the Last Call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Application Area Directors that the documents, after possible editorial or other minor changes, be considered by the IESG for publication as Standards Track RFCs (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! - RL "Bob" Morgan LDAPbis co-chair From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 03:33: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 DAA23957 for ; Fri, 13 Jun 2003 03:33:23 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5D7UREl064100; Fri, 13 Jun 2003 07:31:09 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 h5D7Th5U064058; Fri, 13 Jun 2003 07:29:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 07:29:43 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5D7TfEh064048 for ; Fri, 13 Jun 2003 07:29:41 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 ([199.72.166.218]) by echt.caledonia.net; Fri, 13 Jun 2003 01:29:05 -0600 Reply-To: From: "Chris Apple" To: Subject: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 03:28:54 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000b01c3317d$75080a00$5f0aa8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have encountered a problem while attempting to extend the basic schema of several different LDAPv3 server implementations. Specifically, some of them place restrictions on the length of attribute names. In one case, the attribute name length restriction is rather short, too short to make it possible for it to distinguish between two different attribute names with the same character string as a prefix. Take a look at the DEN schema for examples of such attribute names. So far, I cannot find a requirement in any LDAP-related RFC or I-D that addresses the issue of attribute name length bounds. This means that you cannot take the same schema specification and apply it verbatim to different LDAPv3 server implementations and to me represents an inhibitor to interoperability of clients and servers that have different attribute length restrictions/constraints/etc. However, I am not sure where to suggest adding such a requirement to clarify the nature of the problem to implementers so that this interoperability impact can be minimized. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 03:55:44 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 DAA24449 for ; Fri, 13 Jun 2003 03:55: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 h5D7sREl065227; Fri, 13 Jun 2003 07: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 h5D7rowd065180; Fri, 13 Jun 2003 07:53:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 07:53:50 +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 h5D7rnEh065159 for ; Fri, 13 Jun 2003 07:53:49 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Jun 2003 01:53:29 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 13 Jun 2003 01:52:10 -0600 From: "Jim Sermersheim" To: Subject: Re: Attribute Name Length Bounds 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 As far as I know, neither [Models] nor [Protocol] limits the lenght of attribute names. Any limitiation in a specific implementation is imposed by that implementation, not by the spec, so I'm not sure we can do anything about it here. Obviously no server allows an unlimited length, as they are all limiited if by nothing more than available memory. I'm not sure if this fits into an implementation report. It seems more appropriate for a certification/branding program. Other than that, it seems like a valid defect to raise with those implementors who restrict to unreasonable limits. Jim >>> "Chris Apple" 6/13/03 1:28:54 AM >>> I have encountered a problem while attempting to extend the basic schema of several different LDAPv3 server implementations. Specifically, some of them place restrictions on the length of attribute names. In one case, the attribute name length restriction is rather short, too short to make it possible for it to distinguish between two different attribute names with the same character string as a prefix. Take a look at the DEN schema for examples of such attribute names. So far, I cannot find a requirement in any LDAP-related RFC or I-D that addresses the issue of attribute name length bounds. This means that you cannot take the same schema specification and apply it verbatim to different LDAPv3 server implementations and to me represents an inhibitor to interoperability of clients and servers that have different attribute length restrictions/constraints/etc. However, I am not sure where to suggest adding such a requirement to clarify the nature of the problem to implementers so that this interoperability impact can be minimized. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 09:35:36 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 JAA04201 for ; Fri, 13 Jun 2003 09:35: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 h5DDUTEl086436; Fri, 13 Jun 2003 13:34:12 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 h5DDQgm8086175; Fri, 13 Jun 2003 13:26:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 13:26:42 +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 h5DDQfEh086141 for ; Fri, 13 Jun 2003 13:26:41 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 h5DDQKn11373 for ; Fri, 13 Jun 2003 06:26:20 -0700 (PDT) Received: from netscape.com ([10.169.192.20]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HGF9BS02.VLF; Fri, 13 Jun 2003 06:26:16 -0700 Message-ID: <3EE9D0F4.7060805@netscape.com> Date: Fri, 13 Jun 2003 09:26:12 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030428 Netscape/7.02+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds 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: > As far as I know, neither [Models] nor [Protocol] limits the lenght of > attribute names. Any limitiation in a specific implementation is imposed > by that implementation, not by the spec, so I'm not sure we can do > anything about it here. > > Obviously no server allows an unlimited length, as they are all > limiited if by nothing more than available memory. I'm not sure if this > fits into an implementation report. It seems more appropriate for a > certification/branding program. Other than that, it seems like a valid > defect to raise with those implementors who restrict to unreasonable > limits. I agree. I tried to come up with text that we could add to [Models] or [Protocols] that would encourage implementors to not impose arbitrary, short limits... but I am not sure how to word such a requirement so it is meaningful. This is an interesting interoperability problem though. -Mark From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 11:03: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 LAA09018 for ; Fri, 13 Jun 2003 11:03: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 h5DF0sEp091399; Fri, 13 Jun 2003 15:01:47 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 h5DEmpIA090550; Fri, 13 Jun 2003 14:48:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 14:48:51 +0000 Received: from mx-relay21.treas.gov (mx-relay21.treas.gov [199.196.132.5]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DEmnEh090535 for ; Fri, 13 Jun 2003 14:48:50 GMT (envelope-from lbartz@parnelli.indy.cr.irs.gov) Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with SMTP id h5DEYYRf024680 for ; Fri, 13 Jun 2003 10:34:34 -0400 (EDT) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 13 Jun 2003 14:48:35 UT Received: from irsbd1.net.treas.gov (localhost [127.0.0.1]) by mailhub-21.net.treas.gov (8.12.9/8.12.9) with ESMTP id h5DEmTdS020453 for ; Fri, 13 Jun 2003 10:48:29 -0400 (EDT) Received: from no.name.available by irsbd1.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.13.252.11]) with ESMTP; Fri, 13 Jun 2003 14:48:26 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h5DEmSf01238 for ; Fri, 13 Jun 2003 09:48:28 -0500 Message-ID: <3EE9E43C.408@parnelli.indy.cr.irs.gov> Date: Fri, 13 Jun 2003 09:48:28 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds References: <3EE9D0F4.7060805@netscape.com> In-Reply-To: <3EE9D0F4.7060805@netscape.com> 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 Mark C Smith wrote, On 06/13/03 08:26: > Jim Sermersheim wrote: > >> As far as I know, neither [Models] nor [Protocol] limits the lenght of >> attribute names. Any limitiation in a specific implementation is imposed >> by that implementation, not by the spec, so I'm not sure we can do >> anything about it here. >> >> Obviously no server allows an unlimited length, as they are all >> limiited if by nothing more than available memory. I'm not sure if this >> fits into an implementation report. It seems more appropriate for a >> certification/branding program. Other than that, it seems like a valid >> defect to raise with those implementors who restrict to unreasonable >> limits. > > > I agree. I tried to come up with text that we could add to [Models] or > [Protocols] that would encourage implementors to not impose arbitrary, > short limits... but I am not sure how to word such a requirement so it > is meaningful. This is an interesting interoperability problem though. > > -Mark Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 "IANA Considerations for LDAP" would be helpful. It says, "While the protocol places no maximum length restriction upon descriptors, they should be short. Descriptors longer than 48 characters may be viewed as too long to register." There was obviously consensus in this WG regarding that length and that language. -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 11:50:24 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 LAA10342 for ; Fri, 13 Jun 2003 11:50:23 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DFmUEl093578; Fri, 13 Jun 2003 15:48:56 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 h5DFjEPP093429; Fri, 13 Jun 2003 15:45:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 15:45:14 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DFjBEh093419 for ; Fri, 13 Jun 2003 15:45:12 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Fri, 13 Jun 2003 09:44:37 -0600 Reply-To: From: "Chris Apple" To: "'Larry S. Bartz'" , Subject: RE: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 11:44:27 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000201c331c2$af386130$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3EE9E43C.408@parnelli.indy.cr.irs.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I was thinking more along the lines of a minimum bound in one of the LDAPv3 Draft Standard documents. How about this for a requirement? "Implementations MUST support attribute names that are at least 32 characters in length." It seems like a simple one without a lot of baggage to me. But if anyone thinks there's a good reason not to include it, I'd like to know what that is. I have no strong opinions on an upper bound. I do realize that there is a work-around for this problem in most cases. You can create a shorter attribute name and then use the intended attribute name as an alias. But this gets to be a bit complicated when rolling out services that use schema designed with longer attribute names. You have to perform testing to see what each implementation in question supports and then create aliases matching up with the shortest supported attribute name length. As a service implementer, that's an awfully expensive interoperability hoop to have to jump through if I'm using a technology that is soon to be based on a Draft Standard. I realize that someone might also want a larger attribute name length but there seems to already be some restriction with respect to what may be allowable from an IANA registration perspective. I'm not questioning that because 48 characters for an upper bound seems reasonable to me. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz Sent: Friday, June 13, 2003 10:48 AM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds Mark C Smith wrote, On 06/13/03 08:26: > Jim Sermersheim wrote: > >> As far as I know, neither [Models] nor [Protocol] limits the lenght of >> attribute names. Any limitiation in a specific implementation is imposed >> by that implementation, not by the spec, so I'm not sure we can do >> anything about it here. >> >> Obviously no server allows an unlimited length, as they are all >> limiited if by nothing more than available memory. I'm not sure if this >> fits into an implementation report. It seems more appropriate for a >> certification/branding program. Other than that, it seems like a valid >> defect to raise with those implementors who restrict to unreasonable >> limits. > > > I agree. I tried to come up with text that we could add to [Models] or > [Protocols] that would encourage implementors to not impose arbitrary, > short limits... but I am not sure how to word such a requirement so it > is meaningful. This is an interesting interoperability problem though. > > -Mark Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 "IANA Considerations for LDAP" would be helpful. It says, "While the protocol places no maximum length restriction upon descriptors, they should be short. Descriptors longer than 48 characters may be viewed as too long to register." There was obviously consensus in this WG regarding that length and that language. -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 12:01: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 MAA10544 for ; Fri, 13 Jun 2003 12:01:38 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DG0UEl093938; Fri, 13 Jun 2003 16:00:33 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 h5DFv1Ea093833; Fri, 13 Jun 2003 15:57:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 15:57:01 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DFuxEh093823 for ; Fri, 13 Jun 2003 15:56:59 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Fri, 13 Jun 2003 09:56:20 -0600 Reply-To: From: "Chris Apple" To: "'Jim Sermersheim'" , Subject: RE: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 11:56:11 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000401c331c4$5251a7e0$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5DFv0Eh093824 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 could certainly raise it within an interoperability/certification program like that which The Open Group has. But generally, the certification tests follow the specs. So unless there's a requirement relating to this issue in the specs, it is unlikely to be adopted as a certification requirement. I think the interoperability problem I encountered is caused by lack of a requirement specifying a lower bound. Its basically a grey area as the specs stand now. My interpretation of the LDAPBIS charter is that this is the place where grey areas are to be clarified in preparation for progressing LDAPv3 to Draft Standard. In reminding myself what Draft Standard means (RFC 2026, Section 4.1.2), clarifying grey areas affecting interoperability would seem to fit within the scope of the LDABBIS WG Charter. The group may not agree with my position on this particular issue, but this does appear to be the appropriate place to raise it. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Friday, June 13, 2003 3:52 AM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds As far as I know, neither [Models] nor [Protocol] limits the lenght of attribute names. Any limitiation in a specific implementation is imposed by that implementation, not by the spec, so I'm not sure we can do anything about it here. Obviously no server allows an unlimited length, as they are all limiited if by nothing more than available memory. I'm not sure if this fits into an implementation report. It seems more appropriate for a certification/branding program. Other than that, it seems like a valid defect to raise with those implementors who restrict to unreasonable limits. Jim >>> "Chris Apple" 6/13/03 1:28:54 AM >>> I have encountered a problem while attempting to extend the basic schema of several different LDAPv3 server implementations. Specifically, some of them place restrictions on the length of attribute names. In one case, the attribute name length restriction is rather short, too short to make it possible for it to distinguish between two different attribute names with the same character string as a prefix. Take a look at the DEN schema for examples of such attribute names. So far, I cannot find a requirement in any LDAP-related RFC or I-D that addresses the issue of attribute name length bounds. This means that you cannot take the same schema specification and apply it verbatim to different LDAPv3 server implementations and to me represents an inhibitor to interoperability of clients and servers that have different attribute length restrictions/constraints/etc. However, I am not sure where to suggest adding such a requirement to clarify the nature of the problem to implementers so that this interoperability impact can be minimized. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 13:31:59 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 NAA14860 for ; Fri, 13 Jun 2003 13:31:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DHUUEp097676; Fri, 13 Jun 2003 17:31: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 h5DHPkJa097398; Fri, 13 Jun 2003 17:25:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 17:25:45 +0000 Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DHPgEh097372 for ; Fri, 13 Jun 2003 17:25:42 GMT (envelope-from rvh@qsun.mt.att.com) Received: from qsun.mt.att.com ([135.16.157.16]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5DHP2HL004376; Fri, 13 Jun 2003 12:25:02 -0500 Received: by qsun.mt.att.com (8.8.8p2+Sun/ATTEMS-1.4.1 sol2) id NAA10540; Fri, 13 Jun 2003 13:24:51 -0400 (EDT) Date: Fri, 13 Jun 2003 13:24:51 -0400 (EDT) Message-Id: <200306131724.NAA10540@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: capple@dsi-consulting.net, ietf-ldapbis@OpenLDAP.org, lbartz@parnelli.indy.cr.irs.gov Subject: RE: Attribute Name Length Bounds 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: In line with Larry Bartz' email mentioning RFC3383, how about: To promote interoperability, server implementors SHOULD allow at least 48 characters for attribute names and schema designers SHOULD use attribute names which are no longer than 48 characters. If we allow 48 character names to be registered, the standard ought to support them. I don't see much use for an upper bound. People who are worried about interoperability always have to live within the lower bound in any case. Rick Huber : From owner-ietf-ldapbis@openldap.org Fri Jun 13 11:53:42 2003 : Return-Path: : From: "Chris Apple" : To: "'Larry S. Bartz'" , : : Subject: RE: Attribute Name Length Bounds : Sender: owner-ietf-ldapbis@openldap.org : Precedence: bulk : Comment: ietf-ldapbis mailing list : List-Archive: : List-Help: : List-Unsubscribe: : : I was thinking more along the lines of a minimum bound in one of the : LDAPv3 Draft Standard documents. : : How about this for a requirement? : : "Implementations MUST support attribute names that are at least 32 : characters in length." : : It seems like a simple one without a lot of baggage to me. But if anyone : thinks there's a good reason not to include it, I'd like to know what : that is. : : I have no strong opinions on an upper bound. : : I do realize that there is a work-around for this problem in most cases. : You can create a shorter attribute name and then use the intended attribute : name as an alias. But this gets to be a bit complicated when rolling out : services that use schema designed with longer attribute names. : : You have to perform testing to see what each implementation in question : supports and then create aliases matching up with the shortest supported : attribute name length. : : As a service implementer, that's an awfully expensive interoperability : hoop to have to jump through if I'm using a technology that is soon to : be based on a Draft Standard. : : I realize that someone might also want a larger attribute name length : but there seems to already be some restriction with respect to what may be : allowable from an IANA registration perspective. I'm not questioning that : because 48 characters for an upper bound seems reasonable to me. : : Chris Apple - Principal Architect : : DSI Consulting, Inc. : : mailto:capple@dsi-consulting.net : : http://www.dsi-consulting.com : : -----Original Message----- : From: owner-ietf-ldapbis@OpenLDAP.org : [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz : Sent: Friday, June 13, 2003 10:48 AM : To: ietf-ldapbis@OpenLDAP.org : Subject: Re: Attribute Name Length Bounds : : : Mark C Smith wrote, On 06/13/03 08:26: : > Jim Sermersheim wrote: : > : >> As far as I know, neither [Models] nor [Protocol] limits the lenght of : >> attribute names. Any limitiation in a specific implementation is imposed : >> by that implementation, not by the spec, so I'm not sure we can do : >> anything about it here. : >> : >> Obviously no server allows an unlimited length, as they are all : >> limiited if by nothing more than available memory. I'm not sure if this : >> fits into an implementation report. It seems more appropriate for a : >> certification/branding program. Other than that, it seems like a valid : >> defect to raise with those implementors who restrict to unreasonable : >> limits. : > : > : > I agree. I tried to come up with text that we could add to [Models] or : > [Protocols] that would encourage implementors to not impose arbitrary, : > short limits... but I am not sure how to word such a requirement so it : > is meaningful. This is an interesting interoperability problem though. : > : > -Mark : : : Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 : "IANA Considerations for LDAP" would be helpful. It says, : : "While the protocol places no maximum length restriction upon : descriptors, they should be short. Descriptors longer than 48 : characters may be viewed as too long to register." : : There was obviously consensus in this WG regarding that length and : that language. : : -- : -- : #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| : # Larry Bartz | | : # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | : # | Ooo, ooo, oooooo! | : # | I've got a gnu attitude! | : # voice (317) 226-7060 | | : # FAX (317) 226-6378 | | : #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| : : : From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 13:32:02 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 NAA14877 for ; Fri, 13 Jun 2003 13:32: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 h5DHUUEr097676; Fri, 13 Jun 2003 17:31:07 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 h5DHSIUp097573; Fri, 13 Jun 2003 17:28:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 17:28:18 +0000 Received: from mx-relay1.net.treas.gov (mx-relay1.treas.gov [199.196.144.5]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DHSGEh097563 for ; Fri, 13 Jun 2003 17:28:17 GMT (envelope-from lbartz@parnelli.indy.cr.irs.gov) Received: from tias5.treas.gov (tias-gw5.treas.gov [199.196.144.15]) by mx-relay1.net.treas.gov (8.12.9/8.12.9) with SMTP id h5DHSCGE023751; Fri, 13 Jun 2003 13:28:13 -0400 (EDT) Received: from mailhub.net.treas.gov by tias5.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 13 Jun 2003 17:28:12 UT Received: from irsbd3.net.treas.gov (localhost [127.0.0.1]) by mailhub-4.net.treas.gov (8.12.9/8.12.9) with ESMTP id h5DHS6Ri028101; Fri, 13 Jun 2003 13:28:06 -0400 (EDT) Received: from no.name.available by irsbd3.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.7.14.14]) with ESMTP; Fri, 13 Jun 2003 21:28:36 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h5DHS5f01708; Fri, 13 Jun 2003 12:28:05 -0500 Message-ID: <3EEA09A5.1050603@parnelli.indy.cr.irs.gov> Date: Fri, 13 Jun 2003 12:28:05 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: capple@dsi-consulting.net CC: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds References: <000201c331c2$af386130$3d00000a@D7ST2111> In-Reply-To: <000201c331c2$af386130$3d00000a@D7ST2111> 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 Chris Apple wrote, On 06/13/03 10:44: > I was thinking more along the lines of a minimum bound in one of the > LDAPv3 Draft Standard documents. > > How about this for a requirement? > > "Implementations MUST support attribute names that are at least 32 > characters in length." How about 48? If IANA's ub is 48, then implementations could reasonably expect to see names of that length. All products and implementations should be prepared to support that. Further, the requirement should not be limited to attributetype names. The spec in RFC 3383 covers all object identifier descriptors, which includes attributetype names, objectclass names, matching rule names, etc. How about this? "Implementations MUST support object identifier descriptors (such as attributetype names, objectclass names, matching rule names, and the like) which are at least 48 characters in length." Larry > > It seems like a simple one without a lot of baggage to me. But if anyone > thinks there's a good reason not to include it, I'd like to know what > that is. > > I have no strong opinions on an upper bound. > > I do realize that there is a work-around for this problem in most cases. > You can create a shorter attribute name and then use the intended attribute > name as an alias. But this gets to be a bit complicated when rolling out > services that use schema designed with longer attribute names. > > You have to perform testing to see what each implementation in question > supports and then create aliases matching up with the shortest supported > attribute name length. > > As a service implementer, that's an awfully expensive interoperability > hoop to have to jump through if I'm using a technology that is soon to > be based on a Draft Standard. > > I realize that someone might also want a larger attribute name length > but there seems to already be some restriction with respect to what may be > allowable from an IANA registration perspective. I'm not questioning that > because 48 characters for an upper bound seems reasonable to me. > > Chris Apple - Principal Architect > > DSI Consulting, Inc. > > mailto:capple@dsi-consulting.net > > http://www.dsi-consulting.com > > -----Original Message----- > From: owner-ietf-ldapbis@OpenLDAP.org > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz > Sent: Friday, June 13, 2003 10:48 AM > To: ietf-ldapbis@OpenLDAP.org > Subject: Re: Attribute Name Length Bounds > > > Mark C Smith wrote, On 06/13/03 08:26: > >>Jim Sermersheim wrote: >> >> >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of >>>attribute names. Any limitiation in a specific implementation is imposed >>>by that implementation, not by the spec, so I'm not sure we can do >>>anything about it here. >>> >>>Obviously no server allows an unlimited length, as they are all >>>limiited if by nothing more than available memory. I'm not sure if this >>>fits into an implementation report. It seems more appropriate for a >>>certification/branding program. Other than that, it seems like a valid >>>defect to raise with those implementors who restrict to unreasonable >>>limits. >> >> >>I agree. I tried to come up with text that we could add to [Models] or >>[Protocols] that would encourage implementors to not impose arbitrary, >>short limits... but I am not sure how to word such a requirement so it >>is meaningful. This is an interesting interoperability problem though. >> >>-Mark > > > > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 > "IANA Considerations for LDAP" would be helpful. It says, > > "While the protocol places no maximum length restriction upon > descriptors, they should be short. Descriptors longer than 48 > characters may be viewed as too long to register." > > There was obviously consensus in this WG regarding that length and > that language. > From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 13:37:35 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 NAA15132 for ; Fri, 13 Jun 2003 13:37: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 h5DHaUEl098020; Fri, 13 Jun 2003 17:36:33 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 h5DHXP0q097868; Fri, 13 Jun 2003 17:33:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 17:33:25 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DHXLEh097826 for ; Fri, 13 Jun 2003 17:33:22 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Fri, 13 Jun 2003 11:32:49 -0600 Reply-To: From: "Chris Apple" To: "'Larry S. Bartz'" Cc: Subject: RE: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 13:32:35 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000b01c331d1$cc45fad0$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3EEA09A5.1050603@parnelli.indy.cr.irs.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5DHXNEh097842 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 Works for me. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] Sent: Friday, June 13, 2003 1:28 PM To: capple@dsi-consulting.net Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds Chris Apple wrote, On 06/13/03 10:44: > I was thinking more along the lines of a minimum bound in one of the > LDAPv3 Draft Standard documents. > > How about this for a requirement? > > "Implementations MUST support attribute names that are at least 32 > characters in length." How about 48? If IANA's ub is 48, then implementations could reasonably expect to see names of that length. All products and implementations should be prepared to support that. Further, the requirement should not be limited to attributetype names. The spec in RFC 3383 covers all object identifier descriptors, which includes attributetype names, objectclass names, matching rule names, etc. How about this? "Implementations MUST support object identifier descriptors (such as attributetype names, objectclass names, matching rule names, and the like) which are at least 48 characters in length." Larry > > It seems like a simple one without a lot of baggage to me. But if anyone > thinks there's a good reason not to include it, I'd like to know what > that is. > > I have no strong opinions on an upper bound. > > I do realize that there is a work-around for this problem in most cases. > You can create a shorter attribute name and then use the intended attribute > name as an alias. But this gets to be a bit complicated when rolling out > services that use schema designed with longer attribute names. > > You have to perform testing to see what each implementation in question > supports and then create aliases matching up with the shortest supported > attribute name length. > > As a service implementer, that's an awfully expensive interoperability > hoop to have to jump through if I'm using a technology that is soon to > be based on a Draft Standard. > > I realize that someone might also want a larger attribute name length > but there seems to already be some restriction with respect to what may be > allowable from an IANA registration perspective. I'm not questioning that > because 48 characters for an upper bound seems reasonable to me. > > Chris Apple - Principal Architect > > DSI Consulting, Inc. > > mailto:capple@dsi-consulting.net > > http://www.dsi-consulting.com > > -----Original Message----- > From: owner-ietf-ldapbis@OpenLDAP.org > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz > Sent: Friday, June 13, 2003 10:48 AM > To: ietf-ldapbis@OpenLDAP.org > Subject: Re: Attribute Name Length Bounds > > > Mark C Smith wrote, On 06/13/03 08:26: > >>Jim Sermersheim wrote: >> >> >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of >>>attribute names. Any limitiation in a specific implementation is imposed >>>by that implementation, not by the spec, so I'm not sure we can do >>>anything about it here. >>> >>>Obviously no server allows an unlimited length, as they are all >>>limiited if by nothing more than available memory. I'm not sure if this >>>fits into an implementation report. It seems more appropriate for a >>>certification/branding program. Other than that, it seems like a valid >>>defect to raise with those implementors who restrict to unreasonable >>>limits. >> >> >>I agree. I tried to come up with text that we could add to [Models] or >>[Protocols] that would encourage implementors to not impose arbitrary, >>short limits... but I am not sure how to word such a requirement so it >>is meaningful. This is an interesting interoperability problem though. >> >>-Mark > > > > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 > "IANA Considerations for LDAP" would be helpful. It says, > > "While the protocol places no maximum length restriction upon > descriptors, they should be short. Descriptors longer than 48 > characters may be viewed as too long to register." > > There was obviously consensus in this WG regarding that length and > that language. > From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 13:43:36 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 NAA15338 for ; Fri, 13 Jun 2003 13:43:35 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DHgUEl098288; Fri, 13 Jun 2003 17:42:33 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 h5DHe7DN098139; Fri, 13 Jun 2003 17:40:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 17:40:07 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DHe4Eh098128 for ; Fri, 13 Jun 2003 17:40:04 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Fri, 13 Jun 2003 11:39:34 -0600 Reply-To: From: "Chris Apple" To: "'Richard V Huber'" , , Subject: RE: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 13:39:24 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000c01c331d2$be12c460$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200306131724.NAA10540@qsun.mt.att.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5DHe6Eh098130 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm in favor of the clarification about what schema designers should do. I also like Larry's broader language for the types of names to which this lower bound applies. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Richard V Huber Sent: Friday, June 13, 2003 1:25 PM To: capple@dsi-consulting.net; ietf-ldapbis@OpenLDAP.org; lbartz@parnelli.indy.cr.irs.gov Subject: RE: Attribute Name Length Bounds In line with Larry Bartz' email mentioning RFC3383, how about: To promote interoperability, server implementors SHOULD allow at least 48 characters for attribute names and schema designers SHOULD use attribute names which are no longer than 48 characters. If we allow 48 character names to be registered, the standard ought to support them. I don't see much use for an upper bound. People who are worried about interoperability always have to live within the lower bound in any case. Rick Huber : From owner-ietf-ldapbis@openldap.org Fri Jun 13 11:53:42 2003 : Return-Path: : From: "Chris Apple" : To: "'Larry S. Bartz'" , : : Subject: RE: Attribute Name Length Bounds : Sender: owner-ietf-ldapbis@openldap.org : Precedence: bulk : Comment: ietf-ldapbis mailing list : List-Archive: : List-Help: : List-Unsubscribe: : : I was thinking more along the lines of a minimum bound in one of the : LDAPv3 Draft Standard documents. : : How about this for a requirement? : : "Implementations MUST support attribute names that are at least 32 : characters in length." : : It seems like a simple one without a lot of baggage to me. But if anyone : thinks there's a good reason not to include it, I'd like to know what : that is. : : I have no strong opinions on an upper bound. : : I do realize that there is a work-around for this problem in most cases. : You can create a shorter attribute name and then use the intended attribute : name as an alias. But this gets to be a bit complicated when rolling out : services that use schema designed with longer attribute names. : : You have to perform testing to see what each implementation in question : supports and then create aliases matching up with the shortest supported : attribute name length. : : As a service implementer, that's an awfully expensive interoperability : hoop to have to jump through if I'm using a technology that is soon to : be based on a Draft Standard. : : I realize that someone might also want a larger attribute name length : but there seems to already be some restriction with respect to what may be : allowable from an IANA registration perspective. I'm not questioning that : because 48 characters for an upper bound seems reasonable to me. : : Chris Apple - Principal Architect : : DSI Consulting, Inc. : : mailto:capple@dsi-consulting.net : : http://www.dsi-consulting.com : : -----Original Message----- : From: owner-ietf-ldapbis@OpenLDAP.org : [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz : Sent: Friday, June 13, 2003 10:48 AM : To: ietf-ldapbis@OpenLDAP.org : Subject: Re: Attribute Name Length Bounds : : : Mark C Smith wrote, On 06/13/03 08:26: : > Jim Sermersheim wrote: : > : >> As far as I know, neither [Models] nor [Protocol] limits the lenght of : >> attribute names. Any limitiation in a specific implementation is imposed : >> by that implementation, not by the spec, so I'm not sure we can do : >> anything about it here. : >> : >> Obviously no server allows an unlimited length, as they are all : >> limiited if by nothing more than available memory. I'm not sure if this : >> fits into an implementation report. It seems more appropriate for a : >> certification/branding program. Other than that, it seems like a valid : >> defect to raise with those implementors who restrict to unreasonable : >> limits. : > : > : > I agree. I tried to come up with text that we could add to [Models] or : > [Protocols] that would encourage implementors to not impose arbitrary, : > short limits... but I am not sure how to word such a requirement so it : > is meaningful. This is an interesting interoperability problem though. : > : > -Mark : : : Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 : "IANA Considerations for LDAP" would be helpful. It says, : : "While the protocol places no maximum length restriction upon : descriptors, they should be short. Descriptors longer than 48 : characters may be viewed as too long to register." : : There was obviously consensus in this WG regarding that length and : that language. : : -- : -- : #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| : # Larry Bartz | | : # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | : # | Ooo, ooo, oooooo! | : # | I've got a gnu attitude! | : # voice (317) 226-7060 | | : # FAX (317) 226-6378 | | : #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| : : : From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 14:06:26 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 OAA16052 for ; Fri, 13 Jun 2003 14:06:25 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DI0UEr099279; Fri, 13 Jun 2003 18:05:26 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 h5DHtvtE098973; Fri, 13 Jun 2003 17:55:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 17:55:57 +0000 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DHttEh098945 for ; Fri, 13 Jun 2003 17:55:55 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5DHtVxr186680 for ; Fri, 13 Jun 2003 13:55:31 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5DHtTYj191962 for ; Fri, 13 Jun 2003 13:55:29 -0400 Subject: RE: Attribute Name Length Bounds To: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 13 Jun 2003 12:55:24 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 06/13/2003 12:55:29 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: Should the "schema designers SHOULD" be accompanied by something like "Standards track schemas MUST use ..."? Or does that go better with IANA name registration? Also, I assume this entire discussion applies to objectclass names. John McMeeking rvh@qsun.mt.att.com (Richard V Huber) To: capple@dsi-consulting.net, ietf-ldapbis@OpenLDAP.org, Sent by: lbartz@parnelli.indy.cr.irs.gov owner-ietf-ldapbis@O cc: penLDAP.org Subject: RE: Attribute Name Length Bounds 06/13/2003 12:24 PM In line with Larry Bartz' email mentioning RFC3383, how about: To promote interoperability, server implementors SHOULD allow at least 48 characters for attribute names and schema designers SHOULD use attribute names which are no longer than 48 characters. If we allow 48 character names to be registered, the standard ought to support them. I don't see much use for an upper bound. People who are worried about interoperability always have to live within the lower bound in any case. Rick Huber : From owner-ietf-ldapbis@openldap.org Fri Jun 13 11:53:42 2003 : Return-Path: : From: "Chris Apple" : To: "'Larry S. Bartz'" , : : Subject: RE: Attribute Name Length Bounds : Sender: owner-ietf-ldapbis@openldap.org : Precedence: bulk : Comment: ietf-ldapbis mailing list : List-Archive: : List-Help: : List-Unsubscribe: < mailto:ietf-ldapbis-request@OpenLDAP.org?body=unsubscribe> : : I was thinking more along the lines of a minimum bound in one of the : LDAPv3 Draft Standard documents. : : How about this for a requirement? : : "Implementations MUST support attribute names that are at least 32 : characters in length." : : It seems like a simple one without a lot of baggage to me. But if anyone : thinks there's a good reason not to include it, I'd like to know what : that is. : : I have no strong opinions on an upper bound. : : I do realize that there is a work-around for this problem in most cases. : You can create a shorter attribute name and then use the intended attribute : name as an alias. But this gets to be a bit complicated when rolling out : services that use schema designed with longer attribute names. : : You have to perform testing to see what each implementation in question : supports and then create aliases matching up with the shortest supported : attribute name length. : : As a service implementer, that's an awfully expensive interoperability : hoop to have to jump through if I'm using a technology that is soon to : be based on a Draft Standard. : : I realize that someone might also want a larger attribute name length : but there seems to already be some restriction with respect to what may be : allowable from an IANA registration perspective. I'm not questioning that : because 48 characters for an upper bound seems reasonable to me. : : Chris Apple - Principal Architect : : DSI Consulting, Inc. : : mailto:capple@dsi-consulting.net : : http://www.dsi-consulting.com : : -----Original Message----- : From: owner-ietf-ldapbis@OpenLDAP.org : [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz : Sent: Friday, June 13, 2003 10:48 AM : To: ietf-ldapbis@OpenLDAP.org : Subject: Re: Attribute Name Length Bounds : : : Mark C Smith wrote, On 06/13/03 08:26: : > Jim Sermersheim wrote: : > : >> As far as I know, neither [Models] nor [Protocol] limits the lenght of : >> attribute names. Any limitiation in a specific implementation is imposed : >> by that implementation, not by the spec, so I'm not sure we can do : >> anything about it here. : >> : >> Obviously no server allows an unlimited length, as they are all : >> limiited if by nothing more than available memory. I'm not sure if this : >> fits into an implementation report. It seems more appropriate for a : >> certification/branding program. Other than that, it seems like a valid : >> defect to raise with those implementors who restrict to unreasonable : >> limits. : > : > : > I agree. I tried to come up with text that we could add to [Models] or : > [Protocols] that would encourage implementors to not impose arbitrary, : > short limits... but I am not sure how to word such a requirement so it : > is meaningful. This is an interesting interoperability problem though. : > : > -Mark : : : Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 : "IANA Considerations for LDAP" would be helpful. It says, : : "While the protocol places no maximum length restriction upon : descriptors, they should be short. Descriptors longer than 48 : characters may be viewed as too long to register." : : There was obviously consensus in this WG regarding that length and : that language. : : -- : -- : #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| : # Larry Bartz | | : # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | : # | Ooo, ooo, oooooo! | : # | I've got a gnu attitude! | : # voice (317) 226-7060 | | : # FAX (317) 226-6378 | | : #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| : : : From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 14:06:30 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 OAA16068 for ; Fri, 13 Jun 2003 14:06:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DI0UEt099279; Fri, 13 Jun 2003 18:05: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 h5DHxn0J099216; Fri, 13 Jun 2003 17:59:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 17:59:49 +0000 Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DHxlEh099204 for ; Fri, 13 Jun 2003 17:59:47 GMT (envelope-from kdally@mitre.org) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.12.9/8.12.8) with ESMTP id h5DHxgn5022560; Fri, 13 Jun 2003 13:59:42 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.12.9/8.12.8) with ESMTP id h5DHxcOH012729; Fri, 13 Jun 2003 13:59:39 -0400 (EDT) Received: from mm109527-2k.mitre.org (128.29.3.80) by mailhub1.mitre.org with SMTP id 3001571; Fri, 13 Jun 2003 13:59:31 -0400 Message-ID: <3EEA1103.CCB83579@mitre.org> Date: Fri, 13 Jun 2003 13:59:31 -0400 From: Kathy Dally Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Larry S. Bartz" CC: capple@dsi-consulting.net, ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds References: <000201c331c2$af386130$3d00000a@D7ST2111> <3EEA09A5.1050603@parnelli.indy.cr.irs.gov> Content-Type: text/plain; charset=us-ascii 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 Hi All! Saying all object identifier descriptors is ok. The 48 limit is ok. However, I think we do need to recognize both the sending and receiving cases. How's this: "To promote interoperability, server implementations SHOULD support receiving object identifier descriptors (such as. attributetype names, objectclass names, matching rule names, and the like), which are at least 48 characters in length and MUST send object identifier descriptors that are no longer than 48 characters. Schema designers SHOULD use object identifier descriptors that are no longer than 48 characters." Thanks, Kathy "Larry S. Bartz" wrote: > > Chris Apple wrote, On 06/13/03 10:44: > > I was thinking more along the lines of a minimum bound in one of the > > LDAPv3 Draft Standard documents. > > > > How about this for a requirement? > > > > "Implementations MUST support attribute names that are at least 32 > > characters in length." > > How about 48? If IANA's ub is 48, then implementations could reasonably > expect to see names of that length. All products and implementations > should be prepared to support that. > > Further, the requirement should not be limited to attributetype names. > The spec in RFC 3383 covers all object identifier descriptors, which > includes attributetype names, objectclass names, matching rule names, > etc. > > How about this? > > > > Larry > > > > > It seems like a simple one without a lot of baggage to me. But if anyone > > thinks there's a good reason not to include it, I'd like to know what > > that is. > > > > I have no strong opinions on an upper bound. > > > > I do realize that there is a work-around for this problem in most cases. > > You can create a shorter attribute name and then use the intended attribute > > name as an alias. But this gets to be a bit complicated when rolling out > > services that use schema designed with longer attribute names. > > > > You have to perform testing to see what each implementation in question > > supports and then create aliases matching up with the shortest supported > > attribute name length. > > > > As a service implementer, that's an awfully expensive interoperability > > hoop to have to jump through if I'm using a technology that is soon to > > be based on a Draft Standard. > > > > I realize that someone might also want a larger attribute name length > > but there seems to already be some restriction with respect to what may be > > allowable from an IANA registration perspective. I'm not questioning that > > because 48 characters for an upper bound seems reasonable to me. > > > > Chris Apple - Principal Architect > > > > DSI Consulting, Inc. > > > > mailto:capple@dsi-consulting.net > > > > http://www.dsi-consulting.com > > > > -----Original Message----- > > From: owner-ietf-ldapbis@OpenLDAP.org > > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz > > Sent: Friday, June 13, 2003 10:48 AM > > To: ietf-ldapbis@OpenLDAP.org > > Subject: Re: Attribute Name Length Bounds > > > > > > Mark C Smith wrote, On 06/13/03 08:26: > > > >>Jim Sermersheim wrote: > >> > >> > >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of > >>>attribute names. Any limitiation in a specific implementation is imposed > >>>by that implementation, not by the spec, so I'm not sure we can do > >>>anything about it here. > >>> > >>>Obviously no server allows an unlimited length, as they are all > >>>limiited if by nothing more than available memory. I'm not sure if this > >>>fits into an implementation report. It seems more appropriate for a > >>>certification/branding program. Other than that, it seems like a valid > >>>defect to raise with those implementors who restrict to unreasonable > >>>limits. > >> > >> > >>I agree. I tried to come up with text that we could add to [Models] or > >>[Protocols] that would encourage implementors to not impose arbitrary, > >>short limits... but I am not sure how to word such a requirement so it > >>is meaningful. This is an interesting interoperability problem though. > >> > >>-Mark > > > > > > > > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 > > "IANA Considerations for LDAP" would be helpful. It says, > > > > "While the protocol places no maximum length restriction upon > > descriptors, they should be short. Descriptors longer than 48 > > characters may be viewed as too long to register." > > > > There was obviously consensus in this WG regarding that length and > > that language. > > From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 14:25:47 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 OAA16818 for ; Fri, 13 Jun 2003 14:25:46 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DIOVEl000535; Fri, 13 Jun 2003 18:24:36 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 h5DIJ0eb000411; Fri, 13 Jun 2003 18:19:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 18:19:00 +0000 Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DIIwEh000393 for ; Fri, 13 Jun 2003 18:18:58 GMT (envelope-from rvh@qsun.mt.att.com) Received: from qsun.mt.att.com ([135.16.157.16]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5DIITml032240; Fri, 13 Jun 2003 13:18:29 -0500 Received: by qsun.mt.att.com (8.8.8p2+Sun/ATTEMS-1.4.1 sol2) id OAA14961; Fri, 13 Jun 2003 14:18:23 -0400 (EDT) Date: Fri, 13 Jun 2003 14:18:23 -0400 (EDT) Message-Id: <200306131818.OAA14961@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: kdally@mitre.org, lbartz@parnelli.indy.cr.irs.gov Subject: Re: Attribute Name Length Bounds Cc: capple@dsi-consulting.net, ietf-ldapbis@OpenLDAP.org 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 have no problem with Kathy's text except that I would replace: ... and MUST send object identifier descriptors that are no longer than 48 characters. with ... and MUST NOT send object identifier descriptors that are longer than 48 characters. This is a wordsmithing comment, not a content comment. Rick Huber : From owner-ietf-ldapbis@openldap.org Fri Jun 13 14:02:29 2003 : Return-Path: : From: Kathy Dally : To: "Larry S. Bartz" : CC: capple@dsi-consulting.net, ietf-ldapbis@openldap.org : Subject: Re: Attribute Name Length Bounds : Sender: owner-ietf-ldapbis@openldap.org : Precedence: bulk : Comment: ietf-ldapbis mailing list : List-Archive: : List-Help: : List-Unsubscribe: : : Hi All! : : Saying all object identifier descriptors is ok. The 48 limit is ok. : However, I think we do need to recognize both the sending and receiving : cases. How's this: : : "To promote interoperability, server implementations SHOULD support : receiving object identifier descriptors (such as. attributetype names, : objectclass names, matching rule names, and the like), which are at : least 48 characters in length and MUST send object identifier : descriptors that are no longer than 48 characters. Schema designers : SHOULD use object identifier descriptors that are no longer than 48 : characters." : : Thanks, : Kathy : : : "Larry S. Bartz" wrote: : > : > Chris Apple wrote, On 06/13/03 10:44: : > > I was thinking more along the lines of a minimum bound in one of the : > > LDAPv3 Draft Standard documents. : > > : > > How about this for a requirement? : > > : > > "Implementations MUST support attribute names that are at least 32 : > > characters in length." : > : > How about 48? If IANA's ub is 48, then implementations could reasonably : > expect to see names of that length. All products and implementations : > should be prepared to support that. : > : > Further, the requirement should not be limited to attributetype names. : > The spec in RFC 3383 covers all object identifier descriptors, which : > includes attributetype names, objectclass names, matching rule names, : > etc. : > : > How about this? : > : > : : > : > Larry : > : > > : > > It seems like a simple one without a lot of baggage to me. But if anyone : > > thinks there's a good reason not to include it, I'd like to know what : > > that is. : > > : > > I have no strong opinions on an upper bound. : > > : > > I do realize that there is a work-around for this problem in most cases. : > > You can create a shorter attribute name and then use the intended attribute : > > name as an alias. But this gets to be a bit complicated when rolling out : > > services that use schema designed with longer attribute names. : > > : > > You have to perform testing to see what each implementation in question : > > supports and then create aliases matching up with the shortest supported : > > attribute name length. : > > : > > As a service implementer, that's an awfully expensive interoperability : > > hoop to have to jump through if I'm using a technology that is soon to : > > be based on a Draft Standard. : > > : > > I realize that someone might also want a larger attribute name length : > > but there seems to already be some restriction with respect to what may be : > > allowable from an IANA registration perspective. I'm not questioning that : > > because 48 characters for an upper bound seems reasonable to me. : > > : > > Chris Apple - Principal Architect : > > : > > DSI Consulting, Inc. : > > : > > mailto:capple@dsi-consulting.net : > > : > > http://www.dsi-consulting.com : > > : > > -----Original Message----- : > > From: owner-ietf-ldapbis@OpenLDAP.org : > > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz : > > Sent: Friday, June 13, 2003 10:48 AM : > > To: ietf-ldapbis@OpenLDAP.org : > > Subject: Re: Attribute Name Length Bounds : > > : > > : > > Mark C Smith wrote, On 06/13/03 08:26: : > > : > >>Jim Sermersheim wrote: : > >> : > >> : > >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of : > >>>attribute names. Any limitiation in a specific implementation is imposed : > >>>by that implementation, not by the spec, so I'm not sure we can do : > >>>anything about it here. : > >>> : > >>>Obviously no server allows an unlimited length, as they are all : > >>>limiited if by nothing more than available memory. I'm not sure if this : > >>>fits into an implementation report. It seems more appropriate for a : > >>>certification/branding program. Other than that, it seems like a valid : > >>>defect to raise with those implementors who restrict to unreasonable : > >>>limits. : > >> : > >> : > >>I agree. I tried to come up with text that we could add to [Models] or : > >>[Protocols] that would encourage implementors to not impose arbitrary, : > >>short limits... but I am not sure how to word such a requirement so it : > >>is meaningful. This is an interesting interoperability problem though. : > >> : > >>-Mark : > > : > > : > > : > > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 : > > "IANA Considerations for LDAP" would be helpful. It says, : > > : > > "While the protocol places no maximum length restriction upon : > > descriptors, they should be short. Descriptors longer than 48 : > > characters may be viewed as too long to register." : > > : > > There was obviously consensus in this WG regarding that length and : > > that language. : > > : : From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 14:31:41 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 OAA17106 for ; Fri, 13 Jun 2003 14:31:40 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DIUVEl000803; Fri, 13 Jun 2003 18:30:33 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 h5DIS8TH000719; Fri, 13 Jun 2003 18:28:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 18:28:08 +0000 Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DIS6Eh000709 for ; Fri, 13 Jun 2003 18:28:07 GMT (envelope-from kdally@mitre.org) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.12.9/8.12.8) with ESMTP id h5DIS4n5027371; Fri, 13 Jun 2003 14:28:04 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.12.9/8.12.8) with ESMTP id h5DIS2OH018239; Fri, 13 Jun 2003 14:28:02 -0400 (EDT) Received: from mm109527-2k.mitre.org (128.29.3.80) by mailhub1.mitre.org with SMTP id 3002213; Fri, 13 Jun 2003 14:27:55 -0400 Message-ID: <3EEA17AB.2859C618@mitre.org> Date: Fri, 13 Jun 2003 14:27:55 -0400 From: Kathy Dally Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard V Huber CC: lbartz@parnelli.indy.cr.irs.gov, capple@dsi-consulting.net, ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds References: <200306131818.OAA14961@qsun.mt.att.com> Content-Type: text/plain; charset=us-ascii 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 Hi All! OK with me. Kathy Richard V Huber wrote: > > I have no problem with Kathy's text except that I would replace: > > ... and MUST send object identifier descriptors that are no longer > than 48 characters. > > with > > ... and MUST NOT send object identifier descriptors that are longer > than 48 characters. > > This is a wordsmithing comment, not a content comment. > > Rick Huber > > : From owner-ietf-ldapbis@openldap.org Fri Jun 13 14:02:29 2003 > : Return-Path: > : From: Kathy Dally > : To: "Larry S. Bartz" > : CC: capple@dsi-consulting.net, ietf-ldapbis@openldap.org > : Subject: Re: Attribute Name Length Bounds > : Sender: owner-ietf-ldapbis@openldap.org > : Precedence: bulk > : Comment: ietf-ldapbis mailing list > : List-Archive: > : List-Help: > : List-Unsubscribe: > : > : Hi All! > : > : Saying all object identifier descriptors is ok. The 48 limit is ok. > : However, I think we do need to recognize both the sending and receiving > : cases. How's this: > : > : "To promote interoperability, server implementations SHOULD support > : receiving object identifier descriptors (such as. attributetype names, > : objectclass names, matching rule names, and the like), which are at > : least 48 characters in length and MUST send object identifier > : descriptors that are no longer than 48 characters. Schema designers > : SHOULD use object identifier descriptors that are no longer than 48 > : characters." > : > : Thanks, > : Kathy > : > : > : "Larry S. Bartz" wrote: > : > > : > Chris Apple wrote, On 06/13/03 10:44: > : > > I was thinking more along the lines of a minimum bound in one of the > : > > LDAPv3 Draft Standard documents. > : > > > : > > How about this for a requirement? > : > > > : > > "Implementations MUST support attribute names that are at least 32 > : > > characters in length." > : > > : > How about 48? If IANA's ub is 48, then implementations could reasonably > : > expect to see names of that length. All products and implementations > : > should be prepared to support that. > : > > : > Further, the requirement should not be limited to attributetype names. > : > The spec in RFC 3383 covers all object identifier descriptors, which > : > includes attributetype names, objectclass names, matching rule names, > : > etc. > : > > : > How about this? > : > > : > > : > : > > : > Larry > : > > : > > > : > > It seems like a simple one without a lot of baggage to me. But if anyone > : > > thinks there's a good reason not to include it, I'd like to know what > : > > that is. > : > > > : > > I have no strong opinions on an upper bound. > : > > > : > > I do realize that there is a work-around for this problem in most cases. > : > > You can create a shorter attribute name and then use the intended attribute > : > > name as an alias. But this gets to be a bit complicated when rolling out > : > > services that use schema designed with longer attribute names. > : > > > : > > You have to perform testing to see what each implementation in question > : > > supports and then create aliases matching up with the shortest supported > : > > attribute name length. > : > > > : > > As a service implementer, that's an awfully expensive interoperability > : > > hoop to have to jump through if I'm using a technology that is soon to > : > > be based on a Draft Standard. > : > > > : > > I realize that someone might also want a larger attribute name length > : > > but there seems to already be some restriction with respect to what may be > : > > allowable from an IANA registration perspective. I'm not questioning that > : > > because 48 characters for an upper bound seems reasonable to me. > : > > > : > > Chris Apple - Principal Architect > : > > > : > > DSI Consulting, Inc. > : > > > : > > mailto:capple@dsi-consulting.net > : > > > : > > http://www.dsi-consulting.com > : > > > : > > -----Original Message----- > : > > From: owner-ietf-ldapbis@OpenLDAP.org > : > > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz > : > > Sent: Friday, June 13, 2003 10:48 AM > : > > To: ietf-ldapbis@OpenLDAP.org > : > > Subject: Re: Attribute Name Length Bounds > : > > > : > > > : > > Mark C Smith wrote, On 06/13/03 08:26: > : > > > : > >>Jim Sermersheim wrote: > : > >> > : > >> > : > >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of > : > >>>attribute names. Any limitiation in a specific implementation is imposed > : > >>>by that implementation, not by the spec, so I'm not sure we can do > : > >>>anything about it here. > : > >>> > : > >>>Obviously no server allows an unlimited length, as they are all > : > >>>limiited if by nothing more than available memory. I'm not sure if this > : > >>>fits into an implementation report. It seems more appropriate for a > : > >>>certification/branding program. Other than that, it seems like a valid > : > >>>defect to raise with those implementors who restrict to unreasonable > : > >>>limits. > : > >> > : > >> > : > >>I agree. I tried to come up with text that we could add to [Models] or > : > >>[Protocols] that would encourage implementors to not impose arbitrary, > : > >>short limits... but I am not sure how to word such a requirement so it > : > >>is meaningful. This is an interesting interoperability problem though. > : > >> > : > >>-Mark > : > > > : > > > : > > > : > > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 > : > > "IANA Considerations for LDAP" would be helpful. It says, > : > > > : > > "While the protocol places no maximum length restriction upon > : > > descriptors, they should be short. Descriptors longer than 48 > : > > characters may be viewed as too long to register." > : > > > : > > There was obviously consensus in this WG regarding that length and > : > > that language. > : > > > : > : From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 14:55:53 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 OAA18571 for ; Fri, 13 Jun 2003 14:55:51 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DIsVEl001683; Fri, 13 Jun 2003 18:54:38 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 h5DInfnt001490; Fri, 13 Jun 2003 18:49:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 18:49:41 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DInbEh001480 for ; Fri, 13 Jun 2003 18:49:37 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Fri, 13 Jun 2003 12:48:59 -0600 Reply-To: From: "Chris Apple" To: "'Kathy Dally'" , "'Larry S. Bartz'" Cc: Subject: RE: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 14:48:47 -0400 Organization: DSI-Consulting, Inc. Message-ID: <001c01c331dc$70164660$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3EEA1103.CCB83579@mitre.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5DIndEh001481 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 If you don't support receiving them at least that long, sweeping the SHOULD under the carpet, as is every implementer's prerogative, would make the weight of the sending MUST irrelevant from an interoperability perspective. You could still have implementations sending out attribute names that are 48 characters in length to an implementation that doesn't choose to support the minimum length specified in the receiving case. Why you would do this as an implementer, I don't know. But it is possible given the wording you propose for an implementer to claim conformance, but still have the same interoperability issue arise if the receiving case is covered by a SHOULD requirement. Reversing the sense doesn't help matters much, but also doesn't make it much worse than the original proposal to specify a case for general support and stating that it is a MUST and a lower bound, regardless of sending/receiving. So I guess it comes down to whichever wording seems clearer to implementers if the SHOULD/MUST sense is reversed in your proposal. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Kathy Dally Sent: Friday, June 13, 2003 2:00 PM To: Larry S. Bartz Cc: capple@dsi-consulting.net; ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds Hi All! Saying all object identifier descriptors is ok. The 48 limit is ok. However, I think we do need to recognize both the sending and receiving cases. How's this: "To promote interoperability, server implementations SHOULD support receiving object identifier descriptors (such as. attributetype names, objectclass names, matching rule names, and the like), which are at least 48 characters in length and MUST send object identifier descriptors that are no longer than 48 characters. Schema designers SHOULD use object identifier descriptors that are no longer than 48 characters." Thanks, Kathy "Larry S. Bartz" wrote: > > Chris Apple wrote, On 06/13/03 10:44: > > I was thinking more along the lines of a minimum bound in one of the > > LDAPv3 Draft Standard documents. > > > > How about this for a requirement? > > > > "Implementations MUST support attribute names that are at least 32 > > characters in length." > > How about 48? If IANA's ub is 48, then implementations could reasonably > expect to see names of that length. All products and implementations > should be prepared to support that. > > Further, the requirement should not be limited to attributetype names. > The spec in RFC 3383 covers all object identifier descriptors, which > includes attributetype names, objectclass names, matching rule names, > etc. > > How about this? > > > > Larry > > > > > It seems like a simple one without a lot of baggage to me. But if anyone > > thinks there's a good reason not to include it, I'd like to know what > > that is. > > > > I have no strong opinions on an upper bound. > > > > I do realize that there is a work-around for this problem in most cases. > > You can create a shorter attribute name and then use the intended attribute > > name as an alias. But this gets to be a bit complicated when rolling out > > services that use schema designed with longer attribute names. > > > > You have to perform testing to see what each implementation in question > > supports and then create aliases matching up with the shortest supported > > attribute name length. > > > > As a service implementer, that's an awfully expensive interoperability > > hoop to have to jump through if I'm using a technology that is soon to > > be based on a Draft Standard. > > > > I realize that someone might also want a larger attribute name length > > but there seems to already be some restriction with respect to what may be > > allowable from an IANA registration perspective. I'm not questioning that > > because 48 characters for an upper bound seems reasonable to me. > > > > Chris Apple - Principal Architect > > > > DSI Consulting, Inc. > > > > mailto:capple@dsi-consulting.net > > > > http://www.dsi-consulting.com > > > > -----Original Message----- > > From: owner-ietf-ldapbis@OpenLDAP.org > > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz > > Sent: Friday, June 13, 2003 10:48 AM > > To: ietf-ldapbis@OpenLDAP.org > > Subject: Re: Attribute Name Length Bounds > > > > > > Mark C Smith wrote, On 06/13/03 08:26: > > > >>Jim Sermersheim wrote: > >> > >> > >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of > >>>attribute names. Any limitiation in a specific implementation is imposed > >>>by that implementation, not by the spec, so I'm not sure we can do > >>>anything about it here. > >>> > >>>Obviously no server allows an unlimited length, as they are all > >>>limiited if by nothing more than available memory. I'm not sure if this > >>>fits into an implementation report. It seems more appropriate for a > >>>certification/branding program. Other than that, it seems like a valid > >>>defect to raise with those implementors who restrict to unreasonable > >>>limits. > >> > >> > >>I agree. I tried to come up with text that we could add to [Models] or > >>[Protocols] that would encourage implementors to not impose arbitrary, > >>short limits... but I am not sure how to word such a requirement so it > >>is meaningful. This is an interesting interoperability problem though. > >> > >>-Mark > > > > > > > > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 > > "IANA Considerations for LDAP" would be helpful. It says, > > > > "While the protocol places no maximum length restriction upon > > descriptors, they should be short. Descriptors longer than 48 > > characters may be viewed as too long to register." > > > > There was obviously consensus in this WG regarding that length and > > that language. > > From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 15:01: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 PAA18730 for ; Fri, 13 Jun 2003 15:01:33 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DJ0VEl001984; Fri, 13 Jun 2003 19:00: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 h5DIwkf0001846; Fri, 13 Jun 2003 18:58:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 18:58:46 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DIwhEh001835 for ; Fri, 13 Jun 2003 18:58:43 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Fri, 13 Jun 2003 12:58:04 -0600 Reply-To: From: "Chris Apple" To: , "'Kathy Dally'" , "'Larry S. Bartz'" Cc: Subject: RE: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 14:57:51 -0400 Organization: DSI-Consulting, Inc. Message-ID: <001d01c331dd$b4f22f50$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5DIwjEh001837 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 Actually, I'd like to adjust that response a bit. I think both the sending and receiving cases need to be MUST for the requirement to help solve the interoperability problem. Mixing the strengths of the requirements covering each case leaves the door open for the same type of interoperability issue for established use cases (DEN, LDAP mappings of DMTF CIM schema) of LDAPv3 involving attribute names approaching the bound specified. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Chris Apple [mailto:capple@dsi-consulting.net] Sent: Friday, June 13, 2003 2:49 PM To: 'Kathy Dally'; 'Larry S. Bartz' Cc: 'ietf-ldapbis@OpenLDAP.org' Subject: RE: Attribute Name Length Bounds If you don't support receiving them at least that long, sweeping the SHOULD under the carpet, as is every implementer's prerogative, would make the weight of the sending MUST irrelevant from an interoperability perspective. You could still have implementations sending out attribute names that are 48 characters in length to an implementation that doesn't choose to support the minimum length specified in the receiving case. Why you would do this as an implementer, I don't know. But it is possible given the wording you propose for an implementer to claim conformance, but still have the same interoperability issue arise if the receiving case is covered by a SHOULD requirement. Reversing the sense doesn't help matters much, but also doesn't make it much worse than the original proposal to specify a case for general support and stating that it is a MUST and a lower bound, regardless of sending/receiving. So I guess it comes down to whichever wording seems clearer to implementers if the SHOULD/MUST sense is reversed in your proposal. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Kathy Dally Sent: Friday, June 13, 2003 2:00 PM To: Larry S. Bartz Cc: capple@dsi-consulting.net; ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds Hi All! Saying all object identifier descriptors is ok. The 48 limit is ok. However, I think we do need to recognize both the sending and receiving cases. How's this: "To promote interoperability, server implementations SHOULD support receiving object identifier descriptors (such as. attributetype names, objectclass names, matching rule names, and the like), which are at least 48 characters in length and MUST send object identifier descriptors that are no longer than 48 characters. Schema designers SHOULD use object identifier descriptors that are no longer than 48 characters." Thanks, Kathy "Larry S. Bartz" wrote: > > Chris Apple wrote, On 06/13/03 10:44: > > I was thinking more along the lines of a minimum bound in one of the > > LDAPv3 Draft Standard documents. > > > > How about this for a requirement? > > > > "Implementations MUST support attribute names that are at least 32 > > characters in length." > > How about 48? If IANA's ub is 48, then implementations could reasonably > expect to see names of that length. All products and implementations > should be prepared to support that. > > Further, the requirement should not be limited to attributetype names. > The spec in RFC 3383 covers all object identifier descriptors, which > includes attributetype names, objectclass names, matching rule names, > etc. > > How about this? > > > > Larry > > > > > It seems like a simple one without a lot of baggage to me. But if anyone > > thinks there's a good reason not to include it, I'd like to know what > > that is. > > > > I have no strong opinions on an upper bound. > > > > I do realize that there is a work-around for this problem in most cases. > > You can create a shorter attribute name and then use the intended attribute > > name as an alias. But this gets to be a bit complicated when rolling out > > services that use schema designed with longer attribute names. > > > > You have to perform testing to see what each implementation in question > > supports and then create aliases matching up with the shortest supported > > attribute name length. > > > > As a service implementer, that's an awfully expensive interoperability > > hoop to have to jump through if I'm using a technology that is soon to > > be based on a Draft Standard. > > > > I realize that someone might also want a larger attribute name length > > but there seems to already be some restriction with respect to what may be > > allowable from an IANA registration perspective. I'm not questioning that > > because 48 characters for an upper bound seems reasonable to me. > > > > Chris Apple - Principal Architect > > > > DSI Consulting, Inc. > > > > mailto:capple@dsi-consulting.net > > > > http://www.dsi-consulting.com > > > > -----Original Message----- > > From: owner-ietf-ldapbis@OpenLDAP.org > > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz > > Sent: Friday, June 13, 2003 10:48 AM > > To: ietf-ldapbis@OpenLDAP.org > > Subject: Re: Attribute Name Length Bounds > > > > > > Mark C Smith wrote, On 06/13/03 08:26: > > > >>Jim Sermersheim wrote: > >> > >> > >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of > >>>attribute names. Any limitiation in a specific implementation is imposed > >>>by that implementation, not by the spec, so I'm not sure we can do > >>>anything about it here. > >>> > >>>Obviously no server allows an unlimited length, as they are all > >>>limiited if by nothing more than available memory. I'm not sure if this > >>>fits into an implementation report. It seems more appropriate for a > >>>certification/branding program. Other than that, it seems like a valid > >>>defect to raise with those implementors who restrict to unreasonable > >>>limits. > >> > >> > >>I agree. I tried to come up with text that we could add to [Models] or > >>[Protocols] that would encourage implementors to not impose arbitrary, > >>short limits... but I am not sure how to word such a requirement so it > >>is meaningful. This is an interesting interoperability problem though. > >> > >>-Mark > > > > > > > > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 > > "IANA Considerations for LDAP" would be helpful. It says, > > > > "While the protocol places no maximum length restriction upon > > descriptors, they should be short. Descriptors longer than 48 > > characters may be viewed as too long to register." > > > > There was obviously consensus in this WG regarding that length and > > that language. > > From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 15:13:35 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 PAA19992 for ; Fri, 13 Jun 2003 15:13: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 h5DJCVEl002310; Fri, 13 Jun 2003 19:12:36 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 h5DJ6qpp002240; Fri, 13 Jun 2003 19:06:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 19:06:52 +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 h5DJ6pEh002230 for ; Fri, 13 Jun 2003 19:06:51 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 h5DJ6oc6081124 for ; Fri, 13 Jun 2003 19:06:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030613091932.01a6c740@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Jun 2003 12:03:42 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: Attribute Name Length Bounds In-Reply-To: <000b01c3317d$75080a00$5f0aa8c0@D7ST2111> 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 have a few (personal) thoughts on this issue... From a protocol point-of-view, interoperability can be said to be demonstrated if a presented overly-long attribute descriptor is treated as unrecognized type. Likewise for attribute options and other such protocol tokens. Additionally, no harm (to protocol peers, security, the Internet) is done by an implementation which simply treats overly long (by whatever definition) as unrecognized. Hence, I don't think an RFC 2119 imperative is not warranted here. This is not to say that an implementation which imposes significant limits on the length of attribute descriptors, options, and other such things has not limited its applicability. It just to say its not a protocol interoperability issue. Implementations should be free to limit their applicability. There are many issues that a technical specification detailing how to support "open-ended sets of attributes" likely would need to address. I think these issues can be left to a future document. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 17:50: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 RAA24361 for ; Fri, 13 Jun 2003 17:50:38 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DLmWEl007758; Fri, 13 Jun 2003 21:49:20 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 h5DLjHAY007692; Fri, 13 Jun 2003 21:45:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 21:45:17 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DLjDEh007662; Fri, 13 Jun 2003 21:45:14 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Fri, 13 Jun 2003 15:44:38 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" , Subject: RE: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 17:44:27 -0400 Organization: DSI-Consulting, Inc. Message-ID: <002b01c331f4$f9631f70$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030613091932.01a6c740@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Are you saying that you believe that SHOULD (rather than MUST) is the appropriate strength of requirement to use so that implementers can limit their scope of applicability as they see fit? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Kurt D. Zeilenga Sent: Friday, June 13, 2003 3:04 PM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds I have a few (personal) thoughts on this issue... From a protocol point-of-view, interoperability can be said to be demonstrated if a presented overly-long attribute descriptor is treated as unrecognized type. Likewise for attribute options and other such protocol tokens. Additionally, no harm (to protocol peers, security, the Internet) is done by an implementation which simply treats overly long (by whatever definition) as unrecognized. Hence, I don't think an RFC 2119 imperative is not warranted here. This is not to say that an implementation which imposes significant limits on the length of attribute descriptors, options, and other such things has not limited its applicability. It just to say its not a protocol interoperability issue. Implementations should be free to limit their applicability. There are many issues that a technical specification detailing how to support "open-ended sets of attributes" likely would need to address. I think these issues can be left to a future document. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 18:49:40 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 SAA26961 for ; Fri, 13 Jun 2003 18:49:39 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5DMmWEl009340; Fri, 13 Jun 2003 22:48:40 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 h5DMisnv009237; Fri, 13 Jun 2003 22:44:54 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 22:44:54 +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 h5DMirEh009212 for ; Fri, 13 Jun 2003 22:44:54 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Jun 2003 16:44:33 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 13 Jun 2003 16:43:08 -0600 From: "Jim Sermersheim" To: Subject: Re: Attribute Name Length Bounds 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'm still a little fuzzy on the scope of this discussion. The ASN.1 for attribute names is an unbounded OCTET STRING. This discussion seems to be saying "even though the protocol says the size is unlimited (well, limited to a ber length), we want to be more explicit and require protocols peers to handle some minimum size". What else does this discussion apply to? - LDAPDN (how long of a DN am I required to handle?) - RelativeLDAPDN - AttributeValue/AssertionValue (I note that the current len descriptor on attributes is a 'suggested minimum') - MatchingRuleId - LDAPResult.diagnosticMessage - LDAPURL (I suppose enough for a minimal scheme and delimiters is implied) - SASL mechanism (implied 1 to 20) - SASL credentials - LDAPOID - control/extendedValue - simple password AFAIK, today these all have a max-ber-len max. and no mandatory minimum is explicitly required to be supported. Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 20:05:23 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 UAA29215 for ; Fri, 13 Jun 2003 20:05:22 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5E00XEl010713; Sat, 14 Jun 2003 00:03: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 h5DNv582010608; Fri, 13 Jun 2003 23:57:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 13 Jun 2003 23:57:05 +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 h5DNv3Eh010597 for ; Fri, 13 Jun 2003 23:57:04 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 h5DNv1c6082818; Fri, 13 Jun 2003 23:57:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030613150456.01a6a800@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Jun 2003 16:53:52 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: Attribute Name Length Bounds Cc: In-Reply-To: <002b01c331f4$f9631f70$3d00000a@D7ST2111> References: <5.2.0.9.0.20030613091932.01a6c740@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 02:44 PM 6/13/2003, Chris Apple wrote: >Are you saying that you believe that SHOULD (rather than MUST) >is the appropriate strength of requirement to use so that >implementers can limit their scope of applicability as they >see fit? No. I am saying that, in my opinion, no RFC 2119 imperative is warranted here. Kurt >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Kurt D. Zeilenga >Sent: Friday, June 13, 2003 3:04 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: Re: Attribute Name Length Bounds > > >I have a few (personal) thoughts on this issue... > >>From a protocol point-of-view, interoperability can be said to >be demonstrated if a presented overly-long attribute descriptor is >treated as unrecognized type. Likewise for attribute options and >other such protocol tokens. Additionally, no harm (to protocol >peers, security, the Internet) is done by an implementation which >simply treats overly long (by whatever definition) as unrecognized. >Hence, I don't think an RFC 2119 imperative is not warranted here. > >This is not to say that an implementation which imposes significant >limits on the length of attribute descriptors, options, and other >such things has not limited its applicability. It just to say its >not a protocol interoperability issue. Implementations should be >free to limit their applicability. > >There are many issues that a technical specification detailing >how to support "open-ended sets of attributes" likely would >need to address. I think these issues can be left to a future >document. > >Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 21:08:59 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 VAA00596 for ; Fri, 13 Jun 2003 21:08:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5E16XEl012127; Sat, 14 Jun 2003 01:07:30 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 h5E12HOS012059; Sat, 14 Jun 2003 01:02:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 14 Jun 2003 01:02:17 +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 h5E12FEh012049 for ; Sat, 14 Jun 2003 01:02:15 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 h5E11wc6083101; Sat, 14 Jun 2003 01:01:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030613170912.01bdbe80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Jun 2003 17:58:49 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Attribute Name Length Bounds 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: I've added some more questions below to your list. Basically, the answer to all of these questions is "it depends". In particular, it depends on the circumstances of the use of the protocol. As LDAP is intended to have a general domain of applicability, it's best to leave such answers to applicability statements covering particular circumstances. That is, we should leave the answering of these questions to future applicability statements of restricted domain of applicability (such as use in PKI, use in white pages, use in ...., use for a "general purpose"). Kurt At 03:43 PM 6/13/2003, Jim Sermersheim wrote: >I'm still a little fuzzy on the scope of this discussion. > >The ASN.1 for attribute names is an unbounded OCTET STRING. > >This discussion seems to be saying "even though the protocol says the >size is unlimited (well, limited to a ber length), we want to be more >explicit and require protocols peers to handle some minimum size". > >What else does this discussion apply to? How many RDNs in a DN must implementations support? How many AVAs in a RDN must implementations support? How many options in an attribute description must implementations support? How many descriptions in an attribute description list must implementations support? How many broad of a filter specification must implementations support? How many deep of a filter specification must implementations support? How many any substrings in a substrings assertion must implementations support? ... From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 21:37: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 VAA01159 for ; Fri, 13 Jun 2003 21:37: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 h5E1aXEl012863; Sat, 14 Jun 2003 01:36:38 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 h5E1Wljs012758; Sat, 14 Jun 2003 01:32:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 14 Jun 2003 01:32:47 +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 h5E1WiEh012718; Sat, 14 Jun 2003 01:32:44 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Jun 2003 19:32:23 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 13 Jun 2003 19:30:58 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: Attribute Name Length Bounds 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 Ah yes... And how many controls in a SEQUENCE OF Control? And how many attribute values in a SET of AttributeValue? And how many LDAPURLs in a Referral or SearchResultReference? And how many modifications in a ModifyRequest? I guess the answer my friend, is blowin' in the wind. >>> "Kurt D. Zeilenga" 6/13/03 6:58:49 PM >>> I've added some more questions below to your list. Basically, the answer to all of these questions is "it depends". In particular, it depends on the circumstances of the use of the protocol. As LDAP is intended to have a general domain of applicability, it's best to leave such answers to applicability statements covering particular circumstances. That is, we should leave the answering of these questions to future applicability statements of restricted domain of applicability (such as use in PKI, use in white pages, use in ...., use for a "general purpose"). Kurt At 03:43 PM 6/13/2003, Jim Sermersheim wrote: >I'm still a little fuzzy on the scope of this discussion. > >The ASN.1 for attribute names is an unbounded OCTET STRING. > >This discussion seems to be saying "even though the protocol says the >size is unlimited (well, limited to a ber length), we want to be more >explicit and require protocols peers to handle some minimum size". > >What else does this discussion apply to? How many RDNs in a DN must implementations support? How many AVAs in a RDN must implementations support? How many options in an attribute description must implementations support? How many descriptions in an attribute description list must implementations support? How many broad of a filter specification must implementations support? How many deep of a filter specification must implementations support? How many any substrings in a substrings assertion must implementations support? .. From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 13 23:21:16 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 XAA03994 for ; Fri, 13 Jun 2003 23:21:16 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5E3IYEl014923; Sat, 14 Jun 2003 03:20:16 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 h5E3HVcD014888; Sat, 14 Jun 2003 03:17:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 14 Jun 2003 03:17:31 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5E3HSEh014878 for ; Sat, 14 Jun 2003 03:17:29 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 ([199.72.166.218]) by echt.caledonia.net; Fri, 13 Jun 2003 21:16:59 -0600 Reply-To: From: "Chris Apple" To: "'Jim Sermersheim'" , Subject: RE: Attribute Name Length Bounds Date: Fri, 13 Jun 2003 23:16:48 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000801c33223$68097400$5f0aa8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal 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 My intended scope was names for schema elements such as attribute types, object class identifiers, attribute syntaxes, matching rules, and anything else that might be mapped to an OID with an associated, registered name. Given that there are IANA considerations for the registration of at least some of those types of schema elements, I don't think I'm proposing anything that is outrageous or unreasonable. I absolutely agree that most of the examples you gave should be handled in the context of profiling LDAPv3 DIT structure, Operations, Service Model, etc., for specific applications. I'm of the opinion that this particular minimum size requirement is of more general use than a specific application profile. I've already given two different examples where this is an issue. I'll repeat them here along with a third: - DEN - LDAPv3 mappings of the DMTF CIM - The Open Group's Mobility and Directory (MaD) Schema (this will be publicly presented at the Burton Group's Catalyst meeting in July 2003 - but basically its an information model for directory-enabled mobility management) Those are all different application contexts. Each has a need for attribute type names that are longer than the maximum attribute length supported by some LDAPv3-compliant implementations. Thus it is generally valuable to have a minimum length requirement for at least attribute type names and object class identifiers. By extension it also seems generally valuable to have the same sort of minimum supported length for names of matching rules and attribute syntaxes. I wouldn't take it further than that because I don't have real world examples that justify doing so. However, to accommodate the 3 schema specifications above in a general way, I do believe its justified. Specifying such a minimum schema element name length requirement would solve an interoperability problem related to using the protocol in the real world in at least three different and very significant application contexts. I think that's very much in line with the intent of progressing to Draft Standard. If we were to waive our hands about this and say, it means that we are interoperable if we just say we don't understand something that's been sent to us, we haven't actually helped the users with a relatively costly interoperability problem. I don't think hand waving makes for good standards when there's a need such as this that crosses multiple application contexts. Especially when such a requirement can scoped so that it doesn't cause the kind of "here a limit, there a limit, everywhere a limit" rat hole that some of the most recent postings implied might happen. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Friday, June 13, 2003 6:43 PM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds I'm still a little fuzzy on the scope of this discussion. The ASN.1 for attribute names is an unbounded OCTET STRING. This discussion seems to be saying "even though the protocol says the size is unlimited (well, limited to a ber length), we want to be more explicit and require protocols peers to handle some minimum size". What else does this discussion apply to? - LDAPDN (how long of a DN am I required to handle?) - RelativeLDAPDN - AttributeValue/AssertionValue (I note that the current len descriptor on attributes is a 'suggested minimum') - MatchingRuleId - LDAPResult.diagnosticMessage - LDAPURL (I suppose enough for a minimal scheme and delimiters is implied) - SASL mechanism (implied 1 to 20) - SASL credentials - LDAPOID - control/extendedValue - simple password AFAIK, today these all have a max-ber-len max. and no mandatory minimum is explicitly required to be supported. Jim From owner-ietf-ldapbis@OpenLDAP.org Sat Jun 14 14:21:14 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 OAA00806 for ; Sat, 14 Jun 2003 14:21:10 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5EIIdEl034010; Sat, 14 Jun 2003 18:19: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 h5EIHs86033969; Sat, 14 Jun 2003 18:17:54 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 14 Jun 2003 18:17:54 +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 h5EIHrEh033958 for ; Sat, 14 Jun 2003 18:17:53 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Sat, 14 Jun 2003 12:17:32 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Sat, 14 Jun 2003 12:16:12 -0600 From: "Jim Sermersheim" To: Subject: RE: Attribute Name Length Bounds 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 wouldn't take it further than that because I don't have real world >examples that justify doing so. This is exactly my concern. It seems coincidental that you are seeing this problem, we are edititng the specification, so you see a chance to fix this problem. If you hadn't seen this problem at this particular time, and the spec got progressed without this change, then I suspect the problem would be addressed in some other way (one of those talked about earlier in the thread). Given this concern, I decided to have a look at some of the other potential 'problems' that are the same as this one. If, instead of this problem, you found that some servers limited DNs to 32 characters, we might be having that conversation instead of this one. I don't see the difference between schema lenghts and some of the other sequences listed in this thread. If you want to draw the line at those things which have IANA considerations, then we throw out sizes on other schema elements, and add in sizes on other things (like SASL mechanism). What's happenning here is a jump over to the IANA reasoning, then a hop over to a "similar elements" reasoning. To paraphase, my concern is that we're jumping on a problem just because someone happened to experience it, without looking at it in a general way. If we add this change, it sets a precedence for a class of instructions that was never part of the original spec. We shouldn't do this in such an isolated way. That only makes future readers scratch their heads wondering at the inconsistency. I don't understand why this can't be specified in an application profile document. I would say that there's a class of application that must add to (extend) the standard LDAP schema. For LDAP servers to service this class of applications, then they should handle reasonable schema name lengths. I don't think the LDAP spec even says that an LDAP server needs to allow its schema to be extended, only that it must support certain standard schema. Jim >>> "Chris Apple" 6/13/03 9:16:48 PM >>> My intended scope was names for schema elements such as attribute types, object class identifiers, attribute syntaxes, matching rules, and anything else that might be mapped to an OID with an associated, registered name. Given that there are IANA considerations for the registration of at least some of those types of schema elements, I don't think I'm proposing anything that is outrageous or unreasonable. I absolutely agree that most of the examples you gave should be handled in the context of profiling LDAPv3 DIT structure, Operations, Service Model, etc., for specific applications. I'm of the opinion that this particular minimum size requirement is of more general use than a specific application profile. I've already given two different examples where this is an issue. I'll repeat them here along with a third: - DEN - LDAPv3 mappings of the DMTF CIM - The Open Group's Mobility and Directory (MaD) Schema (this will be publicly presented at the Burton Group's Catalyst meeting in July 2003 - but basically its an information model for directory-enabled mobility management) Those are all different application contexts. Each has a need for attribute type names that are longer than the maximum attribute length supported by some LDAPv3-compliant implementations. Thus it is generally valuable to have a minimum length requirement for at least attribute type names and object class identifiers. By extension it also seems generally valuable to have the same sort of minimum supported length for names of matching rules and attribute syntaxes. I wouldn't take it further than that because I don't have real world examples that justify doing so. However, to accommodate the 3 schema specifications above in a general way, I do believe its justified. Specifying such a minimum schema element name length requirement would solve an interoperability problem related to using the protocol in the real world in at least three different and very significant application contexts. I think that's very much in line with the intent of progressing to Draft Standard. If we were to waive our hands about this and say, it means that we are interoperable if we just say we don't understand something that's been sent to us, we haven't actually helped the users with a relatively costly interoperability problem. I don't think hand waving makes for good standards when there's a need such as this that crosses multiple application contexts. Especially when such a requirement can scoped so that it doesn't cause the kind of "here a limit, there a limit, everywhere a limit" rat hole that some of the most recent postings implied might happen. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Friday, June 13, 2003 6:43 PM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds I'm still a little fuzzy on the scope of this discussion. The ASN.1 for attribute names is an unbounded OCTET STRING. This discussion seems to be saying "even though the protocol says the size is unlimited (well, limited to a ber length), we want to be more explicit and require protocols peers to handle some minimum size". What else does this discussion apply to? - LDAPDN (how long of a DN am I required to handle?) - RelativeLDAPDN - AttributeValue/AssertionValue (I note that the current len descriptor on attributes is a 'suggested minimum') - MatchingRuleId - LDAPResult.diagnosticMessage - LDAPURL (I suppose enough for a minimal scheme and delimiters is implied) - SASL mechanism (implied 1 to 20) - SASL credentials - LDAPOID - control/extendedValue - simple password AFAIK, today these all have a max-ber-len max. and no mandatory minimum is explicitly required to be supported. Jim From owner-ietf-ldapbis@OpenLDAP.org Sat Jun 14 18:08:48 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 SAA05974 for ; Sat, 14 Jun 2003 18:08:47 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5EM6fEl037979; Sat, 14 Jun 2003 22:07: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 h5EM1DSu037796; Sat, 14 Jun 2003 22:01:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 14 Jun 2003 22:01:13 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5EM19Eh037786 for ; Sat, 14 Jun 2003 22:01:11 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-208-252.pskn.east.verizon.net [151.204.208.252]) by echt.caledonia.net; Sat, 14 Jun 2003 16:00:44 -0600 Reply-To: From: "Chris Apple" To: "'Jim Sermersheim'" , Subject: RE: Attribute Name Length Bounds Date: Sat, 14 Jun 2003 18:00:29 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000301c332c0$623b7800$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would be fine with it if the scope was attribute type names and object class names. What is beginning to concern me is that your words imply that it is inappropriate to address known interoperability issues in preparation for moving to Draft Standard. It's true that it has become a known problem because of recent work I've done. The timing doesn't diminish the importance of discussing it in this forum; nor does it diminish the negative impact it will have on deploying services using the protocol in the field if there isn't some requirement addressing this particular known issue. I'm sure it's a good idea to look at the problem in a general way. I'm also sure that most users would appreciate tempering pure technical merit with pragmatic deployment concerns along the way. The idea of addressing this particular issue with a requirement seems to have some supporters and some folks who don't think its a good idea. But there hasn't been a lot of discussion about which LDAPBIS deliverable this might apply to. Notice that I actually stated that I didn't know where to even suggest its inclusion at the start of this thread. Nor do I at this time. That is perhaps a question that needs to be asked and answered explicitly. So consider it asked. Where do folks think such a requirement belongs? In one of the LDAPBIS deliverables? Or somewhere else (and where if that's the case)? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Saturday, June 14, 2003 2:16 PM To: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds >I wouldn't take it further than that because I don't have real world >examples that justify doing so. This is exactly my concern. It seems coincidental that you are seeing this problem, we are edititng the specification, so you see a chance to fix this problem. If you hadn't seen this problem at this particular time, and the spec got progressed without this change, then I suspect the problem would be addressed in some other way (one of those talked about earlier in the thread). Given this concern, I decided to have a look at some of the other potential 'problems' that are the same as this one. If, instead of this problem, you found that some servers limited DNs to 32 characters, we might be having that conversation instead of this one. I don't see the difference between schema lenghts and some of the other sequences listed in this thread. If you want to draw the line at those things which have IANA considerations, then we throw out sizes on other schema elements, and add in sizes on other things (like SASL mechanism). What's happenning here is a jump over to the IANA reasoning, then a hop over to a "similar elements" reasoning. To paraphase, my concern is that we're jumping on a problem just because someone happened to experience it, without looking at it in a general way. If we add this change, it sets a precedence for a class of instructions that was never part of the original spec. We shouldn't do this in such an isolated way. That only makes future readers scratch their heads wondering at the inconsistency. I don't understand why this can't be specified in an application profile document. I would say that there's a class of application that must add to (extend) the standard LDAP schema. For LDAP servers to service this class of applications, then they should handle reasonable schema name lengths. I don't think the LDAP spec even says that an LDAP server needs to allow its schema to be extended, only that it must support certain standard schema. Jim >>> "Chris Apple" 6/13/03 9:16:48 PM >>> My intended scope was names for schema elements such as attribute types, object class identifiers, attribute syntaxes, matching rules, and anything else that might be mapped to an OID with an associated, registered name. Given that there are IANA considerations for the registration of at least some of those types of schema elements, I don't think I'm proposing anything that is outrageous or unreasonable. I absolutely agree that most of the examples you gave should be handled in the context of profiling LDAPv3 DIT structure, Operations, Service Model, etc., for specific applications. I'm of the opinion that this particular minimum size requirement is of more general use than a specific application profile. I've already given two different examples where this is an issue. I'll repeat them here along with a third: - DEN - LDAPv3 mappings of the DMTF CIM - The Open Group's Mobility and Directory (MaD) Schema (this will be publicly presented at the Burton Group's Catalyst meeting in July 2003 - but basically its an information model for directory-enabled mobility management) Those are all different application contexts. Each has a need for attribute type names that are longer than the maximum attribute length supported by some LDAPv3-compliant implementations. Thus it is generally valuable to have a minimum length requirement for at least attribute type names and object class identifiers. By extension it also seems generally valuable to have the same sort of minimum supported length for names of matching rules and attribute syntaxes. I wouldn't take it further than that because I don't have real world examples that justify doing so. However, to accommodate the 3 schema specifications above in a general way, I do believe its justified. Specifying such a minimum schema element name length requirement would solve an interoperability problem related to using the protocol in the real world in at least three different and very significant application contexts. I think that's very much in line with the intent of progressing to Draft Standard. If we were to waive our hands about this and say, it means that we are interoperable if we just say we don't understand something that's been sent to us, we haven't actually helped the users with a relatively costly interoperability problem. I don't think hand waving makes for good standards when there's a need such as this that crosses multiple application contexts. Especially when such a requirement can scoped so that it doesn't cause the kind of "here a limit, there a limit, everywhere a limit" rat hole that some of the most recent postings implied might happen. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Friday, June 13, 2003 6:43 PM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds I'm still a little fuzzy on the scope of this discussion. The ASN.1 for attribute names is an unbounded OCTET STRING. This discussion seems to be saying "even though the protocol says the size is unlimited (well, limited to a ber length), we want to be more explicit and require protocols peers to handle some minimum size". What else does this discussion apply to? - LDAPDN (how long of a DN am I required to handle?) - RelativeLDAPDN - AttributeValue/AssertionValue (I note that the current len descriptor on attributes is a 'suggested minimum') - MatchingRuleId - LDAPResult.diagnosticMessage - LDAPURL (I suppose enough for a minimal scheme and delimiters is implied) - SASL mechanism (implied 1 to 20) - SASL credentials - LDAPOID - control/extendedValue - simple password AFAIK, today these all have a max-ber-len max. and no mandatory minimum is explicitly required to be supported. Jim From owner-ietf-ldapbis@OpenLDAP.org Sat Jun 14 22:33:10 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 WAA09860 for ; Sat, 14 Jun 2003 22:33:09 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5F2UlEl042309; Sun, 15 Jun 2003 02:31:36 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 h5F2SZ7P042223; Sun, 15 Jun 2003 02:28:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 15 Jun 2003 02:28: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 h5F2SWEh042213 for ; Sun, 15 Jun 2003 02:28:32 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 h5F2SQc6093435; Sun, 15 Jun 2003 02:28:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030614184532.01b72630@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 14 Jun 2003 19:25:17 -0700 To: Kathy Dally From: "Kurt D. Zeilenga" Subject: Re: Attribute Name Length Bounds Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3EEA1103.CCB83579@mitre.org> References: <000201c331c2$af386130$3d00000a@D7ST2111> <3EEA09A5.1050603@parnelli.indy.cr.irs.gov> 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: Kathy, your suggested specification change would require many independently developed interoperating implementations to change their "running code". Also, unless the limit is very high, such a limit will invalid existing conformant schema. Today's TS assumes that all implementations can handle all valid PDUs they are passed, including handling all allowed descriptors. An implementation will recognize and support some descriptors it will recognize and support, others it won't. Adding a small size limit won't change that. It will only limit LDAP domain of applicability. (This statement is, I believe, supported by operational experience in over protocol which has placed small limits on protocol fields. For example, the 20 octet SASL mechanism name limit is makes it unnecessarily difficult to support arbitrary GSS API mechanisms.) So, not only is the change not needed, it's going to do significant harm. We should not add size limit restrictions to protocol fields. They are bad. I agree that a LDAP "general purpose" client/server applicability statement, possibly Standard Track, is needed. I agree that extension guidelines, possibly as a BCP, is needed. However, the LDAP "core" technical specification is neither of these and it shouldn't expanded to include either. I note, as co-chair, that LDAPBIS is not chartered to produce either. Kurt At 10:59 AM 6/13/2003, Kathy Dally wrote: >Hi All! > >Saying all object identifier descriptors is ok. The 48 limit is ok. >However, I think we do need to recognize both the sending and receiving >cases. How's this: > > "To promote interoperability, server implementations SHOULD support >receiving object identifier descriptors (such as. attributetype names, >objectclass names, matching rule names, and the like), which are at >least 48 characters in length and MUST send object identifier >descriptors that are no longer than 48 characters. Schema designers >SHOULD use object identifier descriptors that are no longer than 48 >characters." > >Thanks, >Kathy > > >"Larry S. Bartz" wrote: >> >> Chris Apple wrote, On 06/13/03 10:44: >> > I was thinking more along the lines of a minimum bound in one of the >> > LDAPv3 Draft Standard documents. >> > >> > How about this for a requirement? >> > >> > "Implementations MUST support attribute names that are at least 32 >> > characters in length." >> >> How about 48? If IANA's ub is 48, then implementations could reasonably >> expect to see names of that length. All products and implementations >> should be prepared to support that. >> >> Further, the requirement should not be limited to attributetype names. >> The spec in RFC 3383 covers all object identifier descriptors, which >> includes attributetype names, objectclass names, matching rule names, >> etc. >> >> How about this? >> >> > >> >> Larry >> >> > >> > It seems like a simple one without a lot of baggage to me. But if anyone >> > thinks there's a good reason not to include it, I'd like to know what >> > that is. >> > >> > I have no strong opinions on an upper bound. >> > >> > I do realize that there is a work-around for this problem in most cases. >> > You can create a shorter attribute name and then use the intended attribute >> > name as an alias. But this gets to be a bit complicated when rolling out >> > services that use schema designed with longer attribute names. >> > >> > You have to perform testing to see what each implementation in question >> > supports and then create aliases matching up with the shortest supported >> > attribute name length. >> > >> > As a service implementer, that's an awfully expensive interoperability >> > hoop to have to jump through if I'm using a technology that is soon to >> > be based on a Draft Standard. >> > >> > I realize that someone might also want a larger attribute name length >> > but there seems to already be some restriction with respect to what may be >> > allowable from an IANA registration perspective. I'm not questioning that >> > because 48 characters for an upper bound seems reasonable to me. >> > >> > Chris Apple - Principal Architect >> > >> > DSI Consulting, Inc. >> > >> > mailto:capple@dsi-consulting.net >> > >> > http://www.dsi-consulting.com >> > >> > -----Original Message----- >> > From: owner-ietf-ldapbis@OpenLDAP.org >> > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz >> > Sent: Friday, June 13, 2003 10:48 AM >> > To: ietf-ldapbis@OpenLDAP.org >> > Subject: Re: Attribute Name Length Bounds >> > >> > >> > Mark C Smith wrote, On 06/13/03 08:26: >> > >> >>Jim Sermersheim wrote: >> >> >> >> >> >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of >> >>>attribute names. Any limitiation in a specific implementation is imposed >> >>>by that implementation, not by the spec, so I'm not sure we can do >> >>>anything about it here. >> >>> >> >>>Obviously no server allows an unlimited length, as they are all >> >>>limiited if by nothing more than available memory. I'm not sure if this >> >>>fits into an implementation report. It seems more appropriate for a >> >>>certification/branding program. Other than that, it seems like a valid >> >>>defect to raise with those implementors who restrict to unreasonable >> >>>limits. >> >> >> >> >> >>I agree. I tried to come up with text that we could add to [Models] or >> >>[Protocols] that would encourage implementors to not impose arbitrary, >> >>short limits... but I am not sure how to word such a requirement so it >> >>is meaningful. This is an interesting interoperability problem though. >> >> >> >>-Mark >> > >> > >> > >> > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 >> > "IANA Considerations for LDAP" would be helpful. It says, >> > >> > "While the protocol places no maximum length restriction upon >> > descriptors, they should be short. Descriptors longer than 48 >> > characters may be viewed as too long to register." >> > >> > There was obviously consensus in this WG regarding that length and >> > that language. >> > From owner-ietf-ldapbis@OpenLDAP.org Sun Jun 15 00:00:25 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 AAA10722 for ; Sun, 15 Jun 2003 00:00:25 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5F3sgEp044036; Sun, 15 Jun 2003 03:58: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 h5F3o6Ti043974; Sun, 15 Jun 2003 03:50:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 15 Jun 2003 03:50:06 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5F3o0Eh043941; Sun, 15 Jun 2003 03:50:00 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-208-252.pskn.east.verizon.net [151.204.208.252]) by echt.caledonia.net; Sat, 14 Jun 2003 21:49:30 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" , "'Kathy Dally'" Cc: Subject: RE: Attribute Name Length Bounds Date: Sat, 14 Jun 2003 23:49:15 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000501c332f1$1a083b00$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030614184532.01b72630@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5F3o1Eh043945 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 have re-read Kathy's suggestion several times. I now agree that as worded, it would cause more harm than good because it places an upper bound on attribute lengths. I was only concerned with a lower bound to ensure some publicly known requirement. This would enable users to have some reasonable degree of assurance that two products claiming conformance with that requirement should interoperate with respect to this issue. I do not see that similar (or any) harm to the use of LDAPv3 would be caused by a lower bound on attribute type names or object classes. So I will point back to the suggestion from Rick Huber as the requirement wording that seems appropriate to me on this topic. I maintain my view that this particular issue is of sufficiently general nature to justify consideration of adding a requirement to one or more standards track documents. Some of those could be from this group. That question I asked in a separate posting to the WG. I do think there needs to be a bit more discussion about where such a requirement belongs. It would be nice (and helpful for Kurt) if folks would say what they think about where such a requirement belongs and why. That way, if consensus turns out to be that such a requirement should be included in one or more of the LDAPBIS deliverables, we could work on the actual language in the WG. I think it is unwise to make a blanket statement that you shouldn't make size limit restrictions to protocol fields because "they are bad." That's a generalization that you can't back up with a convincing, general technical argument. I'm sure there are cases where size limits are bad. I'm equally certain that there are cases where not having them causes harm. My assertion is that not having a requirement, somewhere in a standards track document, for a lower bound on object class and attribute type names already is causing harm. And we have a chance to mitigate that harm now. So I would like to see such a requirement in an appropriate LDAPBIS deliverable. I've already pointed out that there are multiple application contexts in which this issue is relevant. My opinion about where such a requirement belongs is based on the fact that this is an interoperability issue that transcends any specific application profile. Therefore, according to the work LDAPBIS is chartered to complete, I think it belongs somewhere in one of the deliverables produced by LDAPBIS. I realize that others might have different opinions. I can surmise what a few of those might be to the question of where such a requirement might belong. I would like to hear from more folks about their opinions on where such a requirement belongs and why. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Kurt D. Zeilenga Sent: Saturday, June 14, 2003 10:25 PM To: Kathy Dally Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds Kathy, your suggested specification change would require many independently developed interoperating implementations to change their "running code". Also, unless the limit is very high, such a limit will invalid existing conformant schema. Today's TS assumes that all implementations can handle all valid PDUs they are passed, including handling all allowed descriptors. An implementation will recognize and support some descriptors it will recognize and support, others it won't. Adding a small size limit won't change that. It will only limit LDAP domain of applicability. (This statement is, I believe, supported by operational experience in over protocol which has placed small limits on protocol fields. For example, the 20 octet SASL mechanism name limit is makes it unnecessarily difficult to support arbitrary GSS API mechanisms.) So, not only is the change not needed, it's going to do significant harm. We should not add size limit restrictions to protocol fields. They are bad. I agree that a LDAP "general purpose" client/server applicability statement, possibly Standard Track, is needed. I agree that extension guidelines, possibly as a BCP, is needed. However, the LDAP "core" technical specification is neither of these and it shouldn't expanded to include either. I note, as co-chair, that LDAPBIS is not chartered to produce either. Kurt At 10:59 AM 6/13/2003, Kathy Dally wrote: >Hi All! > >Saying all object identifier descriptors is ok. The 48 limit is ok. >However, I think we do need to recognize both the sending and receiving >cases. How's this: > > "To promote interoperability, server implementations SHOULD support >receiving object identifier descriptors (such as. attributetype names, >objectclass names, matching rule names, and the like), which are at >least 48 characters in length and MUST send object identifier >descriptors that are no longer than 48 characters. Schema designers >SHOULD use object identifier descriptors that are no longer than 48 >characters." > >Thanks, >Kathy > > >"Larry S. Bartz" wrote: >> >> Chris Apple wrote, On 06/13/03 10:44: >> > I was thinking more along the lines of a minimum bound in one of the >> > LDAPv3 Draft Standard documents. >> > >> > How about this for a requirement? >> > >> > "Implementations MUST support attribute names that are at least 32 >> > characters in length." >> >> How about 48? If IANA's ub is 48, then implementations could reasonably >> expect to see names of that length. All products and implementations >> should be prepared to support that. >> >> Further, the requirement should not be limited to attributetype names. >> The spec in RFC 3383 covers all object identifier descriptors, which >> includes attributetype names, objectclass names, matching rule names, >> etc. >> >> How about this? >> >> > >> >> Larry >> >> > >> > It seems like a simple one without a lot of baggage to me. But if anyone >> > thinks there's a good reason not to include it, I'd like to know what >> > that is. >> > >> > I have no strong opinions on an upper bound. >> > >> > I do realize that there is a work-around for this problem in most cases. >> > You can create a shorter attribute name and then use the intended attribute >> > name as an alias. But this gets to be a bit complicated when rolling out >> > services that use schema designed with longer attribute names. >> > >> > You have to perform testing to see what each implementation in question >> > supports and then create aliases matching up with the shortest supported >> > attribute name length. >> > >> > As a service implementer, that's an awfully expensive interoperability >> > hoop to have to jump through if I'm using a technology that is soon to >> > be based on a Draft Standard. >> > >> > I realize that someone might also want a larger attribute name length >> > but there seems to already be some restriction with respect to what may be >> > allowable from an IANA registration perspective. I'm not questioning that >> > because 48 characters for an upper bound seems reasonable to me. >> > >> > Chris Apple - Principal Architect >> > >> > DSI Consulting, Inc. >> > >> > mailto:capple@dsi-consulting.net >> > >> > http://www.dsi-consulting.com >> > >> > -----Original Message----- >> > From: owner-ietf-ldapbis@OpenLDAP.org >> > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz >> > Sent: Friday, June 13, 2003 10:48 AM >> > To: ietf-ldapbis@OpenLDAP.org >> > Subject: Re: Attribute Name Length Bounds >> > >> > >> > Mark C Smith wrote, On 06/13/03 08:26: >> > >> >>Jim Sermersheim wrote: >> >> >> >> >> >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of >> >>>attribute names. Any limitiation in a specific implementation is imposed >> >>>by that implementation, not by the spec, so I'm not sure we can do >> >>>anything about it here. >> >>> >> >>>Obviously no server allows an unlimited length, as they are all >> >>>limiited if by nothing more than available memory. I'm not sure if this >> >>>fits into an implementation report. It seems more appropriate for a >> >>>certification/branding program. Other than that, it seems like a valid >> >>>defect to raise with those implementors who restrict to unreasonable >> >>>limits. >> >> >> >> >> >>I agree. I tried to come up with text that we could add to [Models] or >> >>[Protocols] that would encourage implementors to not impose arbitrary, >> >>short limits... but I am not sure how to word such a requirement so it >> >>is meaningful. This is an interesting interoperability problem though. >> >> >> >>-Mark >> > >> > >> > >> > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 >> > "IANA Considerations for LDAP" would be helpful. It says, >> > >> > "While the protocol places no maximum length restriction upon >> > descriptors, they should be short. Descriptors longer than 48 >> > characters may be viewed as too long to register." >> > >> > There was obviously consensus in this WG regarding that length and >> > that language. >> > From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 09:15:42 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 JAA12924 for ; Mon, 16 Jun 2003 09:15:41 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GDCrEn099039; Mon, 16 Jun 2003 13:13:55 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 h5GDBb4H098898; Mon, 16 Jun 2003 13:11:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 13:11:37 +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 h5GDBZEh098856 for ; Mon, 16 Jun 2003 13:11:36 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 h5GDBFn04396 for ; Mon, 16 Jun 2003 06:11:15 -0700 (PDT) Received: from netscape.com ([10.169.192.36]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HGKSMM01.02C; Mon, 16 Jun 2003 06:11:10 -0700 Message-ID: <3EEDC1EB.3010007@netscape.com> Date: Mon, 16 Jun 2003 09:11:07 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030428 Netscape/7.02+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: capple@dsi-consulting.net CC: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds References: <000501c332f1$1a083b00$6500a8c0@D7ST2111> In-Reply-To: <000501c332f1$1a083b00$6500a8c0@D7ST2111> 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 Chris Apple wrote: > I maintain my view that this particular issue is of > sufficiently general nature to justify consideration > of adding a requirement to one or more standards track > documents. Some of those could be from this group. That > question I asked in a separate posting to the WG. I will be honest and say that I am not sure where such a requirement belongs. Lack of a minimum lower bound does make it difficult for anyone to create and publish schema that may be used with all LDAP implementations. That seems like a fairly general problem to me. I also see Jim and Kurt's point about the problems that will arise if the LDAPBis group descends down the path of specifying minimum lengths for all of the LDAP protocol elements. -Mark From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 12:07: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 MAA19339 for ; Mon, 16 Jun 2003 12:07:42 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GFtLFT016052; Mon, 16 Jun 2003 16:06:15 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 h5GFi1cg015077; Mon, 16 Jun 2003 15:44:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 15:44:01 +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 h5GFhxEh015037 for ; Mon, 16 Jun 2003 15:43:59 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 16 Jun 2003 09:43:39 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 16 Jun 2003 09:41:46 -0600 From: "Jim Sermersheim" To: Subject: RE: Attribute Name Length Bounds 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 >What is beginning to concern me is that your words imply that >it is inappropriate to address known interoperability issues >in preparation for moving to Draft Standard. Well, I never said that, and it's not my intent at all. I agreed that this is a problem. I'm not suggesting that it be ignored. I'm also not suggesting that we get all extreme and put mandatory minimums on all sequences in the protocol/data model. My intent is to ask that we view the general problem, and not just one aspect that happens to have reared its head recently. Jim >>> "Chris Apple" 6/14/03 4:00:29 PM >>> I would be fine with it if the scope was attribute type names and object class names. What is beginning to concern me is that your words imply that it is inappropriate to address known interoperability issues in preparation for moving to Draft Standard. It's true that it has become a known problem because of recent work I've done. The timing doesn't diminish the importance of discussing it in this forum; nor does it diminish the negative impact it will have on deploying services using the protocol in the field if there isn't some requirement addressing this particular known issue. I'm sure it's a good idea to look at the problem in a general way. I'm also sure that most users would appreciate tempering pure technical merit with pragmatic deployment concerns along the way. The idea of addressing this particular issue with a requirement seems to have some supporters and some folks who don't think its a good idea. But there hasn't been a lot of discussion about which LDAPBIS deliverable this might apply to. Notice that I actually stated that I didn't know where to even suggest its inclusion at the start of this thread. Nor do I at this time. That is perhaps a question that needs to be asked and answered explicitly. So consider it asked. Where do folks think such a requirement belongs? In one of the LDAPBIS deliverables? Or somewhere else (and where if that's the case)? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Saturday, June 14, 2003 2:16 PM To: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds >I wouldn't take it further than that because I don't have real world >examples that justify doing so. This is exactly my concern. It seems coincidental that you are seeing this problem, we are edititng the specification, so you see a chance to fix this problem. If you hadn't seen this problem at this particular time, and the spec got progressed without this change, then I suspect the problem would be addressed in some other way (one of those talked about earlier in the thread). Given this concern, I decided to have a look at some of the other potential 'problems' that are the same as this one. If, instead of this problem, you found that some servers limited DNs to 32 characters, we might be having that conversation instead of this one. I don't see the difference between schema lenghts and some of the other sequences listed in this thread. If you want to draw the line at those things which have IANA considerations, then we throw out sizes on other schema elements, and add in sizes on other things (like SASL mechanism). What's happenning here is a jump over to the IANA reasoning, then a hop over to a "similar elements" reasoning. To paraphase, my concern is that we're jumping on a problem just because someone happened to experience it, without looking at it in a general way. If we add this change, it sets a precedence for a class of instructions that was never part of the original spec. We shouldn't do this in such an isolated way. That only makes future readers scratch their heads wondering at the inconsistency. I don't understand why this can't be specified in an application profile document. I would say that there's a class of application that must add to (extend) the standard LDAP schema. For LDAP servers to service this class of applications, then they should handle reasonable schema name lengths. I don't think the LDAP spec even says that an LDAP server needs to allow its schema to be extended, only that it must support certain standard schema. Jim >>> "Chris Apple" 6/13/03 9:16:48 PM >>> My intended scope was names for schema elements such as attribute types, object class identifiers, attribute syntaxes, matching rules, and anything else that might be mapped to an OID with an associated, registered name. Given that there are IANA considerations for the registration of at least some of those types of schema elements, I don't think I'm proposing anything that is outrageous or unreasonable. I absolutely agree that most of the examples you gave should be handled in the context of profiling LDAPv3 DIT structure, Operations, Service Model, etc., for specific applications. I'm of the opinion that this particular minimum size requirement is of more general use than a specific application profile. I've already given two different examples where this is an issue. I'll repeat them here along with a third: - DEN - LDAPv3 mappings of the DMTF CIM - The Open Group's Mobility and Directory (MaD) Schema (this will be publicly presented at the Burton Group's Catalyst meeting in July 2003 - but basically its an information model for directory-enabled mobility management) Those are all different application contexts. Each has a need for attribute type names that are longer than the maximum attribute length supported by some LDAPv3-compliant implementations. Thus it is generally valuable to have a minimum length requirement for at least attribute type names and object class identifiers. By extension it also seems generally valuable to have the same sort of minimum supported length for names of matching rules and attribute syntaxes. I wouldn't take it further than that because I don't have real world examples that justify doing so. However, to accommodate the 3 schema specifications above in a general way, I do believe its justified. Specifying such a minimum schema element name length requirement would solve an interoperability problem related to using the protocol in the real world in at least three different and very significant application contexts. I think that's very much in line with the intent of progressing to Draft Standard. If we were to waive our hands about this and say, it means that we are interoperable if we just say we don't understand something that's been sent to us, we haven't actually helped the users with a relatively costly interoperability problem. I don't think hand waving makes for good standards when there's a need such as this that crosses multiple application contexts. Especially when such a requirement can scoped so that it doesn't cause the kind of "here a limit, there a limit, everywhere a limit" rat hole that some of the most recent postings implied might happen. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Friday, June 13, 2003 6:43 PM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds I'm still a little fuzzy on the scope of this discussion. The ASN.1 for attribute names is an unbounded OCTET STRING. This discussion seems to be saying "even though the protocol says the size is unlimited (well, limited to a ber length), we want to be more explicit and require protocols peers to handle some minimum size". What else does this discussion apply to? - LDAPDN (how long of a DN am I required to handle?) - RelativeLDAPDN - AttributeValue/AssertionValue (I note that the current len descriptor on attributes is a 'suggested minimum') - MatchingRuleId - LDAPResult.diagnosticMessage - LDAPURL (I suppose enough for a minimal scheme and delimiters is implied) - SASL mechanism (implied 1 to 20) - SASL credentials - LDAPOID - control/extendedValue - simple password AFAIK, today these all have a max-ber-len max. and no mandatory minimum is explicitly required to be supported. Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 14:02:29 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 OAA23074 for ; Mon, 16 Jun 2003 14:02: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 h5GI0tEl022672; Mon, 16 Jun 2003 18:01: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 h5GHvM05022543; Mon, 16 Jun 2003 17:57:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 17:57:22 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GHvGEh022530 for ; Mon, 16 Jun 2003 17:57:19 GMT (envelope-from capple@dsi-consulting.net) Received: from Inverness-MTA by echt.caledonia.net with Novell_GroupWise; Mon, 16 Jun 2003 11:56:46 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 16 Jun 2003 11:55:51 -0600 From: "Chris Apple" To: , Subject: Re: Attribute Name Length Bounds 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 definitely agree that we have both of those problems to deal with when considering what to do. Hence my original statement of not really knowing where it belongs either. It is not my intent to open a "Pandora's box," but I am leaning towards wanting something in an LDAPBIS deliverable to cover this particular need because its a general problem. Maybe the other folks who seemed to be expressing a similar leaning could speak up again now that we've had a bit more discussion? I'm referring to Rick, Kathy, and Larry. What do you think about where such a requirement belongs? Chris. >>> Mark C Smith 06/16/03 7:12 AM >>> Chris Apple wrote: > I maintain my view that this particular issue is of > sufficiently general nature to justify consideration > of adding a requirement to one or more standards track > documents. Some of those could be from this group. That > question I asked in a separate posting to the WG. I will be honest and say that I am not sure where such a requirement belongs. Lack of a minimum lower bound does make it difficult for anyone to create and publish schema that may be used with all LDAP implementations. That seems like a fairly general problem to me. I also see Jim and Kurt's point about the problems that will arise if the LDAPBis group descends down the path of specifying minimum lengths for all of the LDAP protocol elements. -Mark From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 14:54: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 OAA25257 for ; Mon, 16 Jun 2003 14:54: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 h5GImtEl026368; Mon, 16 Jun 2003 18:49:04 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 h5GIk2dj026247; Mon, 16 Jun 2003 18:46:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 18:46:02 +0000 Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GIjxEh026237 for ; Mon, 16 Jun 2003 18:46:00 GMT (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h5GIjch05037 for ietf-ldapbis@openldap.org; Mon, 16 Jun 2003 13:45:38 -0500 Date: Mon, 16 Jun 2003 13:45:38 -0500 From: Ryan Moats To: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds Message-ID: <20030616134538.R1422@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from capple@dsi-consulting.net on Mon, Jun 16, 2003 at 11:55:51AM -0600 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: On Mon, Jun 16, 2003 at 11:55:51AM -0600, Chris Apple wrote: | I definitely agree that we have both of those problems to deal with when | considering what to do. | Hence my original statement of not really knowing | where it belongs either. | | It is not my intent to open a "Pandora's box," but | I am leaning towards wanting something in an LDAPBIS | deliverable to cover this particular need because its | a general problem. | | Maybe the other folks who seemed to be expressing a | similar leaning could speak up again now that we've had a bit more | discussion? I'm referring to Rick, Kathy, and Larry. What do you think | about where such | a requirement belongs? | | Chris. | | >>> Mark C Smith 06/16/03 7:12 AM >>> | Chris Apple wrote: | | > I maintain my view that this particular issue is of | > sufficiently general nature to justify consideration | > of adding a requirement to one or more standards track | > documents. Some of those could be from this group. That | > question I asked in a separate posting to the WG. | | I will be honest and say that I am not sure where such a requirement | belongs. Lack of a minimum lower bound does make it difficult for anyone | | to create and publish schema that may be used with all LDAP | implementations. That seems like a fairly general problem to me. | | I also see Jim and Kurt's point about the problems that will arise if | the LDAPBis group descends down the path of specifying minimum lengths | for all of the LDAP protocol elements. | | -Mark Some technical data points: 1) There are *published, in use* schema that already have attribute and objectclass names > 48 chars in length. Therefore, a SHOULD/MUST upper limit of 48 will break an existing implementation, and that's a no-no. Further, using IANA considerations to drive such a limit is not appropriate because of the whole 1.3.6.1.4.1 branch. 2) If I don't have a minimum bound to attribute names, then the only way I can have interoperability is pairwise testing, which is horribly inefficient. Because of the point 1 above, I don't think LDAPBIS can take a pass without noting the fact that *any* upper limit in the attribute/objectclass name size runs afoul of the 1.3.6.1.4.1 branch. That's my proposal for maximal size. On point 2, if LDAPBIS takes a pass on minimal length, I view it as a failure to promote interoperability. I'd propose to see the minimal length be 48 because of the IANA considerations. Further, I think both of these are in fact protocol issues because LDAP can and does use attribute names on the wire. Ryan From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 16:00:02 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 QAA28979 for ; Mon, 16 Jun 2003 16:00:02 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GJstEl031055; Mon, 16 Jun 2003 19:59:02 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 h5GJrbuT030956; Mon, 16 Jun 2003 19:53:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 19:53:37 +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 h5GJrZEh030946 for ; Mon, 16 Jun 2003 19:53:35 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 h5GJrNc6009760; Mon, 16 Jun 2003 19:53:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030616120358.01c5b790@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 12:50:12 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: RE: Attribute Name Length Bounds Cc: capple@dsi-consulting.net, ietf-ldapbis@OpenLDAP.org, lbartz@parnelli.indy.cr.irs.gov In-Reply-To: <200306131724.NAA10540@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 10:24 AM 6/13/2003, Richard V Huber wrote: >In line with Larry Bartz' email mentioning RFC3383, how about: > > To promote interoperability, server implementors SHOULD allow at > least 48 characters for attribute names and schema designers SHOULD > use attribute names which are no longer than 48 characters. Let's look at each imperative separately. First the latter: Schema designers SHOULD use attribute names which are no longer than 48 characters. I think that BCP64, with the additions agreed upon in [Models], basically covers this. That is, BCP64bis will say that all descriptors (excepting those in private name space) SHOULD be registered and all descriptors in RFCs MUST be registered in addition to say that descriptors longer than 48 may be viewed as too long to register. While not precisely a requirement upon all schema (because it doesn't cover private name space elements), it certainly is significant encouragement to schema designers to avoid descriptors longer than 48. If a more precise requirement is desired, I suggest this be stated in a future "guidelines for schema developers" BCP along with the many other requirements that likely should be stated to schema developers. Now the former: Server implementors SHOULD allow at least 48 characters for attribute names Stating this in the LDAP TS is problematic as there is no requirement (and rightly so) for server implementation to support open-ended sets of attribute types. While certainly servers limit the sets of attribute types they support, they do by many means. Name length is just one factor. From a protocol interoperability stand point, this is not problem. Basically, vendors have chosen to limit the suitability to various markets. That's their choice. Now, what folks want is for vendors who claim to support open-ended sets of attribute types to implement some minimum set of requirements. Or to say it another way, folks want an applicability statement for a restricted domain of applicability for which servers can claim to support. That domain being "servers which support open-ended sets of attribute types" or maybe "general-purpose servers". Note here that as no server is required to be a "general-purpose server", we are talking about requirements for a restricted domain of applicability. As we've discussed in the past, those requirements are better stating in a separate document which offers such an applicability statement. It's my view what is needed is two new documents: "Guidelines for LDAP schema developers" "Applicability Statement for general-purpose LDAP servers" There is a fair amount of prior work in each of these areas. Bruce long ago wrote an I-D on the former, and much of that found its way in to my "Considerations for LDAP Extensions" I-D (which covers schema as well as other kinds of extensions). Also, the Open Group DIF is writing what are, in effect, applicability statements for their directory certification programs. I think its best for these works to continue on an individual basis. LDAPBIS needs to remain (at least for now) focused on delivering the "core" (technical) specification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 16:18:59 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 QAA00143 for ; Mon, 16 Jun 2003 16:18:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GKCtEn031997; Mon, 16 Jun 2003 20:18:02 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 h5GKCKJE031987; Mon, 16 Jun 2003 20:12:20 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 20:12:20 +0000 Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GKCGEh031916; Mon, 16 Jun 2003 20:12:16 GMT (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h5GKBhW05251; Mon, 16 Jun 2003 15:11:43 -0500 Date: Mon, 16 Jun 2003 15:11:43 -0500 From: Ryan Moats To: "Kurt D. Zeilenga" Cc: Richard V Huber , capple@dsi-consulting.net, ietf-ldapbis@OpenLDAP.org, lbartz@parnelli.indy.cr.irs.gov Subject: Re: Attribute Name Length Bounds Message-ID: <20030616151143.U1422@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: <200306131724.NAA10540@qsun.mt.att.com> <5.2.0.9.0.20030616120358.01c5b790@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.2.0.9.0.20030616120358.01c5b790@127.0.0.1>; from Kurt@OpenLDAP.org on Mon, Jun 16, 2003 at 12:50:12PM -0700 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- It is *NOT* clear to me whether you are speaking as co-chair or something else or both. Can you please note (going forward) which comments are being made with which hat on? Thanks, Ryan On Mon, Jun 16, 2003 at 12:50:12PM -0700, Kurt D. Zeilenga wrote: | At 10:24 AM 6/13/2003, Richard V Huber wrote: | >In line with Larry Bartz' email mentioning RFC3383, how about: | > | > To promote interoperability, server implementors SHOULD allow at | > least 48 characters for attribute names and schema designers SHOULD | > use attribute names which are no longer than 48 characters. | | Let's look at each imperative separately. First the latter: | Schema designers SHOULD use attribute names which are no | longer than 48 characters. | | I think that BCP64, with the additions agreed upon in [Models], | basically covers this. That is, BCP64bis will say that all | descriptors (excepting those in private name space) SHOULD be | registered and all descriptors in RFCs MUST be registered | in addition to say that descriptors longer than 48 may be | viewed as too long to register. | | While not precisely a requirement upon all schema (because | it doesn't cover private name space elements), it certainly is | significant encouragement to schema designers to avoid | descriptors longer than 48. | | If a more precise requirement is desired, I suggest this be | stated in a future "guidelines for schema developers" BCP | along with the many other requirements that likely should be | stated to schema developers. | | Now the former: | Server implementors SHOULD allow at least 48 characters for attribute names | | Stating this in the LDAP TS is problematic as there is no | requirement (and rightly so) for server implementation to | support open-ended sets of attribute types. While certainly | servers limit the sets of attribute types they support, they do | by many means. Name length is just one factor. From a protocol | interoperability stand point, this is not problem. | | Basically, vendors have chosen to limit the suitability to | various markets. That's their choice. | | Now, what folks want is for vendors who claim to support | open-ended sets of attribute types to implement some minimum | set of requirements. Or to say it another way, folks want | an applicability statement for a restricted domain of | applicability for which servers can claim to support. That | domain being "servers which support open-ended sets of | attribute types" or maybe "general-purpose servers". | | Note here that as no server is required to be a "general-purpose | server", we are talking about requirements for a restricted | domain of applicability. | | As we've discussed in the past, those requirements are better | stating in a separate document which offers such an | applicability statement. | | It's my view what is needed is two new documents: | "Guidelines for LDAP schema developers" | "Applicability Statement for general-purpose LDAP servers" | | There is a fair amount of prior work in each of these areas. | Bruce long ago wrote an I-D on the former, and much of that | found its way in to my "Considerations for LDAP Extensions" | I-D (which covers schema as well as other kinds of extensions). | Also, the Open Group DIF is writing what are, in effect, | applicability statements for their directory certification | programs. | | I think its best for these works to continue on an individual | basis. LDAPBIS needs to remain (at least for now) focused on | delivering the "core" (technical) specification. | | Kurt | | From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 16:41:26 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 QAA01541 for ; Mon, 16 Jun 2003 16:41:25 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GKUtFf033988; Mon, 16 Jun 2003 20:40:15 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 h5GKSmse033781; Mon, 16 Jun 2003 20:28:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 20:28:48 +0000 Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GKSiEh033740; Mon, 16 Jun 2003 20:28:45 GMT (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h5GKSNf05304; Mon, 16 Jun 2003 15:28:23 -0500 Date: Mon, 16 Jun 2003 15:28:23 -0500 From: Ryan Moats To: "Kurt D. Zeilenga" Cc: Richard V Huber , capple@dsi-consulting.net, ietf-ldapbis@OpenLDAP.org, lbartz@parnelli.indy.cr.irs.gov Subject: Re: Attribute Name Length Bounds Message-ID: <20030616152823.V1422@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: <200306131724.NAA10540@qsun.mt.att.com> <5.2.0.9.0.20030616120358.01c5b790@127.0.0.1> <20030616151143.U1422@privateer.local.windrose.omaha.ne.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030616151143.U1422@privateer.local.windrose.omaha.ne.us>; from rmoats@lemurnetworks.net on Mon, Jun 16, 2003 at 03:11:43PM -0500 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: On Mon, Jun 16, 2003 at 03:11:43PM -0500, Ryan Moats wrote: | Kurt- | | It is *NOT* clear to me whether you are speaking as co-chair or | something else or both. Can you please note (going forward) | which comments are being made with which hat on? | | Thanks, | Ryan ugh... that should be a *not* not a *NOT*. stupid caps lock... Ryan | On Mon, Jun 16, 2003 at 12:50:12PM -0700, Kurt D. Zeilenga wrote: | | At 10:24 AM 6/13/2003, Richard V Huber wrote: | | >In line with Larry Bartz' email mentioning RFC3383, how about: | | > | | > To promote interoperability, server implementors SHOULD allow at | | > least 48 characters for attribute names and schema designers SHOULD | | > use attribute names which are no longer than 48 characters. | | | | Let's look at each imperative separately. First the latter: | | Schema designers SHOULD use attribute names which are no | | longer than 48 characters. | | | | I think that BCP64, with the additions agreed upon in [Models], | | basically covers this. That is, BCP64bis will say that all | | descriptors (excepting those in private name space) SHOULD be | | registered and all descriptors in RFCs MUST be registered | | in addition to say that descriptors longer than 48 may be | | viewed as too long to register. | | | | While not precisely a requirement upon all schema (because | | it doesn't cover private name space elements), it certainly is | | significant encouragement to schema designers to avoid | | descriptors longer than 48. | | | | If a more precise requirement is desired, I suggest this be | | stated in a future "guidelines for schema developers" BCP | | along with the many other requirements that likely should be | | stated to schema developers. | | | | Now the former: | | Server implementors SHOULD allow at least 48 characters for attribute names | | | | Stating this in the LDAP TS is problematic as there is no | | requirement (and rightly so) for server implementation to | | support open-ended sets of attribute types. While certainly | | servers limit the sets of attribute types they support, they do | | by many means. Name length is just one factor. From a protocol | | interoperability stand point, this is not problem. | | | | Basically, vendors have chosen to limit the suitability to | | various markets. That's their choice. | | | | Now, what folks want is for vendors who claim to support | | open-ended sets of attribute types to implement some minimum | | set of requirements. Or to say it another way, folks want | | an applicability statement for a restricted domain of | | applicability for which servers can claim to support. That | | domain being "servers which support open-ended sets of | | attribute types" or maybe "general-purpose servers". | | | | Note here that as no server is required to be a "general-purpose | | server", we are talking about requirements for a restricted | | domain of applicability. | | | | As we've discussed in the past, those requirements are better | | stating in a separate document which offers such an | | applicability statement. | | | | It's my view what is needed is two new documents: | | "Guidelines for LDAP schema developers" | | "Applicability Statement for general-purpose LDAP servers" | | | | There is a fair amount of prior work in each of these areas. | | Bruce long ago wrote an I-D on the former, and much of that | | found its way in to my "Considerations for LDAP Extensions" | | I-D (which covers schema as well as other kinds of extensions). | | Also, the Open Group DIF is writing what are, in effect, | | applicability statements for their directory certification | | programs. | | | | I think its best for these works to continue on an individual | | basis. LDAPBIS needs to remain (at least for now) focused on | | delivering the "core" (technical) specification. | | | | Kurt | | | | From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 17:38:32 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 RAA03665 for ; Mon, 16 Jun 2003 17:38:31 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GLauEl039195; Mon, 16 Jun 2003 21:37: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 h5GLYFtk039082; Mon, 16 Jun 2003 21:34:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 21:34:15 +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 h5GLYDEh039072 for ; Mon, 16 Jun 2003 21:34:14 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 h5GLYBc6010567; Mon, 16 Jun 2003 21:34:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030616132126.01bb0020@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 14:31:00 -0700 To: rmoats@lemurnetworks.net From: "Kurt D. Zeilenga" Subject: Re: Attribute Name Length Bounds Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <20030616151143.U1422@privateer.local.windrose.omaha.ne.us> References: <5.2.0.9.0.20030616120358.01c5b790@127.0.0.1> <200306131724.NAA10540@qsun.mt.att.com> <5.2.0.9.0.20030616120358.01c5b790@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 01:11 PM 6/16/2003, Ryan Moats wrote: >It is *NOT* clear to me whether you are speaking as co-chair or >something else or both. Can you please note (going forward) >which comments are being made with which hat on? It's my general practice (though I likely have slipped in the past and likely will again in the future) to mark each statement coming from the chair in some way. I try to sign major statements from the chair with "LDAPBIS co-chair" but do occasionally inject comments from the chair with "as co-chair... ", or equivalent. Also, I occasionally mark individual comments using "Personally, ..." when I think the comment might be misconstrued as coming from the chair, but comments I make as an individual are generally not qualified. Hence, if its not explicitly labeled as coming from the chair, I likely didn't intend for it to be treated as coming from the chair. If I didn't mark something as coming from the chair when it should have been, I won't fault you or others for my error. I'll just post a clarification. I intend to continue with this practice and will try my best not to slip too much. In reviewing this thread, I believe no clarifications are needed. That is, I believe I've explicitly marked the one comment I made from the chair (with "as co-chair"). All my other comments were made as a WG member. With apologies for past and future slips, Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 17:50:09 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 RAA04221 for ; Mon, 16 Jun 2003 17:50: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 h5GLmuEl039580; Mon, 16 Jun 2003 21:49: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 h5GLl5OG039515; Mon, 16 Jun 2003 21:47:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 21:47:05 +0000 Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GLl1Eh039482; Mon, 16 Jun 2003 21:47:01 GMT (envelope-from kdally@mitre.org) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.12.9/8.12.8) with ESMTP id h5GLl0n5029147; Mon, 16 Jun 2003 17:47:00 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.12.9/8.12.8) with ESMTP id h5GLkxOH009951; Mon, 16 Jun 2003 17:46:59 -0400 (EDT) Received: from mm109527-2k.mitre.org (128.29.3.80) by mailhub1.mitre.org with SMTP id 3026179; Mon, 16 Jun 2003 17:46:56 -0400 Message-ID: <3EEE3ACF.EF8E25B9@mitre.org> Date: Mon, 16 Jun 2003 17:46:55 -0400 From: Kathy Dally Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds References: <000201c331c2$af386130$3d00000a@D7ST2111> <3EEA09A5.1050603@parnelli.indy.cr.irs.gov> <5.2.0.9.0.20030614184532.01b72630@127.0.0.1> Content-Type: text/plain; charset=us-ascii 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 Hi Kurt! I'm sorry to be so misunderstood. The issue that has been raised is not proposing limits on the attribute values (implying protocol field sizes), only the name (descriptor) of the attribute or other object. As far as a small limit, I simply recommended the number that is already set as a limit in the IANA considerations for this same issue. If, in general, descriptor identifiers need to be more than 48 characters, then the IANA document needs to be changed. Thanks, Kathy "Kurt D. Zeilenga" wrote: > > Kathy, your suggested specification change would require many > independently developed interoperating implementations to > change their "running code". Also, unless the limit is very > high, such a limit will invalid existing conformant schema. > > Today's TS assumes that all implementations can handle all > valid PDUs they are passed, including handling all allowed > descriptors. An implementation will recognize and support some > descriptors it will recognize and support, others it won't. > Adding a small size limit won't change that. It will only > limit LDAP domain of applicability. (This statement is, I > believe, supported by operational experience in over protocol > which has placed small limits on protocol fields. For example, > the 20 octet SASL mechanism name limit is makes it unnecessarily > difficult to support arbitrary GSS API mechanisms.) > > So, not only is the change not needed, it's going to do > significant harm. We should not add size limit restrictions > to protocol fields. They are bad. > > I agree that a LDAP "general purpose" client/server > applicability statement, possibly Standard Track, is needed. > I agree that extension guidelines, possibly as a BCP, is > needed. However, the LDAP "core" technical specification is > neither of these and it shouldn't expanded to include either. > > I note, as co-chair, that LDAPBIS is not chartered to produce > either. > > Kurt > > At 10:59 AM 6/13/2003, Kathy Dally wrote: > >Hi All! > > > >Saying all object identifier descriptors is ok. The 48 limit is ok. > >However, I think we do need to recognize both the sending and receiving > >cases. How's this: > > > > "To promote interoperability, server implementations SHOULD support > >receiving object identifier descriptors (such as. attributetype names, > >objectclass names, matching rule names, and the like), which are at > >least 48 characters in length and MUST send object identifier > >descriptors that are no longer than 48 characters. Schema designers > >SHOULD use object identifier descriptors that are no longer than 48 > >characters." > > > >Thanks, > >Kathy > > > > > >"Larry S. Bartz" wrote: > >> > >> Chris Apple wrote, On 06/13/03 10:44: > >> > I was thinking more along the lines of a minimum bound in one of the > >> > LDAPv3 Draft Standard documents. > >> > > >> > How about this for a requirement? > >> > > >> > "Implementations MUST support attribute names that are at least 32 > >> > characters in length." > >> > >> How about 48? If IANA's ub is 48, then implementations could reasonably > >> expect to see names of that length. All products and implementations > >> should be prepared to support that. > >> > >> Further, the requirement should not be limited to attributetype names. > >> The spec in RFC 3383 covers all object identifier descriptors, which > >> includes attributetype names, objectclass names, matching rule names, > >> etc. > >> > >> How about this? > >> > >> > > > >> > >> Larry > >> > >> > > >> > It seems like a simple one without a lot of baggage to me. But if anyone > >> > thinks there's a good reason not to include it, I'd like to know what > >> > that is. > >> > > >> > I have no strong opinions on an upper bound. > >> > > >> > I do realize that there is a work-around for this problem in most cases. > >> > You can create a shorter attribute name and then use the intended attribute > >> > name as an alias. But this gets to be a bit complicated when rolling out > >> > services that use schema designed with longer attribute names. > >> > > >> > You have to perform testing to see what each implementation in question > >> > supports and then create aliases matching up with the shortest supported > >> > attribute name length. > >> > > >> > As a service implementer, that's an awfully expensive interoperability > >> > hoop to have to jump through if I'm using a technology that is soon to > >> > be based on a Draft Standard. > >> > > >> > I realize that someone might also want a larger attribute name length > >> > but there seems to already be some restriction with respect to what may be > >> > allowable from an IANA registration perspective. I'm not questioning that > >> > because 48 characters for an upper bound seems reasonable to me. > >> > > >> > Chris Apple - Principal Architect > >> > > >> > DSI Consulting, Inc. > >> > > >> > mailto:capple@dsi-consulting.net > >> > > >> > http://www.dsi-consulting.com > >> > > >> > -----Original Message----- > >> > From: owner-ietf-ldapbis@OpenLDAP.org > >> > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz > >> > Sent: Friday, June 13, 2003 10:48 AM > >> > To: ietf-ldapbis@OpenLDAP.org > >> > Subject: Re: Attribute Name Length Bounds > >> > > >> > > >> > Mark C Smith wrote, On 06/13/03 08:26: > >> > > >> >>Jim Sermersheim wrote: > >> >> > >> >> > >> >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of > >> >>>attribute names. Any limitiation in a specific implementation is imposed > >> >>>by that implementation, not by the spec, so I'm not sure we can do > >> >>>anything about it here. > >> >>> > >> >>>Obviously no server allows an unlimited length, as they are all > >> >>>limiited if by nothing more than available memory. I'm not sure if this > >> >>>fits into an implementation report. It seems more appropriate for a > >> >>>certification/branding program. Other than that, it seems like a valid > >> >>>defect to raise with those implementors who restrict to unreasonable > >> >>>limits. > >> >> > >> >> > >> >>I agree. I tried to come up with text that we could add to [Models] or > >> >>[Protocols] that would encourage implementors to not impose arbitrary, > >> >>short limits... but I am not sure how to word such a requirement so it > >> >>is meaningful. This is an interesting interoperability problem though. > >> >> > >> >>-Mark > >> > > >> > > >> > > >> > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 > >> > "IANA Considerations for LDAP" would be helpful. It says, > >> > > >> > "While the protocol places no maximum length restriction upon > >> > descriptors, they should be short. Descriptors longer than 48 > >> > characters may be viewed as too long to register." > >> > > >> > There was obviously consensus in this WG regarding that length and > >> > that language. > >> > From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 18:26:14 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 SAA06648 for ; Mon, 16 Jun 2003 18:26:13 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GMOuEl041653; Mon, 16 Jun 2003 22:25:09 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 h5GMOUlR041629; Mon, 16 Jun 2003 22:24:30 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 22:24:30 +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 h5GMOREh041619 for ; Mon, 16 Jun 2003 22:24:27 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 h5GMOOc6010900; Mon, 16 Jun 2003 22:24:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030616145026.01c86498@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 15:21:13 -0700 To: Kathy Dally From: "Kurt D. Zeilenga" Subject: Re: Attribute Name Length Bounds Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3EEE3ACF.EF8E25B9@mitre.org> References: <000201c331c2$af386130$3d00000a@D7ST2111> <3EEA09A5.1050603@parnelli.indy.cr.irs.gov> <5.2.0.9.0.20030614184532.01b72630@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 02:46 PM 6/16/2003, Kathy Dally wrote: >Hi Kurt! > >I'm sorry to be so misunderstood. I think you misunderstand my comments. >The issue that has been raised is not proposing limits on the attribute >values (implying protocol field sizes), only the name (descriptor) of >the attribute or other object. Attribute short names (descriptors) are protocol values (or tokens) transferred in protocol fields. >As far as a small limit, I simply >recommended the number that is already set as a limit in the IANA >considerations for this same issue. If, in general, descriptor >identifiers need to be more than 48 characters, then the IANA document >needs to be changed. The BCP 64 provides guidelines for registration of LDAP protocol values, such as short names (descriptors). Nothing in BCP 64 disallows a descriptor longer than 48 characters from being registered. Nothing in BCP 64 restricts the length of descriptors which may appear in the protocol. Also, being just a guideline, it can be revised if found to be too limiting (or not limiting enough) without having to change the technical specification. For example, if the community were to decode that registration of portions of the name space can be delegated to owners of domains without involving IANA actions, we'd could publish a BCP allowing descriptors like COM-EXAMPLE-ORGANIZATIONALUNIT-MY-PERSONAL-USER-APPLICATION-ATTRIBUTE to be used in naming attribute types. Placing limits on protocol fields would prevent this. This is what happened with SASL mechanism names. They put a 20 character limit into the Technical Specification instead of just stating a IANA consideration on what mechanism names were considered too long to register. Now folks want to use OIDs to name mechanisms (coming from GSS API) but they cannot without changing the technical specification. Kurt >Thanks, >Kathy > > >"Kurt D. Zeilenga" wrote: >> >> Kathy, your suggested specification change would require many >> independently developed interoperating implementations to >> change their "running code". Also, unless the limit is very >> high, such a limit will invalid existing conformant schema. >> >> Today's TS assumes that all implementations can handle all >> valid PDUs they are passed, including handling all allowed >> descriptors. An implementation will recognize and support some >> descriptors it will recognize and support, others it won't. >> Adding a small size limit won't change that. It will only >> limit LDAP domain of applicability. (This statement is, I >> believe, supported by operational experience in over protocol >> which has placed small limits on protocol fields. For example, >> the 20 octet SASL mechanism name limit is makes it unnecessarily >> difficult to support arbitrary GSS API mechanisms.) >> >> So, not only is the change not needed, it's going to do >> significant harm. We should not add size limit restrictions >> to protocol fields. They are bad. >> >> I agree that a LDAP "general purpose" client/server >> applicability statement, possibly Standard Track, is needed. >> I agree that extension guidelines, possibly as a BCP, is >> needed. However, the LDAP "core" technical specification is >> neither of these and it shouldn't expanded to include either. >> >> I note, as co-chair, that LDAPBIS is not chartered to produce >> either. >> >> Kurt >> >> At 10:59 AM 6/13/2003, Kathy Dally wrote: >> >Hi All! >> > >> >Saying all object identifier descriptors is ok. The 48 limit is ok. >> >However, I think we do need to recognize both the sending and receiving >> >cases. How's this: >> > >> > "To promote interoperability, server implementations SHOULD support >> >receiving object identifier descriptors (such as. attributetype names, >> >objectclass names, matching rule names, and the like), which are at >> >least 48 characters in length and MUST send object identifier >> >descriptors that are no longer than 48 characters. Schema designers >> >SHOULD use object identifier descriptors that are no longer than 48 >> >characters." >> > >> >Thanks, >> >Kathy >> > >> > >> >"Larry S. Bartz" wrote: >> >> >> >> Chris Apple wrote, On 06/13/03 10:44: >> >> > I was thinking more along the lines of a minimum bound in one of the >> >> > LDAPv3 Draft Standard documents. >> >> > >> >> > How about this for a requirement? >> >> > >> >> > "Implementations MUST support attribute names that are at least 32 >> >> > characters in length." >> >> >> >> How about 48? If IANA's ub is 48, then implementations could reasonably >> >> expect to see names of that length. All products and implementations >> >> should be prepared to support that. >> >> >> >> Further, the requirement should not be limited to attributetype names. >> >> The spec in RFC 3383 covers all object identifier descriptors, which >> >> includes attributetype names, objectclass names, matching rule names, >> >> etc. >> >> >> >> How about this? >> >> >> >> >> > >> >> >> >> Larry >> >> >> >> > >> >> > It seems like a simple one without a lot of baggage to me. But if anyone >> >> > thinks there's a good reason not to include it, I'd like to know what >> >> > that is. >> >> > >> >> > I have no strong opinions on an upper bound. >> >> > >> >> > I do realize that there is a work-around for this problem in most cases. >> >> > You can create a shorter attribute name and then use the intended attribute >> >> > name as an alias. But this gets to be a bit complicated when rolling out >> >> > services that use schema designed with longer attribute names. >> >> > >> >> > You have to perform testing to see what each implementation in question >> >> > supports and then create aliases matching up with the shortest supported >> >> > attribute name length. >> >> > >> >> > As a service implementer, that's an awfully expensive interoperability >> >> > hoop to have to jump through if I'm using a technology that is soon to >> >> > be based on a Draft Standard. >> >> > >> >> > I realize that someone might also want a larger attribute name length >> >> > but there seems to already be some restriction with respect to what may be >> >> > allowable from an IANA registration perspective. I'm not questioning that >> >> > because 48 characters for an upper bound seems reasonable to me. >> >> > >> >> > Chris Apple - Principal Architect >> >> > >> >> > DSI Consulting, Inc. >> >> > >> >> > mailto:capple@dsi-consulting.net >> >> > >> >> > http://www.dsi-consulting.com >> >> > >> >> > -----Original Message----- >> >> > From: owner-ietf-ldapbis@OpenLDAP.org >> >> > [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Larry S. Bartz >> >> > Sent: Friday, June 13, 2003 10:48 AM >> >> > To: ietf-ldapbis@OpenLDAP.org >> >> > Subject: Re: Attribute Name Length Bounds >> >> > >> >> > >> >> > Mark C Smith wrote, On 06/13/03 08:26: >> >> > >> >> >>Jim Sermersheim wrote: >> >> >> >> >> >> >> >> >>>As far as I know, neither [Models] nor [Protocol] limits the lenght of >> >> >>>attribute names. Any limitiation in a specific implementation is imposed >> >> >>>by that implementation, not by the spec, so I'm not sure we can do >> >> >>>anything about it here. >> >> >>> >> >> >>>Obviously no server allows an unlimited length, as they are all >> >> >>>limiited if by nothing more than available memory. I'm not sure if this >> >> >>>fits into an implementation report. It seems more appropriate for a >> >> >>>certification/branding program. Other than that, it seems like a valid >> >> >>>defect to raise with those implementors who restrict to unreasonable >> >> >>>limits. >> >> >> >> >> >> >> >> >>I agree. I tried to come up with text that we could add to [Models] or >> >> >>[Protocols] that would encourage implementors to not impose arbitrary, >> >> >>short limits... but I am not sure how to word such a requirement so it >> >> >>is meaningful. This is an interesting interoperability problem though. >> >> >> >> >> >>-Mark >> >> > >> >> > >> >> > >> >> > Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383 >> >> > "IANA Considerations for LDAP" would be helpful. It says, >> >> > >> >> > "While the protocol places no maximum length restriction upon >> >> > descriptors, they should be short. Descriptors longer than 48 >> >> > characters may be viewed as too long to register." >> >> > >> >> > There was obviously consensus in this WG regarding that length and >> >> > that language. >> >> > From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 19:08:33 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 TAA07980 for ; Mon, 16 Jun 2003 19:08:32 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GN6uEl043711; Mon, 16 Jun 2003 23:07: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 h5GN6mo7043691; Mon, 16 Jun 2003 23:06:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 16 Jun 2003 23:06:48 +0000 Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5GN6kEh043661; Mon, 16 Jun 2003 23:06:46 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5GN6fYV031162; Mon, 16 Jun 2003 16:06:41 -0700 Received: from D-140-142-21-86.dhcp4.washington.edu (D-140-142-21-86.dhcp4.washington.edu [140.142.21.86]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5GN6e3i029959 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 16 Jun 2003 16:06:41 -0700 Date: Mon, 16 Jun 2003 16:06:47 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: "Kurt D. Zeilenga" cc: IETF ldapbis WG Subject: Re: Attribute Name Length Bounds In-Reply-To: <5.2.0.9.0.20030616145026.01c86498@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: On Mon, 16 Jun 2003, Kurt D. Zeilenga wrote: > For example, if the community were to decode that registration > of portions of the name space can be delegated to owners of > domains without involving IANA actions, we'd could publish > a BCP allowing descriptors like > COM-EXAMPLE-ORGANIZATIONALUNIT-MY-PERSONAL-USER-APPLICATION-ATTRIBUTE > to be used in naming attribute types. And let me add that this is not at all a far-fetched notion. I'm engaged in making up some conventions for representing attribute-type descriptors as URNs (for use in XML context), with a result that looks a lot like the above. (And why not use urn:oid, you ask? Don't ask ...) - RL "Bob" From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 23:20:52 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 XAA14581 for ; Mon, 16 Jun 2003 23:20:51 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H3IwEl050690; Tue, 17 Jun 2003 03:19:30 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 h5H3Hein050604; Tue, 17 Jun 2003 03:17:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 03:17:40 +0000 Received: from www.cequs.com (pcp04129315pcs.walngs01.pa.comcast.net [68.83.138.212]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H3HbEh050593 for ; Tue, 17 Jun 2003 03:17:38 GMT (envelope-from root@cequs.com) Received: from developer2.cequs.com ([192.168.1.102]) by www.cequs.com (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id h5H2G8US012481 for ; Mon, 16 Jun 2003 22:16:09 -0400 Received: (from root@localhost) by developer2.cequs.com (8.11.7+Sun/8.11.6) id h5H3CeU01038; Mon, 16 Jun 2003 23:12:40 -0400 (EDT) Date: Mon, 16 Jun 2003 23:12:40 -0400 From: Peter Bachman To: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds Message-Id: <20030616231240.4b6eefbb.peterb@cequs.com> In-Reply-To: References: Organization: Cequs Inc. X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; sparc-sun-solaris2.8) X-Identity: cn=Peter Bachman, o=Cequs Inc, c=US Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 generalized problem then is not related to the length, i take it, since there's no requirement that a specific length, can or cannot represent the information that's captured in schema, even if it causes problems of interoperability. -pb On Mon, 16 Jun 2003 09:41:46 -0600 "Jim Sermersheim" wrote: >>What is beginning to concern me is that your words imply that >>it is inappropriate to address known interoperability issues >>in preparation for moving to Draft Standard. > >Well, I never said that, and it's not my intent at all. > >I agreed that this is a problem. I'm not suggesting that it be ignored. >I'm also not suggesting that we get all extreme and put mandatory >minimums on all sequences in the protocol/data model. > >My intent is to ask that we view the general problem, and not just one >aspect that happens to have reared its head recently. > >Jim > > >>>> "Chris Apple" 6/14/03 4:00:29 PM >>> >I would be fine with it if the scope was attribute type names >and object class names. > >What is beginning to concern me is that your words imply that >it is inappropriate to address known interoperability issues >in preparation for moving to Draft Standard. It's true that it >has become a known problem because of recent work I've done. >The timing doesn't diminish the importance of discussing it >in this forum; nor does it diminish the negative impact it will >have on deploying services using the protocol in the field if >there isn't some requirement addressing this particular known >issue. > >I'm sure it's a good idea to look at the problem in a general >way. I'm also sure that most users would appreciate >tempering pure technical merit with pragmatic deployment >concerns along the way. > >The idea of addressing this particular issue with a requirement >seems to have some supporters and some folks who don't think its >a good idea. But there hasn't been a lot of discussion about >which LDAPBIS deliverable this might apply to. > >Notice that I actually stated that I didn't know where to even >suggest its inclusion at the start of this thread. Nor do I at >this time. > >That is perhaps a question that needs to be asked and answered >explicitly. So consider it asked. Where do folks think such a >requirement belongs? In one of the LDAPBIS deliverables? Or >somewhere else (and where if that's the case)? > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim >Sent: Saturday, June 14, 2003 2:16 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: RE: Attribute Name Length Bounds > > >>I wouldn't take it further than that because I don't have real world >>examples that justify doing so. > >This is exactly my concern. It seems coincidental that you are seeing >this problem, we are edititng the specification, so you see a chance >to >fix this problem. If you hadn't seen this problem at this particular >time, and the spec got progressed without this change, then I suspect >the problem would be addressed in some other way (one of those talked >about earlier in the thread). > >Given this concern, I decided to have a look at some of the other >potential 'problems' that are the same as this one. > >If, instead of this problem, you found that some servers limited DNs >to >32 characters, we might be having that conversation instead of this >one. >I don't see the difference between schema lenghts and some of the >other >sequences listed in this thread. If you want to draw the line at those >things which have IANA considerations, then we throw out sizes on >other >schema elements, and add in sizes on other things (like SASL >mechanism). >What's happenning here is a jump over to the IANA reasoning, then a >hop >over to a "similar elements" reasoning. > >To paraphase, my concern is that we're jumping on a problem just >because someone happened to experience it, without looking at it in a >general way. > >If we add this change, it sets a precedence for a class of >instructions >that was never part of the original spec. We shouldn't do this in such >an isolated way. That only makes future readers scratch their heads >wondering at the inconsistency. > >I don't understand why this can't be specified in an application >profile document. I would say that there's a class of application that >must add to (extend) the standard LDAP schema. For LDAP servers to >service this class of applications, then they should handle reasonable >schema name lengths. I don't think the LDAP spec even says that an >LDAP >server needs to allow its schema to be extended, only that it must >support certain standard schema. > >Jim > >>>> "Chris Apple" 6/13/03 9:16:48 PM >>> >My intended scope was names for schema elements such as >attribute types, object class identifiers, attribute >syntaxes, matching rules, and anything else that might >be mapped to an OID with an associated, registered name. > >Given that there are IANA considerations for the registration >of at least some of those types of schema elements, I don't >think I'm proposing anything that is outrageous or unreasonable. > >I absolutely agree that most of the examples you gave should be >handled in the context of profiling LDAPv3 DIT structure, >Operations, Service Model, etc., for specific applications. > >I'm of the opinion that this particular minimum size requirement >is of more general use than a specific application profile. I've >already given two different examples where this is an issue. >I'll repeat them here along with a third: > > - DEN > - LDAPv3 mappings of the DMTF CIM > - The Open Group's Mobility and Directory (MaD) Schema > (this will be publicly presented at the Burton Group's > Catalyst meeting in July 2003 - but basically its an > information model for directory-enabled mobility > management) > >Those are all different application contexts. Each has a need >for attribute type names that are longer than the maximum >attribute length supported by some LDAPv3-compliant implementations. > >Thus it is generally valuable to have a minimum length requirement >for at least attribute type names and object class identifiers. By >extension it also seems generally valuable to have the same sort of >minimum supported length for names of matching rules and attribute >syntaxes. > >I wouldn't take it further than that because I don't have real world >examples that justify doing so. > >However, to accommodate the 3 schema specifications above in >a general way, I do believe its justified. Specifying such >a minimum schema element name length requirement would solve an >interoperability problem related to using the protocol in the real >world in at least three different and very significant application >contexts. I think that's very much in line with the intent of >progressing to Draft Standard. If we were to waive our hands about >this and say, it means that we are interoperable if we just say >we don't understand something that's been sent to us, we haven't >actually helped the users with a relatively costly interoperability >problem. > >I don't think hand waving makes for good standards when >there's a need such as this that crosses multiple application >contexts. Especially when such a requirement can scoped so >that it doesn't cause the kind of "here a limit, there a limit, >everywhere a limit" rat hole that some of the most recent postings >implied might happen. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim >Sent: Friday, June 13, 2003 6:43 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: Re: Attribute Name Length Bounds > > >I'm still a little fuzzy on the scope of this discussion. > >The ASN.1 for attribute names is an unbounded OCTET STRING. > >This discussion seems to be saying "even though the protocol says the >size is unlimited (well, limited to a ber length), we want to be more >explicit and require protocols peers to handle some minimum size". > >What else does this discussion apply to? >- LDAPDN (how long of a DN am I required to handle?) >- RelativeLDAPDN >- AttributeValue/AssertionValue (I note that the current len >descriptor >on attributes is a 'suggested minimum') >- MatchingRuleId >- LDAPResult.diagnosticMessage >- LDAPURL (I suppose enough for a minimal scheme and delimiters is >implied) >- SASL mechanism (implied 1 to 20) >- SASL credentials >- LDAPOID >- control/extendedValue >- simple password > >AFAIK, today these all have a max-ber-len max. and no mandatory >minimum >is explicitly required to be supported. > >Jim > > From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 16 23:56:13 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 XAA15430 for ; Mon, 16 Jun 2003 23:56:12 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H3swEl051562; Tue, 17 Jun 2003 03:55:04 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 h5H3rrme051528; Tue, 17 Jun 2003 03:53:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 03:53:53 +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 h5H3rpEh051514 for ; Tue, 17 Jun 2003 03:53:51 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 16 Jun 2003 21:53:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 16 Jun 2003 21:52:02 -0600 From: "Jim Sermersheim" To: Subject: RE: Attribute Name Length Bounds 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 Did you mean to say the generlized problem *is* related to the length? As I see it, the generalized problem is that there are sequences defined in the LDAP protocol and models, and because no requirements to support a minimum lower or maximum upper number of elements in some of them have and will cause certain applications to fail. Jim >>> Peter Bachman 6/16/03 9:12:40 PM >>> The generalized problem then is not related to the length, i take it, since there's no requirement that a specific length, can or cannot represent the information that's captured in schema, even if it causes problems of interoperability. -pb On Mon, 16 Jun 2003 09:41:46 -0600 "Jim Sermersheim" wrote: >>What is beginning to concern me is that your words imply that >>it is inappropriate to address known interoperability issues >>in preparation for moving to Draft Standard. > >Well, I never said that, and it's not my intent at all. > >I agreed that this is a problem. I'm not suggesting that it be ignored. >I'm also not suggesting that we get all extreme and put mandatory >minimums on all sequences in the protocol/data model. > >My intent is to ask that we view the general problem, and not just one >aspect that happens to have reared its head recently. > >Jim > > >>>> "Chris Apple" 6/14/03 4:00:29 PM >>> >I would be fine with it if the scope was attribute type names >and object class names. > >What is beginning to concern me is that your words imply that >it is inappropriate to address known interoperability issues >in preparation for moving to Draft Standard. It's true that it >has become a known problem because of recent work I've done. >The timing doesn't diminish the importance of discussing it >in this forum; nor does it diminish the negative impact it will >have on deploying services using the protocol in the field if >there isn't some requirement addressing this particular known >issue. > >I'm sure it's a good idea to look at the problem in a general >way. I'm also sure that most users would appreciate >tempering pure technical merit with pragmatic deployment >concerns along the way. > >The idea of addressing this particular issue with a requirement >seems to have some supporters and some folks who don't think its >a good idea. But there hasn't been a lot of discussion about >which LDAPBIS deliverable this might apply to. > >Notice that I actually stated that I didn't know where to even >suggest its inclusion at the start of this thread. Nor do I at >this time. > >That is perhaps a question that needs to be asked and answered >explicitly. So consider it asked. Where do folks think such a >requirement belongs? In one of the LDAPBIS deliverables? Or >somewhere else (and where if that's the case)? > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim >Sent: Saturday, June 14, 2003 2:16 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: RE: Attribute Name Length Bounds > > >>I wouldn't take it further than that because I don't have real world >>examples that justify doing so. > >This is exactly my concern. It seems coincidental that you are seeing >this problem, we are edititng the specification, so you see a chance >to >fix this problem. If you hadn't seen this problem at this particular >time, and the spec got progressed without this change, then I suspect >the problem would be addressed in some other way (one of those talked >about earlier in the thread). > >Given this concern, I decided to have a look at some of the other >potential 'problems' that are the same as this one. > >If, instead of this problem, you found that some servers limited DNs >to >32 characters, we might be having that conversation instead of this >one. >I don't see the difference between schema lenghts and some of the >other >sequences listed in this thread. If you want to draw the line at those >things which have IANA considerations, then we throw out sizes on >other >schema elements, and add in sizes on other things (like SASL >mechanism). >What's happenning here is a jump over to the IANA reasoning, then a >hop >over to a "similar elements" reasoning. > >To paraphase, my concern is that we're jumping on a problem just >because someone happened to experience it, without looking at it in a >general way. > >If we add this change, it sets a precedence for a class of >instructions >that was never part of the original spec. We shouldn't do this in such >an isolated way. That only makes future readers scratch their heads >wondering at the inconsistency. > >I don't understand why this can't be specified in an application >profile document. I would say that there's a class of application that >must add to (extend) the standard LDAP schema. For LDAP servers to >service this class of applications, then they should handle reasonable >schema name lengths. I don't think the LDAP spec even says that an >LDAP >server needs to allow its schema to be extended, only that it must >support certain standard schema. > >Jim > >>>> "Chris Apple" 6/13/03 9:16:48 PM >>> >My intended scope was names for schema elements such as >attribute types, object class identifiers, attribute >syntaxes, matching rules, and anything else that might >be mapped to an OID with an associated, registered name. > >Given that there are IANA considerations for the registration >of at least some of those types of schema elements, I don't >think I'm proposing anything that is outrageous or unreasonable. > >I absolutely agree that most of the examples you gave should be >handled in the context of profiling LDAPv3 DIT structure, >Operations, Service Model, etc., for specific applications. > >I'm of the opinion that this particular minimum size requirement >is of more general use than a specific application profile. I've >already given two different examples where this is an issue. >I'll repeat them here along with a third: > > - DEN > - LDAPv3 mappings of the DMTF CIM > - The Open Group's Mobility and Directory (MaD) Schema > (this will be publicly presented at the Burton Group's > Catalyst meeting in July 2003 - but basically its an > information model for directory-enabled mobility > management) > >Those are all different application contexts. Each has a need >for attribute type names that are longer than the maximum >attribute length supported by some LDAPv3-compliant implementations. > >Thus it is generally valuable to have a minimum length requirement >for at least attribute type names and object class identifiers. By >extension it also seems generally valuable to have the same sort of >minimum supported length for names of matching rules and attribute >syntaxes. > >I wouldn't take it further than that because I don't have real world >examples that justify doing so. > >However, to accommodate the 3 schema specifications above in >a general way, I do believe its justified. Specifying such >a minimum schema element name length requirement would solve an >interoperability problem related to using the protocol in the real >world in at least three different and very significant application >contexts. I think that's very much in line with the intent of >progressing to Draft Standard. If we were to waive our hands about >this and say, it means that we are interoperable if we just say >we don't understand something that's been sent to us, we haven't >actually helped the users with a relatively costly interoperability >problem. > >I don't think hand waving makes for good standards when >there's a need such as this that crosses multiple application >contexts. Especially when such a requirement can scoped so >that it doesn't cause the kind of "here a limit, there a limit, >everywhere a limit" rat hole that some of the most recent postings >implied might happen. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim >Sent: Friday, June 13, 2003 6:43 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: Re: Attribute Name Length Bounds > > >I'm still a little fuzzy on the scope of this discussion. > >The ASN.1 for attribute names is an unbounded OCTET STRING. > >This discussion seems to be saying "even though the protocol says the >size is unlimited (well, limited to a ber length), we want to be more >explicit and require protocols peers to handle some minimum size". > >What else does this discussion apply to? >- LDAPDN (how long of a DN am I required to handle?) >- RelativeLDAPDN >- AttributeValue/AssertionValue (I note that the current len >descriptor >on attributes is a 'suggested minimum') >- MatchingRuleId >- LDAPResult.diagnosticMessage >- LDAPURL (I suppose enough for a minimal scheme and delimiters is >implied) >- SASL mechanism (implied 1 to 20) >- SASL credentials >- LDAPOID >- control/extendedValue >- simple password > >AFAIK, today these all have a max-ber-len max. and no mandatory >minimum >is explicitly required to be supported. > >Jim > > From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 00:14:18 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 AAA15922 for ; Tue, 17 Jun 2003 00:14:17 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H4CwEl051984; Tue, 17 Jun 2003 04:13: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 h5H4Amu6051900; Tue, 17 Jun 2003 04:10:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 04:10:48 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H4AfEh051887 for ; Tue, 17 Jun 2003 04:10:41 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 ([199.72.166.218]) by echt.caledonia.net; Mon, 16 Jun 2003 22:09:21 -0600 Reply-To: From: "Chris Apple" To: "'Jim Sermersheim'" , Subject: RE: Attribute Name Length Bounds Date: Tue, 17 Jun 2003 00:08:51 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000501c33486$34a35fd0$5f0aa8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 found that confusing as well. Peter: could you please clarify or elaborate? Jim: I agree with your generalized problem statement. I'm guessing that the sequence of octets in an attribute type name or object class name is how your covering the specific problem I found under this general statement. Is that accurate? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Monday, June 16, 2003 11:52 PM To: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds Did you mean to say the generlized problem *is* related to the length? As I see it, the generalized problem is that there are sequences defined in the LDAP protocol and models, and because no requirements to support a minimum lower or maximum upper number of elements in some of them have and will cause certain applications to fail. Jim >>> Peter Bachman 6/16/03 9:12:40 PM >>> The generalized problem then is not related to the length, i take it, since there's no requirement that a specific length, can or cannot represent the information that's captured in schema, even if it causes problems of interoperability. -pb On Mon, 16 Jun 2003 09:41:46 -0600 "Jim Sermersheim" wrote: >>What is beginning to concern me is that your words imply that >>it is inappropriate to address known interoperability issues >>in preparation for moving to Draft Standard. > >Well, I never said that, and it's not my intent at all. > >I agreed that this is a problem. I'm not suggesting that it be ignored. >I'm also not suggesting that we get all extreme and put mandatory >minimums on all sequences in the protocol/data model. > >My intent is to ask that we view the general problem, and not just one >aspect that happens to have reared its head recently. > >Jim > > >>>> "Chris Apple" 6/14/03 4:00:29 PM >>> >I would be fine with it if the scope was attribute type names >and object class names. > >What is beginning to concern me is that your words imply that >it is inappropriate to address known interoperability issues >in preparation for moving to Draft Standard. It's true that it >has become a known problem because of recent work I've done. >The timing doesn't diminish the importance of discussing it >in this forum; nor does it diminish the negative impact it will >have on deploying services using the protocol in the field if >there isn't some requirement addressing this particular known >issue. > >I'm sure it's a good idea to look at the problem in a general >way. I'm also sure that most users would appreciate >tempering pure technical merit with pragmatic deployment >concerns along the way. > >The idea of addressing this particular issue with a requirement >seems to have some supporters and some folks who don't think its >a good idea. But there hasn't been a lot of discussion about >which LDAPBIS deliverable this might apply to. > >Notice that I actually stated that I didn't know where to even >suggest its inclusion at the start of this thread. Nor do I at >this time. > >That is perhaps a question that needs to be asked and answered >explicitly. So consider it asked. Where do folks think such a >requirement belongs? In one of the LDAPBIS deliverables? Or >somewhere else (and where if that's the case)? > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim >Sent: Saturday, June 14, 2003 2:16 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: RE: Attribute Name Length Bounds > > >>I wouldn't take it further than that because I don't have real world >>examples that justify doing so. > >This is exactly my concern. It seems coincidental that you are seeing >this problem, we are edititng the specification, so you see a chance >to >fix this problem. If you hadn't seen this problem at this particular >time, and the spec got progressed without this change, then I suspect >the problem would be addressed in some other way (one of those talked >about earlier in the thread). > >Given this concern, I decided to have a look at some of the other >potential 'problems' that are the same as this one. > >If, instead of this problem, you found that some servers limited DNs >to >32 characters, we might be having that conversation instead of this >one. >I don't see the difference between schema lenghts and some of the >other >sequences listed in this thread. If you want to draw the line at those >things which have IANA considerations, then we throw out sizes on >other >schema elements, and add in sizes on other things (like SASL >mechanism). >What's happenning here is a jump over to the IANA reasoning, then a >hop >over to a "similar elements" reasoning. > >To paraphase, my concern is that we're jumping on a problem just >because someone happened to experience it, without looking at it in a >general way. > >If we add this change, it sets a precedence for a class of >instructions >that was never part of the original spec. We shouldn't do this in such >an isolated way. That only makes future readers scratch their heads >wondering at the inconsistency. > >I don't understand why this can't be specified in an application >profile document. I would say that there's a class of application that >must add to (extend) the standard LDAP schema. For LDAP servers to >service this class of applications, then they should handle reasonable >schema name lengths. I don't think the LDAP spec even says that an >LDAP >server needs to allow its schema to be extended, only that it must >support certain standard schema. > >Jim > >>>> "Chris Apple" 6/13/03 9:16:48 PM >>> >My intended scope was names for schema elements such as >attribute types, object class identifiers, attribute >syntaxes, matching rules, and anything else that might >be mapped to an OID with an associated, registered name. > >Given that there are IANA considerations for the registration >of at least some of those types of schema elements, I don't >think I'm proposing anything that is outrageous or unreasonable. > >I absolutely agree that most of the examples you gave should be >handled in the context of profiling LDAPv3 DIT structure, >Operations, Service Model, etc., for specific applications. > >I'm of the opinion that this particular minimum size requirement >is of more general use than a specific application profile. I've >already given two different examples where this is an issue. >I'll repeat them here along with a third: > > - DEN > - LDAPv3 mappings of the DMTF CIM > - The Open Group's Mobility and Directory (MaD) Schema > (this will be publicly presented at the Burton Group's > Catalyst meeting in July 2003 - but basically its an > information model for directory-enabled mobility > management) > >Those are all different application contexts. Each has a need >for attribute type names that are longer than the maximum >attribute length supported by some LDAPv3-compliant implementations. > >Thus it is generally valuable to have a minimum length requirement >for at least attribute type names and object class identifiers. By >extension it also seems generally valuable to have the same sort of >minimum supported length for names of matching rules and attribute >syntaxes. > >I wouldn't take it further than that because I don't have real world >examples that justify doing so. > >However, to accommodate the 3 schema specifications above in >a general way, I do believe its justified. Specifying such >a minimum schema element name length requirement would solve an >interoperability problem related to using the protocol in the real >world in at least three different and very significant application >contexts. I think that's very much in line with the intent of >progressing to Draft Standard. If we were to waive our hands about >this and say, it means that we are interoperable if we just say >we don't understand something that's been sent to us, we haven't >actually helped the users with a relatively costly interoperability >problem. > >I don't think hand waving makes for good standards when >there's a need such as this that crosses multiple application >contexts. Especially when such a requirement can scoped so >that it doesn't cause the kind of "here a limit, there a limit, >everywhere a limit" rat hole that some of the most recent postings >implied might happen. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim >Sent: Friday, June 13, 2003 6:43 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: Re: Attribute Name Length Bounds > > >I'm still a little fuzzy on the scope of this discussion. > >The ASN.1 for attribute names is an unbounded OCTET STRING. > >This discussion seems to be saying "even though the protocol says the >size is unlimited (well, limited to a ber length), we want to be more >explicit and require protocols peers to handle some minimum size". > >What else does this discussion apply to? >- LDAPDN (how long of a DN am I required to handle?) >- RelativeLDAPDN >- AttributeValue/AssertionValue (I note that the current len >descriptor >on attributes is a 'suggested minimum') >- MatchingRuleId >- LDAPResult.diagnosticMessage >- LDAPURL (I suppose enough for a minimal scheme and delimiters is >implied) >- SASL mechanism (implied 1 to 20) >- SASL credentials >- LDAPOID >- control/extendedValue >- simple password > >AFAIK, today these all have a max-ber-len max. and no mandatory >minimum >is explicitly required to be supported. > >Jim > > From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 00:26:21 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 AAA16465 for ; Tue, 17 Jun 2003 00:26:21 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H4OwEl052302; Tue, 17 Jun 2003 04: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 h5H4NEuw052230; Tue, 17 Jun 2003 04:23:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 04:23:14 +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 h5H4NCEh052219 for ; Tue, 17 Jun 2003 04:23:12 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 16 Jun 2003 22:22:52 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 16 Jun 2003 22:21:36 -0600 From: "Jim Sermersheim" To: Subject: RE: Attribute Name Length Bounds 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, (sequence of octets = octet string). Not following asn.1 terminology, just trying to avoid typing more words than I had to. Jim >>> "Chris Apple" 6/16/03 10:08:51 PM >>> I found that confusing as well. Peter: could you please clarify or elaborate? Jim: I agree with your generalized problem statement. I'm guessing that the sequence of octets in an attribute type name or object class name is how your covering the specific problem I found under this general statement. Is that accurate? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Monday, June 16, 2003 11:52 PM To: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds Did you mean to say the generlized problem *is* related to the length? As I see it, the generalized problem is that there are sequences defined in the LDAP protocol and models, and because no requirements to support a minimum lower or maximum upper number of elements in some of them have and will cause certain applications to fail. Jim >>> Peter Bachman 6/16/03 9:12:40 PM >>> The generalized problem then is not related to the length, i take it, since there's no requirement that a specific length, can or cannot represent the information that's captured in schema, even if it causes problems of interoperability. -pb On Mon, 16 Jun 2003 09:41:46 -0600 "Jim Sermersheim" wrote: >>What is beginning to concern me is that your words imply that >>it is inappropriate to address known interoperability issues >>in preparation for moving to Draft Standard. > >Well, I never said that, and it's not my intent at all. > >I agreed that this is a problem. I'm not suggesting that it be ignored. >I'm also not suggesting that we get all extreme and put mandatory >minimums on all sequences in the protocol/data model. > >My intent is to ask that we view the general problem, and not just one >aspect that happens to have reared its head recently. > >Jim > > >>>> "Chris Apple" 6/14/03 4:00:29 PM >>> >I would be fine with it if the scope was attribute type names >and object class names. > >What is beginning to concern me is that your words imply that >it is inappropriate to address known interoperability issues >in preparation for moving to Draft Standard. It's true that it >has become a known problem because of recent work I've done. >The timing doesn't diminish the importance of discussing it >in this forum; nor does it diminish the negative impact it will >have on deploying services using the protocol in the field if >there isn't some requirement addressing this particular known >issue. > >I'm sure it's a good idea to look at the problem in a general >way. I'm also sure that most users would appreciate >tempering pure technical merit with pragmatic deployment >concerns along the way. > >The idea of addressing this particular issue with a requirement >seems to have some supporters and some folks who don't think its >a good idea. But there hasn't been a lot of discussion about >which LDAPBIS deliverable this might apply to. > >Notice that I actually stated that I didn't know where to even >suggest its inclusion at the start of this thread. Nor do I at >this time. > >That is perhaps a question that needs to be asked and answered >explicitly. So consider it asked. Where do folks think such a >requirement belongs? In one of the LDAPBIS deliverables? Or >somewhere else (and where if that's the case)? > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim >Sent: Saturday, June 14, 2003 2:16 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: RE: Attribute Name Length Bounds > > >>I wouldn't take it further than that because I don't have real world >>examples that justify doing so. > >This is exactly my concern. It seems coincidental that you are seeing >this problem, we are edititng the specification, so you see a chance >to >fix this problem. If you hadn't seen this problem at this particular >time, and the spec got progressed without this change, then I suspect >the problem would be addressed in some other way (one of those talked >about earlier in the thread). > >Given this concern, I decided to have a look at some of the other >potential 'problems' that are the same as this one. > >If, instead of this problem, you found that some servers limited DNs >to >32 characters, we might be having that conversation instead of this >one. >I don't see the difference between schema lenghts and some of the >other >sequences listed in this thread. If you want to draw the line at those >things which have IANA considerations, then we throw out sizes on >other >schema elements, and add in sizes on other things (like SASL >mechanism). >What's happenning here is a jump over to the IANA reasoning, then a >hop >over to a "similar elements" reasoning. > >To paraphase, my concern is that we're jumping on a problem just >because someone happened to experience it, without looking at it in a >general way. > >If we add this change, it sets a precedence for a class of >instructions >that was never part of the original spec. We shouldn't do this in such >an isolated way. That only makes future readers scratch their heads >wondering at the inconsistency. > >I don't understand why this can't be specified in an application >profile document. I would say that there's a class of application that >must add to (extend) the standard LDAP schema. For LDAP servers to >service this class of applications, then they should handle reasonable >schema name lengths. I don't think the LDAP spec even says that an >LDAP >server needs to allow its schema to be extended, only that it must >support certain standard schema. > >Jim > >>>> "Chris Apple" 6/13/03 9:16:48 PM >>> >My intended scope was names for schema elements such as >attribute types, object class identifiers, attribute >syntaxes, matching rules, and anything else that might >be mapped to an OID with an associated, registered name. > >Given that there are IANA considerations for the registration >of at least some of those types of schema elements, I don't >think I'm proposing anything that is outrageous or unreasonable. > >I absolutely agree that most of the examples you gave should be >handled in the context of profiling LDAPv3 DIT structure, >Operations, Service Model, etc., for specific applications. > >I'm of the opinion that this particular minimum size requirement >is of more general use than a specific application profile. I've >already given two different examples where this is an issue. >I'll repeat them here along with a third: > > - DEN > - LDAPv3 mappings of the DMTF CIM > - The Open Group's Mobility and Directory (MaD) Schema > (this will be publicly presented at the Burton Group's > Catalyst meeting in July 2003 - but basically its an > information model for directory-enabled mobility > management) > >Those are all different application contexts. Each has a need >for attribute type names that are longer than the maximum >attribute length supported by some LDAPv3-compliant implementations. > >Thus it is generally valuable to have a minimum length requirement >for at least attribute type names and object class identifiers. By >extension it also seems generally valuable to have the same sort of >minimum supported length for names of matching rules and attribute >syntaxes. > >I wouldn't take it further than that because I don't have real world >examples that justify doing so. > >However, to accommodate the 3 schema specifications above in >a general way, I do believe its justified. Specifying such >a minimum schema element name length requirement would solve an >interoperability problem related to using the protocol in the real >world in at least three different and very significant application >contexts. I think that's very much in line with the intent of >progressing to Draft Standard. If we were to waive our hands about >this and say, it means that we are interoperable if we just say >we don't understand something that's been sent to us, we haven't >actually helped the users with a relatively costly interoperability >problem. > >I don't think hand waving makes for good standards when >there's a need such as this that crosses multiple application >contexts. Especially when such a requirement can scoped so >that it doesn't cause the kind of "here a limit, there a limit, >everywhere a limit" rat hole that some of the most recent postings >implied might happen. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldapbis@OpenLDAP.org >[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim >Sent: Friday, June 13, 2003 6:43 PM >To: ietf-ldapbis@OpenLDAP.org >Subject: Re: Attribute Name Length Bounds > > >I'm still a little fuzzy on the scope of this discussion. > >The ASN.1 for attribute names is an unbounded OCTET STRING. > >This discussion seems to be saying "even though the protocol says the >size is unlimited (well, limited to a ber length), we want to be more >explicit and require protocols peers to handle some minimum size". > >What else does this discussion apply to? >- LDAPDN (how long of a DN am I required to handle?) >- RelativeLDAPDN >- AttributeValue/AssertionValue (I note that the current len >descriptor >on attributes is a 'suggested minimum') >- MatchingRuleId >- LDAPResult.diagnosticMessage >- LDAPURL (I suppose enough for a minimal scheme and delimiters is >implied) >- SASL mechanism (implied 1 to 20) >- SASL credentials >- LDAPOID >- control/extendedValue >- simple password > >AFAIK, today these all have a max-ber-len max. and no mandatory >minimum >is explicitly required to be supported. > >Jim > > From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 00:37:55 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 AAA16670 for ; Tue, 17 Jun 2003 00:37: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 h5H4awEl052578; Tue, 17 Jun 2003 04:37:03 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 h5H4aABp052540; Tue, 17 Jun 2003 04:36:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 04:36:10 +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 h5H4a8Eh052490 for ; Tue, 17 Jun 2003 04:36:08 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 ; Tue, 17 Jun 2003 14:32:04 +1000 Received: (qmail 10358 invoked from network); 17 Jun 2003 04:32:14 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 17 Jun 2003 04:32:14 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: Attribute Name Length Bounds Date: Tue, 17 Jun 2003 14:35:45 +1000 Message-ID: <002401c33489$eb9db110$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <5.2.0.9.0.20030616120358.01c5b790@127.0.0.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: Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga wrote: > At 10:24 AM 6/13/2003, Richard V Huber wrote: > >In line with Larry Bartz' email mentioning RFC3383, how about: > > > > To promote interoperability, server implementors SHOULD allow at > > least 48 characters for attribute names and schema designers SHOULD > > use attribute names which are no longer than 48 characters. > > Let's look at each imperative separately. First the latter: > Schema designers SHOULD use attribute names which are no > longer than 48 characters. > > I think that BCP64, with the additions agreed upon in [Models], > basically covers this. That is, BCP64bis will say that all > descriptors (excepting those in private name space) SHOULD be > registered and all descriptors in RFCs MUST be registered > in addition to say that descriptors longer than 48 may be > viewed as too long to register. > > While not precisely a requirement upon all schema (because > it doesn't cover private name space elements), it certainly is > significant encouragement to schema designers to avoid > descriptors longer than 48. > > If a more precise requirement is desired, I suggest this be > stated in a future "guidelines for schema developers" BCP > along with the many other requirements that likely should be > stated to schema developers. > > Now the former: > Server implementors SHOULD allow at least 48 characters for > attribute names > > Stating this in the LDAP TS is problematic as there is no > requirement (and rightly so) for server implementation to > support open-ended sets of attribute types. While certainly > servers limit the sets of attribute types they support, they do > by many means. Name length is just one factor. From a protocol > interoperability stand point, this is not problem. > > Basically, vendors have chosen to limit the suitability to > various markets. That's their choice. > > Now, what folks want is for vendors who claim to support > open-ended sets of attribute types to implement some minimum > set of requirements. Or to say it another way, folks want > an applicability statement for a restricted domain of > applicability for which servers can claim to support. That > domain being "servers which support open-ended sets of > attribute types" or maybe "general-purpose servers". > > Note here that as no server is required to be a "general-purpose > server", we are talking about requirements for a restricted > domain of applicability. > > As we've discussed in the past, those requirements are better > stating in a separate document which offers such an > applicability statement. > > It's my view what is needed is two new documents: > "Guidelines for LDAP schema developers" > "Applicability Statement for general-purpose LDAP servers" Or an "LDAP Implementation Guide". Either way, I agree that size limits and such don't belong in the LDAPbis core specifications. It's pretty clear that the core documents don't impose limits or even suggest that there may be limits. The situation we have is that some implementors have cut corners for their own convenience and been caught out. I think the main message should always be "don't impose limits". Whatever limits we might impose now are likely to eventually prove inadequate and need revising. If we are going to suggest limits of some sort then it's better if that is in an informational "guidelines" document than in the technical specification. Regards, Steven > > There is a fair amount of prior work in each of these areas. > Bruce long ago wrote an I-D on the former, and much of that > found its way in to my "Considerations for LDAP Extensions" > I-D (which covers schema as well as other kinds of extensions). > Also, the Open Group DIF is writing what are, in effect, > applicability statements for their directory certification > programs. > > I think its best for these works to continue on an individual > basis. LDAPBIS needs to remain (at least for now) focused on > delivering the "core" (technical) specification. > > Kurt > > > From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 01:06: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 BAA17040 for ; Tue, 17 Jun 2003 01:06:02 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H4swEl052889; Tue, 17 Jun 2003 04:55:03 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 h5H4ndHt052825; Tue, 17 Jun 2003 04:49:39 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 04:49: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 h5H4ncEh052815 for ; Tue, 17 Jun 2003 04:49: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 h5H4nWc6014364; Tue, 17 Jun 2003 04:49:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030616213251.01c9ae00@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 21:46:20 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: Attribute Name Length Bounds Cc: In-Reply-To: <000b01c3317d$75080a00$5f0aa8c0@D7ST2111> 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: In re-reading the top of this thread, I have a comment which are covered well in other follow-ups. At 12:28 AM 6/13/2003, Chris Apple wrote: >I have encountered a problem while attempting to extend the basic schema >of several different LDAPv3 server implementations. Specifically, some of >them place restrictions on the length of attribute names. In one case, >the attribute name length restriction is rather short, too short to >make it possible for it to distinguish between two different attribute >names with the same character string as a prefix. Are you saying that a server is treating two different short names (descriptors) as being equivalent because the first few characters of the name happen to be the same? That is, an implementation is ignoring the difference in 'x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-1' and 'x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-2'. If yes, I would consider that to be an implementation bug. I suggest you report this to the implementor. Two names should only be considered equivalent if they contain the same set of characters (ignoring case). Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 01:26:15 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 BAA17444 for ; Tue, 17 Jun 2003 01:26:15 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H5OwEl054099; Tue, 17 Jun 2003 05:25:11 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 h5H5KkgR053885; Tue, 17 Jun 2003 05:20:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 05:20:46 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H5KdEh053804; Tue, 17 Jun 2003 05:20:41 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 ([199.72.166.218]) by echt.caledonia.net; Mon, 16 Jun 2003 23:19:39 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: Attribute Name Length Bounds Date: Tue, 17 Jun 2003 01:19:19 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000601c33490$0683c5e0$5f0aa8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030616213251.01c9ae00@127.0.0.1> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 That's an accurate example of what I observed. The implementer is aware of the issue. I do see your point that this might be considered a bug. I also think that the fact that this bug can exist is a result of an ambiguity in the LDAPv3 proposed standard specs. Based on one way of reading the specs, the two attributes are actually the same from the perspective of the implementation. This is based on there not being any minimally supported length requirement. In this case, from a protocol perspective, the attributes really are the same and therefore should not be distinguishable Because the implementer chose to give precedence to the allowance of unbounded attribute types over the requirement to distinguish unique attribute type names based on their unique octet string representations. Based on another way of reading the spec, the two attributes are different because they were intended by the folks deploying the implementation in question to be different. This interpretation requires that an implementer prioritize the requirement that two attribute type names be considered equivalent iff they are represented by the same character string over the implicit allowance that attribute type names are to be unbounded with respect to length. Either interpretation is arguably correct given the state of the currently published proposed standards documents for LDAPv3. Thus implementers choosing either strategy are correct when they claim compliance with the specs. I believe the best way to address this problem is by clarifying a minimally supported length as it would remove the ambiguity. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, June 17, 2003 12:46 AM To: capple@dsi-consulting.net Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds In re-reading the top of this thread, I have a comment which are covered well in other follow-ups. At 12:28 AM 6/13/2003, Chris Apple wrote: >I have encountered a problem while attempting to extend the basic schema >of several different LDAPv3 server implementations. Specifically, some of >them place restrictions on the length of attribute names. In one case, >the attribute name length restriction is rather short, too short to >make it possible for it to distinguish between two different attribute >names with the same character string as a prefix. Are you saying that a server is treating two different short names (descriptors) as being equivalent because the first few characters of the name happen to be the same? That is, an implementation is ignoring the difference in 'x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-1' and 'x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-2'. If yes, I would consider that to be an implementation bug. I suggest you report this to the implementor. Two names should only be considered equivalent if they contain the same set of characters (ignoring case). Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 05:31:36 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 FAA04706 for ; Tue, 17 Jun 2003 05:31:35 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H9P0El066514; Tue, 17 Jun 2003 09:29: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 h5H9NBlH066333; Tue, 17 Jun 2003 09:23:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 09:23:11 +0000 Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5H9MvEh066270 for ; Tue, 17 Jun 2003 09:23:10 GMT (envelope-from hyc@highlandsun.com) Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id h5H9MNXJ025635; Tue, 17 Jun 2003 04:22:24 -0500 From: "Howard Chu" To: Cc: Subject: RE: Attribute Name Length Bounds Date: Tue, 17 Jun 2003 02:20:45 -0700 Message-ID: <000301c334b1$c7ff9f20$0e01a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000601c33490$0683c5e0$5f0aa8c0@D7ST2111> Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-ldapbis@OpenLDAP.org > [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Chris Apple > That's an accurate example of what I observed. > > The implementer is aware of the issue. > > I do see your point that this might be considered > a bug. > > I also think that the fact that this bug can exist > is a result of an ambiguity in the LDAPv3 proposed > standard specs. > Either interpretation is arguably correct given the state of > the currently published proposed standards documents for > LDAPv3. Thus implementers choosing either strategy are correct > when they claim compliance with the specs. ????? If I send an ASN.1 encoded message to a server, and the server arbitrarily truncates the end off any of the several length-encoded fields of the message while processing it, the server has corrupted the message. I don't see how you can possibly interpret this as correct behavior in the server. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 08:30: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 IAA10262 for ; Tue, 17 Jun 2003 08:30: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 h5HCP1El077079; Tue, 17 Jun 2003 12:29:26 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 h5HCKExx076740; Tue, 17 Jun 2003 12:20:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 12:20:14 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5HCKCEh076713 for ; Tue, 17 Jun 2003 12:20:13 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19SFRX-0002uV-00 for ietf-ldapbis@openldap.org; Tue, 17 Jun 2003 14:20:07 +0200 Received: from [129.240.130.19] (helo=miss.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.14) id 19SFRP-0001gC-VE for ietf-ldapbis@openldap.org; Tue, 17 Jun 2003 14:19:59 +0200 Received: from bombur.uio.no ([129.240.186.42]) by miss.uio.no with esmtp (Exim 2.12 #7) id 19SFRP-0007bS-00; Tue, 17 Jun 2003 14:19:59 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19SFRP-0002G6-00; Tue, 17 Jun 2003 14:19:59 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: [Syntaxes] Century overflow in Generalized Time Date: Tue, 17 Jun 2003 14:19:59 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: How is century overflow/underflow in Generalized Time handled? That is, - does generalizedTimeMatch say 9999123120-08 = 0000010104Z? - how does generalizedTimeOrderingMatch order 9999123120-08 vs. 2000010100Z? I suggest to leave it implementation-defined as long as the two matching rules are consistent, and maybe allow (but not require) such dates to be invalid. But if the draft does specify a rule, I think the rule should be silent wraparound (i.e. century 0 = -100 = +100), since these centuries would all look the same when expressed as a Generalized Time date. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 08:56:15 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 IAA12229 for ; Tue, 17 Jun 2003 08:56:15 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5HCt1El080578; Tue, 17 Jun 2003 12:55: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 h5HCqNMX080410; Tue, 17 Jun 2003 12:52:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 12:52:23 +0000 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5HCqMEh080385 for ; Tue, 17 Jun 2003 12:52:22 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5HCpwtd162186; Tue, 17 Jun 2003 08:51:58 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5HCpu3e033304; Tue, 17 Jun 2003 08:51:57 -0400 Subject: Re: [Syntaxes] Century overflow in Generalized Time To: Hallvard B Furuseth Cc: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Tue, 17 Jun 2003 07:51:55 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 06/17/2003 07:51:57 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: Generalized time uses a 4-digit year (YYYYMMDD...) . Wrap-around won't occur until date reach the year 10000 (another 7997 years to go). Do you still have a question in that light? John McMeeking Hallvard B Furuseth cc: Sent by: Subject: [Syntaxes] Century overflow in Generalized Time owner-ietf-ldapbis@O penLDAP.org 06/17/2003 07:19 AM How is century overflow/underflow in Generalized Time handled? That is, - does generalizedTimeMatch say 9999123120-08 = 0000010104Z? - how does generalizedTimeOrderingMatch order 9999123120-08 vs. 2000010100Z? I suggest to leave it implementation-defined as long as the two matching rules are consistent, and maybe allow (but not require) such dates to be invalid. But if the draft does specify a rule, I think the rule should be silent wraparound (i.e. century 0 = -100 = +100), since these centuries would all look the same when expressed as a Generalized Time date. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 09:26: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 JAA14380 for ; Tue, 17 Jun 2003 09:26:56 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5HDPtEh082955; Tue, 17 Jun 2003 13:25:55 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 h5HDJ0IS082206; Tue, 17 Jun 2003 13:19:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 13:19:00 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5HDIwEh082195 for ; Tue, 17 Jun 2003 13:18:59 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19SGMN-0004fS-00; Tue, 17 Jun 2003 15:18:51 +0200 Received: from [129.240.130.14] (helo=mons.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.14) id 19SGMK-0006NK-Pt; Tue, 17 Jun 2003 15:18:48 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 19SGMK-0002hE-00; Tue, 17 Jun 2003 15:18:48 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19SGMG-0002P9-00; Tue, 17 Jun 2003 15:18:44 +0200 From: Hallvard B Furuseth Message-Id: To: John McMeeking Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: [Syntaxes] Century overflow in Generalized Time In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 17 Jun 2003 15:18:44 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: John McMeeking writes: > Generalized time uses a 4-digit year (YYYYMMDD...) . Wrap-around won't > occur until date reach the year 10000 (another 7997 years to go). So? Someone may still put dates far in the future (or the past) in the directory, or compare with such dates. Come to think of it, another gray area is dates from before the Gregorian calendar was used. But that's so messy that I don't know what to suggest, except possibly that implementations _may_ be clever about that if they want to. Like not having leap years before 1581 or whatever, and implementing the 'hole' in the calendar that year where some days were skipped when comparing dates with different time zones (where the hour may overflow into the hole). -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 12:03:18 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 MAA24567 for ; Tue, 17 Jun 2003 12:03:13 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5HG16El097106; Tue, 17 Jun 2003 16:01: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 h5HFwRsF096889; Tue, 17 Jun 2003 15:58:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 15:58:27 +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 h5HFwQEh096870 for ; Tue, 17 Jun 2003 15:58:26 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 17 Jun 2003 09:58:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Tue, 17 Jun 2003 09:56:45 -0600 From: "Jim Sermersheim" To: Subject: Re: [Syntaxes] Century overflow in Generalized Time 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've always thought of these as "known limitations" >>> Hallvard B Furuseth 6/17/03 7:18:44 AM >>> John McMeeking writes: > Generalized time uses a 4-digit year (YYYYMMDD...) . Wrap-around won't > occur until date reach the year 10000 (another 7997 years to go). So? Someone may still put dates far in the future (or the past) in the directory, or compare with such dates. Come to think of it, another gray area is dates from before the Gregorian calendar was used. But that's so messy that I don't know what to suggest, except possibly that implementations _may_ be clever about that if they want to. Like not having leap years before 1581 or whatever, and implementing the 'hole' in the calendar that year where some days were skipped when comparing dates with different time zones (where the hour may overflow into the hole). -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 12:14:13 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 MAA25103 for ; Tue, 17 Jun 2003 12:14:12 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5HGD2El097626; Tue, 17 Jun 2003 16:13: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 h5HG8JiB097440; Tue, 17 Jun 2003 16:08:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 17 Jun 2003 16:08:19 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5HG8HEh097425 for ; Tue, 17 Jun 2003 16:08:17 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Tue, 17 Jun 2003 10:07:25 -0600 Reply-To: From: "Chris Apple" To: "'Howard Chu'" Cc: Subject: RE: Attribute Name Length Bounds Date: Tue, 17 Jun 2003 12:07:09 -0400 Organization: DSI-Consulting, Inc. Message-ID: <00b201c334ea$84b56d60$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <000301c334b1$c7ff9f20$0e01a8c0@CELLO> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 server wouldn't truncate it. It might say that it doesn't support the attribute if it is longer than the value it recognizes as significant for it. Or it might reply back with some error message. Even though the sending entity did have a resonable expectation that it would be recognized... And since there are not requirements in the specs about a minimally supported attribute type name length, replying to attribute types longer than a natively constrained minimum with a message indicating an unsupported attribute type is possible and could even be argued as being compliant with the specs. The point is that the possibility of interpreting the specs in this way already set us up for deployment issues related to several published schema with attribute names on the longer side of what might have been considered typical a few years ago. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Howard Chu [mailto:hyc@highlandsun.com] Sent: Tuesday, June 17, 2003 5:21 AM To: capple@dsi-consulting.net Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds > -----Original Message----- > From: owner-ietf-ldapbis@OpenLDAP.org > [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Chris Apple > That's an accurate example of what I observed. > > The implementer is aware of the issue. > > I do see your point that this might be considered > a bug. > > I also think that the fact that this bug can exist > is a result of an ambiguity in the LDAPv3 proposed > standard specs. > Either interpretation is arguably correct given the state of > the currently published proposed standards documents for > LDAPv3. Thus implementers choosing either strategy are correct > when they claim compliance with the specs. ????? If I send an ASN.1 encoded message to a server, and the server arbitrarily truncates the end off any of the several length-encoded fields of the message while processing it, the server has corrupted the message. I don't see how you can possibly interpret this as correct behavior in the server. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 22:45:14 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 WAA19976 for ; Tue, 17 Jun 2003 22:45:13 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5I2h6El019374; Wed, 18 Jun 2003 02:43:35 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 h5I2f6aV019280; Wed, 18 Jun 2003 02:41:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 02:41:06 +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 h5I2f4Eh019268 for ; Wed, 18 Jun 2003 02:41:05 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 ; Wed, 18 Jun 2003 12:37:03 +1000 Received: (qmail 6863 invoked from network); 18 Jun 2003 02:37:14 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 18 Jun 2003 02:37:14 -0000 Reply-To: From: "Steven Legg" To: "'RL 'Bob' Morgan'" , "'IETF ldapbis WG'" Subject: RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Date: Wed, 18 Jun 2003 12:40:50 +1000 Message-ID: <004401c33543$0896b000$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: 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 Some minor edits to draft-ietf-ldapbis-06.txt required: 1) The title of RFC 3383 is incorrect in the references, 2) Section 5.2.16 omits the sentence (thanks to Hallvard for picking it up), "The LDAP definition for the numericStringSubstringsMatch matching rule is:" 3) The telephoneNumberMatch and telephoneNumberSubstringsMatch need to be added to the list in the first sentence of section 5.2. The comment on telephoneNumberMatch in Appendix B, case 25 needs to be struck out. Regards, Steven > -----Original Message----- > From: owner-ietf-ldapbis@OpenLDAP.org > [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of RL 'Bob' Morgan > Sent: Wednesday, 11 June 2003 19:23 > To: IETF ldapbis WG > Subject: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep > > > > This message initiates a LDAPbis Working Group Last Call on the two > documents: > > LDAP: Syntaxes and Matching Rules > draft-ietf-ldapbis-syntaxes-06.txt > 3 June 2003 > > and > > LDAP: Internationalized String Preparation > draft-ietf-ldapbis-strprep-00.txt > 26 May 2003 > > The purpose of this WG Last Call it to ensure that the > Working Group has > achieved consensus that these documents are suitable for > publication as > IETF Standards Track RFCs. > > Please review the documents for both technical and editorial problems. > Technical issues should be discussed on this list. Editorial > issues may > be sent to the document editors. > > The Last Call period will end on Wednesday, June 25, 2003. > > Upon completion of the Last Call, the WG chair(s) will take > action based > upon the consensus of the WG. Possible actions include: > > 1) recommending to the IETF Application Area Directors that the > documents, after possible editorial or other minor changes, be > considered by the IESG for publication as Standards Track RFCs > (which generally involves an IETF-wide Last Call); or > > 2) requiring that outstanding issues be adequately addressed prior > to further action (including, possibly, another Last Call). > > Remember that it is our responsibility as Working Group members to > ensure the quality of our documents and of the Internet Standards > process. So, please read and comment! > > - RL "Bob" Morgan > LDAPbis co-chair > > > > > From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 23:26:16 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 XAA21003 for ; Tue, 17 Jun 2003 23:26:15 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5I3P6El020651; Wed, 18 Jun 2003 03:25: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 h5I3KrDi020587; Wed, 18 Jun 2003 03:20:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 03:20:53 +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 h5I3KoEh020577 for ; Wed, 18 Jun 2003 03:20:52 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 ; Wed, 18 Jun 2003 13:16:41 +1000 Received: (qmail 18097 invoked from network); 18 Jun 2003 03:16:51 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 18 Jun 2003 03:16:51 -0000 Reply-To: From: "Steven Legg" To: "'RL 'Bob' Morgan'" , "'IETF ldapbis WG'" Subject: RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Date: Wed, 18 Jun 2003 13:20:28 +1000 Message-ID: <004501c33548$91dc7ed0$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <004401c33543$0896b000$a518200a@osmium.mtwav.adacel.com.au> 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 > Some minor edits to draft-ietf-ldapbis-06.txt required: That should be draft-ietf-ldapbis-syntaxes-06.txt (doh!). Also, one more correction: 4) [ROADMAP] isn't provided in the references. It is [ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress, March 2003. Regards, Steven > > 1) The title of RFC 3383 is incorrect in the references, > > 2) Section 5.2.16 omits the sentence (thanks to Hallvard for > picking it up), > > "The LDAP definition for the numericStringSubstringsMatch matching > rule is:" > > 3) The telephoneNumberMatch and telephoneNumberSubstringsMatch need to > be added to the list in the first sentence of section 5.2. > The comment > on telephoneNumberMatch in Appendix B, case 25 needs to be > struck out. > > Regards, > Steven > > > -----Original Message----- > > From: owner-ietf-ldapbis@OpenLDAP.org > > [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of RL 'Bob' Morgan > > Sent: Wednesday, 11 June 2003 19:23 > > To: IETF ldapbis WG > > Subject: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep > > > > > > > > This message initiates a LDAPbis Working Group Last Call on the two > > documents: > > > > LDAP: Syntaxes and Matching Rules > > draft-ietf-ldapbis-syntaxes-06.txt > > 3 June 2003 > > > > and > > > > LDAP: Internationalized String Preparation > > draft-ietf-ldapbis-strprep-00.txt > > 26 May 2003 > > > > The purpose of this WG Last Call it to ensure that the > > Working Group has > > achieved consensus that these documents are suitable for > > publication as > > IETF Standards Track RFCs. > > > > Please review the documents for both technical and > editorial problems. > > Technical issues should be discussed on this list. Editorial > > issues may > > be sent to the document editors. > > > > The Last Call period will end on Wednesday, June 25, 2003. > > > > Upon completion of the Last Call, the WG chair(s) will take > > action based > > upon the consensus of the WG. Possible actions include: > > > > 1) recommending to the IETF Application Area Directors that the > > documents, after possible editorial or other minor changes, be > > considered by the IESG for publication as Standards Track RFCs > > (which generally involves an IETF-wide Last Call); or > > > > 2) requiring that outstanding issues be adequately addressed prior > > to further action (including, possibly, another Last Call). > > > > Remember that it is our responsibility as Working Group members to > > ensure the quality of our documents and of the Internet Standards > > process. So, please read and comment! > > > > - RL "Bob" Morgan > > LDAPbis co-chair > > > > > > > > > > > > From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 17 23:31:58 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 XAA21111 for ; Tue, 17 Jun 2003 23:31:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5I3V6El020881; Wed, 18 Jun 2003 03:31:08 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 h5I3UpIl020850; Wed, 18 Jun 2003 03:30:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 03:30:51 +0000 Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5I3UoEh020840 for ; Wed, 18 Jun 2003 03:30:50 GMT (envelope-from hyc@highlandsun.com) Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id h5I3UZfs014439; Tue, 17 Jun 2003 22:30:36 -0500 From: "Howard Chu" To: Cc: Subject: RE: Attribute Name Length Bounds Date: Tue, 17 Jun 2003 20:29:09 -0700 Message-ID: <005f01c33549$ce3c7820$0e01a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <00b201c334ea$84b56d60$3d00000a@D7ST2111> Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Chris Apple [mailto:capple@dsi-consulting.net] (reposting to the list...) > The server wouldn't truncate it. It might say that it > doesn't support the attribute if it is longer than > the value it recognizes as significant for it. Or it might > reply back with some error message. Even though the > sending entity did have a resonable expectation that > it would be recognized... > > And since there are not requirements in the specs > about a minimally supported attribute type name length, > replying to attribute types longer than a natively > constrained minimum with a message indicating an unsupported > attribute type is possible and could even be argued as > being compliant with the specs. > > The point is that the possibility of interpreting > the specs in this way already set us up for deployment > issues related to several published schema with attribute > names on the longer side of what might have been considered > typical a few years ago. If the server rejects overly-long names with an error message, fine, but your message implied that it silently ignored the characters comprising the excess length in the name. If it seems that the spec is ambiguous about the significance of characters in a short name, perhaps it would be sufficient to state in the the spec "all of the characters in an attribute name are significant. If an attribute name is presented that exceeds a server's implementation limits, the server MUST fail the request with an error code." (Maybe NAMING_VIOLATION or CONSTRAINT_VIOLATION...) This would satisfy the basic need without specifying arbitrary numbers for minimum acceptable lengths. > -----Original Message----- > From: Howard Chu [mailto:hyc@highlandsun.com] > > -----Original Message----- > > From: owner-ietf-ldapbis@OpenLDAP.org > > [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Chris Apple > > > That's an accurate example of what I observed. > > > > The implementer is aware of the issue. > > > > I do see your point that this might be considered > > a bug. > > > > I also think that the fact that this bug can exist > > is a result of an ambiguity in the LDAPv3 proposed > > standard specs. > > > Either interpretation is arguably correct given the state of > > the currently published proposed standards documents for > > LDAPv3. Thus implementers choosing either strategy are correct > > when they claim compliance with the specs. > > ????? If I send an ASN.1 encoded message to a server, and the server > arbitrarily truncates the end off any of the several > length-encoded fields > of the message while processing it, the server has corrupted > the message. I > don't see how you can possibly interpret this as correct > behavior in the > server. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 18 00:56: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 AAA23402 for ; Wed, 18 Jun 2003 00:56:54 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5I4t6El023918; Wed, 18 Jun 2003 04:55:30 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 h5I4s1OT023869; Wed, 18 Jun 2003 04:54:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 04:54:01 +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 h5I4rwEh023836 for ; Wed, 18 Jun 2003 04:53:59 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 ; Wed, 18 Jun 2003 14:49:48 +1000 Received: (qmail 12912 invoked from network); 18 Jun 2003 04:49:58 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 18 Jun 2003 04:49:58 -0000 Reply-To: From: "Steven Legg" To: "'Hallvard B Furuseth'" , Subject: RE: [Syntaxes] Century overflow in Generalized Time Date: Wed, 18 Jun 2003 14:53:35 +1000 Message-ID: <004801c33555$942aa1a0$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: 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, Hallvard B Furuseth wrote: > How is century overflow/underflow in Generalized Time handled? The matching semantics are described in terms of the underlying universal coordinated time represented by the character string. Underflow/overflow is meaningless in that context. Matching rule evaluation functions are not restricted to what can be physically represented in the syntax. > That is, > - does generalizedTimeMatch say 9999123120-08 = 0000010104Z? The first string represents the UTC date & time 04:00 on the 1st of January 10000. The second string represents the UTC date & time 04:00 on the 1st of January, year 0. The former is clearly greater than the latter. > - how does generalizedTimeOrderingMatch order 9999123120-08 > vs. 2000010100Z? The former is greater than the latter by the same reasoning. > > I suggest to leave it implementation-defined as long as the > two matching > rules are consistent, and maybe allow (but not require) such > dates to be > invalid. > > But if the draft does specify a rule, I think the rule should > be silent > wraparound (i.e. century 0 = -100 = +100), since these centuries would > all look the same when expressed as a Generalized Time date. GeneralizedTime has a limited range of dates it can represent. Dates outside that range cannot be represented. End of story. It is analogous to an INTEGER that is constrained to be between 0 and 9. Integer values outside the range cannot be represented, but we can still perform arithmetic on a much wider range of integer values. Regards, Steven > > -- > Hallvard > From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 18 07:59: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 HAA28761 for ; Wed, 18 Jun 2003 07:59: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 h5IBt9El041851; Wed, 18 Jun 2003 11:55:50 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 h5IBrgrG041779; Wed, 18 Jun 2003 11:53:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 11:53:42 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5IBreEh041769 for ; Wed, 18 Jun 2003 11:53:40 GMT (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28269; Wed, 18 Jun 2003 07:53:39 -0400 (EDT) Message-Id: <200306181153.HAA28269@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapbis@OpenLDAP.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapbis-protocol-14.txt Date: Wed, 18 Jun 2003 07:53:38 -0400 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. Title : LDAP: The Protocol Author(s) : J. Sermersheim Filename : draft-ietf-ldapbis-protocol-14.txt Pages : 61 Date : 2003-6-17 This document describes the protocol elements, along with their semantics and encodings, for the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapbis-protocol-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapbis-protocol-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17144612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-protocol-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-protocol-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144612.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 18 09:44:39 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 JAA06750 for ; Wed, 18 Jun 2003 09:44:38 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5IDb9Er049035; Wed, 18 Jun 2003 13:43:16 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 h5IDavra048994; Wed, 18 Jun 2003 13:36:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 13:36:57 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5IDasEh048984 for ; Wed, 18 Jun 2003 13:36:55 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19Sd7E-000129-00; Wed, 18 Jun 2003 15:36:44 +0200 Received: from [129.240.130.14] (helo=mons.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.14) id 19Sd74-0003vE-F9; Wed, 18 Jun 2003 15:36:34 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 19Sd74-0006H3-00; Wed, 18 Jun 2003 15:36:34 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19Sd72-0004kX-00; Wed, 18 Jun 2003 15:36:32 +0200 From: Hallvard B Furuseth Message-Id: To: steven.legg@adacel.com.au Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: [Syntaxes] Century overflow in Generalized Time In-Reply-To: <004801c33555$942aa1a0$a518200a@osmium.mtwav.adacel.com.au> References: <004801c33555$942aa1a0$a518200a@osmium.mtwav.adacel.com.au> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 18 Jun 2003 15:36:32 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Steven Legg writes: >> - does generalizedTimeMatch say 9999123120-08 = 0000010104Z? > > The first string represents the UTC date & time 04:00 on the 1st of > January 10000. Damn. Then we can't compare two dates by 'normalizing' them to 'Z' format and comparing the result:-( -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 18 11:24:04 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 LAA12334 for ; Wed, 18 Jun 2003 11:24: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 h5IFJDEp057966; Wed, 18 Jun 2003 15:22: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 h5IF5eB3056972; Wed, 18 Jun 2003 15:05:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 15:05:40 +0000 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5IF5YEj056925 for ; Wed, 18 Jun 2003 15:05:38 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5IF5Axr056892; Wed, 18 Jun 2003 11:05:10 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5IF53mO047014; Wed, 18 Jun 2003 11:05:04 -0400 Subject: RE: [Syntaxes] Century overflow in Generalized Time To: Hallvard B Furuseth Cc: ietf-ldapbis@OpenLDAP.org, owner-ietf-ldapbis@OpenLDAP.org, steven.legg@adacel.com.au X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Wed, 18 Jun 2003 10:04:59 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 06/18/2003 10:05:09 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 wouldn't go that far. You cannot compare dates if one of the values normalizes to an illegal value (year > 9999 or year < 0). Other dates are fine. I think it would be reasonable for a server to reject a value like 9999123120-08 as an illegal value precisely because the normalized value is illegal. If an application wants to use such a "large" time, it should ensure that normalized values stay within range -- Either don't use UTC offsets or use a smaller time 99990101000000Z. John McMeeking Hallvard B Furuseth cc: ietf-ldapbis@OpenLDAP.org Sent by: Subject: RE: [Syntaxes] Century overflow in Generalized Time owner-ietf-ldapbis@O penLDAP.org 06/18/2003 08:36 AM Steven Legg writes: >> - does generalizedTimeMatch say 9999123120-08 = 0000010104Z? > > The first string represents the UTC date & time 04:00 on the 1st of > January 10000. Damn. Then we can't compare two dates by 'normalizing' them to 'Z' format and comparing the result:-( -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 18 11:29:22 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 LAA12593 for ; Wed, 18 Jun 2003 11:29: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 h5IFPAEl058711; Wed, 18 Jun 2003 15:28:26 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 h5IFN7hx058535; Wed, 18 Jun 2003 15:23:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 15:23:07 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5IFN5Eh058516 for ; Wed, 18 Jun 2003 15:23:05 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19Sem5-00029d-00 for ietf-ldapbis@openldap.org; Wed, 18 Jun 2003 17:23:01 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.14) id 19Sem4-0007P1-7L for ietf-ldapbis@openldap.org; Wed, 18 Jun 2003 17:23:00 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19Sem3-0004jk-00 for ietf-ldapbis@openldap.org; Wed, 18 Jun 2003 17:22:59 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19Sem3-00050D-00 for ietf-ldapbis@OpenLDAP.org; Wed, 18 Jun 2003 17:22:59 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: [Syntaxes] Missing GeneralizedTime/UTCTime restrictions Date: Wed, 18 Jun 2003 17:22:59 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: Other problems with GeneralizedTime and UTCTime: Day numbers 29-31 should not be allowed in all months. Or at least, the implementation should be allowed to treat invalid dates as errors. Maybe the wording should be a bit vague about that which dates are valid, so an implementation can be allowed to either treat all years as Gregorian or to properly treat pre-someting years as Julian. (The Julian calendar had leap years every 4. year including each 100. year.) Also, there is the 'hole' in the calendar where some 10 dates are not valid at all, since they were dropped realign the Gregorian calendar with the seasons. Also, maybe the implementation of GeneralizedTime should be allowed to treat "false" leap seconds as errors. Either by checking against a table of leap seconds that have occurred so far, or with a rougher check that the leap second is at 23:59:60 UTC. (Leap seconds do not happen at other times of the day.) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 18 17:35:42 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 RAA01071 for ; Wed, 18 Jun 2003 17:35:42 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5ILVGFP079942; Wed, 18 Jun 2003 21:34:37 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 h5ILH82Q079049; Wed, 18 Jun 2003 21:17:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 18 Jun 2003 21:17:08 +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 h5ILH7Eh079039 for ; Wed, 18 Jun 2003 21:17:07 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 h5ILH6c6031015 for ; Wed, 18 Jun 2003 21:17:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030618135340.01ad52d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 18 Jun 2003 14:14:13 -0700 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Updating our milestones 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: Our milestones need to be renegotiated. In has been proposed that our current uncompleted milestones be replaced with: Aug 03 Deliver revised LDAP "core" TS to the IESG for consideration as a Proposed Standard Aug 03 Deliver revised BCP 64 I-D to IESG for consideration to the IESG as a BCP Oct 03 Submit Interoperability Report I-D Apr 04 Deliver Interoperability Report to IESG with recommendation that revised LDAP "core" TS be promoted to Draft Standard. The chairs plan to make a decision in the next few weeks on this proposal and solicits your comments on it. Please send any comments to this list (or, if necessary, directly to the chairs) by 30 June 2003. Kurt, LDAPBIS co-chair From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 19 20:27: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 UAA26572 for ; Thu, 19 Jun 2003 20:27:27 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K0PLEl099081; Fri, 20 Jun 2003 00:26:12 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 h5K0Or1p099066; Fri, 20 Jun 2003 00:24:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 00:24:53 +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 h5K0OpEh099050 for ; Fri, 20 Jun 2003 00:24:52 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 19 Jun 2003 18:24:39 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 19 Jun 2003 18:22:45 -0600 From: "Jim Sermersheim" To: Subject: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms 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 couldn't get a response on ldapext. Maybe people are ignoring it, or maybe everyone is just on a holiday. >>> "Jim Sermersheim" 6/18/03 2:56:34 PM >>> All, It appears that X.501 allows name forms to specify attributes that are not allowed by the object class definition that the name form is used for. "The RDN attribute (or attributes) need not be chosen from the list of permitted attributes of the structural object class as specified in its structural or alias object class definition." a) Does this also apply to DITContentRules? Meaning, if an attribute is not allowed on the object class definition, or allowed by the DIT Content Rule, can it be specified in the name form? b) If yes, can objects be instantiated with names that use those attributes? c) If yes, what happens when modifyDN.deleteOldRDN is set to false when renaming one of these attributes? I can't find answers to a, b, or c, in the X.500 series. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 19 20:56:30 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 UAA27244 for ; Thu, 19 Jun 2003 20:56:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K0tLEl000145; Fri, 20 Jun 2003 00:55:30 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 h5K0ruwk099930; Fri, 20 Jun 2003 00:53:56 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 00: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 h5K0rtEh099920 for ; Fri, 20 Jun 2003 00: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 h5K0rhc6043370; Fri, 20 Jun 2003 00:53:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030619173607.01afd6c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 19 Jun 2003 17:50:48 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms 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 05:22 PM 6/19/2003, Jim Sermersheim wrote: >I couldn't get a response on ldapext. Maybe people are ignoring it, or >maybe everyone is just on a holiday. > >>>> "Jim Sermersheim" 6/18/03 2:56:34 PM >>> >All, > >It appears that X.501 allows name forms to specify attributes that are >not allowed by the object class definition that the name form is used >for. Not the "structural" distinction made in the following quote. > "The RDN attribute (or attributes) need >not >be chosen from the list of permitted attributes of the structural >object >class as specified in its structural or alias object class >definition." I take this means that the RDN may be chosen from the other attributes which are allowed to appear in the entry, such as those allowed (directly or indirectly) by a DIT Content Rule. >a) Does this also apply to DITContentRules? Meaning, if an attribute >is >not allowed on the object class definition, or allowed by the DIT >Content Rule, can it be specified in the name form? No. The naming attributes must be listed from the attributes of the entry and those attributes must be allowed either the structural object class of the entry or by the controlling DIT content rule. >I can't find answers to a, b, or c, in the X.500 series. I think the answer is primarily given in X.501. From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 19 21:08:30 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 VAA27508 for ; Thu, 19 Jun 2003 21:08: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 h5K17LEl000631; Fri, 20 Jun 2003 01:07:29 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 h5K11ejP000346; Fri, 20 Jun 2003 01:01:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 01:01:40 +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 h5K11dEh000336 for ; Fri, 20 Jun 2003 01:01:39 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 h5K11Xc6043479; Fri, 20 Jun 2003 01:01:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030619175617.01b185e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 19 Jun 2003 17:58:38 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms Cc: In-Reply-To: <5.2.0.9.0.20030619173607.01afd6c0@127.0.0.1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: A few editorial corrections to my post... Kurt At 05:50 PM 6/19/2003, Kurt D. Zeilenga wrote: >>It appears that X.501 allows name forms to specify attributes that are >>not allowed by the object class definition that the name form is used >>for. > >Not the "structural" distinction made in the following quote. s/Not/Note/ >> "The RDN attribute (or attributes) need >>not >>be chosen from the list of permitted attributes of the structural >>object >>class as specified in its structural or alias object class >>definition." > >I take this means that the RDN may be chosen from the other >attributes which are allowed to appear in the entry, such as >those allowed (directly or indirectly) by a DIT Content Rule. s/means/to mean/ >>a) Does this also apply to DITContentRules? Meaning, if an attribute >>is >>not allowed on the object class definition, or allowed by the DIT >>Content Rule, can it be specified in the name form? > >No. The naming attributes must be listed from the attributes of the >entry and those attributes must be allowed either the structural >object class of the entry or by the controlling DIT content rule. s/listed/chosen/ >>I can't find answers to a, b, or c, in the X.500 series. > >I think the answer is primarily given in X.501. From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 19 21:26:19 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 VAA28118 for ; Thu, 19 Jun 2003 21:26:18 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K1PLEl001136; Fri, 20 Jun 2003 01:25: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 h5K1KqRH000947; Fri, 20 Jun 2003 01:20:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 01:20:52 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K1KmEh000917; Fri, 20 Jun 2003 01:20:49 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Jun 2003 11:20:25 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms Date: Fri, 20 Jun 2003 11:20:25 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638134ED0E@ausyms21.ca.com> Thread-Topic: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms Thread-Index: AcM2yFwGqK33iBqCTjWvvBFR7eU06gAAWejA From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , "Jim Sermersheim" Cc: X-OriginalArrivalTime: 20 Jun 2003 01:20:25.0372 (UTC) FILETIME=[208A15C0:01C336CA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5K1KnEh000918 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 Of course, the other possibility is that an auxiliary object class is expected to be included in entries named with the name form. Then, the other answers will be a) yes b) yes c) normal operation Ron -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 20 June 2003 10:59 To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms A few editorial corrections to my post... Kurt At 05:50 PM 6/19/2003, Kurt D. Zeilenga wrote: >>It appears that X.501 allows name forms to specify attributes that are >>not allowed by the object class definition that the name form is used >>for. > >Not the "structural" distinction made in the following quote. s/Not/Note/ >> "The RDN attribute (or attributes) need >>not >>be chosen from the list of permitted attributes of the structural >>object >>class as specified in its structural or alias object class >>definition." > >I take this means that the RDN may be chosen from the other >attributes which are allowed to appear in the entry, such as >those allowed (directly or indirectly) by a DIT Content Rule. s/means/to mean/ >>a) Does this also apply to DITContentRules? Meaning, if an attribute >>is >>not allowed on the object class definition, or allowed by the DIT >>Content Rule, can it be specified in the name form? > >No. The naming attributes must be listed from the attributes of the >entry and those attributes must be allowed either the structural >object class of the entry or by the controlling DIT content rule. s/listed/chosen/ >>I can't find answers to a, b, or c, in the X.500 series. > >I think the answer is primarily given in X.501. From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 19 22:51:02 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 WAA00766 for ; Thu, 19 Jun 2003 22:51:02 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K2nMEl003065; Fri, 20 Jun 2003 02:49:42 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 h5K2iA0n002928; Fri, 20 Jun 2003 02:44:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 02:44:10 +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 h5K2i9Eh002918 for ; Fri, 20 Jun 2003 02:44:09 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 h5K2i7c6044053; Fri, 20 Jun 2003 02:44:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030619192643.01b3caf0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 19 Jun 2003 19:41:11 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Another problem with abandon 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: In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 19 23:08: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 XAA01239 for ; Thu, 19 Jun 2003 23:08: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 h5K37LEl003931; Fri, 20 Jun 2003 03:07: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 h5K34i0P003873; Fri, 20 Jun 2003 03:04:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 03:04:44 +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 h5K34hEh003863 for ; Fri, 20 Jun 2003 03:04:43 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 h5K34bc6044307; Fri, 20 Jun 2003 03:04:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030619195317.01b0b5b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 19 Jun 2003 20:01:42 -0700 To: "Howard Chu" From: "Kurt D. Zeilenga" Subject: RE: Attribute Name Length Bounds Cc: In-Reply-To: <005f01c33549$ce3c7820$0e01a8c0@CELLO> References: <00b201c334ea$84b56d60$3d00000a@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:29 PM 6/17/2003, Howard Chu wrote: >> The point is that the possibility of interpreting >> the specs in this way already set us up for deployment >> issues related to several published schema with attribute >> names on the longer side of what might have been considered >> typical a few years ago. > >If the server rejects overly-long names with an error message, fine, but your >message implied that it silently ignored the characters comprising the excess >length in the name. If it seems that the spec is ambiguous about the >significance of characters in a short name, perhaps it would be sufficient to >state in the the spec "all of the characters in an attribute name are >significant. One could argue that the TS should be clarified to say: All bits of very octet of the PDU are significant unless stated otherwise. However, I think basically already says this already in X.680/X.690. But, I don't see much harm in restating this in [Protocol] (even though I think it a bit redundant and quite obvious). I, however, think we should avoid per field statements (except for the otherwise cases). >If an attribute name is presented that exceeds a server's >implementation limits, the server MUST fail the request with an error code." That would be, in general, a bad thing. Servers should treat attribute type names they don't recognize as unrecognized attribute types and many of these cases don't result in an error being returned. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 00:05:49 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 AAA02779 for ; Fri, 20 Jun 2003 00:05:48 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K41MEp005053; Fri, 20 Jun 2003 04:01:55 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 h5K401AM005031; Fri, 20 Jun 2003 04:00:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 04:00:01 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K3xvEh004974; Fri, 20 Jun 2003 03:59:58 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Jun 2003 13:59:37 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Attribute Name Length Bounds Date: Fri, 20 Jun 2003 13:59:36 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B6381364427@ausyms21.ca.com> Thread-Topic: Attribute Name Length Bounds Thread-Index: AcM22R8fHnogbB8vS3aPRTrRXdVKugABuAAg From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , "Howard Chu" Cc: X-OriginalArrivalTime: 20 Jun 2003 03:59:37.0094 (UTC) FILETIME=[5DCF3260:01C336E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5K3xwEh004975 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 This is a silly suggestiion, of course every octet in a PDU is significant. If this was an ellipses for "every octet of every attribute description in a PDU is significanr" then it is inappropriate - it is not an ASN.1 issue, it is an application issue. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 20 June 2003 13:02 To: Howard Chu Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds At 08:29 PM 6/17/2003, Howard Chu wrote: >> The point is that the possibility of interpreting >> the specs in this way already set us up for deployment >> issues related to several published schema with attribute >> names on the longer side of what might have been considered >> typical a few years ago. > >If the server rejects overly-long names with an error message, fine, but your >message implied that it silently ignored the characters comprising the excess >length in the name. If it seems that the spec is ambiguous about the >significance of characters in a short name, perhaps it would be sufficient to >state in the the spec "all of the characters in an attribute name are >significant. One could argue that the TS should be clarified to say: All bits of very octet of the PDU are significant unless stated otherwise. However, I think basically already says this already in X.680/X.690. But, I don't see much harm in restating this in [Protocol] (even though I think it a bit redundant and quite obvious). I, however, think we should avoid per field statements (except for the otherwise cases). >If an attribute name is presented that exceeds a server's >implementation limits, the server MUST fail the request with an error code." That would be, in general, a bad thing. Servers should treat attribute type names they don't recognize as unrecognized attribute types and many of these cases don't result in an error being returned. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 00:05: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 AAA02780 for ; Fri, 20 Jun 2003 00:05: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 h5K41MEr005053; Fri, 20 Jun 2003 04:01:56 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 h5K3vFN7004948; Fri, 20 Jun 2003 03:57:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 03:57:15 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K3vBEh004918; Fri, 20 Jun 2003 03:57:12 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Jun 2003 13:56:50 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Another problem with abandon Date: Fri, 20 Jun 2003 13:56:50 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B6381364417@ausyms21.ca.com> Thread-Topic: Another problem with abandon Thread-Index: AcM21qOmA1FLN/7ARdmahSfDeMGcogACNyXw From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , "Jim Sermersheim" Cc: X-OriginalArrivalTime: 20 Jun 2003 03:56:50.0518 (UTC) FILETIME=[FA85B760:01C336DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5K3vCEh004919 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 Is the URL correct? I couldn't see the quotes. I dodn't think the order of receipt of requests is related to the order of processing of the requests, and I think this is Jim's point. Naturally, this can be avoided by always processing abandons immediately. In any event, references to the connection-oriented nature of TCP are irrelevant and misleading. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 20 June 2003 12:41 To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Another problem with abandon In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 00:38: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 AAA03987 for ; Fri, 20 Jun 2003 00:38:33 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K4bMEl005813; Fri, 20 Jun 2003 04:37:40 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 h5K4ZWNP005766; Fri, 20 Jun 2003 04:35:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 04:35:32 +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 h5K4ZTEh005735; Fri, 20 Jun 2003 04:35:30 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 19 Jun 2003 22:35:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 19 Jun 2003 22:34:01 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms 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 still can't find language that says (effectively) that "the attributes of an RDN must be chosen from the set of allowable attributes for an entry". Is there such language? Jim >>> "Kurt D. Zeilenga" 6/19/03 6:58:38 PM >>> A few editorial corrections to my post... Kurt At 05:50 PM 6/19/2003, Kurt D. Zeilenga wrote: >>It appears that X.501 allows name forms to specify attributes that are >>not allowed by the object class definition that the name form is used >>for. > >Not the "structural" distinction made in the following quote. s/Not/Note/ >> "The RDN attribute (or attributes) need >>not >>be chosen from the list of permitted attributes of the structural >>object >>class as specified in its structural or alias object class >>definition." > >I take this means that the RDN may be chosen from the other >attributes which are allowed to appear in the entry, such as >those allowed (directly or indirectly) by a DIT Content Rule. s/means/to mean/ >>a) Does this also apply to DITContentRules? Meaning, if an attribute >>is >>not allowed on the object class definition, or allowed by the DIT >>Content Rule, can it be specified in the name form? > >No. The naming attributes must be listed from the attributes of the >entry and those attributes must be allowed either the structural >object class of the entry or by the controlling DIT content rule. s/listed/chosen/ >>I can't find answers to a, b, or c, in the X.500 series. > >I think the answer is primarily given in X.501. From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 00:44:22 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 AAA04092 for ; Fri, 20 Jun 2003 00:44:21 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K4hMEp006048; Fri, 20 Jun 2003 04:43: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 h5K4fJRH005985; Fri, 20 Jun 2003 04:41:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 04:41:19 +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 h5K4fGEh005954; Fri, 20 Jun 2003 04:41:16 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 19 Jun 2003 22:41:14 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 19 Jun 2003 22:39:38 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: Another problem with abandon 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 second the proposal to remove the "If the LDAP session is operating over a connection-oriented transport such as TCP,". Not only does it cause the problem Jurt raises, it also leaves one wondering just how search responses are to be returned over a non-connection-oriented transport. It makes one wonder if different protocol elements need to be defined for when running over non-connection-oriented transports. >>> "Kurt D. Zeilenga" 6/19/03 8:41:11 PM >>> In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 00:44:22 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 AAA04093 for ; Fri, 20 Jun 2003 00:44:21 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K4hMEr006048; Fri, 20 Jun 2003 04:43:25 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 h5K4h6YL006035; Fri, 20 Jun 2003 04:43:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 04:43:06 +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 h5K4h5Eh006025 for ; Fri, 20 Jun 2003 04:43:05 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 h5K4gnc6045169; Fri, 20 Jun 2003 04:42:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030619211213.01b10e80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 19 Jun 2003 21:39:54 -0700 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: Another problem with abandon Cc: "Jim Sermersheim" , In-Reply-To: <1395B4B334FCC143B36AF788E68B6381364417@ausyms21.ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:56 PM 6/19/2003, Ramsay, Ron wrote: >Is the URL correct? The URL is for the top of the thread. >I couldn't see the quotes. They are actually from: http://www.openldap.org/lists/ietf-ldapbis/200211/msg00010.html >I dodn't think the order of receipt of requests is related to the order of processing of the requests, and I think this is Jim's point. Naturally, this can be avoided by always processing abandons immediately. Or by tracking the order in which operations were received so that the abandon request will act upon the appropriate operation. Or by a number of other approaches. Basically, the semantics of the abandon are tied to the ordering of requests from the client. The abandon operation requests that a previously sent operation be abandoned. It would be inappropriate to apply the abandon to subsequently requested operations. >In any event, references to the connection-oriented nature of TCP are irrelevant and misleading. >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Friday, 20 June 2003 12:41 >To: Jim Sermersheim >Cc: ietf-ldapbis@OpenLDAP.org >Subject: Re: Another problem with abandon > > >In an attempt to bring closure to an other thread... > http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html > >As John McMeeking pointed out, this isn't really a protocol >issue as LDAP assumes it is mapped onto a connection-oriented >transport which ensures in-order delivery of PDUs. > This protocol is designed to run over connection-oriented, reliable > transports, with all 8 bits in an octet being significant in the data > stream. > >If the server chooses to use an multi-threaded approach, then it >needs to maintain appropriate state information to ensure the >appropriate behavior is provided. > >I do, however, think the following statement: > If the LDAP session is operating over a connection-oriented transport > such as TCP, the server will return to the client a sequence of > responses in separate LDAP messages. > >needs clarification (s/If ... TCP//) as it implies the protocol >is designed to run over non-connection-oriented transports such >as UDP. > >(This is not to say that LDAP cannot be mapped onto UDP, just that >this is not discussed in the technical specification.) > >Kurt > > >At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >>Due to abandon not having a response, I've found another little problem with message ID re-use. >> >>The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). >> >>Here's the problem: >> >>MessageID 1 is used for an operation, the server is processing this op. >>Abandon is sent for MessageID 1 >>A response is sent for operation 1 >>The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >>This next message reaches the server, and is processed before the previously sent abandon request. >>The previous abandon request ends up abandoning the second operation. >> >>I'm not sure yet how to fix this. If we say that: >>- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >>- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. >> >>I sure wish abandon had a resonse... >> >>Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 00:56:25 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 AAA04565 for ; Fri, 20 Jun 2003 00:56:25 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K4tMEl006377; Fri, 20 Jun 2003 04:55:35 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 h5K4po5G006289; Fri, 20 Jun 2003 04:51:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 04:51:50 +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 h5K4pmEh006279 for ; Fri, 20 Jun 2003 04:51:48 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 h5K4plc6045234; Fri, 20 Jun 2003 04:51:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030619214237.01b51bf8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 19 Jun 2003 21:48:51 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms 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:34 PM 6/19/2003, Jim Sermersheim wrote: >I still can't find language that says (effectively) that "the attributes >of an RDN must be chosen from the set of allowable attributes for an >entry". Is there such language? X.501(93): distinguished value: An attribute value in an entry which has been designated to appear in the relative distinguished name of the entry. relative distinguished name (RDN): A set of one or more attribute type and value pairs, each of which matches a distinct distinguished attribute value of the entry. RFC 2251 said: Entries have names: one or more attribute values from the entry form its relative distinguished name (RDN), ... Which attribute values may appear in an entry is controlled by user (and/or system) schema. Kurt >Jim > >>>> "Kurt D. Zeilenga" 6/19/03 6:58:38 PM >>> >A few editorial corrections to my post... > Kurt > >At 05:50 PM 6/19/2003, Kurt D. Zeilenga wrote: >>>It appears that X.501 allows name forms to specify attributes that >are >>>not allowed by the object class definition that the name form is >used >>>for. >> >>Not the "structural" distinction made in the following quote. > >s/Not/Note/ > >>> "The RDN attribute (or attributes) need >>>not >>>be chosen from the list of permitted attributes of the structural >>>object >>>class as specified in its structural or alias object class >>>definition." >> >>I take this means that the RDN may be chosen from the other >>attributes which are allowed to appear in the entry, such as >>those allowed (directly or indirectly) by a DIT Content Rule. > >s/means/to mean/ > >>>a) Does this also apply to DITContentRules? Meaning, if an attribute >>>is >>>not allowed on the object class definition, or allowed by the DIT >>>Content Rule, can it be specified in the name form? >> >>No. The naming attributes must be listed from the attributes of the >>entry and those attributes must be allowed either the structural >>object class of the entry or by the controlling DIT content rule. > >s/listed/chosen/ > > >>>I can't find answers to a, b, or c, in the X.500 series. >> >>I think the answer is primarily given in X.501. From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 01:24:16 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 BAA05270 for ; Fri, 20 Jun 2003 01:24:16 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K5JMEt007271; Fri, 20 Jun 2003 05:23:15 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 h5K5D9Pu006888; Fri, 20 Jun 2003 05:13:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 05:13:09 +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 h5K5D6Eh006853; Fri, 20 Jun 2003 05:13:06 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 19 Jun 2003 23:12:46 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 19 Jun 2003 23:11:12 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms 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, that's clear enough--I burried myself in the schema sections and forgot to come up for air. >>> "Kurt D. Zeilenga" 6/19/03 10:48:51 PM >>> At 09:34 PM 6/19/2003, Jim Sermersheim wrote: >I still can't find language that says (effectively) that "the attributes >of an RDN must be chosen from the set of allowable attributes for an >entry". Is there such language? X.501(93): distinguished value: An attribute value in an entry which has been designated to appear in the relative distinguished name of the entry. relative distinguished name (RDN): A set of one or more attribute type and value pairs, each of which matches a distinct distinguished attribute value of the entry. RFC 2251 said: Entries have names: one or more attribute values from the entry form its relative distinguished name (RDN), ... Which attribute values may appear in an entry is controlled by user (and/or system) schema. Kurt >Jim > >>>> "Kurt D. Zeilenga" 6/19/03 6:58:38 PM >>> >A few editorial corrections to my post... > Kurt > >At 05:50 PM 6/19/2003, Kurt D. Zeilenga wrote: >>>It appears that X.501 allows name forms to specify attributes that >are >>>not allowed by the object class definition that the name form is >used >>>for. >> >>Not the "structural" distinction made in the following quote. > >s/Not/Note/ > >>> "The RDN attribute (or attributes) need >>>not >>>be chosen from the list of permitted attributes of the structural >>>object >>>class as specified in its structural or alias object class >>>definition." >> >>I take this means that the RDN may be chosen from the other >>attributes which are allowed to appear in the entry, such as >>those allowed (directly or indirectly) by a DIT Content Rule. > >s/means/to mean/ > >>>a) Does this also apply to DITContentRules? Meaning, if an attribute >>>is >>>not allowed on the object class definition, or allowed by the DIT >>>Content Rule, can it be specified in the name form? >> >>No. The naming attributes must be listed from the attributes of the >>entry and those attributes must be allowed either the structural >>object class of the entry or by the controlling DIT content rule. > >s/listed/chosen/ > > >>>I can't find answers to a, b, or c, in the X.500 series. >> >>I think the answer is primarily given in X.501. From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 01:24:17 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 BAA05275 for ; Fri, 20 Jun 2003 01:24:16 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K5JMEr007271; Fri, 20 Jun 2003 05:23:15 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 h5K5Hil5007122; Fri, 20 Jun 2003 05:17:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 05:17:44 +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 h5K5HfEh007086; Fri, 20 Jun 2003 05:17:41 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 19 Jun 2003 23:17:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 19 Jun 2003 23:16:12 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: Another problem with abandon 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 Here's my proposal for this (it's a little wordy, I may try to fix that): There is no response defined in the Abandon operation. Upon reciept of an AbandonRequest, the server MAY abandon the operation identified by the MessageID. Operation responses are not sent for successfully abandoned operations, thus a client SHOULD NOT use the Abandon operation when it needs an indication of whether the operation was abandoned. For example, if a client performs an update operation (Add, Modify, or ModifyDN), and it needs to know whether the directory has changed due to the operation, it should not use the Abandon operation to cancel the update operation. Clients can ensure that an operation has been successfully abandoned by performing a subsequent bind operation, and this method only works when the underlying transport guaranties ordering of messages. Jim >>> "Kurt D. Zeilenga" 6/19/03 8:41:11 PM >>> In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 01:24:17 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 BAA05279 for ; Fri, 20 Jun 2003 01:24:17 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K5JMEv007271; Fri, 20 Jun 2003 05:23:16 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 h5K5BBRw006797; Fri, 20 Jun 2003 05:11:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 05:11:11 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K5B7Eh006763; Fri, 20 Jun 2003 05:11:07 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Jun 2003 15:10:45 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Another problem with abandon Date: Fri, 20 Jun 2003 15:10:45 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B6381364579@ausyms21.ca.com> Thread-Topic: Another problem with abandon Thread-Index: AcM25oYYb6csAvXrRs2kRnpppP/nFAAA5bBA From: "Ramsay, Ron" To: "Jim Sermersheim" , Cc: X-OriginalArrivalTime: 20 Jun 2003 05:10:45.0852 (UTC) FILETIME=[4E2FF9C0:01C336EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5K5B8Eh006768 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 There were two attempts to define connectionless LDAP. I think they were both unsuccessful. Yes, there are problems. Please don't go there! -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 20 June 2003 14:40 To: Kurt@OpenLDAP.org Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Another problem with abandon I second the proposal to remove the "If the LDAP session is operating over a connection-oriented transport such as TCP,". Not only does it cause the problem Jurt raises, it also leaves one wondering just how search responses are to be returned over a non-connection-oriented transport. It makes one wonder if different protocol elements need to be defined for when running over non-connection-oriented transports. >>> "Kurt D. Zeilenga" 6/19/03 8:41:11 PM >>> In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 01:38:21 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 BAA05946 for ; Fri, 20 Jun 2003 01:38: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 h5K5bMEl008227; Fri, 20 Jun 2003 05:37: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 h5K5ac4D008209; Fri, 20 Jun 2003 05:36:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 05:36:38 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K5aYEh008179; Fri, 20 Jun 2003 05:36:35 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Jun 2003 15:36:14 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Another problem with abandon Date: Fri, 20 Jun 2003 15:36:14 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B63813645F7@ausyms21.ca.com> Thread-Topic: Another problem with abandon Thread-Index: AcM27BWogD9PCRg9Qcqu1K//Ey56GQAAYpZw From: "Ramsay, Ron" To: "Jim Sermersheim" , Cc: X-OriginalArrivalTime: 20 Jun 2003 05:36:14.0337 (UTC) FILETIME=[DD3C4710:01C336ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5K5aZEh008180 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 You went off the rails at the end! A bind operation does not signify a successful abandon. The only way to ensure an update operation was abandoned is to perform a search. It seems unnecessary to know whether a query operation was successfully abandoned. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 20 June 2003 15:16 To: Kurt@OpenLDAP.org Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Another problem with abandon Here's my proposal for this (it's a little wordy, I may try to fix that): There is no response defined in the Abandon operation. Upon reciept of an AbandonRequest, the server MAY abandon the operation identified by the MessageID. Operation responses are not sent for successfully abandoned operations, thus a client SHOULD NOT use the Abandon operation when it needs an indication of whether the operation was abandoned. For example, if a client performs an update operation (Add, Modify, or ModifyDN), and it needs to know whether the directory has changed due to the operation, it should not use the Abandon operation to cancel the update operation. Clients can ensure that an operation has been successfully abandoned by performing a subsequent bind operation, and this method only works when the underlying transport guaranties ordering of messages. Jim >>> "Kurt D. Zeilenga" 6/19/03 8:41:11 PM >>> In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 02:08: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 CAA15436 for ; Fri, 20 Jun 2003 02:08:56 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K67NEl010969; Fri, 20 Jun 2003 06:07:36 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 h5K651EX010773; Fri, 20 Jun 2003 06:05:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 06:05:01 +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 h5K64vEh010736; Fri, 20 Jun 2003 06:04:58 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Jun 2003 00:04:57 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 20 Jun 2003 00:03:20 -0600 From: "Jim Sermersheim" To: , Cc: Subject: RE: Another problem with abandon 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 A client can have knowledge of whether the update was abandoned by abandoning the update, then rebinding (or just rebinding). If I get a response to the update op before I get a bind response, then the update op result tells me what happened. If I don't get a response to the update op before I get a bind response, then the update was abandoned. This is because the server must either abandon outstanding ops or wait for them to complete before a bind can be serviced. This probably is not clear in that last sentence below. I will break it up and clarify. Jim >>> "Ramsay, Ron" 6/19/03 11:36:14 PM >>> You went off the rails at the end! A bind operation does not signify a successful abandon. The only way to ensure an update operation was abandoned is to perform a search. It seems unnecessary to know whether a query operation was successfully abandoned. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 20 June 2003 15:16 To: Kurt@OpenLDAP.org Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Another problem with abandon Here's my proposal for this (it's a little wordy, I may try to fix that): There is no response defined in the Abandon operation. Upon reciept of an AbandonRequest, the server MAY abandon the operation identified by the MessageID. Operation responses are not sent for successfully abandoned operations, thus a client SHOULD NOT use the Abandon operation when it needs an indication of whether the operation was abandoned. For example, if a client performs an update operation (Add, Modify, or ModifyDN), and it needs to know whether the directory has changed due to the operation, it should not use the Abandon operation to cancel the update operation. Clients can ensure that an operation has been successfully abandoned by performing a subsequent bind operation, and this method only works when the underlying transport guaranties ordering of messages. Jim >>> "Kurt D. Zeilenga" 6/19/03 8:41:11 PM >>> In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 02:12:29 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 BAA05271 for ; Fri, 20 Jun 2003 01:24:16 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K5JMEx007271; Fri, 20 Jun 2003 05:23:16 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 h5K57xWU006701; Fri, 20 Jun 2003 05:07:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 05:07:59 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K57qEh006668; Fri, 20 Jun 2003 05:07:56 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Jun 2003 15:07:44 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms Date: Fri, 20 Jun 2003 15:07:44 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638136456D@ausyms21.ca.com> Thread-Topic: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms Thread-Index: AcM25blrkQpROReJSOKyRm1282ILZgAA6+0w From: "Ramsay, Ron" To: "Jim Sermersheim" , Cc: X-OriginalArrivalTime: 20 Jun 2003 05:07:44.0838 (UTC) FILETIME=[E24B6E60:01C336E9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5K57uEh006672 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 Does it need to be stated? Doesn't the schema section say something like this? That is, just because it is talking about name forms, doesn't mean that the normal rules do not apply. The attributes of an RDN actually form part of the entry. To turn it around, an entry contains attributes; attributes have values; some values are distinguished. That is, the concept of RDN is subordinate to the concept of entry, not orthogonal. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 20 June 2003 14:34 To: Kurt@OpenLDAP.org Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Fwd: [ldapext] modifyDN.deleteOldRDN and name forms I still can't find language that says (effectively) that "the attributes of an RDN must be chosen from the set of allowable attributes for an entry". Is there such language? Jim >>> "Kurt D. Zeilenga" 6/19/03 6:58:38 PM >>> A few editorial corrections to my post... Kurt At 05:50 PM 6/19/2003, Kurt D. Zeilenga wrote: >>It appears that X.501 allows name forms to specify attributes that are >>not allowed by the object class definition that the name form is used >>for. > >Not the "structural" distinction made in the following quote. s/Not/Note/ >> "The RDN attribute (or attributes) need >>not >>be chosen from the list of permitted attributes of the structural >>object >>class as specified in its structural or alias object class >>definition." > >I take this means that the RDN may be chosen from the other >attributes which are allowed to appear in the entry, such as >those allowed (directly or indirectly) by a DIT Content Rule. s/means/to mean/ >>a) Does this also apply to DITContentRules? Meaning, if an attribute >>is >>not allowed on the object class definition, or allowed by the DIT >>Content Rule, can it be specified in the name form? > >No. The naming attributes must be listed from the attributes of the >entry and those attributes must be allowed either the structural >object class of the entry or by the controlling DIT content rule. s/listed/chosen/ >>I can't find answers to a, b, or c, in the X.500 series. > >I think the answer is primarily given in X.501. From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 04:15:19 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 EAA20874 for ; Fri, 20 Jun 2003 04:15:18 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K8DNEl019415; Fri, 20 Jun 2003 08:14:03 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 h5K89nOf019225; Fri, 20 Jun 2003 08:09:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 08:09:49 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5K89jEh019189; Fri, 20 Jun 2003 08:09:45 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Jun 2003 18:09:27 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Another problem with abandon Date: Fri, 20 Jun 2003 18:09:27 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B6381364826@ausyms21.ca.com> Thread-Topic: Another problem with abandon Thread-Index: AcM28efSjBL67tuuS3ibRdYq27dlYAAECcJw From: "Ramsay, Ron" To: "Jim Sermersheim" , Cc: X-OriginalArrivalTime: 20 Jun 2003 08:09:27.0766 (UTC) FILETIME=[44F23760:01C33703] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5K89kEh019196 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 Surely the rebind will abandon ALL outstanding oerations. Doesn't RFC 2251 recommend a search? In any case, I don't believe this is an appropriate use of the bind service. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 20 June 2003 16:03 To: Ramsay, Ron; Kurt@OpenLDAP.org Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Another problem with abandon A client can have knowledge of whether the update was abandoned by abandoning the update, then rebinding (or just rebinding). If I get a response to the update op before I get a bind response, then the update op result tells me what happened. If I don't get a response to the update op before I get a bind response, then the update was abandoned. This is because the server must either abandon outstanding ops or wait for them to complete before a bind can be serviced. This probably is not clear in that last sentence below. I will break it up and clarify. Jim >>> "Ramsay, Ron" 6/19/03 11:36:14 PM >>> You went off the rails at the end! A bind operation does not signify a successful abandon. The only way to ensure an update operation was abandoned is to perform a search. It seems unnecessary to know whether a query operation was successfully abandoned. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 20 June 2003 15:16 To: Kurt@OpenLDAP.org Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Another problem with abandon Here's my proposal for this (it's a little wordy, I may try to fix that): There is no response defined in the Abandon operation. Upon reciept of an AbandonRequest, the server MAY abandon the operation identified by the MessageID. Operation responses are not sent for successfully abandoned operations, thus a client SHOULD NOT use the Abandon operation when it needs an indication of whether the operation was abandoned. For example, if a client performs an update operation (Add, Modify, or ModifyDN), and it needs to know whether the directory has changed due to the operation, it should not use the Abandon operation to cancel the update operation. Clients can ensure that an operation has been successfully abandoned by performing a subsequent bind operation, and this method only works when the underlying transport guaranties ordering of messages. Jim >>> "Kurt D. Zeilenga" 6/19/03 8:41:11 PM >>> In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 10:23: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 KAA08276 for ; Fri, 20 Jun 2003 10:23: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 h5KEJQEl062479; Fri, 20 Jun 2003 14:22:10 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 h5KEIVZT062446; Fri, 20 Jun 2003 14:18:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 14:18:31 +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 h5KEIREh062405; Fri, 20 Jun 2003 14:18:27 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Jun 2003 08:18:07 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 20 Jun 2003 08:16:43 -0600 From: "Jim Sermersheim" To: , Cc: Subject: RE: Another problem with abandon 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 No, RFC 2251 does not recommend a search, for at least two reasons: 1) Either the update or the search operation may be chained to a different server(s), thus giving a false positive, or false negative. 2) Another DUA, or DSA may have changed the entry between the update and the search. I didn't want to suggest that clients go around using re-bind in order to abandon operations. I just wanted to point out that it's the only mechanism available to actually know what happened. If I could, I'd make the suggestion that clients use the cancel operation and forget about abandon. I can remove the whole bit about re-bind if people think it's not useful. Jim >>> "Ramsay, Ron" 6/20/03 2:09:27 AM >>> Surely the rebind will abandon ALL outstanding oerations. Doesn't RFC 2251 recommend a search? In any case, I don't believe this is an appropriate use of the bind service. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 20 June 2003 16:03 To: Ramsay, Ron; Kurt@OpenLDAP.org Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Another problem with abandon A client can have knowledge of whether the update was abandoned by abandoning the update, then rebinding (or just rebinding). If I get a response to the update op before I get a bind response, then the update op result tells me what happened. If I don't get a response to the update op before I get a bind response, then the update was abandoned. This is because the server must either abandon outstanding ops or wait for them to complete before a bind can be serviced. This probably is not clear in that last sentence below. I will break it up and clarify. Jim >>> "Ramsay, Ron" 6/19/03 11:36:14 PM >>> You went off the rails at the end! A bind operation does not signify a successful abandon. The only way to ensure an update operation was abandoned is to perform a search. It seems unnecessary to know whether a query operation was successfully abandoned. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 20 June 2003 15:16 To: Kurt@OpenLDAP.org Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Another problem with abandon Here's my proposal for this (it's a little wordy, I may try to fix that): There is no response defined in the Abandon operation. Upon reciept of an AbandonRequest, the server MAY abandon the operation identified by the MessageID. Operation responses are not sent for successfully abandoned operations, thus a client SHOULD NOT use the Abandon operation when it needs an indication of whether the operation was abandoned. For example, if a client performs an update operation (Add, Modify, or ModifyDN), and it needs to know whether the directory has changed due to the operation, it should not use the Abandon operation to cancel the update operation. Clients can ensure that an operation has been successfully abandoned by performing a subsequent bind operation, and this method only works when the underlying transport guaranties ordering of messages. Jim >>> "Kurt D. Zeilenga" 6/19/03 8:41:11 PM >>> In an attempt to bring closure to an other thread... http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html As John McMeeking pointed out, this isn't really a protocol issue as LDAP assumes it is mapped onto a connection-oriented transport which ensures in-order delivery of PDUs. This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. If the server chooses to use an multi-threaded approach, then it needs to maintain appropriate state information to ensure the appropriate behavior is provided. I do, however, think the following statement: If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. needs clarification (s/If ... TCP//) as it implies the protocol is designed to run over non-connection-oriented transports such as UDP. (This is not to say that LDAP cannot be mapped onto UDP, just that this is not discussed in the technical specification.) Kurt At 11:31 AM 11/1/2002, Jim Sermersheim wrote: >Due to abandon not having a response, I've found another little problem with message ID re-use. > >The current protocol draft says that a client can re-use a messageID as long as it can be determined that the operation associated with that messageID has completed (this can be determined either by seeing a response to the earlier message, or completing a successful bind). > >Here's the problem: > >MessageID 1 is used for an operation, the server is processing this op. >Abandon is sent for MessageID 1 >A response is sent for operation 1 >The client, seing that operation 1 has returned a response, uses messageID 1 again for another operation >This next message reaches the server, and is processed before the previously sent abandon request. >The previous abandon request ends up abandoning the second operation. > >I'm not sure yet how to fix this. If we say that: >- a messageID cannot be reused until a subsequent bind, we limit the number of messages between binds to maxInt. >- a messageID of an abandoned operation cannot be reused, it limits the number of abandoned messages between binds to maxInt. > >I sure wish abandon had a resonse... > >Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 10:50:42 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 KAA09659 for ; Fri, 20 Jun 2003 10:50:41 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5KEnPEn064103; Fri, 20 Jun 2003 14:49: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 h5KEjQta063845; Fri, 20 Jun 2003 14:45:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 14:45:26 +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 h5KEjOEh063833 for ; Fri, 20 Jun 2003 14:45:24 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 h5KEjHc6049171; Fri, 20 Jun 2003 14:45:17 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030620073436.01b2ba80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 20 Jun 2003 07:42:22 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Another problem with abandon 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 10:16 PM 6/19/2003, Jim Sermersheim wrote: >There is no response defined in the Abandon operation. Upon reciept of >an AbandonRequest, the server MAY abandon the operation identified by >the MessageID. Operation responses are not sent for successfully >abandoned operations, thus a client SHOULD NOT use the Abandon operation >when it needs an indication of whether the operation was abandoned. For >example, if a client performs an update operation (Add, Modify, or >ModifyDN), and it needs to know whether the directory has changed due to >the operation, it should not use the Abandon operation to cancel the >update operation. Clients can ensure that an operation has been >successfully abandoned by performing a subsequent bind operation, and >this method only works when the underlying transport guaranties ordering >of messages. I suggest dropping the last sentence as it implies the client can get an indication of success of the abandon operation by issuing a subsequent bind operation. Also, change the "MAY" to a "may". MAY implies that a server can elect to implement the abandon operation while may implies the server which implements the abandon operation can choose when to honor the request. Likely, the "SHOULD NOT use" does not appear to be an implementation imperative and likely should be a "should not". And, you left "Delete" out of list of update operations. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 20 10:56:24 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 KAA10326 for ; Fri, 20 Jun 2003 10:56:23 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5KEtPEl064509; Fri, 20 Jun 2003 14:55: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 h5KEpK71064256; Fri, 20 Jun 2003 14:51:20 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 20 Jun 2003 14:51:20 +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 h5KEpIEh064192; Fri, 20 Jun 2003 14:51:18 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Jun 2003 08:50:57 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 20 Jun 2003 08:49:18 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: Another problem with abandon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>>> "Kurt D. Zeilenga" 6/20/03 8:42:22 AM >>> >At 10:16 PM 6/19/2003, Jim Sermersheim wrote: >>There is no response defined in the Abandon operation. Upon reciept of >>an AbandonRequest, the server MAY abandon the operation identified by >>the MessageID. Operation responses are not sent for successfully >>abandoned operations, thus a client SHOULD NOT use the Abandon operation >>when it needs an indication of whether the operation was abandoned. For >>example, if a client performs an update operation (Add, Modify, or >>ModifyDN), and it needs to know whether the directory has changed due to >>the operation, it should not use the Abandon operation to cancel the >>update operation. Clients can ensure that an operation has been >>successfully abandoned by performing a subsequent bind operation, and >>this method only works when the underlying transport guaranties ordering >>of messages. > >I suggest dropping the last sentence as it implies the client can >get an indication of success of the abandon operation by issuing >a subsequent bind operation. Well, it can. I can crop it anyway as no one seems to find it useful. >Also, change the "MAY" to a "may". MAY implies that a server >can elect to implement the abandon operation while may >implies the server which implements the abandon operation can >choose when to honor the request. yes >Likely, the "SHOULD NOT use" does not appear to be an implementation >imperative and likely should be a "should not". > >And, you left "Delete" out of list of update operations. yes and yes. Jim >Kurt From owner-ietf-ldapbis@OpenLDAP.org Sun Jun 22 22:13:44 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 WAA24030 for ; Sun, 22 Jun 2003 22:13:27 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5N1hakf028470; Mon, 23 Jun 2003 01:45:12 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 h5N1gkr5028461; Mon, 23 Jun 2003 01:42:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 23 Jun 2003 01:42:46 +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 h5N1ghkb028451 for ; Mon, 23 Jun 2003 01:42:44 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 ; Mon, 23 Jun 2003 11:39:01 +1000 Received: (qmail 3769 invoked from network); 23 Jun 2003 01:41:59 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 23 Jun 2003 01:41:59 -0000 Reply-To: From: "Steven Legg" To: , Subject: FW: I-D ACTION:draft-legg-ldap-binary-00.txt Date: Mon, 23 Jun 2003 11:42:15 +1000 Message-ID: <00c801c33928$adcd16c0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C9_01C3397C.7F7926C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-MS-TNEF-Correlator: 00000000959925F7459DD311B46500E02915D5DB04B34700 Importance: Normal 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_00C9_01C3397C.7F7926C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, For the benefit of PKI LDAP clients (among other things), this is the I-D that reintroduces the ";binary" attribute option that has been removed from the LDAPbis core documents for the LDAPv3 draft standard. Regards, Steven -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, 20 June 2003 21:34 To: IETF-Announce: ; Subject: I-D ACTION:draft-legg-ldap-binary-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP: The Binary Encoding Option Author(s) : S. Legg Filename : draft-legg-ldap-binary-00.txt Pages : 9 Date : 2003-6-19 Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e. data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, which can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-ldap-binary-00.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-legg-ldap-binary-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-legg-ldap-binary-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [[ Unknown attachment : 273 in winmail.dat ]][[ Unknown attachment : 274 in winmail.dat ]] ------=_NextPart_000_00C9_01C3397C.7F7926C0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhEBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEIAAUABAAAAAAAAAAAAAEJAAQAAgAAAAAA AAABBoADAA4AAADTBwYAFwALACoAAAABAC0BAQOQBgAoDAAALAAAAAsAAgABAAAACwAjAAAAAAAD ACYAAAAAAAsAKQAAAAAACwArAAAAAAADAC4AAAAAAAMANgAAAAAAHgBNAAEAAAABAAAAAAAAAB4A cAABAAAAKQAAAEktRCBBQ1RJT046ZHJhZnQtbGVnZy1sZGFwLWJpbmFyeS0wMC50eHQAAAAAAgFx AAEAAAAWAAAAAcM5KKzNARBqmqUIEdehOwCAyE5p9QAACwAXDAAAAAACAR0MAQAAAB8AAABTTVRQ OlNURVZFTi5MRUdHQEFEQUNFTC5DT00uQVUAAAsAAQ4AAAAAQAAGDgDkb6MoOcMBAgEKDgEAAAAY AAAAAAAAAJWZJfdFndMRtGUA4CkV1dvCgAAAAwAUDgEAAAALAB8OAQAAAAMABhBaCQI3AwAHEAsJ AAAeAAgQAQAAAGUAAABGT0xLUyxGT1JUSEVCRU5FRklUT0ZQS0lMREFQQ0xJRU5UUyhBTU9OR09U SEVSVEhJTkdTKSxUSElTSVNUSEVJLURUSEFUUkVJTlRST0RVQ0VTVEhFIjtCSU5BUlkiQVRUUklC AAAAAAIBCRABAAAAggcAAH4HAADTDQAATFpGdXPbNg8DAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/ CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjv Cfe2OxgfDjA1ESIMYGMAULMLCQFkMzYWUAunYwEwiwrjCoBGBvBrcywdNIMdNgXAdGhlIGIJ8AUB EGkFQG9mIFBLAEkgTERBUCBjTmwIkAIwBCAoYQRgbh5nH6Ae8R7SC4Bncyk+LCGyBCAEAB00HvJJ LbpEHuFhBUAYIAuAdANgjmQa0AeRHvIiO2ILgDEKwHkiICPAJDBpYu51DrAfoAUwaQIgI5QT4L8E IB8wCfAdNBggBGB2CYD+IANSHuMgIiUgBCAFoR8Q8GRvY3UHgCCyAhAe1EkgInYzKbByYQGAIFJz AZBuZAsRLh36UuxlZwsRHdZTDrAoICd11R00LS8CTwUQZyUxAyDCTQeQc2FnZS8DHTWVA2E6H6B3 H1ByLQiQVQAwLQBwbghgbiSAQG0xwi4FsCFAWwDAAxB0rG86MW8yeV0dNE8DoFRCZRPgbB/ATx/A Sd8CMASRFCAjcCticzKXLYXXIKExQDEAaSvweSIwAdBcIEoyUB8QAdAwKzAy0DE6MzQdNFQzkCNQ 4EVURi1BMiUxQBkwcS2UdWJqBZA4wSNiQUBDVElPTjorUy2abC0QZz4gK/BwLSUkai06AC4M0HQd +h00Qe8Hsza8IpElkHYzUQGgPjB/KFgCID4gC4AjQTbMKbBp7xggPOAFsAiQcyw7HfUBkfogB2B0 PjBG00bTMUAgIpUxQFQfAUIlMyBFMmBfBHAh4TZwJlNGeUEmAGjNBbAoIhBHxVMuIBA+Qf1GeUYD EAnwIQBHZDFAPd+7Pu9GxFAwISKwR4k5RnkORCPAR2s58i02LTHrUYodNEUA0GglmSuwKYEfKEAL gCWQIBAvcGh0d58kAFaxUjBFBUkgQWMkgb0EIFADYDOAF5EdNCggIv4pROdJICcCVnABAUOxKEAk c3kCMGF4IOBpLh5lS/Ar8AGQHuB5cGX+KUvwEMBbJR00WrMfgCZy+nNccGMGkEVxJvAzsCWZ10JQ CkEpUm4qYW1JkjOAfx7jXPoKwB8QMjBgoAdAbHtJIBggcBggFBA2wShAd+8fACaRK2AAgGYEkFYF ICP/JkAEkCPAJnFFkFywSJAipv9jB2WTQgIYIGRlYQEnESi28i1eZWMgCfBJZTOAXVX3BAAmYCEw dQQAVRAfgShj/yFkB4BLAS1QH6Jp919OZfv/KcZapUIhVlElvSIyHxFI5O9xlmPADeBVEGMDkR8w HTT+dRQQaFNeZEkgI6Me8icQ/nMp0AcwY4JfT2IyC4ArsPxlYQsxHVJp83ZyWAAFsDtqNR7jQicQ acFJR1J1Y05QINFCRVJZkHRjYvFJIFguNToAaqZFH0B1uFVSTCpVInFBLzodNIFWwHRwOi8vd4GQ Oi4ypi8kETbkK1NzLz9N/08PHkU68CPhKAIgef8IYRQQNlEoZzsyEMAyJW/z/yCAK7AiMGNRdoFs kTADYPLrHTQ0Gy0YIHFgEQVAA/D7HvAe43d5cXvwAIA8oATy/x8wVjIe8wRwcqEfwB7yiaX/LDtD /mIyB0B2EEI5fFEAcI8CIAbACGAEIEZUUEvxfm8vgYwIdGEEoE1SHUMi/5KHJYGJUwqwBBCMox+x hpLtaeAtM0Jw4GQrUC/xS/D+QQGAEoEXsIPgSZILgB3l+1xSJPBjViKCi5XkHvFKKt4iMDBwIYN/ hIkife2I0v8fokP/fUhzlSpRMlBWIoDPr4HXa5B4QDOwLlbAbQMhfx1DBbEBgKOSpfGByTQhL/4x pKRpUB+ARYE/f4/vIMHnc6KRY42Bb2IBkFrjfFH/l3QsOziRiWyAtUbTM0KUcX52MpcsNTawjdhc Uq5qIuBGSUxFIIJfnQ+eH+FUDE5PVEWAsEbjjrJ/l6KvYhKBI8Eyp3OiGCB0HwhwjcRvt6LmRtNN SU38RS14xmCCfEJ0YGDDJNLybQqwY2slgCYAAxAfgP55ZfJhEHRhIkNGeWRgI8B9CHBlIjB38QSQ dZQFoG0DA4EoQCJFTkNPRPhJTkdskAdxJYAfMCph977iJOGyciJGecE1vmQFgtcBAB7jYzFwZcFl S0EiML+GkYwBYsBiYAngwZFtMlD/vZQFsEZ5VnC7g8ExC1AHMP9wEZeTGCB4QASQXKFXUAEg/wSQ cALJP8pHvzoOwCHQJSCvcCHLFx8wE+B2JnByIjD/xgFegWKzY8MBAAdASZKMEv+cCsewM3AFIArA nsC7c4mW/yDRW7Qp13NEz0EfEmPhXmDzviFGeXVwmmJhENJEQrHf00YiIZGBE9AFkGuXFBew/3Og AyApxmdUShtfAtciAHD/BSB7UFJRHuK+0dNGtbtUSP/d/jYQF7AH4CJxueNcEnNE/8cDTTFCoskU wSLML8hVB3D/16HaGGhyJgADcSZg2ZFi04clwS4BHuNBU0NJIAB/uDEAkNqCjoOpTytxLDV9Aeog AAADABAQAAAAAAMAERABAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAG AAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAsAA4AIIAYAAAAAAMAAAAAAAABGAAAAABSFAAAAAAAA AwAIgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAADwYAAAeAAmACCAGAAAAAADAAAAAAAAARgAAAABU hQAAAQAAAAQAAAA4LjUACwAKgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAuACCAGAAAA AADAAAAAAAAARgAAAAABhQAAAAAAAAsAFIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAV gAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADABeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAB4AJoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeACeACCAGAAAAAADA AAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAogAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEA AAABAAAAAAAAAAsAM4ALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA1gAsgBgAAAAAAwAAA AAAAAEYAAAAABYgAAAAAAAACAfgPAQAAABAAAACVmSX3RZ3TEbRlAOApFdXbAgH6DwEAAAAQAAAA lZkl90Wd0xG0ZQDgKRXV2wIB+w8BAAAASQAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3BzdC5k bGwAAAAAAE5JVEH5v7gBAKoAN9luAAAASTpcbWFpbFxtYWlsYm94LnBzdAAAAAADAP4PBQAAAAMA DTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDA5NTk5MjVGNzQ1OUREMzExQjQ2NTAwRTAyOTE1RDVE QjA0QjM0NzAwAAAAALJcAgKQBgAOAAAAAQD/////IAAgAAAAAAA9BAIQgAEAFAAAAFVudGl0bGVk IEF0dGFjaG1lbnQAcgcCE4ADAA4AAADTBwYAFwALACoAEQABAD4BAhGABgC4DQAAAQAJAAAD3AYA AAAAIQYAAAAABQAAAAkCAAAAAAUAAAABAv///wClAAAAQQvGAIgAIAAgAAAAAAAgACAAAAAAACgA AAAgAAAAQAAAAAEAAQAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AA AAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAH8AAA D/AAAB/wAAA/8AAAf/AAAP8hBgAAQQtGAGYAIAAgAAAAAAAgACAAAAAAACgAAAAgAAAAIAAAAAEA GAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAAAAAAAAAAAAAAAAAAAAAAAAAA AACAgID///////////////////////////////////////////////////////////////////// ///////////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////// ///////////////////////////////////////////////////////////////////////////A wMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////////// ///////////////////////////////////////////////////AwMAAAAAAAAAAAAAAAAAAAAAA AAAAAACAgID///////////////////////////////////////////////////////////////// ///////////////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////// //////////////////////////////////////////////////////////////////////////// ///AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////// ///////////////////////////////////////////////////////AwMAAAAAAAAAAAAAAAAAA AAAAAAAAAACAgID///////////////////////8AAAAAAAAAAAAAAAAAAAD///////////////// //////////////8AAAD////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////// //////8AAAD///8AAAD///8AAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAD///// ///////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////8AAAD///////////// //////8AAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD////////////AwMAAAAAAAAAAAAAA AAAAAAAAAAAAAACAgID/////////////////////////AAD/AAD/AAD/AAAAAAD/AAD/AAAAAAAA AAAAAAAAAAAA//8AAAAAAAD////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///// ////////////AAD/////AAD/////AAD/AAAAAAD/AAD/AAD/AAAAAAAA//8A//8A//8AAAAAAAD/ ///////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID/////////////////AAD///////// //////////8AAAAAAAD/AAD/AAAAAAAA//8A//8A//8AAAAAAAD////////////AwMAAAAAAAAAA AAAAAAAAAAAAAAAAAACAgID///////////////////////8AAP8AAP8AAP8AAP8AAAAAAAAAAAD/ AAAAAAAA//8A//8AAAAAAAAAAAD////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID/ //////////////8AAP////8AAP////8AAP8AAP8AAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////8AAP////// //////////////8AAAAAAP8AAP8AAAAAAAAAAAAAAAAAgAAAAAAAAAD////////////AwMAAAAAA AAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////8AAAAAAAAAAAAAAAAAAAAAAP8A AP8AAP8AAAAAgAAAgAAAgAAAAAAAAAD////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACA gID///////////////8AAAD///8AAAD///8AAAAAAAAAAAAAAAAAAP8AAP8AAAAAgAAAgAAAgAAA AAAAAAD////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////8AAAD/ //////////////////8AAAAAAAAAAAAAAP8AAAAAgAAAgAAAAAAAAAAAAAD////////////AwMAA AAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAA AACAgID///////////////////////////////////////////////////8AAAAAAAAAAAAAAAD/ ///////////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////// ///////////////////////////////////////////////////////////////////////////A wMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////////// ///////////////////////////////////////////////////AwMAAAAAAAAAAAAAAAAAAAAAA AAAAAACAgID///////////////////////////////////////////////////////////////// ///////////////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////// //////////////////////////////////////////////////////////+AgIAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////// //////////////////////////////////+AgID////////AwMCAgIAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAgID///////////////////////////////////////////////////////////// //////////+AgID////AwMCAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////// //////////////////////////////////////////////////////////////+AgIDAwMCAgIAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////// //////////////////////////////////////+AgICAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACAgID///////////////////////////////////////////////////////// //////////////+AgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgICAgICA gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAB1wIFkAYA7AAAAAoAAAADACAOKAAAAB4AATABAAAA GQAAAEFUVDAwMDIyLmRhdCAoMTA1IGJ5dGVzKQAAAAADAAU3AQAAAAMACzf/////AwAQNwAAAAAD ACEO5R4NAAIB+A8BAAAAEAAAAJWZJfdFndMRtGUA4CkV1dsCAfoPAQAAABAAAACVmSX3RZ3TEbRl AOApFdXbAgH7DwEAAABJAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklU Qfm/uAEAqgA32W4AAABJOlxtYWlsXG1haWxib3gucHN0AAAAAAMA/g8HAAAAPTgCApAGAA4AAAAB AP////8gACAAAAAAAD0EAhCAAQAUAAAAVW50aXRsZWQgQXR0YWNobWVudAByBwITgAMADgAAANMH BgAXAAsAKgARAAEAPgECEYAGALgNAAABAAkAAAPcBgAAAAAhBgAAAAAFAAAACQIAAAAABQAAAAEC ////AKUAAABBC8YAiAAgACAAAAAAACAAIAAAAAAAKAAAACAAAABAAAAAAQABAAAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAAAD8AAAA/AAAAPwAAAD8AAAA/AA AAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAA A/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAfwAAAP8AAAH/AAAD/wAAB/8AAA/yEGAABBC0YA ZgAgACAAAAAAACAAIAAAAAAAKAAAACAAAAAgAAAAAQAYAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////////////// /////////////////////////////////////////////////////////////////8DAwAAAAAAA AAAAAAAAAAAAAAAAAAAAAICAgP////////////////////////////////////////////////// /////////////////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICA gP////////////////////////////////////////////////////////////////////////// /////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////////// /////////////////////////////////////////////////////////////////////8DAwAAA AAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////////////////////////////////// /////////////////////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAA AICAgP////////////////////////////////////////////////////////////////////// /////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////// /////wAAAAAAAAAAAAAAAAAAAP///////////////////////////////wAAAP///////////8DA wAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP///////////////wAAAP///wAAAP///wAAAAAAAAAA AAAAAAAAAP///////////////wAAAAAAAAAAAP///////////8DAwAAAAAAAAAAAAAAAAAAAAAAA AAAAAICAgP///////////////wAAAP///////////////////wAAAIAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////// //////////8AAP8AAP8AAP8AAAAAAP8AAP8AAAAAAAAAAAAAAAAAAAD//wAAAAAAAP////////// /8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////8AAP////8AAP////8AAP8A AAAAAP8AAP8AAP8AAAAAAAD//wD//wD//wAAAAAAAP///////////8DAwAAAAAAAAAAAAAAAAAAA AAAAAAAAAICAgP////////////////8AAP///////////////////wAAAAAAAP8AAP8AAAAAAAD/ /wD//wD//wAAAAAAAP///////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////// /////////////wAA/wAA/wAA/wAA/wAAAAAAAAAAAP8AAAAAAAD//wD//wAAAAAAAAAAAP////// /////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP///////////////wAA/////wAA/////wAA /wAA/wAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////8DAwAAAAAAAAAAAAAAA AAAAAAAAAAAAAICAgP///////////////wAA/////////////////////wAAAAAA/wAA/wAAAAAA AAAAAAAAAACAAAAAAAAAAP///////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////// /////////////////wAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wAAAACAAACAAACAAAAAAAAAAP// /////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP///////////////wAAAP///wAAAP// /wAAAAAAAAAAAAAAAAAA/wAA/wAAAACAAACAAACAAAAAAAAAAP///////////8DAwAAAAAAAAAAA AAAAAAAAAAAAAAAAAICAgP///////////////wAAAP///////////////////wAAAAAAAAAAAAAA /wAAAACAAACAAAAAAAAAAAAAAP///////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP// /////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// /////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////////////// /////////////////////////wAAAAAAAAAAAAAAAP///////////////////////8DAwAAAAAAA AAAAAAAAAAAAAAAAAAAAAICAgP////////////////////////////////////////////////// /////////////////////////////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICA gP////////////////////////////////////////////////////////////////////////// /////////////////8DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////////// /////////////////////////////////////////////////////////////////////8DAwAAA AAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////////////////////////////////// /////////////////////////4CAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AICAgP////////////////////////////////////////////////////////////////////// /4CAgP///////8DAwICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////// /////////////////////////////////////////////////////4CAgP///8DAwICAgAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////////////////////////////////// /////////////////////////////4CAgMDAwICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAICAgP////////////////////////////////////////////////////////////////// /////4CAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgP////////////// /////////////////////////////////////////////////////////4CAgAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgICAgICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAA AAHXAgWQBgD8AAAACgAAAAMAIA44AAAAHgABMAEAAAApAAAAZHJhZnQtbGVnZy1sZGFwLWJpbmFy eS0wMC50eHQgKDUyIGJ5dGVzKQAAAAADAAU3AQAAAAMACzf/////AwAQNwEAAAADACEOBR8NAAIB +A8BAAAAEAAAAJWZJfdFndMRtGUA4CkV1dsCAfoPAQAAABAAAACVmSX3RZ3TEbRlAOApFdXbAgH7 DwEAAABJAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA3 2W4AAABJOlxtYWlsXG1haWxib3gucHN0AAAAAAMA/g8HAAAAhD4= ------=_NextPart_000_00C9_01C3397C.7F7926C0-- From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 23 12:49:11 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 MAA28352 for ; Mon, 23 Jun 2003 12:49:10 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5NGVZl5072706; Mon, 23 Jun 2003 16:48:11 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 h5NGQLk2071997; Mon, 23 Jun 2003 16:26:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 23 Jun 2003 16:26:21 +0000 Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5NGQKkb071986 for ; Mon, 23 Jun 2003 16:26:20 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5NGQF2Z022740 for ; Mon, 23 Jun 2003 09:26:19 -0700 Received: from D-140-142-21-45.dhcp4.washington.edu (D-140-142-21-45.dhcp4.washington.edu [140.142.21.45]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5NGQFXa004015 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Jun 2003 09:26:15 -0700 Date: Mon, 23 Jun 2003 09:26:24 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: IETF ldapbis WG Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: A reminder that the Last Call period on these drafts ends this Wednesday, June 25. - RL "Bob" On Wed, 11 Jun 2003, RL 'Bob' Morgan wrote: > > This message initiates a LDAPbis Working Group Last Call on the two > documents: > > LDAP: Syntaxes and Matching Rules > draft-ietf-ldapbis-syntaxes-06.txt > 3 June 2003 > > and > > LDAP: Internationalized String Preparation > draft-ietf-ldapbis-strprep-00.txt > 26 May 2003 > > The purpose of this WG Last Call it to ensure that the Working Group has > achieved consensus that these documents are suitable for publication as > IETF Standards Track RFCs. > > Please review the documents for both technical and editorial problems. > Technical issues should be discussed on this list. Editorial issues may > be sent to the document editors. > > The Last Call period will end on Wednesday, June 25, 2003. > > Upon completion of the Last Call, the WG chair(s) will take action based > upon the consensus of the WG. Possible actions include: > > 1) recommending to the IETF Application Area Directors that the > documents, after possible editorial or other minor changes, be > considered by the IESG for publication as Standards Track RFCs > (which generally involves an IETF-wide Last Call); or > > 2) requiring that outstanding issues be adequately addressed prior > to further action (including, possibly, another Last Call). > > Remember that it is our responsibility as Working Group members to > ensure the quality of our documents and of the Internet Standards > process. So, please read and comment! > > - RL "Bob" Morgan > LDAPbis co-chair > > > > > From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 23 13:15:37 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 NAA29489 for ; Mon, 23 Jun 2003 13:15:36 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5NGJakp071003; Mon, 23 Jun 2003 16:24:15 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 h5NGDcDf070448; Mon, 23 Jun 2003 16:13:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 23 Jun 2003 16:13:38 +0000 Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5NGDbkb070437 for ; Mon, 23 Jun 2003 16:13:37 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5NGDXkI030532 for ; Mon, 23 Jun 2003 09:13:37 -0700 Received: from D-140-142-21-45.dhcp4.washington.edu (D-140-142-21-45.dhcp4.washington.edu [140.142.21.45]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5NGDXXa003212 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Jun 2003 09:13:33 -0700 Date: Mon, 23 Jun 2003 09:13:42 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: IETF ldapbis WG Subject: Re: ldapbis WG last call on draft-ietf-ldapbis-dn-10.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This Last Call period has ended. As far as I can tell no comments on this draft were sent to the list (perhaps not surprising since it has been extensively reviewed before). Some comments were sent to the author: a) update the "changes since 2253" appendix to reflect the adoption of the registry approach instead of the static table approach, b) add [REGISTRY] reference, and c) change the UTF-8 reference from RFC 2279 to draft-yergeau-rfc2279bis (this needs to be done throughout the LDAP TS). (a) and (b) are obvious; (c) seems reasonable since draft-yergeau-rfc2279bis is intended to replace RFC 2279 and seems to be making its way through the IESG. So I observe that the current state of this doc reflects the consensus of the WG, and upon submission of a new version of the doc incorporating the above changes, I'll pass it along to the IESG. (And please note that editorial corrections are always welcome ...) - RL "Bob" On Tue, 27 May 2003, RL 'Bob' Morgan wrote: > > This message initiates a LDAPbis Working Group Last Call on the > document: > > LDAP: String Representation of Distinguished Names > > 4 May 2003 > > The purpose of this WG Last Call it to ensure that the Working Group has > achieved consensus that the document is suitable for publication as an > IETF Draft Standard. > > Please review the document for both technical and editorial problems. > Technical issues should be discussed on this list. Editorial issues may > be sent to the document editor. > > (Let me point out that a previous version of this document went through WG > last call quite a while ago. Subsequently the "short names registry" > issue was reopened. The current version of this document reflects > apparent current WG consensus to support a registry approach; see section > 2.3. This Last Call is intended to confirm this consensus as well as > solicit any other review.) > > The Last Call period will end on Friday, June 13, 2003. > > Upon completion of the last call, the WG chair(s) will take action based > upon the consensus of the WG. Possible actions include: > > 1) recommending to the IETF Application Area Directors that the > document, after possible editorial or other minor changes, be > considered by the IESG for publication as a Draft Standard > (which generally involves an IETF-wide Last Call); or > > 2) requiring that outstanding issues be adequately addressed prior > to further action (including, possibly, another Last Call). > > Remember that it is our responsibility as Working Group members to > ensure the quality of our documents and of the Internet Standards > process. So, please read and comment! > > - RL "Bob" Morgan > LDAPbis co-chair From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 23 14:21:59 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 OAA02350 for ; Mon, 23 Jun 2003 14:21: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 h5NIJbkv080674; Mon, 23 Jun 2003 18:20:10 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 h5NIJCbR080654; Mon, 23 Jun 2003 18:19:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 23 Jun 2003 18:19:12 +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 h5NIJBkb080643 for ; Mon, 23 Jun 2003 18:19:11 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 23 Jun 2003 12:18:51 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 23 Jun 2003 12:17:20 -0600 From: "Jim Sermersheim" To: Subject: RE: Attribute Name Length Bounds 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 Can we answer the question: Does any work need to happen to the LDAP TS to address this particular issue? Any suggested changes I've heard so far have worried me for one reason or another. Jim >>> "Ramsay, Ron" 6/19/03 9:59:36 PM >>> This is a silly suggestiion, of course every octet in a PDU is significant. If this was an ellipses for "every octet of every attribute description in a PDU is significanr" then it is inappropriate - it is not an ASN.1 issue, it is an application issue. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 20 June 2003 13:02 To: Howard Chu Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds At 08:29 PM 6/17/2003, Howard Chu wrote: >> The point is that the possibility of interpreting >> the specs in this way already set us up for deployment >> issues related to several published schema with attribute >> names on the longer side of what might have been considered >> typical a few years ago. > >If the server rejects overly-long names with an error message, fine, but your >message implied that it silently ignored the characters comprising the excess >length in the name. If it seems that the spec is ambiguous about the >significance of characters in a short name, perhaps it would be sufficient to >state in the the spec "all of the characters in an attribute name are >significant. One could argue that the TS should be clarified to say: All bits of very octet of the PDU are significant unless stated otherwise. However, I think basically already says this already in X.680/X.690. But, I don't see much harm in restating this in [Protocol] (even though I think it a bit redundant and quite obvious). I, however, think we should avoid per field statements (except for the otherwise cases). >If an attribute name is presented that exceeds a server's >implementation limits, the server MUST fail the request with an error code." That would be, in general, a bad thing. Servers should treat attribute type names they don't recognize as unrecognized attribute types and many of these cases don't result in an error being returned. Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 07:28: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 HAA12141 for ; Tue, 24 Jun 2003 07:28:18 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OBQQkb033223; Tue, 24 Jun 2003 11:26:26 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 h5OB81WT032054; Tue, 24 Jun 2003 11:08:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 11:08:01 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OB7wkb032044 for ; Tue, 24 Jun 2003 11:07:59 GMT (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11269; Tue, 24 Jun 2003 07:00:38 -0400 (EDT) Message-Id: <200306241100.HAA11269@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapbis@OpenLDAP.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapbis-bcp64-00.txt Date: Tue, 24 Jun 2003 07:00:38 -0400 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. Title : IANA Considerations for LDAP Author(s) : K. Zeilenga Filename : draft-ietf-ldapbis-bcp64-00.txt Pages : 15 Date : 2003-6-23 This document provides procedures for registering extensible elements of Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-bcp64-00.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-bcp64-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapbis-bcp64-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-23142526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-bcp64-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-bcp64-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-23142526.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 14:21:30 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 OAA29633 for ; Tue, 24 Jun 2003 14:21:25 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OIJjkf061546; Tue, 24 Jun 2003 18:20: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 h5OIEnAq061352; Tue, 24 Jun 2003 18:14:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 18:14:49 +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 h5OIEmkb061317 for ; Tue, 24 Jun 2003 18:14:48 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 24 Jun 2003 12:14:28 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Tue, 24 Jun 2003 12:12:54 -0600 From: "Jim Sermersheim" To: Cc: "Steve McLain" , "Tom Doman" Subject: Specifying non-tcp transports referrals 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 All, Currently, either an LDAPURL or "Other kind of URL" may be specified in an LDAP referral. I believe it's assumed that the address in an LDAP URL (draft-ietf-ldapbis-url-03.txt) points to an LDAP server capable of communicating over TCP/IP. This is probably a bad assumption. If/when someone wants to specify a non-TCP transport be used to follow a referral, how would that be done? So far, all I can think of is to use different URI schemes like: ldap.udp ldap.mobileip Is there another way I'm not seeing? Also, in [Protocol], there is this wording (Section 4.1.10) >URLs for servers implementing the LDAP protocol are written according >to [LDAPURL]. and >Other kinds of URLs may be returned, so long as the operation could >be performed using that protocol. This implies (maybe it's more than an implication) that if the LDAP protocol is to be used, the Referral will adhere to [LDAPURL]. This means an ldap referral shouldn't contain a scheme like "ldaps". I think the wording is either unclear or too restrictive. Why shouldn't I be able to name a server supporting the LDAP protocol using some non [LDAPURL] URI? Jim From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 14:23: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 OAA00046 for ; Tue, 24 Jun 2003 14:23:45 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OHhikf059703; Tue, 24 Jun 2003 17:48: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 h5OHgQk9059690; Tue, 24 Jun 2003 17:42:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 17:42:26 +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 h5OHgOkb059680 for ; Tue, 24 Jun 2003 17:42:25 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 h5OHgOc6087215 for ; Tue, 24 Jun 2003 17:42:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030624103327.01c09980@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 24 Jun 2003 10:39:24 -0700 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldapbis-bcp64-00.txt In-Reply-To: <200306241100.HAA11269@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is first cut at revising BCP 64. Aside from numerous editorial changes, it incorporates the change (descriptors SHOULD be registered, descriptors in RFCs MUST be registered) previously detailed in [Models, 6.2] to Section 3.3. Kurt At 04:00 AM 6/24/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 : IANA Considerations for LDAP > Author(s) : K. Zeilenga > Filename : draft-ietf-ldapbis-bcp64-00.txt > Pages : 15 > Date : 2003-6-23 > >This document provides procedures for registering extensible elements >of Lightweight Directory Access Protocol (LDAP). The document also >provides guidelines to Internet Assigned Numbers Authority (IANA) >describing conditions under which new values can be assigned. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-bcp64-00.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-bcp64-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ldapbis-bcp64-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-6-23142526.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ldapbis-bcp64-00.txt > > From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 15:30:49 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 PAA06217 for ; Tue, 24 Jun 2003 15:30: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 h5OJPjkf066004; Tue, 24 Jun 2003 19:29:40 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 h5OJP8YO065983; Tue, 24 Jun 2003 19:25:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 19:25:08 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OJP0kb065927 for ; Tue, 24 Jun 2003 19:25:03 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-202-57.pskn.east.verizon.net [151.204.202.57]) by echt.caledonia.net; Tue, 24 Jun 2003 13:24:05 -0600 Reply-To: From: "Chris Apple" To: "'Jim Sermersheim'" , Cc: "'Steve McLain'" , "'Tom Doman'" Subject: RE: Specifying non-tcp transports referrals Date: Tue, 24 Jun 2003 15:23:41 -0400 Organization: DSI-Consulting, Inc. Message-ID: <016401c33a86$2b926930$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Tuesday, June 24, 2003 2:13 PM To: ietf-ldapbis@OpenLDAP.org Cc: Steve McLain; Tom Doman Subject: Specifying non-tcp transports referrals All, Currently, either an LDAPURL or "Other kind of URL" may be specified in an LDAP referral. I believe it's assumed that the address in an LDAP URL (draft-ietf-ldapbis-url-03.txt) points to an LDAP server capable of communicating over TCP/IP. This is probably a bad assumption. If/when someone wants to specify a non-TCP transport be used to follow a referral, how would that be done? So far, all I can think of is to use different URI schemes like: ldap.udp ldap.mobileip Is there another way I'm not seeing? ============================================================== Not if you want to comply with the specs as written. The only other way I can think of is to use a labeledURI such as ldap://host.name[udp] or ldap://host.name[mobileip]. The drawback is that you have to analyze content further down in the string to determine what transport to use. I acknowledge that this could represent significant changes to various documents (and implementations) including [LDAPURL]. But it is another way of solving the general problem you describe below. And I haven't sorted through the non-referral-related issues with using the label in this way. It may make more sense to use something like: ldap://host.name[transport-udp] That would seem to solve the more general problem below and avoid confusion over more human-friendly uses of the label value. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ============================================================== Also, in [Protocol], there is this wording (Section 4.1.10) >URLs for servers implementing the LDAP protocol are written according >to [LDAPURL]. and >Other kinds of URLs may be returned, so long as the operation could >be performed using that protocol. This implies (maybe it's more than an implication) that if the LDAP protocol is to be used, the Referral will adhere to [LDAPURL]. This means an ldap referral shouldn't contain a scheme like "ldaps". I think the wording is either unclear or too restrictive. Why shouldn't I be able to name a server supporting the LDAP protocol using some non [LDAPURL] URI? Jim From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 15:39:36 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 PAA06818 for ; Tue, 24 Jun 2003 15:39:35 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OJVjkf066182; Tue, 24 Jun 2003 19:38: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 h5OJTITU066070; Tue, 24 Jun 2003 19:29:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 19:29:18 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OJT3kb066049 for ; Tue, 24 Jun 2003 19:29:16 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19UtTP-0003cP-00 for ietf-ldapbis@openldap.org; Tue, 24 Jun 2003 21:28:59 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.14) id 19UtTL-0002Cf-7b for ietf-ldapbis@openldap.org; Tue, 24 Jun 2003 21:28:55 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19UtTL-0006fA-00; Tue, 24 Jun 2003 21:28:55 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19UtTK-0002ur-00; Tue, 24 Jun 2003 21:28:54 +0200 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 24 Jun 2003 21:28:54 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: RL 'Bob' Morgan writes: > A reminder that the Last Call period on these drafts ends this Wednesday, > June 25. Whoops. Thanks for the reminder. I've been sitting on this for too long: I have some problems with ldapbis-strprep. I posted some of them before to the strmatch draft, but I don't think I got a reply. > 2. String Preparation > The following six-step process SHALL be applied to each presented and > attribute value in preparation for string match rule evaluation. Not to octet strings. Do they count as _string_ match? > 2.2. Map > > All other control code points (e.g., Cc) or code points with a control > function (e.g., Cf) are mapped to nothing. > > ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points > with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or > Zp) are mapped to SPACE (U+0020). Can you list these (mostly as character ranges, I hope), or are there too many of them? For syntaxes/matching rules that expect non-empty strings, character removal in step 2.2 can change a valid (non-empty) string to an invalid (empty) one. If that happens, I suggest a SPACE should be inserted for matching rules where space can be insignificant. I don't know what to do about matching rules where space is always significant. For the same reason, > 2.6.1. Insignificant Space Removal > A string consisting entirely of spaces is equivalent to a string ^^^^^^^^^^^^^^^^ > containing exactly one space. This doesn't say anything about how to translate the string. I think it should be "... is _translated to_ a string containing...". 2.6.2 (numericString) and 2.6.3 (telephoneNumber) should also re-insert a single space if they would translate a non-empty string to an empty one, since these syntaxes also expect a non-empty string. That is, I assume 'PrintableString (SIZE(1..ub-telephone-number))' in the definition of the Telephone Number syntax means one or more character. Finally, there is no section 2.6. Sections 2.6.* should be 2.5.*. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 16:00:11 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 QAA07661 for ; Tue, 24 Jun 2003 16:00:10 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OJ1jkh063729; Tue, 24 Jun 2003 19:14:33 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 h5OIp3IU062996; Tue, 24 Jun 2003 18:51:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 18:51:03 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OIookb062963 for ; Tue, 24 Jun 2003 18:50:57 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-202-57.pskn.east.verizon.net [151.204.202.57]) by echt.caledonia.net; Tue, 24 Jun 2003 12:49:59 -0600 Reply-To: From: "Chris Apple" To: "'Jim Sermersheim'" , Subject: RE: Attribute Name Length Bounds Date: Tue, 24 Jun 2003 14:49:45 -0400 Organization: DSI-Consulting, Inc. Message-ID: <015e01c33a81$67a8e520$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 that's a consensus judgment call that the Co-Chairs need to make based on the discussion so far... Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Monday, June 23, 2003 2:17 PM To: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds Can we answer the question: Does any work need to happen to the LDAP TS to address this particular issue? Any suggested changes I've heard so far have worried me for one reason or another. Jim >>> "Ramsay, Ron" 6/19/03 9:59:36 PM >>> This is a silly suggestiion, of course every octet in a PDU is significant. If this was an ellipses for "every octet of every attribute description in a PDU is significanr" then it is inappropriate - it is not an ASN.1 issue, it is an application issue. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 20 June 2003 13:02 To: Howard Chu Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds At 08:29 PM 6/17/2003, Howard Chu wrote: >> The point is that the possibility of interpreting >> the specs in this way already set us up for deployment >> issues related to several published schema with attribute >> names on the longer side of what might have been considered >> typical a few years ago. > >If the server rejects overly-long names with an error message, fine, but your >message implied that it silently ignored the characters comprising the excess >length in the name. If it seems that the spec is ambiguous about the >significance of characters in a short name, perhaps it would be sufficient to >state in the the spec "all of the characters in an attribute name are >significant. One could argue that the TS should be clarified to say: All bits of very octet of the PDU are significant unless stated otherwise. However, I think basically already says this already in X.680/X.690. But, I don't see much harm in restating this in [Protocol] (even though I think it a bit redundant and quite obvious). I, however, think we should avoid per field statements (except for the otherwise cases). >If an attribute name is presented that exceeds a server's >implementation limits, the server MUST fail the request with an error code." That would be, in general, a bad thing. Servers should treat attribute type names they don't recognize as unrecognized attribute types and many of these cases don't result in an error being returned. Kurt From owner-ietf-ldapbis@openldap.org Tue Jun 24 17:04:02 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 RAA11160 for ; Tue, 24 Jun 2003 17:04:02 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OK7jl3067198; Tue, 24 Jun 2003 20:19: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 h5OK4jhJ067096; Tue, 24 Jun 2003 20:04:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 20:04:45 +0000 Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OK4ikb067084 for ; Tue, 24 Jun 2003 20:04:44 GMT (envelope-from rvh@qsun.mt.att.com) Received: from qsun.mt.att.com ([135.16.157.16]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5OK4InC019614; Tue, 24 Jun 2003 15:04:18 -0500 Received: by qsun.mt.att.com (8.8.8p2+Sun/ATTEMS-1.4.1 sol2) id QAA16330; Tue, 24 Jun 2003 16:04:16 -0400 (EDT) Date: Tue, 24 Jun 2003 16:04:16 -0400 (EDT) Message-Id: <200306242004.QAA16330@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: capple@dsi-consulting.net, ietf-ldapbis@openldap.org, jimse@novell.com Subject: RE: Attribute Name Length Bounds 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: As noted in Chris' email that started this discussion, it seems there are implementations that do NOT consider every octet of every attribute description to be significant. So there is evidence that the current documents were not interpreted the same way by all implementors and there are interoperability problems if we say nothing. So I think it should be clarified in the new documents. Rick Huber : From owner-ietf-ldapbis@openldap.org Tue Jun 24 15:09:42 2003 : Return-Path: : From: "Chris Apple" : To: "'Jim Sermersheim'" , : Subject: RE: Attribute Name Length Bounds : Sender: owner-ietf-ldapbis@openldap.org : : I think that's a consensus judgment call that : the Co-Chairs need to make based on the discussion : so far... : : Chris Apple - Principal Architect : : DSI Consulting, Inc. : : mailto:capple@dsi-consulting.net : : http://www.dsi-consulting.com : : -----Original Message----- : From: owner-ietf-ldapbis@OpenLDAP.org : [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim : Sent: Monday, June 23, 2003 2:17 PM : To: ietf-ldapbis@OpenLDAP.org : Subject: RE: Attribute Name Length Bounds : : : Can we answer the question: : : Does any work need to happen to the LDAP TS to address this particular : issue? : : Any suggested changes I've heard so far have worried me for one reason : or another. : : Jim : : >>> "Ramsay, Ron" 6/19/03 9:59:36 PM >>> : This is a silly suggestiion, of course every octet in a PDU is : significant. If this was an ellipses for "every octet of every attribute : description in a PDU is significanr" then it is inappropriate - it is : not an ASN.1 issue, it is an application issue. : : -----Original Message----- : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] : Sent: Friday, 20 June 2003 13:02 : To: Howard Chu : Cc: ietf-ldapbis@OpenLDAP.org : Subject: RE: Attribute Name Length Bounds : : : At 08:29 PM 6/17/2003, Howard Chu wrote: : >> The point is that the possibility of interpreting : >> the specs in this way already set us up for deployment : >> issues related to several published schema with attribute : >> names on the longer side of what might have been considered : >> typical a few years ago. : > : >If the server rejects overly-long names with an error message, fine, : but your : >message implied that it silently ignored the characters comprising the : excess : >length in the name. If it seems that the spec is ambiguous about the : >significance of characters in a short name, perhaps it would be : sufficient to : >state in the the spec "all of the characters in an attribute name are : >significant. : : One could argue that the TS should be clarified to say: : All bits of very octet of the PDU are significant unless stated : otherwise. : : However, I think basically already says this already in X.680/X.690. : But, : I don't see much harm in restating this in [Protocol] (even though I : think : it a bit redundant and quite obvious). : : I, however, think we should avoid per field statements (except for the : otherwise cases). : : >If an attribute name is presented that exceeds a server's : >implementation limits, the server MUST fail the request with an error : code." : : That would be, in general, a bad thing. Servers should treat attribute : type : names they don't recognize as unrecognized attribute types and many of : these : cases don't result in an error being returned. : : Kurt : : : : : From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 22:07:58 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 WAA02937 for ; Tue, 24 Jun 2003 22:07:42 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P21lkf078668; Wed, 25 Jun 2003 02:06:28 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 h5P1vGBx078613; Wed, 25 Jun 2003 01:57:16 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 01:57:16 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P1vEkb078603 for ; Wed, 25 Jun 2003 01:57:15 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 11:56:51 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Date: Wed, 25 Jun 2003 11:56:51 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638139AE93@ausyms21.ca.com> Thread-Topic: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Thread-Index: AcM6iD8ABrKf+vfLS9CyIYTwhPrhyAANHpjQ From: "Ramsay, Ron" To: "Hallvard B Furuseth" , X-OriginalArrivalTime: 25 Jun 2003 01:56:51.0416 (UTC) FILETIME=[0B96AD80:01C33ABD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5P1vFkb078604 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 Surely you can't do strprep on PrintableString? The choice of characters is so limited that there can't be any translation? -----Original Message----- From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Wednesday, 25 June 2003 05:29 To: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep RL 'Bob' Morgan writes: > A reminder that the Last Call period on these drafts ends this Wednesday, > June 25. Whoops. Thanks for the reminder. I've been sitting on this for too long: I have some problems with ldapbis-strprep. I posted some of them before to the strmatch draft, but I don't think I got a reply. > 2. String Preparation > The following six-step process SHALL be applied to each presented and > attribute value in preparation for string match rule evaluation. Not to octet strings. Do they count as _string_ match? > 2.2. Map > > All other control code points (e.g., Cc) or code points with a control > function (e.g., Cf) are mapped to nothing. > > ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points > with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or > Zp) are mapped to SPACE (U+0020). Can you list these (mostly as character ranges, I hope), or are there too many of them? For syntaxes/matching rules that expect non-empty strings, character removal in step 2.2 can change a valid (non-empty) string to an invalid (empty) one. If that happens, I suggest a SPACE should be inserted for matching rules where space can be insignificant. I don't know what to do about matching rules where space is always significant. For the same reason, > 2.6.1. Insignificant Space Removal > A string consisting entirely of spaces is equivalent to a string ^^^^^^^^^^^^^^^^ > containing exactly one space. This doesn't say anything about how to translate the string. I think it should be "... is _translated to_ a string containing...". 2.6.2 (numericString) and 2.6.3 (telephoneNumber) should also re-insert a single space if they would translate a non-empty string to an empty one, since these syntaxes also expect a non-empty string. That is, I assume 'PrintableString (SIZE(1..ub-telephone-number))' in the definition of the Telephone Number syntax means one or more character. Finally, there is no section 2.6. Sections 2.6.* should be 2.5.*. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 22:15: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 WAA03097 for ; Tue, 24 Jun 2003 22:14: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 h5P01kkf076727; Wed, 25 Jun 2003 00:05: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 h5ONw9QA076608; Tue, 24 Jun 2003 23:58:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 23:58:09 +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 h5ONw7kb076598 for ; Tue, 24 Jun 2003 23:58:07 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 h5ONw6c6090038; Tue, 24 Jun 2003 23:58:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 24 Jun 2003 16:55:06 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 12:28 PM 6/24/2003, Hallvard B Furuseth wrote: >> 2. String Preparation >> The following six-step process SHALL be applied to each presented and >> attribute value in preparation for string match rule evaluation. > >Not to octet strings. Do they count as _string_ match? The algorithm is intended to apply (as specified in other documents) to character string matching. I suggest inserting the word 'character' before 'string' in the above sentence and likewise in a few other places. >> 2.2. Map >> >> All other control code points (e.g., Cc) or code points with a control >> function (e.g., Cf) are mapped to nothing. >> >> ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points >> with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or >> Zp) are mapped to SPACE (U+0020). > >Can you list these (mostly as character ranges, I hope), or are there >too many of them? I could. But I prefer to say it once than twice to avoid possible inconsistencies. I am not adverse to adding an informative mapping table as an appendix. Would that adequately address your concern? >For syntaxes/matching rules that expect non-empty strings, character >removal in step 2.2 can change a valid (non-empty) string to an invalid >(empty) one. If either the presented or stored values are mapped to empty strings, then the match is Undefined. I don't see that as being much of a problem, especially since caseIgnoreIA5Match("",X) can be argued should behave just like caseIgnoreMatch("",X)... evaluated to Undefined. >If that happens, I suggest a SPACE should be inserted for >matching rules where space can be insignificant. I think this would be bad as caseIgnoreMatch(""," ") would evaluate to TRUE not Undefined. >For the same reason, > >> 2.6.1. Insignificant Space Removal >> A string consisting entirely of spaces is equivalent to a string > ^^^^^^^^^^^^^^^^ >> containing exactly one space. > >This doesn't say anything about how to translate the string. >I think it should be "... is _translated to_ a string containing...". I suggest combining the statement with the previous paragraph: A string consisting entirely of spaces is to be replaced with a string of exactly one space. Otherwise, the following spaces are regarded are to be removed: >2.6.2 (numericString) and 2.6.3 (telephoneNumber) should also re-insert >a single space if they would translate a non-empty string to an empty >one, since these syntaxes also expect a non-empty string. >That is, I assume 'PrintableString (SIZE(1..ub-telephone-number))' in >the definition of the Telephone Number syntax means one or more >character. Okay. >Finally, there is no section 2.6. Sections 2.6.* should be 2.5.*. Yes. From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 22:15: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 WAA03100 for ; Tue, 24 Jun 2003 22:15:00 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OMbkkf075303; Tue, 24 Jun 2003 22:42:11 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 h5OMZCtP075245; Tue, 24 Jun 2003 22:35:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 24 Jun 2003 22:35:12 +0000 Received: from boole.openldap.org (kurt@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OMZCkb075234 for ; Tue, 24 Jun 2003 22:35:12 GMT (envelope-from kurt@boole.openldap.org) Received: (from kurt@localhost) by boole.openldap.org (8.12.9/8.12.9/Submit) id h5OMZCqh075233 for ietf-ldapbis@openldap.org; Tue, 24 Jun 2003 22:35:12 GMT (envelope-from kurt) Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5OKqNkb070614 for ; Tue, 24 Jun 2003 20:52:24 GMT (envelope-from ehall@ehsco.com) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 243052; Tue, 24 Jun 2003 15:52:02 -0500 Message-ID: <3EF8BA04.9000004@ehsco.com> Date: Tue, 24 Jun 2003 15:52:20 -0500 From: "Eric A. Hall" 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, Steve McLain , Tom Doman Subject: Re: Specifying non-tcp transports referrals References: In-Reply-To: Content-Type: text/plain; charset=us-ascii 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 on 6/24/2003 1:12 PM Jim Sermersheim wrote: > I believe it's assumed that the address in an LDAP URL > (draft-ietf-ldapbis-url-03.txt) points to an LDAP server capable of > communicating over TCP/IP. This is probably a bad assumption. > > If/when someone wants to specify a non-TCP transport be used to follow > a referral, how would that be done? So far, all I can think of is to use > different URI schemes like: This is a problem for other schemes that can use multiple transport protocols already. RFC 3263 defines a mechanism using NAPTR and SRV RRs to handle this problem with SIP and is being advocated by some folks for use with other services. My own personal preference would be to modify the scheme descriptor to include a transport (eg ldap/tcp://host:port/...) since that would be the cleanest service/proto mapping. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-ldapbis@OpenLDAP.org Tue Jun 24 23:01:04 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 XAA04241 for ; Tue, 24 Jun 2003 23:01: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 h5P2tlkf079853; Wed, 25 Jun 2003 02:56:03 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 h5P2pDQL079768; Wed, 25 Jun 2003 02:51:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 02:51:13 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P2pAkb079757 for ; Wed, 25 Jun 2003 02:51:10 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-202-57.pskn.east.verizon.net [151.204.202.57]) by echt.caledonia.net; Tue, 24 Jun 2003 20:50:52 -0600 Reply-To: From: "Chris Apple" To: , "'Jim Sermersheim'" , Subject: RE: Attribute Name Length Bounds Date: Tue, 24 Jun 2003 22:50:44 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000201c33ac4$95d60ca0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <015e01c33a81$67a8e520$6500a8c0@D7ST2111> 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 Or that they think there needs to be more discussion... Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Chris Apple Sent: Tuesday, June 24, 2003 2:50 PM To: 'Jim Sermersheim'; ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds I think that's a consensus judgment call that the Co-Chairs need to make based on the discussion so far... Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Monday, June 23, 2003 2:17 PM To: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds Can we answer the question: Does any work need to happen to the LDAP TS to address this particular issue? Any suggested changes I've heard so far have worried me for one reason or another. Jim >>> "Ramsay, Ron" 6/19/03 9:59:36 PM >>> This is a silly suggestiion, of course every octet in a PDU is significant. If this was an ellipses for "every octet of every attribute description in a PDU is significanr" then it is inappropriate - it is not an ASN.1 issue, it is an application issue. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 20 June 2003 13:02 To: Howard Chu Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Attribute Name Length Bounds At 08:29 PM 6/17/2003, Howard Chu wrote: >> The point is that the possibility of interpreting >> the specs in this way already set us up for deployment >> issues related to several published schema with attribute >> names on the longer side of what might have been considered >> typical a few years ago. > >If the server rejects overly-long names with an error message, fine, but your >message implied that it silently ignored the characters comprising the excess >length in the name. If it seems that the spec is ambiguous about the >significance of characters in a short name, perhaps it would be sufficient to >state in the the spec "all of the characters in an attribute name are >significant. One could argue that the TS should be clarified to say: All bits of very octet of the PDU are significant unless stated otherwise. However, I think basically already says this already in X.680/X.690. But, I don't see much harm in restating this in [Protocol] (even though I think it a bit redundant and quite obvious). I, however, think we should avoid per field statements (except for the otherwise cases). >If an attribute name is presented that exceeds a server's >implementation limits, the server MUST fail the request with an error code." That would be, in general, a bad thing. Servers should treat attribute type names they don't recognize as unrecognized attribute types and many of these cases don't result in an error being returned. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 00:02:02 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 AAA05215 for ; Wed, 25 Jun 2003 00:02: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 h5P3tmkf081672; Wed, 25 Jun 2003 03:59:55 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 h5P3rZFh081598; Wed, 25 Jun 2003 03:53:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 03:53: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 h5P3rYkb081588 for ; Wed, 25 Jun 2003 03:53:34 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 h5P3rWc6092080; Wed, 25 Jun 2003 03:53:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030624204115.01ade660@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 24 Jun 2003 20:50:31 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: Attribute Name Length Bounds Cc: In-Reply-To: <000201c33ac4$95d60ca0$6500a8c0@D7ST2111> References: <015e01c33a81$67a8e520$6500a8c0@D7ST2111> 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:50 PM 6/24/2003, Chris Apple wrote: >Or that they think there needs to be more discussion... While the chairs are currently considering what steps should be taken to bring this discussion to a conclusion, we're not yet ready to declare consensus. The discussion is still wide open. Kurt, LDAPBIS co-chair From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 00:15:18 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 AAA05349 for ; Wed, 25 Jun 2003 00:15:17 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P4Dlkf082070; Wed, 25 Jun 2003 04:14:01 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 h5P48SIF082026; Wed, 25 Jun 2003 04:08:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 04:08:28 +0000 Received: from cosium01.intelliden.net (cosium01.intelliden.net [12.41.186.248]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P48Rkb082016 for ; Wed, 25 Jun 2003 04:08:27 GMT (envelope-from John.Strassner@intelliden.com) Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 22:08:26 -0600 Message-ID: From: John Strassner To: ietf-ldapbis@OpenLDAP.org Subject: Attribute Name Length Bounds Date: Tue, 24 Jun 2003 22:08:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33ACF.6ADFD0C0" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33ACF.6ADFD0C0 Content-Type: text/plain Since I have rather strong views on this, I thought I would carefully read the thread and then provide some insight as to how decisions made in LDAPbis could affect various fora and standards bodies. I've now gone through the thread twice, and still have the same conclusion - prescribing an attribute name length bound is BAD. I'm not going to rehash any of the other arguments, because my feeling is that the WG is at somewhat of an impasse here. However, I will present an argument with new data, which is based on **users** wishing to develop directory schemata and finding that existing implementations have severe interoperability problems. There are numerous standards bodies and fora, ranging from the TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web Services efforts, that have as part of their standards relatively long names. For those that are using UML (or UML-like) approaches, this takes the form of very long (> 64 characters is common) class, attribute, and relationship (e.g., association, aggregation, composition, etc.) names. The basic way that many of these schemata are designed uses a standard and simple method to generate the name of relationships: . Note that the order may also be . Thus, whether a class or an attribute name could conceivably be shortened, it is almost certain that the relationship won't be able to be shortened a sufficient amount to do any good. More importantly, however, as a schema designer, I find it unaccceptable that my schema has to go through some bizarre machinations when being transformed from an information model to a data model just so it has a prayer of being implemented in a directory. This is a great way to encourage people NOT to use a directory. The mapping is difficult enough as it is - coming up with some difficult alias schemes, or methodology for name shortening, is not conformant to the basic schema that was agreed to by the standard body or fora in the first place. Furthermore, once one "buys into" any type of translation mechanism to produce different names, it is guaranteed to cause interoperability problems, simply because it is too hard to guarantee that two different implementations will apply the same rule to produce the same name. The examples listed above cover a very large body of work in different disciplines. Restricting name length to some arbitrary limit is inherently bad, as it flies in the face of the standards bodies and fora that are trying to use directories in the first place. They also exacerbate existing interoperability problems. This WG might not have identified issues such as these explicitly as part of its charter, but it should consider them, since its fundamental purpose is to produce a draft standard. That requires interoperability. Please, let's not ruin LDAP as it starts to mature. regards, John John Strassner Chief Strategy Officer Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 USA phone: +1.719.785.0648 FAX: +1.719.785.0644 email: john.strassner@intelliden.com ------_=_NextPart_001_01C33ACF.6ADFD0C0 Content-Type: text/html Message
Since I have rather strong views on this, I thought I would carefully read the thread and then provide some insight as to how decisions made in LDAPbis could affect various fora and standards bodies.
 
I've now gone through the thread twice, and still have the same conclusion - prescribing an attribute name length bound is BAD.
 
I'm not going to rehash any of the other arguments, because my feeling is that the WG is at somewhat of an impasse here. However, I will present an argument with new data, which is based on **users** wishing to develop directory schemata and finding that existing implementations have severe interoperability problems.
 
There are numerous standards bodies and fora, ranging from the TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web Services efforts, that have as part of their standards relatively long names. For those that are using UML (or UML-like) approaches, this takes the form of very long (> 64 characters is common) class, attribute, and relationship (e.g., association, aggregation, composition, etc.) names. The basic way that many of these schemata are designed uses a standard and simple method to generate the name of relationships: <object1><verb><object2>. Note that the order may also be <verb><object1><object2>.
 
Thus, whether a class or an attribute name could conceivably be shortened, it is almost certain that the relationship won't be able to be shortened a sufficient amount to do any good.
 
More importantly, however, as a schema designer, I find it unaccceptable that my schema has to go through some bizarre machinations when being transformed from an information model to a data model just so it has a prayer of being implemented in a directory. This is a great way to encourage people NOT to use a directory.
 
The mapping is difficult enough as it is - coming up with some difficult alias schemes, or methodology for name shortening, is not conformant to the basic schema that was agreed to by the standard body or fora in the first place.
 
Furthermore, once one "buys into" any type of translation mechanism to produce different names, it is guaranteed to cause interoperability problems, simply because it is too hard to guarantee that two different implementations will apply the same rule to produce the same name.
 
The examples listed above cover a very large body of work in different disciplines. Restricting name length to some arbitrary limit is inherently bad, as it flies in the face of the standards bodies and fora that are trying to use directories in the first place. They also exacerbate existing interoperability problems.
 
This WG might not have identified issues such as these explicitly as part of its charter, but it should consider them, since its fundamental purpose is to produce a draft standard. That requires interoperability.
 
Please, let's not ruin LDAP as it starts to mature.
 

regards,
John

John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO  80903  USA
phone: +1.719.785.0648
  FAX: +1.719.785.0644
email: john.strassner@intelliden.com
 

 
------_=_NextPart_001_01C33ACF.6ADFD0C0-- From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 04:21:11 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 EAA04594 for ; Wed, 25 Jun 2003 04:20:56 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P8Dnkf089369; Wed, 25 Jun 2003 08:18: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 h5P8CKJD089331; Wed, 25 Jun 2003 08:12:20 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 08:12:20 +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 h5P8CIkb089294 for ; Wed, 25 Jun 2003 08:12:18 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 25 Jun 2003 02:11:57 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Wed, 25 Jun 2003 02:10:12 -0600 From: "Jim Sermersheim" To: , Subject: Re: Attribute Name Length Bounds Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. I don't like adding an upper limit. Right now, the LDAP TS doesn't specify any limit (an attribute name can be from 1 to infinite in length). The TS neither limits the length, nor allows a protocol peer to ignore data exceeding any length. The only actual problem I've heard articulated is that it doesn't explicitly forbid a protocol peer from ignoring data exceeding any length. Some argue that such a specification is redundant and not needed (do we really need to state in every protocol specification that protocol peers MUST NOT arbitrarily truncate PDU data?) My question at this point is: Do we need a statement like this? Is there language (or absence of language) that made an implementor think they were following the TS when they chose to ignore the 33rd and higher octets in attribute names passed in protocol? If this is just a case of an implementation not allowing (by means of returning an error) more than 32 characters for attribute names, it seems like an application issue. It's no different from an implementation returning an error for DNs that exceed 32 characters, or a host of other similar implementation-imposed limitations. Jim >>> John Strassner 6/24/03 10:08:22 PM >>> Since I have rather strong views on this, I thought I would carefully read the thread and then provide some insight as to how decisions made in LDAPbis could affect various fora and standards bodies. I've now gone through the thread twice, and still have the same conclusion - prescribing an attribute name length bound is BAD. I'm not going to rehash any of the other arguments, because my feeling is that the WG is at somewhat of an impasse here. However, I will present an argument with new data, which is based on **users** wishing to develop directory schemata and finding that existing implementations have severe interoperability problems. There are numerous standards bodies and fora, ranging from the TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web Services efforts, that have as part of their standards relatively long names. For those that are using UML (or UML-like) approaches, this takes the form of very long (> 64 characters is common) class, attribute, and relationship (e.g., association, aggregation, composition, etc.) names. The basic way that many of these schemata are designed uses a standard and simple method to generate the name of relationships: . Note that the order may also be . Thus, whether a class or an attribute name could conceivably be shortened, it is almost certain that the relationship won't be able to be shortened a sufficient amount to do any good. More importantly, however, as a schema designer, I find it unaccceptable that my schema has to go through some bizarre machinations when being transformed from an information model to a data model just so it has a prayer of being implemented in a directory. This is a great way to encourage people NOT to use a directory. The mapping is difficult enough as it is - coming up with some difficult alias schemes, or methodology for name shortening, is not conformant to the basic schema that was agreed to by the standard body or fora in the first place. Furthermore, once one "buys into" any type of translation mechanism to produce different names, it is guaranteed to cause interoperability problems, simply because it is too hard to guarantee that two different implementations will apply the same rule to produce the same name. The examples listed above cover a very large body of work in different disciplines. Restricting name length to some arbitrary limit is inherently bad, as it flies in the face of the standards bodies and fora that are trying to use directories in the first place. They also exacerbate existing interoperability problems. This WG might not have identified issues such as these explicitly as part of its charter, but it should consider them, since its fundamental purpose is to produce a draft standard. That requires interoperability. Please, let's not ruin LDAP as it starts to mature. regards, John John Strassner Chief Strategy Officer Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 USA phone: +1.719.785.0648 FAX: +1.719.785.0644 email: john.strassner@intelliden.com From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 04:42: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 EAA04932 for ; Wed, 25 Jun 2003 04:42:31 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P8bnkf090657; Wed, 25 Jun 2003 08:40:28 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 h5P8YanZ090557; Wed, 25 Jun 2003 08:34:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 08:34:36 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P8YTkb090525; Wed, 25 Jun 2003 08:34:30 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19V5jV-0007lD-00; Wed, 25 Jun 2003 10:34:25 +0200 Received: from [129.240.130.14] (helo=mons.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.14) id 19V5jR-0002PZ-Is; Wed, 25 Jun 2003 10:34:21 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 19V5jQ-0001cE-00; Wed, 25 Jun 2003 10:34:21 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19V5jQ-0004xQ-00; Wed, 25 Jun 2003 10:34:20 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> References: <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 25 Jun 2003 10:34:20 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: >>> 2.2. Map >>> >>> All other control code points (e.g., Cc) or code points with a control >>> function (e.g., Cf) are mapped to nothing. >>> >>> ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points >>> with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or >>> Zp) are mapped to SPACE (U+0020). >> >>Can you list these (mostly as character ranges, I hope), or are there >>too many of them? > > I could. But I prefer to say it once than twice to avoid possible > inconsistencies. I am not adverse to adding an informative mapping > table as an appendix. Would that adequately address your concern? That's fine. >>For syntaxes/matching rules that expect non-empty strings, character >>removal in step 2.2 can change a valid (non-empty) string to an invalid >>(empty) one. > > If either the presented or stored values are mapped to empty > strings, then the match is Undefined. Well, that's exactly my problem. I think invalid strings should not be inserted in the directory, and valid strings should compare as true or false. I don't like valid strings that do not compare as true or false. I would't have a problem if non-empty strings that are mapped to "" were invalid so they couldn't even be inserted in the directory. But that looks like another big can of worms, I don't think we want to go there. > I don't see that as being much of a problem, especially since > caseIgnoreIA5Match("",X) can be argued should behave just like > caseIgnoreMatch("",X)... evaluated to Undefined. But it isn't "" which is compared to X. It's "" or something. >>If that happens, I suggest a SPACE should be inserted for >>matching rules where space can be insignificant. > > I think this would be bad as caseIgnoreMatch(""," ") would > evaluate to TRUE not Undefined. No, I did not mean "" to map to " ". Only insert a space if a non-empty string would map to an empty one. >>For the same reason, >> >>> 2.6.1. Insignificant Space Removal > > I suggest combining the statement with the previous paragraph: > > A string consisting entirely of spaces is to be replaced with a > string of exactly one space. Otherwise, the following spaces are > regarded are to be removed: Fine. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 04:44:59 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 EAA04988 for ; Wed, 25 Jun 2003 04:44:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P8hnkl091049; Wed, 25 Jun 2003 08:43: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 h5P8eeiD090828; Wed, 25 Jun 2003 08:40:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 08:40:40 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P8eMkb090792; Wed, 25 Jun 2003 08:40:22 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19V5pC-0000hW-00; Wed, 25 Jun 2003 10:40:18 +0200 Received: from [129.240.130.14] (helo=mons.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.14) id 19V5pB-0003DT-8v; Wed, 25 Jun 2003 10:40:17 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 19V5pB-0002Qi-00; Wed, 25 Jun 2003 10:40:17 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19V5pA-0004yT-00; Wed, 25 Jun 2003 10:40:16 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: References: <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 25 Jun 2003 10:40:16 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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 wrote: >Kurt D. Zeilenga writes: >> >> A string consisting entirely of spaces is to be replaced with a >> string of exactly one space. Otherwise, the following spaces are >> regarded are to be removed: > > Fine. On second thought, I think "are regarded" should go away. "are regarded are" looks strange. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 04:45:04 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 EAA05004 for ; Wed, 25 Jun 2003 04:45: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 h5P8hnkj091049; Wed, 25 Jun 2003 08:43: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 h5P8gq9L090960; Wed, 25 Jun 2003 08:42:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 08:42:52 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P8gokb090943 for ; Wed, 25 Jun 2003 08:42:50 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19V5rZ-00012I-00; Wed, 25 Jun 2003 10:42:45 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.14) id 19V5rU-0003Wf-B0; Wed, 25 Jun 2003 10:42:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19V5rU-0007VI-00; Wed, 25 Jun 2003 10:42:40 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19V5rT-0004zd-00; Wed, 25 Jun 2003 10:42:39 +0200 From: Hallvard B Furuseth Message-Id: To: "Ramsay, Ron" Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <1395B4B334FCC143B36AF788E68B638139AE93@ausyms21.ca.com> References: <1395B4B334FCC143B36AF788E68B638139AE93@ausyms21.ca.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 25 Jun 2003 10:42:39 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Ramsay, Ron writes: > Surely you can't do strprep on PrintableString? The choice of > characters is so limited that there can't be any translation? There are no UTF-8 characters to translate, but spaces can be removed. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 05:35:58 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 FAA05607 for ; Wed, 25 Jun 2003 05:35:58 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P9Vokf093591; Wed, 25 Jun 2003 09:33:20 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 h5P9Tljr093498; Wed, 25 Jun 2003 09:29:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 09:29:47 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P9Tkkb093467 for ; Wed, 25 Jun 2003 09:29:46 GMT (envelope-from Ron.Ramsay@ca.com) Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Jun 2003 19:29:24 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Date: Wed, 25 Jun 2003 19:29:24 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638139B521@ausyms21.ca.com> Thread-Topic: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Thread-Index: AcM69cRAQ90vrWYhQNqq+VWtDd/AlAABlRhQ From: "Ramsay, Ron" To: "Hallvard B Furuseth" Cc: X-OriginalArrivalTime: 25 Jun 2003 09:29:24.0706 (UTC) FILETIME=[4435EC20:01C33AFC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5P9Tlkb093489 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 Spaces can only be removed if the equality matching rule is caseIgnoreMatch or caseExactMatch? -----Original Message----- From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Wednesday, 25 June 2003 18:43 To: Ramsay, Ron Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Ramsay, Ron writes: > Surely you can't do strprep on PrintableString? The choice of > characters is so limited that there can't be any translation? There are no UTF-8 characters to translate, but spaces can be removed. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 05:59:33 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 FAA05936 for ; Wed, 25 Jun 2003 05:59:33 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P9tnkf094390; Wed, 25 Jun 2003 09:58:25 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 h5P9oV6L094234; Wed, 25 Jun 2003 09:50:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 09:50:31 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5P9oTkb094214 for ; Wed, 25 Jun 2003 09:50:29 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19V6v2-0003nX-00; Wed, 25 Jun 2003 11:50:24 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.14) id 19V6ux-0004w3-Tb; Wed, 25 Jun 2003 11:50:19 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19V6uz-0006SI-00; Wed, 25 Jun 2003 11:50:21 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19V6uu-0005AT-00; Wed, 25 Jun 2003 11:50:16 +0200 From: Hallvard B Furuseth Message-Id: To: "Ramsay, Ron" Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <1395B4B334FCC143B36AF788E68B638139B521@ausyms21.ca.com> References: <1395B4B334FCC143B36AF788E68B638139B521@ausyms21.ca.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 25 Jun 2003 11:50:16 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Ramsay, Ron writes: > Spaces can only be removed if the equality matching rule is > caseIgnoreMatch or caseExactMatch? Any matching rule which ignores space, I should hope. Including caseExactIA5Match and caseIgnoreIA5Match. See [Syntaxes] 5.2. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 07:17:10 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 HAA06835 for ; Wed, 25 Jun 2003 07:17:10 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PB7okf097176; Wed, 25 Jun 2003 11:15:29 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 h5PB751c097117; Wed, 25 Jun 2003 11:07:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 11:07:05 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PB71kb097074; Wed, 25 Jun 2003 11:07:01 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19V877-0005te-00; Wed, 25 Jun 2003 13:06:57 +0200 Received: from [129.240.130.19] (helo=miss.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.14) id 19V874-0007qo-2D; Wed, 25 Jun 2003 13:06:54 +0200 Received: from bombur.uio.no ([129.240.186.42]) by miss.uio.no with esmtp (Exim 2.12 #7) id 19V873-0000Ok-00; Wed, 25 Jun 2003 13:06:53 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19V873-0005M7-00; Wed, 25 Jun 2003 13:06:53 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: References: <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 25 Jun 2003 13:06:53 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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 wrote: >Kurt D. Zeilenga writes: > >>>> 2.2. Map >>>For syntaxes/matching rules that expect non-empty strings, character >>>removal in step 2.2 can change a valid (non-empty) string to an invalid >>>(empty) one. >> >> If either the presented or stored values are mapped to empty >> strings, then the match is Undefined. > > Well, that's exactly my problem. I think invalid strings should not be > inserted in the directory, and valid strings should compare as true or > false. I don't like valid strings that do not compare as true or false. > > I would't have a problem if non-empty strings that are mapped to "" were > invalid so they couldn't even be inserted in the directory. But that > looks like another big can of worms, I don't think we want to go there. Perhaps I should add a little here. [Models] 2.3 (Structure of an Entry) says: No two values of an attribute may be equivalent. Two values are considered equivalent if they would match according to the equality matching rule of the attribute type. So what happens if I attempt to give an attribute in an entry two valid values that map to "" and thus match as undefined? Are the values equivalent, or not? - If they are not equivalent, then we can put several "" values in one attribute in an entry. - If they are equivalent, then we can only add the value "" if the attribute has no other values. After that, an attempt to add _any_ value will fail. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 07:38: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 HAA07110 for ; Wed, 25 Jun 2003 07:38:00 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PBVtkf098792; Wed, 25 Jun 2003 11:36: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 h5PBQcq2098386; Wed, 25 Jun 2003 11:26:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 11:26:38 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PBQZkb098351; Wed, 25 Jun 2003 11:26:35 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19V8Q3-0000TO-00; Wed, 25 Jun 2003 13:26:31 +0200 Received: from [129.240.130.14] (helo=mons.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.14) id 19V8Q1-0002J8-D7; Wed, 25 Jun 2003 13:26:29 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 19V8Q1-00050B-00; Wed, 25 Jun 2003 13:26:29 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19V8Q0-0005Pd-00; Wed, 25 Jun 2003 13:26:28 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: References: <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 25 Jun 2003 13:26:28 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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 wrote: > So what happens if I attempt to give an attribute in an entry two valid > values that map to "" and thus match as undefined? Are the values > equivalent, or not? Sorry, I mean two valid values where at least one maps to "", so they match as undefined. Hopefully this will be the last followup-to-self for a while... -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 09:32:42 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 JAA08973 for ; Wed, 25 Jun 2003 09:32:41 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PDPpkf005422; Wed, 25 Jun 2003 13:30:09 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 h5PDN5uB005301; Wed, 25 Jun 2003 13:23:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 13:23:05 +0000 Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PDN4kb005274 for ; Wed, 25 Jun 2003 13:23: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 h5PDMcE18770 for ; Wed, 25 Jun 2003 06:22:38 -0700 (PDT) Received: from netscape.com ([10.169.27.69]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HH1H5O02.PF0; Wed, 25 Jun 2003 06:22:36 -0700 Message-ID: <3EF93638.7030401@netscape.com> Date: Tue, 24 Jun 2003 22:42:16 -0700 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030617 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Eric A. Hall" CC: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org, Steve McLain , Tom Doman Subject: Re: Specifying non-tcp transports referrals References: <3EF8BA04.9000004@ehsco.com> In-Reply-To: <3EF8BA04.9000004@ehsco.com> 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 Eric A. Hall wrote: > on 6/24/2003 1:12 PM Jim Sermersheim wrote: > > >>I believe it's assumed that the address in an LDAP URL >>(draft-ietf-ldapbis-url-03.txt) points to an LDAP server capable of >>communicating over TCP/IP. This is probably a bad assumption. Why is that a bad assumption? If and when someone wants to use URLs that support LDAP over a non-TCP transport, they can define an LDAP URL extension or a new URL scheme (as both Jim and Eric suggested). I do not think the LDAPBis documents need to say much if anything about this. -Mark From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 10:21:36 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 KAA11680 for ; Wed, 25 Jun 2003 10:21:35 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PEJpkf008036; Wed, 25 Jun 2003 14:20:18 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 h5PEFEnV007861; Wed, 25 Jun 2003 14:15:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 14:15:13 +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 h5PEFCkb007841 for ; Wed, 25 Jun 2003 14:15:12 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 25 Jun 2003 08:14:52 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Wed, 25 Jun 2003 08:13:23 -0600 From: "Jim Sermersheim" To: , Cc: "Steve McLain" , "Tom Doman" , Subject: Re: Specifying non-tcp transports referrals 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 assumed it was a bad assumption because as I looked closer at draft-ietf-ldapbis-url-03.txt, I found nothing to indicate that the LDAPURL is to be used for any particular transport. From what I can tell, it is only a defacto standard that this is always used for TCP/IP. >>> Mark C Smith 6/24/03 11:42:16 PM >>> Eric A. Hall wrote: > on 6/24/2003 1:12 PM Jim Sermersheim wrote: > > >>I believe it's assumed that the address in an LDAP URL >>(draft-ietf-ldapbis-url-03.txt) points to an LDAP server capable of >>communicating over TCP/IP. This is probably a bad assumption. Why is that a bad assumption? If and when someone wants to use URLs that support LDAP over a non-TCP transport, they can define an LDAP URL extension or a new URL scheme (as both Jim and Eric suggested). I do not think the LDAPBis documents need to say much if anything about this. -Mark From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 11:05:12 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 LAA13944 for ; Wed, 25 Jun 2003 11:05:11 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PEnpl5009780; Wed, 25 Jun 2003 15:02:26 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 h5PEf484009268; Wed, 25 Jun 2003 14:41:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 14:41:04 +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 h5PEf3kb009258 for ; Wed, 25 Jun 2003 14:41:03 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 h5PEf2c6096059; Wed, 25 Jun 2003 14:41:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 25 Jun 2003 07:38:01 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030624130612.01bdd0a8@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:06 AM 6/25/2003, Hallvard B Furuseth wrote: >Perhaps I should add a little here. >[Models] 2.3 (Structure of an Entry) says: > No two values of an attribute may be equivalent. > Two values are considered equivalent if they would match according to > the equality matching rule of the attribute type. > >So what happens if I attempt to give an attribute in an entry two valid >values that map to "" and thus match as undefined? Are the values >equivalent, or not? I'd argue, for attributes which have an EQUALITY RULE, that only values which EQUALITY(value,value) is True can be added to the directory. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 11:51:52 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 LAA18087 for ; Wed, 25 Jun 2003 11:51:52 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PFnpkf013145; Wed, 25 Jun 2003 15:50:28 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 h5PFhrJ9012874; Wed, 25 Jun 2003 15:43:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 15:43:53 +0000 Received: from mx-relay21.treas.gov (mx-relay21.treas.gov [199.196.132.5]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PFhokb012860 for ; Wed, 25 Jun 2003 15:43:50 GMT (envelope-from lbartz@parnelli.indy.cr.irs.gov) Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with SMTP id h5PFStRf011768; Wed, 25 Jun 2003 11:28:55 -0400 (EDT) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 25 Jun 2003 15:43:05 UT Received: from irsbd2.net.treas.gov (localhost [127.0.0.1]) by mailhub-21.net.treas.gov (8.12.9/8.12.9) with ESMTP id h5PFgxTM025760; Wed, 25 Jun 2003 11:42:59 -0400 (EDT) Received: from no.name.available by irsbd2.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.13.252.11]) with ESMTP; Wed, 25 Jun 2003 15:42:59 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h5PFgwf14501; Wed, 25 Jun 2003 10:42:58 -0500 Message-ID: <3EF9C302.20604@parnelli.indy.cr.irs.gov> Date: Wed, 25 Jun 2003 10:42:58 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: John.Strassner@intelliden.com, ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds 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 As a schema implementer, I require some assurance that Directory servers will uniformly support schema specifications which conform to some kind of consensus-based constraints. As a schema designer, I require the flexibility of assigning meaningful (and sometimes long) names to schema components. I have had the same experience of which Chris Apple wrote when he started this thread. It is obvious that since no constraints are specified in standards documents, Directory server providers are free to choose and set their own limits. This leads directly to interoperability problems. The problems are the direct result of underspecification. The non-spec leads to arbitrary implementation. I don't think it is reasonable to expect Directory implementations to support length-limitless names for the schema's object identifiers. I don't code Directory server software, but I expect that a limitless spec is an invitation to buffer overflow problems and/or resource exhaustion. In my previous contributions to this thread, I suggested that the RFC 3383 might serve as a guide, since consensus had already been achieved. That document specifies a limit on names of 48 characters. Considering other contributions to this thread, I don't think RFC 3383's 48 characters is enough. [As an aside, note that Kurt has just published a draft intended to replace RFC 3383. These considerations may impact the discussion of that draft, as well.] Instead, consider X.501. My reading of the 4th Edition indicates a length limit of 1024 characters is specified. Here is a pertinent excerpt from Annex C of X.501: DITStructureRuleDescription ::= SEQUENCE { COMPONENTS OF DITStructureRule, name [1] SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, description DirectoryString { ub-schema } OPTIONAL, obsolete BOOLEAN DEFAULT FALSE } DITContentRuleDescription ::= SEQUENCE { COMPONENTS OF DITContentRule, name [4] SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, description DirectoryString { ub-schema } OPTIONAL, obsolete BOOLEAN DEFAULT FALSE } MatchingRuleDescription ::= SEQUENCE { identifier MATCHING-RULE.&id, name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, description DirectoryString { ub-schema } OPTIONAL, obsolete BOOLEAN DEFAULT FALSE, information [0] DirectoryString { ub-schema } OPTIONAL } AttributeTypeDescription ::= SEQUENCE { identifier ATTRIBUTE.&id, name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, description DirectoryString { ub-schema } OPTIONAL, obsolete BOOLEAN DEFAULT FALSE, information [0] AttributeTypeInformation } ObjectClassDescription ::= SEQUENCE { identifier OBJECT-CLASS.&id, name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, description DirectoryString { ub-schema } OPTIONAL, obsolete BOOLEAN DEFAULT FALSE, information [0] ObjectClassInformation } NameFormDescription ::= SEQUENCE { identifier NAME-FORM.&id, name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, description DirectoryString { ub-schema } OPTIONAL, obsolete BOOLEAN DEFAULT FALSE, information [0] NameFormInformation } Note that the "name" component of each is specified with an upper bound of "ub-schema". Note that Annex C of X.520 4th Edition defines "ub-schema" as: ub-schema INTEGER ::= 1024 Can we agree that these considerations must apply to all of LDAP's object identifier descriptors, including attributetype names, objectclass names, matching rule names, etc? I suggest that we further follow X.501's lead and provide a length constraint of 1024 chars for LDAP's "DESC" stanzas as well. How about this language? "Implementations MUST, at minimum, support object identifier descriptors (such as attributetype names, objectclass names, matching rule names, and the like) which are 1024 characters in length. Implementations MUST, at minimum, support 'DESC' or description values which are 1024 characters in length. Implementations MAY support object identifier descriptors and/or 'DESC' values which exceed 1024 characters in length." Larry Jim Sermersheim wrote, On 06/25/03 03:10: > I agree. I don't like adding an upper limit. > > Right now, the LDAP TS doesn't specify any limit (an attribute name can > be from 1 to infinite in length). The TS neither limits the length, nor > allows a protocol peer to ignore data exceeding any length. > > The only actual problem I've heard articulated is that it doesn't > explicitly forbid a protocol peer from ignoring data exceeding any > length. Some argue that such a specification is redundant and not needed > (do we really need to state in every protocol specification that > protocol peers MUST NOT arbitrarily truncate PDU data?) > > My question at this point is: Do we need a statement like this? Is > there language (or absence of language) that made an implementor think > they were following the TS when they chose to ignore the 33rd and higher > octets in attribute names passed in protocol? > > If this is just a case of an implementation not allowing (by means of > returning an error) more than 32 characters for attribute names, it > seems like an application issue. It's no different from an > implementation returning an error for DNs that exceed 32 characters, or > a host of other similar implementation-imposed limitations. > > Jim > > > >>>>John Strassner 6/24/03 10:08:22 PM >>>> > > Since I have rather strong views on this, I thought I would carefully > read > the thread and then provide some insight as to how decisions made in > LDAPbis > could affect various fora and standards bodies. > > I've now gone through the thread twice, and still have the same > conclusion - > prescribing an attribute name length bound is BAD. > > I'm not going to rehash any of the other arguments, because my feeling > is > that the WG is at somewhat of an impasse here. However, I will present > an > argument with new data, which is based on **users** wishing to develop > directory schemata and finding that existing implementations have > severe > interoperability problems. > > There are numerous standards bodies and fora, ranging from the > TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web > Services > efforts, that have as part of their standards relatively long names. > For > those that are using UML (or UML-like) approaches, this takes the form > of > very long (> 64 characters is common) class, attribute, and > relationship > (e.g., association, aggregation, composition, etc.) names. The basic > way > that many of these schemata are designed uses a standard and simple > method > to generate the name of relationships: . Note > that > the order may also be . > > Thus, whether a class or an attribute name could conceivably be > shortened, > it is almost certain that the relationship won't be able to be > shortened a > sufficient amount to do any good. > > More importantly, however, as a schema designer, I find it > unaccceptable > that my schema has to go through some bizarre machinations when being > transformed from an information model to a data model just so it has a > prayer of being implemented in a directory. This is a great way to > encourage > people NOT to use a directory. > > The mapping is difficult enough as it is - coming up with some > difficult > alias schemes, or methodology for name shortening, is not conformant to > the > basic schema that was agreed to by the standard body or fora in the > first > place. > > Furthermore, once one "buys into" any type of translation mechanism to > produce different names, it is guaranteed to cause interoperability > problems, simply because it is too hard to guarantee that two > different > implementations will apply the same rule to produce the same name. > > The examples listed above cover a very large body of work in different > disciplines. Restricting name length to some arbitrary limit is > inherently > bad, as it flies in the face of the standards bodies and fora that are > trying to use directories in the first place. They also exacerbate > existing > interoperability problems. > > This WG might not have identified issues such as these explicitly as > part of > its charter, but it should consider them, since its fundamental purpose > is > to produce a draft standard. That requires interoperability. > > Please, let's not ruin LDAP as it starts to mature. > > > regards, > John > > John Strassner > Chief Strategy Officer > Intelliden Corporation > 90 South Cascade Avenue > Colorado Springs, CO 80903 USA > phone: +1.719.785.0648 > FAX: +1.719.785.0644 > email: john.strassner@intelliden.com > > > From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 13:09:14 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 NAA21505 for ; Wed, 25 Jun 2003 13:08: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 h5PGDqkr014940; Wed, 25 Jun 2003 16:24: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 h5PGCvP1014914; Wed, 25 Jun 2003 16:12:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 16:12:57 +0000 Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PGCkkb014900 for ; Wed, 25 Jun 2003 16:12:49 GMT (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-202-57.pskn.east.verizon.net [151.204.202.57]) by echt.caledonia.net; Wed, 25 Jun 2003 10:11:38 -0600 Reply-To: From: "Chris Apple" To: "'Jim Sermersheim'" , , Subject: RE: Attribute Name Length Bounds Date: Wed, 25 Jun 2003 12:11:15 -0400 Organization: DSI-Consulting, Inc. Message-ID: <002001c33b34$730a9f40$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: 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 completely agree that an upper limit would be bad. The IANA considerations mentioned earlier in this thread do place an upper limit on names which are to be registered. This doesn't affect the protocol, but does make the registry less useful than would be ideal. If someone can point out plausible scenarios in which harm is caused by adding a requirement of a SHOULD strength that attribute type names and object class names of "at least 64 octets in length," I'll withdraw the issue. However, I think its time the bar gets raised with respect to interoperability on this issue. Its fine to say (as suggested earlier in this thread) that one implementation responding with an error message or other indication of lack of support means that its interoperable. In the most basic sense of interoperability that is indeed true. Its just not as useful as the suggested requirement of a minimally supported length in the present operational environment for LDAPv3 implementations. As we move from PS to DS for LDAPv3, I think it would be a good idea to improve the usefulness of interoperability. We still have to have the more basic means of interoperability (such as saying when you don't support something using appropriate in-band methods). And we still have to improve that if needed. But only doing that as you move from PS to DS doesn't help improve the overall interoperability of the protocol as it is being used; it simply preserves ipso facto interoperability. That doesn't seem very useful to me as a user and service implementer. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim Sent: Wednesday, June 25, 2003 4:10 AM To: John.Strassner@intelliden.com; ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds I agree. I don't like adding an upper limit. Right now, the LDAP TS doesn't specify any limit (an attribute name can be from 1 to infinite in length). The TS neither limits the length, nor allows a protocol peer to ignore data exceeding any length. The only actual problem I've heard articulated is that it doesn't explicitly forbid a protocol peer from ignoring data exceeding any length. Some argue that such a specification is redundant and not needed (do we really need to state in every protocol specification that protocol peers MUST NOT arbitrarily truncate PDU data?) My question at this point is: Do we need a statement like this? Is there language (or absence of language) that made an implementor think they were following the TS when they chose to ignore the 33rd and higher octets in attribute names passed in protocol? If this is just a case of an implementation not allowing (by means of returning an error) more than 32 characters for attribute names, it seems like an application issue. It's no different from an implementation returning an error for DNs that exceed 32 characters, or a host of other similar implementation-imposed limitations. Jim >>> John Strassner 6/24/03 10:08:22 PM >>> Since I have rather strong views on this, I thought I would carefully read the thread and then provide some insight as to how decisions made in LDAPbis could affect various fora and standards bodies. I've now gone through the thread twice, and still have the same conclusion - prescribing an attribute name length bound is BAD. I'm not going to rehash any of the other arguments, because my feeling is that the WG is at somewhat of an impasse here. However, I will present an argument with new data, which is based on **users** wishing to develop directory schemata and finding that existing implementations have severe interoperability problems. There are numerous standards bodies and fora, ranging from the TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web Services efforts, that have as part of their standards relatively long names. For those that are using UML (or UML-like) approaches, this takes the form of very long (> 64 characters is common) class, attribute, and relationship (e.g., association, aggregation, composition, etc.) names. The basic way that many of these schemata are designed uses a standard and simple method to generate the name of relationships: . Note that the order may also be . Thus, whether a class or an attribute name could conceivably be shortened, it is almost certain that the relationship won't be able to be shortened a sufficient amount to do any good. More importantly, however, as a schema designer, I find it unaccceptable that my schema has to go through some bizarre machinations when being transformed from an information model to a data model just so it has a prayer of being implemented in a directory. This is a great way to encourage people NOT to use a directory. The mapping is difficult enough as it is - coming up with some difficult alias schemes, or methodology for name shortening, is not conformant to the basic schema that was agreed to by the standard body or fora in the first place. Furthermore, once one "buys into" any type of translation mechanism to produce different names, it is guaranteed to cause interoperability problems, simply because it is too hard to guarantee that two different implementations will apply the same rule to produce the same name. The examples listed above cover a very large body of work in different disciplines. Restricting name length to some arbitrary limit is inherently bad, as it flies in the face of the standards bodies and fora that are trying to use directories in the first place. They also exacerbate existing interoperability problems. This WG might not have identified issues such as these explicitly as part of its charter, but it should consider them, since its fundamental purpose is to produce a draft standard. That requires interoperability. Please, let's not ruin LDAP as it starts to mature. regards, John John Strassner Chief Strategy Officer Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 USA phone: +1.719.785.0648 FAX: +1.719.785.0644 email: john.strassner@intelliden.com From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 13:57:46 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 NAA23035 for ; Wed, 25 Jun 2003 13:57:46 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PHntl1020210; Wed, 25 Jun 2003 17:56:16 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 h5PHXA2v019094; Wed, 25 Jun 2003 17:33:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 17:33:10 +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 h5PHX7kb019084 for ; Wed, 25 Jun 2003 17:33:07 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 h5PHX6c6096969; Wed, 25 Jun 2003 17:33:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030625101129.01ab6e68@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 25 Jun 2003 10:30:05 -0700 To: "Larry S. Bartz" From: "Kurt D. Zeilenga" Subject: Re: Attribute Name Length Bounds Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3EF9C302.20604@parnelli.indy.cr.irs.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Larry, No server is required to support open-ended schema. Requirements for such servers supporting open-ended schema don't belong in the LDAP TS, they belong in an applicability statement for servers supporting open-ended schema. The "assurance" is then provided by developers who claim their server adheres to this applicability statement. At 08:42 AM 6/25/2003, Larry S. Bartz wrote: >"Implementations MUST, at minimum, support object identifier >descriptors (such as attributetype names, objectclass names, >matching rule names, and the like) which are 1024 characters >in length. Today, servers must be able to handle descriptors of any length but are not required to otherwise support descriptors of any length. Your suggestion would not only require servers to otherwise support names which they need not, but would imply that a server need not handle names longer than 1024. The former is problematic because no server is required to support open-ended schema and the latter is problematic as servers need to be able to handle all legal PDUs to avoid protocol interoperability problems. >Implementations MUST, at minimum, support 'DESC' or >description values which are 1024 characters in length. >Implementations MAY support object identifier descriptors >and/or 'DESC' values which exceed 1024 characters in length." Likewise. >Larry > > >Jim Sermersheim wrote, On 06/25/03 03:10: >>I agree. I don't like adding an upper limit. >>Right now, the LDAP TS doesn't specify any limit (an attribute name can >>be from 1 to infinite in length). The TS neither limits the length, nor >>allows a protocol peer to ignore data exceeding any length. >>The only actual problem I've heard articulated is that it doesn't >>explicitly forbid a protocol peer from ignoring data exceeding any >>length. Some argue that such a specification is redundant and not needed >>(do we really need to state in every protocol specification that >>protocol peers MUST NOT arbitrarily truncate PDU data?) >>My question at this point is: Do we need a statement like this? Is >>there language (or absence of language) that made an implementor think >>they were following the TS when they chose to ignore the 33rd and higher >>octets in attribute names passed in protocol? >>If this is just a case of an implementation not allowing (by means of >>returning an error) more than 32 characters for attribute names, it >>seems like an application issue. It's no different from an >>implementation returning an error for DNs that exceed 32 characters, or >>a host of other similar implementation-imposed limitations. >>Jim >> >> >>>>>John Strassner 6/24/03 10:08:22 PM >>Since I have rather strong views on this, I thought I would carefully >>read >>the thread and then provide some insight as to how decisions made in >>LDAPbis >>could affect various fora and standards bodies. >> >>I've now gone through the thread twice, and still have the same >>conclusion - >>prescribing an attribute name length bound is BAD. >> >>I'm not going to rehash any of the other arguments, because my feeling >>is >>that the WG is at somewhat of an impasse here. However, I will present >>an >>argument with new data, which is based on **users** wishing to develop >>directory schemata and finding that existing implementations have >>severe >>interoperability problems. >> >>There are numerous standards bodies and fora, ranging from the >>TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web >>Services >>efforts, that have as part of their standards relatively long names. >>For >>those that are using UML (or UML-like) approaches, this takes the form >>of >>very long (> 64 characters is common) class, attribute, and >>relationship >>(e.g., association, aggregation, composition, etc.) names. The basic >>way >>that many of these schemata are designed uses a standard and simple >>method >>to generate the name of relationships: . Note >>that >>the order may also be . >> >>Thus, whether a class or an attribute name could conceivably be >>shortened, >>it is almost certain that the relationship won't be able to be >>shortened a >>sufficient amount to do any good. >> >>More importantly, however, as a schema designer, I find it >>unaccceptable >>that my schema has to go through some bizarre machinations when being >>transformed from an information model to a data model just so it has a >>prayer of being implemented in a directory. This is a great way to >>encourage >>people NOT to use a directory. >> >>The mapping is difficult enough as it is - coming up with some >>difficult >>alias schemes, or methodology for name shortening, is not conformant to >>the >>basic schema that was agreed to by the standard body or fora in the >>first >>place. >> >>Furthermore, once one "buys into" any type of translation mechanism to >>produce different names, it is guaranteed to cause interoperability >>problems, simply because it is too hard to guarantee that two >>different >>implementations will apply the same rule to produce the same name. >> >>The examples listed above cover a very large body of work in different >>disciplines. Restricting name length to some arbitrary limit is >>inherently >>bad, as it flies in the face of the standards bodies and fora that are >>trying to use directories in the first place. They also exacerbate >>existing >>interoperability problems. >> >>This WG might not have identified issues such as these explicitly as >>part of >>its charter, but it should consider them, since its fundamental purpose >>is >>to produce a draft standard. That requires interoperability. >> >>Please, let's not ruin LDAP as it starts to mature. >> >>regards, >>John >>John Strassner >>Chief Strategy Officer >>Intelliden Corporation >>90 South Cascade Avenue >>Colorado Springs, CO 80903 USA >>phone: +1.719.785.0648 >> FAX: +1.719.785.0644 >>email: john.strassner@intelliden.com >> > > From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 14:40: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 OAA24763 for ; Wed, 25 Jun 2003 14:40: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 h5PIVqkr024246; Wed, 25 Jun 2003 18:38:45 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 h5PITBAR024048; Wed, 25 Jun 2003 18:29:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 18:29:10 +0000 Received: from tconl91223.tconl.com ([65.217.190.62]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PIT7kb024008 for ; Wed, 25 Jun 2003 18:29:07 GMT (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h5PIQQa03190; Wed, 25 Jun 2003 13:26:26 -0500 Date: Wed, 25 Jun 2003 13:26:26 -0500 From: Ryan Moats To: "Larry S. Bartz" Cc: Jim Sermersheim , John.Strassner@intelliden.com, ietf-ldapbis@OpenLDAP.org Subject: Re: Attribute Name Length Bounds Message-ID: <20030625132626.F1619@privateer> Reply-To: rmoats@lemurnetworks.net References: <3EF9C302.20604@parnelli.indy.cr.irs.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3EF9C302.20604@parnelli.indy.cr.irs.gov>; from lbartz@parnelli.indy.cr.irs.gov on Wed, Jun 25, 2003 at 10:42:58AM -0500 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I can live with this. Ryan On Wed, Jun 25, 2003 at 10:42:58AM -0500, Larry S. Bartz wrote: | As a schema implementer, I require some assurance that Directory | servers will uniformly support schema specifications which conform | to some kind of consensus-based constraints. As a schema designer, | I require the flexibility of assigning meaningful (and sometimes | long) names to schema components. | | I have had the same experience of which Chris Apple wrote when he | started this thread. It is obvious that since no constraints are | specified in standards documents, Directory server providers are | free to choose and set their own limits. This leads directly to | interoperability problems. The problems are the direct result of | underspecification. The non-spec leads to arbitrary implementation. | | I don't think it is reasonable to expect Directory implementations | to support length-limitless names for the schema's object identifiers. | I don't code Directory server software, but I expect that a | limitless spec is an invitation to buffer overflow problems and/or | resource exhaustion. | | In my previous contributions to this thread, I suggested that the | RFC 3383 might serve as a guide, since consensus had already been | achieved. That document specifies a limit on names of 48 characters. | Considering other contributions to this thread, I don't think | RFC 3383's 48 characters is enough. [As an aside, note that Kurt | has just published a draft intended to replace RFC 3383. These | considerations may impact the discussion of that draft, as well.] | | Instead, consider X.501. My reading of the 4th Edition indicates | a length limit of 1024 characters is specified. Here is a pertinent | excerpt from Annex C of X.501: | | | DITStructureRuleDescription ::= SEQUENCE { | COMPONENTS OF DITStructureRule, | name [1] SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, | description DirectoryString { ub-schema } OPTIONAL, | obsolete BOOLEAN DEFAULT FALSE } | | DITContentRuleDescription ::= SEQUENCE { | COMPONENTS OF DITContentRule, | name [4] SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, | description DirectoryString { ub-schema } OPTIONAL, | obsolete BOOLEAN DEFAULT FALSE } | | MatchingRuleDescription ::= SEQUENCE { | identifier MATCHING-RULE.&id, | name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, | description DirectoryString { ub-schema } OPTIONAL, | obsolete BOOLEAN DEFAULT FALSE, | information [0] DirectoryString { ub-schema } OPTIONAL } | | AttributeTypeDescription ::= SEQUENCE { | identifier ATTRIBUTE.&id, | name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, | description DirectoryString { ub-schema } OPTIONAL, | obsolete BOOLEAN DEFAULT FALSE, | information [0] AttributeTypeInformation } | | ObjectClassDescription ::= SEQUENCE { | identifier OBJECT-CLASS.&id, | name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, | description DirectoryString { ub-schema } OPTIONAL, | obsolete BOOLEAN DEFAULT FALSE, | information [0] ObjectClassInformation } | | NameFormDescription ::= SEQUENCE { | identifier NAME-FORM.&id, | name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL, | description DirectoryString { ub-schema } OPTIONAL, | obsolete BOOLEAN DEFAULT FALSE, | information [0] NameFormInformation } | | | Note that the "name" component of each is specified with an upper | bound of "ub-schema". Note that Annex C of X.520 4th Edition defines | "ub-schema" as: | | | ub-schema INTEGER ::= 1024 | | | Can we agree that these considerations must apply to all of LDAP's | object identifier descriptors, including attributetype names, | objectclass names, matching rule names, etc? I suggest that we further | follow X.501's lead and provide a length constraint of 1024 chars | for LDAP's "DESC" stanzas as well. | | How about this language? | | "Implementations MUST, at minimum, support object identifier | descriptors (such as attributetype names, objectclass names, | matching rule names, and the like) which are 1024 characters | in length. Implementations MUST, at minimum, support 'DESC' or | description values which are 1024 characters in length. | Implementations MAY support object identifier descriptors | and/or 'DESC' values which exceed 1024 characters in length." | | Larry | | | Jim Sermersheim wrote, On 06/25/03 03:10: | > I agree. I don't like adding an upper limit. | > | > Right now, the LDAP TS doesn't specify any limit (an attribute name can | > be from 1 to infinite in length). The TS neither limits the length, nor | > allows a protocol peer to ignore data exceeding any length. | > | > The only actual problem I've heard articulated is that it doesn't | > explicitly forbid a protocol peer from ignoring data exceeding any | > length. Some argue that such a specification is redundant and not needed | > (do we really need to state in every protocol specification that | > protocol peers MUST NOT arbitrarily truncate PDU data?) | > | > My question at this point is: Do we need a statement like this? Is | > there language (or absence of language) that made an implementor think | > they were following the TS when they chose to ignore the 33rd and higher | > octets in attribute names passed in protocol? | > | > If this is just a case of an implementation not allowing (by means of | > returning an error) more than 32 characters for attribute names, it | > seems like an application issue. It's no different from an | > implementation returning an error for DNs that exceed 32 characters, or | > a host of other similar implementation-imposed limitations. | > | > Jim | > | > | > | >>>>John Strassner 6/24/03 10:08:22 PM | >>>> | > | > Since I have rather strong views on this, I thought I would carefully | > read | > the thread and then provide some insight as to how decisions made in | > LDAPbis | > could affect various fora and standards bodies. | > | > I've now gone through the thread twice, and still have the same | > conclusion - | > prescribing an attribute name length bound is BAD. | > | > I'm not going to rehash any of the other arguments, because my feeling | > is | > that the WG is at somewhat of an impasse here. However, I will present | > an | > argument with new data, which is based on **users** wishing to develop | > directory schemata and finding that existing implementations have | > severe | > interoperability problems. | > | > There are numerous standards bodies and fora, ranging from the | > TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web | > Services | > efforts, that have as part of their standards relatively long names. | > For | > those that are using UML (or UML-like) approaches, this takes the form | > of | > very long (> 64 characters is common) class, attribute, and | > relationship | > (e.g., association, aggregation, composition, etc.) names. The basic | > way | > that many of these schemata are designed uses a standard and simple | > method | > to generate the name of relationships: . Note | > that | > the order may also be . | > | > Thus, whether a class or an attribute name could conceivably be | > shortened, | > it is almost certain that the relationship won't be able to be | > shortened a | > sufficient amount to do any good. | > | > More importantly, however, as a schema designer, I find it | > unaccceptable | > that my schema has to go through some bizarre machinations when being | > transformed from an information model to a data model just so it has a | > prayer of being implemented in a directory. This is a great way to | > encourage | > people NOT to use a directory. | > | > The mapping is difficult enough as it is - coming up with some | > difficult | > alias schemes, or methodology for name shortening, is not conformant to | > the | > basic schema that was agreed to by the standard body or fora in the | > first | > place. | > | > Furthermore, once one "buys into" any type of translation mechanism to | > produce different names, it is guaranteed to cause interoperability | > problems, simply because it is too hard to guarantee that two | > different | > implementations will apply the same rule to produce the same name. | > | > The examples listed above cover a very large body of work in different | > disciplines. Restricting name length to some arbitrary limit is | > inherently | > bad, as it flies in the face of the standards bodies and fora that are | > trying to use directories in the first place. They also exacerbate | > existing | > interoperability problems. | > | > This WG might not have identified issues such as these explicitly as | > part of | > its charter, but it should consider them, since its fundamental purpose | > is | > to produce a draft standard. That requires interoperability. | > | > Please, let's not ruin LDAP as it starts to mature. | > | > | > regards, | > John | > | > John Strassner | > Chief Strategy Officer | > Intelliden Corporation | > 90 South Cascade Avenue | > Colorado Springs, CO 80903 USA | > phone: +1.719.785.0648 | > FAX: +1.719.785.0644 | > email: john.strassner@intelliden.com | > | > | > From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 16:42:17 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 QAA01376 for ; Wed, 25 Jun 2003 16:42: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 h5PJxfkb032208; Wed, 25 Jun 2003 19:59: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 h5PJiOm7031063; Wed, 25 Jun 2003 19:44:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 19:44:24 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PJiJkb031008; Wed, 25 Jun 2003 19:44:20 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19VGBj-0000RI-00; Wed, 25 Jun 2003 21:44:15 +0200 Received: from [129.240.130.14] (helo=mons.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.14) id 19VGBh-0000hQ-Q6; Wed, 25 Jun 2003 21:44:13 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 19VGBf-0004jN-00; Wed, 25 Jun 2003 21:44:11 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19VGBe-0006cJ-00; Wed, 25 Jun 2003 21:44:10 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> References: <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 25 Jun 2003 21:44:10 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt D. Zeilenga writes: > I'd argue, for attributes which have an EQUALITY RULE, that only > values which EQUALITY(value,value) is True can be added to the > directory. This diverges from X.500, doesn't it? Also, not that I mind, but it sounds a little like LDAPv4 to me... -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 16:45:25 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 QAA01549 for ; Wed, 25 Jun 2003 16:45:24 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PKhrkf034398; Wed, 25 Jun 2003 20:44: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 h5PKgG99034324; Wed, 25 Jun 2003 20:42:16 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 20:42:16 +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 h5PKgEkb034306 for ; Wed, 25 Jun 2003 20:42:14 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 h5PKgDc6098620; Wed, 25 Jun 2003 20:42:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 25 Jun 2003 13:39:12 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 12:44 PM 6/25/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> I'd argue, for attributes which have an EQUALITY RULE, that only >> values which EQUALITY(value,value) is True can be added to the >> directory. > >This diverges from X.500, doesn't it? >Also, not that I mind, but it sounds a little like LDAPv4 to me... Well, it might be a bit divergent. I'd have to carefully review X.501 to see what it says here. So let's reconsider the options here: >[Models] 2.3 (Structure of an Entry) says: > No two values of an attribute may be equivalent. > Two values are considered equivalent if they would match according to > the equality matching rule of the attribute type. > >So what happens if I attempt to give an attribute in an entry two valid >values that map to "" and thus match as undefined? Are the values >equivalent, or not? > >- If they are not equivalent, then we can put several "" > values in one attribute in an entry. Obviously that would be counter to X.501. >- If they are equivalent, then we can only add the value "" > if the attribute has no other values. After that, an attempt to add > _any_ value will fail. This, I believe, is consistent with X.501. That's how the matching rules behave. When I first read your suggestion, I assumed you wanted to replace "" with " ". I think I am fine with your suggestion that if the input to the mapping step is non-empty and the mapping would result in an empty string, the output is instead " ". This handles the map to "" issues, but it does nothing to allow both "foobar" and "barfoo" to co-exist as values of CN. Personally, I don't think "foobar" should be an allowed value of CN. Anyways, to implement this suggestion, I think I rather say that the output of the translation step must be non-empty (if empty, the preparation fails, match is Undefined). Remove the prohibition of empty strings in the prohibit section and insert the space during the insignificant space removal step. My rationale for doing it this way is that mapping and prohibition should be done on a character-by-character basis and string-wise things should be done either in first or last steps. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 17:43:16 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 RAA04795 for ; Wed, 25 Jun 2003 17:43:00 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PLWukn038643; Wed, 25 Jun 2003 21:38:10 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 h5PLJ3XE037283; Wed, 25 Jun 2003 21:19:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 21:19:03 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PLIvkb037228; Wed, 25 Jun 2003 21:18:58 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19VHfK-0001Sn-00; Wed, 25 Jun 2003 23:18:54 +0200 Received: from [129.240.130.14] (helo=mons.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.14) id 19VHfG-0002Bo-5T; Wed, 25 Jun 2003 23:18:50 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 19VHfF-0003fE-00; Wed, 25 Jun 2003 23:18:49 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19VHfF-0006pv-00; Wed, 25 Jun 2003 23:18:49 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> References: <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 25 Jun 2003 23:18:49 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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 12:44 PM 6/25/2003, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >> >>[Models] 2.3 (Structure of an Entry) says: >> >>So what happens if I attempt to give an attribute in an entry two valid >>values that map to "" and thus match as undefined? Are the values >>equivalent, or not? >> >>- If they are not equivalent, then we can put several "" >> values in one attribute in an entry. > > Obviously that would be counter to X.501. > >>- If they are equivalent, then we can only add the value "" >> if the attribute has no other values. After that, an attempt to add >> _any_ value will fail. > > This, I believe, is consistent with X.501. Well, if you say so. Both the alternatives I listed sound weird to me. But perhaps this is the best we can do. > That's how the matching rules behave. Well, it's how LDAP (and X.500?) {will} _use_ the matching rules. If I understand you correctly, the part of [Models] 2.3 which I quoted should be changed to something like If the attribute type has an equality matching rule, any two values of the attribute must compare as false according to that matching rule. > This handles the map to "" issues, but it does nothing to allow > both "foobar" and "barfoo" to co-exist as > values of CN. Nor does it let "foobar" to co-exist with _any_ value, since since they would match as Undefined whatever the other value is. > Personally, I don't think "foobar" > should be an allowed value of CN. No opinion. I don't even know what is. > Anyways, to implement this suggestion, I think I rather say that the > output of the translation step must be non-empty (if empty, > the preparation fails, match is Undefined). Remove the prohibition > of empty strings You mean, move the prohibition of empty strings from the Prohibit step to the Transcode step? > in the prohibit section and insert the space during > the insignificant space removal step. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 18:14: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 SAA06535 for ; Wed, 25 Jun 2003 18:14:00 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PL7xl1035885; Wed, 25 Jun 2003 21:17:21 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 h5PKsW3F034960; Wed, 25 Jun 2003 20:54:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 20:54:32 +0000 Received: from mx-relay21.treas.gov (mx-relay21.treas.gov [199.196.132.5]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PKsTkb034930; Wed, 25 Jun 2003 20:54:29 GMT (envelope-from lbartz@parnelli.indy.cr.irs.gov) Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with SMTP id h5PKeFRf011919; Wed, 25 Jun 2003 16:40:15 -0400 (EDT) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 25 Jun 2003 20:54:25 UT Received: from irsbd3.net.treas.gov (localhost [127.0.0.1]) by mailhub-21.net.treas.gov (8.12.9/8.12.9) with ESMTP id h5PKsJpe023750; Wed, 25 Jun 2003 16:54:19 -0400 (EDT) Received: from no.name.available by irsbd3.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.13.252.11]) with ESMTP; Thu, 26 Jun 2003 00:54:43 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h5PKsJf14981; Wed, 25 Jun 2003 15:54:19 -0500 Message-ID: <3EFA0BFB.50905@parnelli.indy.cr.irs.gov> Date: Wed, 25 Jun 2003 15:54:19 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapbis@OpenLDAP.org, lsbartz@parnelli.indy.cr.irs.gov Subject: Re: Attribute Name Length Bounds References: <5.2.0.9.0.20030625101129.01ab6e68@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030625101129.01ab6e68@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote, On 06/25/03 12:30: > Larry, > > No server is required to support open-ended schema. What is "open-ended schema"? > Requirements > for such servers supporting open-ended schema don't belong in the > LDAP TS, they belong in an applicability statement for servers > supporting open-ended schema. The "assurance" is then provided > by developers who claim their server adheres to this applicability > statement. I won't/haven't presume(d) to say whether LDAP TS is the right document to address this issue or not. It's just an issue right now, as far as I'm concerned. But it's definitely an issue which should be addressed by this WG. > > At 08:42 AM 6/25/2003, Larry S. Bartz wrote: > >>"Implementations MUST, at minimum, support object identifier >>descriptors (such as attributetype names, objectclass names, >>matching rule names, and the like) which are 1024 characters >>in length. > > > Today, servers must be able to handle descriptors of any length > but are not required to otherwise support descriptors of any > length. What is the difference between "handle" and "support"? How does that difference impinge upon the potential for one to implement a schema which contains long names on a server which has a relatively short name length limit? > > Your suggestion would not only require servers to otherwise > support names which they need not, but would imply that a > server need not handle names longer than 1024. The former > is problematic because no server is required to support > open-ended schema and the latter is problematic as servers > need to be able to handle all legal PDUs to avoid protocol > interoperability problems. > > >>Implementations MUST, at minimum, support 'DESC' or >>description values which are 1024 characters in length. >>Implementations MAY support object identifier descriptors >>and/or 'DESC' values which exceed 1024 characters in length." > > > Likewise. > > > [sound of light bulb clicking "ON"] Right. Both NAME and DESC are optional fields of various schema component descriptors. So by "open-ended schema" do you mean that they are optional for servers to support as well as optional for implementors to use? I haven't seen a server which didn't support NAME and DESC, so it didn't occur to me that some servers might not implement support for them. Try this: "Implementations which support the 'NAME' field of schema descriptors MUST, at minimum, support values for that field (such as attributetype names, objectclass names, matching rule names, and the like) which are 1024 characters in length. Implementations which support the 'DESC' field of schema descriptors MUST, at minimum, support values for that field which are 1024 characters in length. Implementations MAY support 'NAME' field values and/or 'DESC' field values which exceed 1024 characters in length." -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 18:19:29 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 SAA06897 for ; Wed, 25 Jun 2003 18:19:29 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PM7rkf042022; Wed, 25 Jun 2003 22:08:20 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 h5PM7Qcg041979; Wed, 25 Jun 2003 22:07:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 22:07:26 +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 h5PM7Okb041954 for ; Wed, 25 Jun 2003 22:07:24 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 h5PM7Nc6099454; Wed, 25 Jun 2003 22:07:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030625135220.01a99098@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 25 Jun 2003 15:04:22 -0700 To: "Larry S. Bartz" From: "Kurt D. Zeilenga" Subject: Re: Attribute Name Length Bounds Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3EFA0BFB.50905@parnelli.indy.cr.irs.gov> References: <5.2.0.9.0.20030625101129.01ab6e68@127.0.0.1> <5.2.0.9.0.20030625101129.01ab6e68@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 01:54 PM 6/25/2003, Larry S. Bartz wrote: >Kurt D. Zeilenga wrote, On 06/25/03 12:30: >>No server is required to support open-ended schema. >What is "open-ended schema"? I used "open-ended schema" as a short hand for "an open-ended set of schema elements." The LDAP TS does not require servers to support any schema element not defined in the LDAP TS. In fact, the LDAP TS does not even require servers to support all of the schema elements defined in the LDAP TS. Some servers support only schema elements which they are specifically designed to support. Other servers support schema specified by the administrator (or user), normally with significant implementation-specific constraints. This latter breed of servers can be viewed as supporting an open-ended set of schema elements. The concern seems to be that some implementations have constraints which you and others find to be quite limiting. It's my view that servers are quite free to limited their suitability in this fashion. What folks seem to want is raise the bar on servers which support open-ended sets of schema elements. That's quite a reasonable think to want to do. >I won't/haven't presume(d) to say whether LDAP TS is the right >document to address this issue or not. My point is that the LDAP TS is not the right place to address this issue. It's seems to me that this name length issue is one of many similar issues facing schema designers as well as those trying to determine whose server to deploy. It seems like the right document would be some sort of applicability statement for servers intending to support open-ended sets of schema and/or document providing schema design guidelines, and/or a document providing implementation guidelines. >>At 08:42 AM 6/25/2003, Larry S. Bartz wrote: >> >>>"Implementations MUST, at minimum, support object identifier >>>descriptors (such as attributetype names, objectclass names, >>>matching rule names, and the like) which are 1024 characters >>>in length. >> >>Today, servers must be able to handle descriptors of any length >>but are not required to otherwise support descriptors of any >>length. > >What is the difference between "handle" and "support"? As I used them, handle means that the server is capable of parsing the client's PDU and to take any one of the actions allowed it by the technical specification. Support means that the server would actually recognize the descriptor as being equivalent to one of the object identifiers it recognizes and supports. Or, to say it with an example, a server which doesn't support 'createTimestamp' should still be able to handle 'createTimestamp' appearing in PDUs in a manner consistent with the LDAP TS (that is, treat 'createTimestamp' as referring to an unrecognized attribute type). >How does >that difference impinge upon the potential for one to implement >a schema which contains long names on a server which has a >relatively short name length limit? 'handle' ensures protocol interoperability. I like to note that regardless of what attribute name limit one might add to the LDAP TS, that limit cannot rightly be viewed as requiring servers to support open-ended sets of schema elements in any particular manner. Aside from not being required to support open-ended sets of schema elements at all, servers are free to restrict the the sets of schema elements by any means (including very arbitrary ones). For example, the statement would not prevent a server supporting open-ended sets of schema elements from not supporting attribute types names starting with 'x-'. >So by "open-ended schema" do you mean.. See above. From owner-ietf-ldapbis@OpenLDAP.org Wed Jun 25 19:08: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 TAA10274 for ; Wed, 25 Jun 2003 19:08:18 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5PMJskf042740; Wed, 25 Jun 2003 22:22:31 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 h5PMGE0J042531; Wed, 25 Jun 2003 22:16:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 25 Jun 2003 22:16:13 +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 h5PMGCkb042521 for ; Wed, 25 Jun 2003 22:16:12 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 h5PMGBc6099523; Wed, 25 Jun 2003 22:16:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 25 Jun 2003 15:13:10 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 02:18 PM 6/25/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 12:44 PM 6/25/2003, Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>> >>>[Models] 2.3 (Structure of an Entry) says: >>> >>>So what happens if I attempt to give an attribute in an entry two valid >>>values that map to "" and thus match as undefined? Are the values >>>equivalent, or not? >>> >>>- If they are not equivalent, then we can put several "" >>> values in one attribute in an entry. >> >> Obviously that would be counter to X.501. >> >>>- If they are equivalent, then we can only add the value "" >>> if the attribute has no other values. After that, an attempt to add >>> _any_ value will fail. >> >> This, I believe, is consistent with X.501. > >Well, if you say so. Both the alternatives I listed sound weird to me. >But perhaps this is the best we can do. > >> That's how the matching rules behave. > >Well, it's how LDAP (and X.500?) {will} _use_ the matching rules. >If I understand you correctly, the part of [Models] 2.3 which I quoted >should be changed to something like > > If the attribute type has an equality matching rule, any two values of > the attribute must compare as false according to that matching rule. Yes. >> This handles the map to "" issues, but it does nothing to allow >> both "foobar" and "barfoo" to co-exist as >> values of CN. > >Nor does it let "foobar" to co-exist with _any_ >value, since since they would match as Undefined whatever the other >value is. Yes. >> Personally, I don't think "foobar" >> should be an allowed value of CN. > >No opinion. I don't even know what is. You might want to consider all the other cases where the preparation fails and hence the rule evaluation is Undefined. There are many. >> Anyways, to implement this suggestion, I think I rather say that the >> output of the translation step must be non-empty (if empty, >> the preparation fails, match is Undefined). Remove the prohibition >> of empty strings > >You mean, move the prohibition of empty strings from the Prohibit >step to the Transcode step? Yes. >> in the prohibit section and insert the space during >> the insignificant space removal step. From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 26 00:15:35 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 AAA24943 for ; Thu, 26 Jun 2003 00:15: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 h5Q47ukf058968; Thu, 26 Jun 2003 04:12:28 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 h5Q45YIE058924; Thu, 26 Jun 2003 04:05:34 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 26 Jun 2003 04:05:34 +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 h5Q45Vkb058913 for ; Thu, 26 Jun 2003 04:05:32 GMT (envelope-from steven.legg@adacel.com.au) Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Thu, 26 Jun 2003 14:01:31 +1000 Received: (qmail 23929 invoked from network); 26 Jun 2003 04:04:31 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 26 Jun 2003 04:04:31 -0000 Reply-To: From: "Steven Legg" To: "'Larry S. Bartz'" Cc: Subject: RE: Attribute Name Length Bounds Date: Thu, 26 Jun 2003 14:05:08 +1000 Message-ID: <007b01c33b98$22692610$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: <3EF9C302.20604@parnelli.indy.cr.irs.gov> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal 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 Larry, Larry S. Bartz wrote: > Instead, consider X.501. My reading of the 4th Edition indicates > a length limit of 1024 characters is specified. Here is a pertinent > excerpt from Annex C of X.501: > Can we agree that these considerations must apply to all of LDAP's > object identifier descriptors, including attributetype names, > objectclass names, matching rule names, etc? I suggest that we further > follow X.501's lead and provide a length constraint of 1024 chars > for LDAP's "DESC" stanzas as well. The length constraint of 1024 in X.500 is non-normative. It only carries the weight of a "suggestion". Implementors are free to impose any limit they like, less or greater. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 26 02:44: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 CAA10315 for ; Thu, 26 Jun 2003 02:43:47 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5Q6Dukf062377; Thu, 26 Jun 2003 06:18:02 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 h5Q6B6LO062313; Thu, 26 Jun 2003 06:11:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 26 Jun 2003 06:11:06 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5Q6B3kb062283; Thu, 26 Jun 2003 06:11:03 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19VPyF-0002cS-00; Thu, 26 Jun 2003 08:10:59 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.14) id 19VPyA-0007bH-O1; Thu, 26 Jun 2003 08:10:54 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19VPyA-0003HS-00; Thu, 26 Jun 2003 08:10:54 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19VPyA-0000TU-00; Thu, 26 Jun 2003 08:10:54 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> References: <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 26 Jun 2003 08:10:54 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: >>> Personally, I don't think "foobar" >>> should be an allowed value of CN. >> >> No opinion. I don't even know what is. > > You might want to consider all the other cases where the preparation > fails and hence the rule evaluation is Undefined. There are many. True. Well, I wouldn't want Private Use code points to be prohibited from existing in the directory, at least. They exist to be used, and someone who uses them will want to put them in LDAP. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 26 02:57:10 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 CAA10622 for ; Thu, 26 Jun 2003 02:57:10 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5Q6tvkf063406; Thu, 26 Jun 2003 06:56:11 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 h5Q6sfJ4063372; Thu, 26 Jun 2003 06:54:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 26 Jun 2003 06:54:41 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5Q6sckb063339; Thu, 26 Jun 2003 06:54:38 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19VQeQ-0007Rt-00; Thu, 26 Jun 2003 08:54:34 +0200 Received: from [129.240.130.19] (helo=miss.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.14) id 19VQdz-0006FJ-EA; Thu, 26 Jun 2003 08:54:07 +0200 Received: from bombur.uio.no ([129.240.186.42]) by miss.uio.no with esmtp (Exim 2.12 #7) id 19VQe0-0002ss-00; Thu, 26 Jun 2003 08:54:08 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19VQdw-0000ad-00; Thu, 26 Jun 2003 08:54:04 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> References: <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 26 Jun 2003 08:54:04 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: >> If I understand you correctly, the part of [Models] 2.3 which I >> quoted should be changed to something like >> >> If the attribute type has an equality matching rule, any two values >> of the attribute must compare as false according to that matching >> rule. > > Yes. In view of this, I'm beginning to dislike that Prohibit step. If I have a purely local LDAP directory, why shouldn't I be allowed to give an attribute two values where one uses a Private Use code point? Or to search for - and find - the one with a Private Use code point by searching for that exact string, at least? The results of choosing to do this would of course be my responsibility. I think it would be better if servers SHOULD implement the Prohibit step but MAY allow it to be turned off, and recommend that managers keep it turned on for globally accessible directories. Then make the problem with certificate chain validation a problem for certificates, not for string matching in general: Either prohibit the characters listed in the Prohibit step from existing in certificates, or say that the Prohibit step MUST be performed when checking components of certificates. In either case, these characters won't match anything. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 26 14:58:11 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 OAA14959 for ; Thu, 26 Jun 2003 14:57: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 h5QHQ0mF047506; Thu, 26 Jun 2003 18:02:36 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 h5QHLQ1m047203; Thu, 26 Jun 2003 17:21:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 26 Jun 2003 17:21:26 +0000 Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5QHLPkb047184 for ; Thu, 26 Jun 2003 17:21:25 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 h5QHKxE21323 for ; Thu, 26 Jun 2003 10:20:59 -0700 (PDT) Received: from netscape.com ([10.169.27.123]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HH3MUX00.7O3; Thu, 26 Jun 2003 10:20:57 -0700 Message-ID: <3EFB2B7E.5080202@netscape.com> Date: Thu, 26 Jun 2003 10:21:02 -0700 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030617 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ehall@ehsco.com, Steve McLain , Tom Doman , ietf-ldapbis@OpenLDAP.org Subject: Re: Specifying non-tcp transports referrals 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 assumed it was a bad assumption because as I looked closer at > draft-ietf-ldapbis-url-03.txt, I found nothing to indicate that the > LDAPURL is to be used for any particular transport. From what I can > tell, it is only a defacto standard that this is always used for > TCP/IP. The only well defined transport for LDAP is TCP. So I just assume that LDAP URLs must use TCP as a transport too. Are you saying that is too limiting? -Mark From owner-ietf-ldapbis@OpenLDAP.org Thu Jun 26 15:29:11 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 PAA17465 for ; Thu, 26 Jun 2003 15:29:10 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5QIi1lH056244; Thu, 26 Jun 2003 19:07:04 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 h5QIfZGq056103; Thu, 26 Jun 2003 18:41:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 26 Jun 2003 18:41:35 +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 h5QIfYkb056087 for ; Thu, 26 Jun 2003 18:41:34 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 26 Jun 2003 12:41:10 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 26 Jun 2003 12:39:37 -0600 From: "Jim Sermersheim" To: Cc: , "Steve McLain" , "Tom Doman" , Subject: Re: Specifying non-tcp transports referrals Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >The only well defined transport for LDAP is TCP. So I just assume that >LDAP URLs must use TCP as a transport too. Are you saying that is too >limiting? I'm just saying that it's under specified or ambiguous (I actually don't know if LDAP URLs can be used to specify transports other than TCP--I'd like it to be able to). The protocol doc says: "This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream." It doesn't limit to TCP, but it does go on to define how things work over TCP. So while TCP is the only well-defined transport, nothing limits LDAP to run over some other transport (as long as it follows the definition above). The other problem is (and maybe this is really a problem to be solved in [Protocol] is that a referral is a sequence of LDAPURL, where LDAPURL follows [LDAPURL]. And also we see in the referral definition: "Other kinds of URLs may be returned, so long as the operation could be performed using that protocol." To me, this means either [LDAPURL] needs to allow anything considered as an "Other kind of URL", or [Protocol] needs to be fixed to allow either URLs that follow [LDAPURL] or anything else. I also thing that if [LDAPURL] is meant to implicitly specify TCP, it should be called out. Jim From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 27 13:29: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 NAA08107 for ; Fri, 27 Jun 2003 13:28:46 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5RGu8kf055119; Fri, 27 Jun 2003 17:00: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 h5RGtDO7055105; Fri, 27 Jun 2003 16:55:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 27 Jun 2003 16:55:13 +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 h5RGtCkb055095 for ; Fri, 27 Jun 2003 16:55:12 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 h5RGtBc6018585; Fri, 27 Jun 2003 16:55:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030627093357.01bf45b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Jun 2003 09:52:12 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 11:54 PM 6/25/2003, Hallvard B Furuseth wrote: >>> If I understand you correctly, the part of [Models] 2.3 which I >>> quoted should be changed to something like >>> >>> If the attribute type has an equality matching rule, any two values >>> of the attribute must compare as false according to that matching >>> rule. >> >> Yes. > >In view of this, I'm beginning to dislike that Prohibit step. >If I have a purely local LDAP directory, why shouldn't I be allowed to >give an attribute two values where one uses a Private Use code point? These rules are designed for interoperability between independently developed implementations which you are likely to have even in local environments. If all directory agents do not agree on matching rule semantics, interoperability problems will occur. Some of these will have impact upon security. These matching rules are not just used by DSAs to locate information, but used in DUAs to correlate information provided by the DSAs. To be appropriate for naming of objects and values of security related attributes, I think the appearance of a Private Use code points in strings to be matched with these rules need to cause the evaluation to be Undefined. Note that one is always free to define other schema elements to meet local needs. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 27 15:55:19 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 PAA18119 for ; Fri, 27 Jun 2003 15:55: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 h5RJK9l7063529; Fri, 27 Jun 2003 19:36:52 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 h5RJHNrc063330; Fri, 27 Jun 2003 19:17:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 27 Jun 2003 19:17:23 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5RJHJkb063300; Fri, 27 Jun 2003 19:17:20 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19Vyih-0006XY-00; Fri, 27 Jun 2003 21:17:15 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.14) id 19Vyi7-0007g9-AT; Fri, 27 Jun 2003 21:16:39 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19Vyi6-0003o3-00; Fri, 27 Jun 2003 21:16:38 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19Vyi6-0006VW-00; Fri, 27 Jun 2003 21:16:38 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <5.2.0.9.0.20030627093357.01bf45b0@127.0.0.1> References: <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030627093357.01bf45b0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 27 Jun 2003 21:16:38 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: >> In view of this, I'm beginning to dislike that Prohibit step. >> If I have a purely local LDAP directory, why shouldn't I be allowed to >> give an attribute two values where one uses a Private Use code point? > > These rules are designed for interoperability between independently > developed implementations which you are likely to have even in > local environments. (...) We have at least two LDAP servers here (OpenLDAP and AD), but will never need any interoperability between them. Interoperability is important, but I think the price is too high sometimes. Like in this case. I don't like to have to pay too much for features I know I won't need. That's why I think the prohibit step should only be a SHOULD or RECOMMENDED, with a 'MAY allow admins to turn it off'. > Note that one is always free to define other schema elements to meet > local needs. That only helps if I can hack the server to add new matching rules, or if I'm satisfied with using Octet String for string data and don't need features like case-ignore matching. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 27 16:50: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 QAA20243 for ; Fri, 27 Jun 2003 16:50: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 h5RKc9l3067231; Fri, 27 Jun 2003 20:49:01 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 h5RKWEGn066836; Fri, 27 Jun 2003 20:32:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 27 Jun 2003 20:32:14 +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 h5RKWCkb066826 for ; Fri, 27 Jun 2003 20:32:12 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 h5RKWBc6020405; Fri, 27 Jun 2003 20:32:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030627131835.01b92b40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Jun 2003 13:29:11 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030627093357.01bf45b0@127.0.0.1> <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030627093357.01bf45b0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Hallvard, The way you worded your suggestion, the suggestion applies to all currently prohibited characters. That is problematic as prohibiting certain assigned code points as well as all unassigned code points is quite appropriate. (Note that as code points are assigned, one can update the profile to properly handle them.) If you limit your suggestion to just private use code points, then I think we might be able to change the algorithm such that those points may be handled in a "local manner" (meaning that the implementation may map, normalize, prohibit, bidi check, insignificant character remove as they please) but we'd also need to not only state some interoperability and security considerations. I don't necessarily support making such a change. I offer it for discussion purposes. Kurt At 12:16 PM 6/27/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> In view of this, I'm beginning to dislike that Prohibit step. >>> If I have a purely local LDAP directory, why shouldn't I be allowed to >>> give an attribute two values where one uses a Private Use code point? >> >> These rules are designed for interoperability between independently >> developed implementations which you are likely to have even in >> local environments. (...) > >We have at least two LDAP servers here (OpenLDAP and AD), but will never >need any interoperability between them. > >Interoperability is important, but I think the price is too high >sometimes. Like in this case. I don't like to have to pay too much for >features I know I won't need. That's why I think the prohibit step >should only be a SHOULD or RECOMMENDED, with a 'MAY allow admins to turn >it off'. > >> Note that one is always free to define other schema elements to meet >> local needs. > >That only helps if I can hack the server to add new matching rules, or >if I'm satisfied with using Octet String for string data and don't need >features like case-ignore matching. > >-- >Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 27 16:57:49 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 QAA20449 for ; Fri, 27 Jun 2003 16:57:33 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5RKu9kf068875; Fri, 27 Jun 2003 20:56: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 h5RKpLDF068566; Fri, 27 Jun 2003 20:51:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 27 Jun 2003 20:51:21 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5RKpHkb068524; Fri, 27 Jun 2003 20:51:18 GMT (envelope-from hbf@bombur.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19W0Bd-0006fP-00; Fri, 27 Jun 2003 22:51:13 +0200 Received: from [129.240.130.19] (helo=miss.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.14) id 19W0Bb-00028I-AQ; Fri, 27 Jun 2003 22:51:11 +0200 Received: from bombur.uio.no ([129.240.186.42]) by miss.uio.no with esmtp (Exim 2.12 #7) id 19W0Bb-0005sm-00; Fri, 27 Jun 2003 22:51:11 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19W0BZ-0007Xg-00; Fri, 27 Jun 2003 22:51:09 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep In-Reply-To: <5.2.0.9.0.20030627131835.01b92b40@127.0.0.1> References: <5.2.0.9.0.20030627093357.01bf45b0@127.0.0.1> <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030627131835.01b92b40@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 27 Jun 2003 22:51:09 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: > Hallvard, > > The way you worded your suggestion, the suggestion applies to all > currently prohibited characters. Yes, I assumed that was the simplest way to do it. Also: > That is problematic as prohibiting certain assigned code points as > well as all unassigned code points is quite appropriate. (Note that > as code points are assigned, one can update the profile to properly > handle them.) Assigned code points: OK. I only know portions of Unicode, so I don't know what all the code points are for. I simply assumed that they are there to be used, so someone who uses them may want to put them i LDAP. Unassigned code points: Prohibiting them looks more problematic to me. That means the server becomes obsolete when new code points are assigned. If one wants to use such new code points, it will then be convenient if one can configure the server to not prohibit them. One won't get features like proper case folding, but at least one can but them in the directory. > If you limit your suggestion to just private use code points, then > I think we might be able to change the algorithm such that those > points may be handled in a "local manner" (meaning that the > implementation may map, normalize, prohibit, bidi check, > insignificant character remove as they please) but we'd also > need to not only state some interoperability and security > considerations. > > I don't necessarily support making such a change. I offer it for > discussion purposes. Well, as you can guess, my vote is for it. Or more:-) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 27 17:38:37 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 RAA21242 for ; Fri, 27 Jun 2003 17:38:36 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5RLQAlB069956; Fri, 27 Jun 2003 21:37:42 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 h5RLL4F6069589; Fri, 27 Jun 2003 21:21:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 27 Jun 2003 21:21:04 +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 h5RLL2kb069578 for ; Fri, 27 Jun 2003 21:21: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 h5RLL1c6020799; Fri, 27 Jun 2003 21:21:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030627135655.01d27d98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Jun 2003 14:18:00 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030627131835.01b92b40@127.0.0.1> <5.2.0.9.0.20030627093357.01bf45b0@127.0.0.1> <5.2.0.9.0.20030625150537.01ccccb0@127.0.0.1> <5.2.0.9.0.20030625131618.01c6bae8@127.0.0.1> <5.2.0.9.0.20030625073051.01bc7ab8@127.0.0.1> <5.2.0.9.0.20030624130612.01bdd0a8@127.0.0.1> <5.2.0.9.0.20030627131835.01b92b40@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 01:51 PM 6/27/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> Hallvard, >> >> The way you worded your suggestion, the suggestion applies to all >> currently prohibited characters. > >Yes, I assumed that was the simplest way to do it. Also: > >> That is problematic as prohibiting certain assigned code points as >> well as all unassigned code points is quite appropriate. (Note that >> as code points are assigned, one can update the profile to properly >> handle them.) > >Assigned code points: OK. I only know portions of Unicode, so I don't >know what all the code points are for. I simply assumed that they are >there to be used, so someone who uses them may want to put them i LDAP. > >Unassigned code points: Prohibiting them looks more problematic to me. >That means the server becomes obsolete when new code points are >assigned. If one wants to use such new code points, it will then be >convenient if one can configure the server to not prohibit them. One >won't get features like proper case folding, but at least one can but >them in the directory. I think its best we stick with versioning consistent with Section 7.3 of RFC 3454. >> If you limit your suggestion to just private use code points, then >> I think we might be able to change the algorithm such that those >> points may be handled in a "local manner" (meaning that the >> implementation may map, normalize, prohibit, bidi check, >> insignificant character remove as they please) but we'd also >> need to not only state some interoperability and security >> considerations. >> >> I don't necessarily support making such a change. I offer it for >> discussion purposes. > >Well, as you can guess, my vote is for it. Or more:-) Noted. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 27 17:55:59 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 RAA21605 for ; Fri, 27 Jun 2003 17:55: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 h5RLo9kf071094; Fri, 27 Jun 2003 21:54:07 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 h5RLlQuP070993; Fri, 27 Jun 2003 21:47:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 27 Jun 2003 21:47:26 +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 h5RLlOkb070983 for ; Fri, 27 Jun 2003 21:47:24 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 h5RLksc6020945; Fri, 27 Jun 2003 21:46:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030627143920.01cf8db8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Jun 2003 14:43:54 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Specifying non-tcp transports referrals Cc: , , "Steve McLain" , "Tom Doman" , 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 11:39 AM 6/26/2003, Jim Sermersheim wrote: >The other problem is (and maybe this is really a problem to be solved >in [Protocol] is that a referral is a sequence of LDAPURL, where LDAPURL >follows [LDAPURL]. And also we see in the referral definition: RFC 2251, LDAPURL ::= LDAPString -- limited to characters permitted in URLs That is, an LDAPURL != [LDAPURL]. It might be wise to s/LDAPURL/URL/ in the ASN.1. >I also thing that if [LDAPURL] is meant to implicitly specify TCP, it >should be called out. Likely some clarification here is appropriate. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 27 19:45: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 TAA26487 for ; Fri, 27 Jun 2003 19:45:35 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5RNiAkf077024; Fri, 27 Jun 2003 23:44: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 h5RNcqi8076866; Fri, 27 Jun 2003 23:38:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 27 Jun 2003 23:38:52 +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 h5RNcokb076856 for ; Fri, 27 Jun 2003 23:38:51 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 h5RNcVc6021718; Fri, 27 Jun 2003 23:38:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030627162633.01c002d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Jun 2003 16:35:31 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Specifying non-tcp transports referrals Cc: , , "Steve McLain" , "Tom Doman" , 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 04:01 PM 6/27/2003, Jim Sermersheim wrote: >But read a little further: >> URLs for servers implementing the LDAP protocol are written >according >> to [9]. > >(where [9] is [LDAPURL]) > >This means that URLs pointing to LDAP servers, follow [LDAPURL]. And if >[LDAPURL] is only used for TCP/IP... Well, it means any URL to an LDAP >server means TCP is used. This is too limiting (in my view). Likely the above needs to be clarified with something like: URLs for servers implementing LDAP and accessible via TCP/IP (v4 or v6) are written according to [LDAPURL]. I think ldap:// needs to be viewed as providing a LDAP/TCP/IP service locator and that LDAP over other transports locators will use other schemes (e.g., ldaps://, ldapi://, ldap.sctp://, or whatever) defined in other documents. And Referrals and Continuations may contain non-LDAP URLs (e.g., xdap:// ?). Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jun 27 19:48: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 TAA26640 for ; Fri, 27 Jun 2003 19:48: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 h5RN8Akf076092; Fri, 27 Jun 2003 23:12:09 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 h5RN3MWZ075964; Fri, 27 Jun 2003 23:03:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 27 Jun 2003 23:03:22 +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 h5RN3Kkb075919; Fri, 27 Jun 2003 23:03:20 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 27 Jun 2003 17:02:56 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 27 Jun 2003 17:01:29 -0600 From: "Jim Sermersheim" To: Cc: , , "Steve McLain" , "Tom Doman" , Subject: Re: Specifying non-tcp transports referrals 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 But read a little further: > URLs for servers implementing the LDAP protocol are written according > to [9]. (where [9] is [LDAPURL]) This means that URLs pointing to LDAP servers, follow [LDAPURL]. And if [LDAPURL] is only used for TCP/IP... Well, it means any URL to an LDAP server means TCP is used. This is too limiting (in my view). BTW, I agree with the s/LDAPURL/URL in the ASN.1 Jim >>> "Kurt D. Zeilenga" 6/27/03 3:43:54 PM >>> At 11:39 AM 6/26/2003, Jim Sermersheim wrote: >The other problem is (and maybe this is really a problem to be solved >in [Protocol] is that a referral is a sequence of LDAPURL, where LDAPURL >follows [LDAPURL]. And also we see in the referral definition: RFC 2251, LDAPURL ::= LDAPString -- limited to characters permitted in URLs That is, an LDAPURL != [LDAPURL]. It might be wise to s/LDAPURL/URL/ in the ASN.1. >I also thing that if [LDAPURL] is meant to implicitly specify TCP, it >should be called out. Likely some clarification here is appropriate. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sat Jun 28 00:56: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 AAA03197 for ; Sat, 28 Jun 2003 00:56: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 h5S4krkv086211; Sat, 28 Jun 2003 04:54: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 h5S4c4gM085962; Sat, 28 Jun 2003 04:38:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 28 Jun 2003 04:38: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 h5S4c1kb085932; Sat, 28 Jun 2003 04:38:02 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 27 Jun 2003 22:37:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 27 Jun 2003 22:37:36 -0600 From: "Jim Sermersheim" To: Cc: , , "Steve McLain" , "Tom Doman" , Subject: Re: Specifying non-tcp transports referrals Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. I'll plan on reflecting this in a future edit if no one disagrees. Jim >>> "Kurt D. Zeilenga" 06/27/03 5:35 PM >>> At 04:01 PM 6/27/2003, Jim Sermersheim wrote: >But read a little further: >> URLs for servers implementing the LDAP protocol are written >according >> to [9]. > >(where [9] is [LDAPURL]) > >This means that URLs pointing to LDAP servers, follow [LDAPURL]. And if >[LDAPURL] is only used for TCP/IP... Well, it means any URL to an LDAP >server means TCP is used. This is too limiting (in my view). Likely the above needs to be clarified with something like: URLs for servers implementing LDAP and accessible via TCP/IP (v4 or v6) are written according to [LDAPURL]. I think ldap:// needs to be viewed as providing a LDAP/TCP/IP service locator and that LDAP over other transports locators will use other schemes (e.g., ldaps://, ldapi://, ldap.sctp://, or whatever) defined in other documents. And Referrals and Continuations may contain non-LDAP URLs (e.g., xdap:// ?). Kurt From owner-ietf-ldapbis@OpenLDAP.org Sat Jun 28 09:44:18 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 JAA22484 for ; Sat, 28 Jun 2003 09:44:02 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5SDQFkf097490; Sat, 28 Jun 2003 13:31: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 h5SDQ8m0097481; Sat, 28 Jun 2003 13:26:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 28 Jun 2003 13:26:08 +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 h5SDQ0kb097451; Sat, 28 Jun 2003 13:26: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 h5SDPVn24031; Sat, 28 Jun 2003 06:25:31 -0700 (PDT) Received: from netscape.com ([10.169.192.34]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HH71AA02.OX8; Sat, 28 Jun 2003 06:25:22 -0700 Message-ID: <3EFD9749.5050107@netscape.com> Date: Sat, 28 Jun 2003 09:25:29 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030617 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: Kurt@OpenLDAP.org, ehall@ehsco.com, Steve McLain , Tom Doman , ietf-ldapbis@OpenLDAP.org Subject: Re: Specifying non-tcp transports referrals 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 I also agree with this. Kurt said it very clearly. I think that was the original intent back when LDAPv3 was created. -Mark Jim Sermersheim wrote: >I agree. I'll plan on reflecting this in a future edit if no one >disagrees. > >Jim > > > >>>>"Kurt D. Zeilenga" 06/27/03 5:35 PM >>> >>>> >>>> >At 04:01 PM 6/27/2003, Jim Sermersheim wrote: > > >>But read a little further: >> >> >>> URLs for servers implementing the LDAP protocol are written >>> >>> >>according >> >> >>> to [9]. >>> >>> >>(where [9] is [LDAPURL]) >> >>This means that URLs pointing to LDAP servers, follow [LDAPURL]. And if >>[LDAPURL] is only used for TCP/IP... Well, it means any URL to an LDAP >>server means TCP is used. This is too limiting (in my view). >> >> > >Likely the above needs to be clarified with something like: > URLs for servers implementing LDAP and accessible via > TCP/IP (v4 or v6) are written according to [LDAPURL]. > >I think ldap:// needs to be viewed as providing a LDAP/TCP/IP >service locator and that LDAP over other transports locators >will use other schemes (e.g., ldaps://, ldapi://, ldap.sctp://, >or whatever) defined in other documents. And Referrals and >Continuations may contain non-LDAP URLs (e.g., xdap:// ?). > >Kurt > > > > From owner-ietf-ldapbis@OpenLDAP.org Sat Jun 28 21:33: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 VAA07824 for ; Sat, 28 Jun 2003 21:33:13 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5T1QJkj011017; Sun, 29 Jun 2003 01:31: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 h5T1PRLH010984; Sun, 29 Jun 2003 01:25:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 29 Jun 2003 01:25:27 +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 h5T1PQkb010961 for ; Sun, 29 Jun 2003 01:25:26 GMT (envelope-from RHARRISON@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Sat, 28 Jun 2003 19:25:02 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Sat, 28 Jun 2003 09:55:24 -0600 From: "Roger Harrison" To: Subject: [authmeth] use of SASL "PLAIN" witih LDAP Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__NextPart_0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__NextPart_0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In my conversations with WG members, I have learned that at least one LDAP server implementer has found the SASL "PLAIN" mechanism useful in authenticating to legacy systems that do not represent authentication identities as DNs. [authmeth] section 3.3.1 implicitly disallows the use of the SASL "PLAIN" mechanism with LDAP: "As LDAP includes native anonymous and plaintext authentication methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used with LDAP." Should we remove the reference to "PLAIN" in this section to allow the use of the SASL "PLAIN" mechanism? Roger Harrison Roger G. Harrison Manager, eDirectory Core and Utilities Novell, Inc., the Leader Provider of Net Business Solutions www.novell.com --=__NextPart_0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
In my conversations with WG members, I have learned that at least one LDAP server implementer has found the SASL "PLAIN" mechanism useful in authenticating to legacy systems that do not represent authentication identities as DNs. [authmeth] section 3.3.1 implicitly disallows the use of the SASL "PLAIN" mechanism with LDAP:
 
"As LDAP includes native anonymous and plaintext authentication methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used with LDAP."
 
Should we remove the reference to "PLAIN" in this section to allow the use of the SASL "PLAIN" mechanism?
 
Roger Harrison
 
Roger G. Harrison
Manager, eDirectory Core and Utilities
Novell, Inc., the Leader Provider of Net Business Solutions
www.novell.com
--=__NextPart_0__=-- From owner-ietf-ldapbis@OpenLDAP.org Sat Jun 28 21:33: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 VAA07825 for ; Sat, 28 Jun 2003 21:33:13 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5T1QJkl011017; Sun, 29 Jun 2003 01:31: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 h5T1PRHJ010979; Sun, 29 Jun 2003 01:25:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 29 Jun 2003 01:25:27 +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 h5T1PQkb010960 for ; Sun, 29 Jun 2003 01:25:26 GMT (envelope-from RHARRISON@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Sat, 28 Jun 2003 19:25:02 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Sat, 28 Jun 2003 08:43:12 -0600 From: "Roger Harrison" To: , Subject: [authmeth] secure derivations of server hostname Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__NextPart_0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__NextPart_0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit There is an outstanding work item, G.25, in authmeth-05 regarding the use of derived forms of the server's name when performing a the server identity check while processing a StartTLS request. Currently, the wording of section 4.1.6 says: "The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use any other derived form of name including the server's canonical DNS name." According to my notes, Bob Morgan offered to provide some wording that would relax this restriction to allow usage of derivations of the server name that are provided securely. If Bob or some other knowledgeable member of the WG would help me with the proper wording or some information about what is acceptable, I will make the needed changes and close out the work item.' Thanks, Roger --=__NextPart_0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
There is an outstanding work item, G.25, in authmeth-05 regarding the use of derived forms of the server's name when performing a the server identity check while processing a StartTLS request. Currently, the wording of section 4.1.6 says:
 
"The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate.  The client MUST NOT use any other derived form of name including the server's canonical DNS name."
 
According to my notes, Bob Morgan offered to provide some wording that would relax this restriction to allow usage of derivations of the server name that are provided securely. If Bob or some other knowledgeable member of the WG would help me with the proper wording or some information about what is acceptable, I will make the needed changes and close out the work item.'
 
Thanks,
 
Roger
--=__NextPart_0__=-- From owner-ietf-ldapbis@OpenLDAP.org Sun Jun 29 01:02: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 BAA10199 for ; Sun, 29 Jun 2003 01:02:22 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5T4uKkf013994; Sun, 29 Jun 2003 05:00:49 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 h5T4t9SD013979; Sun, 29 Jun 2003 04:55:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 29 Jun 2003 04:55:09 +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 h5T4t8kb013967 for ; Sun, 29 Jun 2003 04:55:08 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 h5T4t6c6033784; Sun, 29 Jun 2003 04:55:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030628213627.01bd79e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 28 Jun 2003 21:52:05 -0700 To: "Roger Harrison" From: "Kurt D. Zeilenga" Subject: Re: [authmeth] use of SASL "PLAIN" witih LDAP 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 08:55 AM 6/28/2003, Roger Harrison wrote: >In my conversations with WG members, I have learned that at least one LDAP server implementer has found the SASL "PLAIN" mechanism useful in authenticating to legacy systems that do not represent authentication identities as DNs. PLAIN is also useful where proxy authorization is need. >[authmeth] section 3.3.1 implicitly disallows the use of the SASL "PLAIN" mechanism with LDAP: > >"As LDAP includes native anonymous and plaintext authentication methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used with LDAP." Note that Section 4 of RFC 2829 implied that PLAIN may be used (with TLS). >Should we remove the reference to "PLAIN" in this section to allow the use of the SASL "PLAIN" mechanism? I suggest inserting the word 'typically' (or 'generally') in the quoted sentence. That is, As LDAP includes native anonymous and plaintext authentication methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are typically not used with LDAP. This allows use of PLAIN (and ANONYMOUS) in atypical situations while still noting to implementors that these mechanisms have limited applicability. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sun Jun 29 09:05: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 JAA27704 for ; Sun, 29 Jun 2003 09:05:12 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5TCuNkj022918; Sun, 29 Jun 2003 13:03:21 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 h5TCot1o022768; Sun, 29 Jun 2003 12:50:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 29 Jun 2003 12:50:55 +0000 Received: from nb2.stroeder.com (cxxix.yapay.inka.de [193.197.185.3]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5TCokkb022758 for ; Sun, 29 Jun 2003 12:50:53 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 9EFB1B5E1; Sun, 29 Jun 2003 14:44:55 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id CEAC5B593; Sun, 29 Jun 2003 14:44:54 +0200 (CEST) Message-ID: <3EFEDF46.1020408@stroeder.com> Date: Sun, 29 Jun 2003 14:44:54 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Roger Harrison Cc: ietf-ldapbis@OpenLDAP.org, rlmorgan@washington.edu Subject: Re: [authmeth] secure derivations of server hostname References: In-Reply-To: X-Enigmail-Version: 0.74.3.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 Roger Harrison wrote: > There is an outstanding work item, G.25, in authmeth-05 regarding > the use of derived forms of the server's name when performing a the > server identity check while processing a StartTLS request. Currently, > the wording of section 4.1.6 says: > > "The client MUST use the server hostname it used to open the LDAP > connection as the value to compare against the server name as expressed > in the server's certificate. The client MUST NOT use any other derived > form of name including the server's canonical DNS name." > > According to my notes, Bob Morgan offered to provide some wording that > would relax this restriction to allow usage of derivations of the server > name that are provided securely. If Bob or some other knowledgeable > member of the WG would help me with the proper wording or some > information about what is acceptable, I will make the needed changes and > close out the work item.' Could you please give some examples of "derivations of the server name that are provided securely"? Is this about using host names in X.509v3 subjectAltName extension? I'm rather scared about relaxing this since I suspect that unsecure DNS is used to get the derivation of the server name. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 30 07:45: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 HAA11287 for ; Mon, 30 Jun 2003 07:45:15 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UBQUkf057337; Mon, 30 Jun 2003 11:28: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 h5UBMT0u057226; Mon, 30 Jun 2003 11:22:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 30 Jun 2003 11:22:29 +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 h5UBMSkb057213 for ; Mon, 30 Jun 2003 11:22:28 GMT (envelope-from RHARRISON@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 30 Jun 2003 05:22:04 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 30 Jun 2003 05:17:03 -0600 From: "Roger Harrison" To: Cc: , Subject: Re: [authmeth] secure derivations of server hostname Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__NextPart_0__=" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__NextPart_0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can't provide some examples, because I'm not sure what, precisely, Bob = had in mind when he made his suggestion. Bob, can you give us some insight = here? =20 Thanks, =20 Roger >>> Michael Str=F6der 6/29/2003 6:44:54 AM >>> Roger Harrison wrote: > There is an outstanding work item, G.25, in authmeth-05 regarding=20 > the use of derived forms of the server's name when performing a the=20 > server identity check while processing a StartTLS request. Currently,=20 > the wording of section 4.1.6 says: >=20 > "The client MUST use the server hostname it used to open the LDAP=20 > connection as the value to compare against the server name as = expressed=20 > in the server's certificate. The client MUST NOT use any other derived=20= > form of name including the server's canonical DNS name." >=20 > According to my notes, Bob Morgan offered to provide some wording = that=20 > would relax this restriction to allow usage of derivations of the = server=20 > name that are provided securely. If Bob or some other knowledgeable=20 > member of the WG would help me with the proper wording or some=20 > information about what is acceptable, I will make the needed changes = and=20 > close out the work item.' Could you please give some examples of "derivations of the server name that are provided securely"? Is this about using host names in = X.509v3=20 subjectAltName extension? I'm rather scared about relaxing this since I=20 suspect that unsecure DNS is used to get the derivation of the server = name. Ciao, Michael. --=__NextPart_0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I can't provide some examples, because I'm not sure what, precisely, = Bob had in mind when he made his suggestion. Bob, can you give us some = insight here?
 
Thanks,
 
Roger

>>> Michael Str=F6der <michael@stroeder.com&g= t; 6/29/2003 6:44:54 AM >>>
Roger Harrison wrote:
> = There is an outstanding work item, G.25, in authmeth-05 regarding
> = the use of derived forms of the server's name when performing a the =
> server identity check while processing a StartTLS request. = Currently,
> the wording of section 4.1.6 says:
>
> = "The client MUST use the server hostname it used to open the LDAP
> = connection as the value to compare against the server name as expressed =
> in the server's certificate. The client MUST NOT use any other = derived
> form of name including the server's canonical DNS = name."
>
> According to my notes, Bob Morgan offered to = provide some wording that
> would relax this restriction to allow = usage of derivations of the server
> name that are provided = securely. If Bob or some other knowledgeable
> member of the WG = would help me with the proper wording or some
> information about = what is acceptable, I will make the needed changes and
> close out = the work item.'

Could you please give some examples of "derivations = of the server
name that are provided securely"? Is this about using = host names in X.509v3
subjectAltName extension? I'm rather scared = about relaxing this since I
suspect that unsecure DNS is used to get = the derivation of the server name.

Ciao, Michael.

--=__NextPart_0__=-- From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 30 14:02:24 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 OAA08768 for ; Mon, 30 Jun 2003 14:02:24 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UHuWkh081501; Mon, 30 Jun 2003 18:01: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 h5UHnZQI081059; Mon, 30 Jun 2003 17:49:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 30 Jun 2003 17:49:35 +0000 Received: from nb2.stroeder.com (krl9-d9bb4e9e.pool.mediaWays.net [217.187.78.158]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UHnWkb081004 for ; Mon, 30 Jun 2003 17:49:33 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 0C4C88CA26; Mon, 30 Jun 2003 19:49:08 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 379018A1A7; Mon, 30 Jun 2003 19:49:07 +0200 (CEST) Message-ID: <3F007813.6000903@stroeder.com> Date: Mon, 30 Jun 2003 19:49:07 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Roger Harrison Cc: ietf-ldapbis@OpenLDAP.org, rlmorgan@washington.edu Subject: Re: [authmeth] secure derivations of server hostname References: In-Reply-To: X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5UHnXkb081049 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 Roger Harrison wrote: > I can't provide some examples, because I'm not sure what, precisely, Bob > had in mind when he made his suggestion. Without the rationale and some real-world examples I'm rather scared to relax the checking of the server's hostname in any way. Ciao, Michael. Bob, can you give us some > insight here? > > Thanks, > > Roger > > >>> Michael Ströder 6/29/2003 6:44:54 AM >>> > Roger Harrison wrote: > > There is an outstanding work item, G.25, in authmeth-05 regarding > > the use of derived forms of the server's name when performing a the > > server identity check while processing a StartTLS request. Currently, > > the wording of section 4.1.6 says: > > > > "The client MUST use the server hostname it used to open the LDAP > > connection as the value to compare against the server name as expressed > > in the server's certificate. The client MUST NOT use any other derived > > form of name including the server's canonical DNS name." > > > > According to my notes, Bob Morgan offered to provide some wording that > > would relax this restriction to allow usage of derivations of the server > > name that are provided securely. If Bob or some other knowledgeable > > member of the WG would help me with the proper wording or some > > information about what is acceptable, I will make the needed changes and > > close out the work item.' > > Could you please give some examples of "derivations of the server > name that are provided securely"? Is this about using host names in X.509v3 > subjectAltName extension? I'm rather scared about relaxing this since I > suspect that unsecure DNS is used to get the derivation of the server name. > > Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 30 14:55:04 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 OAA10748 for ; Mon, 30 Jun 2003 14:55:04 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UIiXl7084483; Mon, 30 Jun 2003 18:53:56 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 h5UIhnKu084445; Mon, 30 Jun 2003 18:43:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 30 Jun 2003 18:43:49 +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 h5UIhlkb084435 for ; Mon, 30 Jun 2003 18:43:47 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 h5UIhic6047505; Mon, 30 Jun 2003 18:43:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 30 Jun 2003 11:40:41 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [authmeth] secure derivations of server hostname Cc: Roger Harrison , ietf-ldapbis@OpenLDAP.org, rlmorgan@washington.edu In-Reply-To: <3F007813.6000903@stroeder.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5UIhlkb084436 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'll give two examples. 1) a client could derive a hostname from "localhost" in a secure fashion. 2) a client could derive a hostname from a domain name in a secure fashion using DNSSEC. I know of implementations doing 1). Kurt At 10:49 AM 6/30/2003, Michael Ströder wrote: >Roger Harrison wrote: >>I can't provide some examples, because I'm not sure what, precisely, Bob had in mind when he made his suggestion. > >Without the rationale and some real-world examples I'm rather scared to relax the checking of the server's hostname in any way. > >Ciao, Michael. > > Bob, can you give us some >>insight here? >> >>Thanks, >> >>Roger >> >>> Michael Ströder 6/29/2003 6:44:54 AM >>> >>Roger Harrison wrote: >> > There is an outstanding work item, G.25, in authmeth-05 regarding >> > the use of derived forms of the server's name when performing a the >> > server identity check while processing a StartTLS request. Currently, >> > the wording of section 4.1.6 says: >> > >> > "The client MUST use the server hostname it used to open the LDAP >> > connection as the value to compare against the server name as expressed >> > in the server's certificate. The client MUST NOT use any other derived >> > form of name including the server's canonical DNS name." >> > >> > According to my notes, Bob Morgan offered to provide some wording that >> > would relax this restriction to allow usage of derivations of the server >> > name that are provided securely. If Bob or some other knowledgeable >> > member of the WG would help me with the proper wording or some >> > information about what is acceptable, I will make the needed changes and >> > close out the work item.' >>Could you please give some examples of "derivations of the server >>name that are provided securely"? Is this about using host names in X.509v3 >>subjectAltName extension? I'm rather scared about relaxing this since I >>suspect that unsecure DNS is used to get the derivation of the server name. >>Ciao, Michael. > From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 30 16:13:24 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 QAA14326 for ; Mon, 30 Jun 2003 16:13:23 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UJuXl1090818; Mon, 30 Jun 2003 20:12: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 h5UJsQm3090365; Mon, 30 Jun 2003 19:54:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 30 Jun 2003 19:54:26 +0000 Received: from nb2.stroeder.com (krl9-d9bb4e9e.pool.mediaWays.net [217.187.78.158]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UJsNkb090294; Mon, 30 Jun 2003 19:54:24 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id E83DB10969; Mon, 30 Jun 2003 21:53:59 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 23DDBB5CE; Mon, 30 Jun 2003 21:53:59 +0200 (CEST) Message-ID: <3F009555.1000502@stroeder.com> Date: Mon, 30 Jun 2003 21:53:57 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: [authmeth] secure derivations of server hostname References: <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> X-Enigmail-Version: 0.74.3.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 Kurt D. Zeilenga wrote: > I'll give two examples. > > 1) a client could derive a hostname from "localhost" in a secure fashion. How? > 2) a client could derive a hostname from a domain name in a secure fashion > using DNSSEC. Yes. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 30 16:39:48 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 QAA14944 for ; Mon, 30 Jun 2003 16:39:48 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UKcXkf093819; Mon, 30 Jun 2003 20:38:40 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 h5UKbWsL093767; Mon, 30 Jun 2003 20:37:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 30 Jun 2003 20:37:32 +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 h5UKbVkb093757 for ; Mon, 30 Jun 2003 20:37:31 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 h5UKbVc6048273; Mon, 30 Jun 2003 20:37:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030630132208.01c6c9d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 30 Jun 2003 13:34:28 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [authmeth] secure derivations of server hostname Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3F009555.1000502@stroeder.com> References: <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5UKbVkb093758 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 12:53 PM 6/30/2003, Michael Ströder wrote: >Kurt D. Zeilenga wrote: >>I'll give two examples. >>1) a client could derive a hostname from "localhost" in a secure fashion. > >How? By use of gethostname(3) or the like. >>2) a client could derive a hostname from a domain name in a secure fashion >> using DNSSEC. > >Yes. > >Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 30 16:45:37 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 QAA15109 for ; Mon, 30 Jun 2003 16:45:36 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UKiXkf094123; Mon, 30 Jun 2003 20:44:36 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 h5UKhuk5094110; Mon, 30 Jun 2003 20:43:56 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 30 Jun 2003 20:43:56 +0000 Received: from nb2.stroeder.com (krl9-d9bb4e9e.pool.mediaWays.net [217.187.78.158]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UKhrkb094077; Mon, 30 Jun 2003 20:43:53 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id BC68723FB5; Mon, 30 Jun 2003 22:43:29 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id EB2ABB5AA; Mon, 30 Jun 2003 22:43:28 +0200 (CEST) Message-ID: <3F00A0F0.1050609@stroeder.com> Date: Mon, 30 Jun 2003 22:43:28 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: [authmeth] secure derivations of server hostname References: <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> <5.2.0.9.0.20030630132208.01c6c9d8@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030630132208.01c6c9d8@127.0.0.1> X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5UKhskb094080 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Kurt D. Zeilenga wrote: > At 12:53 PM 6/30/2003, Michael Ströder wrote: > >>Kurt D. Zeilenga wrote: >> >>>I'll give two examples. >>>1) a client could derive a hostname from "localhost" in a secure fashion. >> >>How? > > By use of gethostname(3) or the like. Note that on most systems localhost is rarely the same like the machine's host name. E.g. on a Linux box the interface lo (loopback-device) with IP addr 127.0.0.1 and name localhost is definitely something different than eth0 with different IP addr assigned matching the machine's host name. And not every service binds to all available interface when running on a machine. I see some risks when relaxing the host name check. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 30 18:22:52 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 SAA19593 for ; Mon, 30 Jun 2003 18:22:52 -0400 (EDT) Received: from boole.openldap.org (smmsp@localhost [IPv6:::1]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UMKYkf098308; Mon, 30 Jun 2003 22:21:50 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 h5UMFMYw097550; Mon, 30 Jun 2003 22:15:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 30 Jun 2003 22:15:22 +0000 Received: from nb2.stroeder.com (krl9-d9bb4d31.pool.mediaWays.net [217.187.77.49]) by boole.openldap.org (8.12.9/8.12.9) with ESMTP id h5UMFJkb097509; Mon, 30 Jun 2003 22:15:19 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 4F7043B8E2; Tue, 1 Jul 2003 00:14:54 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 6C54BB5A9; Tue, 1 Jul 2003 00:14:53 +0200 (CEST) Message-ID: <3F00B65D.4080701@stroeder.com> Date: Tue, 01 Jul 2003 00:14:53 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: [authmeth] secure derivations of server hostname References: <5.2.0.9.0.20030630132208.01c6c9d8@127.0.0.1> <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> <5.2.0.9.0.20030630132208.01c6c9d8@127.0.0.1> <5.2.0.9.0.20030630141628.01d129d0@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030630141628.01d129d0@127.0.0.1> X-Enigmail-Version: 0.74.3.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 Kurt D. Zeilenga wrote: > > And with regards to mappings of "localhost" (or 127.0.0.1 or ::1), I > view the security considerations to a local matter (that is, it may > be secure in some environments, not in others). If it's only secure in a minority of systems that's not a strong argument. > This text: > "The client MUST use the server hostname it used to open the > LDAP connection as the value to compare against the server name as > expressed in the server's certificate. The client MUST NOT use any > other derived form of name including the server's canonical DNS name." > is problematic for a couple of reasons. > > First, it says "the server hostname it used to open the LDAP connection" > instead of "the server hostname provided by the user (or application > entity or other trusted entity)". Yes, the wording should be changed. > Second, derivation is fine if the result is confirmed by the user. Well, given all the misconfigured systems today human user are trained to happily click away every alert box with "OK" just to step forward. :-/ > So, I'm thinking this should be reworded. > The client MUST use the server hostname provided by the user (or other trusted > entity) as the value to compare against the server name as expressed in the > server's certificate. A hostname derived from the user input is to be considered > provided by the user only if derived in a secure fashion (e.g., DNSSEC) or confirmed > by the user. I'd prefer to drop the note about user confirmation for the reason above. IMHO the common work-around with SSL-related dialog boxes appearing all the time asking the user for confirmation with most times very unclear language should not be mentioned in such a standard. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Mon Jun 30 18:23:06 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 SAA19610 for ; Mon, 30 Jun 2003 18:23: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 h5UMEYl5097485; Mon, 30 Jun 2003 22:21: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 h5ULr45L096142; Mon, 30 Jun 2003 21:53:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 30 Jun 2003 21:53:04 +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 h5ULr3kb096131 for ; Mon, 30 Jun 2003 21:53:03 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 h5ULr2c6048631; Mon, 30 Jun 2003 21:53:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030630141628.01d129d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 30 Jun 2003 14:49:59 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [authmeth] secure derivations of server hostname Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3F00A0F0.1050609@stroeder.com> References: <5.2.0.9.0.20030630132208.01c6c9d8@127.0.0.1> <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> <5.2.0.9.0.20030630113902.01d17260@127.0.0.1> <5.2.0.9.0.20030630132208.01c6c9d8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boole.openldap.org id h5ULr3kb096132 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 01:43 PM 6/30/2003, Michael Ströder wrote: >I see some risks when relaxing the host name check. There are certainly risks in use of derived names. But, I think, the risks are not so severe to warrant the absolute prohibition of their use. DNSSEC can be used to derive a name in secure fashion. Even DNS can be used in a secure fashion (e.g., with user confirmation). And with regards to mappings of "localhost" (or 127.0.0.1 or ::1), I view the security considerations to a local matter (that is, it may be secure in some environments, not in others). This text: "The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use any other derived form of name including the server's canonical DNS name." is problematic for a couple of reasons. First, it says "the server hostname it used to open the LDAP connection" instead of "the server hostname provided by the user (or application entity or other trusted entity)". Second, derivation is fine if the result is confirmed by the user. So, I'm thinking this should be reworded. The client MUST use the server hostname provided by the user (or other trusted entity) as the value to compare against the server name as expressed in the server's certificate. A hostname derived from the user input is to be considered provided by the user only if derived in a secure fashion (e.g., DNSSEC) or confirmed by the user. Kurt