Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA7MtSur011898 for ; Thu, 7 Nov 2002 23:55:28 +0100 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA7MtGgM004117; Thu, 7 Nov 2002 14:55:16 -0800 (PST) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.0-GA) with SMTP id ABF44834; Thu, 7 Nov 2002 14:55:41 -0800 (PST) From: "Andrea Westerinen" To: "Durham, David" , "'David T. Perkins'" , Subject: RE: [nmrg] Binary vs Text Date: Thu, 7 Nov 2002 14:55:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Check out DSML - http://www.oasis-open.org/committees/dsml/. Most directories said that they would support it. Andrea -----Original Message----- From: nmrg-admin@ibr.cs.tu-bs.de [mailto:nmrg-admin@ibr.cs.tu-bs.de]On Behalf Of Durham, David Sent: Wednesday, November 06, 2002 11:41 AM To: 'David T. Perkins'; nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] Binary vs Text I am not aware of any such mappings for the protocol. Although, the directory can simply be used to store XML docs in its attributes. Also, LDAP unlike X.500, only uses string encodings for all attribute data. No other directly binary types are available. It would be really nice if LDAP provided something more like XML Schema instead of its own home-brewed schema definitions. Hummm, (LDAP using BER)->((LDAP using XML)+XMLSchema)... I wonder, then, what would differentiate a directory service from an XML DOM. -Dave > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Wednesday, November 06, 2002 11:12 AM > To: nmrg@ibr.cs.tu-bs.de > Subject: [nmrg] Binary vs Text > > > HI, > > I was recently reminded that LDAP uses BER encoding of ASN.1. > Have there > been pushes to "convert" LDAP messages to text encoding (ie XML)? > (Or has this already happened, and I miss it?) > > Regards, > /david t. perkins > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust > !! your settings, send a mail message to > > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > -- !! This message is brought to you via the `nmrg' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA7Ki6us005287 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 7 Nov 2002 21:44:06 +0100 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gA7Ki5t3017904 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 7 Nov 2002 21:44:06 +0100 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gA7Ki5wb017901; Thu, 7 Nov 2002 21:44:05 +0100 From: Frank Strauss To: Phil Shafer Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Notification filtering and logging References: <200211072029.gA7KTjJX042517@idle.juniper.net> Date: 07 Nov 2002 21:44:05 +0100 In-Reply-To: <200211072029.gA7KTjJX042517@idle.juniper.net> Message-ID: Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi! >> When we look at management data as XML guys, I think we should prefer >> XPath for filtering. Phil> XPath is good technology, but implementing it on the box will Phil> be expensive, both in terms of the technology itself and the Phil> mapping between the underlaying commands and the data requirements Phil> for the XPath expression. While it's attractive to think of Phil> the device as a huge dynamic datastore, it's very costly and Phil> brings its own inefficiencies. >> GET /context[@name="router.nowhere.com" and @port="161" and >> @community="public"]/IF-MIB/ifEntry[ifOperStatus='up' and >> ((ifInErrors * 10000 > ifInOctets) or >> (ifOutErrors * 10000 > ifOutOctets))]/ifDescr Phil> For complex queries like this, I'd prefer to get the data off the Phil> device and post-process it using xslt/xpath/etc. Agreed. A student at our institute just started working on an SNMP/XML gateway that will hopefully support such XPath expressions. One approach would be what you suggest, but I have some hope that we will also be able to interpret the requests (partly) so that we can reduce the Agent/Gateway SNMP traffic to some degree. -frank Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA7KT0us004775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Nov 2002 21:29:01 +0100 Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA7KSsS43207; Thu, 7 Nov 2002 12:28:54 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id gA7KTjJX042517; Thu, 7 Nov 2002 20:29:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200211072029.gA7KTjJX042517@idle.juniper.net> To: Frank Strauss cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Notification filtering and logging In-Reply-To: Your message of "07 Nov 2002 21:19:51 +0100." Date: Thu, 07 Nov 2002 15:29:45 -0500 From: Phil Shafer X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Frank Strauss writes: >When we look at management data as XML guys, I think we should prefer >XPath for filtering. XPath is good technology, but implementing it on the box will be expensive, both in terms of the technology itself and the mapping between the underlaying commands and the data requirements for the XPath expression. While it's attractive to think of the device as a huge dynamic datastore, it's very costly and brings its own inefficiencies. > GET /context[@name="router.nowhere.com" and @port="161" and > @community="public"]/IF-MIB/ifEntry[ifOperStatus='up' and > ((ifInErrors * 10000 > ifInOctets) or > (ifOutErrors * 10000 > ifOutOctets))]/ifDescr For complex queries like this, I'd prefer to get the data off the device and post-process it using xslt/xpath/etc. Thanks, Phil Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA7KJpus004356 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 7 Nov 2002 21:19:51 +0100 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gA7KJpt3017425 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 7 Nov 2002 21:19:51 +0100 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gA7KJpC7017422; Thu, 7 Nov 2002 21:19:51 +0100 From: Frank Strauss To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Notification filtering and logging References: <200211071024.gA7AOYEC032268@hansa.ibr.cs.tu-bs.de> Date: 07 Nov 2002 21:19:51 +0100 In-Reply-To: <200211071024.gA7AOYEC032268@hansa.ibr.cs.tu-bs.de> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi! David> One of the appealing aspects of XML-based management is that it David> is text-based, and, thus, reg-exs can be used for selection. When we look at management data as XML guys, I think we should prefer XPath for filtering. (I don't know enough about XQuery, maybe it's an additional worthwhile approach.) XPath is able to evaluate elements, attributes and text nodes as strings and numbers, e.g. GET /context[@name="router.nowhere.com" and @port="161" and @community="public"]/IF-MIB/ifEntry[ifOperStatus='up' and ((ifInErrors * 10000 > ifInOctets) or (ifOutErrors * 10000 > ifOutOctets))]/ifDescr (Yes, we cannot handle wrapping counters appropriately this way, and there are certainly further problems that cannot be addressed easily.) -frank Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA7AOZus005996 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 7 Nov 2002 11:24:35 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gA7AOYt3032271 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 7 Nov 2002 11:24:34 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gA7AOYEC032268; Thu, 7 Nov 2002 11:24:34 +0100 Date: Thu, 7 Nov 2002 11:24:34 +0100 Message-Id: <200211071024.gA7AOYEC032268@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dperkins@dsperkins.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <5.1.1.6.2.20021106105558.035f2a00@127.0.0.1> (dperkins@dsperkins.com) Subject: Re: [nmrg] Notification filtering and logging References: <5.1.1.6.2.20021106105558.035f2a00@127.0.0.1> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> David T Perkins writes: David> One of the appealing aspects of XML-based management is that it David> is text-based, and, thus, reg-exs can be used for selection. The SMI and SNMP basically distinguished between numbers, OIDs and (binary) strings. Regular expression matches make sense for strings, but not really for numbers (common relational operators usually just work fine on numbers). So from this perspective, there is really no need to convert numbers into strings in order to do better filtering. (And even typical databases query languages do not do this for a good reasons.) I think the real problem with SNMP is the OID naming system which requires some code to unpack instance identifier in order to do matches on them. The packing of strings and numbers into instance identifier is really kind of ugly if you look at it from an outsider perspective. David> (For me, one of the features that significantly drove up the David> cost of CMIP was support for filtering paired with defining new David> data types. Each time a new data type was created, one had to David> define the comparison operators. And to support the objects David> with the new data types, one had to both add new David> parsing/encoding functions and add comparison functions. This David> complicated the "packaging" and complexity of management David> toolkits, and bloat, and we all know the result.) As you wrote, it is not the filtering (CMIP filter expressions have a fixed and probably well-defined set of operators) which is the cost factor, but the fact that you could add arbitrary differently encoded data types which makes it costly. SNMP is much better in this respect. /js -- Juergen Schoenwaelder Received: from phoebe.eim.surrey.ac.uk (IDENT:exim@phoebe.eim.surrey.ac.uk [131.227.74.4]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA6Jn6ig000845 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 6 Nov 2002 20:49:07 +0100 Received: from athena.ee.surrey.ac.uk ([131.227.88.19] ident=exim) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 189WAR-00003O-00; Wed, 06 Nov 2002 19:48:48 +0000 Received: from ees2gp (helo=eim.surrey.ac.uk) by athena.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 189WAP-000182-00; Wed, 6 Nov 2002 19:48:45 +0000 To: "David T. Perkins" cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Notification filtering and logging In-Reply-To: Message from "David T. Perkins" of "Wed, 06 Nov 2002 11:10:10 PST." <5.1.1.6.2.20021106105558.035f2a00@127.0.0.1> Date: Wed, 06 Nov 2002 19:48:45 +0000 From: George Pavlou Message-Id: X-Spam-Level: X-Scanner: exiscan *189WAR-00003O-00*.6bzywx7ky2* (SECM, UniS) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: David, > A next-generation replacement > for SNMP should address this issue. Also, it seems desirable to me that > the selection mechanism should be applicable to retrieval requests. If a filtering mechanism for events is there, it could easily be used to also eliminate object selection in retrievals. And I also agree that the next generation Internet management should provide this capability. > One of the appealing aspects of XML-based management is that it is > text-based, and, thus, reg-exs can be used for selection. True, but arguably not with the flexibility and power one gets with boolean predicates. > (For me, one of the features that significantly drove up the cost of CMIP > was support for filtering paired with defining new data types. Each > time a new data type was created, one had to define the comparison > operators. And to support the objects with the new data types, one > had to both add new parsing/encoding functions and add comparison > functions. This complicated the "packaging" and complexity of > management toolkits, and bloat, and we all know the result.) Having implemented CMIS/P filtering in the past, I can tell you that comparison methods are provided once for fundamental types and used thereafter. For most composite types, the only possible comparison is equality and this was produced by our O-O ASN.1 compiler. I admit that other possible comparisons had to be hand-coded, but that was rare (and we implemented many type-rich MIBs). I don't think that the reasons for the failure include complexity of the facilities provided by the protocol/agent. A selection of SNMP object subtrees + filtering of some kind (the latter also applying to events) should be high in the list of desirable features for next generation SNMP. But unfortunately these are not the only fixes needed... Regards, -George *********************************************************************** * Prof. George Pavlou Tel: +44 1483 689480 * * Fax: +44 1483 686011 * * Centre for Communication Systems Research * * School of Electronics, Computing and Mathematics * * University of Surrey * * Guildford, Surrey GU2 7XH, U.K. * * * * e-mail: G.Pavlou@eim.surrey.ac.uk * * WWW: http://www.ee.surrey.ac.uk/CCSR/Networks/ * * http://www.ee.surrey.ac.uk/Personal/G.Pavlou/ * * * *********************************************************************** Received: from momus.sc.intel.com (momus.sc.intel.com [143.183.152.8]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA6Jg6if000505 for ; Wed, 6 Nov 2002 20:42:07 +0100 Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id gA6JfcI22986 for ; Wed, 6 Nov 2002 19:41:48 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110611414823846 ; Wed, 06 Nov 2002 11:41:48 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 11:41:27 -0800 Message-ID: From: "Durham, David" To: "'David T. Perkins'" , nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] Binary vs Text Date: Wed, 6 Nov 2002 11:41:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I am not aware of any such mappings for the protocol. Although, the directory can simply be used to store XML docs in its attributes. Also, LDAP unlike X.500, only uses string encodings for all attribute data. No other directly binary types are available. It would be really nice if LDAP provided something more like XML Schema instead of its own home-brewed schema definitions. Hummm, (LDAP using BER)->((LDAP using XML)+XMLSchema)... I wonder, then, what would differentiate a directory service from an XML DOM. -Dave > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Wednesday, November 06, 2002 11:12 AM > To: nmrg@ibr.cs.tu-bs.de > Subject: [nmrg] Binary vs Text > > > HI, > > I was recently reminded that LDAP uses BER encoding of ASN.1. > Have there > been pushes to "convert" LDAP messages to text encoding (ie XML)? > (Or has this already happened, and I miss it?) > > Regards, > /david t. perkins > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust > !! your settings, send a mail message to > > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA6JEnif031662 for ; Wed, 6 Nov 2002 20:14:50 +0100 Received: from host.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id LAA66874 for ; Wed, 6 Nov 2002 11:14:47 -0800 (PST) (envelope-from dperkins@dsperkins.com) Message-Id: <5.1.1.6.2.20021106105558.035f2a00@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 06 Nov 2002 11:10:10 -0800 To: nmrg@ibr.cs.tu-bs.de From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] Notification filtering and logging Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: HI, The filtering(selection) and logging of notifications seems to be a common requirement in many management protocols. I am seeing work such as the following http://www.ietf.org/internet-drafts/draft-moran-sipping-filter-reqs-00.txt coming from many areas within the IETF. A next-generation replacement for SNMP should address this issue. Also, it seems desirable to me that the selection mechanism should be applicable to retrieval requests. One of the appealing aspects of XML-based management is that it is text-based, and, thus, reg-exs can be used for selection. (For me, one of the features that significantly drove up the cost of CMIP was support for filtering paired with defining new data types. Each time a new data type was created, one had to define the comparison operators. And to support the objects with the new data types, one had to both add new parsing/encoding functions and add comparison functions. This complicated the "packaging" and complexity of management toolkits, and bloat, and we all know the result.) So, any reactions? Regards, /david t. perkins Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gA6JEnif031663 for ; Wed, 6 Nov 2002 20:14:50 +0100 Received: from host.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id LAA66882 for ; Wed, 6 Nov 2002 11:14:48 -0800 (PST) (envelope-from dperkins@dsperkins.com) Message-Id: <5.1.1.6.2.20021106111012.0356f940@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 06 Nov 2002 11:11:59 -0800 To: nmrg@ibr.cs.tu-bs.de From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] Binary vs Text Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: HI, I was recently reminded that LDAP uses BER encoding of ASN.1. Have there been pushes to "convert" LDAP messages to text encoding (ie XML)? (Or has this already happened, and I miss it?) Regards, /david t. perkins