Subject: RE: SVRLOC WG IMPORTANT: SLPv2 next step?

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 19 Sep 2000 18:53:53 -0700

Hi Erik and Evan,

I think I support Erik's side of this dispute.

I agree that allowing the infixing of '|' wherever in
LDAP search filters makes them _much_ harder to 
efficiently evaluate.  I'd be willing to just lose
'|' in SLP, because a long string of '&' really is
the typical case when searching for SERVICES.

And I agree that '!' is of dubious value.

If I got this right, Erik, you suggest we keep all
the comparison operators, so we can do approximate
match, substring, and so on right?  If so, then I'm
ready to support removing '|' and '!'.

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Tuesday, September 19, 2000 2:54 AM
To: Evan Hughes
Cc: Erik Guttman; [email-masked]
Subject: Re: SVRLOC WG IMPORTANT: SLPv2 next step?

> On Wed, 30 Aug 2000, Erik Guttman wrote:
> > So are you happy with the slpv2bis-01 draft?
> 
>   No:
> 
> With regards to section 3.1.1:
> 
>   I do not feel that the issues raised regarding the complexity of
> implementing LDAPv3 search filters justifies the simplification of SLP
> search facilities. My reasons follow:
> 
>  * I have implemented the LDAPv3 search filter for OpenSLP (which should
> be included Any Day Now, see
> http://www.nexus.carleton.ca/~hughes/filter.tgz for the implementation),
> and found the task doable. Implementing the logical operators was the
> easiest part, since the code for `&` is almost identical to `|`s. 

That has not been common experience.  If you handle both & and | you
can get arbitrary nesting.  If you only handle & then there is only 
one level of nesting - which can be handled serially (no need for
recursive descent, etc.)

Remember the *CHIEF* resistance to SLP has been the complexity of
supporting LDAP search filters.  If we can make this support dead
simple (ie. handle it in a page or two of code) we will dissolve
over half of our opposition.

>  * In order to implement the `|` or `!` operators, some form of recursion
> on the filter string is necessary. Arbitrarily limiting the filter string
> to contain one `&`, while allowing an unlimited number of `|`s is
> nonsensical, as `&` will become a special case for parsing -- increasing
> complexity. 

! is a real pain since you have to *invert* the results from the previous
filtering.

| really means that you have different search filters you are gluing 
together.  With some reduction in efficiency on the network, these
filters could be sent separately.  We are not searching for fields in
a database - we are searching for services which have required features.
The *common case* is that there is a list of features we need.   It is
*farfetched* to say we need a disjoint set of feature (exclusive or).
Inclusive or can be managed using n separate queries and concatenating
the results.

>  * The removal of any operator limits SLP's applicability. Before causing
> such a dramatic reduction in SLP's potential functionality, it should be
> shown that the `&` operator greatly increases the complexity of filter
> parsing. This has not been done. 

We need to keep '&'!  No one has suggested getting rid of '&'!
 
>  * At some point during the discussion somebody mentioned the relative
> complexity of each of the entities on the network. As far as I recall,
> complexity was a spectrum, with UA/SA's being simple (possibly
> computationally bound), and DAs being complex (possibly with greater
> memory/processor resources). Removing the `&` weakens the role of the DA,
> since any UA that wishes to use multiple `&`s will have to do client side
> attribute checking. This does not follow with the aforementioned
> resource model.

I totally agree.  But we don't need multiple &s.  (&(a=b)(&(c=d)(d=e)))
is logically equivalent to (&(a=b)(c=d)(d=e)) - that is, we can do all
the conjunction we need with only one, initial, '&'.

It is much easier to understand this interface, too.  I have yet to see
a human interface which supports '!' or '|' which is comprehensible.  I
have seen many excellent interfaces which support '&' (a list of conditions,
check boxes, etc.)

> (I feel like I should get a t-shirt saying "Save the &". =)

Send me one!
 
>  Before stating that the LDAPv3 filters make SLP difficult to implement,
> it may be a good idea to find some supportive references. I was able to
> code and then refactor the search filter in less than two weeks. 

It took me longer :-)  In the end, every implementation I have seen has
been pretty complex, especially if the filter handling is to be done 
efficiently.  The goal is to have this be something that will fit on a
single page or two of code - that is what will win the hearts and minds
of the SLPv2 opponents I personally know.

>  Further, I don't see the point of removing the eliding of
> leading/trailing white space. Again, the code of eliding is relatively
> simple, and it avoids pesky white-space errors. 

Please discuss this further on the list, in regard to the WG ACTION:
comments requested for SLPv2bis final list of changes.

> In general:
> 
>  Reducing SLP's functionality will only harm SLP's utilization. As it is,
> SLP has not gained widespread acceptance (OpenSLP is the first opensource
> implementation of SLP. This indicates that few oft-used services use
> SLP). Weakening SLP's functionality condemns the protocol to disuse. 

I have argued that dropping '!' and '|' do not really reduce the
functionality of SLP - at least the core functionality.  I have
further argued that it will *increase* the acceptability of SLP
to drop these features.

Erik

---

From: Ganesan Rajagopal <[email-masked]>
Date: 20 Sep 2000 09:30:46 +0530

>>>>> "McDonald," == McDonald, Ira <[email-masked]> writes:

> I think I support Erik's side of this dispute.

FWIW, I support Evan's side of the discussion. My main interest is backward
compatibility and I admit I have a vested interest, see below.

> I agree that allowing the infixing of '|' wherever in LDAP search filters
> makes them _much_ harder to efficiently evaluate.  I'd be willing to just
> lose '|' in SLP, because a long string of '&' really is the typical case
> when searching for SERVICES.

Suppose, I want a laser printer or a bubble jet printer (i.e. not a dot
matrix, or thermal or whatever). Now Erik's point is that I could first
lookup a laser printer, and then lookup a bubble jet printer if I can't find
one. This is indeed a valid point. However, if there is no DA in the network
the service lookup time doubles because of the multicast convergence
algorithm. 

> And I agree that '!' is of dubious value.

In fact current Novell clients are already using a '|' in their query for
looking up services to avoid this multicast convergence delay. There, that
proves my bias ;-).

Ganesan

-- 
R. Ganesan ([email-masked])       | Ph: 91-80-5721856 Ext: 2149
Novell India Development Center.       | #include <std_disclaimer.h>

---

From: Erik Guttman <[email-masked]>
Date: Wed, 20 Sep 2000 09:36:24 +0200 (MET DST)

> the service lookup time doubles because of the multicast convergence

Unless you issue both requests at the same time.
 
> looking up services to avoid this multicast convergence delay. There, that

Novell isn't using SLPv2 with '|' filters, so there isn't any backward
compatibility issue there.  I'm not saying no one else is using full
SLPv2 filters in their products - this could be a real issue.

Note 1: I still haven't heard anyone defend '!'.

Note 2: There is a tension between those who think there are interesting 
uses for complex queries (many of which we haven't though of yet) and 
those who think that service discovery with attributes is not required 
at all - and for whom *any* support for attributes/search filters is 
'too much.'  I'm trying to find a 'middle course.'

Erik

---

From: Ganesan Rajagopal <[email-masked]>
Date: 20 Sep 2000 14:34:56 +0530

>>>>> "Erik" == Erik Guttman <[email-masked]> writes:

> Unless you issue both requests at the same time.

You need to use the async API for that, but yes it is possible. 

> SLPv2 filters in their products - this could be a real issue.

Yes, current Novell clients only use SLPv1 and we could always change the
search filter when we move to SLPv2. However, as you say, there might be
others who are already using the filters.

> 'too much.'  I'm trying to find a 'middle course.'

How about allowing both '&' and '|' but not together (i.e. no nesting)? I
don't think this significantly increases complexity, but addresses a broader
range of queries. 

Ganesan

---

From: Erik Guttman <[email-masked]>
Date: Wed, 20 Sep 2000 11:33:24 +0200 (MET DST)

>>> if there is no DA in the network the service lookup time 
>>> doubles because of the multicast convergence algorithm. 

Multiple blocking threads work, too.

> However, as you say, there might be others who are already using the 
> filters.

The reason we do WG reviews of technical specs it to discover these 
(real as opposed to potential) conflicts.  If disallowing full LDAPv3
search filters would cause problems for any existing products, please 
post this information to the srvloc list.

> How about allowing both '&' and '|' but not together 
> (i.e. no nesting)? I don't think this significantly increases
> complexity, but addresses a broader range of queries. 

Its true this isn't complex - but the '&' case is so fundamentally 
important I haven't found justification for disallowing it in any
filter.

Erik

---

From: Evan Hughes <[email-masked]>
Date: Wed, 20 Sep 2000 12:18:08 -0400 (EDT)

On Tue, 19 Sep 2000, McDonald, Ira wrote:
...
> And I agree that '!' is of dubious value.

The following are three examples (off the top of my head) of the
usefulness of the '|' and '!' operators. 

   Consider the situation where I wish to print to one of a set of 
printers. My calendar app tells me that there are meetings going on in
rooms A, B, and C. How do I find the printers that are in nonbusy rooms?

   Consider the situation where an attribute has a set of allowed values.
The only way a UA can query for more than one of those allowed values in a
given attribute is to reissue the same request with different attribute
values in each. (ie, if we're interested in all services in which
attribute "a" is either 1, 3, 8, or 9, we have to issue four seperate
requests "(&(a=1)...)", "(&(a=3)...)", "(&(a=8)...)", and "(&(a=9)...)").

   The situation worsens when we want to find services for which a given
attribute does _not_ have a certain value. As an example, consider the
tn3270 template. The Ciphersuites attribute has nine defined values, if a
UA doesn't want one of them (say that one of them is no longer considered
secure), it must either:
  a) Request all known types individually (see prev. paragraph). 
  b) Request all servers and the attributes of those servers, and then
weed out bad responses. 

 Ten of the 17 templates listed in the repository have attributes that
have allowed values as discussed above, making this a potentially common
problem. 

e

---

From: Erik Guttman <[email-masked]>
Date: Thu, 21 Sep 2000 09:03:49 +0200 (MET DST)

> requests "(&(a=1)...)", "(&(a=3)...)", "(&(a=8)...)", and "(&(a=9)...)").

OK.  This is a reasonable issue.  If we had N values, where N is big,
and a reasonable subset are acceptable, the others not, we don't want to
send even log(N) requests.  We want to send one request.  I agree that 
without '|' we are in bad shape.

>   b) Request all servers and the attributes of those servers, and then

I understand how this can be supported with '|', but why do you need '!'?
The only possibility I can think of is if you have an attribute with a
very big number N of potential values, and you are willing to accept any
of them *except* some small number of values.  For example:

silly-attr = string
# this can take any of the following values
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19, <imagine>
1000,fred

Say we can accept any value except fred for silly-attr.  We could either 
send the search filter "(!(silly-attr=fred))" or 
"(|(silly-attr=0)(silly-attr=1) <imagine> (silly-attr=1000))"
Clearly the former is better to send.  The question is:  Is this really
a problem we have to solve?

Erik

---

From: Evan Hughes <[email-masked]>
Date: Thu, 21 Sep 2000 09:49:16 -0400 (EDT)

> a problem we have to solve?

   Yes. The leaf operators (those that perform tests on attributes) do not
provide a '!=' (NOT EQUAL) operator -- and the comparison operators ('=>'
and '=<') also test for equality, meaning that there is no way  to see if
an attribute is 'any value except'. 

   An example situation could involve the tn3270 'ciphersuites' attribute,
which lists all of the cypher protocols the server understands. If one or
two of those are considered untrustworthy, and a UA wants to find any
value except those untrustworthy ones, it is forced to list all known
values, as opposed to simply excluding the undesired values. 

e