Hello all,

Antti and I came across a question that we could not answer with the TTCN-3 standards and therefore would like to bring to a wider audience.

Assume that a message from the SUT is enqueued at some port and that it is possible to receive messages of various types at this port. I.e. the port is defined as

type port Pt message {
in A;
in B;
in C
}

Let us assume that the enqueued message cannot be decoded as value of type A, but can be decoded as value of both types B and C.

Consider the following alt statement, where b is a template of type B that does _not_ match the received message.
alt {
[] pt.receive(A:?) {/*branch A*/}
[] pt.receive(B:b) {/*branch B*/}
[] pt.receive(C:?) {/*branch C*/}
[else] {/*branch D*/}
}

The question is which of the branches will be taken, is there a unique one or are there several correct ones, leaving room for different implementations by tool vendors?

We could imagine several possible argumentations, but could not find decisive information from the standards. The only relevant parts seem to be the following snippet from the description of decode from part 5:
7.3.2.2.1 decode
...
Constraint This operation shall be called whenever the TE has to decode an encoded value. The TE might decode immediately after reception of a encoded value, or might for performance considerations postpone the decoding until the actual access of the encoded value.
Effect This operations decodes message according to the encoding rules and returns a TTCN-3 value. The decodingHypothesis shall be used to determine whether the encoded value can be decoded. If an encoding rule is not self-sufficient, i.e. if the encoded message does not inherently contain its type decodingHypothesis shall be used. If the encoded value can be decoded without the decoding hypothesis, the distinct null value shall be returned if the type determined from the encoded message is not compatible with the decoding hypothesis.

Now the different argumentations:
1) The enqueued value is repeatedly decoded in the order of the templates in the alternatives and until the decoded value could be matched successfully. Here this means that it is first attempted without success to decode the message as a value of type A. Then it is successfully attempted to decode the message as value of type B, but this does not match the template. Hence the execution would continue with decoding the message as value of type C, this could be received and branch C would be taken.
2) One of the possible types is chosen arbitrarily (randomly, or from the order of types in the port definition) and the enqueued message is decoded as a value of this type. Independent of whether this is successful or not, there will be no further decoding attempt. Let's assume the type A is chosen, here there the encoded value could not be decoded successfully as value of type A. Therefore, branch A cannot be taken. And as there are no further decoding attempts, neither the branches B nor C can be taken, and execution will end up in branch D.
3) This is a variant of case 1): The enqueued value is repeatedly decoded until it can be successfully decoded. In our case, there would be first an unsuccessful attempt to decode the message as value of type A, then there would be a successful attempt to decode the message as value of type B. But the template does not match and the next alternative has to be tried. But as the message has been successfully decoded there will be no further decoding attempt as value of type C, therefore the template would not match and finally branch D would be taken.
4) ... And there might be even more ...

As I understood TTCN-3, case 1) describes what should happen. No assumptions about uniqueness of encodings are made, this is just the semantics that is least depending on the way how the TTCN-3 is written. It is only the order of the alternatives and the types of the templates that have to be used. But as said, the standards do not give a clear statement here.

Note that this question is independent of whether decoding is done immediately as part of enqueueing or as part of the receive statement or sometime in between.

Did we overlook something in the standards, or is that actually an open question. In the latter case it would be good to know whether this is intentionally left open or whether this should be clarified.

Best regards

Thomas

---

| Thomas Deiß, Nokia Research Center Street address: |
| P.O. Box 101823 Meesmannstrasse 103 |
| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
| Phone: +49 234 984 2217 (int. 8272217) |
| Mobile: +49 163 984 2217 |
| Fax: +49 234 984 3491 (int. 8273491) |
| E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

Hello Thomas,

Could you give a reference to an example protocol or service
specification where the same message can be decoded in two
different ways? What would be the use of decoding the same
message in two different ways? As B and C.

Best regards,
Vesa-Matti

Thomas Deiss wrote:
> Hello all,
>
> Antti and I came across a question that we could not answer with the TTCN-3 standards and therefore would like to bring to a wider audience.
>
> Assume that a message from the SUT is enqueued at some port and that it is possible to receive messages of various types at this port. I.e. the port is defined as
>
> type port Pt message {
> in A;
> in B;
> in C
> }
>
> Let us assume that the enqueued message cannot be decoded as value of type A, but can be decoded as value of both types B and C.
>
> Consider the following alt statement, where b is a template of type B that does _not_ match the received message.
> alt {
> [] pt.receive(A:?) {/*branch A*/}
> [] pt.receive(B:b) {/*branch B*/}
> [] pt.receive(C:?) {/*branch C*/}
> [else] {/*branch D*/}
> }
>
> The question is which of the branches will be taken, is there a unique one or are there several correct ones, leaving room for different implementations by tool vendors?
>
> We could imagine several possible argumentations, but could not find decisive information from the standards. The only relevant parts seem to be the following snippet from the description of decode from part 5:
> 7.3.2.2.1 decode
> ...
> Constraint This operation shall be called whenever the TE has to decode an encoded value. The TE might decode immediately after reception of a encoded value, or might for performance considerations postpone the decoding until the actual access of the encoded value.
> Effect This operations decodes message according to the encoding rules and returns a TTCN-3 value. The decodingHypothesis shall be used to determine whether the encoded value can be decoded. If an encoding rule is not self-sufficient, i.e. if the encoded message does not inherently contain its type decodingHypothesis shall be used. If the encoded value can be decoded without the decoding hypothesis, the distinct null value shall be returned if the type determined from the encoded message is not compatible with the decoding hypothesis.
>
> Now the different argumentations:
> 1) The enqueued value is repeatedly decoded in the order of the templates in the alternatives and until the decoded value could be matched successfully. Here this means that it is first attempted without success to decode the message as a value of type A. Then it is successfully attempted to decode the message as value of type B, but this does not match the template. Hence the execution would continue with decoding the message as value of type C, this could be received and branch C would be taken.
> 2) One of the possible types is chosen arbitrarily (randomly, or from the order of types in the port definition) and the enqueued message is decoded as a value of this type. Independent of whether this is successful or not, there will be no further decoding attempt. Let's assume the type A is chosen, here there the encoded value could not be decoded successfully as value of type A. Therefore, branch A cannot be taken. And as there are no further decoding attempts, neither the branches B nor C can be taken, and execution will end up in branch D.
> 3) This is a variant of case 1): The enqueued value is repeatedly decoded until it can be successfully decoded. In our case, there would be first an unsuccessful attempt to decode the message as value of type A, then there would be a successful attempt to decode the message as value of type B. But the template does not match and the next alternative has to be tried. But as the message has been successfully decoded there will be no further decoding attempt as value of type C, therefore the template would not match and finally branch D would be taken.
> 4) ... And there might be even more ...
>
> As I understood TTCN-3, case 1) describes what should happen. No assumptions about uniqueness of encodings are made, this is just the semantics that is least depending on the way how the TTCN-3 is written. It is only the order of the alternatives and the types of the templates that have to be used. But as said, the standards do not give a clear statement here.
>
> Note that this question is independent of whether decoding is done immediately as part of enqueueing or as part of the receive statement or sometime in between.
>
> Did we overlook something in the standards, or is that actually an open question. In the latter case it would be good to know whether this is intentionally left open or whether this should be clarified.
>
> Best regards
>
> Thomas
>
>
>

---

> | Thomas Deiß, Nokia Research Center Street address: |
> | P.O. Box 101823 Meesmannstrasse 103 |
> | D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
> | Phone: +49 234 984 2217 (int. 8272217) |
> | Mobile: +49 163 984 2217 |
> | Fax: +49 234 984 3491 (int. 8273491) |
> | E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>

---

>

Hi Thomas, hi Antti,

I do not have the standards at hand, but I would strongly support your view of 1) being the that 'it should be done'. A failed match or decoding attempt should not have a side effect that prevents subsequent successful decoding or matching. As you have correctly mentioned, there are nowhere requirements that encoding should be injective over all values/types at any given port.

Cheers

Stephan

>

---

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 Thomas Deiss
> Sent: 19 August 2005 15:08
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Decoding of messages
>
> Hello all,
>
> Antti and I came across a question that we could not answer
> with the TTCN-3 standards and therefore would like to bring
> to a wider audience.
>
> Assume that a message from the SUT is enqueued at some port
> and that it is possible to receive messages of various types
> at this port. I.e. the port is defined as
>
> type port Pt message {
> in A;
> in B;
> in C
> }
>
> Let us assume that the enqueued message cannot be decoded as
> value of type A, but can be decoded as value of both types B and C.
>
> Consider the following alt statement, where b is a template
> of type B that does _not_ match the received message.
> alt {
> [] pt.receive(A:?) {/*branch A*/}
> [] pt.receive(B:b) {/*branch B*/}
> [] pt.receive(C:?) {/*branch C*/}
> [else] {/*branch D*/}
> }
>
> The question is which of the branches will be taken, is there
> a unique one or are there several correct ones, leaving room
> for different implementations by tool vendors?
>
> We could imagine several possible argumentations, but could
> not find decisive information from the standards. The only
> relevant parts seem to be the following snippet from the
> description of decode from part 5:
> 7.3.2.2.1 decode
> ...
> Constraint This operation shall be called whenever the TE
> has to decode an encoded value. The TE might decode
> immediately after reception of a encoded value, or might for
> performance considerations postpone the decoding until the
> actual access of the encoded value.
> Effect This operations decodes message according to
> the encoding rules and returns a TTCN-3 value. The
> decodingHypothesis shall be used to determine whether the
> encoded value can be decoded. If an encoding rule is not
> self-sufficient, i.e. if the encoded message does not
> inherently contain its type decodingHypothesis shall be used.
> If the encoded value can be decoded without the decoding
> hypothesis, the distinct null value shall be returned if the
> type determined from the encoded message is not compatible
> with the decoding hypothesis.
>
> Now the different argumentations:
> 1) The enqueued value is repeatedly decoded in the order of
> the templates in the alternatives and until the decoded value
> could be matched successfully. Here this means that it is
> first attempted without success to decode the message as a
> value of type A. Then it is successfully attempted to decode
> the message as value of type B, but this does not match the
> template. Hence the execution would continue with decoding
> the message as value of type C, this could be received and
> branch C would be taken.
> 2) One of the possible types is chosen arbitrarily (randomly,
> or from the order of types in the port definition) and the
> enqueued message is decoded as a value of this type.
> Independent of whether this is successful or not, there will
> be no further decoding attempt. Let's assume the type A is
> chosen, here there the encoded value could not be decoded
> successfully as value of type A. Therefore, branch A cannot
> be taken. And as there are no further decoding attempts,
> neither the branches B nor C can be taken, and execution will
> end up in branch D.
> 3) This is a variant of case 1): The enqueued value is
> repeatedly decoded until it can be successfully decoded. In
> our case, there would be first an unsuccessful attempt to
> decode the message as value of type A, then there would be a
> successful attempt to decode the message as value of type B.
> But the template does not match and the next alternative has
> to be tried. But as the message has been successfully decoded
> there will be no further decoding attempt as value of type C,
> therefore the template would not match and finally branch D
> would be taken.
> 4) ... And there might be even more ...
>
> As I understood TTCN-3, case 1) describes what should happen.
> No assumptions about uniqueness of encodings are made, this
> is just the semantics that is least depending on the way how
> the TTCN-3 is written. It is only the order of the
> alternatives and the types of the templates that have to be
> used. But as said, the standards do not give a clear statement here.
>
> Note that this question is independent of whether decoding is
> done immediately as part of enqueueing or as part of the
> receive statement or sometime in between.
>
> Did we overlook something in the standards, or is that
> actually an open question. In the latter case it would be
> good to know whether this is intentionally left open or
> whether this should be clarified.
>
> Best regards
>
> Thomas
>
>
>

---

> | Thomas Deiß, Nokia Research Center Street address: |
> | P.O. Box 101823 Meesmannstrasse 103 |
> | D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
> | Phone: +49 234 984 2217 (int. 8272217) |
> | Mobile: +49 163 984 2217 |
> | Fax: +49 234 984 3491 (int. 8273491) |
> | E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>

---

>

Hi Vesa-Matti,

I cannot think of any natural examples where two different protocols would have overlapping encodings, at least not when looking on protocols on the same OSI level.

But consider the example where you are dealing with protocols on different layers of the same stack. Assume an IPv4 test scenario (Stephan Schulz may give his view of how this maps to IPv6), where you first may attempt do decode incoming Ethernet frams messages as UDP packets, and if that fails, as ICMP packets, and if that fails are pure Ethernet frames.

We had a similar example where we were building a tester that deals with malformed messages, where we would have decoders of decreasing strictness, all running on the same port: if a messages failed to decode as a proper message of the protocol, we would attempt to decode it and preserver some of the structure of the message, and if that would also fail, we would decode it purely as an octet string.

Cheers

Stephan
--
Stephan Tobies Software Design Engineer, European Microsoft Innovation Center
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-241-9978439
Mobile: +49-160-5892831
Address: EMIC, Ritterstrasse 23, 52072 Aachen, Germany

>

---

Ursprüngliche Nachricht

---

> Von: 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.] Im Auftrag von
> Vesa-Matti Puro
> Gesendet: Freitag, 19. August 2005 18:30
> An: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Betreff: Re: Decoding of messages
>
> Hello Thomas,
>
> Could you give a reference to an example protocol or service
> specification where the same message can be decoded in two
> different ways? What would be the use of decoding the same
> message in two different ways? As B and C.
>
> Best regards,
> Vesa-Matti
>
> Thomas Deiss wrote:
> > Hello all,
> >
> > Antti and I came across a question that we could not answer
> with the TTCN-3 standards and therefore would like to bring
> to a wider audience.
> >
> > Assume that a message from the SUT is enqueued at some port
> and that
> > it is possible to receive messages of various types at this
> port. I.e.
> > the port is defined as
> >
> > type port Pt message {
> > in A;
> > in B;
> > in C
> > }
> >
> > Let us assume that the enqueued message cannot be decoded
> as value of type A, but can be decoded as value of both types B and C.
> >
> > Consider the following alt statement, where b is a template
> of type B that does _not_ match the received message.
> > alt {
> > [] pt.receive(A:?) {/*branch A*/}
> > [] pt.receive(B:b) {/*branch B*/}
> > [] pt.receive(C:?) {/*branch C*/}
> > [else] {/*branch D*/}
> > }
> >
> > The question is which of the branches will be taken, is
> there a unique one or are there several correct ones, leaving
> room for different implementations by tool vendors?
> >
> > We could imagine several possible argumentations, but could
> not find decisive information from the standards. The only
> relevant parts seem to be the following snippet from the
> description of decode from part 5:
> > 7.3.2.2.1 decode
> > ...
> > Constraint This operation shall be called whenever the TE
> has to decode an encoded value. The TE might decode
> immediately after reception of a encoded value, or might for
> performance considerations postpone the decoding until the
> actual access of the encoded value.
> > Effect This operations decodes message according to
> the encoding rules and returns a TTCN-3 value. The
> decodingHypothesis shall be used to determine whether the
> encoded value can be decoded. If an encoding rule is not
> self-sufficient, i.e. if the encoded message does not
> inherently contain its type decodingHypothesis shall be used.
> If the encoded value can be decoded without the decoding
> hypothesis, the distinct null value shall be returned if the
> type determined from the encoded message is not compatible
> with the decoding hypothesis.
> >
> > Now the different argumentations:
> > 1) The enqueued value is repeatedly decoded in the order of
> the templates in the alternatives and until the decoded value
> could be matched successfully. Here this means that it is
> first attempted without success to decode the message as a
> value of type A. Then it is successfully attempted to decode
> the message as value of type B, but this does not match the
> template. Hence the execution would continue with decoding
> the message as value of type C, this could be received and
> branch C would be taken.
> > 2) One of the possible types is chosen arbitrarily
> (randomly, or from the order of types in the port definition)
> and the enqueued message is decoded as a value of this type.
> Independent of whether this is successful or not, there will
> be no further decoding attempt. Let's assume the type A is
> chosen, here there the encoded value could not be decoded
> successfully as value of type A. Therefore, branch A cannot
> be taken. And as there are no further decoding attempts,
> neither the branches B nor C can be taken, and execution will
> end up in branch D.
> > 3) This is a variant of case 1): The enqueued value is
> repeatedly decoded until it can be successfully decoded. In
> our case, there would be first an unsuccessful attempt to
> decode the message as value of type A, then there would be a
> successful attempt to decode the message as value of type B.
> But the template does not match and the next alternative has
> to be tried. But as the message has been successfully decoded
> there will be no further decoding attempt as value of type C,
> therefore the template would not match and finally branch D
> would be taken.
> > 4) ... And there might be even more ...
> >
> > As I understood TTCN-3, case 1) describes what should
> happen. No assumptions about uniqueness of encodings are
> made, this is just the semantics that is least depending on
> the way how the TTCN-3 is written. It is only the order of
> the alternatives and the types of the templates that have to
> be used. But as said, the standards do not give a clear
> statement here.
> >
> > Note that this question is independent of whether decoding
> is done immediately as part of enqueueing or as part of the
> receive statement or sometime in between.
> >
> > Did we overlook something in the standards, or is that
> actually an open question. In the latter case it would be
> good to know whether this is intentionally left open or
> whether this should be clarified.
> >
> > Best regards
> >
> > Thomas
> >
> >
> >

---

> > | Thomas Deiß, Nokia Research Center Street address: |
> > | P.O. Box 101823 Meesmannstrasse 103 |
> > | D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
> > | Phone: +49 234 984 2217 (int. 8272217) |
> > | Mobile: +49 163 984 2217 |
> > | Fax: +49 234 984 3491 (int. 8273491) |
> > | E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
> >

---

> >
>

Hello Vesa-Matti,

As for the requested protocol, we have made use of multiple decodings to cope with decoding failures. For a single protocol, we defined at the end three different message types:
1) an abstract definition, as it would be expected
2) a definition resembling a TLV encoding, the fields are kept as octet strings, but field tags and length information became accessible
3) plain octet strings

We first tried to receive the message as a value of the first type, if that could not be done successfully, even with a the most general template for this type, this would correspond to incorrectly encoded value. In that situation we used further alternatives to try and receive the message as a value of the second type. If successful, we gained at least some information about the received value, if this has not been successful, in a last attempt, we received the message as an octetstring, which allowed to at least get rid of the message from the message queue.

In this case we relied on the assumption, that for each alternative a different attempt to decode would be done, depending on the type used in the template.

I hope that this gives some idea, where this could be used. Although I would urge everybody to make sure that messages can be decoded uniquely to the abstract types.

Best regards

Thomas


>

---

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 ext
>Vesa-Matti Puro
>Sent: Friday, 19 August, 2005 18:30
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Decoding of messages
>
>Hello Thomas,
>
>Could you give a reference to an example protocol or service
>specification where the same message can be decoded in two
>different ways? What would be the use of decoding the same
>message in two different ways? As B and C.
>
>Best regards,
>Vesa-Matti
>
>Thomas Deiss wrote:
>> Hello all,
>>
>> Antti and I came across a question that we could not answer
>with the TTCN-3 standards and therefore would like to bring to
>a wider audience.
>>
>> Assume that a message from the SUT is enqueued at some port and that
>> it is possible to receive messages of various types at this
>port. I.e.
>> the port is defined as
>>
>> type port Pt message {
>> in A;
>> in B;
>> in C
>> }
>>
>> Let us assume that the enqueued message cannot be decoded as
>value of type A, but can be decoded as value of both types B and C.
>>
>> Consider the following alt statement, where b is a template
>of type B that does _not_ match the received message.
>> alt {
>> [] pt.receive(A:?) {/*branch A*/}
>> [] pt.receive(B:b) {/*branch B*/}
>> [] pt.receive(C:?) {/*branch C*/}
>> [else] {/*branch D*/}
>> }
>>
>> The question is which of the branches will be taken, is
>there a unique one or are there several correct ones, leaving
>room for different implementations by tool vendors?
>>
>> We could imagine several possible argumentations, but could
>not find decisive information from the standards. The only
>relevant parts seem to be the following snippet from the
>description of decode from part 5:
>> 7.3.2.2.1 decode
>> ...
>> Constraint This operation shall be called whenever the TE
>has to decode an encoded value. The TE might decode
>immediately after reception of a encoded value, or might for
>performance considerations postpone the decoding until the
>actual access of the encoded value.
>> Effect This operations decodes message according to
>the encoding rules and returns a TTCN-3 value. The
>decodingHypothesis shall be used to determine whether the
>encoded value can be decoded. If an encoding rule is not
>self-sufficient, i.e. if the encoded message does not
>inherently contain its type decodingHypothesis shall be used.
>If the encoded value can be decoded without the decoding
>hypothesis, the distinct null value shall be returned if the
>type determined from the encoded message is not compatible
>with the decoding hypothesis.
>>
>> Now the different argumentations:
>> 1) The enqueued value is repeatedly decoded in the order of
>the templates in the alternatives and until the decoded value
>could be matched successfully. Here this means that it is
>first attempted without success to decode the message as a
>value of type A. Then it is successfully attempted to decode
>the message as value of type B, but this does not match the
>template. Hence the execution would continue with decoding the
>message as value of type C, this could be received and branch
>C would be taken.
>> 2) One of the possible types is chosen arbitrarily
>(randomly, or from the order of types in the port definition)
>and the enqueued message is decoded as a value of this type.
>Independent of whether this is successful or not, there will
>be no further decoding attempt. Let's assume the type A is
>chosen, here there the encoded value could not be decoded
>successfully as value of type A. Therefore, branch A cannot be
>taken. And as there are no further decoding attempts, neither
>the branches B nor C can be taken, and execution will end up
>in branch D.
>> 3) This is a variant of case 1): The enqueued value is
>repeatedly decoded until it can be successfully decoded. In
>our case, there would be first an unsuccessful attempt to
>decode the message as value of type A, then there would be a
>successful attempt to decode the message as value of type B.
>But the template does not match and the next alternative has
>to be tried. But as the message has been successfully decoded
>there will be no further decoding attempt as value of type C,
>therefore the template would not match and finally branch D
>would be taken.
>> 4) ... And there might be even more ...
>>
>> As I understood TTCN-3, case 1) describes what should
>happen. No assumptions about uniqueness of encodings are made,
>this is just the semantics that is least depending on the way
>how the TTCN-3 is written. It is only the order of the
>alternatives and the types of the templates that have to be
>used. But as said, the standards do not give a clear statement here.
>>
>> Note that this question is independent of whether decoding
>is done immediately as part of enqueueing or as part of the
>receive statement or sometime in between.
>>
>> Did we overlook something in the standards, or is that
>actually an open question. In the latter case it would be good
>to know whether this is intentionally left open or whether
>this should be clarified.
>>
>> Best regards
>>
>> Thomas
>>
>>
>>

---

>> | Thomas Deiß, Nokia Research Center Street address: |
>> | P.O. Box 101823 Meesmannstrasse 103 |
>> | D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
>> | Phone: +49 234 984 2217 (int. 8272217) |
>> | Mobile: +49 163 984 2217 |
>> | Fax: +49 234 984 3491 (int. 8273491) |
>> | E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>>

---

>>
>

Hi Vesi-Matti,

one such example is the Media Gateway Controller protocol which has a textual and binary encoding.
But I think this is not what thomas meant.

He meant there is _one_ received message with, e.g., a binary encoding, that could be correctly decoded as two _different_ protocol messages.

Moikka,
stephan



>

---

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 ext Vesa-Matti Puro
> Sent: 19 August, 2005 19:30
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Decoding of messages
>
>
> Hello Thomas,
>
> Could you give a reference to an example protocol or service
> specification where the same message can be decoded in two
> different ways? What would be the use of decoding the same
> message in two different ways? As B and C.
>
> Best regards,
> Vesa-Matti
>
> Thomas Deiss wrote:
> > Hello all,
> >
> > Antti and I came across a question that we could not answer
> with the TTCN-3 standards and therefore would like to bring
> to a wider audience.
> >
> > Assume that a message from the SUT is enqueued at some port
> and that it is possible to receive messages of various types
> at this port. I.e. the port is defined as
> >
> > type port Pt message {
> > in A;
> > in B;
> > in C
> > }
> >
> > Let us assume that the enqueued message cannot be decoded
> as value of type A, but can be decoded as value of both types B and C.
> >
> > Consider the following alt statement, where b is a template
> of type B that does _not_ match the received message.
> > alt {
> > [] pt.receive(A:?) {/*branch A*/}
> > [] pt.receive(B:b) {/*branch B*/}
> > [] pt.receive(C:?) {/*branch C*/}
> > [else] {/*branch D*/}
> > }
> >
> > The question is which of the branches will be taken, is
> there a unique one or are there several correct ones, leaving
> room for different implementations by tool vendors?
> >
> > We could imagine several possible argumentations, but could
> not find decisive information from the standards. The only
> relevant parts seem to be the following snippet from the
> description of decode from part 5:
> > 7.3.2.2.1 decode
> > ...
> > Constraint This operation shall be called whenever the TE
> has to decode an encoded value. The TE might decode
> immediately after reception of a encoded value, or might for
> performance considerations postpone the decoding until the
> actual access of the encoded value.
> > Effect This operations decodes message according to
> the encoding rules and returns a TTCN-3 value. The
> decodingHypothesis shall be used to determine whether the
> encoded value can be decoded. If an encoding rule is not
> self-sufficient, i.e. if the encoded message does not
> inherently contain its type decodingHypothesis shall be used.
> If the encoded value can be decoded without the decoding
> hypothesis, the distinct null value shall be returned if the
> type determined from the encoded message is not compatible
> with the decoding hypothesis.
> >
> > Now the different argumentations:
> > 1) The enqueued value is repeatedly decoded in the order of
> the templates in the alternatives and until the decoded value
> could be matched successfully. Here this means that it is
> first attempted without success to decode the message as a
> value of type A. Then it is successfully attempted to decode
> the message as value of type B, but this does not match the
> template. Hence the execution would continue with decoding
> the message as value of type C, this could be received and
> branch C would be taken.
> > 2) One of the possible types is chosen arbitrarily
> (randomly, or from the order of types in the port definition)
> and the enqueued message is decoded as a value of this type.
> Independent of whether this is successful or not, there will
> be no further decoding attempt. Let's assume the type A is
> chosen, here there the encoded value could not be decoded
> successfully as value of type A. Therefore, branch A cannot
> be taken. And as there are no further decoding attempts,
> neither the branches B nor C can be taken, and execution will
> end up in branch D.
> > 3) This is a variant of case 1): The enqueued value is
> repeatedly decoded until it can be successfully decoded. In
> our case, there would be first an unsuccessful attempt to
> decode the message as value of type A, then there would be a
> successful attempt to decode the message as value of type B.
> But the template does not match and the next alternative has
> to be tried. But as the message has been successfully decoded
> there will be no further decoding attempt as value of type C,
> therefore the template would not match and finally branch D
> would be taken.
> > 4) ... And there might be even more ...
> >
> > As I understood TTCN-3, case 1) describes what should
> happen. No assumptions about uniqueness of encodings are
> made, this is just the semantics that is least depending on
> the way how the TTCN-3 is written. It is only the order of
> the alternatives and the types of the templates that have to
> be used. But as said, the standards do not give a clear
> statement here.
> >
> > Note that this question is independent of whether decoding
> is done immediately as part of enqueueing or as part of the
> receive statement or sometime in between.
> >
> > Did we overlook something in the standards, or is that
> actually an open question. In the latter case it would be
> good to know whether this is intentionally left open or
> whether this should be clarified.
> >
> > Best regards
> >
> > Thomas
> >
> >
> >

---

> > | Thomas Deiß, Nokia Research Center Street address: |
> > | P.O. Box 101823 Meesmannstrasse 103 |
> > | D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
> > | Phone: +49 234 984 2217 (int. 8272217) |
> > | Mobile: +49 163 984 2217 |
> > | Fax: +49 234 984 3491 (int. 8273491) |
> > | E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
> >

---

> >
>

Hi Thomas

See my comments below.

> 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 ext Thomas Deiss
> Sent: 22. elokuuta 2005 9:45
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Decoding of messages
>
> Hello Vesa-Matti,
>
> As for the requested protocol, we have made use of multiple decodings
> to cope with decoding failures. For a single protocol, we defined at
> the end three different message types:
>
> 1) an abstract definition, as it would be expected
>
> 2) a definition resembling a TLV encoding, the fields are kept as
> octet strings, but field tags and length information became accessible
>
> 3) plain octet strings
>
> We first tried to receive the message as a value of the first type, if
> that could not be done successfully, even with a the most general
> template for this type, this would correspond to incorrectly encoded
> value. In that situation we used further alternatives to try and
> receive the message as a value of the second type. If successful, we
> gained at least some information about the received value, if this has
> not been successful, in a last attempt, we received the message as an
> octetstring, which allowed to at least get rid of the message from the
> message queue.

> In this case we relied on the assumption, that for each alternative a
> different attempt to decode would be done, depending on the type used
> in the template.

I believe the situation you describe would work (with an assumption
about decoding attempt order) with the case 3) in which the first
succesful decoding determines the type of the data.


> alt {
> [] pt.receive(A:?) {/*branch A*/}
> [] pt.receive(B:b) {/*branch B*/}
> [] pt.receive(C:?) {/*branch C*/}
> [else] {/*branch D*/}
> }

> 3) This is a variant of case 1): The enqueued value is repeatedly
> decoded until it can be successfully decoded. In our case, there would
> be first an unsuccessful attempt to decode the message as value of
> type A, then there would be a successful attempt to decode the message
> as value of type B. But the template does not match and the next
> alternative has to be tried. But as the message has been successfully
> decoded there will be no further decoding attempt as value of type C,
> therefore the template would not match and finally branch D would be
> taken.

The alt statement for the sitation you describe would be

alt {
[] pt.receive(A:a) {/* A specific*/}
[] pt.receive(A:?) {/* A anything */}
[] pt.receive(TLV:?) {/*TLV kind anything */}
[] pt.receive(octetstring:?) {/* octetstring anything */}
...
[else] {/*branch D*/}
}

This does require, that decoding for type A is tried first, and if
fails, then for TLV, and if fails, then for type octetstring. However
the standard does not say anything how the order in which the the
decoding attempts are done.

If the decoding attempts are done in the order of alternatives listed
in the alt, then the above would work.

Alternatively, if the port pt was defined as

type port Pt message {
in A;
in TLV;
in octetstring
}

and the decoding attempt order is defined by the order in which the
types are listed in the port definition, the execution of the alt
statement would result in the desired behaviour.

Since the standard does not say where the decoding attempt order comes
from , one vendor might choose the alt-order approach, and another one
the port definition approach, and these are incompatible in general.
To the alt-order tool it does not matter at all in which order the
types are defined in the port definition, but for a port-order tool it
matters a lot. Neither of the approaches really violate the current
standard.

I still want to point out that what I have writter is relevant only
when the behaviour of alt is as in case 3, which allows only one
succesful decoding for the received data.

Antti

Hi Vesa-Matti

> Hello Thomas,
>
> Could you give a reference to an example protocol or service
> specification where the same message can be decoded in two
> different ways? What would be the use of decoding the same
> message in two different ways? As B and C.
>
> Best regards,
> Vesa-Matti
>

Within a single protocol, I don't think that one can or want to decode
the same data as two different PDUs of that protocol (unless you are
playing with some kind of bizarre non deterministic protocol that has
escaped from the lab).

I think protocol specifications in general specify PDUs in their
encoded form (i.e. in their transfer syntax form), and they never
speak about how they should be decoded. It is true that protocol
specifications give some kind of field-views of the PDUs, which
specify the order of the fields of the PDUs, and in addition they also
define the rule by which the fields must be encoded when they are sent
over transmission path. I see the field-view as part of the transfer
syntax (since it specifies the relative order of fields), and not as a
representation of an unencoded PDU. To me, the unencoded (or decoded)
message is the form in which the entity that handles the protocol
wants to see the message, i.e., how it wants to represent it internally.
In my point of view, the TTCN-3 types I have defined in a test case
specify how I want to handle or see the data in the test case, and
this may vary between test cases. This is where multiple decodings for
the same message comes from.

With binary based protocols I probably do not need to see the
received message decoded into several different representation formats,
but when when the data is erroneously encodeded I want to represent
this data in some easy to understand format (which can be seen
as a PDU of my error protocol, which is compatible with any PDU of
any of protocol). Someone else than me might want to see the received
data in some other format though.

With text based protocol it is easier to give examples. I might
want to decode a SIP protocol PDU, or a HTML or XML file/PDU as an long
charstring in some cases, or as a structured type in some other cases,
depending on what I am going to do with them and what happens to
be the most convenient. If I received an XML file, I might
be interested in the total length of bytes in it. This information
is not part of XML, but I could decode the page as a structure type
which contains this information. The structure type might contain
only statistical data about the file (how many fields, what are
their lengths, total file length) without its "contents". In another
test I might want decode it as structured type containing
the real contents. Was that a real world example, maybe not :).

Does the tool have to support two different representation formats for
the same data _at the same time_, i.e. does the tool have to support
multiple successful decodings for the same instance of the data, this
question is independent of the above. However, this does affect the
correct interpretation of the alt-example Thomas presented in the first
posting.

Antti

> >

---

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 ext Vesa-Matti Puro
> > Sent: 19 August, 2005 19:30
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Decoding of messages
> >
> >
> > Hello Thomas,
> >
> > Could you give a reference to an example protocol or service
> > specification where the same message can be decoded in two
> > different ways? What would be the use of decoding the same
> > message in two different ways? As B and C.
> >
> > Best regards,
> > Vesa-Matti
> >
> > Thomas Deiss wrote:
> > > Hello all,
> > >
> > > Antti and I came across a question that we could not answer
> > with the TTCN-3 standards and therefore would like to bring
> > to a wider audience.
> > >
> > > Assume that a message from the SUT is enqueued at some port
> > and that it is possible to receive messages of various types
> > at this port. I.e. the port is defined as
> > >
> > > type port Pt message {
> > > in A;
> > > in B;
> > > in C
> > > }
> > >
> > > Let us assume that the enqueued message cannot be decoded
> > as value of type A, but can be decoded as value of both types B and C.
> > >
> > > Consider the following alt statement, where b is a template
> > of type B that does _not_ match the received message.
> > > alt {
> > > [] pt.receive(A:?) {/*branch A*/}
> > > [] pt.receive(B:b) {/*branch B*/}
> > > [] pt.receive(C:?) {/*branch C*/}
> > > [else] {/*branch D*/}
> > > }
> > >
> > > The question is which of the branches will be taken, is
> > there a unique one or are there several correct ones, leaving
> > room for different implementations by tool vendors?
> > >
> > > We could imagine several possible argumentations, but could
> > not find decisive information from the standards. The only
> > relevant parts seem to be the following snippet from the
> > description of decode from part 5:
> > > 7.3.2.2.1 decode
> > > ...
> > > Constraint This operation shall be called whenever the TE
> > has to decode an encoded value. The TE might decode
> > immediately after reception of a encoded value, or might for
> > performance considerations postpone the decoding until the
> > actual access of the encoded value.
> > > Effect This operations decodes message according to
> > the encoding rules and returns a TTCN-3 value. The
> > decodingHypothesis shall be used to determine whether the
> > encoded value can be decoded. If an encoding rule is not
> > self-sufficient, i.e. if the encoded message does not
> > inherently contain its type decodingHypothesis shall be used.
> > If the encoded value can be decoded without the decoding
> > hypothesis, the distinct null value shall be returned if the
> > type determined from the encoded message is not compatible
> > with the decoding hypothesis.
> > >
> > > Now the different argumentations:
> > > 1) The enqueued value is repeatedly decoded in the order of
> > the templates in the alternatives and until the decoded value
> > could be matched successfully. Here this means that it is
> > first attempted without success to decode the message as a
> > value of type A. Then it is successfully attempted to decode
> > the message as value of type B, but this does not match the
> > template. Hence the execution would continue with decoding
> > the message as value of type C, this could be received and
> > branch C would be taken.
> > > 2) One of the possible types is chosen arbitrarily
> > (randomly, or from the order of types in the port definition)
> > and the enqueued message is decoded as a value of this type.
> > Independent of whether this is successful or not, there will
> > be no further decoding attempt. Let's assume the type A is
> > chosen, here there the encoded value could not be decoded
> > successfully as value of type A. Therefore, branch A cannot
> > be taken. And as there are no further decoding attempts,
> > neither the branches B nor C can be taken, and execution will
> > end up in branch D.
> > > 3) This is a variant of case 1): The enqueued value is
> > repeatedly decoded until it can be successfully decoded. In
> > our case, there would be first an unsuccessful attempt to
> > decode the message as value of type A, then there would be a
> > successful attempt to decode the message as value of type B.
> > But the template does not match and the next alternative has
> > to be tried. But as the message has been successfully decoded
> > there will be no further decoding attempt as value of type C,
> > therefore the template would not match and finally branch D
> > would be taken.
> > > 4) ... And there might be even more ...
> > >
> > > As I understood TTCN-3, case 1) describes what should
> > happen. No assumptions about uniqueness of encodings are
> > made, this is just the semantics that is least depending on
> > the way how the TTCN-3 is written. It is only the order of
> > the alternatives and the types of the templates that have to
> > be used. But as said, the standards do not give a clear
> > statement here.
> > >
> > > Note that this question is independent of whether decoding
> > is done immediately as part of enqueueing or as part of the
> > receive statement or sometime in between.
> > >
> > > Did we overlook something in the standards, or is that
> > actually an open question. In the latter case it would be
> > good to know whether this is intentionally left open or
> > whether this should be clarified.
> > >
> > > Best regards
> > >
> > > Thomas
> > >
> > >
> > >

---

> > > | Thomas Deiß, Nokia Research Center Street address: |
> > > | P.O. Box 101823 Meesmannstrasse 103 |
> > > | D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
> > > | Phone: +49 234 984 2217 (int. 8272217) |
> > > | Mobile: +49 163 984 2217 |
> > > | Fax: +49 234 984 3491 (int. 8273491) |
> > > | E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
> > >

---

> > >
> >
>