rfc2608.txt

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

   which identify services which are administratively identified.  A
   scope could indicate a location, administrative grouping, proximity
   in a network topology or some other category.  Service Agents and
   Directory Agents are always assigned a scope string.

   A User Agent is normally assigned a scope string (in which case the
   User Agent will only be able to discover that particular grouping of
   services).  This allows a network administrator to 'provision'
   services to users.  Alternatively, the User Agent may be configured
   with no scope at all.  In that case, it will discover all available
   scopes and allow the client application to issue requests for any
   service available on the network.

   +---------+   Multicast  +-----------+   Unicast   +-----------+
   | Service | <--SrvRqst-- |   User    | --SrvRqst-> | Directory |
   |  Agent  |              |   Agent   |             |   Agent   |
   | Scope=X |   Unicast    | Scope=X,Y |   Unicast   |  Scope=Y  |
   +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+

   In the above illustration, the User Agent is configured with scopes X
   and Y. If a service is sought in scope X, the request is multicast.
   If it is sought in scope Y, the request is unicast to the DA.
   Finally, if the request is to be made in both scopes, the request
   must be both unicast and multicast.

   Service Agents and User Agents may verify digital signatures provided
   with DAAdverts.  User Agents and Directory Agents may verify service
   information registered by Service Agents.  The keying material to use
   to verify digital signatures is identified using a SLP Security
   Parameter Index, or SLP SPI.

   Every host configured to generate a digital signature includes the
   SLP SPI used to verify it in the Authentication Block it transmits.
   Every host which can verify a digital signature must be configured
   with keying material and other parameters corresponding with the SLP
   SPI such that it can perform verifying calculations.

   SAs MUST accept multicast service requests and unicast service
   requests.  SAs MAY accept other requests (Attribute and Service Type
   Requests).  SAs MUST listen for multicast DA Advertisements.

   The features described up to this point are required to implement.  A
   minimum implementation consists of a User Agent, Service Agent or
   both.

   There are several optional features in the protocol.  Note that DAs
   MUST support all these message types, but DA support is itself



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


   optional to deploy on networks using SLP. UAs and SAs MAY support
   these message types.  These operations are primarily for interactive
   use (browsing or selectively updating service registrations.)  UAs
   and SAs either support them or not depending on the requirements and
   constraints of the environment where they will be used.

  Service Type Request   A request for all types of service on the
                         network.  This allows generic service browsers
                         to be built.

  Service Type Reply     A reply to a Service Type Request.

  Attribute Request      A request for attributes of a given type of
                         service or attributes of a given service.

  Attribute Reply        A reply to an Attribute Request.

  Service Deregister     A request to deregister a service or some
                         attributes of a service.

  Service Update         A subsequent SrvRqst to an advertisement.
                         This allows individual dynamic attributes to
                         be updated.

  SA Advertisement       In the absence of Directory Agents, a User
                         agent may request Service Agents in order
                         to discover their scope configuration.  The
                         User Agent may use these scopes in requests.

   In the absence of Multicast support, Broadcast MAY be used.  The
   location of DAs may be staticly configured, discovered using SLP as
   described above, or configured using DHCP. If a message is too large,
   it may be unicast using TCP.

   A SLPv2 implementation SHOULD support SLPv1 [22].  This support
   includes:

    1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.

    2. Unscoped SLPv1 requests are considered to be of DEFAULT scope.
       SLPv1 UAs MUST be reconfigured to have a scope if possible.

    3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1
       DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.

    4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2
       requests with SLPv2 replies.




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


    5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same
       way.  That is, incoming requests from agents using either version
       of the protocol will be matched against this common set of
       registered services.

    6. SLPv2 registrations which use Language Tags which are greater
       than 2 characters long will be inaccessible to SLPv1 UAs.

    7. SLPv2 DAs MUST return only service type strings in SrvTypeRply
       messages which conform to SLPv1 service type string syntax, ie.
       they MUST NOT return Service Type strings for abstract service
       types.

    8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service
       URLs with abstract service types.  They only match Service URLs
       with concrete service types.

   SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will
   not receive replies from SLPv1 SAs.  In order to interoperate UAs and
   SAs of different versions require a SLPv2 DA to be present on the
   network which supports both protocols.

   The use of abstract service types in SLPv2 presents a backward
   compatibility issue for SLPv1.  It is possible that a SLPv1 UA will
   request a service type which is actually an abstract service type.
   Based on the rules above, the SLPv1 UA will never receive an abstract
   Service URL reply.  For example, the service type 'service:x' in a
   SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'.
   If the request was made with SLPv2, it would return the attributes of
   this service.

4. URLs used with Service Location

   A Service URL indicates the location of a service.  This URL may be
   of the service: scheme [13] (reviewed in section 4.1), or any other
   URL scheme conforming to the URI standard [8], except that URLs
   without address specifications SHOULD NOT be advertised by SLP. The
   service type for an 'generic' URL is its scheme name.  For example,
   the service type string for "http://www.srvloc.org" would be "http".

   Reserved characters in URLs follow the rules in RFC 2396 [8].










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


4.1. Service: URLs

   Service URL syntax and semantics are defined in  [13].  Any network
   service may be encoded in a Service URL.

   This section provides an introduction to Service URLs and an example
   showing a simple application of them, representing standard network
   services.

   A Service URL may be of the form:

      "service:"<srvtype>"://"<addrspec>

   The Service Type of this service: URL is defined to be the string up
   to (but not including) the final `:'  before <addrspec>, the address
   specification.

   <addrspec> is a hostname (which should be used if possible) or dotted
   decimal notation for a hostname, followed by an optional `:'  and
   port number.

   A service: scheme URL may be formed with any standard protocol name
   by concatenating "service:" and the reserved port [1] name.  For
   example, "service:tftp://myhost" would indicate a tftp service.  A
   tftp service on a nonstandard port could be
   "service:tftp://bad.glad.org:8080".

   Service Types SHOULD be defined by a "Service Template" [13], which
   provides expected attributes, values and protocol behavior.  An
   abstract service type (also described in [13]) has the form

      "service:<abstract-type>:<concrete-type>".

   The service type string "service:<abstract-type>" matches all
   services of that abstract type.  If the concrete type is included
   also, only these services match the request.  For example:  a SrvRqst
   or AttrRqst which specifies "service:printer" as the Service Type
   will match the URL service:printer:lpr://hostname and
   service:printer:http://hostname.  If the requests specified
   "service:printer:http" they would match only the latter URL.

   An optional substring MAY follow the last `.'  character in the
   <srvtype> (or <abstract-type> in the case of an abstract service type
   URL). This substring is the Naming Authority, as described in Section
   9.6.  Service types with different Naming Authorities are quite
   distinct.  In other words, service:x.one and service:x.two are
   different service types, as are service:abstract.one:y and
   service:abstract.two:y.



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


4.2. Naming Authorities

   A Naming Authority MAY optionally be included as part of the Service
   Type string.  The Naming Authority of a service defines the meaning
   of the Service Types and attributes registered with and provided by
   Service Location.  The Naming Authority itself is typically a string
   which uniquely identifies an organization.  IANA is the implied
   Naming Authority when no string is appended.  "IANA" itself MUST NOT
   be included explicitly.

   Naming Authorities may define Service Types which are experimental,
   proprietary or for private use.  Using a Naming Authority, one may
   either simply ignore attributes upon registration or create a local-
   use only set of attributes for one's site.  The procedure to use is
   to create a 'unique' Naming Authority string and then specify the
   Standard Attribute Definitions as described above.  This Naming
   Authority will accompany registration and queries, as described in
   Sections 8.1 and 8.3.  Service Types SHOULD be registered with IANA
   to allow for Internet-wide interoperability.

4.3. URL Entries

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved    |          Lifetime             |   URL Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |URL len, contd.|            URL (variable length)              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |# of URL auths |            Auth. blocks (if any)              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SLP stores URLs in protocol elements called URL Entries, which
   associate a length, a lifetime, and possibly authentication
   information along with the URL. URL Entries, defined as shown above,
   are used in Service Replies and Service Registrations.

5. Service Attributes

   A service advertisement is often accompanied by Service Attributes.
   These attributes are used by UAs in Service Requests to select
   appropriate services.

   The allowable attributes which may be used are typically specified by
   a Service Template  [13] for a particular service type.  Services
   which are advertised according to a standard template MUST register
   all service attributes which the standard template requires.  URLs
   with schemes other than "service:" MAY be registered with attributes.



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


   Non-standard attribute names SHOULD begin with "x-", because no
   standard attribute name will ever have those initial characters.

   An attribute list is a string encoding of the attributes of a
   service.  The following ABNF [11] grammar defines attribute lists:

   attr-list = attribute / attribute `,' attr-list
   attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag