ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0002150 | Part 01: TTCN-3 Core Language | New Feature | public | 15-10-2007 13:12 | 25-04-2008 14:10

Reporter | Gyorgy Rethy |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v3.4.1 (published 2008-09) | Fixed in Version | v3.4.1 (published 2008-09) |
Clause Reference(s) | Annex C
Source (company - Author) |

Summary | 0002150: Encoder/Decoder Access

Description

Although this can be done by using an external function, we prefer this to be added to the TTCN3 specification as a built in function. This will provide compiler independency, reduce maintenance and reduce the number of external functions required.
function msg_decode(in bitstring p_EncodedMsg, in anytype p_ExpectedType) return anytype
Parameters:
p_EncodedMsg: Bitstring of the message to be decoded
p_ExpectedType: anytype having a dummy of the expected type assigned
returns an anytype having the decoded message assigned
(alternatively the 2nd parameter may be inout)
function msg_encode(in anytype p_AnyType) return bitstring
Parameters:
p_AnyType: anytype having assigned the massage to be encoded
returns bitstring of the encoded message
Problem:
Different compilers may handle assignments to/from anytype in mutually exclusive different ways
Example:
type record MyRecordType {
integer Int,
boolean Bool
};
function MyTest() {
var bitstring var_Bitstring1 := '010101'B;
var bitstring var_Bitstring2;
var MyRecordType var_MyRecord;
var anytype var_Any := {MyRecordType := var_MyRecord};
var_Any := msg_decode(var_Bitstring1, var_Any);
var_MyRecord := var_Any.MyRecordType;
var_Bitstring2 := msg_encode({MyRecordType := var_MyRecord});
}

Steps To Reproduce |

Additional Information

Add the predefined functions below to TTCN-3 core language.
NOTE: Using bitstring type for encoded messages in 3GPP examples need clarification; all known message encodings are producing integer number of octets, in our practice never bitstring or hexstring was used to treat encoded messages.
Simple message encoding
msg_encode(in any type p_msg) return octetstring;
msg_encode(in any type p_msg) return charstring;
These predefined functions have one in value parameter, which shall contain the TTCN-3 value to be encoded. The encoded message is obtained in the return value of the function. This enables using this type of encoding function directly i.e. in sending operations or at the right hand side of assignments.
NOTE: Some encoded messages may contain universal charstring characters; these are stored on 1 to 4 charstring positions in the encoded message (depending on universal charstring character set and encoding). It is supposed that the encoding rule allows identifying these positions (for decoding).
Please note the following:
ï‚§ The type of the message encoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the actual in parameterâ€™s type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module where the predefine function is used).
Fast message encoding
msg_encode(in any type p_msg, out octetstring p_encMsg);
msg_encode(in any type p_msg, out charstring p_encMsg);
These predefined functions differ from the simple encode functions in that they have two value parameters: the first is an in parameter and it shall contain the TTCN-3 value to be encoded. The encoded message is returned in the second, out parameter of the function. These functions cannot directly be used i.e. in sending operations or right hand side of assignments, but allows higher runtime performance than the simple encoding functions.
NOTE: Some encoded messages may contain universal charstring characters; these are not handled separately as they also can be stored on 1 to 4 charstring positions (depending on universal charstring character set and encoding).
Please note the following:
ï‚§ The type of the message encoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the actual in parameterâ€™s type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module the predefine function is used).
Simple message decoding
msg_decode(in octetstring p_encMsg, in charstring p_type) return any type;
msg_decode(in charstring p_encMsg, in charstring p_type) return any type;
These predefined functions have two in value parameters: the first, p_encMsg shall be used to pass the encoded message to the function and the second, p_type denotes the type hypothesis, based on which message decoding is attempted. The decoded message is obtained in the return value of the function.
NOTE: Encoded messages containing universal charstring characters shall be converted to charstring values before calling this predefined function (i.e. universal charstring characters shall be stored on 1 to 4 charstring-s); it is supposed that the encoding rule allows identifying positions of universal charstring characters during decoding.
Please note the following:
ï‚§ The type of the message decoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the type denoted by p_type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module the predefine function is used).
ï‚§ Message decoding failure results dynamic test case error (i.e. the REAL type of the message MUST be know apriori and p_encMsg MUST contain exactly one complete message).
Fast message decoding
msg_decode(in octetstring p_encMsg, out any type p_msg, in charstring p_type)
return integer;
msg_decode(in charstring p_encMsg, out any type p_msg, in charstring p_type)
return integer;
These predefined functions differ from simple decoding functions in that they have three value parameters and an integer return value. The first parameter, in parameter p_encMsg, shall be used to pass the encoded message to the function. The TTCN-3 value representing the decoded message is returned in second, out parameter p_msg. The third, in parameter p_type, denotes the type hypothesis, based on which message decoding is attempted. The returned integer value contains the result of the decoding as:
â€¢ 0 (OK). Decoding was successful; the result is stored in the out parameter.
â€¢ 1 (NOT_MY_TYPE). Decoding was unsuccessful because the input parameter does not contain a valid message of type p_type. The content of out parameter is undefined.
NOTE: The error code is returned as an integer value for forward compatibility: it allows extending the list of error symptoms in the future. This is also aligns the return value type with the sliding message decoding predefined functions.
NOTE: Encoded messages containing universal charstring characters shall be converted to charstring before calling this predefined function (i.e. universal charstring characters shall be stored on 1 to 4 charstring-s); it is supposed that the encoding rule allows identifying positions of universal charstring characters.
Please note the following:
ï‚§ The type of the message decoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the type denoted by p_type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module the predefine function is used).
ï‚§ Message decoding result shall always be checked, as in case of decode failure the content of p_msg is undefined and would cause dynamic test case error with high probability (or even worth, a false test result).
Sliding message decoding
msg_decode_slide(inout octetstring p_encMsg, out any type p_msg,
in charstring p_type) return integer;
msg_decode_slide (inout charstring p_encMsg, out any type p_msg
in charstring p_type) return integer;
These predefined functions have three value parameters. The first, inout octetstring parameter p_encMsg shall be used to pass the encoded message to the function; when the function returns, it gives back the whole, part or nothing of the octetstring value passed to it in p_encMsg (see details below). The TTCN-3 value representing the decoded message is returned in the second, out parameter p_msg. The in value parameter p_type denotes the type hypothesis, based on which message decoding is attempted. The returned integer value contains the result of the decoding as:
â€¢ 0 (OK). Decoding was successful; the result is stored in the out parameter. The decoded message was removed from the beginning of the inout parameter p_encMsg.
â€¢ 1 (NOT_MY_TYPE). Decoding was unsuccessful because the inout parameter p_encMsg does not contain or start with a valid message of type denoted by p_type. The inout parameter p_encMsg remains unchanged. The content of out parameter p_msg is undefined.
â€¢ 2 (INCOMPLETE_MESSAGE). Decoding was unsuccessful because the input stream does not contain a complete message (i.e. the end of the message is missing). The inout parameter p_encMsg remains unchanged. The content of out parameter p_msg is undefined.
NOTE: Encoded messages containing universal charstring characters shall be converted to charstring before calling this predefined function (i.e. universal charstring characters shall be stored on 1 to 4 charstring-s); it is supposed that the encoding rule allows identifying positions of universal charstring characters.
Please note the following:
ï‚§ The type of the message decoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the type denoted by p_type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module the predefine function is used).
ï‚§ Message decoding result shall always be checked as in case of failure the content of p_msg is undefined and would cause dynamic test case error with high probability (or even worth, a false test result).

Tags | No tags attached.
Relationships |

Attached Files

CR_2150_solution.doc (631,808) 04-12-2007 16:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=1200&type=bug
CR_2150_Encoder_Decoder_access_solution_01.doc (498,176) 11-03-2008 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1366&type=bug
CR_2150_Encoder_Decoder_access_solution_02.doc (501,248) 11-03-2008 17:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1368&type=bug
CR_2150_Encoder_Decoder_access_solution_03.doc (469,504) 23-04-2008 16:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1442&type=bug
CR_2150_Encoder_Decoder_access_solution_04.doc (448,512) 23-04-2008 19:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=1449&type=bug
CR_2150_Encoder_Decoder_access_solution_05.doc (448,000) 24-04-2008 17:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=1455&type=bug

Issue History
Date Modified | Username | Field | Change
15-10-2007 13:12 | Gyorgy Rethy | New Issue |
15-10-2007 13:12 | Gyorgy Rethy | Status | new => assigned
15-10-2007 13:12 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
15-10-2007 13:12 | Gyorgy Rethy | Clause Reference(s) | => Annex C
15-10-2007 13:12 | Gyorgy Rethy | Source (company - Author) | =>
15-10-2007 13:14 | Gyorgy Rethy | Additional Information Updated |
18-10-2007 13:46 | Ina Schieferdecker | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:59 | Ina Schieferdecker | Target Version | => Edition 3.3.1 (not yet published)
04-12-2007 16:22 | Thomas DeiÃŸ | File Added: CR_2150_solution.doc |
04-12-2007 16:35 | Thomas DeiÃŸ | Note Added: 0004283 |
07-12-2007 11:07 | Ina Schieferdecker | Target Version | Edition 3.3.1 (not yet published) => Edition 4.1.1 (not yet published)
07-12-2007 11:08 | Ina Schieferdecker | Note Added: 0004419 |
11-03-2008 09:28 | Thomas DeiÃŸ | File Added: CR_2150_Encoder_Decoder_access_solution_01.doc |
11-03-2008 09:30 | Thomas DeiÃŸ | Note Added: 0005195 |
11-03-2008 17:46 | Thomas DeiÃŸ | File Added: CR_2150_Encoder_Decoder_access_solution_02.doc |
11-03-2008 17:51 | Thomas DeiÃŸ | Note Added: 0005203 |
21-04-2008 08:50 | Ina Schieferdecker | Target Version | Edition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
23-04-2008 16:42 | Gyorgy Rethy | Note Added: 0005530 |
23-04-2008 16:42 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Thomas DeiÃŸ
23-04-2008 16:43 | Gyorgy Rethy | File Added: CR_2150_Encoder_Decoder_access_solution_03.doc |
23-04-2008 19:26 | Thomas DeiÃŸ | File Added: CR_2150_Encoder_Decoder_access_solution_04.doc |
23-04-2008 19:28 | Thomas DeiÃŸ | Note Added: 0005543 |
23-04-2008 19:28 | Thomas DeiÃŸ | Assigned To | Thomas DeiÃŸ => Gyorgy Rethy
24-04-2008 10:22 | Gyorgy Rethy | Note Added: 0005548 |
24-04-2008 10:22 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
24-04-2008 17:26 | Thomas DeiÃŸ | File Added: CR_2150_Encoder_Decoder_access_solution_05.doc |
24-04-2008 17:27 | Thomas DeiÃŸ | Note Added: 0005561 |
25-04-2008 14:10 | Ina Schieferdecker | Status | assigned => closed
25-04-2008 14:10 | Ina Schieferdecker | Resolution | open => fixed
25-04-2008 14:10 | Ina Schieferdecker | Fixed in Version | => Edition 3.4.1 (not yet published)

Notes

(0004283)
Thomas DeiÃŸ
04-12-2007 16:35

encode and decode builtin functions added as wrappers for the TCI functions encode and decode. Only bitstrings used as types for encoded values (agreed in 1st STF session).

(0004419)
Ina Schieferdecker
07-12-2007 11:08

This CR is not that urgent for 3GPP - external functions can be used instead.

(0005195)
Thomas DeiÃŸ
11-03-2008 09:30

Solution proposal. Two predefined functions (names to be discussed), allow to retrieve amount of consumed bits in decoding. Otherwise close to the TCI functions encode/decode. For discussion of names: 'encode' is used already as keyword in the context of attributes. So far, the names of predefined functions have not been keywords.

(0005203)
Thomas DeiÃŸ
11-03-2008 17:51

STF349, Thomas: Solution proposal updated:
- simple reference to TCI operations might not be sufficient, as the codecs might change throughout execution. For encode, refer to the time of executing the operation. for decode this is more problematic and not mentioned.
- return value of decode changed be a return code instaed of the amount of bits consumed.
- possibility that RTS might not raise an error when encoding or decoding mentioned. This is out of scope of the standard.

(0005530)
Gyorgy Rethy
23-04-2008 16:42

In file CR_2150_Encoder_Decoder_access_solution_03.doc: as we discussed, I have copied the text to the newest standard version; hence I added comments to most of my changes (except trivial editorial).

(0005543)
Thomas DeiÃŸ
23-04-2008 19:28

clean up of the editorial changes. Name proposal: encvalue, decvalue 2nd parameter of decvalue changed from out to inout. Otherwise there would be a successful function call, where an out parameter is undefined afterwards.

(0005548)
Gyorgy Rethy
24-04-2008 10:22

The version 04 (provided by Thomas) is reviewed by me; it is an agreed version between me and Thomas.

(0005561)
Thomas DeiÃŸ
24-04-2008 17:27

2nd parameter of decvalue changed to 'out' (instead 'inout'). Definition in case of unsuccessful behaviour slightly revised.