Subject: Re: Cross-purpose SEQUENCE/CHOICE protocol extension fields

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 07 Nov 2004 19:34:59 -0700

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?
 
Jim

>>> Hallvard B Furuseth <[email-masked]> 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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Nov 2004 03:44:22 +0100

> [10]. Does this mean that LDAPResult can only be extended with 4 - 6, 8,

Heh.  Clearly I have no idea how such extensions work.  I assumed any
unused tag could be used, including anything from [12] and up.  I expect
the true answer may reduce the problem my original posting suggested...

-- 
Hallvard

---

From: Steven Legg <[email-masked]>
Date: Tue, 09 Nov 2004 10:16:12 +1100

Jim,

> [10]. Does this mean that LDAPResult can only be extended with 4 - 6, 8, 

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 <[email-masked]> 11/7/04 4:13:45 PM >>>
> 2) One may define trailing SEQUENCE elements; [Protocol] section 4 says

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Nov 2004 12:18:51 +0100

Steven Legg writes:
> 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].  (...)

If one does not know that the peer recognizes an LDAPResult extension,
can that extension be used at all in COMPONENTS OF LDAPResult followed
by some other element?  My guess is no, unless COMPONENTS OF for some
reason is an exception to 'known elements precede unknown elements'.
Even if an extension is standardized, that doesn't mean the peer is
updated to recognize that new standard.

My impression from this thread, with some liberal guessing about what
the ASN.1 speak means:-) is that the BindAuthData and ModifyChangeData
extensions I suggested seem useful, and that a similar extension to
LDAPResult would have been useful if it had been in the standard.
Though one could define it + an extension (either an ASN.1 field or a
control) for clients to inform servers which extensions they recognize.

-- 
Hallvard