rfc2165.txt

SLP协议在linux下的实现。此版本为1.2.1版。官方网站为www.openslp.org

Veizades, et. al.           Standards Track                    [Page 22]

RFC 2165               Service Location Protocol               June 1997


   In the absence of a Directory Agent, the request above could be
   multicast.  In this case it would be sent to the Service Specific
   Multicast Address for "service:printer" and not to the Directory
   Agent.  Service Agents that can satisfy the predicate will reply.
   Service Agents which cannot support the character set of the request
   MUST return CHARSET_NOT_UNDERSTOOD in the SrvRply.  In all other
   circumstances, Service Agents which cannot satisfy the reply do not
   send any reply at all.

   The only way a User Agent can be sure there are no services which
   match the query is by retrying the request (CONFIG_INTERVAL_8).  If
   no response comes, the User Agent gives up and assumes there are no
   such printers.

   Another form of query is a simpler 'join' query.  Its syntax has no
   parentheses or logical operators.  Each term is conjoined (AND-ed
   together.)  Rewriting the initial query provides an example:

      lpr//PAGES PER MINUTE==12,
           UNRESTRICTED_ACCESS,
           LOCATION==12th FLOOR/

5.2. Directory Agent Discovery Request

   Normally a Service Request returns a Service Reply.  The sole
   exception to this is a Service Request for the Service Type
   "directory-agent".  This Service Request is answered with a DA
   Advertisement.

   Without configured knowledge of a Directory Agent (DA), a User Agent
   or Service Agent uses a Service Request to discover a DA. (See
   section 15.1 for mechanisms by which a client may be configured to
   have knowledge of a DA.) Such a Service Request used for Directory
   Agent Discovery includes a predicate of the form:

      directory-agent///

   This query is always sent to the Directory Agent Discovery multicast
   address.  The Service Type of a Directory Agent is "directory-agent",
   hence it is the Service Type used in the request.  No scope is
   included in the request, so all Directory Agents will reply.  This is
   the only request which omits a scope which all Directory Agents MUST
   respond to.  Normally, a Directory Agent with a scope ONLY responds
   to requests with that scope.  No Naming Authority is included, so
   "IANA" is assumed.  We want to reach all the available directory
   agents.  If the scope were supplied, only DAs supporting that scope
   would reply.




Veizades, et. al.           Standards Track                    [Page 23]

RFC 2165               Service Location Protocol               June 1997


   DA Advertisement Replies may arrive from different sources, similar
   in form to:

     URL returned:   service:directory-agent://slp-resolver.catch22.com
     Scope returned: ACCOUNTING

     URL returned:   service:directory-agent://204.182.15.66 Scope
     returned: JANITORIAL SERVICES

   The DA Advertisement format is defined in Section 14.

   If the goal is merely to discover any Directory Agent, the first
   reply will do.  If the goal, however, is to discover all reachable
   DAs, the request must be retransmitted after an interval (the
   recommended time is CONFIG_INTERVAL_5).  This retransmitted request
   will include a list of DAs which have already responded.  See
   sections 7 and 20.1.  Directory Agents which receive the request will
   only respond if they are not on this list.  After there are no new
   replies, all DAs are presumed to have been discovered.

   If a DA fails to respond after CONFIG_INTERVAL_6 seconds, the UA or
   Service Agent should use a different DA. DA addresses may be cached
   from previous discovery attempts, preconfigured, or by use of DHCP
   (see section 15.2).  If no such DA responds, DA discovery should be
   used to find a new DA. Only after CONFIG_INTERVAL_7 seconds should it
   be assumed that no DA exists and multicast based Service Requests
   should be used.

5.3. Explanation of Terms of Predicate Grammar

   A predicate has a simple structure, which depends on parentheses,
   commas and slashes to delimit the elements.  Examples of proper usage
   are given throughout this document.  The terms used in the grammar
   are as follows:

      predicate:

         Placed in a Service Request, this is interpreted by a Service
         Agent or Directory Agent to determine what information to
         return.

      scope:

         If this is absent in a Service Request, the request will match
         only services registered without a scope.  If it is present,
         only services registered under that scope or are unscoped will
         match the request.




Veizades, et. al.           Standards Track                    [Page 24]

RFC 2165               Service Location Protocol               June 1997


      where-clause:

         This determines which services the request matches.  An empty
         where-clause will match all services.  The request will be
         limited to services which have the specified Service Type, so
         the where-clause is not the sole factor in picking out which
         services match the request.

      where-list:

         The where-list is a logical expression.  It can be a single
         expression, a disjunction or a conjunction.  A single
         expression must apply for the where-clause to match.  A
         disjunction matches if any expression in the OR list matches.
         A conjunction matches only if all elements in the AND list
         match.

         Note that there is no logical negation operator:  This is
         because there is no notion of returning "everything except"
         what matches a given criteria.

         A where-list can be nested and complex.  For example, the
         following requires that three subexpressions must all be true:

                (& (| <query-item> <query-item>)
                   <query-item>
                   (& <query-item> <query-item> <query-item>)
                )

         Notice that white space, tabs or carriage returns can be added
         anywhere outside query-items.  Each list has 2 or more items in
         it, and lists can be nested.  Services which fulfill the entire
         logical expression match the where-clause.

         degenerate expressions but they should be tolerated.  They are
         equivalent to <query-item>.

      query-item:

         A query item has the form:

               '(' <attr-tag> <comp-op> <attr-val> ')'

         or

               '(' <keyword> ')'





Veizades, et. al.           Standards Track                    [Page 25]

RFC 2165               Service Location Protocol               June 1997


         Examples of this would be:

            (SOME ATTRIBUTE == SOME VALUE)
            (RESERVED)
            (QUEUE LENGTH <= 234)

      query-join:

         The query-join is a comma delimited list of conditions which
         the service must satisfy in order to match the query.  The
         items are considered to be logically conjoined.  Thus the
         query-join:

               ATTR1=VALUE1, KEYWORD1, KEYWORD2, ATTR2>=34

         is equivalent to the where-list:

               (& (ATTR1=VALUE1) (KEYWORD1) (KEYWORD2) (ATTR2>=34))

         The query-join cannot be mixed with a where-list.  It is
         provided as a convenient mechanism to provide a statement of
         necessary conditions without building a logical expression.

5.4. Service Request Predicate Grammar

   Service Requests can precisely describe the services they need by
   including a Predicate the body of the Request.  This Predicate must
   be constructed according to the grammar below.

   <predicate>  ::= <srvtype>['.'<na>]'/'<scope>'/'<where>'/'

   <srvtype>    ::= string representing type of service.  Only
                    alphanumeric characters, '+', and '-' are allowed.

   <na>         ::= string representing the Naming Authority.
                    Only alphanumeric characters, '+',
                    and '-' are allowed.  If this field is
                    omitted then "IANA" is assumed.

   <scope>      ::= string representing the directory agent scope.
                    '/', ',' (comma) and ':'  are not allowed in
                    this string.  The scopes "LOCAL" and "REMOTE"
                    are reserved.

   <attr-tag>   ::= class name of an attribute of a given Service
                    Type.  This tag cannot include the following
                     characters:  '(', ')', ',', '=', '!', '>',
                     '<', '/', '*', except where escaped (see 17.1.)



Veizades, et. al.           Standards Track                    [Page 26]

RFC 2165               Service Location Protocol               June 1997


   <keyword>    ::= a class name of an attribute which will have
                    no values.  This string has the same limits
                    as the <attr-tag>, except that white space
                    internal to the keyword is illegal.

   <where>      ::= <where-any> |
                    <where-list> |
                    <query-join>

   <where-any>  ::=
                    That is NOTHING, or white space.

   <where-list> ::= '(' '&' <where-list> <query-list> ')' |
                    '(' '|' <where-list> <query-list> ')' |
                    '(' <keyword> ')'
                    '(' <attr-tag> <comp-op> <attr-val> ')'

   <query-list> ::= <where-list> |
                    <where-list> <query-list>
   <query-join> ::= <keyword> |
                    <join-item> |
                    <query-join> ',' <keyword> |
                    <query-join> ',' <join-item>

   <join-item>  ::= <attr-tag> <comp-op> <attr-val>

   <comp-op>    ::= "!=" | "==" | '<' | "<=" | '>' | ">="

   <attr-val>   ::= any string (see Section 20.5 for the ways
                    in which attr-vals are interpreted.)
                    Value strings may not contain '/', ','
                    '=', '<', '>', or '*' except where escaped
                    (see 17.1.).

                    '(' and ')' may be used in attribute values
                     for the purpose of encoding a binary values.
                     Binary encodings (See 20.5) may
                     include the above reserved characters.

5.5. String Matching for Requests

   All strings are case insensitive, with respect to string matching on
   queries.  All preceding or trailing blanks should not be considered
   for a match, but blanks internal to a string are relevant.

   For example, "  Some String  " matches "SOME STRING", but not "some
   string".




Veizades, et. al.           Standards Track                    [Page 27]

RFC 2165               Service Location Protocol               June 1997


   String matching may only be performed over the same character sets.
   If a request cannot be satisfied due to a lack of support for the
   character set of the request a CHARSET_NOT_UNDERSTOOD error is
   returned.

   String comparisons (using comparison operators such as '<' or
   registration, not using any language specific rules.  The ordering is
   strictly by the character value, i.e.  "0" < "A" is true when the
   character set is US-ASCII, since "0" has the value of 48 and "A" has
   the value 65.

   The special character '*' may precede or follow a string in order to
   allow substring matching.  If the '*