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

[Arnoud van Wijk <[e-mail]>]

Hi Dale,
Thanks for the excellent feedback and we will look into these matters 
and address them where possible in the next draft versions.
And to discuss the possible solutions.

Sincerely

Arnoud van Wijk

On 05-07-11 19:56, Worley, Dale R (Dale) wrote:
>> 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
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>