rfc2609.txt

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

    4. An optional block of text readable by people providing a short,
       informative description of the attribute,

    5. An optional list of allowed values which restrict the value or
       values the attribute can take on.

3.2.6.1. The Attribute Identifier

   An attribute definition starts with the specification of the
   attribute's identifier.  The attribute's identifier functions as the
   name of the attribute.  Note that the characters used to compose an
   attribute identifier are restricted to those characters considered
   unrestricted for inclusion in a URL according to [5].  The reason is
   that services can display prominent attributes in their service:  URL
   registrations.  Each attribute identifier must be unique in the
   template.  Since identifiers are case folded, upper case and lower
   case characters are the same.

3.2.6.2. The Attribute Type

   Attributes can have one of five different types:  string, integer,
   boolean, opaque, or keyword.  The attribute's type specification is
   separated from the attribute's identifier by an equal sign ("=") and
   follows the equal sign on the same line.  The string, signed integer,
   and boolean types have the standard programming language or database
   semantics.  Integers are restricted to those signed values that can
   be represented in 32 bits.  The character set used to represent
   strings is not specified at the time the template is defined, but
   rather is determined by the service registration.  Booleans have the
   standard syntax.  Opaques are byte escaped values that can be used to
   represent any other kind of data.  Keywords are attributes that have
   no characteristics other than their existence (and possibly the
   descriptive text in their definition).

   Keyword and boolean attributes impose restrictions on the following
   parts of the attribute definition.  Keyword attribute definitions
   MUST have no flag information following the type definition, nor any
   default or allowed values list.  Boolean attributes are single value
   only, i.e., multi-valued boolean attributes are not allowed.



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


3.2.6.3. Attribute Flags

   Flags determine other characteristics of an attribute.  With the
   exception of keyword attributes, which may not have any flags, flags
   follow the attribute type on the same line as the attribute
   identifier, and are separated from each other by whitespace.  Flags
   may appear in any order after the attribute type.  Other information
   must not follow the flags, and only one flag identifier of a
   particular flag type is allowed per attribute definition.

   The semantics of the flags are as follows:

    -  o or O

       Indicates that the attribute is optional.  If this flag is
       missing, the attribute is required in every service registration.

    -  m or M

       Indicates that the attribute can take on multiple values.  If
       this flag is present, every value in a multi-valued attribute
       has the same type as the type specified in the type part of the
       attribute definition.  Boolean attributes must not include this
       flag.

    -  l or L

       Indicates that attribute is literal, i.e.  is not meant to be
       translated into other languages.  If this flag is present, the
       attribute is not considered to be readable by people and should
       not be translated when the template is translated.  See Section 6
       for more information about translation.

    -  x or X

       Indicates that clients SHOULD include the indicated attribute
       in requests for services.  Neglecting to include this attribute
       will not sufficiently differentiate the service.  If services are
       obtained without selecting this attribute they will quite likely
       be useless to the client.

   The values for multivalued attributes are an unordered set.
   Deletions of individual values from a multivalued attribute are not
   supported, and deletion of the attribute causes the entire set of
   values to be removed.






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


3.2.6.4. Default Value or List

   If the attribute definition includes a default value or, in the case
   of multivalued attributes, a default values list, it begins on the
   second line of the attribute definition and continues over the
   following lines until a line ends without a comma.  As a consequence,
   newlines cannot be embedded in values unless escaped.  See Section
   2.1.

   Particular attribute types and definitions restrict the default
   values list.  Keyword attributes must not have a list of defaults.
   If an optional attribute's definition has an allowed values list,
   then a default value or list is not optional but required.  The
   motivation for this is that defining an attribute with an allowed
   values list is meant to restrict the values the attribute can take
   on, and requiring a default value or list assures that the default
   value is a member of the given set of allowed values.

   The default value or list indicates what values the attribute is
   given if no values are assigned to the attribute when a service is
   registered.  If an optional attribute's definition includes no
   default value or list, the following defaults are assigned:

    1. String values are assigned the empty string,

    2. Integer values are assigned zero,

    3. Boolean values are assigned false,

    4. Opaque values are assigned a byte array containing no values,

    5. Multi-valued attributes are initialized with a single value.

   For purposes of translating nonliteral attributes, the default values
   list is taken to be an ordered set, and translations MUST maintain
   that order.

3.2.6.5. Descriptive Text

   Immediately after the default values list, if any, a block of
   descriptive text SHOULD be included in the attribute definition.
   This text is meant to be readable by people, and should include a
   short, informative description of the attribute.  It may also provide
   additional information, such as a description of the allowed values.
   This text is primarily designed for display by interactive browsing
   tools.  The descriptive text is set off from the surrounding
   definition by a crosshatch character ("#") at the beginning of the
   line.  The text should not, however, be treated as a comment by



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


   parsing and other tools, since it is an integral part of the
   attribute definition.  Within the block of descriptive text, the text
   is transferred verbatim, including indentation and line breaks, so
   any formatting is preserved.

3.2.6.6. Allowed Values List

   Finally, the attribute definition concludes with an optional allowed
   values list.  The allowed values list, if any, follows the
   descriptive text, or, if the descriptive text is absent, the initial
   values list.  The syntax of the allowed values list is identical to
   that of the initial values list.  The allowed values list is also
   terminated by a line that does not end in a comma.  If the allowed
   values list is present, assignment to attributes is restricted to
   members of the list.

   As with the default values list, the allowed values list is also
   considered to be an ordered set for purposes of translation.

3.2.6.7. Conclusion of An Attribute Definition

   An attribute definition concludes with a single empty line.

4. A Process For Standardizing New Service Types

   New service types can be suggested simply by providing a service type
   template and a short description about how to use the service.  The
   template MUST have its "template-version" template attribute set to
   0.0.

   MAJOR revision numbers come before the '.', MINOR revision numbers
   come after the '.'.

   The minor version number increments once with each change until it
   achieves 1.0.  There is no guarantee any version of the service
   template is backward compatible before it reaches 1.0.

   Once a service template has reached 1.0, the definition is "frozen"
   for that version.  New templates must be defined, of course, to
   refine that definition, but the following rules must be followed:

   A MINOR revision number signifies the introduction of a compatible
   change.  A MAJOR revision number signifies the introduction of an
   incompatible change.  This is formalized by the following rules:

    -  Any new optional attribute defined for the template increases
       the minor version number by one.  All other attributes for the
       version must continue to be supported as before.  A client which



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


       supports 1.x can still use later versions of 1.y (where x<y) as
       it ignores attributes it doesn't know about.

    -  Adding a required attribute, removing support for an attribute
       or changing definition of an attribute requires changing the
       major version number of a service template.  A client application
       may be unable to make use of this information, or it may need
       to obtain the most recent service template to help the user
       interpret the service information.

   The template is submitted to a special mailing list, see section 5.
   This document must include a 'template begins here' and 'template
   ends here' marking, in text, so that it is trivial to cut and paste
   the template from the submission.

   The list will be available at [e-mail].  Ideally, experts
   in the implementation and deployment of the particular protocol are
   consulted so as to add or delete attributes or change their
   definition to make the template as useful as possible.  The mailing
   list will be maintained even when the SVRLOC WG goes dormant for the
   purpose of discussing service templates.

   All published versions of the template must be available on-line,
   including obsolete ones.

   Once consensus is achieved, the template should be reissued with
   possible corrections, having its Version number set to 1.0.
   Templates with version numbers below 1.0 are not submitted to the
   IANA. From that point onwards, templates are submitted.  See Section
   5 for details on how templates are submitted to an IANA registry of
   templates.

5. IANA Considerations

   It is the responsibility of the IESG (e.g., Applications Area
   director) to appoint a Designated Expert (see [12].)  Anyone may ask
   for clarification of a service template.  This is to solicit input
   from the concerned community.  It is up to the appointed reviewer to
   determine whether clarification requests are satisfied.  It is the
   reviewer's responsibility to see that all reasonable clarification
   requests are met before the template is submitted for inclusion in
   the IANA registry.

   When the reviewer has determined that the template submission is
   ready, he or she will submit the template to the IANA for inclusion
   in a registry.  Mailing list participants supply input to the process
   but do not make the decision whether to accept a service template.




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


   If a dispute arises over the decisions made by the reviewer, the
   matter may be appealed according to normal IETF procedure as
   described for the Standards Track process.

   The IANA will maintain a mail forwarding alias for the work of this
   list, so that "[e-mail]" points to a mail server supplied
   by a volunteer organization.

   The service template submission MUST be of the form:

      Name of submitter:
      Language of service template:
      Security Considerations:
      Template Text:
      ----------------------template begins here-----------------------
                                    . . .
      -----------------------template ends here------------------------

   The service template file has a naming convention:

   <service-type> "." <version-no> "." <langtag>

   Each of these fields are defined in Section 2.  They correspond to
   the values of the template fields "type", "template-version".  The
   files for the example templates in this document (see Section A) are
   called:

       "foo.0.0.en",
       "Net-Transducer.0.0.en",
       "Net-Transducer:Thermometer.0.0.de" and
       "Net-Transducer:Thermomoter.0.0.en".

   The reviewer will ensure that the template submission to IANA has the
   correct form and required fields.

   No service type template will be accepted for inclusion in the
   service template registry unless the submission includes a security
   considerations section and contact information for the template
   document author.

   The IANA will maintain a registry containing both the service type
   templates, and the template description document containing the
   service type template, including all previous versions.  The IANA
   will receive notice to include a service template in the registry
   by email from the reviewer.  This message will include the service
   template itself, which is to be registered.