Subject: RE: ASN.1 definitions in draft-ietf-ldapbis-syntaxes-01.txt

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 5 Mar 2002 12:21:19 +1100

I like this - except for the use of 'native', as I described elsewhere. To
recap, as every syntax requires an ASN.1 definition (for ;binary), the ASN.1
becomes the de facto native encoding. 'String' encoding is not perfect, but
native is counter-intuitive.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Saturday, 2 March 2002 6:44
To: Jim Sermersheim
Cc: [email-masked]
Subject: Re: ASN.1 definitions in draft-ietf-ldapbis-syntaxes-01.txt

At 11:15 AM 2002-03-01, Jim Sermersheim wrote:
>For any multipart syntax, could we include the ASN.1 definition, rather
>than including it in prose?
>I'm thinking of examples like Section 3.9 and 3.13.

I think we need to be very clear which ASN.1 data type definition
is associated with the OID.  For example

  This LDAP syntax associates the OID 1.3.6.1.4.1.1466.115.121.1.14
  with the ASN.1 data type DeliveryMethod [REFERENCE].  The 
  following "native" string representation is defined for this
  syntax.

An informative copy of the ASN.1 data definition could be
provided as well.

Then the string representation should be defined in terms
of the referenced ASN.1 data type.  

>For example, in 3.9, rather than "A value in this syntax is a set of
>the ASN.1 enumerated INTEGER 
>   values", we could have:
>
>DeliveryMethod ::= SET OF ENUMERATED {
>        any     (0),
>        mhs     (1),
>        physical        (2),
>        telex   (3),
>        teletex (4),
>        g3fax   (5),
>        g4fax   (6),
>        ia5     (7),
>        videotex        (8),
>        telephone       (9) }
>
>(If that's actually what the statement means.)
>
>Also, there are many multipart syntaxes that lack an ASN.1 definition,
>do we plan to define the ASN.1 for these?

I believe each and every LDAP syntax as an associated ASN.1 definition.
In some cases, it might be implicit or defined in some obscure
document.  We need to clarify for each and every syntax what the
ASN.1 definition is.

There may be some syntaxes which are best removed then clarified.

Kurt

---

From: "Timothy Hahn" <[email-masked]>
Date: Mon, 4 Mar 2002 20:48:54 -0500

Steven,

There's an extension capability for additional information in these things.
Where do you see that being placed?

I would suggest:

    LDAPSchemaDefinition ::= SEQUENCE {
        identifier      OBJECT IDENTIFIER,
        name            SET OF DirectoryString { ub-schema } OPTIONAL,
        obsolete        BOOLEAN DEFAULT FALSE,
        information     LDAPSchemaInformation
        extensions      LDAPSchemaExtensions
    }

    LDAPSchemaExtensions ::= SEQUENCE OF SEQUENCE {
        extensionType   DirectoryString,
        extensionValues SEQUENCE OF DirectoryString
    }

I realize that these don't quite apply to RFC2252bis, but in hopes that
ASN.1 for these is defined at some point, I figured you'd like the
feedback.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

                      "Steven Legg"                                                                                                       
                      <steven.legg@adacel.        To:       "'Jim Sermersheim'" <[email-masked]>, <[email-masked]>           
                      com.au>                     cc:                                                                                     
                      Sent by:                    Subject:  RE: ASN.1 definitions in draft-ietf-ldapbis-syntaxes-01.txt                   
                      owner-ietf-ldapbis@O                                                                                                
                      penLDAP.org                                                                                                         

                      03/04/2002 06:18 PM                                                                                                 
                      Please respond to                                                                                                   
                      steven.legg                                                                                                         

Jim,

> do we plan to define the ASN.1 for these?

In reviewing the LDAP syntaxes some time ago I found ASN.1 type
definitions for all but three syntaxes. These were:

             LDAP Syntax Description - 1.3.6.1.4.1.1466.115.121.1.54
             LDAP Schema Definition  - 1.3.6.1.4.1.1466.115.121.1.56
             LDAP Schema Description - 1.3.6.1.4.1.1466.115.121.1.57

I proposed this ASN.1 type for LDAP Syntax Description:

    LDAPSyntaxDescription ::= SEQUENCE {
        identifier       OBJECT IDENTIFIER,
        description      DirectoryString { ub-schema } OPTIONAL
    }

I proposed this ASN.1 type for LDAP Schema Definition:

    LDAPSchemaDefinition ::= SEQUENCE {
        identifier      OBJECT IDENTIFIER,
        name            SET OF DirectoryString { ub-schema } OPTIONAL,
        obsolete        BOOLEAN DEFAULT FALSE,
        information     LDAPSchemaInformation
    }

    LDAPSchemaInformation ::= SEQUENCE {
        imports         [0] SET SIZE (1..MAX) OF OBJECT IDENTIFIER
OPTIONAL,
        classes         [1] SET SIZE (1..MAX) OF OBJECT-CLASS.&id OPTIONAL,
        attributes      [2] SET SIZE (1..MAX) OF ATTRIBUTE.&id OPTIONAL,
        matching-rules  [3] SET SIZE (1..MAX) OF MATCHING-RULE.&id
OPTIONAL,
        syntaxes        [4] SET SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL
    }

If the group agrees, Kathy and I can put these definitions, plus all the
others I've found, into the syntaxes I-D.

Consensus on LDAP Schema Description was to remove it since it has no
defined native or binary encoding, and no-one implements it.

Regards,
Steven