view Side-By-Side changes
Service Templates and service: Schemes
draft-ietf-svrloc-service-scheme-01.txt
draft-ietf-svrloc-service-scheme-02.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
The 'service:' URL scheme name is used to define URLs (called "service: URLs"
'service: URLs' in this document) which that are primarily intended to be
used by the Service Location Protocol in order to distribute service
access information. These schemes provide an extensible framework
for client based client-based network software to obtain configuration information
required to make use of network services. When registering a
service: URL with a
Directory Agent, URL, the URL may SHOULD be accompanied by a set of well defined well-defined
attributes which define the charateristics of the service. These attributes may SHOULD
convey configuration information to client software, or service
characteristics meaningful to end users.
Guttman,Perkins,Kempf Expires 31 December 1997 [Page i]
Internet Draft Service Templates and URLs 31 July 1997
This document describes how to define a formal procedure for defining and standardize
standardizing 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
"service:" scheme. The formal descriptions of service types and URLs 6 June 1997
Templates. These
attributes are templates that are human and machine readable. They
may
SHOULD be used by administrative tools to parse service registration
information and by client applications to provide localized
translations of service attribute strings.
Guttman,Perkins
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page ii]
Internet Draft Service Templates and URLs 6 June 31 July 1997
Contents
Status of This Memo i
Abstract i
1. Introduction 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Service Schemes . . . . . Location Protocol . . . . . . . . . . . . . . . . 4
1.3.
2. Related work 4
3. Service URL Syntax and Semantics 4
3.1. Service URL Syntax . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Changes made since the last version . . . . . . 4
3.2. Service URL Semantics . . . . . 5
1.5. Open issues and work to be done . . . . . . . . . . . . . 6
2.
3.3. Use of service: URLs 6
3. Specifying A New Service Type 7
3.1. Service Type Specifications . . . . . . . . . . . . . . . 7
3.1.1. Service Type . . . . . . 8
3.4. Specifying the Service Type-Specific URL Syntax . . . . . 8
3.5. Accommodating Abstract Service Types . . . . . . . 7
3.1.2. The service: 'url-path' information . . . 9
3.5.1. Advertising Arbitrary URL's . . . 8
3.1.3. Attributes . . . . . . . . 9
3.5.2. Advertising with Contact Information . . . . . . 10
4. Syntax and Semantics of Service Type Specifications 11
4.1. Syntax of Service Type Templates . . . . . 8
3.2. Specifying Attributes . . . . . . . 11
4.2. Semantics of Service Type Templates . . . . . . . . . . . 8
3.2.1. 14
4.2.1. Definition of a Service Templates and attributes Template . . . . . . . . 9
3.2.2. 14
4.2.2. Service Templates String Encoding . . . Scheme . . . . . 9
3.2.3. Attributes with multiple values . . . . . . . . . 12
3.2.4. Grouping attribute values together in records . . 12
3.3. Special attributes . . . . . 15
4.2.3. Service Type Language . . . . . . . . . . . . . . 13
3.3.1. Service Type Language 15
4.2.4. Version Number . . . . . . . . . . . . . . 13
3.3.2. Version . . . 15
4.2.5. Description . . . . . . . . . . . . . . . . . . 13
3.3.3. url-path rules . 15
4.2.6. Syntax of the Service Type-specific URL Part . . 15
4.2.7. Attribute Definition . . . . . . . . . . . . . . 14
4. 16
5. A Process For Standardizing New Service Types 14
5. Encoding Rules for Service Type URLs 15 20
6. Examples 16 Internationalization Considerations 21
6.1. SLP Directory Agent Character Set Identification and Use . . . . . . . . . . . . . . . . . . . 16 21
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 Identification and translation Translation . . . . . . . . . 19
Guttman,Perkins 22
7. Security Considerations 22
8. Changes Made Since the Last Version 23
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 1]
Internet Draft Service Templates and URLs 6 June 31 July 1997
9. Security Considerations 19
1. Introduction
This document describes a class of schemes URL scheme, called service: URL, which will allow
defines network
services to define their service access information, information for network services using a standard
formal notation. In addition it describes how to define a set of
attributes to associate with a service: URL. These attributes will
allow end users and programs to select between network services of
the same type that have different capabilities. The attributes
are defined in a template document that is readable by people and
machines.
A client may use these uses attributes to select a particular service
(obtain service. Service
selection occurs by obtaining the service: URL) URL that has the
configuration it the client needs. The
minimal encoding rules for attributes are specified. Service Type type templates are used to describe in a standard way those
services which use define the
syntax of service: URL. The rules URLs for specifying a
scheme are provided, along with two examples. particular service type, as well as the
attributes which accompany a service: URL in a service advertisement.
Templates are used for the following distinct purposes:
1. Standardization
The template is reviewed before it is standardized. Once it is
standardized, all versions of the template are archived by IANA.
2. Service Registration
Servers making use of the Service Location Protocol will [19] register
themselves and their attributes. They will use the templates to
generate the service registrations; registrations. In registering, 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 service may use templates to register services itself in more than one language, language
using templates, 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?
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 2]
Internet Draft Service Templates and URLs 31 July 1997
All grammar encoding follows the Augmented BNF (ABNF) [6] [9] for syntax
specifications with a few deviations.
QUESTION: What are the deviations?
specifications.
1.1. Terminology
In order to reduce confusion,
This section introduces some terminology is introduced. for describing 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:".
URLs.
service scheme
A scheme, URL scheme whose name start starts with the string "service:" and
is followed by the service type name, constructed according to
the rules in this document. An example is "service:lpr:" for
the lpr print service template [18].
service: URL
A formal description URL, registered by a service agent of a particular service
type, that conforms to a service scheme definition. The
URL acts as an advertisement for the service, through
which potential clients can discover the service attributes and its
capabilities. An example is service:lpr://server.eng/printer1.
service type
A name denoting either a particular network protocol, or an
abstract service
scheme associated with a particular variety of protocols. If
the service type. type denotes a particular protocol, then the
service may type name should either be selected assigned to a particular
well known port [3] by obtaining convention or or be the Assigned Numbers
name for the service [1].
abstract service type
A service type name which is associated with a variety of
different protocols. An example from [13] is "wp". Section 3
discusses various ways that abstract types can be accommodated.
service advertisement
A service: URL
registered and optionally a set of attributes comprise a
service advertisement. This advertisement is made by that or on
behalf of a given service.
general The URL syntax and attributes must
conform to the service template
A template for describing service templates -- for instance as
is contained within this document.
Guttman,Perkins the advertised service.
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 3]
Internet Draft Service Templates and URLs 6 June 31 July 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 template
A formal description of the service type attributes and address of a network service. It may
additionally include service type specific information.
scheme associated with a particular service type.
1.2. Service Location Protocol
The form Service Location Protocol allows service: URLs to be advertised
and discovered, [19], though service: URLs may be also used in other
contexts.
Client applications discover service advertisements by issuing
queries for services of a service: URL is as follows:
"service:" service-type ":" service-part
where the service-part typically has particular type, specifying the following form:
/addr-family/addr-spec/url-path;FAQ
and attributes
of the last field is never required service: URLs to exist in any return. Clients retrieve the attributes of a
particular service
location registration, but is sometimes provided by supplying its service: URL. Attributes for convenience all
service advertisements of
interactive user agents. The formal syntax for a particular type can also be retrieved.
Service may advertise themselves, or advertisements may be made on
their behalf. These advertisements contain a service: URL is
given in Section 5. URL, and
possibly attributes and digital signatures.
2. Related work
The service-type string indicates the "Finding Stuff" work by Ryan Moats, Martin Hamilton, and
Paul Leach uses service: URLs to provide access information about
arbitrary network protocols through DNS [14]. DNS SRV Resource
Records are a mechanism which provides a way to obtain a service by
type for a given domain [10], without specifying which instance of service. The
the service type determines would meet particular requirements.
3. Service URL Syntax and Semantics
This section describes the syntax and semantics of the service-part and service: URLs.
3.1. Service URL Syntax
The syntax of the
attributes associated with the service: URL. URL MUST conform to [6]. The <addr-family> only
exception is
IP by default (if not present), but can be used to indicate that the use
other address families such as IPX and Appletalk. In this document, <password> field has been omitted from the addr-family>
<site> production, since plain text transmission of passwords is always IP, so
now discouraged. Note that the syntax for the <sap> 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 depends
upon the service or
resource if the <addr-spec> is not sufficient for that purpose. type definition. The FAQ <sap> field 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 service
access point, and needs to ask questions about describes 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 access the service: URL service. In addition,
although both upper case and lower case characters are
not typically included recognized in
the URL. They are stored and retrieved
using other mechanisms. The service: URL is uniquely identified
with a particular service agent, and <service-type> field for convenience, the name is used when registering
Guttman,Perkins case-folded
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 4]
Internet Draft Service Templates and URLs 6 June 31 July 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.
into lower case. Service
agents would types are therefore not typically advertise URLs with FAQs unless manually
configured to do so by a system administrator, distinguished on
the basis of case, so, for example, "http" and a user agent that
obtains "HTTP" designate the
same service type. This is consistent with general URL practice, as
outlined in [7].
The ABNF for a service: URLs by issuing URL is:
service: URL = "service:" service-type ":" sap
service-type = abstract-type / protocol
abstract-type = type-name [ "." naming-auth ]
type-name = resname
naming-auth = resname
protocol = resname
; An Assigned Numbers name [1] or
; well known port name [3] for
; the protocol.
resname = 1*[ alpha / digit / "+" / "-" ]
sap = "/" [ addr-family ] "/" site [ url-part ]
addr-family = *xchar ; depends on the address family
site = [ [ user "@" ] hostport ] / [ other-addr ]
hostport = host [ ":" port ]
other-addr = *xchar ; depends on the address family
host = hostname / hostnumber
hostname = *( domainlabel "." ) toplabel
alphanum = alpha / digit
domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum
toplabel = alpha / alpha *[ alphanum / "-" ] alphanum
ipv4-number = 1*3digit 3*3("." 1*3digit)
ipv6-number = 32*hex
3digit = digit digit digit
port = 1*digit
user = *[ uchar / ";" / "+" / "&" / "=" ]
url-part = [ url-path ] [ attr-list ]
url-path = 1 * ( "/" *xchar )
; Each service type must define its
; own syntax consistent
; with [6].
attr-list = 1 * ( ";" attr-asgn )
attr-asgn = attr-id / attr-id "=" attr-value
safe = "$" / "-" / "_" / "." / "~"
extra = "!" / "*" / "'" / "(" / ")" / "," / "+"
uchar = unreserved / escaped
xchar = unreserved / reserved / escaped
escaped = "%" hex hex
hex "a" / "b" / "c" / "d" / "e" / digit
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
unreserved = alpha / digit / safe / extra
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 5]
Internet Draft Service Templates and URLs 31 July 1997
alpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" /
"h" / "i" / "j" / "k" / "l" / "m" / "n" /
"o" / "p" / "q" / "r" / "s" / "t" / "u" /
"v" / "w" / "x" / "y" / "z" /
"A" / "B" / "C" / "D" / "E" / "F" / "G" /
"H" / "I" / "J" / "K" / "L" / "M" / "N" /
"O" / "P" / "Q" / "R" / "S" / "T" / "U" /
"V" / "W" / "X" / "Y" / "Z"
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
3.2. Service URL Semantics
The service scheme-specific information following the "service:"
URL scheme identifier provides information necessary to access the
service. As described in the previous subsection, the form of a
service: URL is as follows:
service: URL = "service:" service-spec ":" sap
where <sap> has the following form:
/addr-family/addr-spec/url-path;attr-list
The <service-spec> field includes the <service-type> field. As
discussed in Section 1, the <service-type> can be either a concrete
protocol name, or an abstract type name.
The protocol determines the semantics <sap> (for service
access point) field, and of attributes associated with it.
The <addr-family> field indicates the network layer protocol
type [2] through which the service communicates with clients. The
<addr-family> field is null by default, indicating the Internet
Protocol (IP), but it can be used to indicate other address families
such as IPX [17] or Appletalk [11].
The <service-part> field includes a site specification (the
<site> field) in the format specified by [6]. The <site> field
is typically either a domain name (DNS) or an IP or other network
protocol address for the service, and possibly a port number. If
another address family is specified in the <addr-family> field, the
exact syntax of the <site> field depends on the address family. The
<site> field can be null if other information in the service URL or
service attributes is sufficient to use the service.
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 6]
Internet Draft Service Templates and URLs 31 July 1997
The <sap> field allows more information to be provided (by way of
<url-path> and <attr-list>) that can uniquely locate the service or
resource if the <addr-spec> is not sufficient for that purpose.
An <attr-list> field appears at the end of the <url-part> field,
but is never required to exist in any service location registration.
The <attr-list> field is composed of a list of semicolon (";")
separated attribute assignments of the form:
attr-id "=" attr-value
or for keyword attributes:
attr-id
Attributes are part of service: URLs when the attributes are required
to access a particular service. For instance, an ACAP [16] service
might require that the client authenticate with it through Kerberos.
Including an attribute in the service advertisement allows the ACAP
client to make use of the correct SASL [15] authentication mechanism.
The ACAP server's advertisement might look like:
service:acap://some.where.net;authentication=KERBEROSV4
Note that there can be other attributes of an ACAP server which would
not be appropriate to include in the URL. For instance, the list
of users who have access to the server is useful for selecting an
ACAP server, but is not required for a client to use the advertised
service.
Attributes associated with the service: URL are not typically
included in the service: URL. They are stored and retrieved using
other mechanisms. The service: URL is uniquely identified with a Service Request will already
have all
particular service agent or resource, and is used when registering or
requesting the necessary attribute information. The Service Location Protocol
specifies how such information to make use of the
service: URL. SHOULD be advertised by network
services and obtained by client software.
Attributes are associated with service: URLs for three reasons:
1. Many servers Attributes associated with a given URL allow for automatic
selection of services that have optional certain features. Clients Client
software having particular requirements can choose services
based on those requirements. For example, client software may
require a server which has the right font, or which has access to
specific hardware resources.
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 7]
Internet Draft Service Templates and URLs 31 July 1997
2. Attributes provide a mechanism by which servers can advertise
optional features or dynamic qualities. Clients that require or
prefer to make use of these optional features or dynamic information
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 a wide variety of characteristics,
including physical location, access restrictions and characteristics (even dynamic
qualities,
characteristics 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. load.
3. Attributes support selection of service instances by
characteristic as opposed to simply by type. These attributes name. Attributes may
be used to give users people 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 using a graphical user interface, for example.
3.3. Use of 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 service: URL is intended to obtain a service by
type for a given domain [7], without being able allow arbitrary client/server and
peer to specify which of
the (possibly numerous) instances peer systems to make use of the a standardized dynamic service type would satisfy
access point discovery mechanism.
It is intended that service: URLs be selected according to the needs
suitability of associated attributes. A client application can
obtain 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 several services of the Service Specific Multicast Addresses (which
are no longer needed in same type and distinguish
the Service Templates.)
- 'Record based' attribute values.
- The possibility for putting CR, LF, or TAB in most places.
Added:
- Terminology
- Further explanation preferable among them by means of Service Templates.
- New syntax for Service Templates.
- A proposal on how their attributes. The
client uses the service: URL to use Templates for internationalization.
- Some security considerations.
1.5. Open issues and work bind directly to be done
- Justification will be added (as done a service.
Attributes are specified with a formal service template syntax
described in the Section 4. If a service: URL process
draft [3]).
- Encoding rules for transforming is stored by a Service Template to client or
an LDAP
Schema will be added.
- The process for standardizing agent representing a new service type needes to be
sharpened. In particular, feedback from client, the Applications Area
Directors needs to be solicited.
- Description agent SHOULD also keep track of how
the attributes which characterize the service.
Registrations can be checked against the formal attribute
specification defined in the template by the client or agent
representing the client. Service Templates themselves advertisement 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: done using the
Service Location Protocol [19].
3.4. Specifying the Service Type-Specific URL is intended to allow arbitrary client/server and
peer to peer systems to make use of Syntax
When a standardized dynamic service
access point discovery mechanism.
It type is intended that service: URLs be selected according to specified, the
suitability specification includes the
definition of associated attributes. A client application may
obtain the syntax for all URLs of several that are registered by services
of that particular type. For instance, the same "lpr" service type and distinguish
Guttman,Perkins [18]
is defined with service: URLs in the following form:
service:lpr://<address of printer>/<queue name>
The section of the URL after the address of the printer:
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 6] 8]
Internet Draft Service Templates and URLs 6 June 31 July 1997
"/" <queue name>
is specific to the most preferable among them lpr service type and corresponds to the
<url-path> field of the general service: URL syntax. This part is
specified when the lpr service type is specified.
3.5. Accommodating Abstract Service Types
An abstract service type is a service type that can be implemented by means
a variety of their attributes. The
client will use different protocols. Two kinds of advertisements for
abstract service types are encouraged by the standard:
1. Advertising arbitrary URL's but including the abstract service
type name in the attributes,
2. Advertising a service: URL with enough information, including the
protocol, to bind directly contact the service and use it but including the
protocol in the attributes,
Other methods of advertising for abstract service types are
discouraged to a service.
These attributes will avoid problems with interoperability.
Each of the two methods is discussed in the following subsections.
3.5.1. Advertising Arbitrary URL's
An abstract service type may be specified as shown associated with a collection
of protocols and URL's that have already been standardized or
are already in widespread use. In such cases, implementors are
encouraged to advertise the "service-
template", described below. If URL's directly, without creating a new
service: URL type.
An example of such an abstract service type is stored by the "wp" service [13].
In this case, "wp" (for "white pages") is an abstract service type
that can map into a client
or variety of different implementation protocols,
for example "ldap", "whois++", etc. Each of these protocols has an agent representing
existing URL either standardized or in widespread use. Rather than
compose a client, new service: URL, the agent service SHOULD also keep track
of be advertised with the attributes which characterize
existing URL scheme and registered under the abstract service offered at type
name "wp".
However, in order that the
network location indicated by URL is clearly identifiable to clients as
an instance of the URL, and can use abstract service type, the service type template for additional information about those service attributes.
The registration of this
MUST include a required attribute information "service-type" whose value is typically done
using set
upon registration to the abstract service type name. The service
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 9]
Internet Draft Service Location Protocol [10], although manual techniques Templates 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 31 July 1997
type name must conform to the particular type. For instance, a
'Printer' syntactic rules for service type is defined with service: URLs names
in the following
form:
service:printer://<address of printer>/<queue name>
The service agent registering the printer service: URL syntax.
3.5.2. Advertising with Contact Information
Some abstract service can types may be selected by
clients specifying the protocol which matches the protocol attribute
registered associated with the printer URL above. The attribute protocols that
do not have URL's in widespread use, or require more information can
be used to indicate other configuration details, optional features
available and characteristics (which may be relevent to
than just a human user
or standardized URL to access the service. In such cases,
implementors are encouraged to develop a program.)
3.1. Service Type Specifications
Service Type specifications define new service: URL type
for the fields described in advertisement, including enough information so that an
application can access the service without further network traffic
involving service location. However, implementors SHOULD avoid
embedded URL's as a matter of style.
For example, suppose a network service is being developed for
dynamically loading device drivers. The client requires the
following subsections, three pieces of information before it can successfully load
and define instantiate the syntax of driver:
1. The protocol used to load the driver code, for example, "ftp",
2. A pathname identifying where the service-part driver code is located, for
example "/systemhost/drivers/diskdrivers.drv",
3. The name of the driver, for example, "scsi".
The temptation is to form the first two items into a URL and embed
that into a service: URLs URL. Rather, the implemention SHOULD develop
a service type-specific service: URL consistent with the syntactic
rules of [6] that contains the information needed to successfully
use the service type.
3.1.1. Service Type
This is a string which will but avoids embedded URL's. An example might be prepended by the 'service:' scheme.
It may be a name which is entirely invented or be
following:
service:device-drivers://
drivers.ra.sys/systemhost/drivers/diskdrivers.drv;
type=scsi;protocol=ftp
where the URL has been broken after the same as a well
known service scheme. For example, service:http: might refer to type field and before
the attribute list for readability.
In this case, a
HTTP server, whereas pathname followed by the http: scheme <attr-list> field syntax
has been used in a URL generally refers to a document. include the attributes required to successfully make
contact with the service and use it. Other syntactic choices are
possible.
The meaning of this service type must be fully described by template for such an abstract service type specification. A network protocol specification is often
Guttman,Perkins
MUST contain required attributes for each piece of contact
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 7] 10]
Internet Draft Service Templates and URLs 6 June 31 July 1997
included as one of the attributes associated with
information beyond the service, pathname, and
may optionally be registered by some service agents as part of the
service: URL include MUST, in any case, include a
required attribute having the service registration.
3.1.2. The service: 'url-path' information
This information identifier "protocol" that is included in set at
registration time to the URL in order protocol needed to provide uniquely
identifying information. This mechanism is contact the service. In
the above example, these attributes would be "type" and "protocol".
Furthermore, the "protocol" attribute definition SHOULD include a
list of allowed values comprising the protocols that can be used in to
contact the examples
which follow service.
4. Syntax and Semantics of Service Type Specifications
Service type specifications are documents in order a formal syntax defining
properties important to identify a mountable filesystem (using service advertisement. These properties
are:
1. General information on the
'nfs' service type) and an lpd print queue (as described above). type specification itself,
2. The syntax and interpretation of the url-path must accompany service type-specific part of the service URL,
3. The definition of attributes associated with a new Service Type. See section 3.3.3, describing service.
The service type specification document is the
mandatory "template.url-path rules" attribute. service type template.
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 following subsections describe the service's
capabilities, characteristics and required client configuration.
Each attribute which is defined must have a default value syntax and
definition semantics 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
service type templates.
4.1. Syntax of attributes Service Type Templates
Service template documents are encoded in queries a simple form. They may be accomplished using Service Location Protocol,
translated into any language or
possibly other means beyond character set, but the scope of this document.
3.2. Specifying Attributes
Attributes are template used to convey information about a given service
for
purposes of differentiating different services standardization MUST be encoded in ASCII [5] and be in English.
A template document begins with a block of the same type.
They convey information text assigning values to be used
five template identification items. The five template identification
items can appear in any order within the selection of block, but conventionally
the "type" item, which assigns the service type name, occurs at the
very top of the document in order to bind to, either browsers or provide context for use by the rest of
the the document. The attribute definition item occurs after the
document identification items.
All items end with a program.
Attributes may be encoded in different character sets single blank line. Reserved characters
encompass ";", "%", "=", ",", "#", LF, and in
different languages. CR. Reserved characters
should be escaped. The procedure for doing this escape sequence is the same as described
in
Section 9.
Attributes definitions have several components.
1. The first [6]. Values in value lists are separated by commas. A value list
is terminated by a 'tag'. This newline not preceded by a comma. If the newline
is preceded by a string with certain encoding
rules.
Guttman,Perkins comma, the value list is interpreted to continue
onto the next line.
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 8] 11]
Internet Draft Service Templates and URLs 6 June 31 July 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 identifiers, 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 names, and attributes
Service Templates provide rules for attributes. They define:
- Which attributes flags are REQUIRED with every service registration all
case insensitive. For ease of
a given service type, presentation, upper 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 lower case
characters can be be supplied in response used to a
request that does not give a value for represent these in the attribute, when template document,
but the
attribute is used result should be case-folded into lower case by parsers
and other tools. Newlines are significant in the grammar. They
delimit one item from another, as part well as separating parts of the registration for that service:
URL.
3.2.2. Service Templates items
internally.
String Encoding
Service templates values are encoded in a simple form. They may considered to be
translated a sequence of non-whitespace
tokens separated by whitespace. String values are trimmed on both
ends to any language or character set, remove whitespace, but the template used
for standardization MUST interior whitespace is not touched.
For example:
" some value , another example "
would be encoded in ASCII [2] trimmed to
"some value" and "another example".
Note that there can be no ambiguity in English.
Between each attribute definition there is string tokenization because
values in value lists are separated by a blank line. The rules
for encoding attributes comma. String tokens are
not delimited by double quotes (") as is given below. Reserved characters include
";", "&", "=", ",", "*", "#", TAB, LF, usually the case with
programming languages.
Attribute tags and CR. Reserved characters
may values can be escaped. The escaped character is replaced used by a some protocols for directory
look-up. In this case, decoding of character
sequence with no spaces. The digits are a decimal representation escapes and trimming
white space MUST be performed before string matching. In addition,
string matching SHOULD be case insensitive.
Templates have the following ABNF [9] grammar:
template = tem-attrs attr-defs
tem-attrs = schemetype schemevers schemelang
schemetext schemeurl
schemetype = "type" "=" scheme termdef
schemevers = "version" "=" version-no termdef
schemelang = "language" "=" isolang termdef
schemetext = "description" "=" newline desc-text termdef
schemeurl = "url-syntax" "=" newline url-bnf termdef
url-bnf = *[ com-chars ]
; An ABNF describing the <url-path> production
; in the service: URL grammar of
Guttman,Perkins Section 3.
scheme = service-type [ "." naming-auth ]
service-type = scheme-name
naming-auth = scheme-name
scheme-name = 1*schemechar [ "." 1*schemechar ]
schemechar = alpha / digit / "-" / "+" /
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 9] 12]
Internet Draft Service Templates and URLs 6 June 31 July 1997
the character value to be replaced, in the character set used
version-no = 1*digit "." 1*digit
isolang = 2*2lower-alpha ;see [12]
desc-text = *[ com-chars ]
; A block of free-form text for reading by
; people describing the
attribute encoding.
Some attributes may take values only among those present service in a
specified short,
; informative manner.
termdef = newline newline
attr-defs = *( attr-def / keydef )
attr-def = id "=" attrtail
keydef = id "=" "keyword" newline [help-text] newline
attrtail = type flags newline [value-list] [help-text]
[value-list] newline
id = 1*attrchar
type = "string" / "integer" / "boolean" / "opaque"
flags = ["m"/"M"] ["l"/"L"] ["x/"X"] ["o"/"O"]
value-list = value list. A keyword has no newline / value list included. Any
attribute or keyword definition may include help "," value-list /
value "," newline value-list
help-text = 1*( "#" help-line )
; A block of free-form text which can be
used to provide interactive descriptions helpful to for reading by
; people browsing
the available services. This descriptive text is often used to
explain technical details about the attribute or about the values
which describing the attribute can take.
esc-char and
; its values.
help-line = *[ com-chars ] newline
attrchar = schemechar / ":" / "_" / "$" / "~" / "@" / "." /
"|" / "<" / ">" / "*" / "&" "#" 1*DIGIT ";"
value = string / integer / boolean / opaque
string = safe-char *[safe-char / space] safe-char
integer = [ "+" | "-" ] 1*digit
boolean = "true" / "false"
opaque = 1*digit ":" 4*radix64-char
; 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 digits define the comma with ,
Service Templates have original length of
; the following ABNF [6] grammar:
NOTE that this grammar is not quite correct yet, because it
needs a lot opaque value. The restricted character
; string is the radix-64 encoding of work on specifying the scheme-def.
template = scheme-props scheme-def attr-defs
schemeatrs
; opaque value( [8], Sect. 5.2.)
; Newlines are ignored in decoding radix-64
; values.
com-chars = schemevers schemelang schemetype schemetext
schemevers safe-char / white-sp / "," / ";"/ "%"
safe-char = "Version" "=" 1*DIGIT attrchar / escaped / " " / "!" / '"' / "'" /
"|" / "(" / ")" / "+" / "-" / "." 1*DIGIT
schemelang = "Language" "=" 2*2lower-alpha
schemetype = "Type" / ":" /
"=" *schemechar
schemechar = ALPHA / DIGIT "?" / "-" "[" / "_" "]" / "{" / "/" / "{" /
"$"
; All ASCII printable characters are
; included except ",", "%", ";", and "#".
escaped = "%" hex hex
hex = digit / "+" "A" /
"@" "B" / "." "C" / "|" "D" / "<" "E" / ">"
"a" / "~"
schemetext "b" / "c" / "d" / "e"
white-sp = "Scheme-description" "=" [help-text]
scheme-def space / tab
newline = url-path-rules
; Rules for constructing CR / ( CR LF )
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 13]
Internet Draft Service Templates and URLs 31 July 1997
4.2. Semantics of Service Type Templates
The service type template defines the service attributes and service: URLs:
;
URL syntax for a particular service type. The scheme-def part attribute definition
includes the attribute type, default values, allowed values and other
information.
4.2.1. Definition of a Service Template
There are six items included in the template will
; be text describing service template. The semantics
of each item is summarized below.
- type
The scheme name of the allowable format
; service scheme. The scheme name consists
of information the service type name and an optional naming authority name,
separated from the service type name by a period. See 4.2.2 for
the conventions governing service type names.
- version
The version number of the service type specification.
- language
The language of the service type specification.
- description
A description of the service suitable for inclusion in text read
by people.
- url-syntax
The syntax of the url-path service type-specific URL part of the
; service-part service:
URL.
- attribute definitions
A collection of zero or more definitions for attributes
associated with 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 in service advertisements.
Each of
Guttman,Perkins the following subsections deals with one of these items.
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 10] 14]
Internet Draft Service Templates and URLs 6 June 31 July 1997
; this attribute
4.2.2. Service Scheme
The service scheme consists of the service type name 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 an optional
naming authority name separated from the service type name by a
period. The service scheme is a string that is appended to the
'service:' URL scheme identifier, and is the value of the "type"
item in the template document. If the naming authority name is
absent it is assumed to be translated
; X means explicit match required
; O "Optional", IANA. As discussed in Sections 1 and 3,
the attribute may service type name should be omitted either a protocol name or an abstract
type name.
4.2.3. Service Type Language
The service type language is a two letter ISO-639 code defining the
language of the template [12] and is the value = string / integer / boolean / opaque of the "language"
item.
4.2.4. Version Number
The version number of the service type = "STRING" / "INTEGER" / "BOOLEAN" |
"OPAQUE" / "KEYWORD"
; These strings are not template is the value of
the "version" item. A draft proposal starts at 0.0, and the minor
number increments once per revision. A standardized template starts
at 1.0. Additions of attributes add one to be translated.
string = safe-char *[safe-chars / SPACE] safe-char
integer = [-] 1*DIGIT
; the minor number, and
changes of definition or removal of attributes adds one to the major
number. The integer MUST fall within intent is that an old service template still accurately,
if incompletely, defines the range attributes of
; values a 32 bit integer may take, ie.
; -2147483648 to 2147483647.
boolean = "TRUE" / "FALSE"
; These strings are not service advertisement
if the template only differs from the advertisement in its minor
version. See Section 5 for more detail on how to use the version
attribute.
4.2.5. Description
The description is a block of text readable by people in the language
of the template and is the value of the "description" item. It
should be translated.
com-chars = safe-char / white-sp / "*" / "," / ";"/ "&"
safe-char = attrchar / " " / "!" / '"' / "%" / "'" /
"(" / ")" / "+" / "," / "-" / "." / "|" /
":" / "=" / "?" / "[" / "]" /
"" / "/" / "" / " "
; All ASCII printable characters are
; included except ",", "&", "*" sufficient to identify the service to human readers and "#".
white-sp = SPACE / TAB
rad64-char = ALPHA / DIGIT / "+" / "-" / white-sp
opaque = 1*DIGIT ":" 4*rad64-char
; The digits define
provide a short, informative description of what the original length service does.
4.2.6. Syntax of
; the opaque value. Service Type-specific URL Part
The restricted character
; string syntax of the service type-specific part of the service:
URL is provided in the radix-64 encoding template document as the value of the
"url-syntax" item. The <url-path> field of the opaque
; value. See [5], Section 5.2.
; NOTE: White space service: URL is ignored in decoding
; radix-64 values.
newline = CR / ( CR LF )
Guttman,Perkins
designed to provide additional information to locate a service when
the <addr-spec> field is not sufficient. The <url-path> field
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 11] 15]
Internet Draft Service Templates and URLs 6 June 31 July 1997
ABNF should have some way
distinguishes URLs 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 particular service type from those of white space:
A string is considered to be a token another
service type. For instance, 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 lpr service type, the tokens is removed. For example:
" some
<url-path> must include the queue name = some value , another example "
would be trimmed to
"some name" '=' "some value" and "another example".
Notes on string matching:
Attribute tags and values [18], but other service types
may be used by some protocols for directory
look-up. In not require this case, the following rules should be applied information.
The syntax for
string matching of attribute strings.
Decoding character escape and trimming white space the <url-path> field 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 accompany the type definition of
each value is
a new service type, unless the same. Boolean attributes may not take multiple
values.
Attributes service advertisement is an existing
URL and values must be given in exactly the same order not a service: URL. The syntax is included in
translated service templates. This will allow the service templates
to be used to translate attributes and values to other languages
(using service templates template
document as look up tables.)
3.2.4. Grouping attribute values together an ABNF [9] following the rules for URL syntax described
in records
Some attributes may be related, which [6]. There is to say, not independent.
Each configuration, no requirement for instance, might have a limitation and service scheme to support
a best
use. If these were encoded in separate attributes, the dependency
would not <url-path>. The <url-path> field can 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 very simple, or C? Are interactive jobs unpredictable? The
suggested convention even
omitted. If the service advertisement is to choose one of an existing URL, the attributes ranges
"url-syntax" item SHOULD include a reference to be the attribute base. Here, it will be appropriate
standardization documents for the configuration. URL.
4.2.7. Attribute Definition
The others
attributes are, by conventions, extensions bulk 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 template is conventional, by use of devoted to defining service type-specific
attributes. An attribute definition precisely specifies the
dot as an <tag> character, and does not place any constraint
attribute's type, other restrictions 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 (whether it is a two letter code defining the language of
multi-valued, optional, etc), some text readable by people describing
the template [8].
3.3.2. Version
The version attribute, and lists of the Service Type template. A proposal starts at 0.0, default and the minor number increments once per revision. allowed values. The Version
attribute has a string value of only
required information is the form:
version = 1*DIGIT '.' 1*DIGIT
A standardized template starts at 1.0. Additions of attributes add
one to attribute's type, the minor number, where changes of definition or removal of
attributes or values adds one to rest are optional.
Registration, deregistration and the major number. See Section 4 for
more detail on how to use of attributes in queries can
be accomplished using the Version attribute.
Guttman,Perkins Expires 6 December 1997 [Page 13]
Internet Draft Service Templates Location Protocol [19] or other
means, and URLs 6 June 1997
3.3.3. url-path rules
This discussion of this is a text attribute which defines beyond the semantics scope of the url path document.
Attributes are used to convey information about a given service
for purposes of the service: URL differentiating different services of the given same
type.
The <service-part> is of the form:
/<addr-family>/<addr-spec>/<url-path>;FAQ
The <url-path> description specifies additional They convey information to locate
a service when be used in the <addr-spec> is not sufficient, and is a field
whose content that distinguishes URLs selection of a
particular service type
from those of another service type. For instance, to bind to, either through a program offering a
human interface or programmatically. Attributes can be encoded in
different character sets and in different languages. The procedure
for doing this is described in Section 6.
An attribute definition begins with the case specification of a
printer service: URL, the url-path will typically be
attribute's identifier and ends with a queue name,
but not single empty line. Attributes
definitions have five components (in order of appearance in a
definition):
1. An attribute identifier which acts as the case name of a service: URL for any other service type.
4. A Process For Standardizing New Service Types
New Service Types can be suggested simply the attribute,
2. Attribute descriptors (type and flags),
3. An optional list of values which are assigned to the attribute by providing a
default,
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 16]
Internet Draft Service Type
template Templates and URLs 31 July 1997
4. An optional block of text readable by people providing a short short,
informative description of the use for attribute,
5. An optional list of allowed values which restrict the value or
values the service: URL.
This MUST have its 'Version' attribute set to "0.0" initially. can take on.
4.2.7.1. The minor version number will increment once Attribute Identifier
An attribute definition starts with each change until
it achieves 1.0. There is no guarantee any version the specification of the service
template will be backwards compatible before it reaches 1.0.
Once a service template has reached 1.0,
attribute's identifier. The attribute's identifier functions as the definition is "frozen"
for that version. New templates may be defined,
name of course, to refine the attribute. Note that definition, but they must follow these rules:
- Any new the characters used to compose an
attribute defined identifier are restricted to those characters considered
unrestricted for the template will increase the
minor version number by one. All other inclusion in a URL according to [6]. The reason is
that services could want to display prominent attributes for the
version in their
service: URL advertisements. Each attribute identifier must continue to be supported as before. A client which
supports 1.x
unique in the template. Since identifiers are case folded, upper
case and lower case characters are the same.
4.2.7.2. The Attribute Type
Attributes can still use later versions have one of 1.y (where x<y) as
it will ignore attributes it doesn't know about.
- Deprecating five different types: string, integer,
boolean, opaque, or changing keyword. The attribute's type specification is
separated from the definition of attribute's identifier by an attribute requires
changing equal sign ("=") and
follows the major version number of a service template. A user
agent may be unable to make use of this information, equal sign on the same line. The string, signed integer,
and boolean types have the standard programming language or it may
need database
semantics. Integers are restricted to obtain the most recent service template those signed values that can
be represented in 32 bits. The character set used to help represent
strings is not specified at the user
interpret time the service info.
The template should is defined, but
rather is determined by the service registration. Booleans have the
standard syntax. Opaques are radix64 numbers [8] that can be posted used
to represent any other kind of data. Keywords are attributes that
have no characteristics other than their existence (and possibly the Service Location Working Group
mailing list for review. Ideally, experts
descriptive text in the implementation their definition).
Keyword and
deployment boolean attributes impose restrictions on the following
parts of the particular protocol will be consulted so attribute definition. Keyword attribute definitions
MUST have no flag information following the type definition, nor any
default or allowed values list. Boolean attributes are single value
only, i.e., multi-valued boolean attributes are not allowed.
4.2.7.3. Attribute Flags
Flags determine other characteristics of an attribute. With the
exception of keyword attributes, which may not have any flags,
flags follow the attribute type on the same line as to add
Guttman,Perkins the attribute
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 14] 17]
Internet Draft Service Templates and URLs 6 June 31 July 1997
more attributes or change their definition to make them
identifier, and are separated from each other by whitespace. Flags
may appear in any order after the attribute type. Other information
must not follow the flags, and only one flag identifier of a
particular flag type is allowed per attribute definition.
The semantics of the flags are as useful follows:
- o or O
Indicates that the attribute is optional. If this flag is
missing, the attribute is required in every service registration.
- m or M
Indicates that the attribute can take on multiple values. If
this flag is present, every value in a multi-valued attribute
has the same type as
possible.
All published versions the type specified in the type part of the template
attribute definition. Boolean attributes 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 not include this
flag.
- l or L
Indicates that attribute is literal, i.e. is not meant to
"1.0". be
translated into other languages. If there this flag is no comment on present, the template after 3 months, it
should be
attribute is not 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 be readable by people and should
not be translated when the Service Type definition. template is translated. See Section 3. The ABNF 6
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 more information about translation.
- x or X
Indicates that an explicit match between the attribute value and
a query value is required, and that partial matches are excluded.
An attribute which is both multi-valued and explicit (i.e. both
the "M" and "X" flags are set) only requires an explicit match
between one attribute and the query. This attribute must be
included in every query for the service.
Multi-valued attributes are an ordered set like a one-dimensional
array or vector in a programming language. Additions to the
attributes occur on the end that would have the maximum index if the
attribute were a vector. Deletions of individual values from the
attribute are not supported, and deletion of the attribute causes the
entire set of values to be removed. These properties allow linked
sets of multivalued attributes to implement lookup tables and other
data structures.
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 15] 18]
Internet Draft Service Templates and URLs 6 June 31 July 1997
6. Examples
The Service Templates
Explicit matching attributes are used for the SLP Directory Agent creating ACL's and POP3 service other
purposes. As an example of using explicit matching of attributes
consider the following attribute definition:
acl = string m x #Only people whose names are given below.
6.1. SLP Directory Agent
The directory-agent on this
list are allowed to #access the service. george.bonner
charles.fowler muhammad.ali.jhin taso.fujimora
In this case, every query for advertisements of the service type has no must
contain this attribute, and unless there is an exact match between
the query string and one of the allowed values, the advertisement
will not be returned.
4.2.7.4. Default Value or List
If the attribute definition includes a default value or, in the
case of multivalued attributes, a default values list, it begins on
the second line of the attribute definition and continues over the
following lines until a line ends without a comma. As a consequence,
newlines cannot be embedded in values.
Particular attribute types and definitions restrict the default
values list. Keyword attributes except scope.
6.2. POP3
template.service-type = STRING L
POP3
# This must not have a list of defaults.
If an optional attribute's definition has an allowed values list,
then a default value or list is not optional but required. The
motivation for this is that defining an attribute with an allowed
values list is meant to restrict the template for the POP3 service.
template.version = STRING L
0.0
# This is values the preliminary version of attribute can take
on, and requiring a default value or list assures that the template.
template.description = STRING
The question default
value is how to make this string exceed one line
# Clients which wish to make use a member of POP3 service need to be
# configured to use the correct POP3 server. given set of allowed values.
The server may
# default value or may not be able to use list indicates what values the APOP authentication mechanism.
# Clients are able to discover which POP3 server attribute is the correct
# one for them and whether they can use the APOP
given if no values are assigned to authenticate
# themselves. Finally, the POP3 server policy may be
# included.
template.url-path-rules = STRING
The url-path attribute when a service
is omitted.
#
template.language = STRING L
en
# The registered. If an optional attribute's definition includes no
default template is in English.
Mailboxes = STRING M L
# This is value or list, the following defaults are assigned:
1. String values are assigned the empty string,
2. Integer values are assigned zero,
3. Boolean values are assigned false,
4. Opaque values are assigned a list of all users (by user name) which byte array containing no values,
5. Multi-valued attributes are initialized with a single value.
Required attributes must always be included with the POP3
# server supports.
APOP = BOOLEAN L
Guttman,Perkins service
advertisement registration.
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 16] 19]
Internet Draft Service Templates and URLs 6 June 31 July 1997
FALSE
# This determines whether
4.2.7.5. Descriptive Text
Immediately after the default values list, if any, a block of
descriptive text SHOULD be included in the POP3 server supports APOP
Policy = STRING O
# This optional attribute describes definition.
This text is meant to be readable by people, and should include
a short, informative description of the POP3 server's policy
# regarding its use. For instance, are users dissuaded or
# disallowed attribute. It may also
provide additional information, such as a description of the allowed
values. This text is primarily designed for display by interactive
browsing tools. The descriptive text is set off from keeping mail on the server? Is there a
# quota? Is mail older than surrounding
definition by a certain number crosshatch character ("#") at the beginning of days erased?
7. General Service Template
the line. The service-template Service Type has 4 attributes, followed text should not, however, be treated as a comment
by parsing and other tools, since it is an integral part of the
service: URL definition for
attribute definition. Within the service type block of descriptive text, the text
is transferred verbatim, including indentation and line breaks, so
any formatting is preserved.
4.2.7.6. Allowed Values List
Finally, the collection of attribute specifications for definition concludes with an optional
allowed values list. The allowed values list, if any, follows the service type.
version = STRING L
# This
descriptive text, or, if the descriptive text is absent, the version number initial
values list. The syntax of the template.
# It allowed values list is expressed in X.Y notation, where X identical to
that of the initial values list. The allowed values list is also
terminated by a line that does not end in a comma. If the major
# and Y allowed
values list is present, assignment to attributes is restricted to
members of the minor version number.
service type = STRING L
# The value list.
4.2.7.7. Conclusion of this An Attribute Definition
An attribute is definition concludes with a single empty line.
5. A Process For Standardizing New Service Types
New service type string.
description = STRING
# The types can be suggested simply by providing a service type is described here. This is
template and a paragraph or
# so short description for use 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 The template
MUST have its "version" template attribute set to the service access point
# which the service: URL resolves to.
Language tag = STRING L
en
# 0.0.
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>
# minor version number increments once with each change until it
achieves 1.0. There is for no guarantee any version of the service type being specified.
attr-specs = STRING M
# The value of this attribute
template is the backward compatible before it reaches 1.0.
Once a service template text, defining
# all has reached 1.0, the service type attributes.
Of definition is "frozen"
for that version. New templates must be defined, of course, to
refine that definition, but the mandatory attribute tags, only "description" may following rules must be translated
into another language (see Section 9.)
Guttman,Perkins followed:
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 17] 20]
Internet Draft Service Templates and URLs 6 June 31 July 1997
The description field should
- Any new attribute defined for the template increases the minor
version number by one. All other attributes for the version must
continue to be a paragraph supported as before. A client which supports 1.x
can still use later versions of text describing 1.y (where x<y) as it ignores
attributes it doesn't know about.
- Deprecating or changing the definition of an attribute and the all requires
changing the values it can take on. This information
will be used by those who develop major version number of a service template. A user interfaces
agent may be unable to display service
information and those who advertise services using attributes
associated with make use of this information, or it may
need to obtain the service: URL.
7.1. Obtaining Service Templates dynamically
The most recent service template is registered as a to help the user
interpret the service type by any SA which
has a template. information.
The SA SHOULD query template should be posted to the Service Location Working Group
mailing list for review. Ideally, experts in the implementation and
deployment of the DA particular protocol are consulted so as to add or
delete attributes or change their definition to determine if make the
service template has already been registered, and if so, abstain from
registering as
useful as possible.
All published versions of the service template.
This is an area which definitely needs work. The difficulty template must be available on-line,
including obsolete ones. Once consensus is that in order for a service achieved, the template to
should be retrieved as
an attribute of some registered service: URL (presumably
of type service:template:), one would have reissued with possible corrections, having its Version
number set 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 1.0. If there is not immediately attractive.
8. no comment on the template after 3
months, it should be considered to have been accepted.
6. Internationalization Considerations
The service: URL itself must be encoded using the rules set forth
in [4]. [6]. 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. [5].
6.1. Character Set identification Identification and use 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. Note that this means character set must
have US-ASCII as a proper subset in order to be used.
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] [19] 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.
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 21]
Internet Draft Service Templates and URLs 31 July 1997
All attribute information in a single transmission, file, etc. MUST
be in the same character encoding.
8.2.
6.2. Language identification Identification and translation Translation
The language used in attribute string strings should be identified using a
Language tag the
"language" template item as defined by [1]. [4].
A program may can translate a service advertisement from one language to
another provided it has both the template of the language of for the
advertisement and the template of the desired target language. All
standardized attributes will be are in the same order in both templates.
All non-arbitrary strings (such as tags and set members) will be strings, including the descriptive help text, is
directly translatable from one language to another. Free text Non-literal
attribute definitions, attribute identifiers, attribute type names,
attribute flags, and
nonstandard attributes may not be automatically translated in this
manner.
Shouldn't help text the boolean constants "true" and "false" are
never translated. Translation of attribute identifiers is prohibited
because, as with domain names, they can potentially be translatable? What part of a
service: URL and therefore their character set is free text? restricted. In
addition, as with variable identifiers in programming languages, they
could become embedded into program code.
All strings used in attributes (tags and values) attribute values are assumed to
be able to be translated translatable unless explicitely
explicitly defined as should
be being literal, so that best effort translation
(see below) will does not
obfuscate modify strings which are meant to be interpreted
by a program, not a person.
There are two ways to go about translation: Standardization standardization and best
effort.
When the service type is standardized, more than one document may can
be submitted for review. One service type description is registered
for each language. These descriptions must be kept in sync, approved
as a master, so that when a service type template is updated in one
language, all the translations (at least eventually) reflect the same
semantics.
If no document exists describing the standard translation of the
service type, a 'best effort' translation for strings may should be done.
9.
7. Security Considerations
Service type templates provide information which will be that is used to interpret
information obtained by the Service Location Protocol. If these
templates were are modified or false templates were are distributed,
Guttman,Perkins Expires 6 December 1997 [Page 19]
Internet Draft Service Templates and URLs 6 June 1997 services
may not correctly register themselves themselves, or clients might not be able
to interpret service information obtained by SLP. information.
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 22]
Internet Draft Service Templates and URLs 31 July 1997
The service: URLs themselves specify the service access point and
protocol for a particular service type. These Service 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 The Service Location
Protocol [19] distributes service: URLs and has an authentication
mechanism which that allows Service service: URLs of advertised services to
be signed and these for the signatures to be verified by clients.
Guttman,Perkins In
addition, clients can construct their own authentication mechanisms
using attributes with required matching, as described in Section 4.
8. Changes Made Since the Last Version
Removed:
- The examples.
- The discussion of record structures.
Added:
- The discussion of abstract service types.
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 20] 23]
Internet Draft Service Templates and URLs 6 June 31 July 1997
References
[1] Protocol and service names, October 1994.
ftp://ftp.isi.edu/in-notes/iana/assignments/service-names.
[2] Address family numbers, October 1995.
ftp://ftp.isi.edu/in-notes/iana/assignments/address-family-numbers.
[3] Port numbers, July 1997.
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
[4] H. Alvestrand. Tags for the Identification of Languages. RFC
1766, March 1995.
[2]
[5] ANSI. Coded Character Set -- 7-bit American Standard code for
Information Interchange. X3.4-1986, 1986.
[3]
[6] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource
Locators (URL): Generic Syntax and Semantics. RFC1738 as
amended by RFC1808 and updated by draft-fielding-url-syntax-05.txt,
May 1997. (work in progress).
[4]
[7] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). RFC 1738, December 1994.
[5]
[8] 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]
[9] D. Crocker and P Overell. Augmented BNF for Syntax
Specifications: ABNF. draft-ietf-drums-abnf-02.txt, November
1996. March
1997. (work in progress).
[7]
[10] A. Gulbrandsen and P. Vixie. A DNS RR for specifying the
location of services (DNS SRV). RFC 2052, October 1996.
[8]
[11] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk.
Addison-Wesley, 1990.
[12] Geneva ISO. Code for the representation of names of languages.
ISO 639:1988 (E/F), 1988.
[9]
[13] R. Moats. Defining White Pages and Yellow Pages Services.
draft-ietf-svrloc-wpyp-00.txt, February 1997. (work in
progress).
[14] R. Moats and M. Hamilton. Finding Stuff(Providing Stuff (Providing information
to support service discovery). draft-ietf-svrloc-advertise-00.txt, February 1997.
draft-ietf-svrloc-advertise-00.txt, (work in progress).
[10]
Guttman,Perkins,Kempf Expires 31 December 1997 [Page 24]
Internet Draft Service Templates and URLs 31 July 1997
[15] J. Myers. Simple Authentication and Security Layer (SASL).
draft-myers-auth-sasl-11.txt, May 1997. (work in progress).
[16] J. G. Myers. ACAP -- Application Configuration Access Prototol.
draft-ietf-acap-spec-04.txt, June 1997. (work in progress).
[17] Inc Novell. Advanced netware v2.1 internetwork packet exchange
protocol (ipx) with asynchronous event scheduler (aes), October
1986.
[18] Pete St. Pierre. Definition of lpr: URLs for use with Service
Location. draft-ietf-svrloc-lpr-scheme-00.txt, July 1997.
(work in progress).
[19] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol, April Protocol. RFC 2165, July 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 James Kempf
Sun Microsystems Sun Microsystems
Gaisbergstr. 6 2550 Garcia Avenue
D-69115 Heidelberg Mountain View, CA 94043 Sun Microsystems
Bahnstr. 2 901 San Antonio Rd. 901 San Antonio Rd.
74915 Waibstadt Palo Alto, CA, 94303 Palo Alto, CA, 94303
Germany USA
Guttman,Perkins Expires 6 December 1997 [Page 21]
Internet Draft Service Templates and URLs 6 June 1997
Phone: +1 USA
+49 6221 601649 1 415 786 6464 1 415 336 6697 786 5890
1 415 336 7153
email: Erik.Guttman@eng.sun.com cperkins@corp.sun.com
Guttman,Perkins 786 6445 (fax) 1 415 786 6445 (fax)
erik.guttman@sun.com charles.perkins@sun.com james.kempf@sun.com
Guttman,Perkins,Kempf Expires 6 31 December 1997 [Page 22] 25]
----