From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 12 20:09:58 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22087 for ; Tue, 12 Dec 2000 20:09:57 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBD19K520464; Wed, 13 Dec 2000 01:09:20 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 13 Dec 2000 01:09:20 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBD19Id20457 for ; Wed, 13 Dec 2000 01:09:18 GMT Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 12 Dec 2000 17:50:15 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 12 Dec 2000 17:50:12 -0700 From: "Jim Sermersheim" To: , Subject: Re: may to MUST Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id eBD19Jd20458 Sender: 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're right Bob, the changelog is wrong. However, I agree with Mark's sentiment that there is the chance that some may/MUST manipulation happened without an exhaustive review, so I will re-submit a less-changed version of the document. The changes I pull out will be sent to the list for review before being re-changed. I'll likely pull more than just may/MUST manipulations. In fact I estimate of the 60 odd non-editorial changes, I'll pull 30-40. This means there may be 30-40 new threads to look forward to on the list (sorry). I'll try to keep the process as sane as possible. Jim >>> bob_joslin@hp.com 12/12/00 11:01 AM >>> Jim, Mark, I believe that I can dispel some concerns that were brought up at the ldapbis WG last night about changing a "may" to a "MUST." >B.8 Section 4.1.5 > > - Changed "A server may treat" to "A server MUST treat" in the > second to last paragraph. > - Changed "A server MUST treat an AttributeDescription with any > options it does not implement as an unrecognized attribute type." > to "A server MUST treat an AttributeDescription with any options > it does not implement or support as an unrecognized attribute > type." in the second to last paragraph. If I read this change log properly, the original 2251 document did not say "may treat," it said "will treat." So perhaps there is not an specification change concern here. Bob Joslin From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 12 21:46:12 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15727 for ; Tue, 12 Dec 2000 21:46:12 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBD2jeH22332; Wed, 13 Dec 2000 02:45:40 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 13 Dec 2000 02:45:40 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBD2jcd22325 for ; Wed, 13 Dec 2000 02:45:38 GMT Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id CAA18701; Wed, 13 Dec 2000 02:45:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001212183304.00ab91e0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 12 Dec 2000 18:45:31 -0800 To: hahnt@us.ibm.com From: "Kurt D. Zeilenga" Subject: Re: comments on draft-zeilenga-ldapbis-reorg-00.txt 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 08:36 AM 12/12/00 -0500, Timothy Hahn wrote: >I have the following comment on this draft: As we have remanded reorganization issues to engineering teams, I have requested the removal of this I-D from the repository. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 13 09:11:44 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15795 for ; Wed, 13 Dec 2000 09:11:44 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBDEBCl37915; Wed, 13 Dec 2000 14:11:12 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 13 Dec 2000 14:11:12 +0000 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBDEBAd37908 for ; Wed, 13 Dec 2000 14:11:10 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA266308; Wed, 13 Dec 2000 09:10:25 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA166488; Wed, 13 Dec 2000 09:09:11 -0500 Importance: Normal Subject: RE: comments on draft-zeilenga-ldapbis-reorg-00.txt To: "Ryan Moats" Cc: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Timothy Hahn" Date: Wed, 13 Dec 2000 08:27:16 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V506_11152000.dev01 |November 27, 2000) at 12/13/2000 09:11:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Hello, Ryan wrote: >In my opinion, we should detail those LDAP syntaxes that are >required for interoperability. Syntaxes that are not required >for interoperability should be listed, but I don't think detail >is needed. This sounds fine with me - as long as it is clear in the text which ones are required for interoperability. If "lack of detail" is the only determining factor, then I think it is insufficient. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 Ryan Moats From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 13 09:11:46 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15820 for ; Wed, 13 Dec 2000 09:11:46 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBDEB3R37895; Wed, 13 Dec 2000 14:11:03 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 13 Dec 2000 14:11:03 +0000 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBDEB1d37886; Wed, 13 Dec 2000 14:11:01 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA195066; Wed, 13 Dec 2000 09:10:15 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA124020; Wed, 13 Dec 2000 09:09:02 -0500 Importance: Normal Subject: Re: comments on draft-zeilenga-ldapbis-reorg-00.txt To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Timothy Hahn" Date: Wed, 13 Dec 2000 03:37:41 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V506_11152000.dev01 |November 27, 2000) at 12/13/2000 09:10:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, Given that the draft is to be removed, I withdraw the comment. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Kurt D. Zeilenga" @OpenLDAP.org on 12/12/2000 09:45:31 PM Sent by: owner-ietf-ldapbis@OpenLDAP.org To: Timothy Hahn/Endicott/IBM@IBMUS cc: ietf-ldapbis@OpenLDAP.org Subject: Re: comments on draft-zeilenga-ldapbis-reorg-00.txt At 08:36 AM 12/12/00 -0500, Timothy Hahn wrote: >I have the following comment on this draft: As we have remanded reorganization issues to engineering teams, I have requested the removal of this I-D from the repository. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 13 09:11:48 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15831 for ; Wed, 13 Dec 2000 09:11:47 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBDEBIo37938; Wed, 13 Dec 2000 14:11:18 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 13 Dec 2000 14:11:18 +0000 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBDEBGd37927 for ; Wed, 13 Dec 2000 14:11:16 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA217806; Wed, 13 Dec 2000 09:10:31 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA121970; Wed, 13 Dec 2000 09:09:17 -0500 Importance: Normal Subject: RE: Updates for draft-hinckley-ldapv3-attr-syntax-00 (LONG) To: "Ryan Moats" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Timothy Hahn" Date: Wed, 13 Dec 2000 08:37:54 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V506_11152000.dev01 |November 27, 2000) at 12/13/2000 09:11:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Ryan, See comments at end - im See at end ... Ryan -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org Subject: Re: Updates for draft-hinckley-ldapv3-attr-syntax-00 (LONG) Greetings, Ryan, you wrote: 3. Lastly, there are ten matching rules from the copy of X.520 I was reading on the plane that aren't in either the 2252 update or the 2256 update... I'm wondering if they should be included. I've run into situations where several of them would have been useful already... caseExactSubstringMatch numericStringOrderingMatch caseIgnoreListSubstringMatch booleanMatch integerOrderingMatch uTCTimeMatch uTCTimeOrderingMatch directoryStringFirstComponentMatch wordMatch keywordMatch What does the working group want to do with these? My feelings here is that we should indicate which syntaxes and matching rules are MANDATORY to implement (MUST be supported) by servers that support LDAPv3, and then those that are "recommended". I believe the matching rules above would fall into the "recommended" category. Regards, Tim Hahn Ok, that's a position. I would prefer that the following be mandatory or recommended (this means they have to be implemented for going to DS) : caseExactSubstringMatch, numericStringOrderingMatch, booleanMatch, integerOrderingMatch because I've run into multiple situations where it would have made life MUCH easier. For the rest, I think they can be NOT REQUIRED (i.e. we don't have to test them). My important point is that we have to say something. The current state of affairs is unacceptable. I agree with you that from the original set above, the four matching rules listed: caseExactSubstringMatch numericStringOrderingMatch booleanMatch integerOrderingMatch should be made MANDATORY. From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 13 09:12:07 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15944 for ; Wed, 13 Dec 2000 09:12:06 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBDEBaK37978; Wed, 13 Dec 2000 14:11:36 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 13 Dec 2000 14:11:36 +0000 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBDEBYd37962 for ; Wed, 13 Dec 2000 14:11:34 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA211476; Wed, 13 Dec 2000 09:10:29 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA156248; Wed, 13 Dec 2000 09:09:15 -0500 Importance: Normal Subject: RE: Comments on draft-zeilenga-ldapbis-rfc2253-01.txt To: "Ryan Moats" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Timothy Hahn" Date: Wed, 13 Dec 2000 08:34:41 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V506_11152000.dev01 |November 27, 2000) at 12/13/2000 09:11:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Ryan, see my comments below with ... ... See comments... Ryan Greetings, Section 2.3: I understand the intent here (ensure that distinguished names in protocol are unique). However, I believe that this will represent a big compatibility concern for existing implementations. This also places quite a bit more burden on LDAP clients to query the subschema entry and build a OID <-> attribute type name mapping to use when presenting DNs to applications. Well, I can say that Kurt, Rick Huber and I had a lively discussion about this after the working group meeting on Monday night. In my opinion, again, we should find a way to list those attribute type names that are required for interoperability and provide an "escape clause" that implementations SHOULD support additional attribute type names. If I put on my "directory customer" hat (which I wear quite a bit these days), anything without the "escape clause" is DOA. This is because other working groups and standards bodies are defining schema that use additional attribute type names for naming already, and anything that "raises the bar" for implementations is (again IMHO) a BAD thing. Sounds good to me Section 2.4: A note indicating that UTF-8 characters may be escaped using the "\nn" form would be helpful - noting that in this case, multiple escaped bytes will be required. Hmm, I thought there was something in the ABNF already? I checked the draft again this morning. While the draft indicates that a value is first transformed to a UTF-8 string (according to RFC 2252), it also indicates that "Implementations MAY escape other characters." It then goes on to state that the character to be escaped "is replaced by a backslash and two hex digits, which form a single byte in the code of the character." There is an example in section 4 that contains an escaped UTF-8 character. It just seems to me that we could describe how to escape multi-byte characters a bit more than what is in the second quote in this paragraph. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 13 11:05:26 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07238 for ; Wed, 13 Dec 2000 11:05:24 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBDG4gG41762; Wed, 13 Dec 2000 16:04:42 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 13 Dec 2000 16:04:42 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBDG4ed41755 for ; Wed, 13 Dec 2000 16:04:40 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO70161 (AUTH rmoats); Wed, 13 Dec 2000 11:04:22 -0500 (EST) From: "Ryan Moats" To: "Timothy Hahn" Cc: Subject: RE: Comments on draft-zeilenga-ldapbis-rfc2253-01.txt Date: Wed, 13 Dec 2000 10:03:59 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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 this time. I've dropped Section 2.3 since it looks like Tim and I agree. Ryan -----Original Message----- From: Timothy Hahn [mailto:hahnt@us.ibm.com] Subject: RE: Comments on draft-zeilenga-ldapbis-rfc2253-01.txt Ryan, see my comments below with ... ... See comments... Ryan Greetings, [snip]... Section 2.4: A note indicating that UTF-8 characters may be escaped using the "\nn" form would be helpful - noting that in this case, multiple escaped bytes will be required. Hmm, I thought there was something in the ABNF already? I checked the draft again this morning. While the draft indicates that a value is first transformed to a UTF-8 string (according to RFC 2252), it also indicates that "Implementations MAY escape other characters." It then goes on to state that the character to be escaped "is replaced by a backslash and two hex digits, which form a single byte in the code of the character." There is an example in section 4 that contains an escaped UTF-8 character. It just seems to me that we could describe how to escape multi-byte characters a bit more than what is in the second quote in this paragraph. Hmmm. Isn't the multi byte character concern covered under the UTF-8 transformation? I take the sentence about escape to mean if an implementation has a reserved character it can escape it. Maybe I'm confused [that often happens :-)]. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 14 12:22:08 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03706 for ; Thu, 14 Dec 2000 12:22:08 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBEHLAc95962; Thu, 14 Dec 2000 17:21:10 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 14 Dec 2000 17:21:09 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBEHL8d95955 for ; Thu, 14 Dec 2000 17:21:08 GMT Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id RAA23350; Thu, 14 Dec 2000 17:20:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001214091611.01f372f0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 14 Dec 2000 09:20:35 -0800 To: "Timothy Hahn" From: "Kurt D. Zeilenga" Subject: RE: Comments on draft-zeilenga-ldapbis-rfc2253-01.txt Cc: "Ryan Moats" , 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:34 AM 12/13/00 -0500, Timothy Hahn wrote: >"is replaced by a backslash and two hex digits, which form a single byte in >the code of the character." I'll rewrite this sentence to specify that each octet of the character is to be replaced with a backslash and two hex digits as demonstrated in the examples. I likely can borrow language from other portions of the LDAP TS. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 14 18:58:35 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23294 for ; Thu, 14 Dec 2000 18:58:34 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBENvpK07060; Thu, 14 Dec 2000 23:57:51 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 14 Dec 2000 23:57:51 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBENvnd07053 for ; Thu, 14 Dec 2000 23:57:50 GMT Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id XAA24585 for ; Thu, 14 Dec 2000 23:57:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001213074649.00aadeb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 14 Dec 2000 15:57:26 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: LDAPbis Engineering Teams 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: Two engineering teams have been spun up... The LDAPbis Data/Protocol Team will develop an approach for organization of the LDAPv3 Data and Protocol Model portion of the TS (RFC 2251,2829). This team consists of MarkW, MarkS, JimS, JeffH, RogerH, and RyanM. The LDAPbis Schema Team will develop an approach for the organization of the LDAPv3 Schema portion of the TS. The Schema team consists of MarkH, KathyD, StevenL, and RyanM. It is expected that each team will complete their specific task within a month. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 14 19:20:22 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29263 for ; Thu, 14 Dec 2000 19:20:21 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBF0Jlb07369; Fri, 15 Dec 2000 00:19:51 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 15 Dec 2000 00:19:47 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBF0Jkd07362 for ; Fri, 15 Dec 2000 00:19:46 GMT Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id AAA24663 for ; Fri, 15 Dec 2000 00:19:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001214155656.00a8f4a0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 14 Dec 2000 16:19:22 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Implementation Report Master Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: The WG chairs are require do produce an implementation report to accompany the revised technical specification when submitted to the IESG for Draft Standard consideration. Due to the size of the LDAPv3 technical specification, the chairs seek help of volunteer(s) to develop and execute survey(s) of LDAPv3 implementors to determine which features they have independently developed and demonstrated interoperability for (see RFC2026, 4.1.2). Those wishing to volunteer should contact Bob and/or myself. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 14 20:20:24 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17728 for ; Thu, 14 Dec 2000 20:20:23 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBF1JmJ08117; Fri, 15 Dec 2000 01:19:48 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 15 Dec 2000 01:19:48 +0000 Received: from perq.cac.washington.edu (ietf.207.137.72.114.tx.verio.net [207.137.72.114]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBF1Jld08110 for ; Fri, 15 Dec 2000 01:19:47 GMT Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.11.0/8.11.0) with ESMTP id eBF1JnI01592 for ; Thu, 14 Dec 2000 17:19:49 -0800 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Thu, 14 Dec 2000 17:19:49 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: Reply-To: "RL 'Bob' Morgan" To: Subject: Re: Implementation Report Master In-Reply-To: <5.0.0.25.0.20001214155656.00a8f4a0@router.boolean.net> 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: > The WG chairs are require do produce an implementation report to > accompany the revised technical specification when submitted to the > IESG for Draft Standard consideration. Previously-submitted implementation reports are at: http://www.ietf.org/IESG/implementation.html One might note that there are relatively few existing reports for application-level protocols. So this is a chance to make some history. 8^) - RL "Bob" From owner-ietf-ldapbis@OpenLDAP.org Mon Dec 18 19:04:29 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18492 for ; Mon, 18 Dec 2000 19:04:28 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJ03hW49878; Tue, 19 Dec 2000 00:03:43 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 00:03:43 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJ03gd49871 for ; Tue, 19 Dec 2000 00:03:42 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id AAA37869; Tue, 19 Dec 2000 00:03:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001218160257.021ff0c0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 18 Dec 2000 16:03:33 -0800 To: "Ryan Moats" From: "Kurt D. Zeilenga" Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 Cc: In-Reply-To: References: <3A2D3233.DE506E8A@salford.ac.uk> 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:33 AM 12/10/00 -0600, Ryan Moats wrote: >I'd suggest > > quotechar = %x00-%x21 / %x23-%x5B / %x5D-7F ; any character except "\" or >QUOTATION Note that any character is not restricted to ASCII. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Dec 18 19:30:59 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18885 for ; Mon, 18 Dec 2000 19:30:58 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJ0UT150351; Tue, 19 Dec 2000 00:30:29 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 00:30:29 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJ0UQd50343; Tue, 19 Dec 2000 00:30:26 GMT Received: from mail.coreon.net (mail.coreon.net [216.74.131.6]) by mail.coreon.net (Mirapoint) with SMTP id AAO82978; Mon, 18 Dec 2000 19:30:41 -0500 (EST) From: Message-Id: <200012190030.AAO82978@mail.coreon.net> Date: Mon, 18 Dec 2000 19:47:58 -0500 Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org 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 Ok, I'll bite... what does ASCII have to do with this other than extending the last range to FF... Ryan ---- Original message ---- >Date: Mon, 18 Dec 2000 16:03:33 -0800 >From: "Kurt D. Zeilenga" >Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 >To: "Ryan Moats" >Cc: > >At 11:33 AM 12/10/00 -0600, Ryan Moats wrote: >>I'd suggest >> >> quotechar = %x00-%x21 / %x23-%x5B / %x5D-7F ; any character except "\" or >>QUOTATION > >Note that any character is not restricted to ASCII. > >Kurt > From owner-ietf-ldapbis@OpenLDAP.org Mon Dec 18 19:53:11 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19146 for ; Mon, 18 Dec 2000 19:53:10 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJ0qZj50843; Tue, 19 Dec 2000 00:52:35 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 00:52:35 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJ0qYd50836 for ; Tue, 19 Dec 2000 00:52:34 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id AAA38014; Tue, 19 Dec 2000 00:52:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001218163716.02202100@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 18 Dec 2000 16:52:30 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <200012190030.AAO82978@mail.coreon.net> 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:47 PM 12/18/00 -0500, rmoats@coreon.net wrote: >Ok, I'll bite... what does ASCII have to do with this other >than extending the last range to FF... Extending the range to FF is not sufficient. The ISO-10646-1 character code range, IIRC, is 0x000000 - 0x7FFFFFFF. When presented as UTF-8, each character spans from 1 to 6 octets (derived from RFC2849): UTF8-CHAR = ASCII / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 UTF8-1 = %x80-BF UTF8-2 = %xC0-DF UTF8-1 UTF8-3 = %xE0-EF 2UTF8-1 UTF8-4 = %xF0-F7 3UTF8-1 UTF8-5 = %xF8-FB 4UTF8-1 UTF8-6 = %xFC-FD 5UTF8-1 ASCII = %x00-7F Your original suggestion would limit escaping to only ASCII characters. With the range extension, the escaping would apply to the first octet of the character, not to the whole character. Kurt >Ryan > >---- Original message ---- >>Date: Mon, 18 Dec 2000 16:03:33 -0800 >>From: "Kurt D. Zeilenga" >>Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 >>To: "Ryan Moats" >>Cc: >> >>At 11:33 AM 12/10/00 -0600, Ryan Moats wrote: >>>I'd suggest >>> >>> quotechar = %x00-%x21 / %x23-%x5B / %x5D-7F ; any >character except "\" or >>>QUOTATION >> >>Note that any character is not restricted to ASCII. >> >>Kurt >> From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 09:37:12 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14474 for ; Tue, 19 Dec 2000 09:37:11 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJEaGt70185; Tue, 19 Dec 2000 14:36:16 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 14:36:16 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJEaDd70176; Tue, 19 Dec 2000 14:36:13 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO83661 (AUTH rmoats); Tue, 19 Dec 2000 09:36:35 -0500 (EST) From: "Ryan Moats" To: "Kurt D. Zeilenga" Cc: Subject: RE: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 Date: Tue, 19 Dec 2000 08:36:56 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <5.0.0.25.0.20001218163716.02202100@router.boolean.net> Sender: 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 Please, I understand UNICODE and laud what you are saying here. However, my reading is that the draft covers this already, because quotechar only shows up in: string = *( stringchar / pair ) / "#" hexstring / QUOTATION *( quotechar / pair ) QUOTATION so quotechar only needs to go to 0xFF as that covers all of the UTF-8 encoding. I agree that the ABNF below is more specific, but I don't see how changing quote character to -0xFF (and yes I got that wrong the first time), breaks any of the examples in the draft. Ryan -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, December 18, 2000 6:53 PM To: rmoats@coreon.net Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 At 07:47 PM 12/18/00 -0500, rmoats@coreon.net wrote: >Ok, I'll bite... what does ASCII have to do with this other >than extending the last range to FF... Extending the range to FF is not sufficient. The ISO-10646-1 character code range, IIRC, is 0x000000 - 0x7FFFFFFF. When presented as UTF-8, each character spans from 1 to 6 octets (derived from RFC2849): UTF8-CHAR = ASCII / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 UTF8-1 = %x80-BF UTF8-2 = %xC0-DF UTF8-1 UTF8-3 = %xE0-EF 2UTF8-1 UTF8-4 = %xF0-F7 3UTF8-1 UTF8-5 = %xF8-FB 4UTF8-1 UTF8-6 = %xFC-FD 5UTF8-1 ASCII = %x00-7F Your original suggestion would limit escaping to only ASCII characters. With the range extension, the escaping would apply to the first octet of the character, not to the whole character. Kurt >Ryan > >---- Original message ---- >>Date: Mon, 18 Dec 2000 16:03:33 -0800 >>From: "Kurt D. Zeilenga" >>Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 >>To: "Ryan Moats" >>Cc: >> >>At 11:33 AM 12/10/00 -0600, Ryan Moats wrote: >>>I'd suggest >>> >>> quotechar = %x00-%x21 / %x23-%x5B / %x5D-7F ; any >character except "\" or >>>QUOTATION >> >>Note that any character is not restricted to ASCII. >> >>Kurt >> From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 10:20:38 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15820 for ; Tue, 19 Dec 2000 10:20:37 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJFK3B72528; Tue, 19 Dec 2000 15:20:03 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 15:20:03 +0000 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJFK0d72520; Tue, 19 Dec 2000 15:20:00 GMT Received: from us-ea-gtwy-7.ea.unisys.com (us-ea-gtwy-7.ea.unisys.com [192.61.145.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id PAA12794; Tue, 19 Dec 2000 15:19:07 GMT Received: by us-ea-gtwy-7.ea.unisys.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 09:19:47 -0600 Message-ID: From: "Salter, Thomas A" To: Ryan Moats , "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 Date: Tue, 19 Dec 2000 09:20:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Maybe you need to change the wording so that instead of quoting characters, you quote the octets that make up the characters. > -----Original Message----- > From: Ryan Moats [mailto:rmoats@coreon.net] > Sent: Tuesday, December 19, 2000 9:37 AM > To: Kurt D. Zeilenga > Cc: ietf-ldapbis@OpenLDAP.org > Subject: RE: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 > > > Please, I understand UNICODE and laud what you are saying here. > However, my reading is that the draft covers this already, > because quotechar only shows up in: > > string = *( stringchar / pair ) > / "#" hexstring > / QUOTATION *( quotechar / pair ) QUOTATION > > so quotechar only needs to go to 0xFF as that covers all of the > UTF-8 encoding. > > I agree that the ABNF below is more specific, but I don't see > how changing quote character to -0xFF (and yes I got that > wrong the first time), breaks any of the examples in the draft. > > Ryan > > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, December 18, 2000 6:53 PM > To: rmoats@coreon.net > Cc: ietf-ldapbis@OpenLDAP.org > Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 > > > At 07:47 PM 12/18/00 -0500, rmoats@coreon.net wrote: > >Ok, I'll bite... what does ASCII have to do with this other > >than extending the last range to FF... > > Extending the range to FF is not sufficient. The ISO-10646-1 > character code range, IIRC, is 0x000000 - 0x7FFFFFFF. When > presented as UTF-8, each character spans from 1 to 6 octets > (derived from RFC2849): > > UTF8-CHAR = ASCII / UTF8-2 / UTF8-3 / > UTF8-4 / UTF8-5 / UTF8-6 > UTF8-1 = %x80-BF > UTF8-2 = %xC0-DF UTF8-1 > UTF8-3 = %xE0-EF 2UTF8-1 > UTF8-4 = %xF0-F7 3UTF8-1 > UTF8-5 = %xF8-FB 4UTF8-1 > UTF8-6 = %xFC-FD 5UTF8-1 > ASCII = %x00-7F > > Your original suggestion would limit escaping to only ASCII > characters. With the range extension, the escaping would > apply to the first octet of the character, not to the whole > character. > > Kurt > > > > >Ryan > > > >---- Original message ---- > >>Date: Mon, 18 Dec 2000 16:03:33 -0800 > >>From: "Kurt D. Zeilenga" > >>Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 > >>To: "Ryan Moats" > >>Cc: > >> > >>At 11:33 AM 12/10/00 -0600, Ryan Moats wrote: > >>>I'd suggest > >>> > >>> quotechar = %x00-%x21 / %x23-%x5B / %x5D-7F ; any > >character except "\" or > >>>QUOTATION > >> > >>Note that any character is not restricted to ASCII. > >> > >>Kurt > >> > > From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 11:08:37 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17038 for ; Tue, 19 Dec 2000 11:08:37 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJG7sj77333; Tue, 19 Dec 2000 16:07:54 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 16:07:54 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJG7rd77326 for ; Tue, 19 Dec 2000 16:07:53 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id QAA40548; Tue, 19 Dec 2000 16:07:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001219074817.02244020@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 08:07:42 -0800 To: "Salter, Thomas A" From: "Kurt D. Zeilenga" Subject: RE: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 Cc: Ryan Moats , 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 09:20 AM 12/19/00 -0600, Salter, Thomas A wrote: >Maybe you need to change the wording so that instead of quoting characters, >you quote the octets that make up the characters. Yes. Basically the issue is what are the tokens being parsed. The RFC2253 ABNF appears to be written in terms of characters, UTF-8 characters. When I start seeing code ranges restricted to 0x7F (or 0xFF), I start wondering whether or not the tokens are UTF-8 characters or Unicode code points or ASCII code points or octet values. Likely this should be clarified. From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 11:20:38 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17290 for ; Tue, 19 Dec 2000 11:20:37 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJGJwq78096; Tue, 19 Dec 2000 16:19:58 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 16:19:58 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJGJtd78076; Tue, 19 Dec 2000 16:19:56 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO83995 (AUTH rmoats); Tue, 19 Dec 2000 11:20:17 -0500 (EST) From: "Ryan Moats" To: "Kurt D. Zeilenga" , "Salter, Thomas A" Cc: "Ryan Moats" , Subject: RE: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 Date: Tue, 19 Dec 2000 10:20:38 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <5.0.0.25.0.20001219074817.02244020@router.boolean.net> Sender: 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 like this :-) Ryan -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga Sent: Tuesday, December 19, 2000 10:08 AM To: Salter, Thomas A Cc: Ryan Moats; ietf-ldapbis@OpenLDAP.org Subject: RE: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 At 09:20 AM 12/19/00 -0600, Salter, Thomas A wrote: >Maybe you need to change the wording so that instead of quoting characters, >you quote the octets that make up the characters. Yes. Basically the issue is what are the tokens being parsed. The RFC2253 ABNF appears to be written in terms of characters, UTF-8 characters. When I start seeing code ranges restricted to 0x7F (or 0xFF), I start wondering whether or not the tokens are UTF-8 characters or Unicode code points or ASCII code points or octet values. Likely this should be clarified. From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 11:43:20 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17848 for ; Tue, 19 Dec 2000 11:43:20 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJGgmp80030; Tue, 19 Dec 2000 16:42:48 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 16:42:48 +0000 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJGgkd80021 for ; Tue, 19 Dec 2000 16:42:46 GMT Received: from asn-1.com (user-2ivf80v.dialup.mindspring.com [165.247.160.31]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA05859 for ; Tue, 19 Dec 2000 11:42:44 -0500 (EST) Message-ID: <3A3F90AA.DB3995A7@asn-1.com> Date: Tue, 19 Dec 2000 11:45:30 -0500 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 References: <5.0.0.25.0.20001218163716.02202100@router.boolean.net> 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 there, It might be a good idea to not rely too heavily on everything that may appear in RFC 2849, but to consider using the most current materials from the unicode site, and to rely on the precise definitions of the restricted character string types found in the ASN.1 standards. See www.unicode.org/unicode/uni2errata/UTF-8_Corrigendum.html for a discussion relevant to the notion of the 5 and 6 byte sequences listed below. Note that the changes described at this link are very much in line with the long held notion in ASN.1 of string types whose values are said to be "restricted". Much is simply not allowed by the ASN.1 standards for such types (BOMs, escapes to other character sets) for the sole purpose of promoting secure interworking between applications. Phil ---- Phillip H. Griffin Griffin Consulting http://asn-1.com Secure ASN.1 Design & Implementation +1-919-832-7008 1625 Glenwood Avenue, Five Points +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA ------------------------------------------------------------ "Kurt D. Zeilenga" wrote: > > At 07:47 PM 12/18/00 -0500, rmoats@coreon.net wrote: > >Ok, I'll bite... what does ASCII have to do with this other > >than extending the last range to FF... > > Extending the range to FF is not sufficient. The ISO-10646-1 > character code range, IIRC, is 0x000000 - 0x7FFFFFFF. When > presented as UTF-8, each character spans from 1 to 6 octets > (derived from RFC2849): > > UTF8-CHAR = ASCII / UTF8-2 / UTF8-3 / > UTF8-4 / UTF8-5 / UTF8-6 > UTF8-1 = %x80-BF > UTF8-2 = %xC0-DF UTF8-1 > UTF8-3 = %xE0-EF 2UTF8-1 > UTF8-4 = %xF0-F7 3UTF8-1 > UTF8-5 = %xF8-FB 4UTF8-1 > UTF8-6 = %xFC-FD 5UTF8-1 > ASCII = %x00-7F > > Your original suggestion would limit escaping to only ASCII > characters. With the range extension, the escaping would > apply to the first octet of the character, not to the whole > character. > > Kurt > > >Ryan > > > >---- Original message ---- > >>Date: Mon, 18 Dec 2000 16:03:33 -0800 > >>From: "Kurt D. Zeilenga" > >>Subject: Re: ABNF tweak for draft-zeilenga-ldapbis-rfc2253-02 > >>To: "Ryan Moats" > >>Cc: > >> > >>At 11:33 AM 12/10/00 -0600, Ryan Moats wrote: > >>>I'd suggest > >>> > >>> quotechar = %x00-%x21 / %x23-%x5B / %x5D-7F ; any > >character except "\" or > >>>QUOTATION > >> > >>Note that any character is not restricted to ASCII. > >> > >>Kurt > >> From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 11:58:42 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18210 for ; Tue, 19 Dec 2000 11:58:40 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJGvo280746; Tue, 19 Dec 2000 16:57:50 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 16:57:50 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJGvmd80739 for ; Tue, 19 Dec 2000 16:57:48 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id QAA40777 for ; Tue, 19 Dec 2000 16:57:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001219083346.0225a110@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 08:57:42 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Revised DN ABNF 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 the latest DN ABNF. Please review for correctness and clarity (in particular, stringchar). Kurt The structure of the UTF-8 string is specified using the following Augmented BNF [RFC2234] grammar. distinguishedName = [name] ; may be empty name = name-component *(COMMA name-component) name-component = attributeTypeAndValue *(PLUS attributeTypeAndValue) attributeTypeAndValue = attributeType EQUALS attributeValue attributeType = (ALPHA 1*keychar) / oid keychar = ALPHA / DIGIT / MINUS oid = 1*DIGIT *(DOT 1*DIGIT) attributeValue = string / hexstring string = *( stringchar / pair ) ; the string MUST NOT start with SHARP or SP ; and MUST NOT end with SP special = escaped / SHARP / EQUALS / SP escaped = COMMA / PLUS / %x22 / %x3C / %x3E / %3B ; "," / "+" / """ / "<" / ">" / ";" pair = ESC ( ESC / special / hexpair ) stringchar = hexstring = SHARP 1*hexpair hexpair = HEX HEX HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 SP = %x20 ; space (" ") SHARP = %x23 ; sharp sign ("#") PLUS = %x2B ; plus sign ("+") COMMA = %x2C ; comma (",") MINUS = %x2D ; minus sign ("-") DOT = %x2E ; period (".") EQUALS = %x3D ; equals sign ("=") ESC = %x5C ; backslash ("\\") From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 17:31:35 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26462 for ; Tue, 19 Dec 2000 17:31:35 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBJMV0U06863; Tue, 19 Dec 2000 22:31:00 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Dec 2000 22:31:00 +0000 Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBJMUxd06856 for ; Tue, 19 Dec 2000 22:30:59 GMT Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id OAA28530 for ; Tue, 19 Dec 2000 14:30:58 -0800 (PST) Message-Id: <200012192230.OAA28530@fionn.es.net> To: ietf-ldapbis@OpenLDAP.org Reply-to: helm@fionn.es.net Subject: Re: present IANA "directory system names" list (aka "short attribute names") Date: Tue, 19 Dec 2000 14:30:58 -0800 From: Michael Helm Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: What is the plan for this repository? Is there a need for this kind of thing in order to prevent some kind of interoperability problem due to collisions? Or does the burden exceed the benefit? From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 20:40:30 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29516 for ; Tue, 19 Dec 2000 20:40:28 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBK1dfZ11394; Wed, 20 Dec 2000 01:39:41 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Dec 2000 01:39:41 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBK1dbd11362 for ; Wed, 20 Dec 2000 01:39:37 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id BAA42639; Wed, 20 Dec 2000 01:39:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001219144114.0224c100@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Dec 2000 17:38:30 -0800 To: helm@fionn.es.net From: "Kurt D. Zeilenga" Subject: Re: present IANA "directory system names" list (aka "short attribute names") Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <200012192230.OAA28530@fionn.es.net> 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:30 PM 12/19/00 -0800, Michael Helm wrote: >What is the plan for this repository? It is not clear what relationship this registry has to LDAPv3 DNs. This registry establishes keywords which may be used instead of attribute type OIDs only within LDAPv2 DNs (RFC1779). Note that LDAPv2 does not allow attribute type names to be used within a DN. The RFC2253 specification is similar. It also relies on a table to provide DN keywords, but describes them as 'type name strings' and does not provide an IANA registry for the these strings. However, like LDAPv2, the specification is quite clear that attribute types appearing in the table must be identified by the string in the table and all other attribute types must be identified by OID in dot-decimal form. If RFC2253 were to be progressed without significant change, the IANA registry established by RFC1779 would be become historical as RFC2253 obsoletes RFC1779. >Is there a need for this kind of thing in order to >prevent some kind of interoperability problem due >to collisions? There is a need for implementations to agree on an unambiguous representation of DNs which are intended to be globally unique (like DNS, there might be multiple globes but there is only one internationally recognized globe). Note that RFC2253, like RFC1779, offers no chance for attribute type naming collisions as attribute types are specified either by OID, which are globally unique, or centrally managed set of keywords associated with attribute types. A problem which has been voiced is that many implementations do not adhere to RFC2253, 2.3, restrictions for primarily historical reasons. Per discussions at IETF#49, this issue needs further list discussion. For this reason, I don't intend to address this problem (as well as the RFC2253, Section 4. problem) in the next revision of this DN update draft (which I should be able to submit within a day or two). Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 19 21:03:55 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29827 for ; Tue, 19 Dec 2000 21:03:55 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBK23RQ18688; Wed, 20 Dec 2000 02:03:28 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Dec 2000 02:03:27 +0000 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBK23Pd18681 for ; Wed, 20 Dec 2000 02:03:25 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA121366; Tue, 19 Dec 2000 21:02:38 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id VAA166328; Tue, 19 Dec 2000 21:01:16 -0500 Importance: Normal To: helm@fionn.es.net Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: present IANA "directory system names" list (aka "short attribute names") X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 From: "Timothy Hahn" Message-ID: Date: Tue, 19 Dec 2000 21:03:22 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V506_11152000.dev01 |November 27, 2000) at 12/19/2000 09:03:23 PM, Serialize complete at 12/19/2000 09:03:23 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000962D6852569BB_=" Sender: 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 multipart message in MIME format. --=_alternative 000962D6852569BB_= Content-Type: text/plain; charset="us-ascii" Michael, During the ELSE (Evolving LDAP Schema Entries) BOF in San Diego, the issues of potential collision in attribute type and object class names was discussed. Mortezza and Bob Joslin agreed to look into this a bit more and try to come up with some methodology for ensuring unique names (in addition to unique OIDs). Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 Please respond to helm@fionn.es.net Sent by: owner-ietf-ldapbis@OpenLDAP.org To: ietf-ldapbis@OpenLDAP.org cc: Subject: Re: present IANA "directory system names" list (aka "short attribute names") What is the plan for this repository? Is there a need for this kind of thing in order to prevent some kind of interoperability problem due to collisions? Or does the burden exceed the benefit? --=_alternative 000962D6852569BB_= Content-Type: text/html; charset="us-ascii"
Michael,

During the ELSE (Evolving LDAP Schema Entries) BOF in San Diego, the issues of potential collision in attribute type and object class names was discussed.

Mortezza and Bob Joslin agreed to look into this a bit more and try to come up with some methodology for ensuring unique names (in addition to unique OIDs).
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Please respond to helm@fionn.es.net

Sent by:        owner-ietf-ldapbis@OpenLDAP.org

To:        ietf-ldapbis@OpenLDAP.org
cc:        
Subject:        Re: present IANA "directory system names" list (aka "short attribute names")




What is the plan for this repository?
Is there a need for this kind of thing in order to
prevent some kind of interoperability problem due
to collisions?
Or does the burden exceed the benefit?

--=_alternative 000962D6852569BB_=-- From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 20 11:21:10 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01369 for ; Wed, 20 Dec 2000 11:21:08 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBKGJoG46071; Wed, 20 Dec 2000 16:19:50 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Dec 2000 16:19:50 +0000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBKGJnd46064 for ; Wed, 20 Dec 2000 16:19:49 GMT Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26686 for ; Wed, 20 Dec 2000 08:19:47 -0800 (PST) Received: from Sun.COM (kayak [129.156.220.150]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id QAA26437 for ; Wed, 20 Dec 2000 16:19:46 GMT Message-ID: <3A40DC24.B684C8A9@Sun.COM> Date: Wed, 20 Dec 2000 16:19:48 +0000 From: Jonathan Bruce Reply-To: jonathan.bruce@sun.com Organization: Sun Microsystems X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Clarification required in RFC 2831 - DIGEST-MD5 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 As part of the LDAPbis process there are a number of issues specifically related to RFC 2831 - 'Using Digest Authentication as a SASL Mechanism' that need to be clarified. Kurt Zeilenga has asked that I share my concerns with this interest list. RFC 2831 specifies confidentiality protection (see section 2.4) whereby client-server communications can be encrypted according to a format laid out in the RFC. The difficulty arises when either DES or Triple DES ciphers are used for confidentiality protection. However, RFC 2831 does not specify which DES mode (CBC, ECB, PCBC, CFB, OFB etc. ..), should be used if DES is the negotiated cipher. This gap in the RFC allows for possible interoperability issues allowing different vendors to potentiality opt for incompatible DES modes. Possible solutions include ... 1. Add an extra directive in the SASL exchange to allow the SASL client and server to negotiate a DES mode. 2. RFC 2831 is updated to specify exactly what DES mode should be used in the exchange, therefore removing any potential DES mode mismatches between the client and server. -Jonathan Bruce Java Software JNDI Sun Microsystems Inc. From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 20 11:48:26 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02995 for ; Wed, 20 Dec 2000 11:48:26 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBKGlpq48649; Wed, 20 Dec 2000 16:47:51 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Dec 2000 16:47:50 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBKGlnd48641 for ; Wed, 20 Dec 2000 16:47:49 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id QAA44724; Wed, 20 Dec 2000 16:47:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001220084416.022845c0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 20 Dec 2000 08:47:46 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: When to transmit binary 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 04:41 PM 11/15/00 -0700, Jim Sermersheim wrote: >Section 4.1.6 in RFC 2251states: > >"A field of type AttributeValue takes on as its value either a string encoding of a AttributeValue data type, or an OCTET STRING containing an encoded binary value, depending on whether the "binary" option is present in the companion AttributeDescription to this AttributeValue." > >We should state, in addition to the case where the binary option is present, that any AttributeValue with a Binary syntax is also encoded as binary. Right? No. The binary syntax, like many other syntaxes (e.g. JPEG) provide a string encoding. The fact that string encodings may or may not be restricted UTF-8 characters, per the attribute value data type description, is irrelevant to the above statement. From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 20 14:11:19 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11132 for ; Wed, 20 Dec 2000 14:11:17 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBKJAbB53501; Wed, 20 Dec 2000 19:10:37 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Dec 2000 19:10:37 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBKJAZd53494 for ; Wed, 20 Dec 2000 19:10:35 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id TAA45200; Wed, 20 Dec 2000 19:10:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001220110259.03b40a10@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 20 Dec 2000 11:10:31 -0800 To: jonathan.bruce@sun.com From: "Kurt D. Zeilenga" Subject: Re: Clarification required in RFC 2831 - DIGEST-MD5 Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3A40DC24.B684C8A9@Sun.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 04:19 PM 12/20/00 +0000, Jonathan Bruce wrote: >As part of the LDAPbis process there are a number of issues specifically related to RFC >2831 - 'Using Digest Authentication as a SASL Mechanism' that need to be clarified. Kurt >Zeilenga has asked that I share my concerns with this interest list. > >RFC 2831 specifies confidentiality protection (see section 2.4) whereby client-server >communications can be encrypted according to a format laid out in the RFC. The difficulty >arises when either DES or Triple DES ciphers are used for confidentiality protection. > >However, RFC 2831 does not specify which DES mode (CBC, ECB, PCBC, CFB, OFB etc. ..), >should be used if DES is the negotiated cipher. This gap in the RFC allows for possible >interoperability issues allowing different vendors to potentiality opt for incompatible >DES modes. At the top of page 5 of RFC 2831, the TS says: des the Data Encryption Standard (DES) cipher [FIPS] in cipher block chaining (CBC) mode with a 56 bit key. 3des the "triple DES" cipher in CBC mode with EDE with the same key for each E stage (aka "two keys mode") for a total key length of 112 bits. This seems to indicate that CBC mode is to be used. Is this not specific enough? Are there other areas you believe need clarification? >Possible solutions include ... Approach 2, clarifying the specification such that interpretations differences are narrowed to one, should be favored approach. From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 20 14:48:04 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12479 for ; Wed, 20 Dec 2000 14:48:03 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBKJlWN54478; Wed, 20 Dec 2000 19:47:32 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Dec 2000 19:47:32 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBKJlVd54469 for ; Wed, 20 Dec 2000 19:47:31 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id TAA45324; Wed, 20 Dec 2000 19:47:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001220112723.0224a920@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 20 Dec 2000 11:47:23 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: When to transmit binary 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 04:41 PM 11/15/00 -0700, Jim Sermersheim wrote: >Section 4.1.6 in RFC 2251states: > >"A field of type AttributeValue takes on as its value either a string encoding of a AttributeValue data type, or an OCTET STRING containing an encoded binary value, depending on whether the "binary" option is present in the companion AttributeDescription to this AttributeValue." One thing that some have found confusing is whether or not there is an additional OCTET STRING wrapper around the encoded binary value. That is, the statement can be read: For the binary option, a field of type AttributeValue, an OCTET STRING, takes on its value an OCTET STRING containing an encoded binary value. Otherwise, a field of type AttributeValue, an OCTET STRING, takes as its value a string encoding of a AttributeValue data type. For the binary option, this seems inconsistent with 4.1.5.1, RFC2252 4.3.1, and prior discussions on the LDAPext list. I suggest the wording be changed to: A field of type AttributeVale, an OCTET STRING, takes on as its value either a string encoding of the value, or the BER encoding of the of the value, depending on whether the "binary" option is present in the companion AttributeDescription of this AttributeValue. I also believe that RFC2252, 4.3.1 needs to be clarified to state that as the binary syntax itself is not described using ASN.1, values of binary syntax can not be transferred using the ";binary" option. That is, given: ( 1.2.3 NAME 'foo' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 ) "foo;binary" is makes no sense. The attribute should simply be transferred using the defined string encoding of the attribute, e.g. as "foo". Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 20 20:32:05 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21324 for ; Wed, 20 Dec 2000 20:32:04 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBL1VSD67834; Thu, 21 Dec 2000 01:31:28 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 01:31:28 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBL1VRd67827 for ; Thu, 21 Dec 2000 01:31:27 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id BAA46857; Thu, 21 Dec 2000 01:31:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001220171406.03b7cad0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 20 Dec 2000 17:31:19 -0800 To: "Mark Hinckley" From: "Kurt D. Zeilenga" Subject: Re: UTC Time reference in RFC 2252 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 reviewing X.500 documents, the term "OBSOLETE", a component of administrative policy, has specific semantics which is quite different from simply stating a particular schema element is "obsolete" (as is "deprecated"). We should avoid adding "OBSOLETE" to any schema element description but may add a note indicating that a particular element is "obsolete" or "deprecated" where appropriate. In particular, for UTCtime, I suggest: Note: this syntax is deprecated in favor of the generalizedTime syntax Such a note does not disallow use of the element. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 10:19:10 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21715 for ; Thu, 21 Dec 2000 10:19:09 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLALeP98854; Thu, 21 Dec 2000 10:21:40 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 10:21:40 +0000 Received: from tyholt.uninett.no (IDENT:root@tyholt.uninett.no [158.38.60.10]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBLALcd98847 for ; Thu, 21 Dec 2000 10:21:38 GMT Received: from sverresborg.uninett.no (IDENT:root@sverresborg.uninett.no [158.38.60.92]) by tyholt.uninett.no (8.11.1/8.11.1) with ESMTP id eBLALaf01480 for ; Thu, 21 Dec 2000 11:21:36 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.10.1/8.10.1) id eBLAKvX08328 for ietf-ldapbis@OpenLDAP.org; Thu, 21 Dec 2000 11:20:57 +0100 Date: Thu, 21 Dec 2000 11:20:57 +0100 From: Stig Venaas To: ietf-ldapbis@OpenLDAP.org Subject: matching for facsimileTelephoneNumber Message-ID: <20001221112057.C8179@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: RFC 2256 defines no matching for facsimileTelephoneNumber. I think it's reasonable to have equality matching at least. Can this be changed, or do we have to stick to X.520? Stig From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 10:35:05 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22353 for ; Thu, 21 Dec 2000 10:35:04 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLFYX127256; Thu, 21 Dec 2000 15:34:33 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 15:34:33 +0000 Received: (from kurt@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) id eBLFYVf27240 for ietf-ldapbis@openldap.org; Thu, 21 Dec 2000 15:34:31 GMT Received: from ietf.org (odin.ietf.org [132.151.1.176]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBLBkDd00940 for ; Thu, 21 Dec 2000 11:46:13 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15099; Thu, 21 Dec 2000 06:46:11 -0500 (EST) Message-Id: <200012211146.GAA15099@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-dn-00.txt Date: Thu, 21 Dec 2000 06:46:10 -0500 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. Title : Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names Author(s) : K. Zeilenga Filename : draft-ietf-ldapbis-dn-00.txt Pages : 9 Date : 20-Dec-00 The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight Directory Access Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-00.txt 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-dn-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-dn-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: <20001220160759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-dn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-dn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001220160759.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 11:40:12 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23734 for ; Thu, 21 Dec 2000 11:40:12 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLF4ca20713; Thu, 21 Dec 2000 15:04:38 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 15:04:38 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBLF4Zd20698 for ; Thu, 21 Dec 2000 15:04:35 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO90374 (AUTH rmoats); Thu, 21 Dec 2000 10:04:39 -0500 (EST) From: "Ryan Moats" To: "Stig Venaas" , Subject: RE: matching for facsimileTelephoneNumber Date: Thu, 21 Dec 2000 09:05:13 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20001221112057.C8179@sverresborg.uninett.no> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: 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 IMHO... If it isn't in X.520, then its a topic for LDAPEXT. (ietf-ldapext@netscape.com). No new functionality in LDAPBIS. Ryan -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Stig Venaas Sent: Thursday, December 21, 2000 4:21 AM To: ietf-ldapbis@OpenLDAP.org Subject: matching for facsimileTelephoneNumber RFC 2256 defines no matching for facsimileTelephoneNumber. I think it's reasonable to have equality matching at least. Can this be changed, or do we have to stick to X.520? Stig From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 12:35:17 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25377 for ; Thu, 21 Dec 2000 12:35:16 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLHYZt39243; Thu, 21 Dec 2000 17:34:35 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 17:34:35 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBLHYYd39232 for ; Thu, 21 Dec 2000 17:34:34 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id RAA49567 for ; Thu, 21 Dec 2000 17:34:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001221083739.021b4720@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Dec 2000 09:34:30 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Revised DN TS 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 reissued draft-zeilenga-ldapbis-rfc2253-01.txt as draft-ietf-ldapbis-dn-00.txt based upon discussions on this list. - Updated 2.3 to clarify which table is the published table of names which may be appear in DNs. Remove "as an example" language. - Updated 2.4 to allow hex pair escaping of all characters and clarified escaping for when multiple octet UTF-8 characters are present. - Rewrote Section 3 to use ABNF as defined in RFC 2234. - Rewrote Section 3 ABNF to be consistent with 2.4. As noted at IETF#49, the following major issues need to be discussed: a) what "type string names" may be used to identify attribute types in the generation names (and, hence, required to be recognized by protocol peers)? I will separately post my comments regarding this issue. b) what is the "Relationship with RFC1779 and LDAPv2"? I will separately post my comments regarding this issue. In addition, there is an additional, I hope, minor issue: c) normative references 2.3 refers to 'domainComponent' (dc) and 'userId' (uid) X.500 attribute types. RFC 1274, a Proposed Standard, describes 'domainComponent' and 'userid'. RFC 2247 provides an LDAP attribute description for 'domainComponent' using the short name 'dc'. So that a normative reference to RFC 1274 and/or 2247 is not necessary, I suggest that RFC2256bis include LDAP attribute descriptions for 'dc' (domainComponent) and 'uid' (userid) based upon their X.500 counter part descriptions in X.520 and elsewhere. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 14:41:46 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28497 for ; Thu, 21 Dec 2000 14:41:45 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLJfBI44482; Thu, 21 Dec 2000 19:41:11 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 19:41:11 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBLJfAd44475 for ; Thu, 21 Dec 2000 19:41:10 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id TAA50030; Thu, 21 Dec 2000 19:40:56 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001221113044.021b2eb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Dec 2000 11:40:55 -0800 To: "Ryan Moats" From: "Kurt D. Zeilenga" Subject: RE: matching for facsimileTelephoneNumber Cc: "Stig Venaas" , In-Reply-To: References: <20001221112057.C8179@sverresborg.uninett.no> 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:05 AM 12/21/00 -0600, Ryan Moats wrote: >IMHO... If it isn't in X.520, then its a topic for LDAPEXT. >(ietf-ldapext@netscape.com). No new functionality in LDAPBIS. I note, per our charter, that all schema items which are not required and/or described by the LDAPv3 "core" technical specification are not within scope of the LDAPbis WG. facsimileTelephoneNumber is described by the LDAPv3 "core" technical specification, so it is within scope. However, the proposed change, IMO, would be inappropriate as it would create, not resolve, interoperability problems. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 14:49:09 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28620 for ; Thu, 21 Dec 2000 14:49:07 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLJmcY45199; Thu, 21 Dec 2000 19:48:38 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 19:48:38 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBLJmZd45191; Thu, 21 Dec 2000 19:48:35 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO91677 (AUTH rmoats); Thu, 21 Dec 2000 14:48:56 -0500 (EST) From: "Ryan Moats" To: "Kurt D. Zeilenga" Cc: "Stig Venaas" , Subject: RE: matching for facsimileTelephoneNumber Date: Thu, 21 Dec 2000 13:49:25 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.0.0.25.0.20001221113044.021b2eb0@router.boolean.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit ?!?! I agree with what you said, but the request was to specify a matching rule for facsimileTelephoneNumber. This is not currently done by X.520 so I claim the matching rule is NOT part of the "core" spec and so is out of scope. If we are going to start specifying matching rules for things in X.520 that don't have them I claim we've strayed into new functionality. I think we are in agreement about the approriateness of this suggestion, but for different reasons. Ryan -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga Sent: Thursday, December 21, 2000 1:41 PM To: Ryan Moats Cc: Stig Venaas; ietf-ldapbis@OpenLDAP.org Subject: RE: matching for facsimileTelephoneNumber At 09:05 AM 12/21/00 -0600, Ryan Moats wrote: >IMHO... If it isn't in X.520, then its a topic for LDAPEXT. >(ietf-ldapext@netscape.com). No new functionality in LDAPBIS. I note, per our charter, that all schema items which are not required and/or described by the LDAPv3 "core" technical specification are not within scope of the LDAPbis WG. facsimileTelephoneNumber is described by the LDAPv3 "core" technical specification, so it is within scope. However, the proposed change, IMO, would be inappropriate as it would create, not resolve, interoperability problems. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 17:50:05 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03680 for ; Thu, 21 Dec 2000 17:50:04 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLMnZ352663; Thu, 21 Dec 2000 22:49:35 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 22:49:35 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLMnXd52653 for ; Thu, 21 Dec 2000 22:49:33 GMT Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 21 Dec 2000 15:49:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 21 Dec 2000 15:49:04 -0700 From: "Jim Sermersheim" To: , Subject: Re: some outstanding items for clarification Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id eBLMnYd52655 Sender: 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 >>>> "Timothy Hahn" 12/12/00 6:33:32 AM >>> >Greetings, > >In reading the latest drafts I found the following items either not >specified or under-specified. I believe that these were not adequately >covered in RFC 2251-2256 and since we're looking to move these forward in >this group, I would like to see clarifications on these with the goal of >better interoperability across implemenatations. > >1) Null attribute values. Some implementations are known to accept >zero-length values for attributes. I found no information in the RFCs or >drafts that dis-allows this. Could someone clarify whether the LDAP data >model allows zero-length attribute values? My take is that this is generaly implicitly allowed (except where disallowed as in country), and explicitly called out in at least one case (namingContexts in 5.2.1.of 2252). Unfortunately, LDAP doesn't have any way of conveying a minimum length (only a suggested max) in the schema for attribute values. >2) Some implementations always "publish" schema at "cn=schema". Right or >wrong, some applications have assumed that there will always be a subschema >entry in every server named "cn=schema". My interpretation of the RFCs and >drafts is that "publishing schema" at a "fixed" DN is NOT required and >should not be relied upon by clients. I assert that we should not disallow >publishing schema at a subschema entry named "cn=schema" - but it should >not be required either. This is more of an education issue right? The specification doesn't mandate the name of the entry. I think one vendor chose cn=schema, and everyone else just followed. If I remember right, client writers that hard code to cn=schema will be dismayed when they try to run against OpenLDAP. I think the other topics are being/have been discussed in other threads From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 18:16:23 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04268 for ; Thu, 21 Dec 2000 18:16:21 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBLNFuD53032; Thu, 21 Dec 2000 23:15:56 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Dec 2000 23:15:56 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBLNFsd53025 for ; Thu, 21 Dec 2000 23:15:54 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id XAA50843; Thu, 21 Dec 2000 23:15:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001221150246.0221f420@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Dec 2000 15:15:51 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: some outstanding items for clarification 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 03:49 PM 12/21/00 -0700, Jim Sermersheim wrote: >>>>> "Timothy Hahn" 12/12/00 6:33:32 AM >>> >>1) Null attribute values. Some implementations are known to accept >>zero-length values for attributes. I found no information in the RFCs or >>drafts that dis-allows this. Could someone clarify whether the LDAP data >>model allows zero-length attribute values? > >My take is that this is generaly implicitly allowed (except where disallowed >as in country), and explicitly called out in at least one case (namingContexts >in 5.2.1.of 2252). Whether or not a value may be empty is per syntax. Note that the directoryString does not allow empty values whereas octetString does. >>2) Some implementations always "publish" schema at "cn=schema". Right or >>wrong, some applications have assumed that there will always be a subschema >>entry in every server named "cn=schema". My interpretation of the RFCs and >>drafts is that "publishing schema" at a "fixed" DN is NOT required and >>should not be relied upon by clients. I assert that we should not disallow >>publishing schema at a subschema entry named "cn=schema" - but it should >>not be required either. > >This is more of an education issue right? The specification doesn't mandate the >name of the entry. I think one vendor chose cn=schema, and everyone else just >followed. If I remember right, client writers that hard code to cn=schema will be >dismayed when they try to run against OpenLDAP. It our intent to support multiple subschemas which requires clients be able to discover schema by read the appropriate subschemaSubentry value. I specifically choose a different DN so as to discourage hard coding within clients. I don't believe there needs to be any clarification as to where implementations may locate subschema entries (or subentries). However, I do note that the schema discovery section needs to be revised in that the Root DSE subschema discover mechanism is flawed (see my 2252 I-D for a suggested change, see LDAPext archives for prior discussion). Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 19:01:35 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05148 for ; Thu, 21 Dec 2000 19:01:34 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBM00th53830; Fri, 22 Dec 2000 00:00:55 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 00:00:55 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBM00sd53822 for ; Fri, 22 Dec 2000 00:00:54 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id AAA50958 for ; Fri, 22 Dec 2000 00:00:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001221114429.021a8520@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Dec 2000 14:54:52 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: DN "a published table" clarification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I believe that RFC 2253, Section 2.3 was unclear when it referred to "a published table". I fully concur with Mark Wahl's 11/1/2000 post that the table being referred to is the table published within the section. In the revision DN I-D, I offer a clarification to this effect. If others believe RFC2253 was actually referring to some other table, please speak up. The type name string restrictions remains as specified in RFC2253, 2.3. I acknowledge that many, but not all, implementations generate DNs which is not allowed by RFC2253 (when using LDAPv3) and/or RFC1779 (when using RFC1779). However, unless there is specific lack of completeness or clarity or technical weakness of within the specification which someone can point out, I cannot offer any edit. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Dec 21 22:50:41 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10662 for ; Thu, 21 Dec 2000 22:50:39 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBM3o5Y58507; Fri, 22 Dec 2000 03:50:05 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 03:50:05 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBM3o4d58497 for ; Fri, 22 Dec 2000 03:50:04 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id DAA51693 for ; Fri, 22 Dec 2000 03:50:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001221160328.02227880@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Dec 2000 19:49:36 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: DN "Relationship with LDAPv2 and RFC1779" Removal 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: As previously noted, I have removed the "Relationship with LDAPv2 and RFC1779" section and references to it from the DN revision I-D as this section only appears relevant if parsing DNs generated by an LDAPv2 client. My interpretation assumes: - An LDAPv2 client talks LDAPv2 (RFC1777) to a LDAPv2 server - An LDAPv3 client talks LDAPv3 (RFC2251) to a LDAPv3 server - There may be implementations which support both LDAPv2 and LDAPv3 but use one or the other when talking with a particular peer. - RFC2253 obsoletes RFC1779 - RFC2253 has no normative reference to RFC1779 Section 3 says: Server implementations parsing a DN string generated by an LDAPv2 client MUST also accept (and ignore) the variants given in section 4 of this document. As an LDAPv3 server is never faced with parsing a DN string generated by an LDAPv2 client, no LDAPv3 server is required to accept (and ignore) the variants given in section 4. As an LDAPv2 server is required by RFC 1777/1779 to parse DNs generated by LDAPv2 clients and RFC 2253 (with or without these variants) is more restrictive syntax than RFC 1779, the requirement is redundant. When I apply the my assumptions to the remainder of the RFC 2253, including the grammar, comments within the grammar, and Section 4 itself, I arrives at a consistent interpretation that Section 4 does not place restrictions upon LDAPv3 implementations. If there other interpretations of LDAPv2/RFC1779 relationship, I would be quite interested in how such interpretations are arrived at. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 02:43:09 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26443 for ; Fri, 22 Dec 2000 02:43:08 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBM7gbP63519; Fri, 22 Dec 2000 07:42:37 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 07:42:37 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBM7gZd63512 for ; Fri, 22 Dec 2000 07:42:35 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id HAA52128 for ; Fri, 22 Dec 2000 07:42:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001221224820.00a691c0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Dec 2000 23:42:33 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: DN "Relationship with LDAPv2 and RFC1779" Removal In-Reply-To: <5.0.0.25.0.20001221160328.02227880@router.boolean.net> 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: Playing devil's advocate... At 07:49 PM 12/21/00 -0800, Kurt D. Zeilenga wrote: >Section 3 says: > Server implementations parsing a DN string generated by an LDAPv2 > client MUST also accept (and ignore) the variants given in section 4 > of this document. Assume: The syntax given in this document is more restrictive than the syntax in RFC 1779. Implementations parsing a string generated by an LDAPv2 client MUST accept the syntax of RFC 1779. Implementations MUST NOT, however, generate any of the RFC 1779 encodings which are not described above in section 2. was meant to be interpreted as saying: Implementations MUST accept the syntax of RFC 1779 but MUST generate DNs per section 2. As all the additional variants with the section are required by the RFC 1799 syntax, the rest of section 4 is redundant. Given this, one can replace all of section 4 by refining the section 3 statement: "Server implementations parsing a DN string generated by an LDAPv2 client MUST also accept (and ignore) the variants given in section 4 of this document." to read: "All implementations MUST also accept the syntax of RFC 1779 but MUST generate DNs per section 2." Now, as we cannot have a normative reference to RFC 1779, we need to incorporate all the variants of RFC 1779's syntax into the Section 3 grammar.... and at this point we might as well drop "MUST generate DNs per section 2" requirement. However, I was under the impression that the more restrictive syntax was introduced to ease the encoding and decoding of the DN string. It seems to me that the interpretation that all implementations must parse RFC 1779 syntax is not consistent with the introduction of the more restrictive syntax. It also seems very odd to me that RFC 2253 appears to place different requirements upon LDAPv3 servers than LDAPv2 clients. I believe this is inconsistent with the interpretation that all implementations must parse RFC 1779 syntax (as well as just not making much sense). The only reasonable explanation I can come up with is that RFC2253 requires dual server implementations to support the RFC 1779 syntax when using LDAPv2 and the more restrictive RFC 2253 syntax when using LDAPv3 and just didn't consider the dual client implementations. MarkW, do you have any insight how the Section 4 was intended to be interpeted? From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 03:10:41 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26741 for ; Fri, 22 Dec 2000 03:10:40 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBM8A9863844; Fri, 22 Dec 2000 08:10:09 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 08:10:09 +0000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBM8A8d63837 for ; Fri, 22 Dec 2000 08:10:08 GMT Received: from sunfra.France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA23739 for ; Fri, 22 Dec 2000 00:10:06 -0800 (PST) Received: from odin.France.Sun.COM (odin [129.157.192.2]) by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id JAA02264 for ; Fri, 22 Dec 2000 09:10:05 +0100 (MET) Received: from france.sun.com by odin.France.Sun.COM (SMI-8.6/SMI-SVR4) id JAA24772; Fri, 22 Dec 2000 09:10:05 +0100 Message-ID: <3A430C52.80768358@france.sun.com> Date: Fri, 22 Dec 2000 09:09:54 +0100 From: Rob Byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: 2829 questions 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 I posted this on ldapext...hope it's in the right place now! Hi Authentication Guys, A few questions come to mind when thinking about Authentication as used by the acl draft... 1. reading 2829bis it sounds like DIGEST-MD5 is mandatory ONLY IF your server supports password based authentication because of Section 4 point 2: "(2) Implementations providing password-based authenticated access MUST support authentication using the DIGEST-MD5 SASL mechanism [4], as described in section 6.1." ...but the following makes it sound mandatory to provide BOTH password authentication AND DIGEST-MD5: "6.2. Digest authentication LDAP implementations MUST support authentication with a password using the DIGEST-MD5 SASL mechanism for password protection, as defined in section 6.1." The thing is for acl it would be nice (though not critical) to be able to default the required authentication level for a subject to a single "fairly secure" mechanism--if there is no such mandatory authentication scheme then you cannot do that. 2. I think it would be good to have some comments or explicit reference to a place where the security properties of the particular mandatory authentication schemes are outlined. When I say "security properties" I mean stuff like "This scheme is vulnerable to such and such attacks, is only safe if the key size is > 50, this hash is widely considered the best, etc...". I think an LDAP implementor is likely to be interested in that information, without having to wade through the security RFCs. 3. This is a question rather than a suggestion for a change to 2829...again on the subject of authentication level, is it possible to define an ordering on authentication levels which defines their relative "strengths" ? This would be useful in acl as you could say things like "a given aci grants access to a given subject at this authentication level AND ABOVE". David Chadwick raised this before in the context of denying access to a subject at a given authentication level, in which case he wanted to express "deny access to this subject at this authentication level AND TO ALL IDENTITIES AUTHENTICATED BELOW THAT LEVEL". Rob. From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 05:50:58 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27951 for ; Fri, 22 Dec 2000 05:50:57 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMAnwa67435; Fri, 22 Dec 2000 10:49:58 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 10:49:58 +0000 Received: from perq.cac.washington.edu (c986708-c.sttln1.wa.home.com [24.9.54.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMAntd67428 for ; Fri, 22 Dec 2000 10:49:55 GMT Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.11.0/8.11.0) with ESMTP id eBMAnQN04230; Fri, 22 Dec 2000 02:49:27 -0800 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Fri, 22 Dec 2000 02:49:26 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: Reply-To: "RL 'Bob' Morgan" To: Rob Byrne cc: Subject: Re: 2829 questions In-Reply-To: <3A430C52.80768358@france.sun.com> 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, 22 Dec 2000, Rob Byrne wrote: > I posted this on ldapext...hope it's in the right place now! Well, I think your questions are really questions about RFC 2829, hence legitimately in ldapext, but whatever. > 1. reading 2829bis it sounds like DIGEST-MD5 is mandatory ONLY IF your > server > supports password based authentication because of Section 4 point 2: > > "(2) Implementations providing password-based authenticated access > MUST support authentication using the DIGEST-MD5 SASL mechanism > [4], as described in section 6.1." > > ...but the following makes it sound mandatory to provide BOTH password > authentication AND DIGEST-MD5: > > "6.2. Digest authentication > > LDAP implementations MUST support authentication with a password > using the DIGEST-MD5 SASL mechanism for password protection, as > defined in section 6.1." I agree that the language in section 4 of 2829 (the (1)(2)(3) bullets that specify conformance) is somewhat confusing, especially since the text in section 6 is about the same thing but is slightly different. I think the section 4 text started life as "here are the logical conclusions you come to based on the security requirements" but turned into conformance text later. This needs to be clarified as we revise this doc. The intent, I think, is exactly what section 6 says: conformant LDAPv3 implementations have to support DIGEST, end of story. The doc also is trying to say that DIGEST *is* "authentication with a password"; this point may not be clear to you since you ask whether it has to support both. Support for passwords via simple-bind-over-TLS is a SHOULD, not a MUST. > The thing is for acl it would be nice (though not critical) to be able > to default the required authentication level for a subject to a single > "fairly secure" mechanism--if there is no such mandatory authentication > scheme then you cannot do that. Well, DIGEST is the mandatory authentication mechanism. I'm not familiar enough with the acl draft to know what the issue is there, but I'm guessing that a default would want to be implementation-defined or deployer-defined, not defined in the spec. > 2. I think it would be good to have some comments or explicit > reference to a place where the security properties of the particular > mandatory authentication schemes are outlined. When I say "security > properties" I mean stuff like "This scheme is vulnerable to such and > such attacks, is only safe if the key size is > 50, this hash is > widely considered the best, etc...". I think an LDAP implementor is > likely to be interested in that information, without having to wade > through the security RFCs. Well ... security folks needing to work with LDAP would probably like LDAP docs to tell them how to design a DIT, and the answer of course is "it depends"; and it's the same with security levels. There is only one mandatory-to-implement scheme, DIGEST, and its security properties are defined in excruciating detail in section 3 of RFC 2831. It's considered relatively easy to implement and deploy, and relatively secure compared to other similar easy-to-deploy mechanisms (CRAM in particular), which is why it's mandatory. Comparing the properties of, say, TLS and DIGEST and GSS/Kerberos would be a fascinating, complex, and controversial piece of work; I can't see any way to fit useful material on this topic into an LDAP standards document. Recommendations on things like key sizes are even more ephemeral and context-dependent. > 3. This is a question rather than a suggestion for a change to > 2829...again on the subject of authentication level, is it possible to > define an ordering on authentication levels which defines their > relative "strengths" ? This would be useful in acl as you could say > things like "a given aci grants access to a given subject at this > authentication level AND ABOVE". David Chadwick raised this before in > the context of denying access to a subject at a given authentication > level, in which case he wanted to express "deny access to this subject > at this authentication level AND TO ALL IDENTITIES AUTHENTICATED BELOW > THAT LEVEL". I have heard of deployments that did this kind of thing (eg a brokerage website that says "you can't make trades over $1M unless you authenticated with a client cert"). I don't see any way to do this in a standards doc, since there are too many context-dependent elements that contribute to an assessment of "strength". We can agree that traditional replayable-passwords-in-the-clear is "weak", and all the others are "stronger". We can agree that a mechanism that provides and integrity-protected data stream is stronger than one that doesn't. But is Kerberos stronger than DIGEST? Is S/Key? Is Kerberos stronger than passwords-over-TLS? There's no way to answer these in general, IMHO. - RL "Bob" From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 09:25:28 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03154 for ; Fri, 22 Dec 2000 09:25:27 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMEOiW70322; Fri, 22 Dec 2000 14:24:44 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 14:24:44 +0000 Received: from bbmail1-out.unisys.com ([192.63.108.40]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMEOfd70314; Fri, 22 Dec 2000 14:24:42 GMT Received: from us-bb-gtwy-3.bb.unisys.com (us-bb-gtwy-3.bb.unisys.com [192.63.78.153]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id OAA17280; Fri, 22 Dec 2000 14:19:20 GMT Received: by us-bb-gtwy-3.bb.unisys.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 09:24:30 -0500 Message-ID: From: "Salter, Thomas A" To: "Kurt D. Zeilenga" , ietf-ldapbis@OpenLDAP.org Subject: RE: DN "a published table" clarification Date: Fri, 22 Dec 2000 09:24:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Well, I interpret it differently. RFC2253, 2.3 says, "If the AttributeType is in a published table of attribute types associated with LDAP [4], ...". I take that to mean the table is the entire reference [4], namely RFC2252. Thus the names for all attributes defined in RFC2252 can be used. The table in section 2.3 is introduced as, "As an example, strings for a few of the attribute types frequently seen in RDNs include:" The table is clearly identified as an example, not as an exhaustive list of all allowed attribute names. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, December 21, 2000 5:55 PM > To: ietf-ldapbis@OpenLDAP.org > Subject: DN "a published table" clarification > > > I believe that RFC 2253, Section 2.3 was unclear when it > referred to "a published table". I fully concur with Mark > Wahl's 11/1/2000 post that the table being referred to is > the table published within the section. In the revision DN > I-D, I offer a clarification to this effect. If others > believe RFC2253 was actually referring to some other table, > please speak up. The type name string restrictions remains > as specified in RFC2253, 2.3. > > I acknowledge that many, but not all, implementations generate > DNs which is not allowed by RFC2253 (when using LDAPv3) and/or > RFC1779 (when using RFC1779). However, unless there is specific > lack of completeness or clarity or technical weakness of within > the specification which someone can point out, I cannot offer > any edit. > > Kurt > From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 09:37:47 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03535 for ; Fri, 22 Dec 2000 09:37:46 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMEbDZ70526; Fri, 22 Dec 2000 14:37:13 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 14:37:12 +0000 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMEb9d70518; Fri, 22 Dec 2000 14:37:09 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA76762; Fri, 22 Dec 2000 09:36:15 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA56432; Fri, 22 Dec 2000 09:34:50 -0500 Importance: Normal To: "Kurt D. Zeilenga" Cc: "Jim Sermersheim" , Subject: Re: some outstanding items for clarification X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 From: "Timothy Hahn" Message-ID: Date: Fri, 22 Dec 2000 09:37:01 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V506_11152000.dev01 |November 27, 2000) at 12/22/2000 09:37:01 AM, Serialize complete at 12/22/2000 09:37:01 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004F82FC852569BD_=" Sender: 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 multipart message in MIME format. --=_alternative 004F82FC852569BD_= Content-Type: text/plain; charset="us-ascii" Jim and Kurt, Thanks for the clarifications. As long as we're all comfortable that the revised RFCs are clear enough that these things are allowed, then I'm happy. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 Sent by: owner-ietf-ldapbis@OpenLDAP.org To: "Jim Sermersheim" cc: , Timothy Hahn/Endicott/IBM@IBMUS Subject: Re: some outstanding items for clarification At 03:49 PM 12/21/00 -0700, Jim Sermersheim wrote: >>>>> "Timothy Hahn" 12/12/00 6:33:32 AM >>> >>1) Null attribute values. Some implementations are known to accept >>zero-length values for attributes. I found no information in the RFCs or >>drafts that dis-allows this. Could someone clarify whether the LDAP data >>model allows zero-length attribute values? > >My take is that this is generaly implicitly allowed (except where disallowed >as in country), and explicitly called out in at least one case (namingContexts >in 5.2.1.of 2252). Whether or not a value may be empty is per syntax. Note that the directoryString does not allow empty values whereas octetString does. >>2) Some implementations always "publish" schema at "cn=schema". Right or >>wrong, some applications have assumed that there will always be a subschema >>entry in every server named "cn=schema". My interpretation of the RFCs and >>drafts is that "publishing schema" at a "fixed" DN is NOT required and >>should not be relied upon by clients. I assert that we should not disallow >>publishing schema at a subschema entry named "cn=schema" - but it should >>not be required either. > >This is more of an education issue right? The specification doesn't mandate the >name of the entry. I think one vendor chose cn=schema, and everyone else just >followed. If I remember right, client writers that hard code to cn=schema will be >dismayed when they try to run against OpenLDAP. It our intent to support multiple subschemas which requires clients be able to discover schema by read the appropriate subschemaSubentry value. I specifically choose a different DN so as to discourage hard coding within clients. I don't believe there needs to be any clarification as to where implementations may locate subschema entries (or subentries). However, I do note that the schema discovery section needs to be revised in that the Root DSE subschema discover mechanism is flawed (see my 2252 I-D for a suggested change, see LDAPext archives for prior discussion). Kurt --=_alternative 004F82FC852569BD_= Content-Type: text/html; charset="us-ascii"
Jim and Kurt,

Thanks for the clarifications.  As long as we're all comfortable that the revised RFCs are clear enough that these things are allowed, then I'm happy.

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        owner-ietf-ldapbis@OpenLDAP.org

To:        "Jim Sermersheim" <jimse@novell.com>
cc:        <ietf-ldapbis@OpenLDAP.org>, Timothy Hahn/Endicott/IBM@IBMUS
Subject:        Re: some outstanding items for clarification



At 03:49 PM 12/21/00 -0700, Jim Sermersheim wrote:
>>>>> "Timothy Hahn" <hahnt@us.ibm.com> 12/12/00 6:33:32 AM >>>
>>1) Null attribute values.  Some implementations are known to accept
>>zero-length values for attributes.  I found no information in the RFCs or
>>drafts that dis-allows this.  Could someone clarify whether the LDAP data
>>model allows zero-length attribute values?
>
>My take is that this is generaly implicitly allowed (except where disallowed
>as in country), and explicitly called out in at least one case (namingContexts
>in 5.2.1.of 2252).
Whether or not a value may be empty is per syntax.
Note that the directoryString does not allow empty values
whereas octetString does.
>>2) Some implementations always "publish" schema at "cn=schema".  Right or
>>wrong, some applications have assumed that there will always be a subschema
>>entry in every server named "cn=schema".  My interpretation of the RFCs and
>>drafts is that "publishing schema" at a "fixed" DN is NOT required and
>>should not be relied upon by clients.  I assert that we should not disallow
>>publishing schema at a subschema entry named "cn=schema" - but it should
>>not be required either.
>
>This is more of an education issue right? The specification doesn't mandate the
>name of the entry. I think one vendor chose cn=schema, and everyone else just
>followed. If I remember right, client writers that hard code to cn=schema will be
>dismayed when they try to run against OpenLDAP.
It our intent to support multiple subschemas which requires
clients be able to discover schema by read the appropriate
subschemaSubentry value.  I specifically choose a different
DN so as to discourage hard coding within clients.
I don't believe there needs to be any clarification as to
where implementations may locate subschema entries (or
subentries).
However, I do note that the schema discovery section needs to
be revised in that the Root DSE subschema discover mechanism
is flawed (see my 2252 I-D for a suggested change, see LDAPext
archives for prior discussion).
Kurt


--=_alternative 004F82FC852569BD_=-- From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 13:03:46 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09230 for ; Fri, 22 Dec 2000 13:03:45 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMI37g74441; Fri, 22 Dec 2000 18:03:07 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 18:03:07 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMI35d74431 for ; Fri, 22 Dec 2000 18:03:05 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id SAA53162; Fri, 22 Dec 2000 18:03:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001222080033.00ab0c80@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 22 Dec 2000 10:02:59 -0800 To: "Salter, Thomas A" From: "Kurt D. Zeilenga" Subject: RE: DN "a published table" clarification 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 09:24 AM 12/22/00 -0500, Salter, Thomas A wrote: >Well, I interpret it differently. > >RFC2253, 2.3 says, > >"If the AttributeType is in a published table of attribute types associated >with LDAP [4], ...". > >I take that to mean the table is the entire reference [4], namely RFC2252. I believe the reference is intended to provide a description of an "attribute type associated with LDAP". >Thus the names for all attributes defined in RFC2252 can be used. The names of all attribute types defined in RFC2252 are: createTimeStamp, modifyTimeStamp, creatorsName, modifiersName, subschemaSubentry, objectClasses, matchingRules, matchingRuleUse, namingContexts, altServer, supportedExtension, supportedControl, supportedSASLMechanisms, supportedLDAPVersion, ldapSyntaxes, nameForms, ditStructureRules, and ditContentRules. None of these attribute types are commonly used for naming. The intersection with the 2.3 published table is null. One could argue that the 2252 reference is meant to imply that all attribute types of "section 5 of [12] (RFC2256)" are also in the table. As a direct reference was not made in RFC2252 to RFC2256, I do not believe can possibly be the case. But anyways, this argument would cause the following attributes to be included in the table: objectclass, aliasedObjectName, knowledgeInformation, cn, sn, serialNumber, c, l, st, street, o, ou, title, description, searchGuide, businessCategory, postalAddress, postalCode, postOfficeBox, physicalDeliveryOfficeName, telephoneNumber, telexNumber, telexTerminalIdentifier, facismileTelephoneNumber, x121address, internationaliSDNNumber, registeredAddress, destinationIndicator, preferredDeliveryMethod, presentationAddress, supportedApplicationContext, member, owner, roleOccupant, seeAlso, userPassword, userCertificate, cACertificate, authorityRevocationList, certificateRevocationList, crossCertificatePair, name, givenName, initials, generationQualifier, x500UniqueIdentifier, dnQualifier, enhancedSearchGuide, protocolInformation, distinguishedName, uniqueMember, houseIdentifier, supportedAlgorithms, deltaRevocationList, dmdName. Note that the intersection with the table in 2.3 doesn't include the complete set of attributes listed in the 2.3 table. So even this argument is weak. >The table in section 2.3 is introduced as, > "As an example, strings for a few of the attribute types frequently seen in >RDNs include:" > >The table is clearly identified as an example, not as an exhaustive list of >all allowed attribute names. Are you saying that the exhaustive list is all the attribute types names listed above? From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 13:36:32 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10154 for ; Fri, 22 Dec 2000 13:36:31 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMIZxG75057; Fri, 22 Dec 2000 18:35:59 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 18:35:58 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMIZtd75048; Fri, 22 Dec 2000 18:35:56 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO94557 (AUTH rmoats); Fri, 22 Dec 2000 13:36:17 -0500 (EST) From: "Ryan Moats" To: "Kurt D. Zeilenga" , "Salter, Thomas A" Cc: Subject: RE: DN "a published table" clarification Date: Fri, 22 Dec 2000 12:36:58 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.0.0.25.0.20001222080033.00ab0c80@router.boolean.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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 will repeat my assertion that "whatever" the final table becomes, if there isn't an escape clause to allow other attribute types to be specified as the RDN (and thus a example of two independent implementations that allow that), the whole concept is DOA because you are taking away functionality from folks who are using directories as well as hamstringing other working groups. I mention this because folks seem to be concentrating on the table only. Ryan -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga Sent: Friday, December 22, 2000 12:03 PM To: Salter, Thomas A Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: DN "a published table" clarification At 09:24 AM 12/22/00 -0500, Salter, Thomas A wrote: >Well, I interpret it differently. > >RFC2253, 2.3 says, > >"If the AttributeType is in a published table of attribute types associated >with LDAP [4], ...". > >I take that to mean the table is the entire reference [4], namely RFC2252. I believe the reference is intended to provide a description of an "attribute type associated with LDAP". >Thus the names for all attributes defined in RFC2252 can be used. The names of all attribute types defined in RFC2252 are: createTimeStamp, modifyTimeStamp, creatorsName, modifiersName, subschemaSubentry, objectClasses, matchingRules, matchingRuleUse, namingContexts, altServer, supportedExtension, supportedControl, supportedSASLMechanisms, supportedLDAPVersion, ldapSyntaxes, nameForms, ditStructureRules, and ditContentRules. None of these attribute types are commonly used for naming. The intersection with the 2.3 published table is null. One could argue that the 2252 reference is meant to imply that all attribute types of "section 5 of [12] (RFC2256)" are also in the table. As a direct reference was not made in RFC2252 to RFC2256, I do not believe can possibly be the case. But anyways, this argument would cause the following attributes to be included in the table: objectclass, aliasedObjectName, knowledgeInformation, cn, sn, serialNumber, c, l, st, street, o, ou, title, description, searchGuide, businessCategory, postalAddress, postalCode, postOfficeBox, physicalDeliveryOfficeName, telephoneNumber, telexNumber, telexTerminalIdentifier, facismileTelephoneNumber, x121address, internationaliSDNNumber, registeredAddress, destinationIndicator, preferredDeliveryMethod, presentationAddress, supportedApplicationContext, member, owner, roleOccupant, seeAlso, userPassword, userCertificate, cACertificate, authorityRevocationList, certificateRevocationList, crossCertificatePair, name, givenName, initials, generationQualifier, x500UniqueIdentifier, dnQualifier, enhancedSearchGuide, protocolInformation, distinguishedName, uniqueMember, houseIdentifier, supportedAlgorithms, deltaRevocationList, dmdName. Note that the intersection with the table in 2.3 doesn't include the complete set of attributes listed in the 2.3 table. So even this argument is weak. >The table in section 2.3 is introduced as, > "As an example, strings for a few of the attribute types frequently seen in >RDNs include:" > >The table is clearly identified as an example, not as an exhaustive list of >all allowed attribute names. Are you saying that the exhaustive list is all the attribute types names listed above? From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 14:07:31 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10911 for ; Fri, 22 Dec 2000 14:07:29 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMJ6lg75364; Fri, 22 Dec 2000 19:06:47 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 19:06:47 +0000 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMJ6hd75356; Fri, 22 Dec 2000 19:06:43 GMT Received: from us-ea-gtwy-7.ea.unisys.com (us-ea-gtwy-7.ea.unisys.com [192.61.145.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id TAA21425; Fri, 22 Dec 2000 19:05:53 GMT Received: by us-ea-gtwy-7.ea.unisys.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 13:06:41 -0600 Message-ID: From: "Salter, Thomas A" To: "Kurt D. Zeilenga" , Ryan Moats Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: DN "a published table" clarification Date: Fri, 22 Dec 2000 13:07:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I agree that the attributes in 2252 are uninteresting as naming attributes. I think the exhaustive list should be any attribute (or perhaps any attribute with DirectoryString syntax) defined in the schema. What is the rationale behind limiting naming attributes to such a very small list? (Back in v2, the names in this table didn't even match attribute names. The v3 definition sorted out issues like "cn" and "commonName" both identifying the same attribute.) From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 15:05:17 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12460 for ; Fri, 22 Dec 2000 15:05:16 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMK4gL76878; Fri, 22 Dec 2000 20:04:42 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 20:04:42 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMK4fd76868 for ; Fri, 22 Dec 2000 20:04:41 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id UAA53431; Fri, 22 Dec 2000 20:04:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001222115142.00a3a960@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 22 Dec 2000 12:04:31 -0800 To: "Salter, Thomas A" From: "Kurt D. Zeilenga" Subject: RE: DN "a published table" clarification Cc: Ryan Moats , 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 01:07 PM 12/22/00 -0600, Salter, Thomas A wrote: >I agree that the attributes in 2252 are uninteresting as naming attributes. > >I think the exhaustive list should be any attribute (or perhaps any >attribute with DirectoryString syntax) defined in the schema. Which schema? DN generation should not require schema discovery as schema discovery requires DN generation. >What is the rationale behind limiting naming attributes to such a very small list? To provide an unambiguous string representation of a distinguished name which can be encoded and decoded with ease. >(Back in v2, the names in this table didn't even match attribute names. Yes, they were keywords. In v3, one can also view the attribute type name strings provided in the table as being independent of the attribute type short names provided in schema. Where as the schema can be extended such that commonName is recognized not only be the short name "cn" but other names (such as "commonName" and "cname"), but RFC2253 requires that the name "CN" be used for this attribute type in the DN representation. >The >v3 definition sorted out issues like "cn" and "commonName" both identifying >the same attribute.) No. The v3 DN spec says you must use "CN" for commonName. From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 15:34:30 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13899 for ; Fri, 22 Dec 2000 15:34:28 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMKXsU77706; Fri, 22 Dec 2000 20:33:54 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 20:33:54 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMKXrd77699 for ; Fri, 22 Dec 2000 20:33:53 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id UAA53525; Fri, 22 Dec 2000 20:33:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001222111918.00a3beb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 22 Dec 2000 12:33:48 -0800 To: "Ryan Moats" From: "Kurt D. Zeilenga" Subject: RE: DN "a published table" clarification Cc: "Salter, Thomas A" , In-Reply-To: References: <5.0.0.25.0.20001222080033.00ab0c80@router.boolean.net> 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:36 PM 12/22/00 -0600, Ryan Moats wrote: >I will repeat my assertion that "whatever" the final table becomes, >if there isn't an escape clause to allow other attribute types >to be specified as the RDN (and thus a example of two independent >implementations that allow that), the whole concept is DOA because >you are taking away functionality from folks who are using directories >as well as hamstringing other working groups. I will repeat my assertion any DN specification which does not provide an unambiguous string representation of a distinguished name which can be encoded and decoded with ease is DOA. RFC 2253 and RFC 1779 place significant restrictions upon their use of attribute type name strings because attribute type name strings are, by their very nature, ambiguous. Both of these specifications rely on exhaustive published tables to ensure the use of attribute type names does not result in an unambiguous DN representation. This approach is widely believed to be sound. There may be other approaches which are technically better. If there is a better approach for providing unambiguous string presentations, I would suggest that someone provide a description of the approach. In particular, the description should state how provide for unambiguous use of attribute types names. Kurt Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 15:41:16 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14158 for ; Fri, 22 Dec 2000 15:41:15 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMKelj77842; Fri, 22 Dec 2000 20:40:47 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 20:40:47 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMKeid77833; Fri, 22 Dec 2000 20:40:45 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO94984 (AUTH rmoats); Fri, 22 Dec 2000 15:41:08 -0500 (EST) From: "Ryan Moats" To: "Kurt D. Zeilenga" Cc: "Salter, Thomas A" , Subject: RE: DN "a published table" clarification Date: Fri, 22 Dec 2000 14:41:49 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.0.0.25.0.20001222111918.00a3beb0@router.boolean.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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 Hmm let's try a different tack... Can't I define naming rules in the schema? [I'll leave off the question of interoperable implementations of this until later] Once I define a naming rule haven't I extended the list of naming attribute types for my particular implementation? Or are you going to take this approach away as well under because it involves "schema discovery"? Your point is well taken, but any DS document that is useless to the non-white-pages world is a BAD THING, and the current table list is definitely skewed to the white-pages world. Since LDAP and directories are being used in more than just the white-pages world, we should wake up to that fact. Ryan -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga Sent: Friday, December 22, 2000 2:34 PM To: Ryan Moats Cc: Salter, Thomas A; ietf-ldapbis@OpenLDAP.org Subject: RE: DN "a published table" clarification At 12:36 PM 12/22/00 -0600, Ryan Moats wrote: >I will repeat my assertion that "whatever" the final table becomes, >if there isn't an escape clause to allow other attribute types >to be specified as the RDN (and thus a example of two independent >implementations that allow that), the whole concept is DOA because >you are taking away functionality from folks who are using directories >as well as hamstringing other working groups. I will repeat my assertion any DN specification which does not provide an unambiguous string representation of a distinguished name which can be encoded and decoded with ease is DOA. RFC 2253 and RFC 1779 place significant restrictions upon their use of attribute type name strings because attribute type name strings are, by their very nature, ambiguous. Both of these specifications rely on exhaustive published tables to ensure the use of attribute type names does not result in an unambiguous DN representation. This approach is widely believed to be sound. There may be other approaches which are technically better. If there is a better approach for providing unambiguous string presentations, I would suggest that someone provide a description of the approach. In particular, the description should state how provide for unambiguous use of attribute types names. Kurt Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Dec 22 16:13:18 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14607 for ; Fri, 22 Dec 2000 16:13:18 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBMLCl678538; Fri, 22 Dec 2000 21:12:47 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Dec 2000 21:12:47 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBMLCkd78531 for ; Fri, 22 Dec 2000 21:12:46 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id VAA53632 for ; Fri, 22 Dec 2000 21:12:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001222124254.00a56370@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 22 Dec 2000 13:12:44 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: DN "a published table" clarification (a solution?) In-Reply-To: <5.0.0.25.0.20001222111918.00a3beb0@router.boolean.net> References: <5.0.0.25.0.20001222080033.00ab0c80@router.boolean.net> 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: One approach might be to add to the end of 2.3. Note: A closed deployments of LDAP [1] MAY prescribe an alternative table of attribute type name strings to be used a local string representation of the distinguished names. This specifications do not ensure the interoperability of local string representations nor that a particular local string unambiguously represents a distinguished name nor does this specification detail security considerations related to the use of alternative tables. The use of alternative tables is NOT RECOMMENDED. Note that I offer this without any opinion (yet) as to its appropriateness for inclusion in the I-D. From owner-ietf-ldapbis@OpenLDAP.org Sat Dec 23 13:03:31 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05800 for ; Sat, 23 Dec 2000 13:03:30 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBNI2Pg91653; Sat, 23 Dec 2000 18:02:25 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Sat, 23 Dec 2000 18:02:25 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBNI2Nd91646 for ; Sat, 23 Dec 2000 18:02:23 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id SAA57742; Sat, 23 Dec 2000 18:02:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001222222508.00a91950@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 23 Dec 2000 10:02:18 -0800 To: "Ryan Moats" From: "Kurt D. Zeilenga" Subject: RE: DN "a published table" clarification Cc: "Salter, Thomas A" , In-Reply-To: References: <5.0.0.25.0.20001222111918.00a3beb0@router.boolean.net> 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:41 PM 12/22/00 -0600, Ryan Moats wrote: >Can't I define naming rules in the schema? You may. >Once I define a naming rule haven't I extended the list >of naming attribute types for my particular >implementation? Yes. Note that the DN specification fully supports use of arbitrary naming attributes. The question is not which attributes may or may not be used in naming, but how attributes which are used in naming are to represented in the string >Or are you going to take this >approach away as well under because it >involves "schema discovery"? I am not sure I understand the approach... but if it relies upon schema discovery or other information held in a directory, it sounds like it has a catch-22 problem. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sat Dec 23 14:30:29 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06187 for ; Sat, 23 Dec 2000 14:30:28 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBNJTc492075; Sat, 23 Dec 2000 19:29:38 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Sat, 23 Dec 2000 19:29:38 +0000 Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBNJTbd92068 for ; Sat, 23 Dec 2000 19:29:37 GMT Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id TAA57879 for ; Sat, 23 Dec 2000 19:29:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001221111514.021adeb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 23 Dec 2000 11:29:34 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: LDAPbis Acknowledgement Policy 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: To ensure WG documents appropriately and consistently give credit to WG document editors and authors, prior work document editors and authors, and individuals providing other significant contributions to WG documents, an acknowledge policy should be adopted. The following policy statement is offered by this co-chair: Each WG I-D shall list in the header the name and organization of the document editor and author(s) of the WG (revision) document. An author is an individual who has made a direct major contribution to the WG (revision) document. The document editor and author(s) of prior work(s) shall be credited in an Acknowledgement section. Other significant contributors to the (revision) document may be credited in the Acknowledgement section. Such credit should be in a separate paragraph from prior work(s) acknowledgements. A request from a named individual to be credited in the Acknowledgement section instead of the header or not to be credited shall be honored. This statement is based upon past LDAP revision/update acknowledge practices and is believed to be consistent with IETF policy and tradition. The WG chairs plan to make a decision on an acknowledgement policy within the next few weeks and solicits WG comments on this action. Please send your comments to this list or to the WG chairs by 10 January 2001. Kurt, LDAPbis WG co-chair From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 26 10:58:41 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19874 for ; Tue, 26 Dec 2000 10:58:40 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBQFvVt22511; Tue, 26 Dec 2000 15:57:31 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Dec 2000 15:57:31 +0000 Received: from mail.coreon.net (IDENT:mirapoint@[216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBQFvTd22504 for ; Tue, 26 Dec 2000 15:57:30 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO96634 (AUTH rmoats); Tue, 26 Dec 2000 10:56:39 -0500 (EST) From: "Ryan Moats" To: Subject: RE: DN "a published table" clarification (a solution?) Date: Tue, 26 Dec 2000 09:57:51 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <5.0.0.25.0.20001222124254.00a56370@router.boolean.net> Sender: 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 works for me. Of course, it follows that interoperability needs to be verified. Ryan -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga Sent: Friday, December 22, 2000 3:13 PM To: ietf-ldapbis@OpenLDAP.org Subject: RE: DN "a published table" clarification (a solution?) One approach might be to add to the end of 2.3. Note: A closed deployments of LDAP [1] MAY prescribe an alternative table of attribute type name strings to be used a local string representation of the distinguished names. This specifications do not ensure the interoperability of local string representations nor that a particular local string unambiguously represents a distinguished name nor does this specification detail security considerations related to the use of alternative tables. The use of alternative tables is NOT RECOMMENDED. Note that I offer this without any opinion (yet) as to its appropriateness for inclusion in the I-D. From owner-ietf-ldapbis@OpenLDAP.org Tue Dec 26 11:00:13 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19893 for ; Tue, 26 Dec 2000 11:00:10 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBQFxe822544; Tue, 26 Dec 2000 15:59:40 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Dec 2000 15:59:40 +0000 Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBQFxdd22537 for ; Tue, 26 Dec 2000 15:59:39 GMT Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118]) by mail.coreon.net (Mirapoint) with ESMTP id AAO96643 (AUTH rmoats); Tue, 26 Dec 2000 10:59:33 -0500 (EST) From: "Ryan Moats" To: "Salter, Thomas A" , Subject: RE: DN "a published table" clarification Date: Tue, 26 Dec 2000 10:00:45 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <5.0.0.25.0.20001222222508.00a91950@router.boolean.net> Sender: 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 One of my points in here is how will LDAPv3 in its DS form deal with the whole naming rule, stucture rule and content rule stuff. If we keep them in the DS specs (with implementation records) then I think I have my escape clause as well. As to my others, I seem to not have them in my head anymore, but that' probably due to the cold that has taken up residence. Ryan -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Subject: RE: DN "a published table" clarification At 02:41 PM 12/22/00 -0600, Ryan Moats wrote: >Can't I define naming rules in the schema? You may. >Once I define a naming rule haven't I extended the list >of naming attribute types for my particular >implementation? Yes. Note that the DN specification fully supports use of arbitrary naming attributes. The question is not which attributes may or may not be used in naming, but how attributes which are used in naming are to represented in the string >Or are you going to take this >approach away as well under because it >involves "schema discovery"? I am not sure I understand the approach... but if it relies upon schema discovery or other information held in a directory, it sounds like it has a catch-22 problem. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 27 07:11:52 2000 Received: from galois.openldap.org (root@[204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16288 for ; Wed, 27 Dec 2000 07:11:52 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBRCBAZ40908; Wed, 27 Dec 2000 12:11:10 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 27 Dec 2000 12:11:10 +0000 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBRCB5d40900; Wed, 27 Dec 2000 12:11:05 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA284514; Wed, 27 Dec 2000 07:09:55 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id HAA115684; Wed, 27 Dec 2000 07:08:24 -0500 Importance: Normal To: "Kurt D. Zeilenga" Cc: "Ryan Moats" , "Salter, Thomas A" , Subject: RE: DN "a published table" clarification X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 From: "Timothy Hahn" Message-ID: Date: Wed, 27 Dec 2000 07:10:41 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V506_11152000.dev01 |November 27, 2000) at 12/27/2000 07:10:44 AM, Serialize complete at 12/27/2000 07:10:44 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004235A4852569C2_=" Sender: 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 multipart message in MIME format. --=_alternative 004235A4852569C2_= Content-Type: text/plain; charset="us-ascii" Kurt, > There may be other approaches which are technically better. > If there is a better approach for providing unambiguous > string presentations, I would suggest that someone provide > a description of the approach. In particular, the description > should state how provide for unambiguous use of attribute types > names. You probably won't care for this idea, but I will put it here anyway just in case :-) You have asserted in the past that any approach that relies upon schema discovery has a "catch-22" problem. I don't quite understand this - as long as the names of the namingContext values and subschemasubentry(ies) values are built from attributes of a more limited set, why couldn't we use a root DSE search to locate namingContext values, then a base search to locate the subschemasubentry value, then, with the schema discovered, be able to handle attribute in DNs that are defined by the schema? >One approach might be to add to the end of 2.3. > > Note: A closed deployments of LDAP [1] MAY prescribe an > alternative table of attribute type name strings > to be used a local string representation of the > distinguished names. This specifications do not > ensure the interoperability of local string > representations nor that a particular local string > unambiguously represents a distinguished name nor > does this specification detail security considerations > related to the use of alternative tables. > The use of alternative tables is NOT RECOMMENDED. > >Note that I offer this without any opinion (yet) as to >its appropriateness for inclusion in the I-D. If no other alternatives can be agreed to, I am comfortable with the statement above bein added to the draft. At least there will be some way to allow other attribute type names to be used in DN strings. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 Sent by: owner-ietf-ldapbis@OpenLDAP.org To: "Ryan Moats" cc: "Salter, Thomas A" , Subject: RE: DN "a published table" clarification At 12:36 PM 12/22/00 -0600, Ryan Moats wrote: >I will repeat my assertion that "whatever" the final table becomes, >if there isn't an escape clause to allow other attribute types >to be specified as the RDN (and thus a example of two independent >implementations that allow that), the whole concept is DOA because >you are taking away functionality from folks who are using directories >as well as hamstringing other working groups. I will repeat my assertion any DN specification which does not provide an unambiguous string representation of a distinguished name which can be encoded and decoded with ease is DOA. RFC 2253 and RFC 1779 place significant restrictions upon their use of attribute type name strings because attribute type name strings are, by their very nature, ambiguous. Both of these specifications rely on exhaustive published tables to ensure the use of attribute type names does not result in an unambiguous DN representation. This approach is widely believed to be sound. There may be other approaches which are technically better. If there is a better approach for providing unambiguous string presentations, I would suggest that someone provide a description of the approach. In particular, the description should state how provide for unambiguous use of attribute types names. Kurt Kurt --=_alternative 004235A4852569C2_= Content-Type: text/html; charset="us-ascii"
Kurt,

> There may be other approaches which are technically better.
> If there is a better approach for providing unambiguous
> string presentations, I would suggest that someone provide
> a description of the approach.  In particular, the description
> should state how provide for unambiguous use of attribute types
> names.
You probably won't care for this idea, but I will put it here anyway just in case :-)

You have asserted in the past that any approach that relies upon schema discovery has a "catch-22" problem.  I don't quite understand this - as long as the names of the namingContext values and subschemasubentry(ies) values are built from attributes of a more limited set, why couldn't we use a root DSE search to locate namingContext values, then a base search to locate the subschemasubentry value, then, with the schema discovered, be able to handle attribute in DNs that are defined by the schema?

>One approach might be to add to the end of 2.3.
>
>  Note: A closed deployments of LDAP [1] MAY prescribe an
>    alternative table of attribute type name strings
>    to be used a local string representation of the
>    distinguished names.  This specifications do not
>    ensure the interoperability of local string
>    representations nor that a particular local string
>    unambiguously represents a distinguished name nor
>    does this specification detail security considerations
>    related to the use of alternative tables.
>    The use of alternative tables is NOT RECOMMENDED.
>
>Note that I offer this without any opinion (yet) as to
>its appropriateness for inclusion in the I-D.
If no other alternatives can be agreed to, I am comfortable with the statement above bein added to the draft.  At least there will be some way to allow other attribute type names to be used in DN strings.

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        owner-ietf-ldapbis@OpenLDAP.org

To:        "Ryan Moats" <rmoats@coreon.net>
cc:        "Salter, Thomas A" <Thomas.Salter@unisys.com>, <ietf-ldapbis@OpenLDAP.org>
Subject:        RE: DN "a published table" clarification



At 12:36 PM 12/22/00 -0600, Ryan Moats wrote:
>I will repeat my assertion that "whatever" the final table becomes,
>if there isn't an escape clause to allow other attribute types
>to be specified as the RDN (and thus a example of two independent
>implementations that allow that), the whole concept is DOA because
>you are taking away functionality from folks who are using directories
>as well as hamstringing other working groups.
I will repeat my assertion any DN specification which does not
provide an unambiguous string representation of a distinguished
name which can be encoded and decoded with ease is DOA.
RFC 2253 and RFC 1779 place significant restrictions upon their
use of attribute type name strings because attribute type name
strings are, by their very nature, ambiguous.  Both of these
specifications rely on exhaustive published tables to ensure
the use of attribute type names does not result in an
unambiguous DN representation.  This approach is widely
believed to be sound.
There may be other approaches which are technically better.
If there is a better approach for providing unambiguous
string presentations, I would suggest that someone provide
a description of the approach.  In particular, the description
should state how provide for unambiguous use of attribute types
names.
Kurt
Kurt


--=_alternative 004235A4852569C2_=-- From owner-ietf-ldapbis@OpenLDAP.org Wed Dec 27 15:34:11 2000 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23893 for ; Wed, 27 Dec 2000 15:34:08 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id eBRKWpA53292; Wed, 27 Dec 2000 20:32:52 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 27 Dec 2000 20:32:51 +0000 Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id eBRKWld53284; Wed, 27 Dec 2000 20:32:47 GMT Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA10054; Wed, 27 Dec 2000 15:32:11 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA02375; Wed, 27 Dec 2000 15:32:09 -0500 (EST) Received: from dhcp-145-229.mitre.org (128.29.145.229) by mailhub2.mitre.org with SMTP id 5366135; Wed, 27 Dec 2000 15:32:06 -0500 Message-ID: <3A4A56D1.1C1E5C2C@mitre.org> Date: Wed, 27 Dec 2000 15:53:37 -0500 From: Kathy Dally Organization: The MITRE Corporation X-Mailer: Mozilla 4.73 [en]C-20000509M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ryan Moats CC: "Kurt D. Zeilenga" , Stig Venaas , ietf-ldapbis@OpenLDAP.org Subject: Re: matching for facsimileTelephoneNumber References: 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! The bottom line is that the definition of the facsimileTelephoneNumber attribute can not be changed. IMHO, specification of a facsimileTelephoneNumber matching rule and including it in the attribute specification would change the attribute. Therefore, there should be no impact on LDAPv3BIS. Also, IMHO, a facsimileTelephoneNumber matching rule, which would not be formally cited by the attribute definition, would be difficult to implement because the syntax is complex (SEQ). So, I do not support this as a new task for LDAPEXT. Kathy Dally Ryan Moats wrote: > > ?!?! I agree with what you said, but the request was to > specify a matching rule for facsimileTelephoneNumber. > This is not currently done by X.520 so I claim the > matching rule is NOT part of the "core" spec and so is > out of scope. If we are going to start specifying > matching rules for things in X.520 that don't have them > I claim we've strayed into new functionality. > > I think we are in agreement about the approriateness > of this suggestion, but for different reasons. > > Ryan > > -----Original Message----- > From: owner-ietf-ldapbis@OpenLDAP.org > [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga > Sent: Thursday, December 21, 2000 1:41 PM > To: Ryan Moats > Cc: Stig Venaas; ietf-ldapbis@OpenLDAP.org > Subject: RE: matching for facsimileTelephoneNumber > > At 09:05 AM 12/21/00 -0600, Ryan Moats wrote: > >IMHO... If it isn't in X.520, then its a topic for LDAPEXT. > >(ietf-ldapext@netscape.com). No new functionality in LDAPBIS. > > I note, per our charter, that all schema items which are not > required and/or described by the LDAPv3 "core" technical > specification are not within scope of the LDAPbis WG. > > facsimileTelephoneNumber is described by the LDAPv3 "core" > technical specification, so it is within scope. However, > the proposed change, IMO, would be inappropriate as it > would create, not resolve, interoperability problems. > > Kurt