rfc2608.txt

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

   to ASCII character encoding).  Case insensitivity SHOULD be supported
   throughout the entire UTF-8 encoded Unicode [6] character set.

   The case insensitivity rule applies to all string matching in SLPv2,
   including Scope strings, SLP SPI strings, service types, attribute
   tags and values in query handling, language tags, previous responder
   lists.  Comparisons of URL strings, however, is case sensitive.

   White space (SPACE, CR, LF, TAB) internal to a string value is folded
   to a single SPACE character for the sake of string comparisons.
   White space preceding or following a string value is ignored for the
   purposes of string comparison.  For example, "  Some String  "
   matches "SOME    STRING".

   String comparisons (using comparison operators such as `<=' or `>=')
   are done using lexical ordering in UTF-8 encoded characters, not
   using any language specific rules.

   The reserved character `*' may precede, follow or be internal to a
   string value in order to indicate substring matching.  The query
   including this character matches any character sequence which
   conforms to the letters which are not wildcarded.

6.4.1. Scope Lists in SLP

   Scope Lists in SLPv2 have the following grammar:

   scope-list = scope-val / scope-val `,' scope-list
   scope-val = 1*safe
    safe = ; Any character except reserved.
   reserved = `(' / `)' / `,' / `\' / `!'  / `<' / `=' / `>' / `~' / CTL
         / `;' / `*' / `+'
   escape-val = `\' HEXDIG HEXDIG



Guttman, et al.             Standards Track                    [Page 16]

RFC 2608         Service Location Protocol, Version 2          June 1999


   Scopes which include any reserved characters must replace the escaped
   character with the escaped-val format.

7. Errors

   If the Error Code in a SLP reply message is nonzero, the rest of the
   message MAY be truncated.  No data is necessarily transmitted or
   should be expected after the header and the error code, except
   possibly for some optional extensions to clarify the error, for
   example as in section D.1.

   Errors are only returned for unicast requests.  Multicast requests
   are silently discarded if they result in an error.

   LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in
         the scope in the AttrRqst or SrvRqst, but not in the requested
         language.
   PARSE_ERROR = 2: The message fails to obey SLP syntax.
   INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero
         lifetime or an omitted Language Tag.
   SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in
         its <scope-list> supported by the SA or DA.
   AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an
         unsupported SLP SPI.
   AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR
         authentication in the SrvReg and did not receive it.
   AUTHENTICATION_FAILED = 7: The DA detected an authentication error in
         an Authentication block.
   VER_NOT_SUPPORTED = 9: Unsupported version number in message header.
   INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond.
   DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off.
   OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option
         from the mandatory range (see section 9.1).
   INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for
         an unregistered service or with inconsistent Service Types.
   MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst
         and does not support it.
   REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a
         DA more frequently than the DA's min-refresh-interval.

8. Required SLP Messages

   All length fields in SLP messages are in network byte order.  Where '
   tuples' are defined, these are sequences of bytes, in the precise
   order listed, in network byte order.

   SLP messages all begin with the following header:




Guttman, et al.             Standards Track                    [Page 17]

RFC 2608         Service Location Protocol, Version 2          June 1999


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Version    |  Function-ID  |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length, contd.|O|F|R|       reserved          |Next Ext Offset|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Extension Offset, contd.|              XID              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Language Tag Length      |         Language Tag          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Message Type             Abbreviation     Function-ID

          Service Request          SrvRqst              1
          Service Reply            SrvRply              2
          Service Registration     SrvReg               3   
          Service Deregister       SrvDeReg             4
          Service Acknowledge      SrvAck               5
          Attribute Request        AttrRqst             6
          Attribute Reply          AttrRply             7
          DA Advertisement         DAAdvert             8
          Service Type Request     SrvTypeRqst          9
          Service Type Reply       SrvTypeRply          10
          SA Advertisement         SAAdvert             11

   SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert.  SAs MUST
   also support SrvReg, SAAdvert and SrvAck.  For UAs and SAs, support
   for other messages are OPTIONAL.

     - Length is the length of the entire SLP message, header included.
     - The flags are:  OVERFLOW (0x80) is set when a message's length
       exceeds what can fit into a datagram.  FRESH (0x40) is set on
       every new SrvReg.  REQUEST MCAST (0x20) is set when multicasting
       or broadcasting requests.  Reserved bits MUST be 0.
     - Next Extension Offset is set to 0 unless extensions are used.
       The first extension begins at 'offset' bytes, from the message's
       beginning.  It is placed after the SLP message data.  See
       Section 9.1 for how to interpret unrecognized SLP Extensions.
     - XID is set to a unique value for each unique request.  If the
       request is retransmitted, the same XID is used.  Replies set
       the XID to the same value as the xid in the request.  Only
       unsolicited DAAdverts are sent with an XID of 0.
     - Lang Tag Length is the length in bytes of the Language Tag field.
     - Language Tag conforms to [7].  The Language Tag in a reply MUST
       be the same as the Language Tag in the request.  This field must
       be encoded 1*8ALPHA *("-" 1*8ALPHA).




Guttman, et al.             Standards Track                    [Page 18]

RFC 2608         Service Location Protocol, Version 2          June 1999


   If an option is specified, and not included in the message, the
   receiver MUST respond with a PARSE_ERROR.

8.1. Service Request

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Service Location header (function = SrvRqst = 1)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      length of <PRList>       |        <PRList> String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   length of <service-type>    |    <service-type> String      \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    length of <scope-list>     |     <scope-list> String       \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of predicate string   |  Service Request <predicate>  \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of <SLP SPI> string   |       <SLP SPI> String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In order for a Service to match a SrvRqst, it must belong to at least
   one requested scope, support the requested service type, and match
   the predicate.  If the predicate is present, the language of the
   request (ignoring the dialect part of the Language Tag) must match
   the advertised service.

   <PRList> is the Previous Responder List.  This <string-list> contains
   dotted decimal notation IP (v4) addresses, and is iteratively
   multicast to obtain all possible results (see Section 6.3).  UAs
   SHOULD implement this discovery algorithm.  SAs MUST use this to
   discover all available DAs in their scope, if they are not already
   configured with DA addresses by some other means.

   A SA silently drops all requests which include the SA's address in
   the <PRList>.  An SA which has multiple network interfaces MUST check
   if any of the entries in the <PRList> equal any of its interfaces.
   An entry in the PRList which does not conform to an IPv4 dotted
   decimal address is ignored:  The rest of the <PRList> is processed
   normally and an error is not returned.

   Once a <PRList> plus the request exceeds the path MTU, multicast
   convergence stops.  This algorithm is not intended to find all
   instances; it finds 'enough' to provide useful results.

   The <scope-list> is a <string-list> of configured scope names.  SAs
   and DAs which have been configured with any of the scopes in this
   list will respond.  DAs and SAs MUST reply to unicast requests with a



Guttman, et al.             Standards Track                    [Page 19]

RFC 2608         Service Location Protocol, Version 2          June 1999


   SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to
   include a scope they support (see Section 11).  The only exceptions
   to this are described in Section 11.2.

   The <service-type> string is discussed in Section 4.  Normally, a
   SrvRqst elicits a SrvRply.  There are two exceptions:  If the
   <service-type> is set to "service:directory-agent", DAs respond to
   the SrvRqst with a DAAdvert (see Section 8.5.)  If set to
   "service:service-agent", SAs respond with a SAAdvert (see Section
   8.6.)  If this field is omitted, a PARSE_ERROR is returned - as this
   field is REQUIRED.

   The <predicate> is a LDAPv3 search filter [14].  This field is
   OPTIONAL. Services may be discovered simply by type and scope.
   Otherwise, services are discovered which satisfy the <predicate>.  If
   present, it is compared to each registered service.  If the attribute
   in the filter has been registered with multiple values, the filter is
   compared to each value and the results are ORed together, i.e.,
   "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" matches
   (y=0,1) since Y can be nonzero.  Note the matching is case
   insensitive.  Keywords (i.e., attributes without values) are matched
   with a "presence" filter, as in "(keyword=*)".

   An incoming request term MUST have the same type as the attribute in
   a registration in order to match.  Thus, "(x=33)" will not match '
   x=true', etc.  while "(y=foo)" will match 'y=FOO'.
   "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be
   satisfied, because of the `|' (boolean disjunction).

   Wildcard matching MUST be done with the '=' filter.  In any other
   case, a PARSE_ERROR is returned.  Request terms which include
   wildcards are interpreted to be Strings.  That is, (x=34*) would
   match 'x=34foo', but not 'x=3432' since the first value is a String
   while the second value is an Integer; Strings don't match Integers.

   Examples of Predicates follow.  <t> indicates the service type of the
   SrvRqst, <s> gives the <scope-list> and <p> is the predicate string.

      <t>=service:http  <s>=DEFAULT  <p>=  (empty string)
               This is a minimal request string.  It matches all http
               services advertised with the default scope.

      <t>=service:pop3  <s>=SALES,DEFAULT  <p>=(user=wump)
               This is a request for all pop3 services available in
               the SALES or DEFAULT scope which serve mail to the user
               `wump'.





Guttman, et al.             Standards Track                    [Page 20]

RFC 2608         Service Location Protocol, Version 2          June 1999


      <t>=service:backup  <s>=BLDG 32  <p>=(&(q<=3)(speed>=1000))
               This returns the backup service which has a queue length
               less than 3 and a speed greater than 1000.  It will
               return this only for services registered with the BLDG 32
               scope.

      <t>=service:directory-agent  <s>=DEFAULT  <p>=
               This returns DAAdverts for all DAs in the DEFAULT scope.

   DAs are discovered by sending a SrvRqst with the service type set to
   "service:directory-agent".  If a predicate is included in the
   SrvRqst, the DA SHOULD respond only if the predicate can be satisfied
   with the DA's attributes.  The <scope-list> MUST contain all scopes
   configured for the UA or SA which is discovering DAs.

   The <SLP SPI> string indicates a SLP SPI that the requester has been
   configured with.  If this string is omitted, the responder does not
   include any Authentication Blocks in its reply.  If it is included,
   the responder MUST return a reply which has an associated
   authentication block with the SLP SPI in the SrvRqst.  If no replies
   may be returned because the SLP SPI is not supported, the responder
   returns an AUTHENTICATION_UNKNOWN error.