ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007694 | Part 06: TTCN-3 Control Interface | Technical | public | 24-07-2017 10:16 | 02-01-2018 12:34

Reporter | Martin Hauch |
Assigned To | Tomas Urban |
Priority | high | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version |  |
Clause Reference(s) | Encode/Decode handling TCI-interface 7.3.2.2.1 ff
Source (company - Author) | Devoteam, Martin Hauch

Summary | 0007694: dynamic encoding (usage of statement port.setencode(type,"EncodingRule1");

Description

With introduction of multiple encoding rules and the setencode-statement the following problem for tci-Codec interface has to be solved:
The information about the encoding-rule, which should be used is not available for the tci-interface (Chapter 7.3.2.2.2 in document ETSI ES 201 873-6 V4.9.1 (2017-05))! The interface description encode(in Value value) does not provide any information about the encoding set for the type of this value on the port.
The same problem is present for decode (Chapter 7.3.2.2.1)!
In a similar way this also concerns the TTCN-3 predefined functions encvalue, encvalue_unichar, decvalue, decvalue_unichar and the tci-codec interface functions encodeValue and decodeValue ( Chapter 7.3.2.2.3f).

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7694-v1.docx (204,639) 25-07-2017 16:34 http://oldforge.etsi.org/mantis/file_download.php?file_id=3655&type=bug CR7694-v2.docx (205,136) 26-07-2017 08:50 http://oldforge.etsi.org/mantis/file_download.php?file_id=3658&type=bug

Issue History
Date Modified | Username | Field | Change
24-07-2017 10:16 | Martin Hauch | New Issue |
24-07-2017 14:08 | Jens Grabowski | Assigned To | => Tomas Urban
24-07-2017 14:08 | Jens Grabowski | Status | new => assigned
24-07-2017 14:11 | Jens Grabowski | Note Added: 0014736 |
24-07-2017 16:50 | Tomas Urban | Note Added: 0014744 |
25-07-2017 07:32 | Martin Hauch | Note Added: 0014745 |
25-07-2017 15:46 | Tomas Urban | Note Added: 0014756 |
25-07-2017 16:34 | Tomas Urban | File Added: CR7694-v1.docx |
25-07-2017 16:35 | Tomas Urban | Note Added: 0014761 |
25-07-2017 16:35 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
25-07-2017 16:35 | Tomas Urban | Status | assigned => confirmed
26-07-2017 08:48 | Jacob Wieland - Spirent | Note Added: 0014766 |
26-07-2017 08:49 | Jacob Wieland - Spirent | Note Added: 0014767 |
26-07-2017 08:49 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
26-07-2017 08:49 | Jacob Wieland - Spirent | Status | confirmed => assigned
26-07-2017 08:50 | Tomas Urban | File Added: CR7694-v2.docx |
26-07-2017 08:51 | Tomas Urban | Note Added: 0014768 |
26-07-2017 08:51 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
26-07-2017 08:51 | Tomas Urban | Status | assigned => confirmed
26-07-2017 09:23 | Jacob Wieland - Spirent | Note Added: 0014774 |
26-07-2017 09:23 | Jacob Wieland - Spirent | Status | confirmed => resolved
26-07-2017 09:23 | Jacob Wieland - Spirent | Resolution | open => fixed
26-07-2017 09:23 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
26-07-2017 09:24 | Jacob Wieland - Spirent | Project | TTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
02-01-2018 12:34 | Tomas Urban | Note Added: 0014982 |
02-01-2018 12:34 | Tomas Urban | Status | resolved => closed

Notes

(0014736)
Jens Grabowski
24-07-2017 14:11

To be checked how the different tools (Jacob, Kristof) interpret this feature.

(0014744)
Tomas Urban
24-07-2017 16:50

Dear Martin,
It is correct that the encode and decode operations do not contain information on the selected encoding (and related variants) in a dedicated parameter. However, this information is available in the value (encode) or decodingHypothesis parameters (decode). When generating the TCI Type and Value instances, the TE shall take into account all previous setencode calls and the context from which the codec operation is called and pass such a Value or Type instance to the TCI that contains only the selected encoding and related variants.
Example:
type charstring MyString with { encode "binary" encode "text" }
....
p.setencode(MyString, "binary");
p.receive(MyString:?);
// at this point, TCI decode is called
// if the user calls decodingHypothesis.getTypeEncoding, the returned value will be "binary"
p.setencode(MyString, "text");
p.receive(MyString:?);
// at this point, TCI decode is called again
// however, if the user calls decodingHypothesis.getTypeEncoding, the returned value will be "text" this time
enc_value(MyString:"abc");
// inside the TCI encode operation, the value.getValueEncoding call will return "binary<CR><LF>text"
// because the dynamic_encoding parameter is not used and no self.setencode call has been made so far
Could you please say if the provided explanation is satisfactory? If there are any questions, please feel free to ask.

(0014745)
Martin Hauch
25-07-2017 07:32

Dear Thomas,
I do not agree to this. It is possible that for the same type various encoding-types are active in parallel.
p1.setencode(MyString,"binary");
p2.setencode(MyString,"text");
p3.setencode(MyString,"something else");
As far as I understand the TCI-interface the method getTypeEncoding() returns type encoding as defined in the TTCN-3 module, means encode-attributes, that belong to the type e.g.:
with { encode "binary"; encode "text"} getTypeEncoding should return always "binary<CR><LF>text" as it is the information, that belongs to the type and this information is independent from dynamic setencode-statements!
Also if the interleave-statement is used or there are parallel test-components using the same types, the same type may be used in parallel with different encoding-rules. In my opinion an extra parameter representing the dynamic setencode-settings is necessary. The dynamic setencode information belongs to the port or component, not to the type. So you could define an interface function like
String getDyanmicEncodingDescription(EncodingSettings setEncodeSettings,Type type)
Another point should be clarified:
p1.setencode(MyString,"binary");
self.setencode(MyString,"text");
/* which encoding is to be used for p1.send(Mystring:"...");
does self.setencode() overwrite port.setencode()?
does self.setencode() only overwrite type encoding from p1.setencode or
are all type encodings of p1.setencode() calls deleted and only the
encodings of self.setencode() are valid? */

(0014756)
Tomas Urban
25-07-2017 15:46

The intended way of using multiple encodings is as I described above, i.e. the TCI Type instance doesn't have to be related to the TTCN-3 type definition in the source code. Instead, the TE might create an anonymous TCI Type instance with different attributes according to the context from which the TCI call is made. We will rephrase the TCI description to explain this in detail.
This principle is already used in several places of TTCN-3, e.g. when a type is imported to two different modules with different attributes or when a receive statement uses templates of the same type but with different attributes.
The solution you propose has several drawbacks:
1. Adding the additional parameter(s) to the existing methods is not possible because of backwards compatibility.
2. Eventual new methods for types with multiple encodings:
a. Make the creation of the codec more complicated
b. Require update of existing codec so that they can be compiled with the new TCI
c. Should contain several (more or less) mandatory calls to get the actual encoding
3. There will still be situation when more encodings are possible for the same type (e.g. the case with two templates).
As regards the p1.setencode call followed by self.setencode, it will indeed override the encoding setting for p1, because the self.setencode call is valid for all communication operations of the current component (including the ones made from p1).

(0014761)
Tomas Urban
25-07-2017 16:35

Please check the update of the TCI standard.

(0014766)
Jacob Wieland - Spirent
26-07-2017 08:48

other than the one missing 'variant' word before 'encoding attribute' for getTypeEncodingVariant, it's fine

(0014767)
Jacob Wieland - Spirent
26-07-2017 08:49

please add the missing word

(0014768)
Tomas Urban
26-07-2017 08:51

Missing word added. Please check.

(0014774)
Jacob Wieland - Spirent
26-07-2017 09:23

fine with me

(0014982)
Tomas Urban
02-01-2018 12:34

Implemented in draft V4.9.2