rfc2609.txt

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

      hostnumber      =   ipv4-number
      ipv4-number     =   1*3DIGIT 3("." 1*3DIGIT)
      port            =   1*DIGIT
                          ; A port number must be included if the
                          ; protocol field does not have an IANA
                          ; assigned port number.
      user            =   *[ uchar / ";" / "+" / "&" / "=" ]
      ipxsite         =   "/ipx/" ipx-net ":" ipx-node ":" ipx-socket
      ipx-net         =   8 HEXDIGIT
      ipx-node        =   12 HEXDIGIT
      ipx-socket      =   4 HEXDIGIT
      atsite          =   "/at/" at-object ":" at-type "" at-zone



Guttman, et al.             Standards Track                     [Page 6]

RFC 2609               Service Templates and URLs              June 1999


      at-object       =   1*31apple-char
      at-type         =   1*31apple-char
      at-zone         =   1*31apple-char
      apple-char      =   ALPHA / DIGIT / safe / escaped
                      =   ; AppleAscii [7] values that are not
                      =   ; from the restricted range must be escaped.
                      =   ; NOTE: The escaped values do NOT correspond
                      =   ; to UTF-8 values here:  They are AppleAscii
                      =   ; bytes.
      url-part        =   [ url-path ] [ attr-list ]
      url-path        =   1 * ( "/" *xchar )
                          ; Each service type must define its
                          ; own syntax consistent
                          ; with [5].
      attr-list       =   1 * ( ";" attr-asgn )
      attr-asgn       =   attr-id / attr-id "=" attr-value
      safe            =   "$" / "-" / "_" / "." / "~"
      extra           =   "!" / "*" / "'" / "(" / ")" / "," / "+"
      uchar           =   unreserved / escaped
      xchar           =   unreserved / reserved / escaped
      escaped         =   1*(`\' HEXDIG HEXDIG)
      reserved        =   ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
      unreserved      =   ALPHA / DIGIT / safe / extra

   IPX addresses [14] are composed of a network, node and socket number.
   The IPX network number is a four-byte number, in network order and
   expressed in hexadecimal, that signifies an IPX subnet.  The node
   element represents a network interface card.  It is a six-byte
   number, expressed in hexadecimal, that is usually the same as the
   node ID of the interface card.  The socket element represents a
   specific service access point, given an IPX network and node.  IPX
   sockets are analogous to TCP/IP ports, and are not to be confused
   with Berkeley sockets.

   AppleTalk addresses [9] are composed of an object, type and zone.
   The object is a human readable string.  The type is an identifier,
   not intended for human readability.  The zone refers to the AppleTalk
   Zone name, which is also human readable.  The characters composing
   these names are drawn from the AppleAscii character set [7].  Thus,
   they do not equate to escaped ASCII or UTF-8 characters.  The
   characters "=" and "*" are reserved and may not be included in the
   names even in binary form.

   In cases besides the AppleTalk grammar, some characters must be
   escaped before use.  To escape any character, precede the two digits
   indicating its ASCII value by '%'.





Guttman, et al.             Standards Track                     [Page 7]

RFC 2609               Service Templates and URLs              June 1999


2.2. Service URL Semantics

   The service scheme-specific information following the "service:"  URL
   scheme identifier provides information necessary to access the
   service.  As described in the previous subsection, the form of a
   service: URL is as follows:

      service: URL = "service:" service-type ":" site url-path

   where <site> has one of the following forms could refer to an
   <ipsite>, <ipxsite> or <atsite> if the service URL locates to an IP,
   IPX or AppleTalk service access point, respectively.

   As discussed in Section 1, the <service-type> can be either a
   concrete protocol name, or an abstract type name.

   The <ipsite> field is typically either a domain name (DNS) or an IP
   network protocol address for the service, and possibly a port number.
   Note that use of DNS hostnames is preferred for ease of renumbering.
   The <site> field can be null if other information in the service URL
   or service attributes is sufficient to use the service.

   The <sap> field allows more information to be provided (by way of
   <url-path> and <attr-list>) that can uniquely locate the service or
   resource if the <site> is not sufficient for that purpose.  For IP
   addresses, the <site> field begins with "//".  Other address families
   supported are IPX [14] and AppleTalk [9].

   An <attr-list> field appears at the end of the <url-part> field, but
   is never required to exist in any service location registration.

   The <attr-list> field is composed of a list of semicolon (";")
   separated attribute assignments of the form:

      attr-id "=" attr-value

   or for keyword attributes:

      attr-id

   Attributes are part of service: URLs when the attributes are required
   to access a particular service.  For instance, an ACAP [13] service
   might require that the client authenticate with it through Kerberos.
   Including an attribute in the service registration allows the ACAP
   client to make use of the correct SASL [11] authentication mechanism.
   The ACAP server's registration might look like:

      service:acap://some.where.net;authentication=KERBEROSV4



Guttman, et al.             Standards Track                     [Page 8]

RFC 2609               Service Templates and URLs              June 1999


   Note that there can be other attributes of an ACAP server which are
   not appropriate to include in the URL. For instance, the list of
   users who have access to the server is useful for selecting an ACAP
   server, but is not required for a client to use the registered
   service.

   Attributes associated with the service: URL are not typically
   included in the service: URL. They are stored and retrieved using
   other mechanisms.  The service: URL is uniquely identified with a
   particular service agent or resource, and is used when registering or
   requesting the attribute information.  The Service Location Protocol
   specifies how such information is registered by network services and
   obtained by client software.

2.3. Use of service: URLs

   The service: URL is intended to allow arbitrary client/server and
   peer to peer systems to make use of a standardized dynamic service
   access point discovery mechanism.

   It is intended that service: URLs be selected according to the
   suitability of associated attributes.  A client application can
   obtain the URLs of several services of the same type and distinguish
   the most preferable among them by means of their attributes.  The
   client uses the service: URL to communicate directly to a service.

   Attributes are specified with a formal service template syntax
   described in Section 3.  If a service: URL registration includes
   attributes, the registering agent SHOULD also keep track of the
   attributes which characterize the service.

   Registrations can be checked against the formal attribute
   specification defined in the template by the client or agent
   representing the client.  Service registration are typically done
   using the Service Location Protocol [10] (SLP). SLP provides a
   mechanism for service: URLs to be obtained dynamically, according to
   the service's attributes.

   It is also possible to obtain service: URLs from documents and using
   other protocols.  In this case, the URL may not be accompanied by the
   service attributes.  The context in which the URL appears should make
   it clear, if possible, when the service is appropriate to use.  For
   example, in a mail message, a service might be recommended for use
   when the user is in a branch office.  Or, an HTML document might
   include a service: URL as a pointer to a service, describing in text
   what the service does and who is authorized to use it.





Guttman, et al.             Standards Track                     [Page 9]

RFC 2609               Service Templates and URLs              June 1999


2.4. Specifying the Service Type-Specific URL Syntax

   When a service type is specified, the specification includes the
   definition of the syntax for all URLs that are registered by services
   of that particular type.  For instance, the "lpr" service type may be
   defined with service: URLs in the following form:

      service:printer:lpr://<address of printer>/<queue name>

   The section of the URL after the address of the printer:

      "/" <queue name>

   is specific to the lpr service type and corresponds to the <url-path>
   field of the general service: URL syntax.  This part is specified
   when the lpr service type is specified.

2.5. Accommodating Abstract Service Types

   An abstract service type is a service type that can be implemented by
   a variety of different service agents.

   In order to register a service: URL for an abstract service type the
   'abstract-type' grammar rule described in section 3.1 is used.  This
   will result in a URL which includes enough information to use the
   service, namely, the protocol, address and path information.  Unlike
   'concrete' service: URLs, however, the service type is not enough to
   determine the service access.  Rather, an abstract service type
   denotes a class of service types.  The following subsection discusses
   this point in more detail.

   Concrete service templates inherit all attributes defined in the
   abstract service template from which the concrete service template
   was derived.  Attribute defined in the abstract service template MUST
   not be defined in the concrete service template as well.  This
   simplifies interpretation of templates.

   For example, if an abstract service template for service type '
   Abstract' defines an attribute FOO, all concrete service templates
   derived from the abstract service template, such as '
   Abstract:Concrete' will implicitly include the definition of
   attribute FOO. This derived template MUST NOT redefine FOO, according
   to the rule above.

   A further example is described in Section A.






Guttman, et al.             Standards Track                    [Page 10]

RFC 2609               Service Templates and URLs              June 1999


2.5.1. Advertising Abstract Service Types

   Some services may make use of several protocols that are in common
   use and are distinct services in their own right.  In these cases an
   abstract service type is appropriate.  What is essential is that all
   the required information for the service is clearly defined.

   For example, suppose a network service is being developed for
   dynamically loading device drivers.  The client requires the
   following three pieces of information before it can successfully load
   and instantiate the driver:

    1. The protocol used to load the driver code, for example, "ftp",
       "http" or "tftp"

    2. A pathname identifying where the driver code is located, for
       example "/systemhost/drivers/diskdrivers.drv",

    3. The name of the driver, for example, "scsi".

   The temptation is to form the first two items into a URL and embed
   that into a service: URL. As an example which should be avoided,

      service:ftp:/x3.bean.org/drivers/diskdrivers.drv;driver=scsi

   is a service: URL which seems to indicate where to obtain the driver.

   Rather, an abstract service-type SHOULD be used.  The service type is
   not "ftp", as the example indicates.  Rather, it is "device-drivers".
   The service: URL that should be used, consistent with the rules in
   section [6], is the following:

      service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv;
      driver=scsi;platform=sys3.2-rs3000

   Other URLs for the same service using other protocols are also
   supported, as in:

      service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv;
      driver=scsi;platform=sys3.2-rs3000

      service:device-drivers:http://www.bean.org/drivers/drivpak.drv;
      driver=scsi;platform=sys3.2-rs3000

   Using SLP, a search for the service type "device-drivers" may return
   all of the three URLs listed above.  The client selects the most
   appropriate access protocol for the desired resource.




Guttman, et al.             Standards Track                    [Page 11]

RFC 2609               Service Templates and URLs              June 1999


   The fundamental requirement is that the abstract service type MUST be
   well specified.  This requirement is imposed so that program code or
   human users have enough information to access the service.  In every
   case, a well-specified abstract type will include either an access
   protocol and a network address where the service is available, or an
   embedded URL for a standardized URL scheme that describes how to
   access the service.  In the example above, there are three further
   requirements:  A URL path is included for access protocols indicating
   the document to download, and two attributes are included to
   characterize the driver.

3. Syntax and Semantics of Service Type Specifications

   Service type specifications are documents in a formal syntax defining
   properties important to service registration.  These properties are:

    1. General information on the service type specification itself,

    2. The syntax of the service type-specific part of the service URL,

    3. The definition of attributes associated with a service.