Sent by: owner-ietf-ldapbis@OpenLDAP.org
To: <Ron.Ramsay@ca.com>, <mcs@netscape.com>
cc: <ietf-ldapbis@OpenLDAP.org>
Subject: RE: LBER (BER restrictions)
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