IPP Mail Archive: IPP> FW: Revised SLPv2 Search Filters (for

IPP Mail Archive: IPP> FW: Revised SLPv2 Search Filters (for

IPP> FW: Revised SLPv2 Search Filters (for SLPv2 updates)

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sun Jul 22 2001 - 16:40:38 EDT

  • Next message: McDonald, Ira: "RE: IPP> FW: [Srvloc-discuss] [Multiple registrations for a singl e print device]"

    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.

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

    -----Original Message-----
    From: Erik Guttman [mailto:Erik.Guttman@sun.com]
    Sent: Wednesday, July 18, 2001 1:16 PM
    To: srvloc-discuss@lists.sourceforge.net
    Cc: erik.guttman@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:

    Please discuss this proposal on the mailing list, if you have any
    strong feelings about it.

    rev-2608-2 is:

        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:


        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'

        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.


    Srvloc-discuss mailing list

    This archive was generated by hypermail 2b29 : Sun Jul 22 2001 - 16:47:57 EDT