|
I wasn't thinking on my choice for AuthenticationChoice.simple
(should have been no). I Agree LDAPString is a no as well. I revised the table
below, and I'm back to the original question: Do the restrictions apply to
extension data (extended req/resp, and controls)?
If the text says that "ASN.1 values carried opaquely
as OCTET STRING values are not subject to the restriction", Does it
sufficiently describe what to send and expect from extension data? I suppose if
that data is described as an ASN.1 value in its specification, it
does.
Hmm, now I'm inclined to leave the text alone. Or maybe add
something saying that for controls and extended op's, those specifications
dictate what can/can't be in the value. Does anyone think that is
needed?
Jim
>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 11/22/00 6:28:07 PM >>> Whoa! The exemption applies to ASN.1 values carried opaquely in the protocol as OCTET STRINGs. This eliminates LDAPString, LDAPOID, AuthenticationChoice.simple. Also, I don't think the format of the contents of Control.controlValue, SaslCredentials.credentials, ExtendedResponse.response are specified - they may be text. The text should just say that ASN.1 values carried opaquely as octet strings are not subject to the restriction. Ron. -----Original Message----- From: Jim Sermersheim [mailto:JIMSE@novell.com] Sent: Thursday, 23 November 2000 9:57 To: mcs@netscape.com Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: LBER (BER restrictions) 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 LDAPOID no AttributeValue yes AssertionValue yes Control.controlValue no? AuthenticationChoice.simple no 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 |