rfc2614.txt

RFC 的详细文档！

         The attributes associated with a given service.  The values
         that can be assigned to service attributes are defined by the
         service template.

      Scope

         A string used to control the availability of service
         advertisements.  Every SLP Agent is configured with one or more
         scope strings.  Scopes are assigned by site administrators to
         group services for many purposes, but chiefly as a means of
         scalability.  DAs store only services advertised having a scope
         string matching the scopes with which they are configured.

      Naming Authority (NA)

         This is a 'suffix' to the service type string.  It completely
         changes the meaning of the service type.  NAs are used for
         private definitions of well known Service Types and
         experimental Service Type extensions.  The default NA is
         "IANA", which must not be explicitly included.  Service types
         with the IANA naming authority are registered with the Internet
         Assigned Numbers Authority (see [8] for more information on the
         registration procedure).





Kempf & Guttman              Informational                      [Page 6]

RFC 2614                  Service Location API                 June 1999


2. File Formats

   This section describes the configuration and serialized registration
   file formats.  Both files are defined in the UTF-8 character set [3].

   Attribute tags and values in the serialized registration file require
   SLP reserved characters to be escaped.  The SLP reserved characters
   are `(', `)', `,', `\', `!', `<', `=', `>', `~' and control
   characters (characters with UTF codes less than 0x0020 and the
   character 0x007f, which is US-ASCII DEL). The escapes are formed
   exactly as for the wire protocol, i.e.  a backslash followed by two
   hex digits representing the character.  For example, the escape for '
   ,' is '\2c'.  In addition, the characters `\n', `\r', `\t', and `_'
   are prohibited from attribute tags by the SLP wire syntax grammar.
   [7]

   In serialized registration files, escaped strings beginning with
   `\ff`, an encoding for a nonUTF-8 character, are treated as opaques.
   Exactly as in the wire protocol, syntactically correct opaque
   encodings consist of a string beginning with `\ff` and containing
   *only* escaped characters that are transformed to bytes.  Such
   strings are only syntactically correct in the serialized registration
   file as attribute values.  In other cases, whenever an escape is
   encountered and the character is not an SLP reserved character, an
   error is signaled.

   Escaped characters in URLs in serialized registration files use the
   URL escape convention. [2].

   Property names and values in the configuration file have a few
   reserved characters that are involved in file's lexical definition.
   The characters '.'  and '=' are reserved in property names and must
   be escape.  The characters ',', '(', and ')' are reserved in property
   values and must be escaped.  In addition, scope names in the
   net.slp.useScopes property use the SLP wire format escape convention
   for SLP reserved characters.  This simplifies implementation, since
   the same code can be used to unescape scope names as is used in
   processing the serialized registration file or for formatting wire
   messages.

   On platforms that only support US-ASCII and not UTF-8, the upper bit
   of bytes incoming from the configuration and registration files
   determines whether the character is US-ASCII or not US-ASCII.
   According to the standard UTF-8 encoding, the upper bit is zero if
   the character is US-ASCII and one if the character is multibyte and
   thus not US-ASCII. Platforms without intrinsic UTF-8 support are
   required to parse the multibyte character and store it in an
   appropriate internal format.  Support for UTF-8 is required to



Kempf & Guttman              Informational                      [Page 7]

RFC 2614                  Service Location API                 June 1999


   implement the SLP protocol (see [7]), and can therefore be used in
   file processing as well.

   The location and name of the configuration file is system-dependent,
   but implementations of the API are encouraged to locate it together
   with other configuration files and name it consistently.

2.1. Configuration File Format

   The configuration file format consists of a newline delimited list of
   zero or more property definitions.  Each property definition
   corresponds to a particular configurable SLP, network, or other
   parameter in one or more of the three SLP agents.  The file format
   grammar in ABNF [5] syntax is:

      config-file   =  line-list
      line-list     =  line / line line-list
      line          =  property-line / comment-line
      comment-line  =  ( "#" / ";" ) 1*allchar newline
      property-line =  property newline
      property      =  tag "=" value-list
      tag           =  prop / prop "." tag
      prop          =  1*tagchar
      value-list    =  value / value "," value-list
      value         =  int / bool /
                       "(" value-list ")" / string
      int           =  1*DIGIT
      bool          =  "true" / "false" / "TRUE" / "FALSE"
      newline       =  CR / ( CRLF )
      string        =  1*stringchar
      tagchar       =  DIGIT / ALPHA / tother / escape
      tother        =  %x21-%x2d / %x2f /
                       %x3a / %x3c-%x40 /
                       %x5b-%x60 / %7b-%7e
                       ; i.e., all characters except `.',
                       ; and `='.
      stringchar    =  DIGIT / ALPHA / sother / escape
      sother        =  %x21-%x29 / %x2a-%x2b /
                       %x2d-%x2f / %x3a-%x40 /
                       %x5b-%x60 / %7b-%7e
                       ; i.e., all characters except `,'
      allchar       =  DIGIT / ALPHA / HTAB / SP
      escape        =  "\" HEXDIG HEXDIG
                       ; Used for reserved characters

   With the exception of net.slp.useScopes, net.slp.DAAddresses, and
   net.slp.isBroadcastOnly, all other properties can be changed through
   property accessors in the C and Java APIs.  The property accessors



Kempf & Guttman              Informational                      [Page 8]

RFC 2614                  Service Location API                 June 1999


   only change the property values in the running agent program and do
   not affect the values in the configuration file.  The
   net.slp.useScopes and net.slp.DAAddresses properties are read-only
   because they control the agent's view of the scopes and DAs and are
   therefore critical to the function of the API scope discovery
   algorithm.  Attempts to modify them are unlikely to yield productive
   results, and could harm the ability of the agent to find scopes and
   use DAs.  The net.slp.isBroadcastOnly property is read-only because
   the API library needs to configure networking upon start up and
   changing this property might invalidate the configuration.  Whether
   the local network uses broadcast or multicast is not likely to change
   during the course of the program's execution.

   The properties break down into the following subsections describes an
   area and its properties.

2.1.1. DA configuration

   Important configuration properties for DAs are included in this
   section.  These are:

      net.slp.isDA

         A boolean indicating if the SLP server is to act as a DA. If
         false, not run as a DA. Default is false.

      net.slp.DAHeartBeat

         A 32 bit integer giving the number of seconds for the
         DA heartbeat.  Default is 3 hours (10800 seconds).  This
         property corresponds to the protocol specification parameter
         CONFIG_DA_BEAT [7].  Ignored if isDA is false.

      net.slp.DAAttributes

         A comma-separated list of parenthesized attribute/value list
         pairs that the DA must advertise in DAAdverts.  The property
         must be in the SLP attribute list wire format, including
         escapes for reserved characters. [7]

2.1.2. Static Scope Configuration

   These properties allow various aspects of scope handling to be
   configured.







Kempf & Guttman              Informational                      [Page 9]

RFC 2614                  Service Location API                 June 1999


      net.slp.useScopes

         A value-list of strings indicating the only scopes a UA or SA
         is allowed to use when making requests or registering, or the
         scopes a DA must support.  If not present for the DA and SA,
         then in the absence of scope information from DHCP, the default
         scope "DEFAULT" is used.  If not present for the UA, and there
         is no scope information available from DHCP, then the user
         scoping model is in force.  Active and passive DA discovery
         or SA discovery are used for scope discovery, and the scope
         "DEFAULT" is used if no other information is available.  If a
         DA or SA gets another scope in a request, a SCOPE_NOT_SUPPORTED
         error should be returned, unless the request was multicast, in
         which case it should be dropped.  If a DA gets another scope in
         a registration, a SCOPE_NOT_SUPPORTED error must be returned.
         Unlike other properties, this property is "read-only", so
         attempts to change it after the configuration file has been
         read are ignored.  See Section 3.12 for the algorithm the API
         uses in determining what scope information to present.

      net.slp.DAAddresses

         A value-list of IP addresses or DNS resolvable host names
         giving the SLPv2 DAs to use for statically configured UAs and
         SAs.  Ignored by DAs (unless the DA is also an SA server).
         Default is none.  Unlike other properties, this property is
         "read-only", so attempts to change it after the configuration
         file has been read are ignored.

         The following grammar describes the property:


               addr-list     =  addr / addr "," addr-list
               addr          =  fqdn / hostnumber
               fqdn          =  ALPHA / ALPHA *[ anum / "-" ] anum
               anum          =  ALPHA / DIGIT
               hostnumber    =  1*3DIGIT 3("." 1*3DIGIT)


         An example is:


                sawah,mandi,sambal


         IP addresses can be used instead of host names in networks
         where DNS is not deployed, but network administrators are
         reminded that using IP addresses will complicate machine



Kempf & Guttman              Informational                     [Page 10]

RFC 2614                  Service Location API                 June 1999


         renumbering, since the SLP configuration property files
         in statically configured networks will have to be changed.
         Similarly, if host names are used, implementors must be careful
         that a name service is available before SLP starts, in other
         words, SLP cannot be used to find the name service.

2.1.3. Tracing and Logging

   This section allows tracing and logging information to be printed by
   the various agents.

      net.slp.traceDATraffic

         A boolean controlling printing of messages about traffic with
         DAs.  Default is false.

      net.slp.traceMsg

         A boolean controlling printing of details on SLP messages.
         The fields in all incoming messages and outgoing replies are
         printed.  Default is false.

      net.slp.traceDrop

         A boolean controlling printing details when a SLP message is
         dropped for any reason.  Default is false.

      net.slp.traceReg

         A boolean controlling dumps of all registered services upon
         registration and deregistration.  If true, the contents
         of the DA or SA server are dumped after a registration or
         deregistration occurs.  Default is false.

2.1.4. Serialized Proxy Registrations

   These properties control the reading and writing of serialized
   registrations.

      net.slp.serializedRegURL

         A string containing a URL pointing to a document containing
         serialized registrations that should be processed when the DA
         or SA server starts up.  Default is none.







Kempf & Guttman              Informational                     [Page 11]