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@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@omnitor.se WWW: public-www.pi.se/~omnitor ------------------------------------------------