Subject: M2UA: TTC Data message

From: Joyce Archibald <[email-masked]>
Date: Tue, 27 Feb 2001 14:00:27 +0000

Hi All,

The TTC Protocol Data parameter (tag = 0xf) has been included, in order
to support the Japanese TTC variant of the Protocol Data Unit. Fine.

I don't see why it is necessary to add the message type 'TTC Data',
since the Data message could be defined to contain either parameter.
(i.e. a Mandatory Choice, to use ASN.1 terms)

The Data Retrieval Indication and Data Retrieval Indication Complete
messages, presumably can also carry either Protocol Data or TTC Protocol
Data.

May I suggest that tags should be used to identify the parameter and
therefore should not change depending on which message they are in.

Thus the Data, Data Retrieval Indication and Data Retrieval Indication
Complete messages could each contain, either Protocol Data (tag = 0xe)
or TTC Protocol Data (tag = 0xf), but not both.

The 'TTC Data' message and 'PDU from retransmit queue' parameter would
not be required.

Similarly the tag 0x10 should identify the State parameter regardless of
whether it appears in the State Request or State Confirm message. The
Result field in the State Confirm message could be a separate parameter,
possibly using tag 0x16.

Regards,

Joyce

---

From: Ken Morneault <[email-masked]>
Date: Mon, 05 Mar 2001 13:34:28 -0500

I don't think this made it to the list the first time.

>Date: Mon, 05 Mar 2001 08:14:50 -0500
>To: [email-masked]
>From: Ken Morneault <[email-masked]>
>Subject: Re: M2UA: TTC Data message
>Cc: [email-masked]
>
>
>
>Joyce,
>
>At the last meeting, there was a strong desire to have a separate
>message type.  However, I agree that your approach makes more
>sense.
>
>Regarding "State" parameter, I will make the change in the
>next version.
>
>Regards,
>
>Ken
>
>At 07:22 AM 2/28/01 +0000, Joyce Archibald wrote:
>>Hi Ken,
>>