rfc2609.txt

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

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


   Neither the reviewer nor the IANA will take any position on claims of
   copyright or trademark issues with regard to templates.

6. Internationalization Considerations

   The service: URL must be encoded using the rules set forth in [5].
   The character set encoding is limited to specific ranges within the
   US-ASCII character set [4].

   The template is encoded in UTF-8 characters.

6.1. Language Identification and Translation

   The language used in attribute strings should be identified supplying
   a Language Tag [3] in the Service Template submission (see Section
   5).

   A program can translate a service registration from one language to
   another provided it has both the template of the language for the
   registration and the template of the desired target language.  All
   standardized attributes are in the same order in both templates.  All
   non-arbitrary strings, including the descriptive help text, is
   directly translatable from one language to another.  Non-literal
   attribute definitions, attribute identifiers, attribute type names,
   attribute flags, and the boolean constants "true" and "false" are
   never translated.  Translation of attribute identifiers is prohibited
   because, as with domain names, they can potentially be part of a
   service: URL and therefore their character set is restricted.  In
   addition, as with variable identifiers in programming languages, they
   could become embedded into program code.

   All strings used in attribute values are assumed translatable unless
   explicitly defined as being literal, so that best effort translation
   (see below) does not modify strings which are meant to be interpreted
   by a program, not a person.

   An example of a translated service template is included in Section A.

   There are two ways to go about translation:  standardization and best
   effort.

   When the service type is standardized, more than one document can be
   submitted for review.  One service type description is approved as a
   master, so that when a service type template is updated in one
   language, all the translations (at least eventually) reflect the same
   semantics.





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


   If no document exists describing the standard translation of the
   service type, a 'best effort' translation for strings should be done.

7. Security Considerations

   Service type templates provide information that is used to interpret
   information obtained by the Service Location Protocol.  If these
   templates are modified or false templates are distributed, services
   may not correctly register themselves, or clients might not be able
   to interpret service information.

   The service: URLs themselves specify the service access point and
   protocol for a particular service type.  These service: URLs could be
   distributed and indicate the location of a service other than that
   normally want to used.  The Service Location Protocol [10]
   distributes service: URLs and has an authentication mechanism that
   allows service: URLs of registered services to be signed and for the
   signatures to be verified by clients.

   Each Service Template will include a security considerations section
   which will describe security issues with using the service scheme for
   the specific Service Type.





























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


A. Service Template Examples

   The text in the template example sections is to be taken as being a
   single file.  They are completely fictitious (ie.  the examples do
   not represent real services).

   The FOO example shows how to use service templates for an application
   that has very few attributes.  Clients request the FOO server where
   their user data is located by including their user name as the value
   of the user attribute.

   The Net-Transducer example shows how abstract service types are
   defined and how a corresponding concrete instance is defined.  A
   system might support any of several NetTransducer services.  Here we
   give only one concrete instance of the abstract type.

   It is not necessary to register concrete templates for an abstract
   service type if the abstract service type template is completely
   clear as to what possible values can be used as a concrete type, and
   what their interpretation is.

A.1. FOO

   The FOO service template submission example follows:

  Name of submitter: "Erik Guttman" <[e-mail]>
  Language of service template: en
  Security Considerations:
    If the USER and GROUPS attributes are included a
    possibility exists that the list of identities for users or groups
    can be discovered. This information would otherwise be difficult
    to discover.

  Template Text:
  -------------------------template begins here-----------------------
  template-type=FOO

  template-version=0.0

  template-description=
    The FOO service URL provides the location of an FOO service.

  template-url-syntax=
    url-path= ; There is no URL path defined for a FOO URL.

  users= string M L O
  # The list of all users which the FOO server supports.




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


  groups= string M L O
  # The list of all groups which the FOO server supports.
  --------------------------template ends here------------------------

   This template could be internationalized by registering another
   version, say in German:

  Name of submitter: "Erik Guttman" <[e-mail]>
  Language of service template: de
  Security Considerations:
    Wenn die USER und GROUPS Eigenschaften inbegriffen sind,
    besteht die Moeglichkeit, dass die Liste der Identitaeten
    von Benutzern oder Gruppen endeckt werden kann.  Diese
    Information wurde unter anderen Umstaenden schwierig zu
    entdecken sein.

  Template Text:
  -------------------------template begins here-----------------------
  template-type=FOO

  template-version=0.0

  template-description=
    Der FOO Service URL zeigt die Stelle von einem Foo Service an.

  template-url-syntax=
    url-path= ; Es gibt keinen fuer den FOO URL definierten Pfad.

  users= string M L O
  # Die Liste aller Users, die der FOO Server unterstuetzt.

  groups= string M L O
  # Die Liste aller Gruppen, die der FOO Server unterstuetzt.
  --------------------------template ends here------------------------

   Note that the attribute tags are not translated.  If translations
   are desired, the suggested convention for doing so is to define a
   separate attribute called localize-<tag> for each attribute tag which
   is to be localized.  This will aid in displaying the attribute tags
   in a human interface.

   For example, in this case above, the following two attributes could
   be defined:

  localize-users= string
  Benutzer

  localize-groups= string



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


  Gruppen

   The attributes (in SLPv2 attribute list format) for a service
   registration of a FOO service based on this template, in German,
   could be:

  (users=Hans,Fritz),(groups=Verwaltung,Finanzbuchhaltung),
  (template-type=FOO),(template-version=0.0),(template-description=
    Der FOO Service URL zeigt die Stelle von einem Foo Service an.),
  (template-url-syntax= \OD url-path= ; Es gibt kein fuer den FOO
   URL definiert Pfad. \OD),(localize-users=Benutzer),
  (localize-groups=Gruppen)

   Anyone obtaining these attributes could display "Benutzer=Hans,Fritz"
   in a human interface using the included information.  Note that the
   template attributes have been included in this registration.  This is
   OPTIONAL, but makes it possible to discover which template was used
   to register the service.

A.2. Abstract Service Type:  Net-Transducer

   An example submission of an abstract service type template is:

  Name of submitter: "Erik Guttman" <[e-mail]>
  Language of service template: en
  Security Considerations:
    See the security considerations of the concrete service types.

  Template Text:
  -------------------------template begins here-----------------------
  template-type=Net-Transducer

  template-version=0.0

  template-description=
    This is an abstract service type.  The purpose of the Net-
    Transducer service type is to organize into a single category
    all network enabled Transducers which have certain properties.

  template-url-syntax=
    url-path=  ;  Depends on the concrete service type.
               ;  See these templates.

  sample-units= string L
  # The units of sample that the Transducer provides, for instance
  # C (degrees Celsius), V (Volts), kg (Kilograms), etc.

  sample-resolution= string L



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


  # The resolution of the Transducer.  For instance, 10^-3 means
  # that the Transducer has resolution to 0.001 unit.

  sample-rate= integer L
  # The speed at which samples are obtained per second.  For
  # instance 1000 means that one sample is obtained every millisecond.

  --------------------------template ends here------------------------

A.3. Concrete Service Type:  Net-Transducer:Thermometer

   This is another service template submission example, supplying a
   concrete service type corresponding to the abstract template above.

  Name of submitter: "Erik Guttman" <[e-mail]>
  Language of service template: en
  Security Considerations:
    There is no authentication of the Transducer output.  Thus,
    the Thermometer output could easily be spoofed.

  Template Text:
  -------------------------template begins here-----------------------
  template-type=service:Net-Transducer:Thermometer

  template-version=0.0

  template-description=
    The Thermometer is a Net-Transducer capable of reading temperature.
    The data is read by opening a TCP connection to one of the ports
    in the service URL and reading an ASCII string until an NULL
    character is encountered.  The client may continue reading data at
    no faster than the sample-rate, or close the connection.

  template-url-syntax=
    url-path     = "ports=" ports-list
    port-list    = port