WDIFF

draft-ietf-svrloc-template-conversion-03.txt --> draft-ietf-svrloc-template-conversion-04.txt

Service Location Working Group Pete St. PierreInternet Engineerinf Task Force James Kempf
INTERNET DRAFT Sun Microsystems
1
20 June 1998 1999 Ryan Moats
AT&T Laboratories
Pete St. Pierre
Sun Microsystems

Conversion of LDAP Schemas to and from SLP Templates
draft-ietf-svrloc-template-conversion-03.txt
draft-ietf-svrloc-template-conversion-04.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 srvloc@srvloc.org mailing list.

Distribution of this memo is unlimited.

This document is an Internet-Draft. Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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 "work in progress.''

To view the entire progress."

The list of current Internet-Drafts, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts can be accessed at:

http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

The Lightweight Directory Access Protocol (LDAP) can be accessed at:

http://www.ietf.org/shadow.html.

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page i]

Internet Draft Schemas and Service Location
Protocol (SLP) are both useful mechanisms Templates 20 June 1999

Abstract

This document describes a procedure for locating mapping between SLP service
related information on a network. While they do perform similar
functions,
advertisments and LDAP descriptions of services. The document
covers two aspects of the way mapping. One aspect is mapping between
SLP service type templates and LDAP directory schema. Because the
SLP service type template grammer is relatively simple, mapping from
service type templates to LDAP types is straightforward. Mapping
in which the information they provide other direction is formatted straightforward if the LDAP schema is very different. This document describes a
restricted to the set of rules and
mappings for translating between the attribute types defined in RFC 2252. If
arbitrary ASN.1 based LDAP schema and
an SLP Template as described types occur in the "Service Template schema, then the mapping is
more complex and service:
Scheme" draft.

St.Pierre Expires 1 December 1998 [Page i]

Internet Draft Schemas may even be impossible. The second aspect is
representation of service information in an LDAP directory. The
recommended representation simplifies interoperability with SLP by
allowing SLP directory agents to backend into LDAP directory servers.
The resulting system allows service advertisements to propagate
easily between SLP and Templates 1 June 1998 LDAP.

Contents

Status of This Memo i

Abstract i ii

1. Motivation Introduction 1

2. ASN.1 and BER Encodings 1

3. ASN.1 Types and Mapping SLP Templates to LDAP Schema 2

4. URLs and Distinguished Names 3

5.
2.1. Mapping from SLP Templates Attribute Types to LDAP Schemas 3
5.1. Data Type Mappings Attribute Types 5
2.1.1. Integer . . . . . . . . . . . . . . . . . . . 3
5.2. Integer . . 6
2.1.2. String . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Boolean . . 4
5.3. String . . . . . . . . . . . . . . . . . . . 6
2.1.4. Opaque . . . . . . 4
5.4. Boolean . . . . . . . . . . . . . . . 7
2.2. Keyword Attributes . . . . . . . . . . 4
5.5. Opaque . . . . . . . . . 7
2.3. Template Flags . . . . . . . . . . . . . . . . 5
5.6. Enumerations . . . . . 7
2.3.1. Multi-valued . . . . . . . . . . . . . . . . . 5
5.7. Multi-valued Attributes . . . . 7
2.3.2. Optional . . . . . . . . . . . . . 6
5.8. Optional Attributes . . . . . . . 8
2.3.3. Literal . . . . . . . . . . . . 6
5.9. Literal Attributes . . . . . . . . . 8
2.3.4. Explicit Matching . . . . . . . . . . 6
5.10. Explicit Matching . . . . . . 8
2.4. Default and Allowed Value Lists . . . . . . . . . . . . . 8
2.5. Descriptive Text . 6
5.11. Template for Translation . . . . . . . . . . . . . . . . 6
5.12. Translated Schema . . . 9
2.6. Example . . . . . . . . . . . . . . . . . 8

6. Mapping from Schemas to Templates 10
6.1. Data Type Mappings . . . . . . . . 9

3. Mapping from Schema to Templates 12
3.1. Mapping LDAP Attribute Types to SLP Attribute Types . . . 13
3.2. Mapping ASN.1 Types to SLP Types . . . . . . . . 10
6.2. Integer . . . . 15
3.2.1. Integer . . . . . . . . . . . . . . . . . . . . . 10
6.3. 15
3.2.2. Case Ignore String, Case Exact String . . . . . . . . . . 11
6.4. 16
3.2.3. Boolean . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.5. 16

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page ii]

Internet Draft Schemas and Templates 20 June 1999

3.2.4. Octet String . . . . . . . . . . . . . . . . . . . . . . 11
6.6. 16
3.2.5. Binary . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.7. 16
3.2.6. Enumeration . . . . . . . . . . . . . . . . . . . . . . . 11
6.8. Rules for Other ASN.1 Primitive Types . . . . . . . . . . 12
6.9. 16
3.2.7. Set Of . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.10. 17
3.2.8. Real . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.11. 17
3.2.9. Object Identifier . . . . . . . . . . . . . . . . . . . . 12
6.12. 18
3.2.10. Sequence Of . . . . . . . . . . . . . . . . . . . . . . . 13
6.13. 18
3.3. Example ASN.1 Schema to be Translated . . . . . . . . . . . . . . . . . 14
6.14. SLP Translation . . . . . . . . . . . . . . . . . . . . . 15

7. Notes on Matching Operators 16

St.Pierre Expires 1 December 1998 [Page ii]

Internet Draft Schemas and Templates 1 June 1998

8. Acknowledgments 17

A. References 17 18

4. Representing SLP Service Advertisments in an LDAP DIT 20

5. Internationalization Considerations 22

6. Security Considerations 22

1. Motivation Introduction

SLP templates[1] templates [2] are intended to create a simple encoding of the
syntactic and semantic conventions for individual service types,
their attributes, and conventions. This They can easily be generated,
transmitted, read by humans and parsed by programs, as it is a string
based syntax with required comments.

On the other hand, directory Directory schemas serve to
formalize directory entry formulation structures for use with services like LDAP[2]. LDAP [3]. These
directories serve to store information about many types of entities.
Network services are an example of one such entity.

The ability to register services across both SLP[3]

Interoperability between SLP and schema based
directory LDAP is important so clients using
one protocol derive benefit from services registered through the
other. In addition, LDAP directory servers can serve as the backend
for SLP directory agents (DAs) if interoperability is a useful capability. possible In
order to facilitate
this, interoperability, this document creates mappings
between the SLP template grammar and the LDAP directory schemas.

The simple notation schema, and syntactic/semantic attribute capabilities
establishes some conventions for representing service advertisements
in LDAP directories. The goal of SLP will map well into the translation is to allow SLPv2
queries (which are syntatically and semantically equivalent to LDAPv3
string queries [7]) to be submitted to an LDAP directory schemas. This means that
service server by an
SLP DA backended into LDAP without extensive processing by the DA.

The simple notation and syntactic/semantic attribute capabilities
of SLP templates will map easily into directory schemas, and are easily be
converted into directory schemas. schemas, even by automated means. The
reverse is may not be true. Only a certain restricted set of types,
matching rules and encoding conventions used with If the LDAP will be
directly mappable into service type templates. There are rules
to cover schema contains arbitrary ASN.1
types, the cases where mapping cannot translation may be done directly. It is
believed that difficult or impossible. If, however,
the cases which are not supported are LDAP schema contains the exception
rather than types described in RFC 2252 [8], then
the rule. translation is more straightforward.

This document will outline outlines the correct mappings for SLP templates into
the four basic
data types supported syntatic representation specified for LDAP directory schema by SLP to

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 1]

Internet Draft Schemas and Templates 20 June 1999

RFC 2252 [8]. This syntax is a subset of the ASN.1/BER described in
the X.209 specification[4]. This specification [9], and is the encoding used by the LDAP[2] LDAPv3 [3] directory
schema. Likewise, rules and guidelines will be are proposed to facilitate
consistent mapping of ASN.1 based schemas to be translated in the
SLP template grammar. Finally, a proposal for a representation
of service advertisements in LDAP directory services is made that
facilitates SLP interoperability.

2. ASN.1 and BER Encodings

ASN.1 defined schemas are assumed Mapping SLP Templates to be encoded using LDAP Schema

SLP service type templates begin with four definitions that set the Basic
Encoding Rules(BER) defined in CCITT Recommendation X.209[4]. The
X.209[4] specification contains details
context of the on-the-wire encoding
of ASN.1 values. BER supports 4 types of encodings: Universal,
Application, Context Specific and Private. All SLP types will map to
Universal BER encoded values.

St.Pierre Expires 1 December 1998 [Page 1]

Internet Draft Schemas and Templates 1 June 1998

Within template:

template-type

This defines the scope service type of Universal types, there are both primitive
encodings and constructed encodings. A primitive encoding is a data
value encoding in which the content octets directly represent the
value. Constructed encodings are data values encoding template. The service
type can be a simple service type, like ``service:ftp'', an
abstract service type, like ``service:printer'' or a concrete
service type, like ``service:printer:lpr''. The name that
appears in which this field omits the
content octets are ``service:'' prefix.

template-version

A string containing a major and minor version number, separated
by a period.

template-description

A block of human readable text describing what the complete encoding service type
does.

template-url-syntax

An ABNF [5] grammer describing the service type specific part
of one or more other data
values. [2]

This document will deal primarily with mapping the service URL.

The SLP template-type definition is used as the name of the ASN.1 primitive
encodings to
class for the template. If the template defines an SLP data types.

3. concrete
type, then the generic URL scheme name or protocol name becomes the
ASN.1 Types class name and LDAP

Because of the simplicity of SLP data types, any SLP data abstract type
can be represented in ASN.1. This does not mean, however, that
all LDAP servers may be able to handle all name is the ASN.1 types we create.
Specifically, most LDAP servers do not support superclass.
For example, the template for ``service:printer:lpr'' is translated
into an ASN.1 enumerations.

Also, not all LDAP servers are extensible. While some LDAP servers
may allow class called ``lpr'' having a superclass ``printer''.
If the template defines a simple SLP type or an abstract type,
then the superclass is ``top''. An example is the template for
``service:printer'', which is an abstract type, or ``service:ftp'',
which is a simple type. In the definition case of new an SLP abstract type,
the ASN.1 syntax definitions, there class is a base set of ``ABSTRACT'', while concrete types and simple
types that are common among most LDAP servers.
These ``STRUCTURAL''. Since there is no way syntactically to

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 2]

Internet Draft Schemas and Templates 20 June 1999

differentiate between abstract types are:

Distinguished Name
Case Ignore String
Case Exact String
Binary
Integer

Some LDAP implementations may also support an ASN.1 definition for
telephone numbers. This syntax allows for searching without regard
for hyphen and parenthesis use. simple types in an SLP Type ASN.1 Type Common LDAP Type
----------------------------------------------
Integer Integer Integer
String String Case Ignore String
Boolean Boolean Case Ignore String
Opaque Octet String Binary

Because of
service type template, the limitations designation of many abstract v.s. structural
for the LDAP servers. All SLP data types
will type must be discussed entered by hand.

The template-version definition is partitioned into two attributes,
major-version-number and minor-version-number. The LDAP definition
for these attributes is (note: all numericoids used in this document
are samples, they do not represent actual numericoids):

( <standardOID1>
NAME 'major-version-number'
DESC 'The major version number of the context service type template'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
NO-USER-MODIFICATION
)

( <standardOID2>
NAME 'minor-version-number'
DESC 'The minor version number of the common LDAP data types listed
above. When coverting service type template'
SYNTAX 'INTEGER'
EQUALITY integerMatch
SINGLE-VALUE
NO-USER-MODIFICATION
)

These attributes are marked NO-USER-MODIFICATION because they are
set by the definition of the template, and they are required (MUST
contain) attributes in the ASN.1 class translated from an the template.

The template-description, and template-url-syntax definitions in the
SLP template to an LDAP schema, these are described by the preferred data types for translation. For completeness,
alternate ASN.1 syntaxs are presented for each data type. It should following attributes:

( <standardOID3>
NAME 'template-description'
DESC 'A block of human readable text describing what the
service type does'
SYNTAX 'IA5String'
EQUALITY caseExactMatch
SINGLE-VALUE
)

( <standardOID4>
NAME 'template-url-syntax'
DESC 'An ABNF [5] grammar describing the service type

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 2] 3]

Internet Draft Schemas and Templates 1 20 June 1998

be noted that deployment 1999

specific part of these types may not be supported by all
LDAP implementations.

4. URLs and Distinguished Names

SLP uses URLs to uniquely identify a the service instance. These
URLs must somehow be converted to unique handles or "Distinguished
Names" for inclusion in an LDAP directory. This document proposes a
mechanism for storing an SLP URL as a Relative Distinguished Name.

5. Mapping from URL'
SYNTAX 'IA5String'
EQUALITY caseExactMatch
SINGLE-VALUE
)

We further establish the convention that SLP Templates to template characteristcs
that can't be translated into LDAP Schemas are inserted into the DESC field
of the object class definition. The first step in mapping a template is to create items are separated by empty
lines, start on a Distinguished
Dame (DN) for new line, and are tagged at the beginning of the entry.
line to indicate what they represent. This DN is used allows the template to uniquely identify be
reconstructed from the
record within schema by properly parsing the LDAP hierarchy. We do this in two steps, using the
service URL. comments.

The first step is to create bulk of an DN. Since URLs SLP template consists of attribute definitions. There
are likely to contain
characters four items in an SLP template attribute definition that need to
be mapped into LDAP:

Attribute Name

Since SLPv2 attribute names are not allowed in a DN, we must find a way defined to
remove them. Also, the resulting DN must be unique across all peers
in the compatible with
LDAPv3, SLP attributes map directly into LDAP name space. In order to meet these criteria, we take
the URL and perform an MD5 [6] hash attributes with
no change. Similarly, LDAP attributes map directly to obtain a unique bit string
that represents the URL. This bit string SLP
attributes.

Attribute Type

The SLP attribute type is then represented as hex
digits, and used for mapped into the value LDAP attribute type.

Attribute Flags

The SLP attribute flags are mapped into characterics of
the DN.

Secondly, we create an LDAP attribute called "url". This definition, or into the DESC field if no
equivalent LDAP attribute is
of type Case Ignore String. In this attribute, we store definition characteristic occurs.

Default and Allowed Values

These must be handled by the actual
service URL. client or a DA enabled to handle
templates, as in SLP. For example, the URL service:printer:lpr://www.printserv.net/public
would reference, however, they should be stored
included in an LDAP directory with the following two
attributes. The value 6a1c0bfa0396f6be0bf73c4d1e8c45f1 is produced
from the MD5 hash DESC field of the URL, so the attributes would look like:

DN = 6a1c0bfa0396f6be0bf73c4d1e8c45f1
url = service:printer:lpr://www.printserv.net/public

5.1. Data Type Mappings LDAP attribute definition.

Descriptive Text

The SLP supports four data types. Each of these data types can template descriptive text should be mapped into a specific ASN.1 type. In this way, translation the
DESC field.

We discuss mapping of data types
can be described easily. All SLP data types are encoded as strings types, flags, default and allowed values, and
descriptive text in the protocol. subsections below.

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 3] 4]

Internet Draft Schemas and Templates 1 20 June 1998

Complexity is added when the SLP data type is expressed as 1999

For purposes of representing an
enumeration. This section describes SLP entry, we also define two
standardized LDAP attributes with standardized OIDs (TBD). These
attributes are:

( <standardOID5>
NAME 'service-type'
DESC 'The service type of the translation service advertisement. For SLP service
types, the "service:" is dropped. For SLP abstract types, the
value is "abstract-type:concrete-type".'
SYNTAX 'IA5String'
SINGLE-VALUE
EQUALITY caseIgnoreMatch
)

( <standardOID6>
NAME 'scopes'
DESC 'A list of each data
type to its corresponding ASN.1 scopes for a service advertisement.'
SYNTAX 'IA5String'
EQUALITY caseIgnoreMatch
)

Searchs for abstract types can be made with an LDAP query that
wildcards the concrete type. A discussion For example, a search for all service
advertisements of proper
enumeration handling follows these mappings.

5.2. Integer

Both the printer abstract type can be made with the
following query:

(service-type=printer:*)

SLP templates specifies that service URLs and ASN.1 support Integers, so there is attribute lists can be
accompanied by a one structured authenticator consisting of a digital
signature and information necessary to
one mapping between an verify the signature. Two
standardized SLP Integer attributes are defined for this purpose:

( <standardOID7>
NAME 'url-authenticator'
DESC 'The authenticator for the URL, null if none.'
SYNTAX 'binary'
SINGLE-VALUE
)

( <standardOID8>
NAME 'attribute-authenticator'
DESC 'The authenticator for the attribute list, null if none.'
SYNTAX 'IA5String'

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 5]

Internet Draft Schemas and an Templates 20 June 1999

EQUALITY caseIgnoreMatch
)

Finally, we define the following abstract object class as the parent
class for all services. Any specific service type may add other
attributes.

( <standardOOID1>
NAME 'service'
DESC 'parent superclass for SLP services'
ABSTRACT
SUP 'top'
MUST ( major-version-number \$ minor-version-number \$
template-description \$ template-url-syntax \$
service-type \$ scopes \$ url-authenticator \$
attribute-authenticator )
)

2.1. Mapping from SLP Attribute Types to LDAP Attribute Types

We define the mapping from SLP attribute types to LDAP as follows:

SLP Type ASN.1 Type LDAP Type
----------------------------------------------
Integer
attribute. On Integer Binary
String String Directory String
Boolean String Boolean
Opaque String IA5String
Keyword String IA5String

Note that the wire encoding of these two Integer is very different,
though.

In SLP, all represented by the LDAP Binary type. This
allows SLP integer attributes to be encoded according to the X.680
Basic Encoding Rules (BER) [9] and for the X.500 [6] integer equality
and ordering rules and octet string equality rules to apply rather
than the LDAP attribute type rules described in RFC 2252 [8].

The following subsections discuss further details of the mapping.

2.1.1. Integer

SLP integers are encoded as strings. An integer value of 17869
would be represented by a 5 byte string containing the values of the characters '1', '7', '8', '6', and '9' in the character set
specified in

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 6]

Internet Draft Schemas and Templates 20 June 1999

characters '1', '7', '8', '6', and '9'. SLP integers can include
a negative sign, and the request or response packet. ordering operators ``<='' and ``>='' are
expected to order negative integers correctly.

The ASN.1 Integer LDAP INTEGER type is encoded [8] consists of a string of digits. The LDAP
types described in BER according RFC 2252 have no way of representing negative
integers, and there is no ordering rule for integers that would
handle negative integers.

Consequently, the mapping from the SLP integer type to LDAP is
Binary, and the rules in
section 8 first byte of the X.209 specification.

The encoding Octet String wrapper consists
of an the ASN.1 integer value is primitive. The content
octets shall consist of one or more octets. tag byte for Integer. The rules ensure that an ASN.1 integer value is always encoded in
according to the smallest possible number X.680 [9] BER. The directory server treats the value
as an ASN.1 integer for purposes of
octets.

5.3. matching and comparison.

2.1.2. String

SLP strings are encoded as described in section 20.5 of the SLP protocol
specification [3]. [4]. All value strings are considered case insensitive
for matching operations. These SLP strings are not null terminated and are
encoded in UTF-8.

SLP strings are mapped to the
ASN.1 DisplayString syntax. LDAP servers may or may not support the DisplayString syntax. Directory String type. The
preferred representation of an SLP
Directory String type exactly matches the SLP string type, i.e.
it is Case Ignore String.

5.4. a non-null terminated UTF-8 string. The caseIgnoreMatch
equality rule, caseIgnoreOrderingMatch ordering rule, and
caseIgnoreSubstringsMatch substring rule are used for comparing
string attribute values.

2.1.3. Boolean

Boolean attributes may have one of two possible values. In SLP,
these values are represented as strings, TRUE and FALSE. In SLP's
string encoding of a boolean value, case does not matter.

ASN.1 supports a Universal, primitive

The SLP Boolean type maps directly into an LDAP Boolean. The
caseIgnoreMatch rule is used for equality matching.

2.1.4. Opaque

SLP attribute values of boolean. X.209
specifies that the Contents field of a FALSE boolean value be encoded type Opaque are represented as a single octet string
beginning with a value the nonUTF-8 character ``\ff'' and consisting of the
escaped bytes of zero. A boolean whose value is
TRUE shall be encoded as a single octet whose value shall be any
non-zero value, at the sender's option. opaque, the escape sequence consisting of `\`
followed by the two hex digits of the byte. SLP allows equality
comparison on opaques.

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 4] 7]

Internet Draft Schemas and Templates 1 20 June 1998

Many 1999

SLP opaques encoded as strings are mapped directly into LDAP servers
IA5 Strings and the caseIgnoreMatch equality matching attribute
applies. However, neither the caseIgnoreOrderingMatch nor the
caseIgnoreSubstringMatch rules apply, since SLP opaques do not
support a data string ordering and substring matching on opaques.

2.2. Keyword Attributes

SLP service type templates allow the definition of Boolean. For this
reason, it keyword
attributes. Keyword attributes are attributes whose only
characteristic is recommended that the SLP boolean type be translated
to a Case Ignore String. The value stored in this string should be
either "true" their presence. Keyword attributes have no flag
information, nor any default or "false".

5.5. Opaque

SLP allowed values that are encoded as Opaque (since, by definition,
they have no values).

ASN.1 has no concept of keyword attributes. Keyword attributes are really
translated into a series of octets.
While SLP uses the construct of <len>:<radix-64-data>, this maps
very nicely to the tag/length/value BER encoding of ``May'' clause in the ASN.1 Octet
String.

The <len> field of class defintion for the SLP encoding will not match
service type. If the <len> field keyword attribute is present, then its value
is of no consequence, but for consistency we make it simply the BER encoding, NUL
character, ``\00''.

2.3. Template Flags

SLP template flags can be handled as radix-64 encoding results in a 4 to 3 expansion
of the original data. Likewise, data presented described in radix-64 notation
must be converted back to the original byte stream to be encoded following
subsections.

2.3.1. Multi-valued

Multi-valued attributes are defined in an SLP template using the Contents field of the BER encoding.

LDAP servers most commonly support the Binary data type instead
of the 'M'
flag. This flag indicates that an attribute may have more generic Octet String. For compatibility across LDAP
implementations, SLP Opaque than one
value. All values should for a given attribute must be stored using the LDAP
data type of Binary. As with Octet Strings, the Binary type should
store same type.

LDAP attribute definitions require that a single valued attribute
include the original byte stream, not SINGLE-VALUE tag if the radix-64 notation used within attribute is single valued.
Otherwise, the SLP protocol.

5.6. Enumerations

The SLP template grammar provides for the definition of enumerations.
Enumerations are defined by listing all possible values for the
attribute following any help text provided for that attribute. While
the template syntax allows for creation of enumerations, the SLP
protocol does not strictly enforce enumerations. These enumerations
are still treated as text strings within the protocol, and values
outside the scope of the enumeration defined may be present. The
template enumeration is intended as a guideline to client side
applications as to what values may be expected.

An ASN.1 enumeration commonly maps a text string to a numerical
value. In the BER encoding, the numerical value is passed as an
integer across the wire. The receiving side must then translate
the the value to the associated string as defined in the ASN.1
description.

LDAP servers do not commonly support generic ASN.1 enumerations.
For this reason, the preferred conversion for enumerated SLP values
is Case Ignore String. LDAP servers will not however be able to

St.Pierre Expires 1 December 1998 [Page 5]

Internet Draft Schemas and Templates 1 June 1998

perform value checking to assure stored values are in a legal range.
Applications should always verify values before making use of them.

5.7. Multi-valued Attributes

Multi-valued attributes are defined in an SLP template using the
'M' flag. This flag indicates that an attribute may have more than
one value. All values for a given attribute must be of the same
encoding type. The ASN.1 syntax for SET OF is commonly used assumed to
define multi-valued ASN.1 objects that must be of the same type.

Commonly, LDAP servers assume values may be multi-valued. In these
cases, no additional configuration is necessary.

5.8. multivalued by default.

2.3.2. Optional Attributes

SLP uses the 'O' flag to indicate an attribute may or may not be
present. These optional attributes are defined using the "May"
clause in an the ASN.1 definition. definition class definition for the service type.
All other attributes must be defined as a "Must"

5.9. Literal Attributes

ASN.1 does not have a mechanism to indicate

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 8]

Internet Draft Schemas and Templates 20 June 1999

2.3.3. Literal

ASN.1 does not have a mechanism to indicate that the values of an
attribute may not be translated from one language to another.

5.10. another, since
ASN.1 schema are not typically translated. This flag is dropped when
translating a template, but presence of the flag should be noted in
the DESC field. It should be placed on a separate line and tagged
with ``Literal:'' so the template can be reconstructed from the
schema.

2.3.4. Explicit Matching

The SLP template syntax uses a flag of 'X' to indicate that an
attribute must match exactly with a be present in order for the query made by a client. to be properly
satisfied. There
is, however, is no mechanism to prevent clients from using the
sub-string operator with explicit matching attributes. Common
practice would provision for requiring that particular
attributes be to map in a query. Consequently, this to the ASN.1 matching syntax of
"MATCHES EXACTLY".

5.11. Template for Translation

The template included below flag is derived from dropped when
translating a template, but presence of the printer service
scheme described flag should be noted in [5]. All translations assume
the use of ASN.1
data types supported by all LDAP servers.

type = printer
version = 0.0

St.Pierre Expires 1 December 1998 [Page 6]

Internet Draft Schemas DESC field. It should be placed on a separate line and Templates 1 June 1998

language = en

description = tagged
with ``Explicit:'' so the template can be reconstructed from the
schema.

2.4. Default and Allowed Value Lists

The printer service SLP template describes grammar provides the attributes
supported capability to define
default and allowed values for an attribute. The SLP protocol
does not enforce these restrictions on registered attributes,
however. The default and allowed values may be used by network printing devices. Devices client
side applications, or alternatively it may also be
either directly connected used by DAs to a network, or connected
initialize registrations having no attributes and to a
printer spooler that understands the a network queuing
protocol such as IPP, lpr or the Salutation Architecture.

url-syntax =
The URL syntax is specific limit attribute
values to the printing protocol being
employed

description = template allowed values.

LDAP servers also do not support default and allowed values on
attributes. Therefore, enforcement of default and allowed values
in SLP templates is left up to the clients or a DA, if the DA
is backending into LDAP. The default and allowed values should
be included in the DESC field. The comments should be placed on
separate lines and labelled with the ``Default:'' and ``Allowed:''
tags to allow reconstruction of the tempalte.

2.5. Descriptive Text

The descriptive text associated with an attribute definition should
be included in the DESC field. It should start on a separate line
and begin with the ``Description:'' tag.

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 9]

Internet Draft Schemas and Templates 20 June 1999

2.6. Example

The template included below is a hypothetical abstract printer
service template, similar to that described in [10].

template-type = printer

template-version = 0.0

template-description =
The printer service template describes the attributes
supported by network printing devices. Devices may be
either directly connected to a network, or connected to a
printer spooler that understands the a network queuing
protocol such as IPP, lpr or the Salutation Architecture.

template-url-syntax =
;The URL syntax is specific to the printing protocol being
;employed

description = STRING
# This attribute is a free form string that can contain any
# site-specific descriptive information about this printer.

security-mechanisms-supported = STRING L M
none
# This attribute indicates the security mechanisms supported
tls, ssl, http-basic, http-digest, none

operator = STRING O L M
# A person, or persons responsible for maintaining a
# printer on a day-to-day basis, including such tasks
# as filling empty media trays, emptying full output
# trays, replacing toner cartridges, clearing simple
# paper jams, etc.

location-address = STRING O
# Physical/Postal address for this device. Useful for
# nailing down a group of printers in a very large corporate
# network. For example: 960 Main Street, San Jose, CA 95130

priority-queue = BOOLEAN O
FALSE
# TRUE indicates this printer or print queue is a priority
# queuing device.

number-up = INTEGER O
1

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 10]

Internet Draft Schemas and Templates 20 June 1999

# This job attribute specifies the number of source
# page-images to impose upon a single side of an instance
# of a selected medium.
1, 2, 4

paper-output = STRING M L O
standard
# This attribute describes the mode in which pages output

St.Pierre Expires 1 December 1998 [Page 7]

Internet Draft Schemas and Templates 1 June 1998
# are arranged.
standard, noncollated sort, collated sort, stack, unknown

5.12. Translated Schema

This translated schema uses

The LDAP class definition for the template attributes primarily printer abstract service type is
translated as
comments in the beginning of the schema definition. Since all
Objects must support a cannonical name (cn), follows (note: we use the URL as
the value for an object cn. This maps well, as a cn identifies a
particular object attribute names instead of oids
in MUST and a URL identifies a particular resource.

-- MAY for clarity):

( 42.42.42.42.1
NAME 'printer'
DESC `Description: The printer service template describes the
attributes
-- supported by network printing devices. Devices
may be either
-- directly connected to a network, or connected
to a printer
-- spooler that understands the a network queuing
protocol such as
-- IPP, lpr or the Salutation Architecture.
printer OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
dn,
url,
description,
security-mechanisms-supported
}
MAY CONTAIN {
operator,
location-address,
priority-queue,
number-up,
paper-output
}

dn OBJECT-TYPE
SYNTAX Distinguished Name
DESCRIPTION
"The DN of the printer being described"

url OBJECT-TYPE
SYNTAX Case Ignore String
DESCRIPTION
"The

URL of Syntax: ;The URL syntax is specific to the printer printing
protocol being described" employed.'

SUP 'top'
ABSTRACT
SUP 'service'
MUST ( description OBJECT-TYPE
SYNTAX Case Ignore String
DESCRIPTION
"This \$ security-mechanisms-supported \$
labelledURI)
MAY ( operator \$ location-address \$ priority-queue \$
number-up \$ paper-output)
)

The attribute definitions are translated as follows:

( 42.42.42.42.4
NAME 'description'
DESC 'Description: This attribute is a free form string
that can contain
Any any site-specific descriptive
information about this the printer.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringMatch
SYNTAX 'Directory String'
SINGLE-VALUE

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 8] 11]

Internet Draft Schemas and Templates 1 20 June 1998

printer."

security-mechanisms-supported OBJECT-TYPE
SYNTAX Case Ignore String
DESCRIPTION
"This 1999

)

( 42.42.42.42.5
NAME 'security-mechanisms-supported'
DESC 'Description: This attribute indicates the security mechanisms
supported. These values are:
tls
ssl
http-basic
http-digest
none"

operator OBJECT-TYPE

Default: value

Allowed: tls, ssl, http-basic, http-digest, none

Literal:'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringMatch
SYNTAX SET OF Case Ignore String
DESCRIPTION
"A 'Directory String'
)

( 42.42.42.42.6
NAME 'operator'
DESC 'Description: A person, or persons responsible for
maintaining a printer on a day-to-day basis, including
such tasks as filling empty media trays, emptying full
output trays, replacing toner cartridges, clearing simple
paper jams, etc."

location-address OBJECT-TYPE etc.

Literal:'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringMatch
SYNTAX Case Ignore String
DESCRIPTION
"Physical/Postal 'Directory String'
)

( 42.42.42.42.7
NAME 'location-address'
DESC 'Description Physical/Postal address for this device.
Useful for nailing down a group of printers in a very
large corporate network. For example: 960 Main Street,
San Jose, CA 95130"

priority-queue OBJECT-TYPE 95130.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringMatch
SYNTAX Case Ignore String
DESCRIPTION
"TRUE 'Directory String'
SINGLE-VALUE
)

( 42.42.42.42.8
NAME 'priority-queue'
DESC 'Description: TRUE indicates this printer or print

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 12]

Internet Draft Schemas and Templates 20 June 1999

queue is a priority queuing device."

number-up OBJECT-TYPE device.'
EQUALITY caseIgnoreMatch
SYNTAX INTEGER
DESCRIPTION
"This 'Boolean'
SINGLE-VALUE
)

( 42.42.42.42.9
NAME 'number-up'
DESC 'Description: This job attribute specifies the number
of source page-images to impose upon a single side of
an instance of a selected medium."

paper-output OBJECT-TYPE medium. This attribute is
an ASN.1 Integer.

Default: 1

Allowed: 1, 2, 3, 4'
SYNTAX Case Ignore String
DESCRIPTION
"This 'Binary'
SINGLE-VALUE
)

( 42.42.42.42.10
NAME 'paper-output'
DESC 'Description: This attribute describes the mode in
which pages output are arranged. Default value is
standard.

Default: standard

Allowed: standard, noncollated sort, collated sort,
stack, unknown.
Literal:'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringMatch
SYNTAX 'Directory String'
)

3. Mapping from Schema to Templates

The reverse mapping from LDAP schema to SLP service type templates
requires dealing with both LDAP and ASN.1 data types. RFC 2252
defines 57 LDAP attribute data types that should be supported by LDAP
directory servers. These values are: data type are defined on top of the ASN.1
typing system used by X.500, but directory servers are also required
to support standard X.500 ASN.1 data types using the LDAP Binary type
escape.

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 9] 13]

Internet Draft Schemas and Templates 1 20 June 1998

noncollated sort
collated sort
stack
unknown"

6. 1999

Mapping from Schemas to Templates

ASN.1 employs a much richer set of the LDAP data types than provided by SLP.
The table below show the into SLP template types is fairly
straightforward, but mapping of selected arbitrary ASN.1 data types is somewhat
more complicated and requires encoding the ASN.1 data type into a
string. To a certain extent, this masks the ASN.1 data type because
it becomes impossible to their
nearest SLP equivalent. Because distinguish between a native string having
content equivalent to an encoded ASN.1 string. However, inclusion of
the complexity and flexibility of
ASN.1, ASN.1 data type in the comment provides additional information
should a complete list cannot be provided.

As sample of some reverse transformation from SLP to ASN.1 encodings be required.

The following subsections deal with both LDAP and their mappings to SLP: ASN.1 attribute
data type mappings.

3.1. Mapping LDAP Attribute Types to SLP type
---------------------------------------
Integer Integer
Case Exact String String
Case Ignore Attribute Types

The following table contains the mappings for LDAP data types to SLP
data types:

LDAP Type SLP Type
--------------------------------------------------------
ACI Item NA
Access Point NA
Attribute Type Description NA
Audio Opaque
Binary ASN.1 escape
Bit String String
Boolean Boolean
Octet String
Certificate Opaque
Binary
Certificate List Opaque
Enumeration
Certificate Pair Opaque
Country String
Set Of 'M' flag
Real String
Object Identifier
DN String
Sequence Of Multiple Attributes

6.1.
Data Type Mappings

ASN.1 supports a much larger range of values. As such, a subset
will be selected for mapping SLP values. ASN.1 uses BER encoding as
described in CCITT Recommendation X.209[2]. BER encodings are based
on tuples containing a Type, Length and Contents.

6.2. Integer

Both SLP templates and ASN.1 support Integers, so there is a one to
one mapping between an SLP Integer attribute and an ASN.1 Integer
attribute. Details on the encoding of integers is summarized in the
SLP template to ASN.1 section above, as well as being explained in
detail in RFC2165[3] and the X.209[2] specification. Quality Syntax NA
Delivery Method NA
Directory String String
DIT Content Rule Description NA
DIT Structure Rule Description NA
DL Submit Permission NA
DSA Quality Synax NA
Enhanced Guide NA
Facsimile Telephone Number String
Fax Opaque
Generalized Time String
Guide NA
IA5 String String
INTEGER String
JPEG Opaque
LDAP Syntax Description NA

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 10] 14]

Internet Draft Schemas and Templates 1 20 June 1998

6.3. Case Ignore String, Case Exact 1999

LDAP Schema Definition NA
LDAP Schema Description NA
Master and Shadow Access Points NA
Matching Rule Description NA
Matching Rule Use Description NA
Mail Preference NA
MHS OR Address String

Strings are supported between both SLP
Modify Rights NA
Name and ASN.1. SLP encoding
of the strings must conform to the rules for handling special
characters, as outlined in RFC 2165 [3].

6.4. Boolean

Boolean values are supported by both SLP and ASN.1, though on wire
encodings will vary. X.209[2] specifies zero and non-zero encoding
for booleans, where SLP encodes booleans using the strings TRUE and
FALSE.

6.5. Optional UID NA
Name Form Description NA
Numeric String String
Object Class Description NA
Octet String

An ASN.1 octet string should be mapped to an Opaque in an
OID String
Other Mailbox String
Postal Address String
Protocol Information NA
Presentation Address String
Printable String String
Subset Assertion NA
Subtree Specification NA
Supplier Information NA
Supplier or Consumer NA
Supplier And Consumer NA
Supported Algorithm NA
Telephone Number String
Teletex Terminal Identifier String
Telex Number String
UTC Time String

If the SLP
template. An octet string is a sequence of bytes, whereas an Opaque type is a sequence of bytes that has been encoded using radix64.

6.6. Binary

An ASN.1 Binary should be mapped to an Opaque NA in an SLP template. A
binary value is a sequence of bytes, whereas an Opaque is a sequence
of bytes that has been encoded using radix64.

6.7. Enumeration

SLP templates support the concept of enumerations through above table, the listing
of values LDAP type is involved
in the attribute definition. This schema representation or some other internal function, or is similar
otherwise unlikely to appear in the ASN.1 schema definition of enumerations, though encodings vary. In for a service
type.

Note that there is no LDAP type that maps into SLP enumerated
values are passed between client Integer. The
LDAP INTEGER and server Numeric String types map into SLP Strings. The
reason is that, as strings. BER encodes
the ASN.1 enumeration by passing the number discussed in 2, neither LDAP type supports
integer ordering. In addition, since most of the elements position
in LDAP types map into
the enumeration. This SLP String type, the reverse mapping requires both sides to have knowledge either that the
formatted string is recognized as being of the specific enumeration prior to decoding an enumerations value.
Example:

color-supported = STRING M
none
# This attribute specifies whether appropriate LDAP type
or the Printer supports
# color and, if so, what type.
none, highlight, three color, four color, monochromatic

In this example, 'none' would have a value of 1, 'highlight' would be
2, 'three color' would be 3, etc. translation records the exact LDAP type in the SLP attribute
description comment.

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 11] 15]

Internet Draft Schemas and Templates 1 20 June 1998

6.8. Rules for Other 1999

3.2. Mapping ASN.1 Primitive Types

It is not reasonable to think that all SLP Types

ASN.1 employs a much richer set of data types can be
accurately represented using than provided by SLP.
The table below show the very basic mapping of selected ASN.1 data types defined in
ASN.1. type to their
nearest SLP equivalent. Because of the complexity and flexibility of
ASN.1, a complete list cannot be provided.

As such, data sample of some ASN.1 encodings and their mappings to SLP:

ASN.1 type SLP type
-----------------------------------------
Integer Integer
Case Exact String String
Case Ignore String String
Boolean Boolean
Octet String Opaque
Binary Opaque
Enumeration String
Set Of Formatted String
Real String
Object Identifier String
Sequence Of Formatted String

Data types that do not map directly to SLP data types should be
defined as either a String, or as Opaque. ASN.1 types that may only
contain valid characters for Strings, as defined in X.209[2] X.680 [9] should
be encoded as strings. If a value may contain illegal string values,
the SLP Opaque type should be used. In either case, the first line
of the help text is used to indicate the original ASN.1 data type.

6.9. Set Of

Sets can be accommodated in an

The following subsections describe how to convert from the ASN.1
BER [9] to the SLP template by specifying for the
attribute is multivalued. The flag 'M' different types in the table
above.

3.2.1. Integer

Both SLP templates and ASN.1 support Integers, so there is used a one to indicate
one mapping between an SLP Integer attribute Can have multiple values. All values must be of and an ASN.1 Integer
attribute. Details on the same
type. As such, a multivalued attribute encoding of type string could have
values integers is summarized in the
SLP template to ASN.1 section above.

3.2.2. Case Ignore String, Case Exact String

Strings are supported between both SLP and ASN.1. SLP encoding
of "one, 2, three", but the value 2 would be returned as
a string, not an integer. Likewise, a multivalued integer could
not have a value of "1, 2, three", as all values would need to be
converted strings must conform to strings, which are illegal the rules for an attribute of type
integer.

6.10. Real

There is no direct mapping between floating point numbers handling special

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 16]

Internet Draft Schemas and any
SLP data types. As such, attributes are defined Templates 20 June 1999

characters, as outlined in RFC XXX [4]. Note that, unless the ASN.1
type String.
Comments are added to is recorded into the attribute help text indicating comment, the reverse translation will lose
the value
was originally an ASN.1 real. For example:

weight = STRING
# ASN.1: Real
# The objects weight in pounds.

6.11. Object Identifier

Object identifiers(OIDs) type.

3.2.3. Boolean

Boolean values are commonly used supported by both SLP and ASN.1, though on wire
encodings differ. X.680 [9] specifies zero and non-zero encoding
for booleans, where SLP encodes booleans using the strings TRUE and
FALSE. In general, most LDAP servers will use the LDAP Boolean type
(which is a string), so again the ASN.1 type should be recorded in
the comment or it will be lost.

3.2.4. Octet String

An ASN.1 world octet string should be mapped to
identify object and attributes. OIDs are a numerical representation
of an elements place Opaque in the naming hierarchy. Each element at an SLP
template. An octet string is a
particular level sequence of bytes, whereas an Opaque
is a hierarchy has a unique number assigned within string that level encodes a sequence of bytes. Again, the hierarchy. A sample OID would be ASN.1
type is lost unless recorded in the naming tree
for SNMP MIBs.

St.Pierre Expires 1 December 1998 [Page 12]

Internet Draft Schemas and Templates 1 June 1998

iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would comment.

3.2.5. Binary

An ASN.1 Binary should be written as
the string 1.3.6.1.2.1

Because this representation reduces down mapped to an Opaque in an SLP template. A
binary value is a sequence of bytes, whereas an Opaque is a a string
that encodes a sequence of dot separated
numbers, this maps easily to bytes. Again, the SLP String type. The help text for
this element should indicate it is an ASN.1 OID

identifier = STRING
# ASN.1: OID
# The object identifier for this SNMP agent.

6.12. Sequence Of

The ASN.1 construct 'Sequence Of' type is probably lost
unless recorded in the least intuitive to
map to an SLP template. comment.

3.2.6. Enumeration

SLP attributes can only contain values templates support the concept of
like type. By definition, this is an ASN.1 SET OF. ASN.1 sequences
are made enumerations through the listing
of multiple allowed values of different types. For example, an in the attribute named 'Engine' may be defined as:

engine OBJECT-TYPE
SYNTAX SEQUENCE OF {
name DisplayString,
status INTEGER {
unknown(1)
running(2)
shutdown(3)
}
}
DESCRIPTION
"Engine description."

In order definition. These enumerations
are not strictly binding on clients or DAs, but they are similar
to map this the ASN.1 definition of enumerations. BER encodes the ASN.1
enumeration by passing the number of the element's position in the
enumeration. This requires both sides to have knowledge of the
specific enumeration prior to decoding an enumeration's value. SLP template, we can create multiple
attributes and rely
provides no specific support for transmitting enumerations. They are
simply String types. Information on the ordering for association. The above
translates as:

engine-name = STRING M
# The name of one ASN.1 type and ASN. encoding
of this craft's engines.

engine-status the enumeration values is recorded in the comment.

Example:

color-supported = STRING M
unknown
# The state of this crafts engines.
unknown, running, shutdown
none

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 13] 17]

Internet Draft Schemas and Templates 1 20 June 1998

To do this, we are relying on an assumption stated in the service:
Scheme Draft [1] that all values of a multivalued attribute retain
their order. When new values are added, they are added to the end of
the list of values.

As such, if we had:
engine-name 1999

# ASN.1: Enumeration.
# ASN.1 Mapping: none = right, left
engine-status 0, highlight = running, shutdown

We would assume that the engine named right is running and 1, three color = 2, four color = 4,
# monochrmatic = 5
#This attribute specifies whether the engine
named left is shutdown.

6.13. Schema to be Translated

In general, Printer supports
# color and, if so, what type.
none,highlight,three color,four color,monochromatic

3.2.7. Set

ASN.1 provides Sets can be accommodated in an SLP template by simply
concatenating the set elements into a much more general string, separated by
whitespace. Searches for individual set of data types than
provided elements in SLP can use the
LDAP wildcard syntax. For example, given a translated Set attribute
with value ``one two three'', a search can be made for attributes
with set value ``two'' by SLP. For this reason, it is more complex to convert using the LDAP schemas to templates for SLP.

The following schema represents an example wildcard ``*two*''.

Problems arise if the set contains as one or more of its
elements a schema for an
exported filesystem. The section presents it as in ASN.1 data item that is, itself, a set. Without some
delimiter, the elements of both sets would run together and become
indistinguishable. To avoid this problem, we use curly braces ``{}''
to delimit a set. Thus the
following section shows set in the SLP template translation.

-- abstraction above example becomes ``{ one
two three }''.

Since sets have no implicit ordering, the ordering of a fstab entry (a "mount")
-- these lookups would likely be performed by an
-- an automounter type application
mount OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
-- the mount host
mountHost,
-- values in
the mount point
mountDirectory.
-- string is unimportant. Note that sets cannot be represented as
multivalued attributes because it is possible that an LDAP attribute
having the mount ASN.1 Set type may additionally be multivalued. The
template's help text should indicate the original ASN.1 type
mountType
}
MAY CONTAIN {
-- mount options
mountOption,
-- dump frequency
mountDumpFrequency,
-- passno
mountPassNo
}

St.Pierre Expires 1 December 1998 [Page 14]

Internet Draft Schemas and Templates 1 June 1998

mountHost OBJECT-TYPE
SYNTAX Case Ignore String
DESCRIPTION
"The mount host"

mountDirectory
SYNTAX Case Ignore String
DESCRIPTION
"The filesystem to mount"

mountType OBJECT-TYPE
SYNTAX INTEGER {
ufs(1)
hsfs(2)
nfs(3)
rfs(4)
}
DESCRIPTION
"The
facilitate backwards conversion.

3.2.8. Real

There is no direct mapping between floating point numbers and any
SLP data types. Attributes having the ASN.1 type of the filesystem being mounted"

mountOption OBJECT-TYPE
SYNTAX SET OF Case Ignore String
DESCRIPTION
"mount options for this filesystem"

mountDumpFrequency OBJECT-TYPE
SYNTAX INTEGER (0..9)
DESCRIPTION
"How often Real are mapped
to dump this filesystem"

mountPassNo OBJECT-TYPE
SYNTAX Integer
DESCRIPTION
"Boot time mount pass number"

6.14. SLP Translation type String. Comments are added to the attribute help text
indicating the value was originally an ASN.1 real. For example:

weight = mount
version = 1.0

language = en

description = "This would describe a remote filesystem
access protocol"

url-syntax = STRING
# ASN.1: Real
# The objects weight in pounds.

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 15] 18]

Internet Draft Schemas and Templates 1 20 June 1998

filesystem = 1*[ DIGIT / ALPHA ]
urlpath = "/" filesystem

mountHost = STRING L
# The mount host

mountDirectory = STRING L
# The filesystem 1999

3.2.9. Object Identifier

Object identifiers(OIDs) are commonly used in the ASN.1 world to mount

mountType = STRING L
ufs
# The type
identify object and attributes. OIDs are a numerical representation
of an element's place in the filesystem being mounted
ufs, hsfs, nfs, rfs

mountOption = STRING M O L
# mount options naming hierarchy. Each element at a
particular level of a hierarchy has a unique number assigned within
that level of the hierarchy. A sample OID would be the naming tree
for SNMP MIBs: iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would
be written as the string ``1.3.6.1.2.1''.

Because this filesystem

mountDumpFrequency = INTEGER O
0
# How often representation reduces down to dump a string of dot separated
numbers, this filesystem
0, 1, 2, 3, 4, 5, 6, 7, 8, 9

mountPassNo maps easily to the SLP String type. The help text for
this element should indicate it is an ASN.1 OID

identifier = INTEGER O STRING
# Boot time mount pass number

7. Notes on Matching Operators ASN.1: OID
# The object identifier for this SNMP agent.

3.2.10. Sequence

The ASN.1 Sequence type is handled exactly like the Set type. The
sequence elements are converted to strings and inserted into a string
with whitespace separators. Sequences are delimited with angle
brackets ``<>''. An example encoded sequence is ``< one two three
>''. Unlike sets, the ordering of items in a sequence is important
and should be respected by client software. The SLP template grammar does not describe
attribute help text should indicate that the matching properties of
attributes, but attribute was translated
from an ASN.1 does. If choosing to add matching properties
to sequence.

3.3. Example ASN.1 Schema

The following is an SLP template when converting it to example schema for an exported filesystem. The
section presents it as in ASN.1 based schema, and the following rules should section shows the
SLP template translation. Note that the template translation does
not capture the actual attribute format for the Set type, that would
be kept done in mind. the LDAP client software making the translatin.

-- abstraction of a fstab entry (a "mount")
-- these lookups would likely be performed by an
-- an automounter type application
mount OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
-- the mount host
mountHost,

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 19]

Internet Draft Schemas and Templates 20 June 1999

-- the mount point
mountDirectory.
-- the mount type
mountType
}
MAY CONTAIN {
-- mount options
mountOption,
-- dump frequency
mountDumpFrequency,
-- passno
mountPassNo
}

mountHost OBJECT-TYPE
SYNTAX Case Ignore String
DESCRIPTION
"The mount host"

mountDirectory OBJECT-TYPE
SYNTAX Case Ignore String
DESCRIPTION
"The filesystem to mount"

mountType OBJECT-TYPE
SYNTAX INTEGER {
ufs(1)
hsfs(2)
nfs(3)
rfs(4)
}
DESCRIPTION
"The type of the filesystem being mounted"

mountOption OBJECT-TYPE
SYNTAX SET OF Case Ignore String
DESCRIPTION
"mount options for this filesystem"

mountDumpFrequency OBJECT-TYPE
SYNTAX INTEGER (0..9)
DESCRIPTION
"How often to dump this filesystem"

mountPassNo OBJECT-TYPE
SYNTAX Integer
DESCRIPTION
"Boot time mount pass number"

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 20]

Internet Draft Schemas and Templates 20 June 1999

The translated SLP template is:

template-type = mount

template-version = 1.0

template-description = "Describes a remote filesystem access protocol"

template-url-syntax =
filesystem = 1*[ DIGIT / ALPHA ]
urlpath = "/" filesystem

mountHost = STRING L
# ASN.1: Case Ignore String
# The mount host

mountDirectory = STRING L
# ASN.1: Case Ignore String
# The filesystem to mount

mountType = STRING L
ufs
# ASN.1: Enumeration
# ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4
# The type of the filesystem being mounted
ufs, hsfs, nfs, rfs

mountOption = STRING M O L
# ASN.1: Set of Case Ignore String
# mount options for this filesystem

mountDumpFrequency = INTEGER O
0
# ASN.1: Integer Range
# How often to dump this filesystem
0, 1, 2, 3, 4, 5, 6, 7, 8, 9

mountPassNo = INTEGER O
# ASN.1: Integer
# Boot time mount pass number

4. Representing SLP Service Advertisments in an LDAP DIT

In addition to translating between SLP templates and LDAP schema,
another area requiring compatibility is the representation
of SLP service advertisements in an LDAP DIT. A standardized

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 21]

Internet Draft Schemas and Templates 20 June 1999

representation for service information allows SLP DAs to store
service advertisements in LDAP, and for LDAP clients to query
the DIT for those services. Similarly, if LDAP clients represent
service information in the same form, SLP clients can benefit from
interoperability.

In addition, a service advertisement contains the service URL in a
'labelledURI' attribute [11]. The labelledURI attribute in a service
advertisement should only contain the service URL for the service,
with no additional label.It is recommended that the labelledURI be
used as the RDN for the service object in the DIT.

Although service advertisements can appear anywhere within the
DIT, it is recommended that all services be stored under a single
common point to facilitates searching. This allows a client to
search for all of advertisements of a particular service type, say,
for all printers. The recommended storage point is a container
node named "oc=service" under the root node for the local LDAP
server. For example, a printer service with labelledURI of
"service:lpr://printsr/queue1" advertised in the LDAP server that
holds the root for the "dc=foobar, dc=com" tree would have the
following DN:

"labelledURI=service:lpr://printsr/queue1, oc=service, dc=foobar, dc=com"

While this leads to a flat space of service storage, since SLP uses
search filters from LDAP for searches, these filters can be used for
one-level searches from the root node.

A few examples should clarify. The following example illustrates how
an advertisement having a simple service type is represented. The
advertisment for a printer is:

Service URL: service:lpr://printsrv/queue1
Scopes: eng, corp
Attributes: description = A general printer for all to use.
security-mechanisms-supported = none
No Authentication

The RDN of the object is labelledURI=service:lpr://printsrv/queue1,
and the following LDAP search filter will return this object, along
with any others of the service type 'lpr' that match the other
attributes:

(&(service-type=lpr)(scopes=eng, corp)
(description=A general printer for all to use)

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 22]

Internet Draft Schemas and Templates 20 June 1999

(security-mechanisms-supported=none))

Service advertisements in SLP also have a lease time associated
with them. In LDAP servers that support the extensions for dynamic
directory services [12], the service advertisement entry objectClass
should be extended with the dynamicObject class. This allows the
service advertisment to time out within the LDAP directory server.
If the LDAP directory server does not support the dynamic directory
services extension, then advertisement lease timeouts must be handled
by the SLP agent.

While the service advertisement schema outlined in this section
is primarily for SLP DAs that use LDAP as a backing store, if
LDAP agents register services using the same format, complete
interoperability with SLP is achieved.

5. Internationalization Considerations

SLP specifies that an RFC 1766 [13] language code accompanies every
service advertisement. Language codes for service advertisements in
LDAP must be represented according to RFC 2596 [14].

RFC 2596 prohibits language codes in DNs, and specifies that a
directory server which does not support language codes must treat an
attribute with a language code as an unrecognized attributes. If the
directory server does not support language codes, an SLP DA using
LDAP as a backing store should encode the language code in the label
of the 'labelledURI' attribute field.

For example, consider the service URL "service:lpr://printserv/queue1"
registered in the "fr" (French) locale. The 'labelledURI' attribute
in an LDAP directory service that doesn't support language codes is:

labelledURI=service:lpr://printserv/queue1 fr

6. Security Considerations

SLP authenticators are stored with the service advertisement in
the DIT, as discussed in Section 4. LDAP clients need to use LDAP and SLP support the same matching operations, though using
slightly different matching semantics. In addition
authentication [15] to greaterOrEqual
and lessOrEqual, SLP provides for assure that they are connecting with a simple less or greater match.

LDAP Search Operators secure
server. In particular, SLP Search Operators DAs that use LDAP as a back end store
and (&) &
or (|) |
not (!) !=
equalityMatch (=) ==
substrings
greaterOrEqual (>=) >=
lessOrEqual (<=) <=
present (=*) <keyword> that implement SLP authentication MUST use LDAP authentication
to assure that the LDAP entries for their service registrations are
secure.

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 16] 23]

Internet Draft Schemas and Templates 1 20 June 1998

ASN.1 provides for three varieties of substring value matching,
namely initial, any, and final. In specifying the match capability
of an attribute, ASN.1 specifies that a value may match the leading
part, any part, or the final part of a string value. Using the SLP
search semantics, this is accomplished through the substring (*)
operator. Searching for initial, any or final is handled through
specific placement of the operator. The following example, taken
from RFC2165 illustrates this:

initial: "bob*" matches "bob", "bobcat", and "bob and sue"
final: "*bob" matches "bob", "bigbob", and "sue and bob"
any: "*bob*" matches "bob", "bobcat", "bigbob",
and "a bob I know"

8. Acknowledgments

Thanks to Jonathan Wood 1999

References

[1] S. Bradner. Key Words for the suggestion to use MD5 hashes Use in RFCs to avoid
character escape problems between URLs and DNs.

A. References

[1]E. Indicate Requirement
Levels. RFC 2119, March 1997.

[2] E. Guttman, C. Perkins, J. Kempf "Service Kempf. Service Templates and service:
Schemes", Work in Progress, March, 1987
draft-ietf-svrloc-service-scheme-09.txt

[2]W. Yeong,
service:Schemes. RFC XXX, April, 1999.

[3] M. Wahl, T. Howes, and S. Kille, "Lightweight Kille. Lightweight Directory Access
Protocol", RFC1777. 03/28/1995.

[3]J. Veizades,
Protocol (v3). RFC 2251, December, 1997.

[4] E. Guttman, C. Perkins, J. Veizades, and S. Kaplan. "Service M. Day. Service
Location Protocol", Protocol version 2. RFC 2165. June XXX, April 1999.

[5] D. Crocker and P Overell. Augmented BNF for Syntax
Specifications: ABNF. RFC 2234 November 1997.

[4]CCITT Recommendation X.209, "Specification

[6] ITU-T Rec. X.500. The Directory: Overview of Concepts, Models,
and Service. 1993.

[7] T. Howes. The String Representation of Basic Encoding
Rules for LDAP Search Filters.
RFC 2254, December 1997.

[8] M. Wahl, A. Coulbeck, T. Howe, and S. Kille. Lightweight
Directory Access Protocol (v3): Attribute Syntax Definition.
RFC 2252, December, 1997.

[9] ITU-T Rec. X.680. Abstract Syntax Notation One (ASN.1), 1988

[5]P. (ASN.1) -
Specification of Basic Notation. 1994.

[10] P. St. Pierre, "Definition S. Isaccson, I. McDonald. Definition
of printer: URLs for use with Service
Location", Location
draft-ietf-svrloc-printer-scheme-03.txt Work in Progress, March, 1998
draft-ietf-svrloc-printer-scheme-02.txt

[6]Rivest, R., "The MD5 Message-Digest Algorithm", Progress

[11] M. Smith. Definition of an X.500 Attribute Type and an Object
Class to Hold Uniform Resource Identifiers (URIs). RFC 2079,
January, 1997.

[12] Y. Yaacovi, M. Wahl, and T. Genovese. Lightweight Directory
Access Protocol (v3): Extensions for Dynamic Directory
Services. RFC 1321, MIT
Laboratory 2589, May, 1999.

[13] H. Alverstrand. Tags for Computer Science the Identification of Lanaguages. RFC
2252, December, 1997.

[14] M. Wahl and RSA Data Security, Inc., T. Howes. Use of Language Codes in LDAP. RFC 2596,
May, 1999.

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 17] 24]

Internet Draft Schemas and Templates 1 20 June 1999

[15] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan.
Authentication Methods in LDAP. draft-ietf-ldapext-authmeth-xx.txt.
A work in progress.

Kempf, Moats, St.Pierre Expires 20 December 1999 [Page 25]

Internet Draft Schemas and Templates 20 June 1998 1999

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Authors' Address

Questions about this memo can be directed to:

James Kempf Ryan Moats
Sun Microsystems AT&T Laboratories
901 San Antonio Avenue 15621 Drexel Circle
Palo Alto, CA 94303 Omaha, NE, 68135
USA

Phone: +1 650 786-5890 +1 402 894-9456
Email: james.kempf@sun.com jayhawk@att.com

Pete St. Pierre
Sun Microsystems
901 San Antonio Avenue
Palo Alto, CA 94303
USA

Phone: +1 415 786-5790
email:
Email: Pete.StPierre@Eng.Sun.COM

Kempf, Moats, St.Pierre Expires 1 20 December 1998 1999 [Page 18] 26]
----