Hello all,



I have come across a problem when importing ASN.1 types into TTCN-3 modules.
Specifically, the NULL type is giving me the worst headache. Why can't it be
directly mapped to TTCN-3's 'null'?



Please look at the example below...



Consider the following ASN.1 type:



X ::= CHOICE

{

a INTEGER,

b BOOLEAN,

c NULL

}



Suppose we import this into a TTCN-3 module and now we want to write a
template for this type, a template where the 'c' alternative is selected.
Intuitively, that would be done this way:



template X XcTemp :=

{

c := null

}



This is not permitted, however. Look at the mapping rules in D.1.1.0, where
NULL is not included. Then, at D.1.2.0, clause 21, we see that we are
supposed to "replace all occurrences of NULL type with the following
associated ASN.1 type:

type enumerated <identifier> { NULL } , where <identifier> is the ASN.1 Type
referenced converted according to clause D.1.1.1"



OK... So, we should define a type like

" type enumerated X { NULL } "

Right?



No, that doesn't make any sense, since you hardly can represent a three-way
CHOICE with an enumeration, certainly not one that only contains one
possible value.



Then what about

" type enumerated X.c { NULL } "

is that any better?



No, according to BNF rule 38 (and common sense), it is not allowed.

So, my question is; How is this supposed to work, really?



Any input is appreciated.



Cheers,

/Johan

---

---

Tau Generation2 - Development Visualized. Productivity Realized.

Learn more about Telelogic's new system and software development

solution at: <www.taug2.com/> www.taug2.com

---

---

Johan Nordin

Support Engineer

Telelogic

Box 4128 SE-203 12 Malmö, Sweden
Visiting Address: Kungsgatan 6

Tel: +46 703 05 25 27

Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

URL: <www.telelogic.com/> www.telelogic.com/

---

---

Telelogic - Putting you ahead in development!

---

---

ext Johan Nordin wrote:

> Hello all,
>
>
>
> I have come across a problem when importing ASN.1 types into TTCN-3
> modules. Specifically, the NULL type is giving me the worst headache.
> Why can't it be directly mapped to TTCN-3's 'null'?
>
>
>
> Please look at the example below...
>
>
>
> Consider the following ASN.1 type:
>
>
>
> X ::= CHOICE
>
> {
>
> a INTEGER,
>
> b BOOLEAN,
>
> c NULL
>
> }
>
>
>
> Suppose we import this into a TTCN-3 module and now we want to write a
> template for this type, a template where the 'c' alternative is
> selected. Intuitively, that would be done this way:
>
>
>
> template X XcTemp :=
>
> {
>
> c := null
>
> }
>

null in TTCN-3 has nothing at all to do with NULL in ASN.1. 'null' in
TTCN-3 is a special value of type default or component reference.

>
>
> This is not permitted, however. Look at the mapping rules in D.1.1.0,
> where NULL is not included. Then, at D.1.2.0, clause 21, we see that
> we are supposed to "replace all occurrences of NULL type with the
> following associated ASN.1 type:
>
> type enumerated <identifier> { NULL } , where <identifier> is the
> ASN.1 Type referenced converted according to clause D.1.1.1"
>

This is the core of the problem - the ASN.1 mapping rules do not include
NULL. There is a workaround, though, that we use successfully throughout
a number of projects:

In your ASN.1 module, define a synonym of the NULL type and the NULL value:

ASNNULL ::= NULL

asnNULL NULL ::= NULL

After importing these types into TTCN-3, you can use ASNNULL for the
NULL type and asnNULL for the NULL value.

At least for Tau/Tester I know that this works.

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi,

Because there is no null type in TTCN-3, null is a specific value used for component, default etc. types. But you need not define anything in a TTCN-3 module, just simply write:

template X XcTemp :=

{

c := NULL

}


Conversion rules define only the value notation syntax to be used in the case of imported ASN.1 types (the facto for those one non existing in TTCN-3). You may use some NULL type in your tool and know that the value notation for this one shall be "NULL" and it shall be coded as an ASN.1 NULL type (tag!).

Gyorgy

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Johan Nordin
Sent: Tuesday, November 18, 2003 10:23 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Using ASN.1 types in TTCN-3 = problems



Hello all,



I have come across a problem when importing ASN.1 types into TTCN-3 modules. Specifically, the NULL type is giving me the worst headache. Why can't it be directly mapped to TTCN-3's 'null'?



Please look at the example below...



Consider the following ASN.1 type:



X ::= CHOICE

{

a INTEGER,

b BOOLEAN,

c NULL

}



Suppose we import this into a TTCN-3 module and now we want to write a template for this type, a template where the 'c' alternative is selected. Intuitively, that would be done this way:



template X XcTemp :=

{

c := null

}



This is not permitted, however. Look at the mapping rules in D.1.1.0, where NULL is not included. Then, at D.1.2.0, clause 21, we see that we are supposed to "replace all occurrences of NULL type with the following associated ASN.1 type:

type enumerated <identifier> { NULL } , where <identifier> is the ASN.1 Type referenced converted according to clause D.1.1.1"



OK... So, we should define a type like

" type enumerated X { NULL } "

Right?



No, that doesn't make any sense, since you hardly can represent a three-way CHOICE with an enumeration, certainly not one that only contains one possible value.



Then what about

" type enumerated X.c { NULL } "

is that any better?



No, according to BNF rule 38 (and common sense), it is not allowed.

So, my question is; How is this supposed to work, really?



Any input is appreciated.



Cheers,

/Johan

---

Tau Generation2 - Development Visualized. Productivity Realized.

Learn more about Telelogic's new system and software development

solution at: <www.taug2.com/> www.taug2.com

---

Johan Nordin

Support Engineer

Telelogic

Box 4128 SE-203 12 Malmö, Sweden
Visiting Address: Kungsgatan 6

Tel: +46 703 05 25 27

Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

URL: <www.telelogic.com/> www.telelogic.com/

---

Telelogic - Putting you ahead in development!

---

Hi,

You do not need any workaround if a tool implements the defined conversion rules
correctly.

In Johan's example:
The ASN.1 type
X ::= CHOICE
{
a INTEGER,
b BOOLEAN,
c NULL
}
The TTCN-3 view of this is:
type union X {
integer a,
boolean b,
enumerated c { NULL }
}

This is naturally not a legal TTCN-3 type (but this is not required). Note the
trick: field "X.c" is the type reference for the NULL type in the given context.
In practical terms the ASN.1 type shall be converted to some tool-internal
structure that directly allows the value notation (and also correct encoding):
template X XcTemp := { c:= NULL }

Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of Stephan Tobies
> Sent: Tuesday, November 18, 2003 10:32 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Using ASN.1 types in TTCN-3 = problems
>
>
> ext Johan Nordin wrote:
>
> > Hello all,
> >
> >
> >
> > I have come across a problem when importing ASN.1 types into TTCN-3
> > modules. Specifically, the NULL type is giving me the worst
> headache.
> > Why can't it be directly mapped to TTCN-3's 'null'?
> >
> >
> >
> > Please look at the example below...
> >
> >
> >
> > Consider the following ASN.1 type:
> >
> >
> >
> > X ::= CHOICE
> >
> > {
> >
> > a INTEGER,
> >
> > b BOOLEAN,
> >
> > c NULL
> >
> > }
> >
> >
> >
> > Suppose we import this into a TTCN-3 module and now we want
> to write a
> > template for this type, a template where the 'c' alternative is
> > selected. Intuitively, that would be done this way:
> >
> >
> >
> > template X XcTemp :=
> >
> > {
> >
> > c := null
> >
> > }
> >
>
> null in TTCN-3 has nothing at all to do with NULL in ASN.1. 'null' in
> TTCN-3 is a special value of type default or component reference.
>
> >
> >
> > This is not permitted, however. Look at the mapping rules
> in D.1.1.0,
> > where NULL is not included. Then, at D.1.2.0, clause 21, we see that
> > we are supposed to "replace all occurrences of NULL type with the
> > following associated ASN.1 type:
> >
> > type enumerated <identifier> { NULL } , where <identifier> is the
> > ASN.1 Type referenced converted according to clause D.1.1.1"
> >
>
> This is the core of the problem - the ASN.1 mapping rules do
> not include
> NULL. There is a workaround, though, that we use successfully
> throughout
> a number of projects:
>
> In your ASN.1 module, define a synonym of the NULL type and
> the NULL value:
>
> ASNNULL ::= NULL
>
> asnNULL NULL ::= NULL
>
> After importing these types into TTCN-3, you can use ASNNULL for the
> NULL type and asnNULL for the NULL value.
>
> At least for Tau/Tester I know that this works.
>
> BR
>
> Stephan
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>

Hi Johah,

I have come across a problem when importing ASN.1 types into TTCN-3 modules.
Specifically, the NULL type is giving me the worst headache. Why can't it be
directly mapped to TTCN-3's 'null'?

Correct me if I am wrong, but NULL in ASN.1 is both a type and a value, which is
not the case in TTCN-3. That is why you are having this problem I suspect.

Cheers,

Claude.




--
Claude Desroches email:CDesroche@aol.com
Conformance Technologies Ltd. phone: +49 30 9606 7986
685 Cedar Point Road fax: +49 30 9606 7987
Penetanguishene Ontario, mobile 0174 701 6792
Canada

Dear Claude,
Very astute!

Best regards,
Bob


On Wed, 19 Nov 2003, Claude Desroches wrote:

> Hi Johah,
>
> I have come across a problem when importing ASN.1 types into TTCN-3 modules.
Specifically, the NULL type is giving me the worst headache. Why can't it be
directly mapped to TTCN-3's 'null'?
>
> Correct me if I am wrong, but NULL in ASN.1 is both a type and a value, which
is not the case in TTCN-3. That is why you are having this problem I suspect.
>
> Cheers,
>
> Claude.
>
>
>
>
> --
> Claude Desroches email:CDesroche@aol.com
> Conformance Technologies Ltd. phone: +49 30 9606 7986
> 685 Cedar Point Road fax: +49 30 9606 7987
> Penetanguishene Ontario, mobile 0174 701 6792
> Canada
>