[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Cross-purpose SEQUENCE/CHOICE protocol extension fields
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