|
Looking at this again, I suggest we enumerate all things that
are OCTET STRING values and explicitly state those that are exceptions to the
BER restrictions.
value
exempt?
LDAPString
no (are there special cases where this is
yes?)
LDAPOID no AttributeValue yes AssertionValue yes Control.controlValue no? AuthenticationChoice.simple yes? SaslCredentials.credentials yes BindResponse.serverSaslCred yes ExtendedRequest.requestValue no? ExtendedResponse.response no? I'm not sure about those with ? marks.
>>> Mark Smith <mcs@netscape.com> 11/22/00 1:44:34 PM >>> Jim Sermersheim wrote: > > In section 5.1 of RFC 2251, after enumerating the restrictions on BER it says: > > "These restrictions do not apply to ASN.1 types encapsulated inside of > OCTET STRING values, such as attribute values, unless otherwise noted." > > I think this should also apply control values and extended operation values. > If so, I'll call those out as well here for clarification. Are you suggesting that Control/controlValue, ExtendedRequest/requestValue, and ExtendedResponse/response NOT be subject to the BER restrictions outlined in section 5.1? I would prefer that they continue to be subject to the restrictions. Why? Because controls and extensions can be standardized and there are advantages in having the restrictions in place (both in terms of increased efficiency and in terms of reduced complexity). -- Mark Smith Directory Product Development / Netscape |