home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-svrloc-service-scheme-01.txt < prev    next >
Text File  |  1997-06-06  |  46KB  |  1,347 lines
  1.  
  2. Service Location Working Group                              Erik Guttman
  3. INTERNET DRAFT                                           Charles Perkins
  4. 6 June 1997                                             Sun Microsystems
  5.  
  6.                 Service Templates and service:  Schemes
  7.                 draft-ietf-svrloc-service-scheme-01.txt
  8.  
  9.  
  10. Status of This Memo
  11.  
  12.    This document is a submission by the Service Location Working Group
  13.    of the Internet Engineering Task Force (IETF).  Comments should be
  14.    submitted to the srvloc@corp.home.net mailing list.
  15.  
  16.    Distribution of this memo is unlimited.
  17.  
  18.    This document is an Internet-Draft.  Internet-Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its areas,
  20.    and its working groups.  Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six months
  24.    and may be updated, replaced, or obsoleted by other documents at
  25.    any time.  It is inappropriate to use Internet-Drafts as reference
  26.    material or to cite them other than as ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft, please check
  29.    the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
  30.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
  31.    Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
  32.    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  33.  
  34.  
  35. Abstract
  36.  
  37.    Service:  schemes define URLs (called "service: URLs" in this
  38.    document) which are primarily intended to be used by the Service
  39.    Location Protocol in order to distribute service access information.
  40.    These schemes provide an extensible framework for client based
  41.    network software to obtain configuration information required to make
  42.    use of network services.  When registering a service: URL with a
  43.    Directory Agent, the URL may be accompanied by a set of well defined
  44.    attributes which define the charateristics of the service.  These
  45.    attributes may convey configuration information to client software,
  46.    or service characteristics meaningful to end users.
  47.  
  48.    This document describes how to define and standardize new service
  49.    types and attributes for use with the service:  scheme using Service
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Guttman,Perkins             Expires 6 December 1997             [Page i]
  57.  
  58. Internet Draft          Service Templates and URLs           6 June 1997
  59.  
  60.  
  61.    Templates.  These templates are human and machine readable.  They
  62.    may be used by administrative tools to parse service registration
  63.    information and by client applications to provide localized
  64.    translations of service attribute strings.
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Guttman,Perkins            Expires 6 December 1997             [Page ii]
  113.  
  114. Internet Draft          Service Templates and URLs           6 June 1997
  115.  
  116.  
  117.  
  118.  
  119.                                 Contents
  120.  
  121.  
  122.  
  123. Status of This Memo                                                    i
  124.  
  125. Abstract                                                               i
  126.  
  127.  1. Introduction                                                       2
  128.      1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .    3
  129.      1.2. Service Schemes . . . . . . . . . . . . . . . . . . . . .    4
  130.      1.3. Related work  . . . . . . . . . . . . . . . . . . . . . .    5
  131.      1.4. Changes made since the last version . . . . . . . . . . .    5
  132.      1.5. Open issues and work to be done . . . . . . . . . . . . .    6
  133.  
  134.  2. Use of service: URLs                                               6
  135.  
  136.  3. Specifying A New Service Type                                      7
  137.      3.1. Service Type Specifications . . . . . . . . . . . . . . .    7
  138.            3.1.1. Service Type  . . . . . . . . . . . . . . . . . .    7
  139.            3.1.2. The service:  'url-path' information  . . . . . .    8
  140.            3.1.3. Attributes  . . . . . . . . . . . . . . . . . . .    8
  141.      3.2. Specifying Attributes . . . . . . . . . . . . . . . . . .    8
  142.            3.2.1. Service Templates and attributes  . . . . . . . .    9
  143.            3.2.2. Service Templates String Encoding . . . . . . . .    9
  144.            3.2.3. Attributes with multiple values . . . . . . . . .   12
  145.            3.2.4. Grouping attribute values together in records . .   12
  146.      3.3. Special attributes  . . . . . . . . . . . . . . . . . . .   13
  147.            3.3.1. Service Type Language . . . . . . . . . . . . . .   13
  148.            3.3.2. Version . . . . . . . . . . . . . . . . . . . . .   13
  149.            3.3.3. url-path rules  . . . . . . . . . . . . . . . . .   14
  150.  
  151.  4. A Process For Standardizing New Service Types                     14
  152.  
  153.  5. Encoding Rules for Service Type URLs                              15
  154.  
  155.  6. Examples                                                          16
  156.      6.1. SLP Directory Agent . . . . . . . . . . . . . . . . . . .   16
  157.      6.2. POP3  . . . . . . . . . . . . . . . . . . . . . . . . . .   16
  158.  
  159.  7. General Service Template                                          17
  160.      7.1. Obtaining Service Templates dynamically . . . . . . . . .   18
  161.  
  162.  8. Internationalization Considerations                               18
  163.      8.1. Character Set identification and use  . . . . . . . . . .   18
  164.      8.2. Language identification and translation . . . . . . . . .   19
  165.  
  166.  
  167.  
  168. Guttman,Perkins             Expires 6 December 1997             [Page 1]
  169.  
  170. Internet Draft          Service Templates and URLs           6 June 1997
  171.  
  172.  
  173.  9. Security Considerations                                           19
  174.  
  175.  
  176. 1. Introduction
  177.  
  178.    This document describes a class of schemes which will allow network
  179.    services to define their service access information, using a standard
  180.    notation.
  181.  
  182.    In addition it describes how to define a set of attributes to
  183.    associate with a service: URL. These attributes will allow end users
  184.    and programs to select between network services of the same type that
  185.    have different capabilities.
  186.  
  187.    A client may use these attributes to select a particular service
  188.    (obtain the service: URL) that has the configuration it needs.  The
  189.    minimal encoding rules for attributes are specified.
  190.  
  191.    Service Type templates are used to describe in a standard way those
  192.    services which use the service: URL. The rules for specifying a
  193.    scheme are provided, along with two examples.  Templates are used the
  194.    following distinct purposes:
  195.  
  196.     1. Standardization
  197.  
  198.        The template is reviewed before it is standardized.  Once it is
  199.        standardized, all versions of the template are archived by IANA.
  200.  
  201.     2. Service Registration
  202.  
  203.        Servers making use of the Service Location Protocol will register
  204.        themselves and their attributes.  They will use the templates to
  205.        generate the service registrations; the service must pick from
  206.        among the allowable values.
  207.  
  208.     3. Client presentation of Service Information
  209.  
  210.        Client applications may display service information.  The
  211.        template provides type information and explanatory text which may
  212.        be helpful in producing user interfaces.
  213.  
  214.     4. Internationalization
  215.  
  216.        If a client application has the template for a given service type
  217.        in two different languages, the attributes may be translated back
  218.        and forth between the two languages.
  219.  
  220.  
  221.  
  222.  
  223.  
  224. Guttman,Perkins             Expires 6 December 1997             [Page 2]
  225.  
  226. Internet Draft          Service Templates and URLs           6 June 1997
  227.  
  228.  
  229.        A Service may use templates to register services in more than
  230.        one language, though it has been configured by the system
  231.        administrator to register in a single language.
  232.  
  233.           QUESTION: Which of several homonyms would be the one known
  234.           to user agents processing the translated information?
  235.  
  236.    All grammar encoding follows the Augmented BNF (ABNF) [6] for syntax
  237.    specifications with a few deviations.
  238.  
  239.       QUESTION: What are the deviations?
  240.  
  241.  
  242. 1.1. Terminology
  243.  
  244.    In order to reduce confusion, some terminology is introduced.
  245.  
  246.       service: URL
  247.  
  248.          A URL, registered by a service agent of a particular service
  249.          type, that conforms to any "service scheme" definition.
  250.  
  251.       service type
  252.  
  253.          A type of service all of whose agents are accessed by service:
  254.          URLs of the same scheme (a service scheme, below).  The name
  255.          of the type of service is the part of the service scheme name
  256.          which follows the initial string "service:".
  257.  
  258.       service scheme
  259.  
  260.          A scheme, whose name start with the string "service:" and is
  261.          followed by the service type name, constructed according to the
  262.          rules in this document.
  263.  
  264.       service template
  265.  
  266.          A formal description of the service attributes and service
  267.          scheme associated with a particular service type.  a particular
  268.          service may be selected by obtaining the service: URL
  269.          registered by that service.
  270.  
  271.       general service template
  272.  
  273.          A template for describing service templates -- for instance as
  274.          is contained within this document.
  275.  
  276.  
  277.  
  278.  
  279.  
  280. Guttman,Perkins             Expires 6 December 1997             [Page 3]
  281.  
  282. Internet Draft          Service Templates and URLs           6 June 1997
  283.  
  284.  
  285. 1.2. Service Schemes
  286.  
  287.    Each service scheme MUST obey the URL conventions defined in [4].
  288.  
  289.    The scheme specific information following the service:  scheme
  290.    provides the service type and address of a network service.  It may
  291.    additionally include service type specific information.  The form of
  292.    a service: URL is as follows:
  293.  
  294.       "service:" service-type ":" service-part
  295.  
  296.    where the service-part typically has the following form:
  297.  
  298.       /addr-family/addr-spec/url-path;FAQ
  299.  
  300.    and the last field is never required to exist in any service
  301.    location registration, but is sometimes provided for convenience of
  302.    interactive user agents.  The formal syntax for a service: URL is
  303.    given in Section 5.
  304.  
  305.    The service-type string indicates the type of service.  The service
  306.    type determines the semantics of the service-part and of the
  307.    attributes associated with the service: URL. The <addr-family> is
  308.    IP by default (if not present), but can be used to indicate the use
  309.    other address families such as IPX and Appletalk.  In this document,
  310.    the addr-family> is always IP, so that the field can be omitted; all
  311.    service-parts will start with "//".  Next, the service-part includes
  312.    a address specification (an <addr-spec>), which is typically either
  313.    a domain name (DNS) or an IP address for the service, and possibly a
  314.    port number.  The service-part allows more information to be provided
  315.    (by way of <url-path>) that can uniquely locate the service or
  316.    resource if the <addr-spec> is not sufficient for that purpose.
  317.  
  318.    The FAQ is actually composed of a list of "attribute = value"
  319.    elements, describing for the user the attributes that are associated
  320.    with the service: URL. This might be done in situations where the
  321.    service: URL is used in a context where it was not automatically
  322.    selected by picking desired attributes.  When a human obtains a
  323.    URL and needs to ask questions about how to use it, hopefully the
  324.    attribute values provided in the FAQ can help.  For instance, if
  325.    the keyword "PostScript" were provided in a service:printer URL, a
  326.    user would be able to guess that the printer could correctly print
  327.    PostScript documents.
  328.  
  329.    Other than in a FAQ, attributes associated with the service: URL are
  330.    not typically included in the URL. They are stored and retrieved
  331.    using other mechanisms.  The service: URL is uniquely identified
  332.    with a particular service agent, and is used when registering
  333.  
  334.  
  335.  
  336. Guttman,Perkins             Expires 6 December 1997             [Page 4]
  337.  
  338. Internet Draft          Service Templates and URLs           6 June 1997
  339.  
  340.  
  341.    or requesting the attribute information.  The Service Location
  342.    Protocol [10] specifies how such information may be advertised
  343.    by network services and obtained by client software.  Service
  344.    agents would not typically advertise URLs with FAQs unless manually
  345.    configured to do so by a system administrator, and a user agent that
  346.    obtains a service: URLs by issuing a Service Request will already
  347.    have all the necessary attribute information to make use of the
  348.    service: URL.
  349.  
  350.    Attributes are associated with service: URLs for three reasons:
  351.  
  352.     1. Many servers have optional features.  Clients which require or
  353.        prefer to make use of these features can proceed to do so without
  354.        protocol negotiation or feature selection.  Attributes serve as
  355.        a mechanism for servers to distribute information about their
  356.        configuration, capabilities and characteristics (even dynamic
  357.        qualities, such as status or load.)
  358.  
  359.     2. Client software may have particular requirements.  The attributes
  360.        associated with a given URL allow for automatic selection of
  361.        services which have certain features.  For example, client
  362.        software may require a server which has a particular version of
  363.        something, or which has access to specific resources.
  364.  
  365.     3. Attributes support selection of service instances by
  366.        characteristic as opposed to simply by type.  These attributes
  367.        may be used to give users information enabling the selection of
  368.        particular services when browsing service directories or the
  369.        available services on the local network.
  370.  
  371.  
  372. 1.3. Related work
  373.  
  374.    The "Finding Stuff" work by Ryan Moats and Martin Hamilton uses
  375.    service: URLs provide access information about arbitrary network
  376.    protocols through DNS [9].  They do not associate service attributes
  377.    with these URLs.  The URLs may contain nonstandard service port
  378.    information for services advertised in the DNS. DNS SRV Resource
  379.    Records are a mechanism which provides a way to obtain a service by
  380.    type for a given domain [7], without being able to specify which of
  381.    the (possibly numerous) instances of the service type would satisfy
  382.    the needs of the user agent.
  383.  
  384.  
  385. 1.4. Changes made since the last version
  386.  
  387.    Removed:
  388.  
  389.  
  390.  
  391.  
  392. Guttman,Perkins             Expires 6 December 1997             [Page 5]
  393.  
  394. Internet Draft          Service Templates and URLs           6 June 1997
  395.  
  396.  
  397.     -  The long template examples.
  398.  
  399.     -  Description of the Service Specific Multicast Addresses (which
  400.        are no longer needed in the Service Templates.)
  401.  
  402.     -  'Record based' attribute values.
  403.  
  404.     -  The possibility for putting CR, LF, or TAB in most places.
  405.  
  406.    Added:
  407.  
  408.     -  Terminology
  409.  
  410.     -  Further explanation of Service Templates.
  411.  
  412.     -  New syntax for Service Templates.
  413.  
  414.     -  A proposal on how to use Templates for internationalization.
  415.  
  416.     -  Some security considerations.
  417.  
  418.  
  419. 1.5. Open issues and work to be done
  420.  
  421.     -  Justification will be added (as done in the URL process
  422.        draft [3]).
  423.  
  424.     -  Encoding rules for transforming a Service Template to an LDAP
  425.        Schema will be added.
  426.  
  427.     -  The process for standardizing a new service type needes to be
  428.        sharpened.  In particular, feedback from the Applications Area
  429.        Directors needs to be solicited.
  430.  
  431.     -  Description of how Service Templates themselves may be registered
  432.        and obtained in a network is needed.  Why isn't SLP enough for
  433.        this purpose?
  434.  
  435.  
  436. 2. Use of service: URLs
  437.  
  438.    The service: URL is intended to allow arbitrary client/server and
  439.    peer to peer systems to make use of a standardized dynamic service
  440.    access point discovery mechanism.
  441.  
  442.    It is intended that service: URLs be selected according to the
  443.    suitability of associated attributes.  A client application may
  444.    obtain the URLs of several services of the same type and distinguish
  445.  
  446.  
  447.  
  448. Guttman,Perkins             Expires 6 December 1997             [Page 6]
  449.  
  450. Internet Draft          Service Templates and URLs           6 June 1997
  451.  
  452.  
  453.    the most preferable among them by means of their attributes.  The
  454.    client will use the service: URL to bind directly to a service.
  455.  
  456.    These attributes will be specified as shown with the "service-
  457.    template", described below.  If a service: URL is stored by a client
  458.    or an agent representing a client, the agent SHOULD also keep track
  459.    of the attributes which characterize the service offered at the
  460.    network location indicated by the URL, and can use the service
  461.    template for additional information about those service attributes.
  462.    The registration of this attribute information is typically done
  463.    using the Service Location Protocol [10], although manual techniques
  464.    and other protocols may be possible.
  465.  
  466.  
  467. 3. Specifying A New Service Type
  468.  
  469.    A Service Type defines the syntax for all URLs that will be
  470.    registered by services of the particular type.  For instance, a
  471.    'Printer' service type is defined with service: URLs in the following
  472.    form:
  473.  
  474.       service:printer://<address of printer>/<queue name>
  475.  
  476.    The service agent registering the printer service can be selected by
  477.    clients specifying the protocol which matches the protocol attribute
  478.    registered with the printer URL above.  The attribute information can
  479.    be used to indicate other configuration details, optional features
  480.    available and characteristics (which may be relevent to a human user
  481.    or to a program.)
  482.  
  483.  
  484. 3.1. Service Type Specifications
  485.  
  486.    Service Type specifications define the fields described in the
  487.    following subsections, and define the syntax of the service-part of
  488.    service: URLs of that service type.
  489.  
  490.  
  491. 3.1.1. Service Type
  492.  
  493.    This is a string which will be prepended by the 'service:'  scheme.
  494.    It may be a name which is entirely invented or be the same as a well
  495.    known service scheme.  For example, service:http:  might refer to a
  496.    HTTP server, whereas the http:  scheme used in a URL generally refers
  497.    to a document.
  498.  
  499.    The meaning of this service type must be fully described by service
  500.    type specification.  A network protocol specification is often
  501.  
  502.  
  503.  
  504. Guttman,Perkins             Expires 6 December 1997             [Page 7]
  505.  
  506. Internet Draft          Service Templates and URLs           6 June 1997
  507.  
  508.  
  509.    included as one of the attributes associated with the service, and
  510.    may optionally be registered by some service agents as part of the
  511.    service: URL include in the service registration.
  512.  
  513.  
  514. 3.1.2. The service:  'url-path' information
  515.  
  516.    This information is included in the URL in order to provide uniquely
  517.    identifying information.  This mechanism is used in the examples
  518.    which follow in order to identify a mountable filesystem (using the
  519.    'nfs' service type) and an lpd print queue (as described above).
  520.  
  521.    The syntax and interpretation of the url-path must accompany the
  522.    definition of a new Service Type.  See section 3.3.3, describing the
  523.    mandatory "template.url-path rules" attribute.  The url-path may be
  524.    very simple, or even entirely omitted except possibly a terminating
  525.    slash.  See [4] for examples and general guidance.
  526.  
  527.  
  528. 3.1.3. Attributes
  529.  
  530.    This information provides information about the service's
  531.    capabilities, characteristics and required client configuration.
  532.    Each attribute which is defined must have a default value and
  533.    definition of all values it can take.
  534.  
  535.    An attribute may take one or more values.  A keyword does not take
  536.    any values.  Registration, deregistration and the use of attributes
  537.    in queries may be accomplished using Service Location Protocol, or
  538.    possibly other means beyond the scope of this document.
  539.  
  540.  
  541. 3.2. Specifying Attributes
  542.  
  543.    Attributes are used to convey information about a given service for
  544.    purposes of differentiating different services of the same type.
  545.    They convey information to be used in the selection of which service
  546.    to bind to, either browsers or for use by a program.
  547.  
  548.    Attributes may be encoded in different character sets and in
  549.    different languages.  The procedure for doing this is described in
  550.    Section 9.
  551.  
  552.    Attributes definitions have several components.
  553.  
  554.     1. The first is a 'tag'.  This is a string with certain encoding
  555.        rules.
  556.  
  557.  
  558.  
  559.  
  560. Guttman,Perkins             Expires 6 December 1997             [Page 8]
  561.  
  562. Internet Draft          Service Templates and URLs           6 June 1997
  563.  
  564.  
  565.     2. Attribute descriptors (type and flags)
  566.  
  567.     3. Possibly, a set of typed values.
  568.  
  569.     4. Descriptive help text explaining necessary information about what
  570.        the attribute is
  571.  
  572.    Attributes (but not keywords) may have one or more values.  Values of
  573.    an attribute are typed, and must have the same type for each value if
  574.    the attribute is multivalued.  The rules for typing and encoding of
  575.    attribute values is given in the rest of section 3.2.
  576.  
  577.  
  578. 3.2.1. Service Templates and attributes
  579.  
  580.    Service Templates provide rules for attributes.  They define:
  581.  
  582.     -  Which attributes are REQUIRED with every service registration of
  583.        a given service type, and which are OPTIONAL.
  584.  
  585.     -  The type of values possible for the attribute (e.g., STRING).
  586.  
  587.     -  Whether the attribute may take multiple values.
  588.  
  589.     -  Whether the attribute may take arbitrary values or only those
  590.        provided in the list.
  591.  
  592.     -  Whether the attribute may be translated to other languages or is
  593.        a 'literal', ie.  not meant for human readability.
  594.  
  595.     -  Whether the service: URL can be be supplied in response to a
  596.        request that does not give a value for the attribute, when the
  597.        attribute is used as part of the registration for that service:
  598.        URL.
  599.  
  600.  
  601. 3.2.2. Service Templates String Encoding
  602.  
  603.    Service templates are encoded in a simple form.  They may be
  604.    translated to any language or character set, but the template used
  605.    for standardization MUST be encoded in ASCII [2] and be in English.
  606.  
  607.    Between each attribute definition there is a blank line.  The rules
  608.    for encoding attributes is given below.  Reserved characters include
  609.    ";", "&", "=", ",", "*", "#", TAB, LF, and CR. Reserved characters
  610.    may be escaped.  The escaped character is replaced by a character
  611.    sequence with no spaces.  The digits are a decimal representation of
  612.  
  613.  
  614.  
  615.  
  616. Guttman,Perkins             Expires 6 December 1997             [Page 9]
  617.  
  618. Internet Draft          Service Templates and URLs           6 June 1997
  619.  
  620.  
  621.    the character value to be replaced, in the character set used for the
  622.    attribute encoding.
  623.  
  624.    Some attributes may take values only among those present in a
  625.    specified value list.  A keyword has no value list included.  Any
  626.    attribute or keyword definition may include help text which can be
  627.    used to provide interactive descriptions helpful to people browsing
  628.    the available services.  This descriptive text is often used to
  629.    explain technical details about the attribute or about the values
  630.    which the attribute can take.
  631.  
  632.       esc-char = "&" "#" 1*DIGIT ";"
  633.  
  634.    The following special case should be noted:
  635.  
  636.     -  Commas are used to separate list elements (e.g., allowable
  637.        attribute values.  To use a comma in attribute encodings, escape
  638.        the comma with ,
  639.  
  640.    Service Templates have the following ABNF [6] grammar:
  641.  
  642.       NOTE that this grammar is not quite correct yet, because it
  643.       needs a lot of work on specifying the scheme-def.
  644.  
  645.  
  646.       template   =  scheme-props scheme-def attr-defs
  647.       schemeatrs =  schemevers schemelang schemetype schemetext
  648.       schemevers =  "Version" "=" 1*DIGIT "." 1*DIGIT
  649.       schemelang =  "Language" "=" 2*2lower-alpha
  650.       schemetype =  "Type" "=" *schemechar
  651.       schemechar =  ALPHA / DIGIT / "-" / "_" / "$" / "+" /
  652.                     "@" / "." / "|" / "<" / ">" / "~"
  653.       schemetext =  "Scheme-description" "=" [help-text]
  654.       scheme-def =  url-path-rules
  655.                     ; Rules for constructing service: URLs:
  656.                     ; The scheme-def part of the template will
  657.                     ; be text describing the allowable format
  658.                     ; of information in the url-path of the
  659.                     ; service-part of the service scheme.
  660.                     ; The <addr-spec> and FAQ fields do not
  661.                     ; require additional specification.
  662.       attr-defs  =  *(attr-def/keydef)
  663.       attr-def   =  tag "=" attrtail newline
  664.       keydef     =  keyword "=" "KEYWORD" newline
  665.       attrtail   =  type flags newline [value-list] [help-text]
  666.       value-list =  1#value newline
  667.       help-text  =  1#help-line
  668.                     ; This is a human readable description of
  669.  
  670.  
  671.  
  672. Guttman,Perkins            Expires 6 December 1997             [Page 10]
  673.  
  674. Internet Draft          Service Templates and URLs           6 June 1997
  675.  
  676.  
  677.                     ; this attribute and its values.
  678.       help-line  =  *[white-sp] "#" *[ com-chars ] newline
  679.       tag        =  1*attrchar
  680.       keyword    =  1*attrchar
  681.       attrchar   =  1*(schemechar / ":"
  682.       flags      =  ["M"] ["L"] ["X"] ["O"]
  683.                     ; M means multiple values are allowed
  684.                     ; L "Literal", values MUST NOT be translated
  685.                     ; X means explicit match required
  686.                     ; O "Optional", the attribute may be omitted
  687.  
  688.       value      =  string / integer / boolean / opaque
  689.       type       =  "STRING" / "INTEGER" / "BOOLEAN" |
  690.                     "OPAQUE" / "KEYWORD"
  691.                     ; These strings are not to be translated.
  692.  
  693.       string     =  safe-char *[safe-chars / SPACE] safe-char
  694.  
  695.       integer    =  [-] 1*DIGIT
  696.                     ; The integer MUST fall within the range of
  697.                     ; values a 32 bit integer may take, ie.
  698.                     ; -2147483648 to 2147483647.
  699.  
  700.       boolean    =  "TRUE" / "FALSE"
  701.                     ; These strings are not to be translated.
  702.  
  703.       com-chars  =  safe-char / white-sp / "*" / "," / ";"/ "&"
  704.  
  705.       safe-char  =  attrchar / " " / "!" / '"' / "%" / "'" /
  706.                     "(" / ")" / "+" / "," / "-" / "." / "|" /
  707.                     ":" / "=" / "?" / "[" / "]" /
  708.                     "" / "/" / "" / " "
  709.                     ; All ASCII printable characters are
  710.                     ; included except ",", "&", "*" and "#".
  711.  
  712.       white-sp   =  SPACE / TAB
  713.       rad64-char =  ALPHA / DIGIT / "+" / "-" / white-sp
  714.       opaque     =  1*DIGIT ":" 4*rad64-char
  715.                     ; The digits define the original length of
  716.                     ; the opaque value.  The restricted character
  717.                     ; string is the radix-64 encoding of the opaque
  718.                     ; value.  See [5], Section 5.2.
  719.                     ; NOTE: White space is ignored in decoding
  720.                     ; radix-64 values.
  721.       newline    =  CR / ( CR LF )
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728. Guttman,Perkins            Expires 6 December 1997             [Page 11]
  729.  
  730. Internet Draft          Service Templates and URLs           6 June 1997
  731.  
  732.  
  733.       ABNF should have some way of denoting a continuation
  734.       line!  Otherwise, it is ambiguous whether a next line is a
  735.       continuation or starts with some bizarro nonterminal.
  736.  
  737.    Note on the use of white space:
  738.  
  739.    A string is considered to be a token in the case of a tag or
  740.    <string> value.  In this case, the string is 'trimmed'.  White space
  741.    interior to a string token is left alone, while white space between
  742.    the tokens is removed.  For example:
  743.  
  744.          " some name = some value , another example "
  745.  
  746.       would be trimmed to
  747.  
  748.          "some name" '=' "some value" and "another example".
  749.  
  750.    Notes on string matching:
  751.  
  752.    Attribute tags and values may be used by some protocols for directory
  753.    look-up.  In this case, the following rules should be applied for
  754.    string matching of attribute strings.
  755.  
  756.    Decoding character escape and trimming white space MUST be performed
  757.    before string matching.  In addition, string matching SHOULD be case
  758.    insensitive.
  759.  
  760.  
  761. 3.2.3. Attributes with multiple values
  762.  
  763.    Attributes with multiple values must be defined so that the type of
  764.    each value is the same.  Boolean attributes may not take multiple
  765.    values.
  766.  
  767.    Attributes and values must be given in exactly the same order in
  768.    translated service templates.  This will allow the service templates
  769.    to be used to translate attributes and values to other languages
  770.    (using service templates as look up tables.)
  771.  
  772.  
  773. 3.2.4. Grouping attribute values together in records
  774.  
  775.    Some attributes may be related, which is to say, not independent.
  776.    Each configuration, for instance, might have a limitation and a best
  777.    use.  If these were encoded in separate attributes, the dependency
  778.    would not be clear:
  779.  
  780.  
  781.  
  782.  
  783.  
  784. Guttman,Perkins            Expires 6 December 1997             [Page 12]
  785.  
  786. Internet Draft          Service Templates and URLs           6 June 1997
  787.  
  788.  
  789.       Configuration = A,B,C
  790.       Restriction = slow,large,unpredictable,low-priority
  791.       Best Use = cpu-intensive,batch-jobs,interactive-use
  792.  
  793.  
  794.    Which is slow, A, B or C? Are interactive jobs unpredictable?  The
  795.    suggested convention is to choose one of the attributes ranges to be
  796.    the attribute base.  Here, it will be the configuration.  The others
  797.    attributes are, by conventions, extensions of this record.  The
  798.    following makes all dependencies explicit:
  799.  
  800.       Configuration-A.Restriction = slow,low-priority
  801.       Configuration-A.Best-Use = batch-jobs
  802.       Configuration-B.Restriction = unpredictable
  803.       Configuration-B.Best-Use = interactive-use
  804.       Configuration-C.Restriction = large
  805.       Configuration-C.Best-Use = cpu-intensive
  806.  
  807.  
  808.    Note that the use of such grouping is conventional, by use of the
  809.    dot as an <tag> character, and does not place any constraint on
  810.    the parsing mechanisms used by agents storing the visually related
  811.    attribute values.
  812.  
  813.  
  814. 3.3. Special attributes
  815.  
  816.    Every service template must define the following attributes:
  817.  
  818.  
  819. 3.3.1. Service Type Language
  820.  
  821.    This is a two letter code defining the language of the template [8].
  822.  
  823.  
  824. 3.3.2. Version
  825.  
  826.    The version of the Service Type template.  A proposal starts at 0.0,
  827.    and the minor number increments once per revision.  The Version
  828.    attribute has a string value of the form:
  829.  
  830.       version = 1*DIGIT '.' 1*DIGIT
  831.  
  832.    A standardized template starts at 1.0.  Additions of attributes add
  833.    one to the minor number, where changes of definition or removal of
  834.    attributes or values adds one to the major number.  See Section 4 for
  835.    more detail on how to use the Version attribute.
  836.  
  837.  
  838.  
  839.  
  840. Guttman,Perkins            Expires 6 December 1997             [Page 13]
  841.  
  842. Internet Draft          Service Templates and URLs           6 June 1997
  843.  
  844.  
  845. 3.3.3. url-path rules
  846.  
  847.    This is a text attribute which defines the semantics of the url path
  848.    of the service: URL of the given type.
  849.  
  850.    The <service-part> is of the form:
  851.  
  852.  
  853.       /<addr-family>/<addr-spec>/<url-path>;FAQ
  854.  
  855.    The <url-path> description specifies additional information to locate
  856.    a service when the <addr-spec> is not sufficient, and is a field
  857.    whose content that distinguishes URLs of a particular service type
  858.    from those of another service type.  For instance, in the case of a
  859.    printer service: URL, the url-path will typically be a queue name,
  860.    but not in the case of a service: URL for any other service type.
  861.  
  862.  
  863. 4. A Process For Standardizing New Service Types
  864.  
  865.    New Service Types can be suggested simply by providing a Service Type
  866.    template and a short description of the use for the service:  URL.
  867.    This MUST have its 'Version' attribute set to "0.0" initially.
  868.  
  869.    The minor version number will increment once with each change until
  870.    it achieves 1.0.  There is no guarantee any version of the service
  871.    template will be backwards compatible before it reaches 1.0.
  872.  
  873.    Once a service template has reached 1.0, the definition is "frozen"
  874.    for that version.  New templates may be defined, of course, to refine
  875.    that definition, but they must follow these rules:
  876.  
  877.     -  Any new attribute defined for the template will increase the
  878.        minor version number by one.  All other attributes for the
  879.        version must continue to be supported as before.  A client which
  880.        supports 1.x can still use later versions of 1.y (where x<y) as
  881.        it will ignore attributes it doesn't know about.
  882.  
  883.     -  Deprecating or changing the definition of an attribute requires
  884.        changing the major version number of a service template.  A user
  885.        agent may be unable to make use of this information, or it may
  886.        need to obtain the most recent service template to help the user
  887.        interpret the service info.
  888.  
  889.    The template should be posted to the Service Location Working Group
  890.    mailing list for review.  Ideally, experts in the implementation and
  891.    deployment of the particular protocol will be consulted so as to add
  892.  
  893.  
  894.  
  895.  
  896. Guttman,Perkins            Expires 6 December 1997             [Page 14]
  897.  
  898. Internet Draft          Service Templates and URLs           6 June 1997
  899.  
  900.  
  901.    more attributes or change their definition to make them as useful as
  902.    possible.
  903.  
  904.    All published versions of the template must be available on-line,
  905.    including obselete ones.
  906.  
  907.       QUESTION:
  908.       Where?
  909.  
  910.    Once there is no more active dissent the Service Type should be
  911.    reissued with possible corrections, having its Version number set to
  912.    "1.0".  If there is no comment on the template after 3 months, it
  913.    should be considered to have been accepted.
  914.  
  915.  
  916. 5. Encoding Rules for Service Type URLs
  917.  
  918.    Much of this material is directly adapted from [4].  Note that the
  919.    syntax for the url-path depends upon the Service Type definition.
  920.    See Section 3.  The ABNF for a service: URL is:
  921.  
  922.  
  923.         service: URL   =   "service:" service-type ":" service-part
  924.         service-type   =   1*[ low-alpha / DIGIT / "+" / "-" / "." ]
  925.         low-alpha      =   "a".."z"
  926.         service-part   =   "//" login [ "/" url-path ]
  927.         login          =   [ user "@" ] hostport
  928.         hostport       =   host [ ":" port ]
  929.         host           =   hostname / hostnumber
  930.         hostname       =   hostlabel *[ "." domainlabel ]
  931.         okchar         =   ALPHA / DIGIT
  932.         domainlabel    =   okchar / okchar *[ okchar / "-" ] okchar
  933.         hostlabel      =   ALPHA / ALPHA *[ okchar / "-" ] okchar
  934.         hostnumber     =   ipv4-number / ipv6-number
  935.         ipv4-number    =   1*3DIGIT 3*3("." 1*3DIGIT)
  936.         ipv6-number    =   32hex
  937.         port           =   1*DIGIT
  938.         user           =   *[ uchar / ";" / "?" / "&" / "=" ]
  939.         url-path       =   *xchar ; each Service Type must define its
  940.                            ; own syntax (section 3)
  941.         safe           =   "$" / "-" / "_" / "." / "+"
  942.         extra          =   "!" / "*" / "'" / "(" / ")" / ","
  943.         hex            =   DIGIT / "A".."F" / "a".."f"
  944.         escape         =   "%" hex hex
  945.         reserved       =   ";" / "/" / "?" / ":" / "@" / "&" / "="
  946.         unreserved     =   ALPHA / DIGIT / safe / extra
  947.         uchar          =   unreserved / escape
  948.         xchar          =   unreserved / reserved / escape
  949.  
  950.  
  951.  
  952. Guttman,Perkins            Expires 6 December 1997             [Page 15]
  953.  
  954. Internet Draft          Service Templates and URLs           6 June 1997
  955.  
  956.  
  957.  
  958.  
  959.  
  960. 6. Examples
  961.  
  962.    The Service Templates for the SLP Directory Agent and POP3 service
  963.    are given below.
  964.  
  965.  
  966. 6.1. SLP Directory Agent
  967.  
  968.    The directory-agent service type has no attributes except scope.
  969.  
  970.  
  971. 6.2. POP3
  972.  
  973.  
  974.         template.service-type = STRING L
  975.             POP3
  976.             # This is the template for the POP3 service.
  977.  
  978.         template.version = STRING L
  979.             0.0
  980.             # This is the preliminary version of the template.
  981.  
  982.         template.description = STRING
  983.             The question is how to make this string exceed one line
  984.             # Clients which wish to make use of POP3 service need to be
  985.             # configured to use the correct POP3 server.  The server may
  986.             # or may not be able to use the APOP authentication mechanism.
  987.             # Clients are able to discover which POP3 server is the correct
  988.             # one for them and whether they can use the APOP to authenticate
  989.             # themselves.  Finally, the POP3 server policy may be
  990.             # included.
  991.  
  992.         template.url-path-rules = STRING
  993.             The url-path is omitted.
  994.             #
  995.  
  996.         template.language = STRING L
  997.             en
  998.             # The default template is in English.
  999.  
  1000.         Mailboxes = STRING M L
  1001.             # This is a list of all users (by user name) which the POP3
  1002.             # server supports.
  1003.  
  1004.         APOP = BOOLEAN L
  1005.  
  1006.  
  1007.  
  1008. Guttman,Perkins            Expires 6 December 1997             [Page 16]
  1009.  
  1010. Internet Draft          Service Templates and URLs           6 June 1997
  1011.  
  1012.  
  1013.             FALSE
  1014.             # This determines whether the POP3 server supports APOP
  1015.  
  1016.         Policy = STRING O
  1017.             # This optional attribute describes the POP3 server's policy
  1018.             # regarding its use.  For instance, are users dissuaded or
  1019.             # disallowed from keeping mail on the server?  Is there a
  1020.             # quota?  Is mail older than a certain number of days erased?
  1021.  
  1022.  
  1023.  
  1024. 7. General Service Template
  1025.  
  1026.    The service-template Service Type has 4 attributes, followed by the
  1027.    service: URL definition for the service type and the collection of
  1028.    attribute specifications for the service type.
  1029.  
  1030.         version = STRING L
  1031.             # This is the version number of the template.
  1032.             # It is expressed in X.Y notation, where X is the major
  1033.             # and Y is the minor version number.
  1034.  
  1035.         service type = STRING L
  1036.             # The value of this attribute is a service type string.
  1037.  
  1038.         description = STRING
  1039.             # The service type is described here.  This is a paragraph or
  1040.             # so of text which describes how to interpret the service: URL
  1041.             # for this particular service type.  It should be clear what
  1042.             # protocol or protocols can bind to the service access point
  1043.             # which the service: URL resolves to.
  1044.  
  1045.         Language tag = STRING L
  1046.             en
  1047.             # The Language tag used in the service type template.  This is
  1048.             # an ISO-639 two letter language code.
  1049.  
  1050.         service-URL = STRING
  1051.             # A way of describing the structure of the <service-part>
  1052.             # is for the service type being specified.
  1053.  
  1054.         attr-specs = STRING M
  1055.             # The value of this attribute is the template text, defining
  1056.             # all the service type attributes.
  1057.  
  1058.  
  1059.    Of the mandatory attribute tags, only "description" may be translated
  1060.    into another language (see Section 9.)
  1061.  
  1062.  
  1063.  
  1064. Guttman,Perkins            Expires 6 December 1997             [Page 17]
  1065.  
  1066. Internet Draft          Service Templates and URLs           6 June 1997
  1067.  
  1068.  
  1069.    The description field should be a paragraph of text describing the
  1070.    attribute and the all the values it can take on.  This information
  1071.    will be used by those who develop user interfaces to display service
  1072.    information and those who advertise services using attributes
  1073.    associated with the service: URL.
  1074.  
  1075.  
  1076. 7.1. Obtaining Service Templates dynamically
  1077.  
  1078.    The service template is registered as a service type by any SA which
  1079.    has a template.  The SA SHOULD query the DA to determine if the
  1080.    service template has already been registered, and if so, abstain from
  1081.    registering the service template.
  1082.  
  1083.       This is an area which definitely needs work.  The difficulty
  1084.       is that in order for a service template to be retrieved as
  1085.       an attribute of some registered service: URL (presumably
  1086.       of type service:template:), one would have to allow extra
  1087.       newlines and space and reserved characters in tricky places.
  1088.       On the other hand, devising a new method (a new service) of
  1089.       handing out such information is not immediately attractive.
  1090.  
  1091.  
  1092. 8. Internationalization Considerations
  1093.  
  1094.    The service: URL itself must be encoded using the rules set forth
  1095.    in [4].  The character set encoding is limited to specific ranges
  1096.    within the US-ASCII character set [2].
  1097.  
  1098.    The attribute information associated with the service: URL may be
  1099.    expressed in any character set, and in any language.
  1100.  
  1101.  
  1102. 8.1. Character Set identification and use
  1103.  
  1104.    The way of identifying the character set used is the IANA Character
  1105.    Set registry official name, found at:
  1106.          http://www.isi.edu/in-notes/iana/assignments/character-sets
  1107.  
  1108.    US-ASCII MUST be supported.
  1109.  
  1110.    For other encodings, the repository of the service template or the
  1111.    protocol which transmits attributes (for registration or query
  1112.    purposes) must be able to identify the encoding using an external
  1113.    mechanism.  It would make no sense to use an 'internal' designation
  1114.    for marking the character encoding, as the attribute information is
  1115.    itself string encoded.  The Service Location Protocol [10] makes the
  1116.  
  1117.  
  1118.  
  1119.  
  1120. Guttman,Perkins            Expires 6 December 1997             [Page 18]
  1121.  
  1122. Internet Draft          Service Templates and URLs           6 June 1997
  1123.  
  1124.  
  1125.    character encoding for each registration, query and query result
  1126.    explicit in the protocol header, for example.
  1127.  
  1128.    All attribute information in a single transmission, file, etc.  MUST
  1129.    be in the same character encoding.
  1130.  
  1131.  
  1132. 8.2. Language identification and translation
  1133.  
  1134.    The language used in attribute string should be identified using a
  1135.    Language tag as defined by [1].
  1136.  
  1137.    A program may translate a service advertisement from one language
  1138.    to another provided it has both the template of the language of the
  1139.    advertisement and the template of the desired target language.  All
  1140.    standardized attributes will be in the same order in both templates.
  1141.    All non-arbitrary strings (such as tags and set members) will be
  1142.    directly translatable from one language to another.  Free text and
  1143.    nonstandard attributes may not be automatically translated in this
  1144.    manner.
  1145.  
  1146.       Shouldn't help text be translatable?  What is free text?
  1147.  
  1148.    All strings used in attributes (tags and values) are assumed to
  1149.    be able to be translated unless explicitely defined as should
  1150.    be literal, so that best effort translation (see below) will not
  1151.    obfuscate strings which are meant to be interpreted by a program, not
  1152.    a person.
  1153.  
  1154.    There are two ways to go about translation:  Standardization and best
  1155.    effort.
  1156.  
  1157.    When the service type is standardized, more than one document may be
  1158.    submitted for review.  One service type description is registered
  1159.    for each language.  These descriptions must be kept in sync, so that
  1160.    when a service type template is updated in one language, all the
  1161.    translations (at least eventually) reflect the same semantics.
  1162.  
  1163.    If no document exists describing the standard translation of the
  1164.    service type, a 'best effort' translation for strings may be done.
  1165.  
  1166.  
  1167. 9. Security Considerations
  1168.  
  1169.    Service type templates provide information which will be used to
  1170.    interpret information obtained by the Service Location Protocol.  If
  1171.    these templates were modified or false templates were distributed,
  1172.  
  1173.  
  1174.  
  1175.  
  1176. Guttman,Perkins            Expires 6 December 1997             [Page 19]
  1177.  
  1178. Internet Draft          Service Templates and URLs           6 June 1997
  1179.  
  1180.  
  1181.    services may not correctly register themselves or clients might not
  1182.    be able to interpret service information obtained by SLP.
  1183.  
  1184.    Service URLs themselves specify the service access point and
  1185.    protocol for a particular service type.  These Service URLs could be
  1186.    distributed and indicate the location of a service other than that
  1187.    which a user would normally want to use.  SLP distributes Service
  1188.    URLs and has an authentication mechanism which allows Service URLs of
  1189.    advertised services to be signed and these signatures to be verified
  1190.    by clients.
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232. Guttman,Perkins            Expires 6 December 1997             [Page 20]
  1233.  
  1234. Internet Draft          Service Templates and URLs           6 June 1997
  1235.  
  1236.  
  1237. References
  1238.  
  1239.     [1] H. Alvestrand.  Tags for the Identification of Languages.  RFC
  1240.         1766, March 1995.
  1241.  
  1242.     [2] ANSI.  Coded Character Set -- 7-bit American Standard code for
  1243.         Information Interchange.  X3.4-1986, 1986.
  1244.  
  1245.     [3] T. Berners-Lee, R. Fielding, and L. Masinter.  Uniform
  1246.         Resource Locators (URL): Generic Syntax and Semantics.
  1247.         draft-fielding-url-syntax-05.txt, May 1997.  (work in progress).
  1248.  
  1249.     [4] T. Berners-Lee, L. Masinter, and M. McCahill.  Uniform Resource
  1250.         Locators (URL).  RFC 1738, December 1994.
  1251.  
  1252.     [5] N. Borenstein and N. Freed.  MIME (Multipurpose Internet Mail
  1253.         Extensions) Part One:  Mechanisms for Specifying and Describing
  1254.         the Format of Internet Message Bodies.  RFC 1521, September
  1255.         1993.
  1256.  
  1257.     [6] D. Crocker and P Overell.  Augmented BNF for Syntax
  1258.         Specifications:  ABNF.  draft-ietf-drums-abnf-02.txt, November
  1259.         1996.  (work in progress).
  1260.  
  1261.     [7] A. Gulbrandsen and P. Vixie.  A DNS RR for specifying the
  1262.         location of services (DNS SRV).  RFC 2052, October 1996.
  1263.  
  1264.     [8] Geneva ISO.  Code for the representation of names of languages.
  1265.         ISO 639:1988 (E/F), 1988.
  1266.  
  1267.     [9] R. Moats and M. Hamilton. Finding Stuff(Providing information to
  1268.         support service discovery). draft-ietf-svrloc-advertise-00.txt,
  1269.         February 1997.  (work in progress).
  1270.  
  1271.    [10] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
  1272.         Location Protocol, April 1997. draft-ietf-svrloc-protocol-17.txt
  1273.         (work in progress).
  1274.  
  1275.  
  1276. Authors' Addresses
  1277.  
  1278.    Questions about this memo can be directed to:
  1279.  
  1280.    Erik Guttman                       Charles E. Perkins
  1281.    Sun Microsystems                   Sun Microsystems
  1282.    Gaisbergstr. 6                     2550 Garcia Avenue
  1283.    D-69115 Heidelberg                 Mountain View, CA  94043
  1284.    Germany                            USA
  1285.  
  1286.  
  1287.  
  1288. Guttman,Perkins            Expires 6 December 1997             [Page 21]
  1289.  
  1290. Internet Draft          Service Templates and URLs           6 June 1997
  1291.  
  1292.  
  1293.    Phone: +1 415 336 6697             1 415 336 7153
  1294.    email: Erik.Guttman@eng.sun.com    cperkins@corp.sun.com
  1295.  
  1296.  
  1297.  
  1298.  
  1299.  
  1300.  
  1301.  
  1302.  
  1303.  
  1304.  
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344. Guttman,Perkins            Expires 6 December 1997             [Page 22]
  1345.  
  1346.  
  1347.