Re: [dispatch] Questions about draft-hellstrom-text-conference-04

["Worley, Dale R (Dale)" <[e-mail]>]

> From: Gunnar Hellström [[e-mail]]
> 
> The specification you find very thin is that one for conference-unaware
> clients.
> It is documented at http://www.realtimetext.org/index.php?pagina=62
> 
> Please help us to judge if this description of what to do with
> multiparty real-time text calls when the client does not understand the
> multi-party features. Should it be included in the IETF draft, or kept
> separate?

It's probably not important to include it in the Internet Draft, but I
see no reference from the I-D to
multiparty-real-time-text-mixer-2011-03-06.pdf.

> 3. Redundancy.
> Yes, I have realized that the restriction to not merge different sources
> to contents in primary and secondary text in the same packets as
> described easily creates long waiting before transmission of a specific
> text item. That is not favourable.
> 
> We should find a way to circumvent that limitation. Your proposal to
> analyze the time stamps is one interesting initial way.
> 
> Having a more specialized redundancy format providing more info per text
> item could also be considered.
> RFC 4351 transmits real-time text and has a special added sequence
> number field in the redundancy information. Such solutions but
> specifying the source could be created for the central rtp-based method
> if so decided.

I have just skimmed that RFC.  It appears that the core of the idea is
to define a new "t140c" format, which includes a 16-bit "sequence
number" in the payload, along with the T.140 character octets.  That
would be a cleaner way to deal with the redundancy problems, assuming
that each sub-stream of t140c blocks (identified by CSRC) has its own
sqeuence numbers.

> 4. Graphic rendition.
> You are right that the graphic rendition is stateful information, and
> loss can mess up the presentation.

There is one aspect of "SGR" that may not have been incorporated into
multiparty-real-time-text-mixer-2011-03-06.pdf:  SGR codes are
*cumulative*, that is, the graphic rendition state consists of
multiple components, and an SGR code modifies only one or a few of
those components, leaving the others unchanged.

You can see evidence of this in the structure of the SGR codes.  (See
http://en.wikipedia.org/wiki/ANSI_escape_sequences#graphics.)  There
are SGR codes to turn on special characteristics (blink, underline,
color, etc.) and corresponding codes to turn off each characteristic.

However, looking at ECMA 48 standard
(http://www.ecma-international.org/publications/standards/Ecma-048.htm),
I see that there is a "Set Mode" escape sequence which can control the
"Graphic Rendition Combination Mode".  If GRCM is off, each SGR clears
the effect of any previous SGR before applying its own effect.  If
GRCM is on, each SGR is cumulative with previous SGRs.  (Excepting SGR
"0", of course, which clears all special rendition modes.)

It appears that T.140, multiparty-real-time-text-mixer-2011-03-06.pdf,
and draft-hellstrom-text-conference-04 do not consider how to handle
the Graphic Rendition Combination Mode.  It appears that none of these
standards support Set Mode and Clear Mode, but they do not specify
whether GRCM is set or clear relative to interpreting SGR.

My memory is that computer terminals generally used to assume GRCM is
set, but I may be wrong about that.

This needs to be clarified in a consistent way.  I suspect that "GRCM
clear" would be the easiest mode to implement, as an element that
manipulated text streams (e.g., a mixer) could simply remember the
last SGR rather than having to accumulate and combine the SGRs.

Dale