ASN.1 questions

Kenneth Lundin <>
Wed Oct 25 14:59:59 CEST 2000


"Victor M. Gulias" wrote:
> 
> A couple of questions about the ASN.1 compiler. Could some of you tell me why
> the following definition (from the SET specification) does not compile?
> 
> ---------------
> P2
> DEFINITIONS EXPLICIT TAGS ::=
> BEGIN
> 
> SETString { INTEGER:10 } ::= CHOICE {
>      visibleString  VisibleString (SIZE(1..10)),
>      bmpString      BMPString (SIZE(1..10))
>   }
> 
> END
> ----------------
> 
> % erlc -bber P2.asn
> Erlang ASN.1 version "1.2.7" compiling "/home/lfcia/gulias/work/set/ejemplos/SET/1/P2.asn"
> Compiler Options: [fast,
>                    ber,
>                    report_errors,
>                    {cwd,'/home/lfcia/gulias/work/set/ejemplos/SET/1'},
>                    {outdir,"/home/lfcia/gulias/work/set/ejemplos/SET/1"}]
> "syntax error before: " ["'INTEGER'"] at line 6
> Compiler function asn1ct:compile_asn/3 returned:
> {error,{6,["syntax error before: ",["'INTEGER'"]]}}
> make: *** [all] Error 1
> 
The { INTEGER:10 } belongs to the X.683 "Parameterization of ASN.1
specifications" which very poorly supported by the current version
of the Erlang/ASN.1 compiler. 
Without having the complete X.683 standard in fresh mind I still wonder
if
your example is meaningful. When it comes to parameterization you either
define a parameterized type with names for the formal parameters or
you instantiate an already defined parameteized type by providing the
actual parameters with Typenames and or values.
In your case it is a definition of a parameterized type. Can you explain
what the {INTGER:10} argument is supposed to mean or what effect it is
supposed to have.

> -----------------
> 
> If we remove the { INTEGER:10 } from the LHS of the definition it
> seems to work fine.
Yes since then it is a normal type definition.
> 
> Also, the ASN.1 compiler uses per and ber to code the types. What
> about *der* encoding?
DER is the same as BER but with some restrictions. The
Erlang/ASN.1 compiler does not follow the DER rules 100% but
I don't think it matters in practical use.

DER puts restrictions on:

Length forms (always use definite length) , ok
String encoding, ok
Set components, no not always
Boolean TRUE with all eigth bits set, yes
Unused bits in BIT STRING, yes
Real values, no we hardly support them at all
GeneralString values, no 
Set and Sequence components with default value, no not always
GeneralizedTime, no
UTCTime, no

For all practical uses that I have seen so far the "no's" in the list
are not important. But if someone can show practical examples where
it is important please show me and I will implement 100% DER.

/Regards Kenneth
> 
> Regards,
> 
> --
> Victor M. Gulias

-- 
Kenneth Lundin              Ericsson Utvecklings AB
     ÄT2/UAB/F/P
			    BOX 1505
+46 8 727 57 25 	    125 25 Älvsjö



More information about the erlang-questions mailing list