Hi folks,
As some of you know, standard SLPv2 supports searches with
full LDAPv3 expressions as an OPTION.
The following is a proposal by Erik Guttman to reject the
limiting of LDAPv3 filters but ALSO add the new OPTION for
a limited search SA (service agent, in the printer, for
example) to only support very simple LDAPv3 filters.
The result of this discussion on the SLP Revisions mailing
list will be worth close consideration for any future IPP
generic attribute search filter optional features, as LDAPv3
compatibility has significant value in the marketplace.
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc
-----Original Message-----
From: Erik Guttman [mailto:Erik.Guttman at sun.com]
Sent: Wednesday, July 18, 2001 1:16 PM
To: srvloc-discuss at lists.sourceforge.net
Cc: erik.guttman at sun.com
Subject: [Srvloc-discuss] rev-2608-2 reevaluation
There has been a lot of discussion of the proposal rev-2608-2.
I propose that we REJECT rev-2608-2 and open a new revision
discussion on the limited support for search filters proposed
by Matt Peterson:
http://www.geocrawler.com/archives/3/12970/2001/7/0/6135105
Please discuss this proposal on the mailing list, if you have any
strong feelings about it.
rev-2608-2 is:
Description
===========
Search filters may only be a single term '(a=b)' or a sequence
of terms conjoined together '(&(a=b)(c=d)(e=f))'. '!', '|' And
multiple nesting is not supported.
The reason for requiring simplified search filters is to reduce the
complexity of SA implementation.
My new proposal is:
Description
===========
Search filters are defined in RFC 2608 to comply with LDAP
search filter rules (excluding extensible matching rules).
Support for arbitrarily nested logical functions '&', '|' and '!'
requires complex query interpretation code and implies that the
data store for service agents be designed to accomodate such
searches efficiently. This makes implementation of SLP on very
small platforms difficult.
Dropping support for arbitrary search filters entirely and instead
adopting a subset of these filters for SLP would simplify the
implementation. At the same time, it would limit the capability
of the protocol to express genuinely useful conditions.
Note that query support is already optional - but it is all or
nothing. If a service type supports any attributes, full search
filter support is required. This proposal is a 'middle ground'
compromise.
This proposal is for a class of limited support - for SAs - which
would be OPTIONAL to implement. In this case, the rule is simply
support for either single atomic terms (like '(a=4)') or a conjoined
list of such terms '(&(a=4)(b=3)(c=snort*snort))'.
An SA which receives a service request containing a search filter
which it cannot evaluate (with '|' terms, nested '&' terms, '!' terms,
etc.) would fail to evaluate it. If the request was multicast -
the request would be dropped. If the request were unicast, an error
of code MSG_NOT_SUPPORTED is returned.
The UA can infer that the SA only supports limited queries because
(a) all SAs support SrvRqsts. (b) MSG_NOT_SUPPORTED in response to
a SrvRqst will be defined to mean that the SA cannot support complex
search filters.
This is wire compatible with existing SLP implementations. First,
multicast convergence will work as before. New SAs with limited
capabilities were not present (or discoverable) by legacy UAs, so they
will not miss anything they could've found before. No new error codes
can be returned to confuse legacy software.
Future versions will be instructed that they SHOULD use simple query
filters in multicast requests as some SAs may only implement limited
search filters.
Note that a clever API can break up a compound query into multiple
non-compound ones: "(|(A=1)(B=1))" can be issued as "(A=1)" and "(B=1)"
'!' support can be supported on the UA side by acquiring attributes
associated with service instances and checking to see if the desired
attribute instance is not present. A better way to do this would be
to simply not expose or support '!' and compound queries at the
API at all - which the API implementation MAY do. This is justified
by the fact that there are very few existing or even plausible human
interfaces which support disjunctions or negations.
DAs MUST implement full search filter support.
Erik
_______________________________________________
Srvloc-discuss mailing list
Srvloc-discuss at lists.sourceforge.nethttp://lists.sourceforge.net/lists/listinfo/srvloc-discuss