Re: Cross-purpose SEQUENCE/CHOICE protocol extension fields

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

Jim,

Jim Sermersheim wrote:
> Reading this, I also noticed that definitions which include COMPONENTS 
> OF LDAPResult add some buffer space for future expansion of LDAPResult, 
> but only a little. LDAPResult has assigned [3] to the last tag in the 
> SEQUENCE. BindResponse starts at [7], and ExtendedResponse starts at 
> [10]. Does this mean that LDAPResult can only be extended with 4 - 6, 8, 
> and 9?

ASN.1 doesn't have a requirement that tag numbers have to be ascending. It is
perfectly legal for LDAPResult to have a new component with tag, say, [50].
It is even possible for two consecutive components of a SEQUENCE to have the
same tag provided the first one is mandatory. It is more than sufficient for
the tags used in LDAPResult to just be different from those used in BindResponse
and ExtendedResponse.

Regards,
Steven

>  
> Jim
>
>  >>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 11/7/04 4:13:45 PM >>>
> 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.
>
> 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? Can elements from different specifications be present
> in any order? Or must all specifications of such elements define where
> in the SEQUENCE the element occurs in relation to all previous
> specifications of other elements?
>
> 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:-)
>
> --
> Hallvard