Agreed. >>> Steven Legg <steven.legg@adacel.com.au> 10/22/03 8:47:10 PM >>> Jim, You've chosen the identifiers I would choose except in one case (see below). Jim Sermersheim wrote: > 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 I would just use "attribute" rather than "partialAttribute". Regards, Steven > > 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, > ch anges 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 > > > > |