rfc2165.txt

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

   Reply containing the URL entry.  Service attributes are registered
   along with an Attribute Authentication block.  Both authentication
   blocks have the format illustrated below.

   If a service registration is accompanied by authentication which can
   be validated by the DA, the DA MUST validate any subsequent service
   deregistrations, so that unauthorized entities cannot invalidate such
   registered services.  Likewise, if a service registration is
   accompanied by an Attribute Authentication block which can be
   validated by the DA, the DA MUST validate any subsequent attribute
   registrations, so that unauthorized entities cannot invalidate such
   registered attributes.

   To avoid replay attacks which use previously validated
   deregistrations, the deregistration or attribute registration message
   must contain a timestamp for use by the DA. To avoid replay attacks
   which use previously validated registrations to nullify a valid
   deregistration, registrations must also contain a timestamp.














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


   An authentication block has the following format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                           Timestamp                           +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Block Structure Descriptor   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Structured Authenticator ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Timestamp A 64-bit value formatted as specified by the Network
               Time Protocol (NTP) [16].

      Block Structure Descriptor (BSD)
               A value describing the structure of the Authenticator.
               The only value currently defined is 1, for
               Object-Identifier.

      Length   The length of the Authenticator

      Structured Authenticator
               An algorithm specification, and the authentication data
               produced by the algorithm.

   The Structured Authenticator contains a digital signature of the
   information being authenticated.  It contains sufficient information
   to determine the algorithm to be used and the keys to be selected to
   verify the digital signature.

   The digital signature is computed over the following ordered stream
   of data:

       CHARACTER ENCODING OF URL   (2 bytes in network byte order)
       LIFETIME                    (2 bytes in network byte order)
       LENGTH OF URL               (2 bytes in network byte order)
       URL                         (n bytes)
       TIMESTAMP                   (8 bytes in SNTP format [16])










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


   When producing a URL Authentication block, the authentication data
   produced by the algorithm identified within the Structured
   Authenticator calculated over the following ordered stream of data:

       ATTRIBUTE CHARACTER ENCODING   (2 bytes in network byte order)
       LENGTH OF ATTRIBUTES           (2 bytes in network byte order)
       ATTRIBUTES                     (n bytes)
       TIMESTAMP                      (8 bytes in SNTP format [16])

   Every Service Location Protocol entity (User Agent, Service Agent, or
   Directory Agent) which is configured for use with protected scopes
   SHOULD implement "md5WithRSAEncryption" [4] and be able to associate
   it with BSD value == 1.

   In the case where BSD value == 1 and the OID "md5WithRSAEncryption"
   is selected, the Structured Authenticator will start with the ASN.1
   Distinguished Encoding (DER) [9] for "md5WithRSAEncryption", which
   has the as its value the bytes (MSB first in hex):

      "30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00"

   This is then immediately followed by an ASN.1 Distinguished Encoding
   (as a "Bitstring") of the RSA encryption (using the Scope's private
   key) of a bitstring consisting of the OID for "MD5" concatenated by
   the MD5 [22] message digest computed over the fields above.  The
   exact construction of the MD5 OID and digest can be found in RFC 1423
   [4].

4.4. URL Entry Lifetime

   The Lifetime field is set to the number of seconds the reply can be
   cached by any agent.  A value of 0 means the information must not be
   cached.  User Agents MAY cache service information, but if they do,
   they must provide a way for applications to flush this cached
   information and issue the request directly onto the network.

   Services should be registered with DAs with a Lifetime, the suggested
   value being CONFIG_INTERVAL_1.  The service must be reregistered
   before this interval elapses, or the service advertisement will no
   longer be available.  Thus, services which vanish and fail to
   deregister eventually become automatically deregistered.

5. Service Request Message Format

   The Service Request is used to obtain URLs from a Directory Agent or
   Service Agents.





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


   The format of the Service Request is as follows:

      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 = SrvReq)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |length of prev resp list string|<Previous Responders Addr Spec>|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     \                  <Previous Responders Addr Spec>              \
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of predicate string   |  Service Request <predicate>  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     \               Service Request <predicate>, contd.             \
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If a UA issues a request which will result in a reply which is too
   large, the SA or DA will return an abbreviated response (in a
   datagram the size of the site's MTU) which has the 'Overflow' bit
   flag set.  The UA must then issue the request again using TCP.

   The <Previous Responders Addr Spec> is described in sections 7 and
   20.1.

   After a User Agent restarts (say, after rebooting of a system,
   loading of the network kernel), Service Requests should be delayed
   for some random time uniformly distributed within a one second
   interval centered about a configured delay value (by default,
   CONFIG_INTERVAL_4).

   The Service Request allows the User Agent to specify the Service Type
   of the service and a Predicate in a specific language.  The general
   form of a Service Request is shown below:

      <srvtype>[.<na>]/[<scope>]/[<where>]/

   The punctuation is necessary even where the fields are omitted.

    -  The <srvtype> refers to the Service Type.  For each type of
       service available, there is a unique Service type name string.
       See section 20.2.1.






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


    -  The <na> is the Naming Authority.  This string determines the
       semantic interpretation of the attribute information in the
       <where> part of the Service Request.

    -  The <scope> is a string used to restrict the range of the query.
       Scope is determined administratively, at a given site.  It is not
       necessarily related to network topology (see Section 16).
       Leaving this field out means that the request can be satisfied
       only by unscoped service advertisements.

    -  The <where> string is the Where Clause of the request.  It
       contains a query which allows the selection of those service
       instances which the User Agent is interested in.  The query
       includes attributes, boolean operators and relations.  (See
       section 5.3.)

   In the case of a multicast service request, a list of previous
   responders is sent.  This list will prevent those in the list from
   responding, to be sure that responses from other sources are not
   drowned out.  The request is multicast repeatedly (with a recommended
   wait interval of CONFIG_INTERVAL_2) until there are no new responses,
   or a certain time (CONFIG_INTERVAL_3) has elapsed.  Different timing
   values are applied to a Service Request used for Directory Agent
   Discovery, see Section 5.2.

   In order for a request to succeed in matching registered information,
   the following conditions must be met:

    1. The result must have the same Service Type as the request.

    2. It must have the same Naming Authority.

    3. It must have the same scope.  (If the scope of the request
       as omitted, the request will only match services which were
       registered with no scope.  Note that a scoped request WILL match
       all unscoped Services).

    4. The conditions specified in the Where Clause must match the
       attributes and keywords registered for the service.












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


5.1. Service Request Usage

   The User Agent may form Service Requests using preconfigured
   knowledge of a Service Type's attributes.  It may also issue
   Attribute Requests to obtain the attribute values for a Service Type
   before issuing Service Requests (see Section 13).  Having obtained
   the attributes which describe a particular kind of service from an
   Attribute Request, or using configured knowledge of a service's
   attributes, the User Agent can build a predicate that describes the
   service needs of the user.

   Service Requests may be sent directly to a Directory Agent.  Suppose
   a printer supporting the lpr protocol is needed on the 12th floor
   which has UNRESTRICTED_ACCESS and prints 12 pages per minute.
   Suppose further that a Attribute Request indicates that there is a
   printer on the 12th floor, a printer that prints 12 pages per minute,
   and a printer that offers UNRESTRICTED_ACCESS. To check whether they
   are same printer, issue the following request:

      lpr//(& (PAGES PER MINUTE==12)
               (UNRESTRICTED_ACCESS)
               (LOCATION==12th FLOOR))/

   Suppose there is no such printer.  The Directory Agent responds with
   a Service Reply with 0 in the number of responses and no reply
   values.

   The User Agent then tries a less restrictive query to find a printer,
   using the 12th floor as "where" criteria.

      lpr//(LOCATION==12th FLOOR)/

   In this case, there is now only one reply:

      Returned URL:   service:lpr://igore.wco.ftp.com:515/draft

   The Address Specification for the printer is:  igore.wco.ftp.com:515,
   containing the name of the host managing the requested printer.
   Files would be printed by spooling to that port on that host.  The
   word 'draft' refers to the name of the print queue the lpr server
   supports.