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