WDIFF

draft-ietf-svrloc-service-scheme-00.txt --> draft-ietf-svrloc-service-scheme-01.txt

Service Location Working Group Erik Guttman
Internet Draft
INTERNET DRAFT Charles Perkins
6 June 1997 Sun Microsystems, Inc.
Expires in six months

The Microsystems

Service Templates and service: URL Scheme
<draft-ietf-svrloc-service-scheme-00.txt> 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 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 Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), (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

The service: URL scheme is

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 provide distribute service access information
for arbitrary network services. information.
These URLs schemes provide an extensible framework for client based
network software to obtain configuration information required to make
use of network services. A When registering a service: URL with a
Directory Agent, the URL may be accompanied by a set of well defined
attributes which define the characteristics charateristics of the service. These
attributes may convey
protocol configuration information to client software 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 and provides examples.

Guttman using Service

Guttman,Perkins Expires 6 December 1997 [Page 1] i]

Internet Draft The Service: URL Scheme 20 November 1996

Table 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. The service: Scheme Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Service Schemes . . . . . . . . . . . . . . . . . . . . . 4
1.3. Related work
2. Use of service: URLs
3. Specifying A New Service Type
3.1. A Service Type specification defines:
3.1.1. Service Type
3.1.2. The service: 'urlpath' information
3.1.3. Attributes
3.1.4. Service Discovery Multicast Address
3.2. Specifying Attributes
3.2.1. A subtlety
3.2.2. Types and String Encoding
3.2.3. Attributes with multiple values
3.2.4. Grouping attributes values together in records
3.3. Special Attributes
3.3.1. Service Discovery Multicast Address
3.3.2. . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Changes made since the last version
3.3.3. Language tag
3.4. Service Type templates
3.4.1. Definition
3.4.2. Manditory Attributes
3.4.3. Attribute syntax for Service Type templates
3.4.4. . . . . . . . . . . . 5
1.5. Open issues and work to be done . . . . . . . . . . . . . 6

2. Use of templates by the Service Location Protocol
4. service: URLs 6

3. Specifying A Process For Standardizing New Service Types
5. Encoding Rules for Type 7
3.1. Service Type URLs
6. Examples
6.1. NFS
6.1.1. The NFS Specifications . . . . . . . . . . . . . . . 7
3.1.1. Service Type template
6.1.2. Example: A 'pub' directory
6.1.3. Example: A 'dist' directory
6.2. LPR
6.3. POP3
7. Security Considerations
8. Internationalization Considerations
8.1. Character Set identification and use
8.2. Language identification and translation
9. Bibliography
10. Author's Address

1. Introduction

This document describes a URL scheme which will allow arbitrary
network services to have a standard notation for defining their
service access point.

Guttman [Page 2]

Internet Draft The Service: URL Scheme 20 November 1996

In addition it describes how to define a set of attributes to
associate with service: URLs. These attributes will allow end users
and programs to select between network services of the same type that
have different capabilities. . . . . . . . . . . . . . . . . . . 7
3.1.2. The use of these attributes is recommended but not required to make
use of the service: URL. The minimal encoding rules for attributes
are specified.

Service Type templates are used to describe services which use the
service: URL in a standard way. The rules for writing such a
template are provided, as are three examples.

All grammar encoding follows the Augmented BNF for syntax
specifications [ABNF] with a few deviations.

1.1. The service: Scheme

The service: scheme and all information which follows it MUST obey
the URL conventions defined in [RFC1738].

The scheme specific 'url-path' 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:

serviceurl = "service:" service-type ":" service-part

The formal syntax for a serviceurl is given in Section 5.

The service-type string indicates a specific protocol, such that
client software can be expected to unambiguously make use of the
service. The . . . . . . 8
3.1.3. Attributes . . . . . . . . . . . . . . . . . . . 8
3.2. Specifying Attributes . . . . . . . . . . . . . . . . . . 8
3.2.1. Service Type determines semantics of the service-part Templates and the attributes associated . . . . . . . . 9
3.2.2. Service Templates String Encoding . . . . . . . . 9
3.2.3. Attributes with the service: URL.

The service-part includes an ip-schemepart. This will define either
a domain name or a numerical ip address for the service and possibly
more, such as a port number to use. The remainder of the service-
part is intended to provide sufficient information for client
software to be able to bind and make use of a service.

The service-part allows for extensions to the basic tuple of Service
Type and host (and possibly port number), so that more information
may be provided to uniquely identify the resource. It is also
possible, though less preferable, to provide uniquely identifying
information in the multiple values . . . . . . . . . 12
3.2.4. Grouping attribute information associated with a service:
URL. This string will be referred to values together in this document as the
'urlpath' to be consistent with [RFC 1738].

Guttman [Page 3]

Internet Draft The Service: URL Scheme 20 November 1996

The records . . 12
3.3. Special attributes associated with the URL are not included in the URL.
They are stored and retrieved using other mechanisms. The service:
URL serves as a unique identifier, to be used in registering or
requesting the attribute information. The . . . . . . . . . . . . . . . . . . . 13
3.3.1. Service Location Protocol
[SLP] specifies how such information may be advertised by network
services and obtained by client software. Other facilities, such as
Directory Services, could be used to distribute this information.

Attributes are associated with service: URLs 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 three reasons:

1. They allow configuration of the client. 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. Client configuration
parameters or server convention information may be obtained.

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 or which has access to specific
resources.

3. Attributes support end user selection by characteristic
as opposed to simply by type. These attributes may be
used to populate service browsing and choosing user
interfaces, for example.

1.2. Related work

The "Finding Stuff" work by Ryan Moats and Martin Hamilton uses
service: URLs provide access information about arbitrary network
protocols through DNS. [FINDING] They do not associate service
attributes with these URLs. The URLs allow them to provide
nonstandard service port information and to relate several protocols
to single abstract services, such as white pages and yellow pages.

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 obtained with their associated
attributes. In this way a client application may obtain the Service Type URLs of
several services of the same type and distinguish the most preferable
among them by means of their attributes.

Guttman [Page 4]

Internet Draft The Service: URL Scheme 20 November 1996

These attributes will take the form specified by the "service-
template", described below. Each service: URL SHOULD be accompanied
by all attributes in the template (except the template specific
special attributes.) The registration of this attribute information
could be done using various mechanisms, one of which is the Service
Location Protocol [SLP].

The client will use the service: URL to bind directly to a service.
The client must have a priori knowledge of how to use the network
protocol associated with the Service Type included in the service:
URL.

3. Specifying A New Service Type

A Service Type should be specified to be a close as possible to a
particular protocol. It may be tempting to create a Service Type for
a 'class of services', such as 'printer'. This will complicate the
specification later on, as the single service type must be
differentiated between the different protocols at the level of
service specific information or attributes.

It is much clearer if the protocol is simply named by a service type.
The urlpath is normally used to supply additional naming information
to uniquely identify the service. The attribute information can then
be used to indicate configuration details, optional features
available and characteristics (which may be relevant to a human user
or to a program.)

3.1. A 15

6. Examples 16
6.1. SLP Directory Agent . . . . . . . . . . . . . . . . . . . 16
6.2. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7. General Service Type specification defines:

3.1.1. Template 17
7.1. Obtaining 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 should be cited as the definitive
reference for the protocol to use when binding to the service access
point provided by the service: URL.

3.1.2. The service: 'urlpath' information

This information is included in the URL in order to provide uniquely

Guttman [Page 5]

Internet Draft The Service: URL Scheme 20 November 1996

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 lpr print queue (using the 'lpr' service
type).

The syntax and interpretation of the urlpath must accompany the
definition of a new Service Type. The 'default' urlpath definition
is that it is entirely omitted except possibly a terminating slash.
The syntax is:

urlpath = [ "/" ]

Every effort to remain consistent with the syntax forms and styles of
other standardized urlpaths should be pursued. See [RFC1738] for
examples and 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 normally takes only one value, but optionally it may be
defined to be able to take multiple values.

The transmission of attributes is not described by this document.
Attribute registration, deregistration and the use of attributes in
queries may be accomplished using a number of different protocols. A
future document (or possibly a later version of this document) will
describe how to encode attributes for use with different services.
The Service Location Protocol [SLP] defines one method of encoding
attributes.

3.1.4. Service Discovery Multicast Address

Service Types may be registered with IANA and obtain a unique Service
Discovery Multicast Address. This address is to be used with the
Service Location Protocol [SLP] as a means to specifically discover a
single type of service in a network without burdening all other
servers.

This is purely optional: Services which use the service: scheme do
not need to have a unique Service Discovery Multicast Address
assigned to them.

3.2. Specifying Attributes

Guttman [Page 6]

Internet Draft The Service: URL Scheme 20 November 1996

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 for human consumption 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 8.0.

Attributes have two components. The first is a 'tag'. This is a
string with certain encoding rules. The second component is a set of
values. The set of values may be NULL, in which case the attribute
is a 'keyword'. The value or 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.1.

3.2.1. A subtlety

There is a subtlety in the definition of attributes. A service
may support 'feature A' and 'feature B'. It may also have
'enhancement C'. Suppose the enhancement is only available
when feature B is used, in this case. If 'feature' is one
attribute and 'enhancement' is a second attribute, we can
describe the service with the following:

feature = A, B
enhancement = C

It will be impossible to tell if there is any dependency between
having feature B and enhancement C. Since the data relationships are
flat in the attribute encodings, it is necessary to explicitely state
all combinations as distinct values. This can be done in two ways.
Either all combinations of features which may have dependencies must
be given a well defined value or a 'record' format for an attribute
value must be used.

The combination method is only useful when there are very few values
to be combined, as it will quickly become a very large set of values
to define. In the case of the example we can define feature's values
as:

feature can take:

"A" | "A enhanced by C" | "B" | "B enhanced by C"

In our example:

Guttman [Page 7]

Internet Draft The Service: URL Scheme 20 November 1996

feature = "A" , "B enhanced by C"

The suggested method for solving this problem with the 'record
format' is described in Section 3.2.4. below.

3.2.2. Types and String Encoding

Characters have been reserved in the specification of attributes in
order to avoid ambiguity with respect to the delimiters in the string
based protocol used in attribute lists. Further limitations may be
imposed if the attributes are to be encoded using another protocol.

The Service Location Protocol [SLP], for example, has several
reserved characters that are not to be used in attributes. SLP
provides an escape sequence to allow these characters to be used in
attribute values (not attribute tags.) The same character escape
mechanism is proposed here.

esc-char = "&" "#" 1*DIGIT ";"

The escaped character is replaced by a character sequence with no
spaces. The digits are a decimal representation of the character
value to be replaced, in the character set used for the attribute
encoding.

There are only three heavy handed syntactic devices used:

1. Blank lines are used to separate attributes. To add a
blank line to text, one would have to escape the CRLF
with &#13;&#10;

2. Commas are used to separate attribute values. To use a
comma in attribute encodings, escape the comma with &#44;

3. Sets of colons are used to mark a default value (see
Section 3.4.3.) This means the string "::" must be
escaped in attribute values to &#58;&#58;

Attributes have the following grammar:

attribute = keyword / tag "=" 1#value CRLF CRLF

safe-chars = <any character except "," which is reserved.>
white-sp = SPACE / CR / LF / TAB
key-chars = <any safe-chars except for white-sp which is
not allowed.>

tag = 1*safe-chars

Guttman [Page 8]

Internet Draft The Service: URL Scheme 20 November 1996

keyword = 1*key-chars
value = string / integer / boolean / opaque

string = 1*safe-chars

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 values are the only exception to the
; Internationalization rules in Section 8.0.
; Independent of the translation of the
; attributes, the boolean values remain the
; indicated strings.

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 [RFC 1521], Section 5.2.

; NOTE: White space is ignored in decoding
; radix-64 values.

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" Templates dynamically . . . . . . . . . 18

8. Internationalization Considerations 18
8.1. Character Set identification and "another example".

Note on string matching:

Attribute tags use . . . . . . . . . . 18
8.2. Language identification 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.

String matching MUST be done after character escape encoding has been

Guttman translation . . . . . . . . . 19

Guttman,Perkins Expires 6 December 1997 [Page 9] 1]

Internet Draft The Service: URL Scheme 20 November 1996

removed, white space has been trimmed. 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. Attributes with a boolean value may not take
multiple values.

3.2.4. Grouping attribute values together in records

In order to make use of this value encoding strategy, the record
format must be explicitely described. A 'delimiter' is used to
separate the fields in the record, a 'tab' is suggested, but others
are possible.

Each field in the attribute 'record' value must be defined
separately, as though it were an attribute value of its own. This
means it needs to have a type, default value, whether it can have
multiple values Service Templates and URLs 6 June 1997

9. Security Considerations 19

1. Introduction

This document describes a definition for all values it can take. If a
field is omitted, it is assumed to take its default value. It is
wise to have the default value be "NONE" or "NOT APPLICABLE", class of schemes which will allow network
services to make define their service access information, using a standard
notation.

In addition it possible describes how to explicitely declare only the relevent field values define a set of attributes to
associate with a service: URL. These attributes will allow end users
and
ignore the others. It is also possible programs to declare 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 field service: URL) that has
no default value, if it MUST be defined in each record.

Following the example configuration it needs. The
minimal encoding rules for attributes are specified.

Service Type templates are used to describe in Section 3.1, we can define a standard way those
services which use the attribute
"feature" to have service: URL. The rules for specifying a record structure, delimited by tabs. Both fields
scheme are single valued strings. The first field is provided, along with two examples. Templates are used the "feature name",
and has no default value.
following distinct purposes:

1. Standardization

The second field template is reviewed before it is standardized. Once it is
standardized, all versions of the "enhancement
name", with "NO ENHANCEMENT" as the default value. The resulting
value would be:

"feature =" "A" TAB "," "B" TAB "C"

The string "feature =" indicates template are archived by IANA.

2. Service Registration

Servers making use of the attribute 'feature' takes Service Location Protocol will register
themselves and their attributes. They will use the
value templates to
generate the right of service registrations; the service must pick from
among the equals sign. allowable values.

3. Client presentation of Service Information

Client applications may display service information. The quotes will
template provides type information and explanatory text which may
be used to
indicate that this is not an ABNF syntax but rather helpful in producing user interfaces.

4. Internationalization

If a string encoding
resulting from rules given elsewhere. (In this case client application has the rules were template for a given service type
in Section 3.1.1.).

The feature "A" has no second field value, two different languages, the first value record is
A with NO ENHANCEMENT. The second value record that feature attributes may take
is B with be translated back
and forth between the enhancement C.

3.3. Special attributes

3.3.1. Service Discovery Multicast Address

Guttman two languages.

Guttman,Perkins Expires 6 December 1997 [Page 10] 2]

Internet Draft The Service: URL Scheme 20 November 1996

This attribute is always included in Service Type templates.

It takes a single valued which takes a numerical IP address
specification. This should take the value of the assigned Templates and URLs 6 June 1997

A Service
Discovery Multicast Address. If the service may use templates to register services in more than
one language, though it has not been assigned
one, this attribute should take the value NONE. The value that this
attribute takes is defined configured by the following syntax:

discovery-addr = ipv4-addrport / ipv6-addrport / "NONE"

byte = 1*3DIGIT
; This value MUST be between 0..255
ipv4-addrport = byte "." byte "." byte "." byte [":" 1*DIGIT]

hex = DIGIT / "A" / "B" / "C" / "D" / "E" /
"a" / "b" / "c" / "d" / "e"
ipv6-addrport = 32hex [":" 1*DIGIT]

The address must be system
administrator to register in a valid multicast address (according single language.

QUESTION: Which of several homonyms would be the one known
to either
IPv4 or IPv6 addressing rules. The port number identifies user agents processing the port
number for translated information?

All grammar encoding follows the service discovery protocol. The Service Location
Protocol [SLP] uses port 427, which is Augmented BNF (ABNF) [6] for syntax
specifications with a few deviations.

QUESTION: What are the default if no port number deviations?

1.1. Terminology

In order to reduce confusion, some terminology is given.

3.3.2. Version

This attribute has introduced.

service: URL

A URL, registered by a string value service agent of the form:

version = 1*DIGIT '.' 1*DIGIT

This is the version a particular service
type, that conforms to any "service scheme" definition.

service type

A type of the Service Type template.

This attribute MUST be included in every collection service all of attributes so
as to identify which version whose agents are accessed by service:
URLs of the same scheme (a service scheme, below). The name
of the template it used to determine type of service is the
set part of attributes and attribute definitions. Client software can use
these version numbers potentially to support old attributes, allowing
a smooth migration to new template definitions. the service scheme name
which follows the initial string "service:".

service scheme

A Service Type template proposal starts at 0.0, scheme, whose name start with the string "service:" and is
followed by the minor number
increments once per revision.

A standardized template starts at 1.0. Additions of attributes add
one service type name, constructed according to the minor number, where changes of definition or removal
rules in this document.

service template

A formal description of the service attributes or values adds one to and service
scheme associated with a particular service type. a particular
service may be selected by obtaining the major number. See Section 4 service: URL
registered by that service.

general service template

A template for
more detail on how to use the Version attribute.

3.3.3. Language tag

Guttman describing service templates -- for instance as
is contained within this document.

Guttman,Perkins Expires 6 December 1997 [Page 11] 3]

Internet Draft The Service: Service Templates and URLs 6 June 1997

1.2. Service Schemes

Each service scheme MUST obey the URL Scheme 20 November 1996 conventions defined in [4].

The Language tag attribute must be included with each template scheme specific information following the service: scheme
provides the service type and
with each set address of a network service. It may
additionally include service type specific information. The form of attributes associated with
a particular service:
URL. This allows client applications to identify if URL is as follows:

"service:" service-type ":" service-part

where the attributes
which will be comprehensible 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 a given convenience of
interactive user and retrieve them. See
8.2.

3.4. Service Type templates

3.4.1. Definition agents. The Service Type formal syntax for the Service Type template a service: URL is "service-template".
given in Section 5.

The service-type string indicates the type of service. The service
type specific information which follows is determines the location semantics of the service-part and path information of a hypertext document which describes the
Service Type template, which is to be accessed using http.

For example, this template would be encoded as:

<URL:service:srv-template://www.ietf.org/internet-drafts/
draft-ietf-svrloc-service-scheme-00.txt>
attributes associated with the service: URL. The document would be accessed <addr-family> is
IP by using:

<URL:http://www.ietf.org/internet-drafts/
draft-ietf-svrloc-service-scheme-00.txt>

3.4.2. Mandatory Attributes

The service-template Service Type has 3 mandatory attributes. The
template must also support default (if not present), but can be used to indicate the two special attributes version and
Service Discovery Multicast Address, use
other address families such as defined in Section 3.3.
These attributes are NOT specified in attributes which accompany
service: URLs. These attributes are only to be specified in Service
Type templates.

service type

The value of IPX and Appletalk. In this attribute 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 service type string.

Service Discovery Multicast Address

See section 3.3.1.

description

The service type is described here. This address specification (an <addr-spec>), which is typically either
a paragraph domain name (DNS) or
so of text which describes how to interpret the service: URL an IP address for this particular service type. It should the service, and possibly a
port number. The service-part allows more information to be clear what
protocol or protocols provided
(by way of <url-path>) that can bind to uniquely locate the service access point

Guttman [Page 12]

Internet Draft or
resource if the <addr-spec> is not sufficient for that purpose.

The Service: URL Scheme 20 November 1996

which FAQ is actually composed of a list of "attribute = value"
elements, describing for the user the service: URL resolves to.

Of these attributes tags, only "description" may that are associated
with the service: URL. This might be translated into
another language (see Section 8.0.)

3.4.3. Attribute syntax for Service Type templates

For each attribute done in situations where the service type supports, an additional attribute
service: URL is added 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 service type template. This
attribute has the same
tag as values provided in the service type's attribute. The value of FAQ can help. For instance, if
the attribute has keyword "PostScript" were provided in a service:printer URL, a
user would be able to guess that the following syntax:

tmpl-attr = attr-tag attr-val

safe-char = Any character other 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 ":"
attr-tag = 1*[safe-char]
attr-val = [type] [m] [l] "::" default "::" description

type = ["STRING" | "BOOLEAN" | "INTEGER" | "OPAQUE"]
default = 1*[safe-char]
description = 1*[safe-char]
m = SPACE "M"
l = SPACE "L" retrieved
using other mechanisms. The default is "STRING" if type is omitted.

"M" indicates the attribute can have multiple values. If this
field service: URL is omitted it uniquely identified
with a particular service agent, and is assumed used when registering

Guttman,Perkins Expires 6 December 1997 [Page 4]

Internet Draft Service Templates and URLs 6 June 1997

or requesting the attribute can 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 only
one value.

"L" indicates all the necessary attribute and its values must be considered
literally, that is, they must not be translated information to other
languages. (See Section 8).

The default field provides make use of the default value
service: URL.

Attributes are associated with service: URLs for the attribute.

The description field should be a paragraph three reasons:

1. Many servers have optional features. Clients which require or
prefer to make use of text describing the
attribute and the all the values it these features can take on. This information
will be used by those who develop user interfaces proceed to display service do so without
protocol negotiation or feature selection. Attributes serve as
a mechanism for servers to distribute information about their
configuration, capabilities and those who advertise services using characteristics (even dynamic
qualities, such as status or load.)

2. Client software may have particular requirements. The attributes
associated with the service: URL.

3.4.4. Use a given URL allow for automatic selection of templates
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 the Service Location Protocol

Service templates
characteristic as opposed to simply by type. These attributes
may be used by to give users information enabling the Service Location Protocol [SLP]
in three important ways:

Guttman [Page 13]

Internet Draft The Service: URL Scheme 20 November 1996

First, those who program user interface front ends may use selection of
particular services when browsing service directories or the
template to understand
available services on the format, range local network.

1.3. Related work

The "Finding Stuff" work by Ryan Moats and meaning or Martin Hamilton uses
service: URLs provide access information about arbitrary network
protocols through DNS [9]. They do not associate service attributes
available from Attribute Queries from Service Location.

Second, the template provides requirements for those who program
Service Agents for a particular Service Type.
with these URLs. The attributes URLs may contain nonstandard service port
information for services advertised in the
Service Template must be assigned values to be associated with the
service: URL advertisement.

Finally, the template provides DNS. DNS SRV Resource
Records are a mechanism for the Service Location
Protocol which provides a way to discover Service Type specific Service Discovery
Multicast Addresses. The template itself is obtain a service of by
type
"service-template". A User Agent obtains the template in order to
discover which multicast address to use for issuing requests to
Service Agents. Service Agents obtain the template a given domain [7], without being able to discover specify which
multicast group to join in order to receive multicast User Agent
requests. Both of
the Directory Agent and Service Agent will use (possibly numerous) instances of the
templates in order to associate 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 Type string with Templates and URLs 6 June 1997

- The long template examples.

- Description of the
correct Service Discovery Specific Multicast Address Addresses (which
are no longer needed in the SLP's Service Type
Reply.

All that is required 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 make this work, is use Templates for internationalization.

- Some security considerations.

1.5. Open issues and work to run a Service Agent
which advertises the set of templates of all services supported be done

- Justification will be added (as done in the network. ("The network" here refers to a network which has
multicast routing support with a maximum multicast TTL of 32. That
is, URL process
draft [3]).

- Encoding rules for transforming a "site.")

4. A Process For Standardizing New Service Types

New Service Types can Template to an LDAP
Schema will be suggested simply by providing 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 Type
template Templates themselves may be registered
and obtained in a short description of the use network is needed. Why isn't SLP enough for the
this purpose?

2. Use of service: URL.
This should have its 'Version' attribute set to "0.0" initially. URLs

The minor version number will increment once with each change until
it achieves 1.0. There service: URL is no guarantee any version intended to allow arbitrary client/server and
peer to peer systems to make use of the service
template will be backwards compatible before it reaches 1.0.

Once a standardized dynamic service template has reached 1.0, the definition
access point discovery mechanism.

It is "frozen"
for intended that version. New templates may service: URLs be defined, of course, selected according 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.
suitability of associated attributes. A client which supports 1.x can still use later versions application may
obtain the URLs of 1.y (where x<y) as it will ignore attributes it doesn't
know about.

Guttman several services of the same type and distinguish

Guttman,Perkins Expires 6 December 1997 [Page 14] 6]

Internet Draft The Service: URL Scheme 20 November 1996

- Deprecating or changing Service Templates and URLs 6 June 1997

the definition most preferable among them by means of an attribute
requires changing their attributes. The
client will use the major version number of 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 service
template. The client may be unable to make use of this
information,
or it may need to obtain an agent representing a client, the agent SHOULD also keep track
of the attributes which characterize the most recent service template to help offered at the user interpret
network location indicated by the URL, and can use the service
info.

The
template should be posted to for additional information about those service attributes.
The registration of this attribute information is typically done
using the Service Location Working Group
mailing list for review. Ideally, experts in the implementation Protocol [10], although manual techniques
and
deployment of other protocols may be possible.

3. Specifying A New Service Type

A Service Type defines the particular protocol syntax for all URLs that will be consulted so as to add
more attributes or change their definition to make them as useful as
possible.

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

Once there particular type. For instance, a
'Printer' service type is no more active dissent defined with service: URLs in the Service Type should following
form:

service:printer://<address of printer>/<queue name>

The service agent registering the printer service can be
reissued selected by
clients specifying the protocol which matches the protocol attribute
registered with possible corrections, having its Version number set to
"1.0". If there is no comment on the template after 3 months, it
should printer URL above. The attribute information can
be considered used to have been accepted.

At that time, the a Service Discovery Multicast address indicate other configuration details, optional features
available and characteristics (which may be
obtained from IANA for use with the relevent to a human user
or to a program.)

3.1. Service Type.

5. Encoding Rules for Type Specifications

Service Type specifications define the fields described in the
following subsections, and define the syntax of the service-part of
service: URLs

Much of this material is directly adapted from [RFC1738]. Note that service type.

3.1.1. Service Type

This is a string which will be prepended by the syntax for 'service:' scheme.
It may be a name which is entirely invented or be the urlpath depends upon same as a well
known service scheme. For example, service:http: might refer to a
HTTP server, whereas the Service Type definition.
See Section 3. The ABNF for http: scheme used in a serviceurl is:

serviceurl = "service:" service-type ":" service-part

service-type = 1*[ low-alpha / DIGIT / "+" / "-" / "." ]
service-part = "//" login [ "/" urlpath ]

login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname / hostnumber
hostname = *[ domainlabel "." ] toplabel
okchar = ALPHA / DIGIT
domainlabel = okchar / okchar *[ okchar / "-" ] okchar
toplabel = ALPHA / ALPHA *[ okchar / "-" ] okchar
hostnumber = ipv4-number / ipv6-number
ipv4-number = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
ipv6-number = 32hex
port = 1*DIGIT
user = *[ uchar / ";" / "?" / "&" / "=" ]
password = *[ uchar / ";" / "?" / "&" / "=" ]

Guttman 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 15] 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: service: 'url-path' information

This information is included in the URL Scheme 20 November 1996

urlpath = *xchar ; each Service Type 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 define its own
; syntax. accompany the
definition of a new Service Type. See Section

safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / ","
hex = DIGIT / "A" / "B" / "C" / "D" / "E" /
"a" / "b" / "c" / "d" / "e"
escape = "%" hex hex
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
unreserved = ALPHA / DIGIT / safe / extra

uchar = unreserved / escape
xchar = unreserved / reserved / escape

6. Examples section 3.3.3, describing the
mandatory "template.url-path rules" attribute. The purpose of these 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 demonstrate 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 manner use of specifying
new Service Types described attributes
in this document. In addition, it will
provide 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 useful starting point given service for using service: URLs in
applications.

In the case
purposes of differentiating different services of file servers, print spoolers and POP3 servers, the
client software often requires the user same type.
They convey information to know be used in the name and even
parameters selection of the server before being able which service
to bind to, either browsers or for use the service. A
client which can obtain service: 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 associated attributes
dynamically will be able to bind to the server without any knowledge flags)

3. Possibly, a set of typed values.

4. Descriptive help text explaining necessary information about what
the network at all, even the name attribute is

Attributes (but not keywords) may have one or more values. Values of
an attribute are typed, and must have the server host.

Values given same type for specific each value if
the attribute assignments will be given in
quotes. is multivalued. The syntax rules for typing and encoding of
attribute definitions are values is given in Section
3.2.2. The syntax used to assign the rest of section 3.2.

3.2.1. Service Templates and interpret 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 for
attributes or only those
provided in the template (other than list.

- Whether the mandatory attributes) attribute may be translated to other languages or is
given in section 3.4.3.

Note that in
a 'literal', ie. not meant for human readability.

- Whether the templates commas are used to separate attributes and
that commas themselves must service: URL can be escaped. The templates are assumed to be supplied in the [ASCII] character set, so escape values are expressed in response to a
request that character set.

Default values are given when they exist, otherwise the does not give a value MUST be
assigned for each set the attribute, when the
attribute is used as part of attributes associated with a the registration for that service:
URL.

3.2.2. Service Templates String values Encoding

Service templates are to be assigned descriptive values encoded in the absence of a standardized set of identifiers. The strings without standardized
identifiers or integer values are intended to simple form. They may be read by human
beings.

Tabs in the example strings are represented by "\t".

Guttman [Page 16]

Internet Draft The Service: URL Scheme 20 November 1996

6.1. NFS

The service type for NFS is "NFS".

The protocol it refers
translated to is defined in [RFC2055] and [RFC2054].

The URL has service specific information which specifies the mount
path. The syntax for any language or character set, but the urlpath template used
for specifying this is given standardization MUST be encoded in
[NFSURL].

6.1.1. NFS Service Type template

"Service Discovery Multicast Address = NONE

service type = NFS

version = 0.0

Language tag = en

description =
The NFS service type provides attributes which define the
contents ASCII [2] and policies of server mount points. It defines
three types of storage:
(1) installations (software ready to use)
(2) distributions (software ready to install)
(3) space (ready for others to use)
Each of these attributes have record structured be in English.

Between each attribute
values which are described below.

authorization policy = :: NONE ::
A text description of any authentication requirements for
use of the NFS exported filesystem. For example: Only
groups x&#44; y and z - only users a&#44; b&#44; c definition there is a blank line. The rules
for encoding attributes is given below. Reserved characters include
";", "&", "=", ",", "*", "#", TAB, LF, and so on.

use policy = :: NONE ::
The nfs exported file system CR. Reserved characters
may be intended for certain
purposes or contain software with license restrictions.
This text description will make this clear.

distributions = M :: NONE ::
Software distributions&#44; ready to install on other systems. escaped. The value will have 5 fields&#44; separated escaped character is replaced by a tab. character
sequence with no spaces. The fields are:
- distribution name including relative path from the mount
point (could be the name of a tar file&#44; digits are a self
extracting archive&#44; etc. (String)
- platform the distribution is intended to be run on.

Guttman decimal representation of

Guttman,Perkins Expires 6 December 1997 [Page 17] 9]

Internet Draft The Service: URL Scheme 20 November 1996

(String)
- Service Templates and URLs 6 June 1997

the size of character value to be replaced, in the character set used for the distribution
attribute encoding.

Some attributes may take values only among those present in KB (required 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 install it).
(Integer)
- provide interactive descriptions helpful to people browsing
the date and available services. This descriptive text is often used to
explain technical details about the attribute or version number of about the values
which the distribution. (String) 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 description of comma in attribute encodings, escape
the distribution. (String: default = NONE)

installations = M :: NONE ::
An installation comma with &#44;

Service Templates have the following ABNF [6] grammar:

NOTE that this grammar is not quite correct yet, because it
needs a program which is available lot of work on a file
server.
- relative path and name 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 executable. (String)
- platform the installed program is intended to template will
; be run on.
(String)
- text describing the date and version number allowable format
; of information in the installed program.
(String)
- required configuration to use the program (set environment
variables&#44; required libraries&#44; etc.) (String:
default = NONE)
- a description url-path of the installed program. (String)

documents = M :: NONE::
A document or group
; service-part of documents can be advertised on a server
so as to allow distributed search for the document.
- relative path service scheme.
; The <addr-spec> and name of the document or document directory
(String)
- format the document(s) are in (String)
- a list of keywords (separated by semicolons). These
keywords may be determined by an organization which has an
indexing policy&#44; or done in an ad hoc manner. These
keywords FAQ fields do not have to be guessed&#44; they can be
accumulated and presented to a user or queried for.)
(String)
- date and or version of the document. (String)
- description of the document (String: default
; require additional specification.
attr-defs = NONE )

space *(attr-def/keydef)
attr-def = M :: NONE ::
Space indicates that a filesystem has room for temporary files.
- Available space (in KB). (Integer)
- Policy statement (how long can files be left on the server&#44;
will files be considered temporary and removed when convenient?)
(String)"

6.1.2. Example: A 'pub' directory

Suppose I have an NFS server which exports two filesystems. The
first one is a 'pub' directory with some documents, the second one 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 'dist' directory with both installed software and software ready to
download and install.

Guttman human readable description of

Guttman,Perkins Expires 6 December 1997 [Page 18] 10]

Internet Draft The Service: URL Scheme 20 November 1996

For the pub directory I will assign the following 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 to are allowed
; L "Literal", values MUST NOT be translated
; X means explicit match required
; O "Optional", the
attributes above:

"version = 0.0

Language tag = en

authorization policy attribute may be omitted

value = world readable

use policy string / integer / boolean / opaque
type = Documents here "STRING" / "INTEGER" / "BOOLEAN" |
"OPAQUE" / "KEYWORD"
; These strings are for internal company use only

documents not to be translated.

string =
./slides \t powerpoint \t marketing&#44; quarterly reports \t
10/15/96 \t This directory contains slides are from
presentations made over safe-char *[safe-chars / SPACE] safe-char

integer = [-] 1*DIGIT
; The integer MUST fall within the last year.
./meeting-notes \t text \t planning&#44; update \t 10/22/96 \t
This directory is a repository for all group meetings.
We keep it up to date and hold our meetings once every
25 days.,
./cartoons \t gif \t silly \t 3/23/96 \t This directory has
a bunch range of silly cartoons from a website I like.

distributions=NONE

installations=NONE

space=NONE"

Notice that there are multiple
; values for the attribute "documents."
I use a tab delimited format in order to group 5 items together in
the same value. Carriage returns and white space is basically ignored
BETWEEN values, but is relevent IN values.

6.1.3. Example: A 'dist' directory

Here is an example of where I use an NFS server 32 bit integer may take, ie.
; -2147483648 to provide access 2147483647.

boolean = "TRUE" / "FALSE"
; These strings are not to
software. I will include software in distributed format be translated.

com-chars = safe-char / white-sp / "*" / "," / ";"/ "&"

safe-char = attrchar / " " / "!" / '"' / "%" / "'" /
"(" / ")" / "+" / "," / "-" / "." / "|" /
":" / "=" / "?" / "[" / "]" /
"" / "/" / "" / " "
; All ASCII printable characters are
; included except ",", "&", "*" and
installed format. "#".

white-sp = SPACE / TAB
rad64-char = ALPHA / DIGIT / "+" / "-" / white-sp
opaque = 1*DIGIT ":" 4*rad64-char
; The distributed format allows someone to either
download the distribution or install directly off digits define the fileserver.
The installation is already ready to run on original length of
; the fileserver (ie. it opaque value. The restricted character
; string is
a distribution which has been installed and resides on the
fileserver, in my meaning radix-64 encoding of the word 'distribution.')

This form of software distribution is unnecessary if you are using an
'applet' approach, but opaque
; value. See [5], Section 5.2.
; NOTE: White space is still absolutely required if you are
distributing full applications, scripts, documentation packages, etc.

Say we have two pieces of software, a word processor WP and a

Guttman ignored in decoding
; radix-64 values.
newline = CR / ( CR LF )

Guttman,Perkins Expires 6 December 1997 [Page 19] 11]

Internet Draft The Service: URL Scheme 20 November 1996

Calendar program CP. The sofware runs on 3 platforms, Solaris 2.5
and up, Windows 95 and NT 4.0, and MacOS 7.5 and up. We will call
these platforms Sol2.5, Win32 and MacOS7.5. Our file server will
offer these preinstalled for Sol2.5 Service Templates and MacOS7.5 but not for Windows
- as software configuration for this platform very often requires
modification of the individual host's registry file. The attributes
for this content on the file server could be:

"version = 0.0

Language tag = en

authorization policy=
The files available here URLs 6 June 1997

ABNF should be accessed only by the
Sales Dept. of Acme Corp.

use policy=
The Sales Dept have some way of Acme Corp. (and no one else) has denoting a
software license for all software available here.

space=NONE

documents=NONE

distributions=
./wp-zog/distrib/wp-zog-1-31-sol25.tar.Z \t Sol2.5 \t
2054 kb \t 01/13/96 \t version 1.31 \t
Word processor from Zog Corp - for X/Motif.,
./wp-zog/distrib/wp-zog-1-31-win32.zip \t Win32 \t
3056 kb \t 01/13/96 \t version 1.31 \t
Word processor from Zog Corp - for Windows NT and 95,
./wp-zog/distrib/wp-zog-1-31-mac.hqx \t MacOS7.5 \t
1980 kb \t 02/23/96 \t version 1.31m \t
Word processor from Zog Corp - for Macintosh,
./cp-foo/distrib/cp-foo-2-01-sol25.tar.Z \t Sol2.5 \t
1044 kb \t 08/02/95 version 2.01 \t
Calender Program from Foo - for Solaris 2.5,
./cp-foo/distrib/cp-foo-2-11-win32.zip \t Win32 \t
2096 kb \t 11/30/95 \t version 2.11 \t
Calander Program from Foo - for Windows 95,
./cp-foo/distrib/cp-foo-1-4-mac.hqx \t MacOS7.5 \t
733 kb \t 03/23/95 \t version 1.4 \t
Calander Program from Foo - for Macintosh

installations=
./wp-zog/sol-inst/wp-zog \t Sol2.5 \t 01/13/96 version 1.31 \t
\t Word processor from Zog Corp - for X/Motif.,
./wp-zog/mac-inst/wp-zog \t MacOS7.5 \t 02/23/96 version 1.31m \t

Guttman [Page 20]

Internet Draft The Service: URL Scheme 20 November 1996

Word processor from Zog Corp - for Macintosh,
./cp-foo/sol-inst/cp-foo \t Sol2.5 \t 08/02/95 version 2.01 \t
Set CP-HOME environment variable to ./cp-foo/inst/cp-foo \t
Calander Program from Foo - for Solaris 2.5,
./cp-foo/mac-inst/MyCal \t MacOS7.5 \t 03/23/95 version 1.4 \t
\t Calander Program from Foo - for Macintosh"

This could be registered as an attribute string associated with the
URL "service:nfs://myhost.sun.com/dist".

The attribute values MUST supply continuation
line! Otherwise, it is ambiguous whether a complete 'record'; they declare
the contents of the file repository, the installation or the
distribution. The notation used for platform name, configuration
requirements and so forth next line is informal and MAY be formalized in the
service template text. a
continuation or starts with some bizarro nonterminal.

Note that in the example above, only on the third installation had any
special configuration use of white space:

A string is considered to be done on a token in the client. The other
installations had case of a blank field where configuration details would
normally be. tag or
<string> value. In this case these take on the default value given in case, the template (NONE).

6.2. Line Printer Daemon Protocol

The service type string for the Line Printer Daemon Protocol is
"LPR".

The protocol it refers 'trimmed'. White space
interior to a string token is defined in [RFC1179].

The URL has service specific information which specifies print queue
name. The syntax for left alone, while white space between
the urlpath for specifying this is: tokens is removed. For example:

" some name = 1*[ DIGIT / ALPHA ]
urlpath = "/" name

The attributes 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 lpr service are largely derived from 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
Printer MIB [RFC1759]. The attributes specified are a subset type of
those
each value is the same. Boolean attributes may not take multiple
values.

Attributes and values must be given in exactly the MIB document, as same order in
translated service templates. This will allow the goals of service attributes are
different than that of system management. The attributes specified
here are intended templates
to facilitate automatic be used to translate attributes and user selection of
services not values to provide service statistics or notification. In
short, the target audience of other languages
(using service attributes are users, either
processes or people, where the audience of MIB statistics are network
managers.

In all cases the templates as look up tables.)

3.2.4. Grouping attribute values and terms together in [RFC1759] take precedence over
those listed below. records

Some default "unknown" values have been added attributes may be related, which are is to say, not part of independent.
Each configuration, for instance, might have a limitation and a best
use. If these were encoded in separate attributes, the Printer MIB specification.

Guttman dependency
would not be clear:

Guttman,Perkins Expires 6 December 1997 [Page 21] 12]

Internet Draft The Service: URL Scheme 20 November 1996

The service template for LPR follows:

"Service Discovery Multicast Address = NONE

service type = LPR

version Service Templates and URLs 6 June 1997

Configuration = 0.0

Language tag A,B,C
Restriction = en

Description 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 LPR service provides line printer spooling&#44; using
suggested convention is to choose one of the BSD Unix print spooling protocol&#44; formalized in
RFC 1179. The attributes associated with the LPR
service refer ranges to be
the printer actual printing service attribute base. Here, it will be performed.

Status = INTEGER L :: 1 ::
The status is taken from the Printer Status object configuration. The others
attributes are, by conventions, extensions of the
host MIB&#44; hrDeviceStatus. this record. The enumerated values have
the
following definitions:
1 makes all dependencies explicit:

Configuration-A.Restriction = unknown The state is unknown.
2 slow,low-priority
Configuration-A.Best-Use = running The device is up: No known errors.
3 batch-jobs
Configuration-B.Restriction = warning Still operational: Agent has been warned.
4 unpredictable
Configuration-B.Best-Use = testing Not available: In the 'testing' state.
5 interactive-use
Configuration-C.Restriction = down Not available.

Location Description large
Configuration-C.Best-Use = :: NONE ::
This is a text description of the location of cpu-intensive

Note that the printer.
It may make use of office landmarks and so forth to guide
people.

Location Address = :: NONE ::
This such grouping is the Postal Address conventional, by use of the printer
dot as a minimum.
It should also include any office number or other location
notation used within an organization.

Operator = :: NONE ::
The name and possibly telephone number of the person
responsible for operating the printer. This value should
be obtained from the prtGeneralTable of the Printer MIB&#44;
from the prtGeneralCurrentOperator object of the
prtGeneralEntry if possible.

Service Person = :: NONE ::
The name <tag> character, and possibly telephone number of the person
responsible for servicing the printer if it breaks down.
This value should be obtained from the prtGeneralTable of

Guttman [Page 22]

Internet Draft The Service: URL Scheme 20 November 1996 does not place any constraint on
the Printer MIB from parsing mechanisms used by agents storing the prtGeneralCurrentOperator object
of visually related
attribute values.

3.3. Special attributes

Every service template must define the prtGeneralEntry&#44; if possible.

Use policy = :: NONE ::
Any restrictions to use&#44; such as intended users should be
described here.

Feed type = INTEGER :: 2 :: following attributes:

3.3.1. Service Type Language

This describes is a two letter code defining the feeder mechanism language of the printer. template [8].

3.3.2. Version

The
value should be assigned from the prtInputDefaultIndex
entry version of the prtInputTable of Service Type template. A proposal starts at 0.0,
and the Printer MIB if possible.
This minor number increments once per revision. The Version
attribute takes the has a string value of the prtInputType item
in form:

version = 1*DIGIT '.' 1*DIGIT

A standardized template starts at 1.0. Additions of attributes add
one to the prtInputEntry sequence. The textual minor number, where changes of definition or removal of
the integer type
attributes or values are:
1 = other
2 = unknown
3 = sheetFeedAutoRemovableTray adds one to the major number. See Section 4 = sheetFeedAutoNonRemovableTray
5 = sheetFeedManual for
more detail on how to use the Version attribute.

Guttman,Perkins Expires 6 = continuousRoll
7 = continuousFanFold

Media length = INTEGER :: -2 :: December 1997 [Page 13]

Internet Draft Service Templates and URLs 6 June 1997

3.3.3. url-path rules

This value indicates is a text attribute which defines the length (in semantics of the direction url path
of the
printer feed) service: URL of the media. given type.

The value -2 indicates that <service-part> is of the length form:

/<addr-family>/<addr-spec>/<url-path>;FAQ

The <url-path> description specifies additional information to locate
a service when the <addr-spec> is unknown&#44; -1 means there not sufficient, and is no limit. All
other values are a field
whose content that distinguishes URLs of a particular service type
from those of another service type. For instance, in the Media units given below. This
value should be obtained from case of a
printer service: URL, the default prtInputEntry
(see Feed type) from url-path will typically be a queue name,
but not in the prtInputMediaDimFeedDirDeclared
item.

Media width = INTEGER :: -2 ::
As case of a service: URL for Media length. This value indicates the width
(across the feed path) 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 Media. The item to use
is prtInputMediaDimXFeedDirDeclared.

Media units = INTEGER :: -1 ::
-1 indicates the units are unknown. The value from for the
default prtInputEntry should be used (see Feed type).
The prtInputDimUnit item should be used. The values
are defined as:
3 = .0001 inches
4 = micrometers

Media type = L :: stationary ::
The Media type describes what is service: URL.
This MUST have its 'Version' attribute set to be printed upon. "0.0" initially.

The value from minor version number will increment once with each change until
it achieves 1.0. There is no guarantee any version of the default prtInputEntry should service
template will be used
(see Feed type): backwards compatible before it reaches 1.0.

Once a service template has reached 1.0, the item definition is prtInputMediaType. The

Guttman [Page 23]

Internet Draft The Service: URL Scheme 20 November 1996

defined values are:
stationery Separately cut sheets of an opaque material
transparency Separately cut sheets of a transparent
material
envelope Envelopes that can be used "frozen"
for conventional
mailing purposes
envelope-plain Envelopes that are not preprinted and have no
windows
envelope-window Envelopes version. New templates may be defined, of course, to refine
that have windows definition, but they must follow these rules:

- Any new attribute defined for addressing
purposes
continuous-long Continuously connected sheets 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 an opaque
material connected along 1.y (where x<y) as
it will ignore attributes it doesn't know about.

- Deprecating or changing the long edge
continuous-short Continuously connected sheets definition of an opaque
material connected along attribute requires
changing the short edge
tab-stock Media with tabs
multi-part-form Form medium composed major version number of multiple layers not
pre-attached a service template. A user
agent may be unable to one another; each sheet 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
drawn separately from an input source
labels Label stock
multi-layer Form medium composed of multiple layers which
are pre-attached posted to one another; e.g.&#44; the Service Location Working Group
mailing list for use with impact printers

Media color = L :: unknown ::
The Media color describes review. Ideally, experts in the color implementation and
deployment of what is printed upon.
The value from the default prtInputEntry should particular protocol will be used
(see Feed type): the item is prtInputMediaColor. The
defined values are:
other unknown white
pink yellow buff
goldenrod blue green
transparent
According consulted so as to [RFC1759]:
Implementors may add additional string values. The naming
conventions in ISO 9070 are recommended in order

Guttman,Perkins Expires 6 December 1997 [Page 14]

Internet Draft Service Templates and URLs 6 June 1997

more attributes or change their definition to avoid
potential name clashes.

Max speed = INTEGER :: -1 ::
The maximum speed make them as useful as
possible.

All published versions of the printer expressed in Speed units.
This value template must be available on-line,
including obselete ones.

QUESTION:
Where?

Once there is no more active dissent the Service Type should be obtained
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 prtMediaPathMaxSpeed
object in
syntax for the default prtMediaPathEntry . -1 indicates
'other'&#44; or 'unknown'.

Speed units 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 = INTEGER :: 8 ::
This value determines unit of speed for the Max speed. The
value should be obtained from the prtMediaPathMaxSpeedPrintUnit
of the default prtMediaPathEntry. The definitions of the

Guttman [Page 24]

Internet Draft The Service: URL Scheme 20 November 1996

values are:
3 ALPHA / ALPHA *[ okchar / "-" ] okchar
hostnumber = tenThousandthsOfInchesPerHour -- .0001/hour
4 ipv4-number / ipv6-number
ipv4-number = micrometersPerHour
5 1*3DIGIT 3*3("." 1*3DIGIT)
ipv6-number = charactersPerHour
6 32hex
port = linesPerHour
7 1*DIGIT
user = impressionsPerHour
8 *[ uchar / ";" / "?" / "&" / "=" ]
url-path = sheetsPerHour
9 *xchar ; each Service Type must define its
; own syntax (section 3)
safe = dotRowPerHour
16 "$" / "-" / "_" / "." / "+"
extra = feetPerHour
17 "!" / "*" / "'" / "(" / ")" / ","
hex = metersPerHour

Interpreter Language DIGIT / "A".."F" / "a".."f"
escape = M :: 37 \t 1 \t 1 ::
The Interpreter Language determines what forms of input the
printer can accept "%" 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 interpret. Multiple values are
possible;
each of which has a tab delimited form with three values.
The table is populated by a complete traversal of the
prtInterpreterTable. URLs 6 June 1997

6. Examples

The items to use Service Templates for the fields SLP Directory Agent and POP3 service
are given below. See [RFC1759] for their definitions.
- prtInterpreterLangFamily (INTEGER: Default value is 37
or langAutomatic.)
- prtInterpreterLangVersion (INTEGER: Default value is 1.)
- prtInterpreterLangLevel (INTEGER: Default value is 1.)"

6.3. POP3

6.1. SLP Directory Agent

The POP3 directory-agent service type is "POP3".

The protocol it refers to is defined in [RFC1936].

The 'urlpath' has the default syntax. (See Section 3.1.2.)

The service template for no attributes except scope.

6.2. POP3 is as follows:

"service type

template.service-type = STRING L
POP3
# This is the template for the POP3

Service Discovery Multicast Address = NONE

version service.

template.version = STRING L
0.0

Language tag = en

Description
# 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 services 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

Guttman [Page 25]

Internet Draft The Service: URL Scheme 20 November 1996 to authenticate
# themselves. Finally&#44; Finally, the POP3 server policy statement 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 :: NONE ::
# This is a list of all users (by user name) which 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
POP3 server supports.

APOP structure of the <service-part>
# is for the service type being specified.

attr-specs = BOOLEAN L :: FALSE ::
This STRING M
# The value of this attribute determines whether is the POP3 server supports template text, defining
# all the POP3 AUTHentication command [RFC1734].

Policy = :: NONE ::
This describes service type attributes.

Of the POP3 policy regarding use. In particular
users mandatory attribute tags, only "description" may be dissuaded from keeping mail on the server or
keeping more than 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 certain amount paragraph of mail on text describing the server."

Mail clients may discover POP3 servers which support these attributes
in a new way. A user need only supply her user name
attribute and the client
can proceed to use a dynamic configuration protocol, such as Service
Location, to determine the server and whether to use APOP. If all the
POP3 server is down, a backup server may values it can take on. This information
will be discovered using the same
mechanism, transparently used by those who develop user interfaces to the user.

An example of display service
information and those who advertise services using attributes
associated with a particular POP3
server might be:

<URL:service:pop3://mailfriend.incog.com>

"version = 0.0

Language tag = en

Mailboxes = larry, curly, moe, shemp

APOP = FALSE

Policy = Mail should not be left on the server."

A translation of these attributes could be associated with 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 same
URL DA to make determine if the policy readable to non-English speakers. For
example,
service template has already been registered, and if so, abstain from
registering the following service template.

This is a translation to German:

"version = 0.0

Language tag = de

Mailboxes = larry, curly, moe, shemp

Guttman [Page 26]

Internet Draft an area which definitely needs work. The Service: URL Scheme 20 November 1996

APOP = FALSE

Anweisung = Mail darf nicht auf dem Server bleiben."

Note difficulty
is that only the last in order for a service template to be retrieved as
an attribute is translated. That is because
version and Language tag are not translated (see Section 3.4.2.) of some registered service: URL (presumably
of type service:template:), one would have to allow extra
newlines and
Mailboxes space and APOP are marked with a 'L' reserved characters in tricky places.
On the POP3 template.

7. Security Considerations

Security considerations are other hand, devising a new method (a new service) of
handing out such information is not discussed in this memo. immediately attractive.

8. Internationalization Considerations

The service: URL itself must be encoded using the rules set forth
in
[RFC1738]. [4]. The character set encoding is limited to specific ranges
within the US-ASCII character set [ASCII]. [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. [CHAR-REG]

It can be assumed that name, found at:
http://www.isi.edu/in-notes/iana/assignments/character-sets

US-ASCII [ASCII] will 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 [SLP] [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 [RFC1766]. [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

Guttman [Page 27]

Internet Draft The Service: URL Scheme 20 November 1996
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 are (or eventually are) (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.

A given service: URL may have several sets of attributes associated
with it. Each set

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 localized able to interpret service information obtained by SLP.

Service URLs themselves specify the service access point and
protocol for a particular language.
Mechanisms for obtaining service attributes MUST type. These Service URLs could be parameterized
distributed and indicate the location of a service other than that
which a user would normally want to
allow selection use. SLP distributes Service
URLs and has an authentication mechanism which allows Service URLs of language
advertised services to be signed and these signatures to be verified
by Language tag. This way, users may
access the same information in their own language.

9. Bibliography

[ABNF] D. Crocker, "Augmented BNF clients.

Guttman,Perkins Expires 6 December 1997 [Page 20]

Internet Draft Service Templates and URLs 6 June 1997

References

[1] H. Alvestrand. Tags for Syntax Specifications:
ABNF", Work in progress, November 1996.

[ASCII] "Coded the Identification of Languages. RFC
1766, March 1995.

[2] ANSI. Coded Character Set -- 7-bit American Standard code for
Information Interchange", ANSI X3.4-1986.

[CHAR-REG] IANA Character Set registry, <URL:http://www.isi.edu
/in-notes/iana/assignments/character-sets>.

[FINDING] Interchange. X3.4-1986, 1986.

[3] T. Berners-Lee, R. Moats, M. Hamilton, "Finding Stuff (Providing
information to support service discovery)", Work in
progress, November 1996.

[NFSURL] B. Callaghan, "NFS URL Scheme", Work in progress,
October, 1996.

[RFC2055] B. Callaghan, "WebNFS Server Specification", RFC 2055.
July 1996.

[RFC2054] B. Callaghan, "WebNFS Client Specification", RFC 2054.
July 1996.

[RFC1939] J. Myers, M. Rose, "Post Office Protocol - Version 3",
RFC 1939. Fielding, and L. Masinter. Uniform
Resource Locators (URL): Generic Syntax and Semantics.
draft-fielding-url-syntax-05.txt, May 1996.

Guttman [Page 28]

Internet Draft The Service: URL Scheme 20 November 1996

[RFC1759] R. Smith, F. Wright, T. Hastings, S. Zilles, J.
Gyllenskog, "Printer MIB", RFC 1759. March 1995.

[RFC1766] H. Alvestrand, "Tags for the Identification of
Languages", RFC 1766. March 1995.

[RFC1738] 1997. (work in progress).

[4] T. Berners-Lee, L. Masinter & Masinter, and M. McCahill, "Uni-
form McCahill. Uniform Resource
Locators (URL)", (URL). RFC 1738. 1738, December 1994.

[RFC1734] J. Myers, "POP3 AUTHentication command",

[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 1734.
December 1994.

[RFC1179] L. McLaughlin III, "Line Printer Daemon Protocol", 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 1179. August 1990.

[SLP] 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 & Perkins, and S. Kaplan, Kaplan. Service
Location Protocol", Work in progress,
November 1996.

10. Author's Address 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, Inc. 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

This memo expires on May 20, cperkins@corp.sun.com

Guttman,Perkins Expires 6 December 1997

Guttman [Page 29] 22]

----