Proposal for changes to CHAT protocols T.134 and T.140

Fri Dec 19 15:55:13 EST 1997

I have some comments on Mark's questions and proposals.

I am glad that T.134 has got a walk-through.
At 09:41 1997-12-19 -0500, Mark Duckworth wrote:
>I'm looking for comments on the enclosed proposal, which I would like to
>see incorporated into the T.134 and T.140 recommendations before decision
>in Geneva next month.
>
>Also, a couple months ago Toby Nixon raised the issue "why do we need
>H.chat when we have T.chat?", but I didn't see any discussion on the
>ITU-SG16 reflector.  I think we don't need H.chat in an H.323 environment,
>for all the reasons Toby mentioned.
****************************************
That and similar discussions have popped up now and then during the year.
Lately in the Q11 meeting in Eibsee. In that meeting, a small change in
T.140 was discussed - to change to UTF-8 coding (a more robust variant of
Unicode coding than the straight 16 bit coding. UTF-8 is commonly used for
Unicode communication). That was agreed to be wise, so it will be proposed
in Geneva.

But then also the need for "H.chat" - the simple AL1 channel as one of the
ways to use T.140 chat protocol through H.324 was questioned. There is
always the possibility to have a T.120 with T.134 implemented. 

I started out in March with that view, that using a new member in the T.120
application family for text chatting would mean most interworking
opportunities and good likelihood of implementation. That is now T.134.

T.140 is needed in Internet Phones, in Mobiles, in simple videophones, in
Net-PC-s. There were strong arguments for simple logical channel
implementation of T.140 in some of these environments. That was introduced
in H.324 and work was started in H.323. 
Are there signs enough that there will be T.120 implementations in these
environments, so that we can stop the H.chat activities in H.323? 
******************************************
>
>Mark Duckworth
>duckworthm at pictel.com
>
>1. Introduction
>
>This document proposes specific modifications to T.134 and T.140.  The
>intent is to clarify the usage of T.140 in the T.134 multipoint environment
>and to fix the ASN.1.
>
>2. Proposed changes to T.140
>
>There is no need to have the light and enhanced profiles in a multipoint
>session.  Several enhanced commands are specifically not allowed in
>multipoint, and the other commands can be safely ignored, so the proposal
>is to eliminate the distinction between light and enhanced.
>
>The entire text of section 9, profile and multipoint considerations, should
>be replaced with the following:
>
>   In point-to-point sessions, communication should be limited to
>   what is supported in the highest common profile.
>
>   In multipoint sessions it is not desired that a single node with
>   a low profile can dictate the level of the communication used.
>
>   Therefore the following principles shall be adopted:
>
>   In a point-to-point session, the highest common profile shall be
>   used. ENHANCED is regarded higher than LIGHT.
>
>   In a multipoint session, there is no distinction between enhanced
>   and light profiles.  A multipoint terminal may send commands from
>   the ENHANCED set of protocol elements.  A multipoint terminal shall
>   be capable of ignoring protocol elements it does not support.
>
>   The following protocol elements shall be sent only to a specific
>   node and thus not used in multipoint sessions:
>
>   "Unsupported request", "Check status", "Status report",
>   "Resynchronize", "Indicate ENHANCED profile".
>
>   All other protocol elements shall be distributed to all participants
>   in the session.
>
>   A multipoint session includes any session in a multipoint capable
>   environment (such as T.134), even if only two terminals are involved
>   at a given time.
I see the points in this reasoning. We had this issue up in and before
Sunriver. Fancy things like character rendition (colour, bold, flashing
etc.) was put in the Enhanced profile, in order to let the Light be easy to
implement even with a gray LCD character oriented display. It was regarded
important that the sender can rely on the transmitted info to be possible
to display at the far end terminal. 
But then, in order not to clobber one multi-point-node with too much
"Unsupported request" indications we agreed on multi-point APE:s not
bothering about sending them. 

With Mark's proposal, all H.320¨s using T.140 will be in the Enhanced mode
without knowing that all participants can display what they get, because
they use T.134.

Terminals should act consistently. Will it be understandable to users if
they in some occations get notifications that the user can not display what
was sent and in other occations get no such notifications, but still
understand from the dialogue that the user cannot display all what is sent?
Probably not. 
That would lead to dropping use of the "unsupported request", and instead
introducing display habits always giving some visual presentation of the
features conveyed. Equal for point-to-point and multi-point.

>
>3. Proposed changes to T.134
>
>3.1 CHAT Concepts
>
>The description of the diagram in section 5.1, CHAT Concepts,  is
>misleading.
>The second bullet item, which states "CHATE C acts as an MCU, distributing
>the CHATPDUs among the CHATEs" should be replaced with the following: "The
>MCS provider in the node with CHATE C acts as an MCU, distributing the
>CHATPDUs among the CHATEs".
OK
>
>3.2 Conducted mode operation
>
>The behaviour of a T.134 APE should be restricted in a conducted mode
>conference.  The following text should be added at the end of section 7,
>Use of GCC:
>
>   When a session is in conducted mode, a CHATE may be restricted from
>   sending data, depending on the GCC conducted-mode permission mechanism.
>   If the node is given GCC conducted-mode permission, then a CHATE may
>   send any type of ChatPDU.  If the node is not given GCC conducted-mode
>   permission, then a CHATE shall not send any type of ChatPDU.
OK
>
>3.3 Non-standard extensions
>
>Text should be added at the end of section 8.3, CHATPDU Formats:
>
>   A ChatPDU can contain non standard information using the
>   chatNonStandardPDU choice.  This uses the H221NonStandardIdentifier
>   to allow an implementation to use non-standard information without
>   conflicting with any other implementation's non-standard information.
>   If a terminal receives a ChatNonStandardPDU it doesn't understand,
>   it shall ignore the PDU.
I am no great friend of NonStandard additions, but there may be reasons to
add it.
>
>3.4 ASN.1
>
>Unused types are removed, and a non-standard PDU choice is added to allow
>proprietary extensions.  The entire section 9.1, ASN.1 Definition, should
>be replaced with the following:
>
>
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--
>--                          Begin CHAT Definitions
>--
>-- The following base mode ASN.1 definitions are encoded using the BASIC
>-- ALIGNED variant of the Packed Encoding Rules of ITU-T Recommendation
>-- X.691.
>--
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>
>CHAT-PROTOCOL DEFINITIONS AUTOMATIC TAGS ::=
>
>BEGIN
>
>-- NOTE: ===============================================================
>-- NOTE: All abstract types defined shall be exported
>-- NOTE: ===============================================================
>
>--  H221NonStandardIdentifer
>   --  Used to specify non-standard objects using H.221 numbering.
>   --  The first four octets shall designate country code and
>   --  manufacturer code, assigned as specified in
>   --  Annex A/H.221 for NS-cap and NS-comm.
>H221NonStandardIdentifier ::= OCTET STRING (SIZE (4..255))
>
>Key ::= CHOICE        -- Identifier of a standard or non-standard object
>{
>   object             OBJECT IDENTIFIER,
>   h221NonStandard    H221NonStandardIdentifier
>}
>
>--  NonStandardParameter
>   --  Used to specify non-standard parameters.  This includes a
>   --  data field which may be used to fill in parameter values
>   --  of the type indicated by the NonStandardIdentifier
>NonStandardParameter ::= SEQUENCE
>{
>   key             Key,
>   value           OCTET STRING OPTIONAL
>}
>
>ChatString   ::= GeneralString (SIZE (0..255)) -- Chat Protocol String
>
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--
>--                          Begin CHATPDU Definitions
>--
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>ChatentryPDU ::= SEQUENCE
>{
>   chatString                            ChatString,
>   ...
>}
>
>ChatNonStandardPDU ::=  SEQUENCE
>{
>   nonStandardTransaction            NonStandardParameter,
>   ...
>}
>
>ChatPDU    ::= CHOICE
>{
>   chatentryPDU                      ChatentryPDU,
>   chatNonStandardPDU                ChatNonStandardPDU,
>   ...
>}
>
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--
>--                          End CHAT Definitions
>--
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>--||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
>
>END
>
>3.5 Object Identifier
>
>Typographic errors in the object identifier should be fixed, so it
>conforms to Recommendation X.680.
>
>The object identifier in Annex C is given as:
>
>   {itu recommendation T.134 version 1}
>
>This should be replaced with:
>
>   {itu-t recommendation t 134 version(0) 1}
>
>END
>
>
OK
Gunnar Hellström
------------------------------------------------
Gunnar Hellström
Omnitor
Alsnögatan 7, 4tr
S-116 41 Stockholm
SWEDEN

Tel +46 701 100 501
Fax +46 8 556 002 06

E-mail: gunnar.hellstrom at omnitor.se
WWW:    public-www.pi.se/~omnitor
------------------------------------------------