Service Location Working Group Erik Guttman
INTERNET DRAFT Charles Perkins
6 June 1997 Sun Microsystems
Service Templates and service: Schemes
draft-ietf-svrloc-service-scheme-01.txt
Status of This Memo
This document is a submission by the Service Location Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the srvloc@corp.home.net mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
Service: schemes define URLs (called "service: URLs" in this
document) which 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 with a
Directory Agent, the URL may be accompanied by a set of well defined
attributes which define the charateristics of the service. These
attributes may convey configuration information to client software,
or service characteristics meaningful to end users.
This document describes how to define and standardize new service
types and attributes for use with the service: scheme using Service
Guttman,Perkins Expires 6 December 1997 [Page i]
Internet Draft Service Templates and URLs 6 June 1997
Templates. These templates are human and machine readable. They
may be used by administrative tools to parse service registration
information and by client applications to provide localized
translations of service attribute strings.
Guttman,Perkins Expires 6 December 1997 [Page ii]
Internet Draft Service Templates and URLs 6 June 1997
Contents
Status of This Memo i
Abstract i
1. Introduction 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Service Schemes . . . . . . . . . . . . . . . . . . . . . 4
1.3. Related work . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Changes made since the last version . . . . . . . . . . . 5
1.5. Open issues and work to be done . . . . . . . . . . . . . 6
2. Use of service: URLs 6
3. Specifying A New Service Type 7
3.1. Service Type Specifications . . . . . . . . . . . . . . . 7
3.1.1. Service Type . . . . . . . . . . . . . . . . . . 7
3.1.2. The service: 'url-path' information . . . . . . 8
3.1.3. Attributes . . . . . . . . . . . . . . . . . . . 8
3.2. Specifying Attributes . . . . . . . . . . . . . . . . . . 8
3.2.1. Service Templates and attributes . . . . . . . . 9
3.2.2. Service Templates String Encoding . . . . . . . . 9
3.2.3. Attributes with multiple values . . . . . . . . . 12
3.2.4. Grouping attribute values together in records . . 12
3.3. Special attributes . . . . . . . . . . . . . . . . . . . 13
3.3.1. Service Type Language . . . . . . . . . . . . . . 13
3.3.2. Version . . . . . . . . . . . . . . . . . . . . . 13
3.3.3. url-path rules . . . . . . . . . . . . . . . . . 14
4. A Process For Standardizing New Service Types 14
5. Encoding Rules for Service Type URLs 15
6. Examples 16
6.1. SLP Directory Agent . . . . . . . . . . . . . . . . . . . 16
6.2. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. General Service Template 17
7.1. Obtaining Service Templates dynamically . . . . . . . . . 18
8. Internationalization Considerations 18
8.1. Character Set identification and use . . . . . . . . . . 18
8.2. Language identification and translation . . . . . . . . . 19
Guttman,Perkins Expires 6 December 1997 [Page 1]
Internet Draft Service Templates and URLs 6 June 1997
9. Security Considerations 19
1. Introduction
This document describes a class of schemes which will allow network
services to define their service access information, using a standard
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.
A client may use these attributes to select a particular service
(obtain the service: URL) that has the configuration it needs. The
minimal encoding rules for attributes are specified.
Service Type templates are used to describe in a standard way those
services which use the service: URL. The rules for specifying a
scheme are provided, along with two examples. Templates are used 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 will register
themselves and their attributes. They will use the templates to
generate the service registrations; the service must pick from
among the allowable values.
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
If a client application has the template for a given service type
in two different languages, the attributes may be translated back
and forth between the two languages.
Guttman,Perkins Expires 6 December 1997 [Page 2]
Internet Draft Service Templates and URLs 6 June 1997
A Service may use templates to register services in more than
one language, though it has been configured by the system
administrator to register in a single language.
QUESTION: Which of several homonyms would be the one known
to user agents processing the translated information?
All grammar encoding follows the Augmented BNF (ABNF) [6] for syntax
specifications with a few deviations.
QUESTION: What are the deviations?
1.1. Terminology
In order to reduce confusion, some terminology is introduced.
service: URL
A URL, registered by a service agent of a particular service
type, that conforms to any "service scheme" definition.
service type
A type of service all of whose agents are accessed by service:
URLs of the same scheme (a service scheme, below). The name
of the type of service is the part of the service scheme name
which follows the initial string "service:".
service scheme
A scheme, whose name start with the string "service:" and is
followed by the service type name, constructed according to the
rules in this document.
service template
A formal description of the service attributes and service
scheme associated with a particular service type. a particular
service may be selected by obtaining the service: URL
registered by that service.
general service template
A template for describing service templates -- for instance as
is contained within this document.
Guttman,Perkins Expires 6 December 1997 [Page 3]
Internet Draft Service Templates and URLs 6 June 1997
1.2. Service Schemes
Each service scheme MUST obey the URL conventions defined in [4].
The scheme specific information following the service: scheme
provides the service type and address of a network service. It may
additionally include service type specific information. The form of
a service: URL is as follows:
"service:" service-type ":" service-part
where the service-part typically has the following form:
/addr-family/addr-spec/url-path;FAQ
and the last field is never required to exist in any service
location registration, but is sometimes provided for convenience of
interactive user agents. The formal syntax for a service: URL is
given in Section 5.
The service-type string indicates the type of service. The service
type determines the semantics of the service-part and of the
attributes associated with the service: URL. The <addr-family> is
IP by default (if not present), but can be used to indicate the use
other address families such as IPX and Appletalk. In this document,
the addr-family> is always IP, so that the field can be omitted; all
service-parts will start with "//". Next, the service-part includes
a address specification (an <addr-spec>), which is typically either
a domain name (DNS) or an IP address for the service, and possibly a
port number. The service-part allows more information to be provided
(by way of <url-path>) that can uniquely locate the service or
resource if the <addr-spec> is not sufficient for that purpose.
The FAQ is actually composed of a list of "attribute = value"
elements, describing for the user the attributes that are associated
with the service: URL. This might be done in situations where the
service: URL is used in a context where it was not automatically
selected by picking desired attributes. When a human obtains a
URL and needs to ask questions about how to use it, hopefully the
attribute values provided in the FAQ can help. For instance, if
the keyword "PostScript" were provided in a service:printer URL, a
user would be able to guess that the printer could correctly print
PostScript documents.
Other than in a FAQ, attributes associated with the service: URL are
not typically included in the URL. They are stored and retrieved
using other mechanisms. The service: URL is uniquely identified
with a particular service agent, and is used when registering
Guttman,Perkins Expires 6 December 1997 [Page 4]
Internet Draft Service Templates and URLs 6 June 1997
or requesting the attribute information. The Service Location
Protocol [10] specifies how such information may be advertised
by network services and obtained by client software. Service
agents would not typically advertise URLs with FAQs unless manually
configured to do so by a system administrator, and a user agent that
obtains a service: URLs by issuing a Service Request will already
have all the necessary attribute information to make use of the
service: URL.
Attributes are associated with service: URLs for three reasons:
1. Many servers have optional features. Clients which require or
prefer to make use of these features can proceed to do so without
protocol negotiation or feature selection. Attributes serve as
a mechanism for servers to distribute information about their
configuration, capabilities and characteristics (even dynamic
qualities, such as status or load.)
2. Client software may have particular requirements. The attributes
associated with a given URL allow for automatic selection of
services which have certain features. For example, client
software may require a server which has a particular version of
something, or which has access to specific resources.
3. Attributes support selection of service instances by
characteristic as opposed to simply by type. These attributes
may be used to give users information enabling the selection of
particular services when browsing service directories or the
available services on the local network.
1.3. Related work
The "Finding Stuff" work by Ryan Moats and Martin Hamilton uses
service: URLs provide access information about arbitrary network
protocols through DNS [9]. They do not associate service attributes
with these URLs. The URLs may contain nonstandard service port
information for services advertised in the DNS. DNS SRV Resource
Records are a mechanism which provides a way to obtain a service by
type for a given domain [7], without being able to specify which of
the (possibly numerous) instances of the service type would satisfy
the needs of the user agent.
1.4. Changes made since the last version
Removed:
Guttman,Perkins Expires 6 December 1997 [Page 5]
Internet Draft Service Templates and URLs 6 June 1997
- The long template examples.
- Description of the Service Specific Multicast Addresses (which
are no longer needed in the Service Templates.)
- 'Record based' attribute values.
- The possibility for putting CR, LF, or TAB in most places.
Added:
- Terminology
- Further explanation of Service Templates.
- New syntax for Service Templates.
- A proposal on how to use Templates for internationalization.
- Some security considerations.
1.5. Open issues and work to be done
- Justification will be added (as done in the URL process
draft [3]).
- Encoding rules for transforming a Service Template to an LDAP
Schema will be added.
- The process for standardizing a new service type needes to be
sharpened. In particular, feedback from the Applications Area
Directors needs to be solicited.
- Description of how Service Templates themselves may be registered
and obtained in a network is needed. Why isn't SLP enough for
this purpose?
2. Use of service: URLs
The service: URL is intended to allow arbitrary client/server and
peer to peer systems to make use of a standardized dynamic service
access point discovery mechanism.
It is intended that service: URLs be selected according to the
suitability of associated attributes. A client application may
obtain the URLs of several services of the same type and distinguish
Guttman,Perkins Expires 6 December 1997 [Page 6]
Internet Draft Service Templates and URLs 6 June 1997
the most preferable among them by means of their attributes. The
client will use the service: URL to bind directly to a service.
These attributes will be specified as shown with the "service-
template", described below. If a service: URL is stored by a client
or an agent representing a client, the agent SHOULD also keep track
of the attributes which characterize the service offered at the
network location indicated by the URL, and can use the service
template for additional information about those service attributes.
The registration of this attribute information is typically done
using the Service Location Protocol [10], although manual techniques
and other protocols may be possible.
3. Specifying A New Service Type
A Service Type defines the syntax for all URLs that will be
registered by services of the particular type. For instance, a
'Printer' service type is defined with service: URLs in the following
form:
service:printer://<address of printer>/<queue name>
The service agent registering the printer service can be selected by
clients specifying the protocol which matches the protocol attribute
registered with the printer URL above. The attribute information can
be used to indicate other configuration details, optional features
available and characteristics (which may be relevent to a human user
or to a program.)
3.1. Service Type Specifications
Service Type specifications define the fields described in the
following subsections, and define the syntax of the service-part of
service: URLs of that service type.
3.1.1. Service Type
This is a string which will be prepended by the 'service:' scheme.
It may be a name which is entirely invented or be the same as a well
known service scheme. For example, service:http: might refer to a
HTTP server, whereas the http: scheme used in a URL generally refers
to a document.
The meaning of this service type must be fully described by service
type specification. A network protocol specification is often
Guttman,Perkins Expires 6 December 1997 [Page 7]
Internet Draft Service Templates and URLs 6 June 1997
included as one of the attributes associated with the service, and
may optionally be registered by some service agents as part of the
service: URL include in the service registration.
3.1.2. The service: 'url-path' information
This information is included in the URL in order to provide uniquely
identifying information. This mechanism is used in the examples
which follow in order to identify a mountable filesystem (using the
'nfs' service type) and an lpd print queue (as described above).
The syntax and interpretation of the url-path must accompany the
definition of a new Service Type. See section 3.3.3, describing the
mandatory "template.url-path rules" attribute. The url-path may be
very simple, or even entirely omitted except possibly a terminating
slash. See [4] for examples and general guidance.
3.1.3. Attributes
This information provides information about the service's
capabilities, characteristics and required client configuration.
Each attribute which is defined must have a default value and
definition of all values it can take.
An attribute may take one or more values. A keyword does not take
any values. Registration, deregistration and the use of attributes
in queries may be accomplished using Service Location Protocol, or
possibly other means beyond the scope of this document.
3.2. Specifying Attributes
Attributes are used to convey information about a given service for
purposes of differentiating different services of the same type.
They convey information to be used in the selection of which service
to bind to, either browsers or for use by a program.
Attributes may be encoded in different character sets and in
different languages. The procedure for doing this is described in
Section 9.
Attributes definitions have several components.
1. The first is a 'tag'. This is a string with certain encoding
rules.
Guttman,Perkins Expires 6 December 1997 [Page 8]
Internet Draft Service Templates and URLs 6 June 1997
2. Attribute descriptors (type and flags)
3. Possibly, a set of typed values.
4. Descriptive help text explaining necessary information about what
the attribute is
Attributes (but not keywords) may have one or more values. Values of
an attribute are typed, and must have the same type for each value if
the attribute is multivalued. The rules for typing and encoding of
attribute values is given in the rest of section 3.2.
3.2.1. Service Templates and attributes
Service Templates provide rules for attributes. They define:
- Which attributes are REQUIRED with every service registration of
a given service type, and which are OPTIONAL.
- The type of values possible for the attribute (e.g., STRING).
- Whether the attribute may take multiple values.
- Whether the attribute may take arbitrary values or only those
provided in the list.
- Whether the attribute may be translated to other languages or is
a 'literal', ie. not meant for human readability.
- Whether the service: URL can be be supplied in response to a
request that does not give a value for the attribute, when the
attribute is used as part of the registration for that service:
URL.
3.2.2. Service Templates String Encoding
Service templates are encoded in a simple form. They may be
translated to any language or character set, but the template used
for standardization MUST be encoded in ASCII [2] and be in English.
Between each attribute definition there is a blank line. The rules
for encoding attributes is given below. Reserved characters include
";", "&", "=", ",", "*", "#", TAB, LF, and CR. Reserved characters
may be escaped. The escaped character is replaced by a character
sequence with no spaces. The digits are a decimal representation of
Guttman,Perkins Expires 6 December 1997 [Page 9]
Internet Draft Service Templates and URLs 6 June 1997
the character value to be replaced, in the character set used for the
attribute encoding.
Some attributes may take values only among those present in a
specified value list. A keyword has no value list included. Any
attribute or keyword definition may include help text which can be
used to provide interactive descriptions helpful to people browsing
the available services. This descriptive text is often used to
explain technical details about the attribute or about the values
which the attribute can take.
esc-char = "&" "#" 1*DIGIT ";"
The following special case should be noted:
- Commas are used to separate list elements (e.g., allowable
attribute values. To use a comma in attribute encodings, escape
the comma with ,
Service Templates have the following ABNF [6] grammar:
NOTE that this grammar is not quite correct yet, because it
needs a lot of work on specifying the scheme-def.
template = scheme-props scheme-def attr-defs
schemeatrs = schemevers schemelang schemetype schemetext
schemevers = "Version" "=" 1*DIGIT "." 1*DIGIT
schemelang = "Language" "=" 2*2lower-alpha
schemetype = "Type" "=" *schemechar
schemechar = ALPHA / DIGIT / "-" / "_" / "$" / "+" /
"@" / "." / "|" / "<" / ">" / "~"
schemetext = "Scheme-description" "=" [help-text]
scheme-def = url-path-rules
; Rules for constructing service: URLs:
; The scheme-def part of the template will
; be text describing the allowable format
; of information in the url-path of the
; service-part of the service scheme.
; The <addr-spec> and FAQ fields do not
; require additional specification.
attr-defs = *(attr-def/keydef)
attr-def = tag "=" attrtail newline
keydef = keyword "=" "KEYWORD" newline
attrtail = type flags newline [value-list] [help-text]
value-list = 1#value newline
help-text = 1#help-line
; This is a human readable description of
Guttman,Perkins Expires 6 December 1997 [Page 10]
Internet Draft Service Templates and URLs 6 June 1997
; this attribute and its values.
help-line = *[white-sp] "#" *[ com-chars ] newline
tag = 1*attrchar
keyword = 1*attrchar
attrchar = 1*(schemechar / ":"
flags = ["M"] ["L"] ["X"] ["O"]
; M means multiple values are allowed
; L "Literal", values MUST NOT be translated
; X means explicit match required
; O "Optional", the attribute may be omitted
value = string / integer / boolean / opaque
type = "STRING" / "INTEGER" / "BOOLEAN" |
"OPAQUE" / "KEYWORD"
; These strings are not to be translated.
string = safe-char *[safe-chars / SPACE] safe-char
integer = [-] 1*DIGIT
; The integer MUST fall within the range of
; values a 32 bit integer may take, ie.
; -2147483648 to 2147483647.
boolean = "TRUE" / "FALSE"
; These strings are not to be translated.
com-chars = safe-char / white-sp / "*" / "," / ";"/ "&"
safe-char = attrchar / " " / "!" / '"' / "%" / "'" /
"(" / ")" / "+" / "," / "-" / "." / "|" /
":" / "=" / "?" / "[" / "]" /
"" / "/" / "" / " "
; All ASCII printable characters are
; included except ",", "&", "*" and "#".
white-sp = SPACE / TAB
rad64-char = ALPHA / DIGIT / "+" / "-" / white-sp
opaque = 1*DIGIT ":" 4*rad64-char
; The digits define the original length of
; the opaque value. The restricted character
; string is the radix-64 encoding of the opaque
; value. See [5], Section 5.2.
; NOTE: White space is ignored in decoding
; radix-64 values.
newline = CR / ( CR LF )
Guttman,Perkins Expires 6 December 1997 [Page 11]
Internet Draft Service Templates and URLs 6 June 1997
ABNF should have some way of denoting a continuation
line! Otherwise, it is ambiguous whether a next line is a
continuation or starts with some bizarro nonterminal.
Note on the use of white space:
A string is considered to be a token in the case of a tag or
<string> value. In this case, the string is 'trimmed'. White space
interior to a string token is left alone, while white space between
the tokens is removed. For example:
" some name = some value , another example "
would be trimmed to
"some name" '=' "some value" and "another example".
Notes on string matching:
Attribute tags and values may be used by some protocols for directory
look-up. In this case, the following rules should be applied for
string matching of attribute strings.
Decoding character escape and trimming white space MUST be performed
before string matching. In addition, string matching SHOULD be case
insensitive.
3.2.3. Attributes with multiple values
Attributes with multiple values must be defined so that the type of
each value is the same. Boolean attributes may not take multiple
values.
Attributes and values must be given in exactly the same order in
translated service templates. This will allow the service templates
to be used to translate attributes and values to other languages
(using service templates as look up tables.)
3.2.4. Grouping attribute values together in records
Some attributes may be related, which is to say, not independent.
Each configuration, for instance, might have a limitation and a best
use. If these were encoded in separate attributes, the dependency
would not be clear:
Guttman,Perkins Expires 6 December 1997 [Page 12]
Internet Draft Service Templates and URLs 6 June 1997
Configuration = A,B,C
Restriction = slow,large,unpredictable,low-priority
Best Use = cpu-intensive,batch-jobs,interactive-use
Which is slow, A, B or C? Are interactive jobs unpredictable? The
suggested convention is to choose one of the attributes ranges to be
the attribute base. Here, it will be the configuration. The others
attributes are, by conventions, extensions of this record. The
following makes all dependencies explicit:
Configuration-A.Restriction = slow,low-priority
Configuration-A.Best-Use = batch-jobs
Configuration-B.Restriction = unpredictable
Configuration-B.Best-Use = interactive-use
Configuration-C.Restriction = large
Configuration-C.Best-Use = cpu-intensive
Note that the use of such grouping is conventional, by use of the
dot as an <tag> character, and does not place any constraint on
the parsing mechanisms used by agents storing the visually related
attribute values.
3.3. Special attributes
Every service template must define the following attributes:
3.3.1. Service Type Language
This is a two letter code defining the language of the template [8].
3.3.2. Version
The version of the Service Type template. A proposal starts at 0.0,
and the minor number increments once per revision. The Version
attribute has a string value of the form:
version = 1*DIGIT '.' 1*DIGIT
A standardized template starts at 1.0. Additions of attributes add
one to the minor number, where changes of definition or removal of
attributes or values adds one to the major number. See Section 4 for
more detail on how to use the Version attribute.
Guttman,Perkins Expires 6 December 1997 [Page 13]
Internet Draft Service Templates and URLs 6 June 1997
3.3.3. url-path rules
This is a text attribute which defines the semantics of the url path
of the service: URL of the given type.
The <service-part> is of the form:
/<addr-family>/<addr-spec>/<url-path>;FAQ
The <url-path> description specifies additional information to locate
a service when the <addr-spec> is not sufficient, and is a field
whose content that distinguishes URLs of a particular service type
from those of another service type. For instance, in the case of a
printer service: URL, the url-path will typically be a queue name,
but not in the case of a service: URL for any other service type.
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 of the use for the service: URL.
This MUST have its 'Version' attribute set to "0.0" initially.
The minor version number will increment once with each change until
it achieves 1.0. There is no guarantee any version of the service
template will be backwards compatible before it reaches 1.0.
Once a service template has reached 1.0, the definition is "frozen"
for that version. New templates may be defined, of course, to refine
that definition, but they must follow these rules:
- Any new attribute defined for the template will increase the
minor version number by one. All other attributes for the
version must continue to be supported as before. A client which
supports 1.x can still use later versions of 1.y (where x<y) as
it will ignore attributes it doesn't know about.
- Deprecating or changing the definition of an attribute requires
changing the major version number of a service template. A user
agent 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 info.
The template should be posted to the Service Location Working Group
mailing list for review. Ideally, experts in the implementation and
deployment of the particular protocol will be consulted so as to add
Guttman,Perkins Expires 6 December 1997 [Page 14]
Internet Draft Service Templates and URLs 6 June 1997
more attributes or change their definition to make them as useful as
possible.
All published versions of the template must be available on-line,
including obselete ones.
QUESTION:
Where?
Once there is no more active dissent the Service Type should be
reissued with possible corrections, having its Version number set to
"1.0". If there is no comment on the template after 3 months, it
should be considered to have been accepted.
5. Encoding Rules for Service Type URLs
Much of this material is directly adapted from [4]. Note that the
syntax for the url-path depends upon the Service Type definition.
See Section 3. The ABNF for a service: URL is:
service: URL = "service:" service-type ":" service-part
service-type = 1*[ low-alpha / DIGIT / "+" / "-" / "." ]
low-alpha = "a".."z"
service-part = "//" login [ "/" url-path ]
login = [ user "@" ] hostport
hostport = host [ ":" port ]
host = hostname / hostnumber
hostname = hostlabel *[ "." domainlabel ]
okchar = ALPHA / DIGIT
domainlabel = okchar / okchar *[ okchar / "-" ] okchar
hostlabel = ALPHA / ALPHA *[ okchar / "-" ] okchar
hostnumber = ipv4-number / ipv6-number
ipv4-number = 1*3DIGIT 3*3("." 1*3DIGIT)
ipv6-number = 32hex
port = 1*DIGIT
user = *[ uchar / ";" / "?" / "&" / "=" ]
url-path = *xchar ; each Service Type must define its
; own syntax (section 3)
safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / ","
hex = DIGIT / "A".."F" / "a".."f"
escape = "%" hex hex
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
unreserved = ALPHA / DIGIT / safe / extra
uchar = unreserved / escape
xchar = unreserved / reserved / escape
Guttman,Perkins Expires 6 December 1997 [Page 15]
Internet Draft Service Templates and URLs 6 June 1997
6. Examples
The Service Templates for the SLP Directory Agent and POP3 service
are given below.
6.1. SLP Directory Agent
The directory-agent service type has no attributes except scope.
6.2. POP3
template.service-type = STRING L
POP3
# This is the template for the POP3 service.
template.version = STRING L
0.0
# This is the preliminary version of the template.
template.description = STRING
The question is how to make this string exceed one line
# Clients which wish to make use of POP3 service need to be
# configured to use the correct POP3 server. The server may
# or may not be able to use the APOP authentication mechanism.
# Clients are able to discover which POP3 server is the correct
# one for them and whether they can use the APOP to authenticate
# themselves. Finally, the POP3 server policy may be
# included.
template.url-path-rules = STRING
The url-path is omitted.
#
template.language = STRING L
en
# The default template is in English.
Mailboxes = STRING M L
# This is a list of all users (by user name) which the POP3
# server supports.
APOP = BOOLEAN L
Guttman,Perkins Expires 6 December 1997 [Page 16]
Internet Draft Service Templates and URLs 6 June 1997
FALSE
# This determines whether the POP3 server supports APOP
Policy = STRING O
# This optional attribute describes the POP3 server's policy
# regarding its use. For instance, are users dissuaded or
# disallowed from keeping mail on the server? Is there a
# quota? Is mail older than a certain number of days erased?
7. General Service Template
The service-template Service Type has 4 attributes, followed by the
service: URL definition for the service type and the collection of
attribute specifications for the service type.
version = STRING L
# This is the version number of the template.
# It is expressed in X.Y notation, where X is the major
# and Y is the minor version number.
service type = STRING L
# The value of this attribute is a service type string.
description = STRING
# The service type is described here. This is a paragraph or
# so of text which describes how to interpret the service: URL
# for this particular service type. It should be clear what
# protocol or protocols can bind to the service access point
# which the service: URL resolves to.
Language tag = STRING L
en
# The Language tag used in the service type template. This is
# an ISO-639 two letter language code.
service-URL = STRING
# A way of describing the structure of the <service-part>
# is for the service type being specified.
attr-specs = STRING M
# The value of this attribute is the template text, defining
# all the service type attributes.
Of the mandatory attribute tags, only "description" may be translated
into another language (see Section 9.)
Guttman,Perkins Expires 6 December 1997 [Page 17]
Internet Draft Service Templates and URLs 6 June 1997
The description field should be a paragraph of text describing the
attribute and the all the values it can take on. This information
will be used by those who develop user interfaces to display service
information and those who advertise services using attributes
associated with the service: URL.
7.1. Obtaining Service Templates dynamically
The service template is registered as a service type by any SA which
has a template. The SA SHOULD query the DA to determine if the
service template has already been registered, and if so, abstain from
registering the service template.
This is an area which definitely needs work. The difficulty
is that in order for a service template to be retrieved as
an attribute of some registered service: URL (presumably
of type service:template:), one would have to allow extra
newlines and space and reserved characters in tricky places.
On the other hand, devising a new method (a new service) of
handing out such information is not immediately attractive.
8. Internationalization Considerations
The service: URL itself must be encoded using the rules set forth
in [4]. The character set encoding is limited to specific ranges
within the US-ASCII character set [2].
The attribute information associated with the service: URL may be
expressed in any character set, and in any language.
8.1. Character Set identification and use
The way of identifying the character set used is the IANA Character
Set registry official name, found at:
http://www.isi.edu/in-notes/iana/assignments/character-sets
US-ASCII MUST be supported.
For other encodings, the repository of the service template or the
protocol which transmits attributes (for registration or query
purposes) must be able to identify the encoding using an external
mechanism. It would make no sense to use an 'internal' designation
for marking the character encoding, as the attribute information is
itself string encoded. The Service Location Protocol [10] makes the
Guttman,Perkins Expires 6 December 1997 [Page 18]
Internet Draft Service Templates and URLs 6 June 1997
character encoding for each registration, query and query result
explicit in the protocol header, for example.
All attribute information in a single transmission, file, etc. MUST
be in the same character encoding.
8.2. Language identification and translation
The language used in attribute string should be identified using a
Language tag as defined by [1].
A program may translate a service advertisement from one language
to another provided it has both the template of the language of the
advertisement and the template of the desired target language. All
standardized attributes will be in the same order in both templates.
All non-arbitrary strings (such as tags and set members) will be
directly translatable from one language to another. Free text and
nonstandard attributes may not be automatically translated in this
manner.
Shouldn't help text be translatable? What is free text?
All strings used in attributes (tags and values) are assumed to
be able to be translated unless explicitely defined as should
be literal, so that best effort translation (see below) will not
obfuscate strings which are meant to be interpreted by a program, not
a person.
There are two ways to go about translation: Standardization and best
effort.
When the service type is standardized, more than one document may be
submitted for review. One service type description is registered
for each language. These descriptions must be kept in sync, so that
when a service type template is updated in one language, all the
translations (at least eventually) reflect the same semantics.
If no document exists describing the standard translation of the
service type, a 'best effort' translation for strings may be done.
9. Security Considerations
Service type templates provide information which will be used to
interpret information obtained by the Service Location Protocol. If
these templates were modified or false templates were distributed,
Guttman,Perkins Expires 6 December 1997 [Page 19]
Internet Draft Service Templates and URLs 6 June 1997
services may not correctly register themselves or clients might not
be able to interpret service information obtained by SLP.
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
which a user would normally want to use. SLP distributes Service
URLs and has an authentication mechanism which allows Service URLs of
advertised services to be signed and these signatures to be verified
by clients.
Guttman,Perkins Expires 6 December 1997 [Page 20]
Internet Draft Service Templates and URLs 6 June 1997
References
[1] H. Alvestrand. Tags for the Identification of Languages. RFC
1766, March 1995.
[2] ANSI. Coded Character Set -- 7-bit American Standard code for
Information Interchange. X3.4-1986, 1986.
[3] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform
Resource Locators (URL): Generic Syntax and Semantics.
draft-fielding-url-syntax-05.txt, May 1997. (work in progress).
[4] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). RFC 1738, December 1994.
[5] N. Borenstein and N. Freed. MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies. RFC 1521, September
1993.
[6] D. Crocker and P Overell. Augmented BNF for Syntax
Specifications: ABNF. draft-ietf-drums-abnf-02.txt, November
1996. (work in progress).
[7] A. Gulbrandsen and P. Vixie. A DNS RR for specifying the
location of services (DNS SRV). RFC 2052, October 1996.
[8] Geneva ISO. Code for the representation of names of languages.
ISO 639:1988 (E/F), 1988.
[9] R. Moats and M. Hamilton. Finding Stuff(Providing information to
support service discovery). draft-ietf-svrloc-advertise-00.txt,
February 1997. (work in progress).
[10] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol, April 1997. draft-ietf-svrloc-protocol-17.txt
(work in progress).
Authors' Addresses
Questions about this memo can be directed to:
Erik Guttman Charles E. Perkins
Sun Microsystems Sun Microsystems
Gaisbergstr. 6 2550 Garcia Avenue
D-69115 Heidelberg Mountain View, CA 94043
Germany USA
Guttman,Perkins Expires 6 December 1997 [Page 21]
Internet Draft Service Templates and URLs 6 June 1997
Phone: +1 415 336 6697 1 415 336 7153
email: Erik.Guttman@eng.sun.com cperkins@corp.sun.com
Guttman,Perkins Expires 6 December 1997 [Page 22]
