Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_q_t/draft-ietf-svrloc-template-conversion-00.txt

Text File | 1997-07-31 | 23KB | 674 lines

Service Location Working Group                          Pete St.  Pierre
INTERNET DRAFT                                          Sun Microsystems
                                                            31 July 1997

          Conversion of LDAP Schemas to and from SLP Templates
              draft-ietf-svrloc-template-conversion-00.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 [e-mail] mailing list.

   Distribution of this memo is unlimited.

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

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

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
   Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   LDAP and 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 formated 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.[1]












St.Pierre                Expires 31 January 1998                [Page i]

Internet Draft            Schemas and Templates             31 July 1997




                                Contents



Status of This Memo                                                    i

Abstract                                                               i

 1. Motivation                                                         1

 2. ASN.1 and BER Encodings                                            1

 3. Mapping from Templates to Schemas                                  2
     3.1. Data Type Mappings  . . . . . . . . . . . . . . . . . . .    2
     3.2. Integer . . . . . . . . . . . . . . . . . . . . . . . . .    2
     3.3. String  . . . . . . . . . . . . . . . . . . . . . . . . .    3
     3.4. Boolean . . . . . . . . . . . . . . . . . . . . . . . . .    3
     3.5. Opaque  . . . . . . . . . . . . . . . . . . . . . . . . .    3
     3.6. Enumerations  . . . . . . . . . . . . . . . . . . . . . .    4
     3.7. Multi-valued Attributes . . . . . . . . . . . . . . . . .    4
     3.8. Optional Attributes . . . . . . . . . . . . . . . . . . .    4
     3.9. Literal Attributes  . . . . . . . . . . . . . . . . . . .    5
    3.10. Explicit Matching . . . . . . . . . . . . . . . . . . . .    5
    3.11. Sample Translation  . . . . . . . . . . . . . . . . . . .    5

 4. Mapping from Schemas to Templates                                  5
     4.1. Data Conversions  . . . . . . . . . . . . . . . . . . . .    6
     4.2. Integer . . . . . . . . . . . . . . . . . . . . . . . . .    6
     4.3. Strings . . . . . . . . . . . . . . . . . . . . . . . . .    6
     4.4. Boolean . . . . . . . . . . . . . . . . . . . . . . . . .    6
     4.5. Octet String  . . . . . . . . . . . . . . . . . . . . . .    6
     4.6. Enumeration . . . . . . . . . . . . . . . . . . . . . . .    6
     4.7. Rules for Other ASN.1 Primitive Types . . . . . . . . . .    7
     4.8. Set Of  . . . . . . . . . . . . . . . . . . . . . . . . .    7
     4.9. Real  . . . . . . . . . . . . . . . . . . . . . . . . . .    7
    4.10. bitstring . . . . . . . . . . . . . . . . . . . . . . . .    8
    4.11. Object Identifier . . . . . . . . . . . . . . . . . . . .    8
    4.12. Sequence Of . . . . . . . . . . . . . . . . . . . . . . .    8
    4.13. Sample Translation  . . . . . . . . . . . . . . . . . . .    9

 5. Notes on Matching Operators                                        9

 6. References                                                        10






St.Pierre                Expires 31 January 1998                [Page 1]

Internet Draft            Schemas and Templates             31 July 1997


1. Motivation

   SLP templates 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 X.500 and LDAP. These directories
   server to store information about many types of entities.  Network
   services are one such entity.

   The ability to register services across both SLP and schema based
   directory services is a much needed capability.  In order to
   facilitate this, mappings must be created 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 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 encoding used by the
   LDAP directory schema.  Likewise, rules and guidelines will be
   propsed 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.  This
   document refers heavily to the X.209 specification for 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.

   Within the scope of Universal types, there are both primitive
   encodings and constructed encodings.  A primitive encoding a data
   value encoding in which the contents octets directly represent the
   value.  Constructed encodings are a data value encoding in which the




St.Pierre                Expires 31 January 1998                [Page 2]

Internet Draft            Schemas and Templates             31 July 1997


   contents 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.  All discussions of bit ordering assume
   bit 8 is the most significant bit.


3. Mapping from Templates to Schemas

3.1. Data Type Mappings

   SLP supports four data types.  Each of these data types can be mapped
   to 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.

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

   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.


     SLP Type     ASN.1 Type
     ---------------------------
     Integer      Integer
     String       String
     Boolean      Boolean
     Opaque       Octet String



3.2. Integer

   Both SLP templates and ASN.1 support Integers, therefore 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 repsonse packet.



St.Pierre                Expires 31 January 1998                [Page 3]

Internet Draft            Schemas and Templates             31 July 1997


   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 shall be primitive.  The
   contents 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.

   Also, The contents octets shall be a two's complement binary number
   equal to the integer value, and consisting of bits 8 to 1 of the
   first octet, followed by bits 8 to 1 of the second octet, followed by
   bits 8 to 1 of each octet in turn up to and including the last octet
   of the contents octets.


3.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.  As such, these strings are
   mapped to the ASN.1 caseIgnoreString syntax.


3.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.


3.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/length1/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.



St.Pierre                Expires 31 January 1998                [Page 4]

Internet Draft            Schemas and Templates             31 July 1997


3.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.  Because of this difference, SLP values that are
   encoded as ASN.1 enumerations must be sure the enumeration covers all
   possible values.


3.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.  As such, the ASN.1 syntax for SET OF. Use of ``SET
   OF'' assures all values will be of the same encoding type.


3.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''


3.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.


3.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



St.Pierre                Expires 31 January 1998                [Page 5]

Internet Draft            Schemas and Templates             31 July 1997


   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''.


3.11. Sample Translation

   TBD: Take SLP Template for a Service and convert to LDAP schema


4. 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 enco


    ASN.1 type      SLP type
    ---------------------------------------
    Integer         Integer
    Strings         String
    Boolean         Boolean
    Octet String    Opaque
    Enumeration     String
    Set Of          'M' flag
    Real            String
    Bit String      String
    Object IdentifierString
    Sequence Of     Multiple Attributes



4.1. Data Conversions

4.2. Integer

   Both SLP templates and ASN.1 support Integers, therefore 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.

   Details on the encoding is summarized in the SLP template to ASN.1
   section above, as well as being explained in detail in [3] and
   [X209].



St.Pierre                Expires 31 January 1998                [Page 6]

Internet Draft            Schemas and Templates             31 July 1997


4.3. Strings

   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 [3]


4.4. Boolean

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


4.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, where an Opaque is
   a sequence of bytes that has been encoded using radix64.


4.6. 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.

        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



4.7. Rules for Other ASN.1 Primitive Types

   It is 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 [3] should
   be encoded as strings.  If a value may contain illegal string values,



St.Pierre                Expires 31 January 1998                [Page 7]

Internet Draft            Schemas and Templates             31 July 1997


   the SLP Opaque type should be used.  In either case, the first line
   of the help text should indicate the original ASN.1 data type.


4.8. 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.


4.9. Real

   There is no direct mapping between floating point numbers and any SLP
   data types.  As such, attributes should be defined as type String.
   Comments can be 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.





4.10. bitstring

   While the wire encoding of strings and bitstrings is quite different,
   it is not unreasonable to represent a bitstring as a series of ones
   and zeros.  As such, the ASN.1 bitstring is mapped to the SLP String
   type, where all characters in the string are either ones or zeros.

        mask = STRING
            # ASN.1:  Bitstring# The mask used to convert this number.










St.Pierre                Expires 31 January 1998                [Page 8]

Internet Draft            Schemas and Templates             31 July 1997


4.11. Object Identifier

   Object identifiers are commonly used in the ASN.1 world to identify
   object and attributes.  Object ID's are a numerical representation of
   an elements place in the naming heirarchy.  Each element at the level
   of a heirarchy has a unique number assigned within that level of the
   heirarch.  A sample object ID 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 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.





4.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.  ASN.1 sequences
   are made of multiple values of different types.  For example, an
   attribute named 'Engine' may be defined as:
   SEQUENCE name String, status String

   In order to map this to an SLP template, we can create multiple
   attributes and rely on the ordering for association.  The above might
   translate as:

        engine-name = STRING M
            # The name of one of this crafts engines.


        engine-status = String M
            unknown
            # The name of one of this crafts engines.
            unknown, running, shutdown







St.Pierre                Expires 31 January 1998                [Page 9]

Internet Draft            Schemas and Templates             31 July 1997


   To do this, we are relying on an assumption stated in the service:
   Scheme Draft [SCHEME] 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.


4.13. Sample Translation

   In general, ASN.1 provides a much more robust set of data types than
   provided for by SLP. As such, the more difficult task of converting
   schemas from LDAP to templates for SLP.


5. Notes on Matching Operators

   While the SLP template grammar does not describe the matching
   properties of attributes, ASN.1 does.  If chosing 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 symantics.  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> approxMatch ( =) [TBD: Is
   there an equivalent?]

   ASN.1 provides for three flavors of substring value matching.  These
   are initial, any, and final.  In specifying the match capability of
   an attribute, ASN.1 allows specification that a value may match the
   leading part, any part, or the final part of a string value.  Using
   the SLP search sematics, 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:






St.Pierre               Expires 31 January 1998                [Page 10]

Internet Draft            Schemas and Templates             31 July 1997


   inital:  "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"


6. References


   [1]E. Guttman, C. Perkins, J. Kempf ``Service Templates and service:
   Schemes'', Work in Progress, July, 1997
   draft-ietf-svrloc-service-scheme-02.txt
   [2]CCITT Recommendation X.209, ``Specification of Basic Encoding
   Rules for Abstract Syntax Notation One (ASN.1), 1988

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




Authors' Addresses

   Questions about this memo can be directed to:

   Pete St. Pierre
   Sun Microsystems
   901 San Antonio Avenue
   Palo Alto, CA 94043
   USA
   Phone: [phone]
   email: [e-mail]




















St.Pierre               Expires 31 January 1998                [Page 11]