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

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

It seems to me that (currently) any extension specification must be
cognizant of all previous extension specifications and the SEQUENCE
numbers they have set aside for their use. It would be better if we
could solve this in [LDAPIANA]. I don't know how to do that other than
to set up registrations for each protocol type which is extensible. That
seems like an ugly task, so hopefully someone else has a better idea.
 
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 09:01:14 +0100

Jim Sermersheim writes:
> numbers they have set aside for their use.

I wish someone had given a different answer to that:-)

> It would be better if we

If we are to do that, I'm not sure what is ugly about the task.
Using existing [Protocol] fields as examples (pretend [Protocol]
does not define them), it could be just one table like this, even
with the fields [LDAPIANA] explicitly lists as extendable:

  ASN.1 field name                        tag or value    (extra info)
  --------------------------------------------------------------------
  LDAPMessage.protocolOp.bindRequest      [APPLICATION 0] 
  LDAPMessage.protocolOp.bindResponse     [APPLICATION 1]
          specification: [protocol] - or [roadmap]?
          contact: ...

  AuthenticationChoice.sasl               [3]           (usage COMMON)
          specification: ...
          contact: ...

  LDAPResult.resultCode.operationsError   1
          ...
  SearchRequest.scope.singleLevel         1       (LDAPURL name "one")
          ...
  Filter.and                              [0]
          ...
  ModifyRequest.changes.operation.delete  1
          ...

Though shorter field names would be nicer - i.e. if some fields in the
ASN.1 grammar are moved out from their surrounding SEQUENCE or whatever.

-- 
Hallvard