Service Location Working Group                          Pete St.  Pierre
INTERNET DRAFT                                          Sun Microsystems
                                                             1 June 1998

          Conversion of LDAP Schemas to and from SLP Templates
              draft-ietf-svrloc-template-conversion-03.txt


Status of This Memo

   This document is a submission by the Service Location Working Group
   of the Internet Engineering Task Force (IETF).  Comments should be
   submitted to the srvloc@corp.home.net mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To view the entire list of current Internet-Drafts, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   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) and Service Location
   Protocol (SLP) are both useful mechanisms for locating service
   related information on a network.  While they do perform similar
   functions, the way in which the information they provide is formatted
   is very different.  This document describes a set of rules and
   mappings for translating between the ASN.1 based LDAP schema and
   an SLP Template as described in the "Service Template and service:
   Scheme" draft.












St.Pierre                Expires 1 December 1998                [Page i]


Internet Draft             Schemas and Templates             1 June 1998




                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Motivation                                                         1

 2. ASN.1 and BER Encodings                                            1

 3. ASN.1 Types and LDAP                                               2

 4. URLs and Distinguished Names                                       3

 5. Mapping from SLP Templates to LDAP Schemas                         3
     5.1. Data Type Mappings  . . . . . . . . . . . . . . . . . . .    3
     5.2. Integer . . . . . . . . . . . . . . . . . . . . . . . . .    4
     5.3. String  . . . . . . . . . . . . . . . . . . . . . . . . .    4
     5.4. Boolean . . . . . . . . . . . . . . . . . . . . . . . . .    4
     5.5. Opaque  . . . . . . . . . . . . . . . . . . . . . . . . .    5
     5.6. Enumerations  . . . . . . . . . . . . . . . . . . . . . .    5
     5.7. Multi-valued Attributes . . . . . . . . . . . . . . . . .    6
     5.8. Optional Attributes . . . . . . . . . . . . . . . . . . .    6
     5.9. Literal Attributes  . . . . . . . . . . . . . . . . . . .    6
    5.10. Explicit Matching . . . . . . . . . . . . . . . . . . . .    6
    5.11. Template for Translation  . . . . . . . . . . . . . . . .    6
    5.12. Translated Schema . . . . . . . . . . . . . . . . . . . .    8

 6. Mapping from Schemas to Templates                                 10
     6.1. Data Type Mappings  . . . . . . . . . . . . . . . . . . .   10
     6.2. Integer . . . . . . . . . . . . . . . . . . . . . . . . .   10
     6.3. Case Ignore String, Case Exact String . . . . . . . . . .   11
     6.4. Boolean . . . . . . . . . . . . . . . . . . . . . . . . .   11
     6.5. Octet String  . . . . . . . . . . . . . . . . . . . . . .   11
     6.6. Binary  . . . . . . . . . . . . . . . . . . . . . . . . .   11
     6.7. Enumeration . . . . . . . . . . . . . . . . . . . . . . .   11
     6.8. Rules for Other ASN.1 Primitive Types . . . . . . . . . .   12
     6.9. Set Of  . . . . . . . . . . . . . . . . . . . . . . . . .   12
    6.10. Real  . . . . . . . . . . . . . . . . . . . . . . . . . .   12
    6.11. Object Identifier . . . . . . . . . . . . . . . . . . . .   12
    6.12. Sequence Of . . . . . . . . . . . . . . . . . . . . . . .   13
    6.13. 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


1. Motivation

   SLP templates[1] are intended to create a simple encoding of the
   syntactic and semantic conventions for individual service types,
   their attributes, and conventions.  This 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 schemas serve to formalize directory
   entry formulation for use with services like LDAP[2].  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] and schema based
   directory services is a useful capability.  In order to facilitate
   this, this document creates mappings between the SLP template grammar
   and the directory schemas.

   The simple notation and syntactic/semantic attribute capabilities
   of SLP will map well into directory schemas.  This means that
   service templates will easily be converted into directory schemas.
   The reverse is not true.  Only a certain restricted set of types,
   matching rules and encoding conventions used with LDAP will be
   directly mappable into service type templates.  There are rules
   to cover the cases where mapping cannot be done directly.  It is
   believed that the cases which are not supported are the exception
   rather than the rule.

   This document will outline the correct mappings for the four basic
   data types supported by SLP to the ASN.1/BER described in the
   X.209 specification[4].  This is the encoding used by the LDAP[2]
   directory schema.  Likewise, rules and guidelines will be proposed to
   facilitate consistent mapping of ASN.1 based schemas to be translated
   in the SLP template grammar.


2. ASN.1 and BER Encodings

   ASN.1 defined schemas are assumed to be encoded using the Basic
   Encoding Rules(BER) defined in CCITT Recommendation X.209[4].  The
   X.209[4] specification contains details 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 the scope 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 in which the
   content octets are the complete encoding of one or more other data
   values.  [2]

   This document will deal primarily with mapping ASN.1 primitive
   encodings to SLP data types.


3. ASN.1 Types and LDAP

   Because of the simplicity of SLP data types, any SLP data type
   can be represented in ASN.1.  This does not mean, however, that
   all LDAP servers may be able to handle all ASN.1 types we create.
   Specifically, most LDAP servers do not support ASN.1 enumerations.

   Also, not all LDAP servers are extensible.  While some LDAP servers
   may allow for the definition of new ASN.1 syntax definitions, there
   is a base set of types that are common among most LDAP servers.
   These 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.


     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 the limitations of many LDAP servers.  All SLP data types
   will be discussed in the context of the common LDAP data types listed
   above.  When coverting from an SLP template to an LDAP schema, these
   are the preferred data types for translation.  For completeness,
   alternate ASN.1 syntaxs are presented for each data type.  It should



St.Pierre                Expires 1 December 1998                [Page 2]


Internet Draft             Schemas and Templates             1 June 1998


   be noted that deployment of these types may not be supported by all
   LDAP implementations.


4. URLs and Distinguished Names

   SLP uses URLs to uniquely identify a 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 SLP Templates to LDAP Schemas

   The first step in mapping a template is to create a Distinguished
   Dame (DN) for the entry.  This DN is used to uniquely identify the
   record within the LDAP hierarchy.  We do this in two steps, using the
   service URL.

   The first step is to create an DN. Since URLs are likely to contain
   characters that are not allowed in a DN, we must find a way to
   remove them.  Also, the resulting DN must be unique across all peers
   in the LDAP name space.  In order to meet these criteria, we take
   the URL and perform an MD5 [6] hash to obtain a unique bit string
   that represents the URL. This bit string is then represented as hex
   digits, and used for the value of the DN.

   Secondly, we create an attribute called "url".  This attribute is
   of type Case Ignore String.  In this attribute, we store the actual
   service URL.

   For example, the URL service:printer:lpr://www.printserv.net/public
   would be stored in an LDAP directory with the following two
   attributes.  The value 6a1c0bfa0396f6be0bf73c4d1e8c45f1 is produced
   from the MD5 hash of the URL, so the attributes would look like:


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


5.1. Data Type Mappings

   SLP supports four data types.  Each of these data types can be mapped
   into a specific ASN.1 type.  In this way, translation of data types
   can be described easily.  All SLP data types are encoded as strings
   in the protocol.





St.Pierre                Expires 1 December 1998                [Page 3]


Internet Draft             Schemas and Templates             1 June 1998


   Complexity is added when the SLP data type is expressed as an
   enumeration.  This section describes the translation of each data
   type to its corresponding ASN.1 type.  A discussion of proper
   enumeration handling follows these mappings.


5.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.  On the wire encoding of these two is very different,
   though.

   In SLP, all 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 the request or response packet.

   The ASN.1 Integer type is encoded in BER according to the rules in
   section 8 of the X.209 specification.

   The encoding of an ASN.1 integer value is primitive.  The content
   octets shall consist of one or more octets.  The rules ensure that an
   integer value is always encoded in the smallest possible number of
   octets.


5.3. String

   SLP strings are encoded as described in section 20.5 of the SLP
   protocol specification [3].  All value strings are considered case
   insensitive for matching operations.  These strings are mapped to the
   ASN.1 DisplayString syntax.

   LDAP servers may or may not support the DisplayString syntax.  The
   preferred representation of an SLP String is Case Ignore String.


5.4. 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 type of boolean.  X.209
   specifies that the Contents field of a FALSE boolean value be encoded
   as a single octet with a value 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.



St.Pierre                Expires 1 December 1998                [Page 4]


Internet Draft             Schemas and Templates             1 June 1998


   Many LDAP servers do not support a data type of Boolean.  For this
   reason, it is recommended that the SLP boolean type be translated
   to a Case Ignore String.  The value stored in this string should be
   either "true" or "false".


5.5. Opaque

   SLP values that are encoded as Opaque are really 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 the ASN.1 Octet
   String.

   The <len> field of the SLP encoding will not match the <len> field of
   the BER encoding, as radix-64 encoding results in a 4 to 3 expansion
   of the original data.  Likewise, data presented in radix-64 notation
   must be converted back to the original byte stream to be encoded in
   the Contents field of the BER encoding.

   LDAP servers most commonly support the Binary data type instead
   of the more generic Octet String.  For compatibility across LDAP
   implementations, SLP Opaque values should be stored using the LDAP
   data type of Binary.  As with Octet Strings, the Binary type should
   store the original byte stream, not the radix-64 notation used within
   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 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. 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 ASN.1 definition.  All other attributes must be defined
   as a "Must"


5.9. Literal Attributes

   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. Explicit Matching

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


5.11. Template for Translation

   The template included below is derived from the printer service
   scheme described 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 and Templates             1 June 1998


        language = en

        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.

        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 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
            # 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 template attributes primarily as
   comments in the beginning of the schema definition.  Since all
   Objects must support a cannonical name (cn), we use the URL as
   the value for an object cn.  This maps well, as a cn identifies a
   particular object and a URL identifies a particular resource.

    -- 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 the printer being described"

    description OBJECT-TYPE
                  SYNTAX      Case Ignore String
                  DESCRIPTION
                       "This attribute is a free form string that can contain
                       Any site-specific descriptive information about this



St.Pierre                Expires 1 December 1998                [Page 8]


Internet Draft             Schemas and Templates             1 June 1998


                       printer."

    security-mechanisms-supported OBJECT-TYPE
                  SYNTAX      Case Ignore String
                  DESCRIPTION
                       "This attribute indicates the security mechanisms
                       supported.  These values are:
                       tls
                       ssl
                       http-basic
                       http-digest
                       none"

    operator OBJECT-TYPE
                  SYNTAX      SET OF Case Ignore String
                  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
                  SYNTAX      Case Ignore String
                  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
                  SYNTAX      Case Ignore String
                  DESCRIPTION
                       "TRUE indicates this printer or print queue is a priority
                       queuing device."

    number-up OBJECT-TYPE
                  SYNTAX      INTEGER
                  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
                  SYNTAX      Case Ignore String
                  DESCRIPTION
                       "This attribute describes the mode in which pages
                       output are arranged.  These values are:
                       standard



St.Pierre                Expires 1 December 1998                [Page 9]


Internet Draft             Schemas and Templates             1 June 1998


                       noncollated sort
                       collated sort
                       stack
                       unknown"



6. Mapping from Schemas to Templates

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

   As 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                   'M' flag
    Real                     String
    Object Identifier        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.




St.Pierre               Expires 1 December 1998                [Page 10]


Internet Draft             Schemas and Templates             1 June 1998


6.3. Case Ignore String, Case Exact String

   Strings are supported between both SLP 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. Octet String

   An ASN.1 octet string should be mapped to an Opaque in an SLP
   template.  An octet string is a sequence of bytes, whereas an Opaque
   is a sequence of bytes that has been encoded using radix64.


6.6. Binary

   An ASN.1 Binary should be mapped to an Opaque 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 the listing
   of values in the attribute definition.  This is similar to the ASN.1
   definition of enumerations, though encodings vary.  In SLP enumerated
   values are passed between client and server as strings.  BER encodes
   the ASN.1 enumeration by passing the number of the elements position
   in the enumeration.  This requires both sides to have knowledge of
   the specific enumeration prior to decoding an enumerations value.
   Example:

            color-supported = STRING M
                none
                # This attribute specifies whether 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.



St.Pierre               Expires 1 December 1998                [Page 11]


Internet Draft             Schemas and Templates             1 June 1998


6.8. Rules for Other ASN.1 Primitive Types

   It is not reasonable to think that all ASN.1 data types can be
   accurately represented using the very basic data types defined in
   ASN.1.  As such, 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] 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 SLP template by specifying the
   attribute is multivalued.  The flag 'M' is used to indicate an
   attribute Can have multiple values.  All values must be of the same
   type.  As such, a multivalued attribute of type string could have
   values 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 to strings, which are illegal for an attribute of type
   integer.


6.10. Real

   There is no direct mapping between floating point numbers and any
   SLP data types.  As such, attributes are defined as type String.
   Comments are added to the attribute help text indicating 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) are commonly used in the ASN.1 world to
   identify object and attributes.  OIDs are a numerical representation
   of an elements place in the 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.




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 be written as
   the string 1.3.6.1.2.1

   Because this representation reduces down to a string of dot separated
   numbers, this maps easily to 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' is probably the least intuitive to
   map to an SLP template.  SLP attributes can only contain values of
   like type.  By definition, this is an ASN.1 SET OF. ASN.1 sequences
   are made of multiple values of different types.  For example, an
   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 to map this to an SLP template, we can create multiple
   attributes and rely on the ordering for association.  The above
   translates as:

        engine-name = STRING M
            # The name of one of this craft's engines.


        engine-status = STRING M
            unknown
            # The state of this crafts engines.
            unknown, running, shutdown



St.Pierre               Expires 1 December 1998                [Page 13]


Internet Draft             Schemas and Templates             1 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 = right, left
   engine-status = running, shutdown


   We would assume that the engine named right is running and the engine
   named left is shutdown.


6.13. Schema to be Translated

   In general, ASN.1 provides a much more general set of data types than
   provided for by SLP. For this reason, it is more complex to convert
   LDAP schemas to templates for SLP.

   The following schema represents an example of a schema for an
   exported filesystem.  The section presents it as in ASN.1 and the
   following section shows the SLP template translation.

      -- 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,
                       -- the mount point
                       mountDirectory.
                       -- the mount 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 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"



6.14. SLP Translation

         type = mount
         version = 1.0

         language = en

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

         url-syntax =



St.Pierre               Expires 1 December 1998                [Page 15]


Internet Draft             Schemas and Templates             1 June 1998


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

         mountHost = STRING L
             # The mount host

         mountDirectory = STRING L
             # The filesystem to mount

         mountType = STRING L
             ufs
             # The type of the filesystem being mounted
             ufs, hsfs, nfs, rfs

         mountOption = STRING M O L
             # mount options for this filesystem

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

         mountPassNo = INTEGER O
             # Boot time mount pass number




7. Notes on Matching Operators

   The SLP template grammar does not describe the matching properties of
   attributes, but ASN.1 does.  If choosing to add matching properties
   to an SLP template when converting it to an ASN.1 based schema, the
   following rules should be kept in mind.

   LDAP and SLP support the same matching operations, though using
   slightly different matching semantics.  In addition to greaterOrEqual
   and lessOrEqual, SLP provides for a simple less or greater match.

      LDAP Search Operators        SLP Search Operators
         and (&)                            &
         or (|)                             |
         not (!)                            !=
         equalityMatch (=)                  ==
         substrings
         greaterOrEqual (>=)                >=
         lessOrEqual (<=)                   <=
         present (=*)                       <keyword>




St.Pierre               Expires 1 December 1998                [Page 16]


Internet Draft             Schemas and Templates             1 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 for the suggestion to use MD5 hashes to avoid
   character escape problems between URLs and DNs.


A. References


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

   [2]W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
   Protocol", RFC1777.  03/28/1995.

   [3]J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  "Service
   Location Protocol", RFC 2165.  June 1997.

   [4]CCITT Recommendation X.209, "Specification of Basic Encoding
   Rules for Abstract Syntax Notation One (ASN.1), 1988

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

   [6]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
   Laboratory for Computer Science and RSA Data Security, Inc.,









St.Pierre               Expires 1 December 1998                [Page 17]


Internet Draft             Schemas and Templates             1 June 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   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:

   Pete St. Pierre
   Sun Microsystems
   901 San Antonio Avenue
   Palo Alto, CA 94303
   USA
   Phone: +1 415 786-5790
   email: Pete.StPierre@Eng.Sun.COM












St.Pierre               Expires 1 December 1998                [Page 18]