rfc2609.txt

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

Network Working Group                                        E. Guttman
Request for Comments: 2609                                   C. Perkins
Updates: 2165                                                  J. Kempf
Category: Standards Track                              Sun Microsystems
                                                              June 1999


                 Service Templates and Service: Schemes

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The "service:" URL scheme name is used to define URLs (called
   "service: URLs" in this document) that are primarily intended to be
   used by the Service Location Protocol in order to distribute service
   access information.  These schemes provide an extensible framework
   for client-based network software to obtain configuration information
   required to make use of network services.  When registering a
   service: URL, the URL is accompanied by a set of well-defined
   attributes which define the service.  These attributes convey
   configuration information to client software, or service
   characteristics meaningful to end users.

   This document describes a formal procedure for defining and
   standardizing new service types and attributes for use with the
   "service:" scheme.  The formal descriptions of service types and
   attributes are templates that are human and machine understandable.
   They SHOULD be used by administrative tools to parse service
   registration information and by client applications to provide
   localized translations of service attribute strings.










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


Table of Contents

    1. Introduction                                                    2
        1.1. Terminology  . . . . . . . . . . . . . . . . . . . . .    3
        1.2. Service Location Protocol  . . . . . . . . . . . . . .    5
              1.2.1. Compatibility with SLPv1 . . . . . . . . . . .    5
    2. Service URL Syntax and Semantics                                5
        2.1. Service URL Syntax   . . . . . . . . . . . . . . . . .    5
        2.2. Service URL Semantics  . . . . . . . . . . . . . . . .    8
        2.3. Use of service: URLs   . . . . . . . . . . . . . . . .    9
        2.4. Specifying the Service Type-Specific URL Syntax. . . .   10
        2.5. Accommodating Abstract Service Types   . . . . . . . .   10
              2.5.1. Advertising Abstract Service Types . . . . . .   11
    3. Syntax and Semantics of Service Type Specifications            12
        3.1. Syntax of Service Type Templates   . . . . . . . . . .   12
        3.2. Semantics of Service Type Templates. . . . . . . . . .   15
              3.2.1. Definition of a Service Template . . . . . . .   15
              3.2.2. Service Type . . . . . . . . . . . . . . . . .   16
              3.2.3. Version Number . . . . . . . . . . . . . . . .   16
              3.2.4. Description  . . . . . . . . . . . . . . . . .   16
              3.2.5. Syntax of the Service Type-specific URL Part .   17
              3.2.6. Attribute Definition   . . . . . . . . . . . .   17
    4. A Process For Standardizing New Service Types                  21
    5. IANA Considerations                                            22
    6. Internationalization Considerations                            24
        6.1. Language Identification and Translation. . . . . . . .   24
    7. Security Considerations                                        25
    A. Service Template Examples                                      26
        A.1. FOO . . . . . . . . . . . . . . . . . .. . . . . . . .   26
        A.2. Abstract Service Type:  Net-Transducer . . . . . . . .   28
        A.3. Concrete Service Type:  Net-Transducer:Thermometer . .   29
        A.4. service: URLs and SLP  . . . . . . . . . . . . . . . .   30
    B. Acknowledgments                                                30
    C. References                                                     31
    D. Authors' Addresses                                             32
    E. Full Copyright Statement                                       33

1. Introduction

   This document describes a URL scheme, called service: URL, which
   defines network access information for network services using a
   formal notation.  In addition it describes how to define a set of
   attributes to associate with a service: URL. These attributes will
   allow end users and programs to select between network services of
   the same type that have different capabilities.  The attributes are
   defined in a template document that is readable by people and
   machines.




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


   A client uses attributes to select a particular service.  Service
   selection occurs by obtaining the service: URL that offers the right
   configuration for the client.  Service type templates define the
   syntax of service: URLs for a particular service type, as well as the
   attributes which accompany a service: URL in a service registration.

   Templates are used for the following distinct purposes:

    1. Standardization

       The template is reviewed before it is standardized.  Once it is
       standardized, all versions of the template are archived by IANA.

    2. Service Registration

       Servers making use of the Service Location Protocol [10] register
       themselves and their attributes.  They use the templates to
       generate the service registrations.  In registering, the service
       must use the specified values for its attributes.

    3. Client presentation of Service Information

       Client applications may display service information.  The
       template provides type information and explanatory text which may
       be helpful in producing user interfaces.

    4. Internationalization

       Entities with access to the template for a given service type in
       two different languages may translate between the two languages.

       A service may register itself in more than one language using
       templates, though it has been configured by an operator who
       registered service attributes in a single language.

   All grammar encoding follows the Augmented BNF (ABNF) [8] for syntax
   specifications.

1.1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119  [6].








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


   The following terminology is used for describing service: URLs.

      service scheme

         A URL scheme whose name starts with the string "service:" and
         is followed by the service type name, constructed according to
         the rules in this document.

      service: URL

         A URL constructed according to the service scheme definition.
         It typically provides at least the following:  The name of an
         access protocol, and an address locating this service.  The
         service: URL may include url path information specific to the
         type of service, as well as attribute information encoded
         according to the URL grammar.  The service: URL is used by the
         Service Location Protocol to register and discover the location
         of services.  It may be used by other protocols and in
         documents as well.

      service type

         A name identifying the semantics by which the remainder of the
         service: URL is to be understood.  It may denote either a
         particular network protocol, or an abstract service associated
         with a variety of protocols.  If the service type denotes a
         particular protocol, then the service type name SHOULD either
         be assigned the name of a particular well known port [2] by
         convention or be the Assigned Numbers name for the service [1].

      abstract service type

         A service type name which is associated with a variety of
         different protocols.  An example is given in Section A.
         Section 2 discusses various ways that abstract types can be
         accommodated.

      service registration

         A service: URL and optionally a set of attributes comprise a
         service registration.  This registration is made by or on
         behalf of a given service.  The URL syntax and attributes must
         conform to the service template for the registered service.

      service template

         A formal description of the service attributes and service
         scheme associated with a particular service type.



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


1.2. Service Location Protocol

   The Service Location Protocol version 2 [10] allows service: URLs to
   be registered and discovered, though service: URLs may be also used
   in other contexts.

   Client applications discover service registrations by issuing queries
   for services of a particular type, specifying the attributes of the
   service: URLs to return.  Clients retrieve the attributes of a
   particular service by supplying its service: URL. Attributes for all
   service registrations of a particular type can also be retrieved.

   Services may register themselves, or registrations may be made on
   their behalf.  These registrations contain a service: URL, and
   possibly attributes and digital signatures.

1.2.1. Compatibility with SLPv1

   This document adopts the encoding conventions of SLPv2.

   Compatibility with SLPv1 [[15]] is possible, if the following
   conventions are observed:

    1. Abstract service types must not be used.  SLPv2 specifies the
       use of Service URLs with abstract service types.  SLPv1 does not
       support them.  Thus, a service template which is to serve both
       SLPv1 and SLPv2 must not use abstract service types.

    2. The syntax for representing opaque values in this document is
       consistent with SLPv2.  The syntax must be converted for use with
       SLPv1.  Instead of a sequence of "\FF" then "\" HEXDIG HEXDIG for
       each byte in the opaque value, SLPv1 uses radix-64 notation.

    3. Escape characters are significantly differently in SLPv1 and
       SLPv2.  Instead of using escaped byte notation for escaped
       characters, SLPv1 uses the HTML convention `&' `#' 1*DIGIT `;'.

2. Service URL Syntax and Semantics

   This section describes the syntax and semantics of service: URLs.

2.1. Service URL Syntax

   The syntax of the service: URL MUST conform to an 'absolute URI' as
   defined by [5].  The syntax of a service:  URL differs enough from a
   'generic URI' that it is best to treat it as an opaque URI unless a
   specific parser for the service:  URL is available.




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


   All service:  URLs have the same syntax up to the 'url-part' The
   syntax for a service URL depends on the service type following the
   service scheme.  All service:  URLs have a service access point
   portion, indicating the address of the service to access.

   The syntax for the <sap> field depends upon the service type
   definition.  The <sap> field is the service access point, and
   describes how to access the service.  In addition, although both
   upper case and lower case characters are recognized in the <service-
   type> field for convenience, the name is case-folded into lower case.
   Service types are therefore not distinguished on the basis of case,
   so, for example, "http" and "HTTP" designate the same service type.
   This is consistent with general URL practice, as outlined in [5].

   The ABNF for a service: URL is:

      service: URL    =   "service:" service-type ":" sap
      service-type    =   abstract-type ":" url-scheme / concrete-type
      abstract-type   =   type-name [ "." naming-auth ]
      concrete-type   =   protocol [ "." naming-auth ]
      type-name       =   resname
      naming-auth     =   resname
      url-scheme      =   resname
                          ; A recognized URL scheme name, standardized
                          ; either through common practice or through
                          ; approval of a standards body.
      resname         =   ALPHA [ 1*(ALPHA / DIGIT / "+" / "-") ]
      sap             =   site [url-part]
      site            =   ipsite / atsite / ipxsite
      ipsite          =   "//" [ [ user "@" ] hostport ]
      hostport        =   host [ ":" port ]
      host            =   hostname / hostnumber
      hostname        =   *( domainlabel "." ) toplabel
      alphanum        =   ALPHA / DIGIT
      domainlabel     =   alphanum / alphanum *[alphanum / "-"] alphanum
      toplabel        =   ALPHA / ALPHA *[ alphanum / "-" ] alphanum