RE: WG Last Call: draft-ietf-ldapbis-protocol-17.txt [corrected]

["Jim Sermersheim" <jimse@novell.com>]

So, the changes would produce these types, correct?
 
AttributeSelection ::= SEQUENCE OF selection LDAPString

Attribute ::= SEQUENCE {
   type    AttributeDescription,
   vals    SET SIZE (1..MAX) OF value AttributeValue }

Referral ::= SEQUENCE SIZE (1..MAX) OF url URL

Controls ::= SEQUENCE OF control Control

Filter ::= CHOICE {
   and             [0] SET SIZE (1..MAX) OF filter Filter,
   or              [1] SET SIZE (1..MAX) OF filter Filter,
   not             [2] Filter,
   equalityMatch   [3] AttributeValueAssertion,
   substrings      [4] SubstringFilter,
   greaterOrEqual  [5] AttributeValueAssertion,
   lessOrEqual     [6] AttributeValueAssertion,
   present         [7] AttributeDescription,
   approxMatch     [8] AttributeValueAssertion,
   extensibleMatch [9] MatchingRuleAssertion }

SubstringFilter ::= SEQUENCE {
   type            AttributeDescription,
   -- at least one must be present,
   -- initial and final can occur at most once
   substrings      SEQUENCE SIZE (1..MAX) OF substring CHOICE {
      initial [0] AssertionValue,
      any     [1] AssertionValue,
      final   [2] AssertionValue } }

PartialAttributeList ::= SEQUENCE OF partialAttribute PartialAttribute

PartialAttribute ::= SEQUENCE {
   type   AttributeDescription,
   vals   SET OF value AttributeValue }

SearchResultReference ::= 
   [APPLICATION 19] SEQUENCE SIZE (1..MAX) OF url URL

ModifyRequest ::= [APPLICATION 6] SEQUENCE {
   object          LDAPDN,
   changes         SEQUENCE OF change SEQUENCE {
      operation       ENUMERATED {
         add     (0),
         delete  (1),
         replace (2) },
      modification    PartialAttribute } }

AttributeList ::= SEQUENCE OF attribute Attribute

I'll do this unless there are objections.
 
Jim

>>> "Steven Legg" <steven.legg@adacel.com.au> 10/6/03 6:07:13 PM >>>

Folks,

I recently published an Internet draft on an XML rendition of the LDAP
protocol (called XLDAP) that is realized by applying a set of XML
encoding rules to the ASN.1 types in the ASN.1 specification for LDAP
(specifically the ASN.1 in the protocols draft being last-called).

The XML produced is neat and tidy except with respect to the instances
of the member type of a SEQUENCE OF or SET OF ASN.1 type.

Consider this example drawn from the protocols draft:

AttributeList ::= SEQUENCE OF SEQUENCE { 
type AttributeDescription, 
vals SET OF AttributeValue } 

Using my Directory XML Encoding Rules (DXER) to encode an attribute
list,
each attribute in the list is encoded as an element with the safe, but
bland name of <item>. Using the ITU-T's XML Encoding Rules (XER), each
attribute in the list is encoded as an element with the unappealing
name
of <SEQUENCE>.

However the situation can be improved since the version of ASN.1 that
the protocols draft is referencing allows an ASN.1 identifier after a
SEQUENCE OF or SET OF and before the definition of the member type.

For example:

AttributeList ::= SEQUENCE OF attribute SEQUENCE { 
type AttributeDescription, 
vals SET OF value AttributeValue } 

With this change both DXER and XER would encode each attribute in the
list
as an element with the more meaningful name of <attribute>. This
change
makes no difference to the BER encoding, so it is neutral to LDAP and
does
not represent a new feature.

I would like to see each of the SEQUENCE OF and SET OF definitions in
the
LDAP ASN.1 module given a meaningful mnemonic identifier for the member
type
so as to facilitate better XML representations of LDAP operations
(whether
for XLDAP or any other purpose). If the working group allows it I'll
work
with Jim to make the additions.

Regards,
Steven