From ldapext-admin@ietf.org Tue Apr 1 09:23:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12891 for ; Tue, 1 Apr 2003 09:23:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31EhIK14517; Tue, 1 Apr 2003 09:43:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31EgGK14059 for ; Tue, 1 Apr 2003 09:42:16 -0500 Received: from goose.ehsco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12577 for ; Tue, 1 Apr 2003 09:17:57 -0500 (EST) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0) with ESMTP-TLS id 200257 for ldapext@ietf.org; Tue, 01 Apr 2003 08:19:30 -0600 Message-ID: <3E89A026.90503@ehsco.com> Date: Tue, 01 Apr 2003 08:20:22 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: ldapext@ietf.org Content-Type: multipart/mixed; boundary="------------000808040602090208070606" Subject: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-audit-00.txt] Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------000808040602090208070606 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'd like to get some feedback on this idea. Background -- I'm working on an application where WHOIS data will be stored and exchanged over LDAP. Some registration bodies already store some auditing information in their private databases, and I'd like to provide a common mechanism for this kind of data. However, it seems that this kind of data/usage has broader applicability, and rather than define it exclusively for use with this application, it seems that it would be better for the community to define it for general-use. This draft was assembled in a hurry, so I'm sure there are some basic errors with it. Otherwise, would this be useful as a common schema, and are there any significant architectural concerns? or should I go back and specify it for use with this application in particular? Thanks ps--I'm aware of the changelog work that's going on, but that work deals with data-stores as a whole, and does not readily allow for auditing the changes made to specific entries. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ --------------000808040602090208070606 Content-Type: message/rfc822; name="I-D ACTION:draft-hall-ldap-audit-00.txt" Content-Disposition: attachment; filename="I-D ACTION:draft-hall-ldap-audit-00.txt" Return-Path: Received: from ran.ietf.org ([132.151.6.60] verified) by goose.ehsco.com (CommuniGate Pro SMTP 4.0) with ESMTP id 200232 for lists@ehsco.com; Tue, 01 Apr 2003 06:20:18 -0600 Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 190Kd2-00061m-00 for ietf-announce-list@ran.ietf.org; Tue, 01 Apr 2003 07:12:36 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 190KWJ-0005lz-00 for all-ietf@ran.ietf.org; Tue, 01 Apr 2003 07:05:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04814 for ; Tue, 1 Apr 2003 06:49:05 -0500 (EST) Message-Id: <200304011149.GAA04814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hall-ldap-audit-00.txt Date: Tue, 01 Apr 2003 06:49:05 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The generalizedAudit object class and the generalizedAuditEvent attribute Author(s) : E. Hall Filename : draft-hall-ldap-audit-00.txt Pages : 0 Date : 2003-3-31 This document defines an LDAP auxiliary object class and a single attribute, which together can be used to store and track the entities who may have accessed or modified a specific entry in an LDAP directory information tree. For example, an LDAP application may need to store information which can indicate when an entry was created, when it was accessed, who modified it, and other kinds of similar information, with this information acting as a general- purpose auditing log for that entry. The object class and attributes defined herein are designed for that purpose in particular, and are not intended to serve as detailed auditing information capable of withstanding court-of-law scrutiny, nor are they designed to be used for journaling-playback purposes. They are simply to be used for storing general information about the changes which have been made to a specific entry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hall-ldap-audit-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hall-ldap-audit-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-hall-ldap-audit-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-31124513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hall-ldap-audit-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hall-ldap-audit-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-31124513.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------000808040602090208070606-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From mailman-admin@ietf.org Tue Apr 1 10:04:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16392 for ; Tue, 1 Apr 2003 10:04:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FRwK29415 for ; Tue, 1 Apr 2003 10:27:58 -0500 Date: Tue, 01 Apr 2003 10:27:58 -0500 Message-ID: <20030401152758.29326.83593.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ldapext-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ldapext-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ldapext-archive@lists.ietf.org: List Password // URL ---- -------- ldapext@ietf.org LxAC https://www1.ietf.org/mailman/options/ldapext/ldapext-archive%40lists.ietf.org From ldapext-admin@ietf.org Wed Apr 2 17:35:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12543 for ; Wed, 2 Apr 2003 17:35:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MwvK27104; Wed, 2 Apr 2003 17:58:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MtNK26977 for ; Wed, 2 Apr 2003 17:55:23 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12427 for ; Wed, 2 Apr 2003 17:30:26 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 02 Apr 2003 15:32:53 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 02 Apr 2003 15:32:17 -0700 From: "Jim Sermersheim" To: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I believe this data type needs to be re-defined in the LDAPBis work, and I believe there needs to be a more formal way of extending it with "special" values. Currently (in both RFC 2251, and LDAPBis work), this data type does not allow the string "*" (or the proposed "+" for that matter). Both specifications restrict it to a list of attribute descriptions. An attribute description must either be a numeric oid, or begin with a alpha. Yet both have "special wording" like: "There are two special values which may be used: an empty list with no attributes, and the attribute description string "*". Both of these signify that all user attributes are to be returned. (The "*" allows the client to request all user attributes in addition to any specified operational attributes).". Another proposal furthers this and allows "+" to indicate that all operational attributes are to be returned, and other proposals for other special strings are in the works. To start with, I think the current restriction needs to be lifted in the ldapbis work. The easiest thing to do here is to redefine SearchRequest.attributes as SEQUENCE OF OCTET STRING. It would be a little better to define it as a type that has an associated restriction described in ABNF, where the restriction is like, but less than the current attributedescription restriction. Furthermore, I forsee other "special strings" being introduced, and believe that we'll run out of handy things like * + # $ % etc (beside's they become less and less intuitive). I suggest we come up with some generalized standard extensibility mechanism for this. Something like putting special strings inside parens would work, and would allow the tradition of setting "x-" prefixed strings aside as experimental. Here's my suggested ABNF for a single search attribute (refer to http://ietf.org/internet-drafts/draft-ietf-ldapbis-models-07.txt for elements not defined here): searchattribute = descr / numericoid / %x2A / specialsearchattr specialsearchattr = LPAREN WSP (standardspecialsearchattr / experimentalspecialsearchattr) WSP RPAREN standardspecialsearchattr = 1*(%x21-28 / %x2A-7E) experimental = X HYPHEN standardspecialsearchattr Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 3 14:11:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07556 for ; Thu, 3 Apr 2003 14:11:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33J9HK18210; Thu, 3 Apr 2003 14:09:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33J8GK18123 for ; Thu, 3 Apr 2003 14:08:16 -0500 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07325 for ; Thu, 3 Apr 2003 14:05:22 -0500 (EST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h33J7nn25786 for ; Thu, 3 Apr 2003 11:07:49 -0800 (PST) Received: from netscape.com ([10.169.192.46]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCS7T100.S3I; Thu, 3 Apr 2003 11:07:49 -0800 Message-ID: <3E8C8684.9060903@netscape.com> Date: Thu, 03 Apr 2003 14:07:48 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: Jim Sermersheim CC: ldapext@ietf.org, ietf-ldapbis@openldap.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > I believe this data type needs to be re-defined in the LDAPBis work, and > I believe there needs to be a more formal way of extending it with > "special" values. > > Currently (in both RFC 2251, and LDAPBis work), this data type does not > allow the string "*" (or the proposed "+" for that matter). Both > specifications restrict it to a list of attribute descriptions. An > attribute description must either be a numeric oid, or begin with a > alpha. Yet both have "special wording" like: "There are two special > values which may be used: an empty list with no attributes, and the > attribute description string "*". Both of these signify that all user > attributes are to be returned. (The "*" allows the client to request all > user attributes in addition to any specified operational attributes).". > Another proposal furthers this and allows "+" to indicate that all > operational attributes are to be returned, and other proposals for other > special strings are in the works. Can you provide some examples? I am generally in favor of allowing for extensions in many areas, but I am not convinced we need to allow it in this specific area. -Mark _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 3 19:05:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20856 for ; Thu, 3 Apr 2003 19:05:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3406hK13011; Thu, 3 Apr 2003 19:06:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3405VK12922 for ; Thu, 3 Apr 2003 19:05:31 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20818 for ; Thu, 3 Apr 2003 19:02:31 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Apr 2003 17:04:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 03 Apr 2003 17:03:55 -0700 From: "Jim Sermersheim" To: Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, here are some examples of special attributes: Attribute Meaning "*" All User Attrs (P-S RFC) "+" All Operational Attrs (S-T I-D) "+" All Attributes of an object class (I-T I-D) "*;lang-" All User Attrs with lang-xx (no spec yet on remaining) "@" All Attrs listed at uri "*MCSN>" All User Attrs who's mod CSN is greater than that specified "*Len<" All User Attr val's less than len octets "^" No virtual attributes "^^" No collective attributes "$" Only static (no dynamically calculated) attributes ":-(" Attributes with deleted/unpurged values "+dirOp" All directoryOperation operational "+distOp" All distributedOperation operational "+dsaOp" All dsaOperation operational "#" All attributes belonging to specified syntax Obviously, there are many (inconsistent) ways to express these, and there are no guidelines or instructions to those who want to create new special attributes but don't want to collide with special attributes being defined by other people. Jim >>> Mark C Smith 4/3/03 12:07:48 PM >>> Jim Sermersheim wrote: > I believe this data type needs to be re-defined in the LDAPBis work, and > I believe there needs to be a more formal way of extending it with > "special" values. > > Currently (in both RFC 2251, and LDAPBis work), this data type does not > allow the string "*" (or the proposed "+" for that matter). Both > specifications restrict it to a list of attribute descriptions. An > attribute description must either be a numeric oid, or begin with a > alpha. Yet both have "special wording" like: "There are two special > values which may be used: an empty list with no attributes, and the > attribute description string "*". Both of these signify that all user > attributes are to be returned. (The "*" allows the client to request all > user attributes in addition to any specified operational attributes).". > Another proposal furthers this and allows "+" to indicate that all > operational attributes are to be returned, and other proposals for other > special strings are in the works. Can you provide some examples? I am generally in favor of allowing for extensions in many areas, but I am not convinced we need to allow it in this specific area. -Mark _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 00:50:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26709 for ; Fri, 4 Apr 2003 00:50:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345pfK03101; Fri, 4 Apr 2003 00:51:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345nBK02963 for ; Fri, 4 Apr 2003 00:49:11 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26626 for ; Fri, 4 Apr 2003 00:46:02 -0500 (EST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h345mVBT063352; Fri, 4 Apr 2003 05:48:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030403205848.02251550@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 03 Apr 2003 21:46:28 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] Re: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 02:32 PM 4/2/2003, Jim Sermersheim wrote: >To start with, I think the current restriction needs to be lifted in >the ldapbis work. The easiest thing to do here is to redefine >SearchRequest.attributes as SEQUENCE OF OCTET STRING. We need to be careful here. That said, another possibility would be to change it to: SEQUENCE OF AttributeDescriptionOrSpecial AttributeDescriptionOrSpecial ::= LDAPString where the LDAPString is contains a value conforming to the production: attributeDescriptionOrSpecial = attributeDescription / specials specials = "*" and a statement: The specials production may be updated by standard track technical specifications updating this document to allow additional specials. Servers MUST treat specials they do not recognize as unrecognized attribute types. This leaves the exact form of a future specials up to future standard track technical specifications. If one wanted to allow non-standard track specification of specials, then one could write a standard track specification defining a family of specials that have disambiguated by an IANA registry of specials. I rather leave this to others (e.g., not LDAPBIS). Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 03:41:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11378 for ; Fri, 4 Apr 2003 03:41:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348hQK25546; Fri, 4 Apr 2003 03:43:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348g8K25507 for ; Fri, 4 Apr 2003 03:42:08 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11338 for ; Fri, 4 Apr 2003 03:38:57 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h348fN913356; Fri, 4 Apr 2003 10:41:23 +0200 (MEST) Received: from pappel.asw.mchp.siemens.de ([139.25.160.30]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h348fNJ03847; Fri, 4 Apr 2003 10:41:23 +0200 (MEST) Received: by pappel.asw.mchp.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 10:41:20 +0200 Message-ID: From: "Volpers, Helmut" To: "'Jim Sermersheim'" , mcs@netscape.com Cc: ldapext@ietf.org, ietf-ldapbis@openldap.org Date: Fri, 4 Apr 2003 10:41:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ldapext] RE: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Hi, I am a little bit confused about the examples of the special attributes. I have no problem if your server supports this special attributes, but I hope your client will not send it to my server. How will your client decide whether this attributes can be used (Vendors Name ?). I don't think its a topic for LDAPbis ?! Helmut > -----Original Message----- > From: Jim Sermersheim [mailto:jimse@novell.com] > Sent: Freitag, 4. April 2003 02:04 > To: mcs@netscape.com > Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org > Subject: Re: Extensibility of SearchRequest.attributes > > > Yes, here are some examples of special attributes: > > Attribute Meaning > "*" All User Attrs (P-S RFC) > "+" All Operational Attrs (S-T I-D) > "+" All Attributes of an object class (I-T I-D) > "*;lang-" All User Attrs with lang-xx (no spec yet on > remaining) > "@" All Attrs listed at uri > "*MCSN>" All User Attrs who's mod CSN is greater than that > specified > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values > "+dirOp" All directoryOperation operational > "+distOp" All distributedOperation operational > "+dsaOp" All dsaOperation operational > "#" All attributes belonging to specified syntax > > Obviously, there are many (inconsistent) ways to express these, and > there are no guidelines or instructions to those who want to > create new > special attributes but don't want to collide with special attributes > being defined by other people. > > Jim > > >>> Mark C Smith 4/3/03 12:07:48 PM >>> > Jim Sermersheim wrote: > > I believe this data type needs to be re-defined in the LDAPBis work, > and > > I believe there needs to be a more formal way of extending it with > > "special" values. > > > > Currently (in both RFC 2251, and LDAPBis work), this data type does > not > > allow the string "*" (or the proposed "+" for that matter). Both > > specifications restrict it to a list of attribute descriptions. An > > attribute description must either be a numeric oid, or begin with a > > alpha. Yet both have "special wording" like: "There are two special > > values which may be used: an empty list with no attributes, and the > > attribute description string "*". Both of these signify that all > user > > attributes are to be returned. (The "*" allows the client to request > all > > user attributes in addition to any specified operational > attributes).". > > Another proposal furthers this and allows "+" to indicate that all > > operational attributes are to be returned, and other proposals for > other > > special strings are in the works. > > Can you provide some examples? I am generally in favor of allowing for > > extensions in many areas, but I am not convinced we need to > allow it in > > this specific area. > > -Mark > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 03:57:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11574 for ; Fri, 4 Apr 2003 03:57:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348xIK26203; Fri, 4 Apr 2003 03:59:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348vlK26087 for ; Fri, 4 Apr 2003 03:57:47 -0500 Received: from nb2.stroeder.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11506 for ; Fri, 4 Apr 2003 03:54:30 -0500 (EST) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 17CB96B10B; Fri, 4 Apr 2003 10:56:57 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 353D26B0E3; Fri, 4 Apr 2003 10:56:56 +0200 (CEST) Message-ID: <3E8D48D8.4080807@stroeder.com> Date: Fri, 04 Apr 2003 10:56:56 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Volpers, Helmut" Cc: "'Jim Sermersheim'" , mcs@netscape.com, ldapext@ietf.org, ietf-ldapbis@openldap.org Subject: Re: [ldapext] RE: Extensibility of SearchRequest.attributes References: In-Reply-To: X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Volpers, Helmut wrote: > > I am a little bit confused about the examples of the special attributes. > > I have no problem if your server supports this special attributes, but > I hope your client will not send it to my server. I hope your server won't crash when receiving these special attributes in a search request. ;-) > How will your client decide whether this attributes can be used (Vendors > Name ?). A client can look at attribute 'supportedFeatures' in RootDSE. My client is checking for 1.3.6.1.4.1.4203.1.5.1 (defined in draft-zeilenga-ldap-opattrs) and then sends '+'. Ciao, Michael. >>-----Original Message----- >>From: Jim Sermersheim [mailto:jimse@novell.com] >>Sent: Freitag, 4. April 2003 02:04 >>To: mcs@netscape.com >>Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org >>Subject: Re: Extensibility of SearchRequest.attributes >> >> >>Yes, here are some examples of special attributes: >> >>Attribute Meaning >>"*" All User Attrs (P-S RFC) >>"+" All Operational Attrs (S-T I-D) >>"+" All Attributes of an object class (I-T I-D) >>"*;lang-" All User Attrs with lang-xx (no spec yet on >>remaining) >>"@" All Attrs listed at uri >>"*MCSN>" All User Attrs who's mod CSN is greater than that >>specified >>"*Len<" All User Attr val's less than len octets >>"^" No virtual attributes >>"^^" No collective attributes >>"$" Only static (no dynamically calculated) attributes >>":-(" Attributes with deleted/unpurged values >>"+dirOp" All directoryOperation operational >>"+distOp" All distributedOperation operational >>"+dsaOp" All dsaOperation operational >>"#" All attributes belonging to specified syntax >> >>Obviously, there are many (inconsistent) ways to express these, and >>there are no guidelines or instructions to those who want to >>create new >>special attributes but don't want to collide with special attributes >>being defined by other people. >> >>Jim >> >> >>>>>Mark C Smith 4/3/03 12:07:48 PM >>> >> >>Jim Sermersheim wrote: >> >>>I believe this data type needs to be re-defined in the LDAPBis work, >> >>and >> >>>I believe there needs to be a more formal way of extending it with >>>"special" values. >>> >>>Currently (in both RFC 2251, and LDAPBis work), this data type does >> >>not >> >>>allow the string "*" (or the proposed "+" for that matter). Both >>>specifications restrict it to a list of attribute descriptions. An >>>attribute description must either be a numeric oid, or begin with a >>>alpha. Yet both have "special wording" like: "There are two special >>>values which may be used: an empty list with no attributes, and the >>>attribute description string "*". Both of these signify that all >> >>user >> >>>attributes are to be returned. (The "*" allows the client to request >> >>all >> >>>user attributes in addition to any specified operational >> >>attributes).". >> >>>Another proposal furthers this and allows "+" to indicate that all >>>operational attributes are to be returned, and other proposals for >> >>other >> >>>special strings are in the works. >> >>Can you provide some examples? I am generally in favor of allowing for >> >>extensions in many areas, but I am not convinced we need to >>allow it in >> >>this specific area. >> >>-Mark _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 10:12:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25523 for ; Fri, 4 Apr 2003 10:12:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34FFHK23457; Fri, 4 Apr 2003 10:15:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34FEYK23423 for ; Fri, 4 Apr 2003 10:14:34 -0500 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25359 for ; Fri, 4 Apr 2003 10:11:15 -0500 (EST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h34FDfE08218 for ; Fri, 4 Apr 2003 07:13:41 -0800 (PST) Received: from netscape.com ([10.169.192.53]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCTRMV03.34K; Fri, 4 Apr 2003 07:13:43 -0800 Message-ID: <3E8DA125.3060702@netscape.com> Date: Fri, 04 Apr 2003 10:13:41 -0500 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jim Sermersheim , ldapext@ietf.org, ietf-ldapbis@openldap.org References: <5.2.0.9.0.20030403205848.02251550@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030403205848.02251550@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 10:23:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26104 for ; Fri, 4 Apr 2003 10:23:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34FQ8K23962; Fri, 4 Apr 2003 10:26:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34FPTK23947 for ; Fri, 4 Apr 2003 10:25:30 -0500 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26081 for ; Fri, 4 Apr 2003 10:22:10 -0500 (EST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h34FObE09293 for ; Fri, 4 Apr 2003 07:24:38 -0800 (PST) Received: from netscape.com ([10.169.192.53]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCTS5301.L4Z; Fri, 4 Apr 2003 07:24:39 -0800 Message-ID: <3E8DA3B5.80208@netscape.com> Date: Fri, 04 Apr 2003 10:24:37 -0500 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ldapext@ietf.org, ietf-ldapbis@openldap.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit OK; thanks for the list. I hope I never have to implement support for all of these in a server (not that each one is very difficult; this is just a long list). A side note: it makes sense to me to express concepts like "all" in an AttributeDescriptionList, but I think it makes more sense to use a control to modify how the entire list is processed. So I would use a control to express these concepts from your list of examples: > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values The "*Len<" one is included because I might want to say "return values for attributes a, b, c whose length is less than 1000 octets" or "return all operational attributes whose length is less than 512 octets." Controls have other nice properties: collisions can't happen (due to use of OIDs), handling of unknown controls is well defined, etc. -Mark Smith Netscape Jim Sermersheim wrote: > Yes, here are some examples of special attributes: > > Attribute Meaning > "*" All User Attrs (P-S RFC) > "+" All Operational Attrs (S-T I-D) > "+" All Attributes of an object class (I-T I-D) > "*;lang-" All User Attrs with lang-xx (no spec yet on > remaining) > "@" All Attrs listed at uri > "*MCSN>" All User Attrs who's mod CSN is greater than that > specified > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values > "+dirOp" All directoryOperation operational > "+distOp" All distributedOperation operational > "+dsaOp" All dsaOperation operational > "#" All attributes belonging to specified syntax > > Obviously, there are many (inconsistent) ways to express these, and > there are no guidelines or instructions to those who want to create new > special attributes but don't want to collide with special attributes > being defined by other people. > > Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 12:09:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29485 for ; Fri, 4 Apr 2003 12:09:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HCP832679; Fri, 4 Apr 2003 12:12:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HB0832488 for ; Fri, 4 Apr 2003 12:11:00 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29407 for ; Fri, 4 Apr 2003 12:07:38 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 04 Apr 2003 10:10:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 04 Apr 2003 10:09:30 -0700 From: "Jim Sermersheim" To: , Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] RE: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ldapbis has everything to do with interoperability. The fact that you hope no client sends one of these strings to your server, and the fact that there are currently no instructions on what should happen if one does means that thisis a topic for ldapbis. ldapbis needs to tell servers that it's ok, for unknown strings (which are invalid attribute names) to be sent, and for servers to ignore those unknown strings. Jim >>> "Volpers, Helmut" 4/4/03 1:41:15 AM >>> Hi, I am a little bit confused about the examples of the special attributes. I have no problem if your server supports this special attributes, but I hope your client will not send it to my server. How will your client decide whether this attributes can be used (Vendors Name ?). I don't think its a topic for LDAPbis ?! Helmut > -----Original Message----- > From: Jim Sermersheim [mailto:jimse@novell.com] > Sent: Freitag, 4. April 2003 02:04 > To: mcs@netscape.com > Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org > Subject: Re: Extensibility of SearchRequest.attributes > > > Yes, here are some examples of special attributes: > > Attribute Meaning > "*" All User Attrs (P-S RFC) > "+" All Operational Attrs (S-T I-D) > "+" All Attributes of an object class (I-T I-D) > "*;lang-" All User Attrs with lang-xx (no spec yet on > remaining) > "@" All Attrs listed at uri > "*MCSN>" All User Attrs who's mod CSN is greater than that > specified > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values > "+dirOp" All directoryOperation operational > "+distOp" All distributedOperation operational > "+dsaOp" All dsaOperation operational > "#" All attributes belonging to specified syntax > > Obviously, there are many (inconsistent) ways to express these, and > there are no guidelines or instructions to those who want to > create new > special attributes but don't want to collide with special attributes > being defined by other people. > > Jim > > >>> Mark C Smith 4/3/03 12:07:48 PM >>> > Jim Sermersheim wrote: > > I believe this data type needs to be re-defined in the LDAPBis work, > and > > I believe there needs to be a more formal way of extending it with > > "special" values. > > > > Currently (in both RFC 2251, and LDAPBis work), this data type does > not > > allow the string "*" (or the proposed "+" for that matter). Both > > specifications restrict it to a list of attribute descriptions. An > > attribute description must either be a numeric oid, or begin with a > > alpha. Yet both have "special wording" like: "There are two special > > values which may be used: an empty list with no attributes, and the > > attribute description string "*". Both of these signify that all > user > > attributes are to be returned. (The "*" allows the client to request > all > > user attributes in addition to any specified operational > attributes).". > > Another proposal furthers this and allows "+" to indicate that all > > operational attributes are to be returned, and other proposals for > other > > special strings are in the works. > > Can you provide some examples? I am generally in favor of allowing for > > extensions in many areas, but I am not convinced we need to > allow it in > > this specific area. > > -Mark > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 12:13:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29652 for ; Fri, 4 Apr 2003 12:13:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HG3800516; Fri, 4 Apr 2003 12:16:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HFB800385 for ; Fri, 4 Apr 2003 12:15:11 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29562 for ; Fri, 4 Apr 2003 12:11:49 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 04 Apr 2003 10:14:19 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 04 Apr 2003 10:13:37 -0700 From: "Jim Sermersheim" To: Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yeah, I just popped these off the top of my head--some are more reasonable than others. I'm not sure that I plan to implement any or all of them. The nice thing about not defining a control is that clients don't have to be re-compiled. >>> Mark C Smith 4/4/03 8:24:37 AM >>> OK; thanks for the list. I hope I never have to implement support for all of these in a server (not that each one is very difficult; this is just a long list). A side note: it makes sense to me to express concepts like "all" in an AttributeDescriptionList, but I think it makes more sense to use a control to modify how the entire list is processed. So I would use a control to express these concepts from your list of examples: > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values The "*Len<" one is included because I might want to say "return values for attributes a, b, c whose length is less than 1000 octets" or "return all operational attributes whose length is less than 512 octets." Controls have other nice properties: collisions can't happen (due to use of OIDs), handling of unknown controls is well defined, etc. -Mark Smith Netscape Jim Sermersheim wrote: > Yes, here are some examples of special attributes: > > Attribute Meaning > "*" All User Attrs (P-S RFC) > "+" All Operational Attrs (S-T I-D) > "+" All Attributes of an object class (I-T I-D) > "*;lang-" All User Attrs with lang-xx (no spec yet on > remaining) > "@" All Attrs listed at uri > "*MCSN>" All User Attrs who's mod CSN is greater than that > specified > "*Len<" All User Attr val's less than len octets > "^" No virtual attributes > "^^" No collective attributes > "$" Only static (no dynamically calculated) attributes > ":-(" Attributes with deleted/unpurged values > "+dirOp" All directoryOperation operational > "+distOp" All distributedOperation operational > "+dsaOp" All dsaOperation operational > "#" All attributes belonging to specified syntax > > Obviously, there are many (inconsistent) ways to express these, and > there are no guidelines or instructions to those who want to create new > special attributes but don't want to collide with special attributes > being defined by other people. > > Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 12:37:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00545 for ; Fri, 4 Apr 2003 12:37:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34He3802712; Fri, 4 Apr 2003 12:40:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Hbs802569 for ; Fri, 4 Apr 2003 12:37:54 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00450 for ; Fri, 4 Apr 2003 12:34:31 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 04 Apr 2003 10:37:02 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 04 Apr 2003 10:36:33 -0700 From: "Jim Sermersheim" To: , Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 4 12:42:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00761 for ; Fri, 4 Apr 2003 12:42:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Hj5803016; Fri, 4 Apr 2003 12:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Hi0802943 for ; Fri, 4 Apr 2003 12:44:00 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00666 for ; Fri, 4 Apr 2003 12:40:38 -0500 (EST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h34Hh7BT067901; Fri, 4 Apr 2003 17:43:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030404093917.02445b40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 04 Apr 2003 09:41:04 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: Extensibility of SearchRequest.attributes Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 09:36 AM 4/4/2003, Jim Sermersheim wrote: >I'm fine with the suggestion Kurt made, though I'm still nervous about >the proliferation of special strings. Requiring that specials be extended by standard track specifications (until someone defines a general specials extension mechanism) will slow proliferation. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Apr 7 10:24:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21875 for ; Mon, 7 Apr 2003 10:24:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37ERc814740; Mon, 7 Apr 2003 10:27:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h371Tf817193 for ; Sun, 6 Apr 2003 21:29:41 -0400 Received: from ausyms50.ca.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11185 for ; Sun, 6 Apr 2003 21:25:09 -0400 (EDT) content-class: urn:content-classes:message Date: Mon, 7 Apr 2003 11:27:49 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Extensibility of SearchRequest.attributes Thread-Index: AcL60nDyGOWL+tqdSgK01srLMIoKqQB0YQ/g From: "Ramsay, Ron" To: "Jim Sermersheim" , , Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h371Tf817199 Subject: [ldapext] RE: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Why do you believe special strings can be used. I looked at RFC 2251 and, regarding 'attributes', it says there are two special values. One is no values at all and the other is the string "*". The ASN.1 defines 'attributes' to be of type AttributeDescriptionList, which would seem to disallow arbitrary strings? I think it is weirdness and that, as Mark Smith says, controls should be used to cause special behaviours. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 5 April 2003 03:37 To: mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Apr 7 10:40:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22311 for ; Mon, 7 Apr 2003 10:40:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Ehn816506; Mon, 7 Apr 2003 10:43:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37EfI816415 for ; Mon, 7 Apr 2003 10:41:18 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22257 for ; Mon, 7 Apr 2003 10:36:30 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 07 Apr 2003 08:39:03 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 07 Apr 2003 08:38:08 -0600 From: "Jim Sermersheim" To: , , Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] RE: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, as you point out, in one breath RFC 2251 disallows the "*" string, and in another, it allows it. It is not self consistent. I believe the intent may have been to allow special strings. Furthermore, other Internet-Drafts that describe new special strings have made significant progress with no apparent concern from community members (draft-zeilenga-ldap-opattrs (Proposed Standard, under IESG Evaluation), and draft-zeilenga-ldap-adlist). We either need to allow special strings to be defined, or disallow anything other than "*" and empty, and raise a red flag concerning those two I-D's Jim >>> "Ramsay, Ron" 4/6/03 7:27:49 PM >>> Why do you believe special strings can be used. I looked at RFC 2251 and, regarding 'attributes', it says there are two special values. One is no values at all and the other is the string "*". The ASN.1 defines 'attributes' to be of type AttributeDescriptionList, which would seem to disallow arbitrary strings? I think it is weirdness and that, as Mark Smith says, controls should be used to cause special behaviours. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 5 April 2003 03:37 To: mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Apr 7 21:37:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13515 for ; Mon, 7 Apr 2003 21:37:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h381bA830603; Mon, 7 Apr 2003 21:37:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h381Us830070 for ; Mon, 7 Apr 2003 21:30:54 -0400 Received: from ausyms50.ca.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13298 for ; Mon, 7 Apr 2003 21:25:53 -0400 (EDT) content-class: urn:content-classes:message Date: Tue, 8 Apr 2003 11:28:35 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Extensibility of SearchRequest.attributes Thread-Index: AcL9E3MtCIxIXO+BSS+5QmaWIPZkQAAWQpJg From: "Ramsay, Ron" To: "Jim Sermersheim" , , Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h381Us830071 Subject: [ldapext] RE: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I hadn't realised that "+" was PS and that it had passed last call. However, as "*" only returns normal attributes, and as operational attributes have to be named to be returned, perhaps there is a case for "+". X.500 has a framework for this - a comparable facility in LDAP would have been another item, say "op-attributes" after the item "attributes". But that is water under the bridge. I'd like to see the nonsense stop at "+". A control could serve for the other uses, you just need an I-D to define an OID and some strings (or integers?) Extended-EIS:Control= OID:Name=x.y.z Boolean:Criticality ANY:Value=@Table Table=(table of values and meanings) Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Tuesday, 8 April 2003 00:38 To: Ramsay, Ron; mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: RE: Extensibility of SearchRequest.attributes Well, as you point out, in one breath RFC 2251 disallows the "*" string, and in another, it allows it. It is not self consistent. I believe the intent may have been to allow special strings. Furthermore, other Internet-Drafts that describe new special strings have made significant progress with no apparent concern from community members (draft-zeilenga-ldap-opattrs (Proposed Standard, under IESG Evaluation), and draft-zeilenga-ldap-adlist). We either need to allow special strings to be defined, or disallow anything other than "*" and empty, and raise a red flag concerning those two I-D's Jim >>> "Ramsay, Ron" 4/6/03 7:27:49 PM >>> Why do you believe special strings can be used. I looked at RFC 2251 and, regarding 'attributes', it says there are two special values. One is no values at all and the other is the string "*". The ASN.1 defines 'attributes' to be of type AttributeDescriptionList, which would seem to disallow arbitrary strings? I think it is weirdness and that, as Mark Smith says, controls should be used to cause special behaviours. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 5 April 2003 03:37 To: mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Apr 8 02:00:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18299 for ; Tue, 8 Apr 2003 02:00:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3864B814320; Tue, 8 Apr 2003 02:04:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3860N813507 for ; Tue, 8 Apr 2003 02:00:23 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18067 for ; Tue, 8 Apr 2003 01:55:18 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 07 Apr 2003 23:57:50 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 07 Apr 2003 23:57:00 -0600 From: "Jim Sermersheim" To: , , Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] RE: Extensibility of SearchRequest.attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ron, you're absolutely right about the control thing. There is nothing that can be done with a special string that can't be done with a control. Special strings have the advantage that oftentimes existing applications can just use them without being re-compiled. I do not think we can allow "+", and disallow others. How would such a thing be worded in 2251bis without "extending"? Oh, I know. It can say that all attrDescriptions are allowed, as well as the "*" string, and also any future extensions, so long as they only use the "+" string. ha ha ha. Consensus seems murky on this topic. Does anyone else out there have further input? Jim >>> "Ramsay, Ron" 4/7/03 7:28:35 PM >>> I hadn't realised that "+" was PS and that it had passed last call. However, as "*" only returns normal attributes, and as operational attributes have to be named to be returned, perhaps there is a case for "+". X.500 has a framework for this - a comparable facility in LDAP would have been another item, say "op-attributes" after the item "attributes". But that is water under the bridge. I'd like to see the nonsense stop at "+". A control could serve for the other uses, you just need an I-D to define an OID and some strings (or integers?) Extended-EIS:Control= OID:Name=x.y.z Boolean:Criticality ANY:Value=@Table Table=(table of values and meanings) Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Tuesday, 8 April 2003 00:38 To: Ramsay, Ron; mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: RE: Extensibility of SearchRequest.attributes Well, as you point out, in one breath RFC 2251 disallows the "*" string, and in another, it allows it. It is not self consistent. I believe the intent may have been to allow special strings. Furthermore, other Internet-Drafts that describe new special strings have made significant progress with no apparent concern from community members (draft-zeilenga-ldap-opattrs (Proposed Standard, under IESG Evaluation), and draft-zeilenga-ldap-adlist). We either need to allow special strings to be defined, or disallow anything other than "*" and empty, and raise a red flag concerning those two I-D's Jim >>> "Ramsay, Ron" 4/6/03 7:27:49 PM >>> Why do you believe special strings can be used. I looked at RFC 2251 and, regarding 'attributes', it says there are two special values. One is no values at all and the other is the string "*". The ASN.1 defines 'attributes' to be of type AttributeDescriptionList, which would seem to disallow arbitrary strings? I think it is weirdness and that, as Mark Smith says, controls should be used to cause special behaviours. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 5 April 2003 03:37 To: mcs@netscape.com; Kurt@OpenLDAP.org Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org Subject: Re: Extensibility of SearchRequest.attributes I think the first thing to do is get consensus on whether new special attributes are allowed. I believe the intent of RFC 2251 is that special strings can be used to request different things in the return attributes, thus it itself allows a *. I further believe that the RFC simply missed the point that it was self-inconsistent in the way it defined the data type for the return attr specification. Thus, I believe it needs to a) fix the inconsistency, b) allow for future special strings, and possibly c) define how future extensions should be defined. I'm fine with the suggestion Kurt made, though I'm still nervous about the proliferation of special strings. I'd really like to see some "x-" mechanism available--but I agree, that can be done outside the scope of ldapbis. Unless there are other opinions, I will assume consensus is that we do (a) and (b) above. Jim >>> Mark C Smith 4/4/03 8:13:41 AM >>> I agree with the approach suggested by Kurt. Creating an extensibility mechanism for AttributeDescriptions is a new LDAP feature and should be out of scope for LDAPBis. But doing a little work in LDAPBis to allow for the possibility makes sense to me. I am a little concerned about leaving the possibilities for "specials" wide open. If we adopt the statement suggested by Kurt, then servers must accept any octet inside an AttributeDescription. Perhaps most implementations already do, but some may not. -Mark Smith Netscape Kurt D. Zeilenga wrote: > > We need to be careful here. > > That said, another possibility would be to change it to: > SEQUENCE OF AttributeDescriptionOrSpecial > AttributeDescriptionOrSpecial ::= LDAPString > > where the LDAPString is contains a value conforming to the production: > attributeDescriptionOrSpecial = attributeDescription / specials > specials = "*" > > and a statement: > The specials production may be updated by standard track > technical specifications updating this document to allow > additional specials. Servers MUST treat specials they do > not recognize as unrecognized attribute types. > > This leaves the exact form of a future specials up to > future standard track technical specifications. > > If one wanted to allow non-standard track specification of > specials, then one could write a standard track specification > defining a family of specials that have disambiguated by > an IANA registry of specials. I rather leave this to others > (e.g., not LDAPBIS). > > Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Apr 8 04:06:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01988 for ; Tue, 8 Apr 2003 04:06:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h388AI801430; Tue, 8 Apr 2003 04:10:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3887K800928 for ; Tue, 8 Apr 2003 04:07:20 -0400 Received: from web41712.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01869 for ; Tue, 8 Apr 2003 04:02:12 -0400 (EDT) Message-ID: <20030408080445.9198.qmail@web41712.mail.yahoo.com> Received: from [193.41.96.45] by web41712.mail.yahoo.com via HTTP; Tue, 08 Apr 2003 01:04:45 PDT Date: Tue, 8 Apr 2003 01:04:45 -0700 (PDT) From: Allan Clarke To: ldapext@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1112316304-1049789085=:8799" Subject: [ldapext] changing ldap time Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --0-1112316304-1049789085=:8799 Content-Type: text/plain; charset=us-ascii Hi Guys, The clocks here in the UK moved an hour forwards two weekends back. I changed the time on the ldap server but the passwordexpirationtime attribute still stores the wrong time. Can you please tell me how to change the time on the ldap server. I am using iPlanet 5. Thanks Allan --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more --0-1112316304-1049789085=:8799 Content-Type: text/html; charset=us-ascii

Hi Guys,

The clocks here in the UK moved an hour forwards two weekends back. I changed the time on the ldap server but the passwordexpirationtime attribute still stores the wrong time. Can you please tell me how to change the time on the ldap server. I am using iPlanet 5.

Thanks

Allan


Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more --0-1112316304-1049789085=:8799-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Apr 8 08:03:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07684 for ; Tue, 8 Apr 2003 08:03:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38C81819251; Tue, 8 Apr 2003 08:08:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38C5Q818394 for ; Tue, 8 Apr 2003 08:05:26 -0400 Received: from e1.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07648 for ; Tue, 8 Apr 2003 08:00:14 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h38C2joa055128; Tue, 8 Apr 2003 08:02:45 -0400 Received: from d27ml001.rchland.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by northrelay01.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h38C2hlI086020; Tue, 8 Apr 2003 08:02:43 -0400 Subject: Re: [ldapext] changing ldap time To: Allan Clarke Cc: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Tue, 8 Apr 2003 07:02:43 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0.1|February 07, 2003) at 04/08/2003 07:02:44 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Allan, This is a mailing list for discussion of draft IETF standards for LDAP. Your question would be better directed to the support channels for your directory vendor. That said, it sounds like your server is working fine. PasswordExpirationTime uses GMT/UTC times. GMT didn't change when you set your clocks ahead, only your local time changed. You just happen to live in a place where local time and GMT are the same for much of the year. John McMeeking Allan Clarke cc: Sent by: Subject: [ldapext] changing ldap time ldapext-admin@ietf .org 04/08/2003 03:04 AM Hi Guys, The clocks here in the UK moved an hour forwards two weekends back. I changed the time on the ldap server but the passwordexpirationtime attribute still stores the wrong time. Can you please tell me how to change the time on the ldap server. I am using iPlanet 5. Thanks Allan Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Apr 8 08:41:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08459 for ; Tue, 8 Apr 2003 08:41:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CkI821518; Tue, 8 Apr 2003 08:46:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Cge821372 for ; Tue, 8 Apr 2003 08:42:40 -0400 Received: from web41701.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08354 for ; Tue, 8 Apr 2003 08:37:27 -0400 (EDT) Message-ID: <20030408123959.52979.qmail@web41701.mail.yahoo.com> Received: from [193.41.96.45] by web41701.mail.yahoo.com via HTTP; Tue, 08 Apr 2003 05:39:59 PDT Date: Tue, 8 Apr 2003 05:39:59 -0700 (PDT) From: Allan Clarke Subject: Re: [ldapext] changing ldap time To: John McMeeking Cc: ldapext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1147784319-1049805599=:51808" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --0-1147784319-1049805599=:51808 Content-Type: text/plain; charset=us-ascii I'm sorry, I do realise this is not the place to post such questions, but to answer your question, I do live in London and the clocks were moved an hour ahead last weekend, and I did check the "automatically adjust clock for daylight saving changes" in the TimeZone tab on the server. But it still saves the wrong time. To give you an example if I edit a user, say change his password, the time now on the server is 13:38 or 20030408133811Z but the modifytimestamp attribute saves it as 12:38 or 20030408123811Z. John McMeeking wrote: Allan, This is a mailing list for discussion of draft IETF standards for LDAP. Your question would be better directed to the support channels for your directory vendor. That said, it sounds like your server is working fine. PasswordExpirationTime uses GMT/UTC times. GMT didn't change when you set your clocks ahead, only your local time changed. You just happen to live in a place where local time and GMT are the same for much of the year. John McMeeking Allan Clarke @yahoo.com> cc: Sent by: Subject: [ldapext] changing ldap time ldapext-admin@ietf .org 04/08/2003 03:04 AM Hi Guys, The clocks here in the UK moved an hour forwards two weekends back. I changed the time on the ldap server but the passwordexpirationtime attribute still stores the wrong time. Can you please tell me how to change the time on the ldap server. I am using iPlanet 5. Thanks Allan Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more --0-1147784319-1049805599=:51808 Content-Type: text/html; charset=us-ascii

I'm sorry, I do realise this is not the place to post such questions, but to answer your question, I do live in London and the clocks were moved an hour ahead last weekend, and I did check the "automatically adjust clock for daylight saving changes" in the TimeZone tab on the server. But it still saves the wrong time. To give you an example if I edit a user, say change his password, the time now on the server is 13:38 or 20030408133811Z  but the modifytimestamp attribute saves it as 12:38 or 20030408123811Z.

 John McMeeking <jmcmeek@us.ibm.com> wrote:





Allan,

This is a mailing list for discussion of draft IETF standards for LDAP.
Your question would be better directed to the support channels for your
directory vendor.

That said, it sounds like your server is working fine.
PasswordExpirationTime uses GMT/UTC times. GMT didn't change when you set
your clocks ahead, only your local time changed. You just happen to live
in a place where local time and GMT are the same for much of the year.


John McMeeking




Allan Clarke
@yahoo.com> cc:
Sent by: Subject: [ldapext] changing ldap time
ldapext-admin@ietf
.org


04/08/2003 03:04
AM






Hi Guys,


The clocks here in the UK moved an hour forwards two weekends back. I
changed the time on the ldap server but the passw! ordexpirationtime
attribute still stores the wrong time. Can you please tell me how to change
the time on the ldap server. I am using iPlanet 5.


Thanks


Allan



Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more






Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more --0-1147784319-1049805599=:51808-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext