rfc2609.txt

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

   The service type specification document is the service type template.

   The following subsections describe the syntax and semantics of
   service type templates.

3.1. Syntax of Service Type Templates

   Service template documents are encoded in a simple form.  They may be
   translated into any language or character set, but the template used
   for standardization MUST be encoded in the 0x00-0x7F subrange of
   UTF-8 [16] (which corresponds to ASCII character encoding) and be in
   English.

   A template document begins with a block of text assigning values to
   five document identification items.  The five identification items
   can appear in any order within the block, but conventionally the
   "template-type" item, which assigns the service type name, occurs at
   the very top of the document in order to provide context for the rest
   of the document.  The attribute definition item occurs after the
   document identification items.

   All items end with a blank line.  The reserved characters are ";",
   "%", "=", ",", "#", LF, and CR. Reserved characters MUST be escaped.
   The escape sequence is the same as described in [5].





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


   The service template is encoded in a UTF-8 character set, but
   submitted as a part of an work in progress, which is encoded in ASCII
   characters.  All characters which are outside of the ASCII range MUST
   be escaped using the `\' HEXDIG HEXDIG syntax.  For example, the
   letter e accent aigue would be represented as "\c3\a9".
   Unfortunately, this will detract from the readability of the service
   template in the service template submission.  Hopefully some public
   domain tools will emerge for translating escaped UTF-8 characters
   into humanly readable ones.

   Values in value lists are separated by commas.  A value list is
   terminated by a newline not preceded by a comma.  If the newline is
   preceded by a comma, the value list is interpreted to continue onto
   the next line.

   Attribute identifiers, attribute type names, and flags are all case
   insensitive.  For ease of presentation, upper and lower case
   characters can be used to represent these in the template document.
   Newlines are significant in the grammar.  They delimit one item from
   another, as well as separating parts of items internally.

   String values are considered to be a sequence of non-whitespace
   tokens potentially with embedded whitespace, separated from each
   other by whitespace.  Commas delimit lists of strings.  String values
   are trimmed so as to reduce any sequence of white space interior to a
   string to a single white space.  Preceding or trailing white space is
   removed.  For example:

         " some value , another example "

      is trimmed to

         "some value" and "another example".

   Note that there can be no ambiguity in string tokenization because
   values in value lists are separated by a comma.  String tokens are
   not delimited by double quotes (") as is usually the case with
   programming languages.

   Attribute tags and values are useful for directory look-up.  In this
   case, decoding of character escapes and trimming white space MUST be
   performed before string matching.  In addition, string matching
   SHOULD be case insensitive.








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


   Templates obey the following ABNF [8] grammar:

      template      =  tem-attrs attr-defs
      tem-attrs     =  schemetype schemevers schemetext schemeurl
      schemetype    =  "template-type=" scheme term
      schemevers    =  "template-version=" version-no term
      schemetext    =  "template-description=" newline desc term
      schemeurl     =  "template-url-syntax=" newline url-bnf term
      url-bnf       =  *[ com-chars ]
                       ; An ABNF describing the <url-path> production
                       ; in the service: URL grammar of Section 2.1.
      scheme        =  service-type [ "." naming-auth ]
      service-type  =  scheme-name
      naming-auth   =  scheme-name
      scheme-name   =  ALPHA [1*schemechar] [ "." 1*schemechar ]
      schemechar    =  ALPHA / DIGIT / "-" / "+" /
      version-no    =  1*DIGIT "." 1*DIGIT
      langtag       =  1*8ALPHA ["-" 1*8ALPHA]
                       ; See [3]
      desc          =  *[ com-chars ]
                       ; A block of free-form text for reading by
                       ; people describing the service in a short,
                       ; informative manner.
      term          =  newline newline
      attr-defs     =  *( attr-def / keydef )
      attr-def      =  id "=" attrtail
      keydef        =  id "=" "keyword" newline [help-text] newline
      attrtail      =  type flags newline [value-list] [help-text]
                       [value-list] newline
      id            =  1*attrchar
      type          =  "string" / "integer" / "boolean" / "opaque"
      flags         =  ["m"/"M"] ["l"/"L"] ["o"/"O"] ["x"/"X"]
      value-list    =  value newline / value "," value-list /
                       value "," newline value-list
      help-text     =  1*( "#" help-line )
                       ; A block of free-form text for reading by
                       ; people describing the attribute and
                       ; its values.
      help-line     =  *[ com-chars ] newline
      attrchar      =  schemechar / ":" / "_" / "$" / "~" / "@" / "." /
                       "|" / "<" / ">" / "*" / "&"
      value         =  string / integer / boolean / opaque
      string        =  safe-char *[safe-char / white-sp] safe-char
      integer       =  [ "+" | "-" ] 1*DIGIT
      boolean       =  "true" / "false"
      opaque        =  "\FF" 1*( "\" HEXDIG HEXDIG)
                       ; Each byte of opaque value is hex encoded.
                       ; The format corresponds to [10].



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


                       ; Newlines are ignored in decoding opaque
                       ; values.
      com-chars     =  safe-char / white-sp / "," / ";"/ "%"
      safe-char     =  attrchar / escaped / " " / "!" / '"' / "'" /
                       "|" / "(" / ")" / "+" / "-" / "." / ":" /
                       "=" / "?" / "[" / "]" / "{" / "/" / "{" /
                       "$"
                       ; All UTF-8 printable characters are
                       ; included except ",", "%", ";", and "#".
      escaped       =  1*(`\' HEXDIG HEXDIG)
      white-sp      =  SPACE / HT
      newline       =  CR / ( CR LF )

3.2. Semantics of Service Type Templates

   The service type template defines the service attributes and service:
   URL syntax for a particular service type.  The attribute definition
   includes the attribute type, default values, allowed values and other
   information.

   Note that the 'template-type', 'template-version', 'template-
   description' and 'template-url-syntax' have all been defined as
   attributes.  These attributes MAY accompany any service registration
   using SLPv2.

3.2.1. Definition of a Service Template

   There are four items included in the service template.  The semantics
   of each item is summarized below.

    -  template-type

       The scheme name of the service scheme.  The scheme name consists
       of the service type name and an optional naming authority name,
       separated from the service type name by a period.  See 3.2.2 for
       the conventions governing service type names.

    -  template-version

       The version number of the service type specification.

    -  template-description

       A description of the service suitable for inclusion in text read
       by people.






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


    -  template-url-syntax

       The syntax of the service type-specific URL part of the service:
       URL.

    -  attribute definitions

       A collection of zero or more definitions for attributes
       associated with the service in service registrations.

   Each of the following subsections deals with one of these items.

3.2.2. Service Type

   The service scheme consists of the service type name and an optional
   naming authority name separated from the service type name by a
   period.  The service scheme is a string that is appended to the '
   service:'  URL scheme identifier, and is the value of the "template-
   type" item in the template document.  If the naming authority name is
   absent it is assumed to be IANA.

3.2.3. Version Number

   The version number of the service type template is the value of the
   "template-version" item.  A draft proposal starts at 0.0, and the
   minor number increments once per revision.  A standardized template
   starts at 1.0.  Additions of optional attributes add one to the minor
   number, and additions of required attributes, changes of definition,
   or removal of attributes add one to the major number.  The intent is
   that an old service template still accurately, if incompletely,
   defines the attributes of a service registration if the template only
   differs from the registration in its minor version.  See Section 4
   for more detail on how to use the template-version attribute.

3.2.4. Description

   The description is a block of text readable by people in the language
   of the template and is the value of the "template-description" item.
   It should be sufficient to identify the service to human readers and
   provide a short, informative description of what the service does.

   If the service type corresponds to a particular protocol, the
   protocol specification must be cited here.  The protocol need not be
   a standardized protocol.  The template might refer to a proprietary
   specification, and refer the reader of the template to a contact
   person for further information.





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


3.2.5. Syntax of the Service Type-specific URL Part

   The syntax of the service type-specific part of the service:  URL is
   provided in the template document as the value of the "template-url-
   syntax" item.  The <url-path> field of the service:  URL is designed
   to provide additional information to locate a service when the
   <addr-spec> field is not sufficient.  The <url-path> field
   distinguishes URLs of a particular service type from those of another
   service type.  For instance, in the case of the lpr service type, the
   <url-path> may be defined so that it must include the queue name, but
   other service types may not require this information.

   The syntax for the <url-path> field MUST accompany the definition of
   a new service type, unless the URL scheme has already been
   standardized and is not a service: URL. The syntax is included in the
   template document as an ABNF [8] following the rules for URL syntax
   described in [5].  There is no requirement for a service scheme to
   support a <url-path>.  The <url-path> field can be very simple, or
   even omitted.  If the URL scheme has already been standardized, the
   "template-url-syntax" item SHOULD include a reference to the
   appropriate standardization documents.  Abstract service types may
   defer this field to the template documents describing their concrete
   instances.

3.2.6. Attribute Definition

   The bulk of the template is typically devoted to defining service
   type-specific attributes.  An attribute definition precisely
   specifies the attribute's type, other restrictions on the attribute
   (whether it is multi-valued, optional, etc), some text readable by
   people describing the attribute, and lists of default and allowed
   values.  The only required information is the attribute's type, the
   rest are optional.  Registration, deregistration and the use of
   attributes in queries can be accomplished using the Service Location
   Protocol [10] or other means, and discussion of this is beyond the
   scope of the document.

   Attributes are used to convey information about a given service for
   purposes of differentiating different services of the same type.
   They convey information to be used in the selection of a particular
   service to establish communicate with, either through a program
   offering a human interface or programmatically.  Attributes can be
   encoded in different character sets and in different languages.  The
   procedure for doing this is described in Section 6.

   An attribute definition begins with the specification of the
   attribute's identifier and ends with a single empty line.  Attributes
   definitions have five components (in order of appearance in a



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


   definition):

    1. An attribute identifier which acts as the name of the attribute,

    2. Attribute descriptors (type and flags),

    3. An optional list of values which are assigned to the attribute by
       default,