[erlang-bugs] asn1ct out of date?

Kenneth Lundin <>
Tue Dec 8 22:39:56 CET 2009


Hi again,

I was a bit quick in the last answer regarding the SEQUENCE SIZE() OF construct.
This construct is already supported, but not the NamedType following
the OF keyword.
This is the same limitation as the plain SEQUENCE OF which also did
not support NamedType.

By the way thanks for the bug-report.
I will correct and add this functionality in the next release.

I also think that your changes in the ASN.1 spec in order to let it
through the compiler is
perfectly ok because they will have no impact on the BER encoding
(which is used in LDAP).

/Kenneth

On Fri, Dec 4, 2009 at 1:52 PM, Kenneth Lundin <> wrote:
> Hi,
>
> This isa new LDAP ASN.1 spec that I have not seen before.
> The previous ones has passed the Erlang ASN.1 compiler without problems.
>
> The Erlang ASN.1 compiler does not support everything in the 2002
> standard of ASN.1 and there might also be limitations vs the 1997
> standard.
>
> We have implemented the constructs that we have seen need for because
> they have occured in specifications used by our customers.
>
> This is the firs time I see use of:
>
> EXSTENSIBILITY IMPLIED, % I will implement that  soon, quite easy
> SEQUENCE OF NamedType which is equivalent to
> SEQUENCE OF identifier Type % I will implement that too,the
> identifier is of no real use as I understand it except maybe if the
> XML encoding rules and value notation is to be used. And
> we don't support them now.
>
> SET OF identifier Type % will implement that too, same as SEQUENCE OF
>
> SEQUENCE SIZE (1..MAX) OF uri URI % I can't see that this is allowed
> syntax in any version of ASN.1?
>
> /Kenneth , Erlang/OTP Ericsson
>
> On Sun, Nov 8, 2009 at 4:38 PM, Steve Davis
> <> wrote:
>> While working towards implementing an LDAP server I found that asn1ct does
>> not appear to support the current LDAP asn.1 specification format.
>>
>> http://tools.ietf.org/html/rfc4511#appendix-B
>>
>> Attached is the modified ASN.1 for LDAP3 with the statements that cause the
>> compile time errors commented out as: --##
>>
>> Of course, the modified asn file defines a protocol that is no longer
>> "according to spec"
>>


More information about the erlang-bugs mailing list