Re: Cross-purpose SEQUENCE/CHOICE protocol extension fields

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:
> 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.

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

> 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.

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