Re: Cross-purpose SEQUENCE/CHOICE protocol extension fields

[Steven Legg <steven.legg@eb2bcom.com>]

Hallvard,

Hallvard B Furuseth wrote:
> There are two different ways to extend BindResponse and ModifyRequest.
> I imagine this may lead to some sort of conflict or at least a rather
> messy situation, in particular in which order the fields should occur:
>
> 1) If one defines a new BindRequest.AuthenticationChoice or
>    ModifyRequest.changes.change.operation, one may need a new matching
>    sequence element in BindResponse or ModifyRequest.changes.change.
>
> 2) One may define trailing SEQUENCE elements; [Protocol] section 4 says
>    implementation must ignore unrecognized trailing SEQUENCE elements.

LDAP uses ASN.1 and ASN.1 has rules for extensibility. Extensions to LDAP
should always be consistent with those rules.

> I don't know that works when there are several extra SEQUENCE elements
> present:  Will an implementation pick up a known element following an
> unknown element?

Extensibilty in ASN.1 is essentially linear and assumed to be employed through
standards actions (user-defined extensions are handled through open types
with component relation constraints - directory attributes fall into this
category). If one follows the ASN.1 rules for extensibility then a known
element will never follow an unknown element.

> Can elements from different specifications be present
> in any order?

No. One of the specifications must logically follow the other and take
account of it.

> Or must all specifications of such elements define where
> in the SEQUENCE the element occurs in relation to all previous
> specifications of other elements?

Yes, mostly. The "where" is always at the end (unless the base specification
explicitly put extension marks somewhere else).

Regards,
Steven

> If this is not a problem, ignore the rest of this message.  Otherwise:
> One fix might be to define (not in LDAPbis) two extensions to be used
> with future specifications of Bind authentication choices and Modify
> operation types:
>
>         -- appended to BindResponse
>         BindAuthData ::= [something] CHOICE {
>              -- currently no choices are defined
>         }
>
>         -- appended to ModifyRequest.changes.change
>         ModifyChangeData ::= [something] CHOICE {
>              -- currently no choices are defined
>         }
>
> where each CHOICE tag number is reserved for the same
> BindRequest.AuthenticationChoice tag number and
> ModifyRequest.changes.change.operation value.
>
> If this is desirable, I don't know if such a draft could - or should -
> be rushed out quickly enough that [protocol] and [ldapiana] can add a
> (maybe informative) reference to it?
>
> For reference, here are the current ASN.1 definitions:
>
>         BindResponse ::= [APPLICATION 1] SEQUENCE { 
>              COMPONENTS OF LDAPResult, 
>              serverSaslCreds    [7] OCTET STRING OPTIONAL }
>
>         ModifyRequest ::= [APPLICATION 6] SEQUENCE { 
>              object          LDAPDN, 
>              changes         SEQUENCE OF change SEQUENCE { 
>                   operation       ENUMERATED { 
>                        add     (0), 
>                        delete  (1), 
>                        replace (2) }, 
>                   modification    PartialAttribute } }
>
> As far as I can tell there are no other protocol fields with similar
> troubles, but I make no promises:-)