[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Protocol: Omitting default values

My feeling is that it is safer to leave the current text and force future extension implementations to specify their own encoding rules when those of Section 5.1 are overly restrictive.

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 3/9/04 6:52:35 AM >>>
Protocol-22 says:

> 5.1. Protocol Encoding

> The protocol elements of LDAP SHALL be encoded for exchange using the
> Basic Encoding Rules [BER] of [ASN.1] with the following
> restrictions:
> (...)
> - If a value of a type is its default value, it is absent. Only some
> BOOLEAN and INTEGER types have default values in this protocol
> definition.

This restriction can be impractical to implement for default values of
complex types. It might be better if it only applied to simple types
That's not relevant for the core protocol, but can be for controls and
extended requests/responses whose values are encoded as ASN.1:

4.1.11. Controls
When a controlValue is defined in terms
of ASN.1, and BER encoded according to Section 5.1, it also follows
the extensibility rules in Section 4.
4.12. Extended Operation
Values that are defined in terms of ASN.1 and BER encoded
according to Section 5.1, also follow the extensibility rules in
Section 4.

Note that these texts do not say that ASN.1 values need to obey these
restrictions; the extensions could instead define their own restrictions
without the one I quoted. But I suspect extensions that do use ASN.1
with complex defaults would prefer to do just that, so it would be
simpler if they didn't have to. OTOH, changing this now will change
the spec of such extensions that already depend on this restriction.
So I'm not sure what is best.