Hi Colin et all.,

See my comments to comments regarding ASN.1 (below). Please note: my comments are strictly related to the text of the standard and not off-line thoughts! I think the text in the standard shall be unambiguous and self-explaning.

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
web: <www.r.eth.ericsson.se/~ethgry> www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Csaba Koppany [ <This email address is being protected from spambots. You need JavaScript enabled to view it.> This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Thursday, October 18, 2001 2:17 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: RE: FW: TTCN3 list of errors FYI
>
>
>Gyuri!
>
>Az ASN.1-eket te irtad, inkabb Te olvads at oket!
>
>Udv, Csaba.
>

---

Begin Forwarded Message

---

>
>From: Colin Willcock <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>To: Csaba Koppany_Internet <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>Cc: Anthony Wiles <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>Subject: RE: FW: TTCN3 list of errors FYI
>Date: Thu, 18 Oct 2001 12:31:19 +0200
>MIME-Version: 1.0
>
>Hi Csaba,
>
>

---

Original Message

---

>From: Csaba Koppany [ <This email address is being protected from spambots. You need JavaScript enabled to view it.> This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: 17 October 2001 16:32
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: RE: FW: TTCN3 list of errors FYI
>
>MyvarA := MyvarC; // That is causeing me some hedache! Is it
>useful? Why?
>
>YES this is very useful! thing of a structure with 100 fields
>now do you
>wish
>to assign this in one simple statement or 100?
>
>Now to some of the ASN.1 issues raised by Ericsson.
>
>Error report 17
>===============
>
>Why can't value sets be imported from ASN.1?
>
>The answer quite simply is that value sets do not exist as
>named entities in
>ASN.1!
>This point is perhaps a little difficult to understand to
>those not deeply
>involved
>in the ASN.1 language, but let me try and explain from the
>Ericsson example
>in ER17
>
>b) Why value sets are not accessible? I can not see (at the moment) a
>justification
>for it as TTCN-3 also supports list of values. Note that
>subtypes and value
>sets are
>semantically equal, differs syntactically only.
>
>So if subtypes are accessible (see item a), value sets also should be.
>If defined in ASN.1:
>
> SampleMessage ::= SEQUENCE { field1 Field1,
> <further
>components> }
>
> Field1 ::= INTEGER (0..15)
>
>====> DefinedValuesForField1 Field1 ::= {0 | 1} <============
>
>Why the definition is forbidden?:
>
> template SampleMessage myMessage := {field1 :=
>DefinedValuesForField1,
> <further
>components> }
>
>The point is this subtypes can be imported from ASN.1 to
>TTCN-3, But the
>highlighted
>ASN.1 definition defines not a value set but just another
>subtype (check
>clause 13.4
>in X.680). With this in mind DefinedValuesForField1 may be
>imported into
>TTCN-3 (its just a type)
>but obviously it cannot be used in the template in the way you
>have you may
>not assign
>a type to a field of a template. Please also note we cannot
>import it as
>anything other
>than a type because equally we have no concept of named value sets in
>TTCN-3.

Not this was my comment. The question was: why not to put the text of the note in $ E1.2 in a more precise and exaustive way? and I still have no answer.

Subclause 15.4! of X.680 says the ValueSetTypeAssignment assigns a SUBtype to the notation, which is - taking the current text strictly - is NOT visible from TTCN-3! as subtypes are not mentioned in the note (even if subtypes are types with subset of possible values this may cause ambiguity). Therefore the question could be refrased as: are typereferences using ValueSetTypeAssignments are accessible or not? (you should have noticed my remark in my comment saying "Note that subtypes and value sets are semantically equal, differs syntactically only.").

Please note, such ambiguity exists also in other cases, e.g. notation for the object class field type, information from objects , object sets etc., where I can not reference in TTCN-3 a type from a fixed type value (set) field of an information object class, or a type from the type field of an information object etc.

Please note, this is a real problem as e.g. types defined via a type field of an information object class shall be coded in PER as open types!. So INTEGER is not just the same as myObject.&Argument, where the type field &Argument resolves to the ASN.1 type INTEGER. Therefore myObject.&Argument should not be just mapped into the TTCN-3 type integer but according to the current text (or my reading of it) it simply does.

Named value sets: my understanding is, that ASN.1 types is a superset of TTCN-3 types and in this case it is not clear why named value( set)s can not be included into this superset.

>
>Error Report 18
>===============
>
>The importance of ASN.1 is certainly shared by STF187, but I
>cannot quite
>understand some of the points you are
>making. Information objects may not be imported. True. But
>this in no way
>means that ASN.1 and TTCN
>types cannot be mixed (also though parameterisation)) the only
>restriction
>is that placed on the entire
>TTCN-3 language namely the type system is resolvable at
>compile time (i.e.
>every parameterised type
>must have an actual parameter at compile time)

I agree with your explanation, I will think if any text change should be proposed to avoid possible ambiguity.

>
>Error Report 19
>===============
>
>Section D.1.4 is trying to give initial guidance on what a message
>definition might look like in ASN.1
>(it is also the basis of all the following sections). The
>point about the
>implied limitation of types
>is well made and will be corrected.
>
>Error Report 20
>===============
>
>This point has been clarified in the latest standard in line
>with the ASN.1
>standardisation group.
>
>BR Colin.
>
>
>
>

---

End Forwarded Message

---

>
>
>============================================
>Csaba Koppány
>Ericsson Communications Systems Hungary Lim.
>tel: +36 1 437-7930; fax: +36 1 437-7767
>e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>============================================
>
>

<>