From 84adefa331c4159d432d22840663c38f155cd4c1 Mon Sep 17 00:00:00 2001 From: Erlang/OTP Date: Fri, 20 Nov 2009 14:54:40 +0000 Subject: The R13B03 release. --- lib/asn1/examples/InfClass3.asn | 36 ++++++++++ lib/asn1/examples/Int.py | 30 +++++++++ lib/asn1/examples/P-Record.asn | 59 ++++++++++++++++ lib/asn1/examples/RANAPextract1.asn | 101 ++++++++++++++++++++++++++++ lib/asn1/examples/ecn_internaldoc.txt | 74 ++++++++++++++++++++ lib/asn1/examples/encode_decode_formats.txt | 16 +++++ lib/asn1/examples/recordnames.txt | 51 ++++++++++++++ lib/asn1/examples/test_driver.erl | 46 +++++++++++++ 8 files changed, 413 insertions(+) create mode 100644 lib/asn1/examples/InfClass3.asn create mode 100644 lib/asn1/examples/Int.py create mode 100644 lib/asn1/examples/P-Record.asn create mode 100644 lib/asn1/examples/RANAPextract1.asn create mode 100644 lib/asn1/examples/ecn_internaldoc.txt create mode 100644 lib/asn1/examples/encode_decode_formats.txt create mode 100644 lib/asn1/examples/recordnames.txt create mode 100644 lib/asn1/examples/test_driver.erl (limited to 'lib/asn1/examples') diff --git a/lib/asn1/examples/InfClass3.asn b/lib/asn1/examples/InfClass3.asn new file mode 100644 index 0000000000..6c1fd0f430 --- /dev/null +++ b/lib/asn1/examples/InfClass3.asn @@ -0,0 +1,36 @@ +InfClass3 DEFINITIONS ::= +BEGIN + +FUNCTION ::= CLASS { + &ArgumentType, + &ResultType DEFAULT NULL, + &code INTEGER + } + +ObjSet1 FUNCTION ::= { ... } + +object1 FUNCTION ::= { + &ArgumentType INTEGER, + &ResultType INTEGER, + &code 3 + } + +object2 FUNCTION ::= { + &ArgumentType INTEGER, + &ResultType INTEGER, + &code 2 + } + + +ObjSet2 FUNCTION ::= { + object1 | object2 } + +ParamType{FUNCTION:object} ::=SEQUENCE +{ + val1 INTEGER, + val2 object.&ArgumentType + } + +parTypVal{FUNCTION:object2} ParamType ::= {1,2} + +END diff --git a/lib/asn1/examples/Int.py b/lib/asn1/examples/Int.py new file mode 100644 index 0000000000..490d5a16ea --- /dev/null +++ b/lib/asn1/examples/Int.py @@ -0,0 +1,30 @@ +Int DEFINITIONS ::= +BEGIN + +-- F.2.2.2 +-- Define the minimum and maximum allowed values of an integer type +-- as named numbers. +-- EXAMPLE + + DayOfTheMonth ::= INTEGER {first(1), last(31)} + today DayOfTheMonth ::= first + unknown DayOfTheMonth ::= 0 + +-- To restrict the value of DayOfTheMonth to just "first" and "last", +-- one would write: + + DayOfTheMonth2 ::= INTEGER {first(1), last(31)} (first | last) + +-- and to restrict the value of the DayOfTheMonth to all values +-- between 1 and 31, inclusive, one would write: + + DayOfTheMonth3 ::= INTEGER {first(1), last(31)} (first .. last) + dayOfTheMonth DayOfTheMonth3 ::= 4 + + SmallInt ::= INTEGER (0..1000) + OrInt ::= INTEGER (10 | 20 | 30) + + small SmallInt ::= 17 + or OrInt ::= 20 + +END diff --git a/lib/asn1/examples/P-Record.asn b/lib/asn1/examples/P-Record.asn new file mode 100644 index 0000000000..13643efef3 --- /dev/null +++ b/lib/asn1/examples/P-Record.asn @@ -0,0 +1,59 @@ +P-Record DEFINITIONS ::= +BEGIN + + +PersonnelRecord ::= [APPLICATION 0] SET +{ name Name, + title VisibleString, + number EmployeeNumber, + dateOfHire Date, + nameOfSpouse [1] Name, + children SEQUENCE OF ChildInformation DEFAULT {} +} + +ChildInformation ::= SET +{ name Name OPTIONAL, + dateOfBirth Date OPTIONAL +} + +Name ::= [APPLICATION 1] SEQUENCE +{ givenName VisibleString, + initial VisibleString, + familyName VisibleString +} + +EmployeeNumber ::= [APPLICATION 2] INTEGER +Date ::= [APPLICATION 3] VisibleString -- YYYY MMDD + +v PersonnelRecord ::= +{ + name { + givenName "John", + initial "P", + familyName "Smith" + }, + title "Director", + number 51, + dateOfHire "19710917", + nameOfSpouse { + givenName "Mary", + initial "T", + familyName "Smith" + }, + children { + {name { + givenName "Ralph", + initial "T", + familyName "Smith" + } , + dateOfBirth "19571111"}, + {name { + givenName "Susan", + initial "B", + familyName "Jones" + } , + dateOfBirth "19590717" } + } +} + +END diff --git a/lib/asn1/examples/RANAPextract1.asn b/lib/asn1/examples/RANAPextract1.asn new file mode 100644 index 0000000000..fdd33d6027 --- /dev/null +++ b/lib/asn1/examples/RANAPextract1.asn @@ -0,0 +1,101 @@ +RANAPextract1 DEFINITIONS ::= +BEGIN + + +RANAP-ELEMENTARY-PROCEDURE ::= CLASS { + &InitiatingMessage , + &SuccessfulOutcome OPTIONAL, + &UnsuccessfulOutcome OPTIONAL, + &Outcome OPTIONAL, + &procedureCode ProcedureCode UNIQUE, + &criticality Criticality DEFAULT ignore +} +WITH SYNTAX { + INITIATING MESSAGE &InitiatingMessage + [SUCCESSFUL OUTCOME &SuccessfulOutcome] + [UNSUCCESSFUL OUTCOME &UnsuccessfulOutcome] + [OUTCOME &Outcome] + PROCEDURE CODE &procedureCode + [CRITICALITY &criticality] +} + +RANAP-PDU ::= CHOICE { + initiatingMessage InitiatingMessage, + -- successfulOutcome SuccessfulOutcome, + -- unsuccessfulOutcome UnsuccessfulOutcome, + -- outcome Outcome, + ... +} + +InitiatingMessage ::= SEQUENCE { + procedureCode RANAP-ELEMENTARY-PROCEDURE.&procedureCode ({RANAP-ELEMENTARY-PROCEDURES}), + criticality RANAP-ELEMENTARY-PROCEDURE.&criticality ({RANAP-ELEMENTARY-PROCEDURES}{@procedureCode}), + value RANAP-ELEMENTARY-PROCEDURE.&InitiatingMessage ({RANAP-ELEMENTARY-PROCEDURES}{@procedureCode}) +} + +iu-Release RANAP-ELEMENTARY-PROCEDURE ::= { + INITIATING MESSAGE Iu-ReleaseCommand + SUCCESSFUL OUTCOME Iu-ReleaseComplete + PROCEDURE CODE id-Iu-Release + CRITICALITY ignore +} + +relocationPreparation RANAP-ELEMENTARY-PROCEDURE ::= { + INITIATING MESSAGE Iu-ReleaseCommand + SUCCESSFUL OUTCOME Iu-ReleaseComplete + PROCEDURE CODE id-relocationPreparation + CRITICALITY notify +} + +testObject RANAP-ELEMENTARY-PROCEDURE ::= { + INITIATING MESSAGE Iu-ReleaseCommand + SUCCESSFUL OUTCOME Iu-ReleaseComplete + PROCEDURE CODE id-test + CRITICALITY notify +} + +testObject2 RANAP-ELEMENTARY-PROCEDURE ::= { + INITIATING MESSAGE Iu-ReleaseCommand + SUCCESSFUL OUTCOME Iu-ReleaseComplete + PROCEDURE CODE id-test2 + CRITICALITY notify +} + +RANAP-ELEMENTARY-PROCEDURES RANAP-ELEMENTARY-PROCEDURE ::= { + iu-Release | + relocationPreparation , + ... +} + +RANAP-ELEMENTARY-PROCEDURES2 RANAP-ELEMENTARY-PROCEDURE ::= { + {INITIATING MESSAGE Iu-ReleaseCommand + SUCCESSFUL OUTCOME Iu-ReleaseComplete + PROCEDURE CODE id-test + CRITICALITY notify} +} + +RANAP-ELEMENTARY-PROCEDURES3 RANAP-ELEMENTARY-PROCEDURE ::= { + iu-Release| + testObject, + ..., + relocationPreparation | + testObject2 +} + +Iu-ReleaseCommand ::= SEQUENCE { + first INTEGER, + second BOOLEAN +} + +Iu-ReleaseComplete ::= INTEGER (1..510) + +ProcedureCode ::= INTEGER (0..255) +Criticality ::= ENUMERATED { reject, ignore, notify } +id-Iu-Release INTEGER ::= 1 +id-relocationPreparation INTEGER ::= 2 +id-test INTEGER ::= 3 +id-test2 INTEGER ::= 4 + +END + + diff --git a/lib/asn1/examples/ecn_internaldoc.txt b/lib/asn1/examples/ecn_internaldoc.txt new file mode 100644 index 0000000000..71e2b7a2f1 --- /dev/null +++ b/lib/asn1/examples/ecn_internaldoc.txt @@ -0,0 +1,74 @@ +The ECN specification (X.692) describes how to make encodings +different from the standardised methods, BER and PER with variants. + +ECN has a system with inter-working modules including ordinary ASN1 +specs. There are any number of EDM (Encoding Definition Module) +modules. And always one ELM (Encoding Link Module). + +The EDMs contains definitions of encoding classes, encoding objects +and encoding object sets. They may also have IMPORTS and EXPORTS +clauses. Encoding classes tells the structure of the encoding. Besides +classes corresponding to types there are classes that define +determinants for length and presence. The objects tell how the actual +type that will be mapped to this object is encoded. + +The ELM is the module that links (applies) the various encodings, +defined in the EDMs, to the types in the ASN1 specs. + +The ASN1 specs are not affected by being part of an ECN application. + +The following requirements must be wholly or partly fulfilled to +enable the use of ECN in the OTP ASN1 compiler. + - Parsing of EDM and ELM modules. + - Extend the format of the abstract syntax tree or in other way + pass encoding information to code generation. + - Make possible to generate code with different encoding + methods. + - Unaligned PER backend. Often seems the unaligned PER encoding + as the prefferred main method in ECN applications. One of the + goals with ECN is to use less space for encoding to decrease + the use of bandwith in transmission. This goal is highly + supported by unaligned PER. + + +Parsing of EDM and ELM modules: +This should be done in a different parser than by the ASN1 +asn1ct_parser2.erl. The ECN syntax is quite extensive. A deeper +investigation must be done here. + +Extend format of abstract syntax: +To derive this format one has to consider both the explicit and +implicit defined encoding structures. +This addition of information should maybe be done after the check +phase of the ASN1 syntax. + +Code generation: +Initially one can just generate call-back functions when the encoding +differs from the default method. Nevertheless the information must be +present in the sytax tree so far. When the full functionality is +implemented one has to enable a finer granularity in the use of the +encoding rules. And also enable control of encoding on bit level. + +Unaligned PER backend: +Often in examples this variant of PER is used. It shouldn't be that +much work to add this encoding. Probably this will benefit the use of +the driver. + + +ECN can be used in for instance: + - Protocol systems that is not an ASN1 protocol. + - Specialized ASN1 protocols. + + +Need for ECN? + +Among the ASN1 systems that have been enabled for ECN are: +UMTS, +Bluetooth, +GPRS, +CAMEL phase 3 stage 2, +SS7, +SCCP, +and others. + +Inswitch has asked for it. diff --git a/lib/asn1/examples/encode_decode_formats.txt b/lib/asn1/examples/encode_decode_formats.txt new file mode 100644 index 0000000000..62774cf13b --- /dev/null +++ b/lib/asn1/examples/encode_decode_formats.txt @@ -0,0 +1,16 @@ +Compile options: | encode output | decode input | +------------------------------+-----------------------+-----------------| +ber (default) | flat list | flat list,binary| +ber_bin | iolist | binary | +ber_bin,optimize | iolist | binary | +ber_bin,optimize,driver | iolist | iolist,binary | +per | flat list | flat list | +per_bin | deep list | binary | +per_bin, optimize | binary | binary | +------------------------------+-----------------------+-----------------+ + + + + + +iolist: deep list with binaries and lists as componets \ No newline at end of file diff --git a/lib/asn1/examples/recordnames.txt b/lib/asn1/examples/recordnames.txt new file mode 100644 index 0000000000..78e30ab510 --- /dev/null +++ b/lib/asn1/examples/recordnames.txt @@ -0,0 +1,51 @@ +For each ASN1 types SET and SEQUENCE a record is generated in the .hrl +file with the same name as the corresponding type. +A decoded value is also returned as a record with the apropriate name. +An internally defined type as the type in component 'a' in the +following example will result in a record with name 'Seq_a': + +Seq ::= SEQUENCE{ + a SEQUENCE{ + b INTEGER + } +} + +For each further internally defined type in a SET/SEQUENCE a +'_componentname' is added. + +If an internally defined type is an CHOICE alternative the record name +will get the alternative name as a unique part of the name. + +Seq ::= SEQUENCE{ + a CHOICE{ + b SEQUENCE { + c INTEGER + } + } +} + +This will produece a record 'Seq_a_b'. + +If an component is a SEQUENCE OF a SEQUENCE as in: +Seq ::= SEQUENCE { + a SEQUENCE OF SEQUENCE { + b + } + c SET OF SEQUENCE { + d + } +} +There will be a record 'Seq_a_SEQOF' and 'Seq_c_SETOF' + +A parameterized type should be considered as an internally defined +type. Each time a such type is referenced an instance of it is +defined. Thus in the following example a record 'Seq_b' is generated +in .hrl and used in .erl by decode. + +Seq ::= SEQUENCE { + b PType{INTEGER} +} + +PType{T} ::= SEQUENCE{ + id T +} \ No newline at end of file diff --git a/lib/asn1/examples/test_driver.erl b/lib/asn1/examples/test_driver.erl new file mode 100644 index 0000000000..2bbdce4934 --- /dev/null +++ b/lib/asn1/examples/test_driver.erl @@ -0,0 +1,46 @@ +%%%------------------------------------------------------------------- +%%% File : test_driver.erl +%%% Author : Bertil Karlsson +%%% Description : +%%% +%%% Created : 27 Mar 2002 by Bertil Karlsson +%%%------------------------------------------------------------------- +-module(test_driver). + +-export([start/0, start/1, init/1, complete/1,complete/0]). + +start() -> + start("asn1_erl_drv"). + +start(SharedLib) -> + case erl_ddll:load_driver("../priv/bin/", SharedLib) of + ok -> ok; + {error, already_loaded} -> ok; + Error -> exit({error, could_not_load_driver,Error}) + end, + spawn(?MODULE, init, [SharedLib]). + +init(SharedLib) -> + Port = open_port({spawn, SharedLib}, []), + register(drv_complete,Port), + register(compl_pid,self()), + receive + stop -> + exit(goodbye) + end. + +complete(Data) -> + Ret=port_control(drv_complete,1,Data), + io:format("complete result:~n~p~n",[Ret]). + +complete() -> + %% The result should be <<64,192,17,17,24,96>> + Data1 = [<<0:8>>,<<1:8>>,<<2:8>>,<<10:8,2:8,3:8>>,<<20:8,2:8,17:8,17:8>>,<<30:8,2:8,1:8,24:8>>,<<31:8,2:8,0:8,1:8,24:8>>,<<2:8>>], + complete(Data1), + io:format("should have been:~n<<64,192,17,17,24,96>>~n"), + Data2 = [40,8,8,1,0,1,0,1,0,1,0,0,2,1,45,8,1,170,45,7,1,170], + complete(Data2), + io:format("should have been:~n<<170,0,213,85>>~n"), + Data3 = [40,8,8,1,0,1,0,1,0,1,0,0,2,1,45,8,1,170,45,8,1,170], + complete(Data3), + io:format("should have been:~n<<170,0,213,85,0>>~n"). -- cgit v1.2.3