Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Bo Burman <bo.burman@ericsson.com> Thu, 07 November 2019 15:29 UTC

Return-Path: <bo.burman@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7AD120884 for <mmusic@ietfa.amsl.com>; Thu, 7 Nov 2019 07:29:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oUjCKCAadwW for <mmusic@ietfa.amsl.com>; Thu, 7 Nov 2019 07:29:22 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60075.outbound.protection.outlook.com [40.107.6.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1EB120883 for <mmusic@ietf.org>; Thu, 7 Nov 2019 07:29:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JJV5ZzvRPpUk1iPqaMnsYL9o2joOEv/HgSViXHV/UjeuyA7V/OlKamba8YF1EIxn7Z9yq6y81d5XxCCVRvnop+8gqKmGbh0iDtolMU0qHlvBQvqCCzygFiAN+TkO1LZEhioXBjXzU1Fex/BsKOwpAJJUEu74X/vt/8TXo8rLv6f1S7LWm+5gKd9y3OrK/O9AJynUd/rDRg8u41hruAxKWkjtEavzCFH9Sj+zQGPtowMSw5riuppacHQtzgwLlnp+G+rARFrGquwR/TMSdMsktl5VYBPSYadO3zXHylN9N74J/8tXaD9G9vnXTCmgbxBMgTvCHvg7bkmcY79zC3kDGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YgwTzGfY5Lk8MKrL3xmAE7LqJzkmnmgnoKZgxc3Qz5g=; b=XiqOIrHkkrn9fDE3/KWHWbzwUhOgxuYO/I7OK2OsQXku68xZfyarpElW4TyuJWT1g+LHQFKqRomePlgrF6BjHULf017smLWD10zEyccUSuPwsJl2cYtwcOGUeC2+3ky2qqGp3mQbJwAIkyo9p6m3e2c2iSgNAxa06i9OyAmadFCJMNcfX5243QHK8v9AXlT1HZDeeJ7TCTZDcwrP8GHlE4yoMEIQ2J8ZgV0vNCqXPbo7wX+dueez7mSjEQaYTZm0ZUeVf1QipmJ3CwBbvyY3zhsSEek8D0eWvvYwSpl5ljomySmjaaJxejDckhd7iFRQjr9w20rfpmjNz+Gkv5k9rg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YgwTzGfY5Lk8MKrL3xmAE7LqJzkmnmgnoKZgxc3Qz5g=; b=kCZCTQh2y4LJXzfrnn7C4X9Hp9ktsPAryMyLZWaqC1QTrDznb+T6IjrafEpFaT10e8POzDaHE/UaRgSJMI6nKjvYB0PsT1QxHiriukcgUEUWGWsy5y/KOuzcrFUxRorLjLVFCWqo36MgC7TrpXz7QBSHhqcEXT8LkkL0L1/2HeY=
Received: from HE1PR07MB3259.eurprd07.prod.outlook.com (10.170.246.26) by HE1PR07MB4156.eurprd07.prod.outlook.com (20.176.164.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.13; Thu, 7 Nov 2019 15:29:19 +0000
Received: from HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::34b4:6daf:fd13:71fb]) by HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::34b4:6daf:fd13:71fb%7]) with mapi id 15.20.2430.020; Thu, 7 Nov 2019 15:29:19 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Gunnar Hellström <gunnar.hellstrom@omnitor.se>, "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
Thread-Index: AQHVk909yEtpzH2MKEqkZmDSG+/rpKd9K6IAgACj3A+AAHGsCYAAFbG3gAA2oYCAAOw63YAACpyAgABNzID//+A1AIAABXdggAA6m4D//+XrkA==
Date: Thu, 07 Nov 2019 15:29:19 +0000
Message-ID: <HE1PR07MB3259953C403BCB632DB515E08D780@HE1PR07MB3259.eurprd07.prod.outlook.com>
References: <31B83060-1653-48A1-AB78-9D2418B49CC6@ericsson.com> <5742e425-788d-7d10-0e68-0a75bea74f3a@omnitor.se> <HE1PR07MB31619BBC3A73260C14CC693693790@HE1PR07MB3161.eurprd07.prod.outlook.com> <VI1P193MB06698D287FB68B4DDE435E98FB790@VI1P193MB0669.EURP193.PROD.OUTLOOK.COM> <HE1PR07MB31610CA6717330B5823EC72F93790@HE1PR07MB3161.eurprd07.prod.outlook.com> <c45c5029-72b2-d25f-4a3f-bc1d1c445a1f@omnitor.se> <HE1PR07MB3161BB6FFAC11E637111E0D193780@HE1PR07MB3161.eurprd07.prod.outlook.com> <f79712fd-84fd-3289-f7cb-97e547b2537d@omnitor.se> <FC883EE8-E05F-4E3E-ABF9-A1E94EB61F52@ericsson.com> <169e65c6-207f-3ccd-6c2c-9268d425e2fb@omnitor.se> <HE1PR07MB32593108119FAE1F07C2D7478D780@HE1PR07MB3259.eurprd07.prod.outlook.com> <E6D08311-B137-4583-9AAD-74C1BA728CFB@ericsson.com>
In-Reply-To: <E6D08311-B137-4583-9AAD-74C1BA728CFB@ericsson.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com;
x-originating-ip: [192.176.1.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9a34e7b9-8ef7-41f1-f75f-08d763974201
x-ms-traffictypediagnostic: HE1PR07MB4156:|HE1PR07MB4156:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB4156DF6A67BB98872A2622C98D780@HE1PR07MB4156.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(396003)(366004)(346002)(39860400002)(13464003)(199004)(189003)(110136005)(2906002)(81166006)(476003)(446003)(6306002)(14444005)(486006)(44832011)(66066001)(66946007)(86362001)(52536014)(11346002)(256004)(14454004)(8936002)(66446008)(76116006)(64756008)(8676002)(66476007)(66556008)(316002)(71200400001)(71190400001)(81156014)(305945005)(74316002)(25786009)(6246003)(102836004)(186003)(55016002)(561944003)(76176011)(99286004)(7736002)(9686003)(33656002)(6506007)(53546011)(3846002)(478600001)(6116002)(966005)(5660300002)(30864003)(6436002)(66574012)(7696005)(229853002)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4156; H:HE1PR07MB3259.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1mJ9f+NJ4d35E5iX/Ap0eu+3W33i6hmpj/qwfTf/yypdddsp2C6cDG9vY6RYVlPYPxDGRz0fG8uyD5NtzkZ4Aqd5f51CPuSx8CZDhw7eKkSp1voYVzPe1fAz7hgBuNVfV84KDge7lcTL9jog6A4hKoIwEn8TwEjMC8xzRBCLWmB62fnfKpJXf23+eDjIgKkGqOvMvUR9EE4DjYnJWEUaPewyfJUErRmI+Nvxgg/tNcCUBkJ+VHV+ddmL3tzE9By/SJDUKx4mKP6CPVYkYB+lGlxvQbNkMRDOXTIH7/WpsA10lDp91PS3HVyp5Bw6qCOiwDuMF+eiQQoKybQ7+ajRqGjR8bfweIqzqIHPbsB65PL6CmC3IGiXDnEccoME7wMhL9P1wNh5M/W2AJxwGDJImfaWXvt2qmtfwLqziFhCQzLkYn+QUoHb9z6W6QPbmARarLfHVi9XmNhq4HDNGoncwNI7LvUblgUmRo8YJgELw8M=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a34e7b9-8ef7-41f1-f75f-08d763974201
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 15:29:19.3412 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mXbcEP8cXsSQeHt/9qzVg/f1M5iwI3gSC54gGAv69+OyBuqXdZrqrBLEsDu41tf5vsaf0uk+fBMFqtem/Iq2fQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4156
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/mKnddzLlm5QWYhuwaj7wH5wKprQ>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 15:29:25 -0000

This looks good to me and I have no further comments at this time.
Thanks,
/Bo

> -----Original Message-----
> From: Christer Holmberg <christer.holmberg@ericsson.com>
> Sent: den 7 november 2019 16:02
> To: Bo Burman <bo.burman@ericsson.com>; Gunnar Hellström
> <gunnar.hellstrom@omnitor.se>; mmusic (mmusic@ietf.org)
> <mmusic@ietf.org>
> Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-
> usage-data-channel-07 - Bo's technical comments
>
> Hi,
>
> I have updated the pull request based on Bo's technical comments. Please
> take a look.
>
> https://github.com/cdh4u/draft-datachannel-t140/pull/52
>
> Gunnar, which RFC should I add as reference for the IRC labels?
>
> Regards,
>
> Christer
>
>
>
> On 07/11/2019, 15.34, "Bo Burman" <bo.burman@ericsson.com> wrote:
>
>     Yes, I agree that should resolve the  issue I had with the text.
>     Thanks,
>     /Bo
>
>     > -----Original Message-----
>     > From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
>     > Sent: den 7 november 2019 14:13
>     > To: Christer Holmberg <christer.holmberg@ericsson.com>; Bo Burman
>     > <bo.burman@ericsson.com>; mmusic (mmusic@ietf.org)
>     > <mmusic@ietf.org>
>     > Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-
> t140-
>     > usage-data-channel-07 - Bo's technical comments
>     >
>     > Hi,
>     >
>     > Christer, I accept your proposal below. With the remaining text it should
> be
>     > apparent for all that the solution has limitations.
>     >
>     > I hope also Bo thinks that the issues are solved now.
>     >
>     > Regards
>     >
>     > Gunnar
>     >
>     >
>     > Den 2019-11-07 kl. 14:06, skrev Christer Holmberg:
>     > > Hi,
>     > >
>     > >>> In the first paragraph we say that one needs to use separate data
>     > >>> channels, so it sounds strange to then have a note saying that is not
> true.
>     > Also, the way you suggest the text makes it look like you are defining a
>     > mechanism for using a single channel.
>     > >> Yes, I realized the conflict and tried to avoid it by the words
>     > >> "limited functionality multi-party RTT presentation in one display
> area",
>     > and "This presentation style does not meet all RTT requirements".
>     > >>
>     > >> But maybe that was not obvious. So, I accept your proposal below
> with
>     > >> some modifications
>     > >>
>     > >>> Maybe something like this:
>     > >>>
>     > >>> "The usage of a single T.140 data channel, without any protocol
>     > extensions, would require the conference server to only forward
>     > >>>   real-time text from one source at any given time, and e.g., include
> IRC
>     > style text labels in the real-time text in order for the receiver
>     > >>>   to separate real-time text from different sources. The procedures
> of
>     > such mechanism is outside the scope of this document."
>     > >> Yes, quite good, I suggest a few modifications to:
>     > >>
>     > >> "The usage of a single T.140 data channel, without any protocol
>     > >> extensions, would require the conference server to only forward
>     > >> real-time text from one source at any given time, and e.g., include
>     > >> IRC style text labels in the real-time text in order for the receiver to
>     > present real-time text from different sources separated. The procedures
> of
>     > such mechanisms cause functional limitations and are outside the scope
> of
>     > this document."
>     > > I am ok to replace 'separate' with 'present', but with the modification to
> the
>     > last sentence you would still have the question what those 'functional
>     > limitations' are,  and we would need to include additional text...
>     > >
>     > > So, I suggest that we remove the text about functional limitations.
>     > >
>     > > Regards,
>     > >
>     > > Christer
>     > >
>     > >
>     > >
>     > >
>     > >
>     > > From: Gunnar Hellström mailto:gunnar.hellstrom@omnitor.se
>     > > Sent: Wednesday, November 6, 2019 9:44 PM
>     > > To: Christer Holmberg mailto:christer.holmberg@ericsson.com; Bo
> Burman
>     > > mailto:bo.burman=40ericsson.com@dmarc.ietf.org; mmusic
>     > > (mailto:mmusic@ietf.org) mailto:mmusic@ietf.org
>     > > Subject: Re: [MMUSIC] Starting shepherd's review of
>     > > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical
> comments
>     > >
>     > > Hi,
>     > > Even if I accepted to delete the last sentence in section 5 on multi-
> party, I
>     > want to propose a solution that might better address the original issue 5.
>     > >
>     > > So, this is a proposal for new wording of the last sentence in 5, as a
> solution
>     > on issue 5:
>     > > "Conference mixers that use a single T.140 data channel
>     > >     to transmit real-time text towards clients might however without any
>     > protocol extensions produce a limited functionality multi-party RTT
>     > presentation in one display area. Only one source at a time can be
> presented
>     > in real-time, but switch of source of text to display in real-time can be
> made
>     > automatically by the mixer and at suitable points in the text streams.
> Sources
>     > could be identified by inline text labels in IRC style. This presentation
> style
>     > does not meet all RTT requirements and if used, should be a temporary
>     > fallback method for conference-unaware clients."
>     > >
>     > > This wording is a self sustained description on what is possible and
> would
>     > also match better the recently revived work on multi-party rtt.
>     > >
>     > > Regards
>     > >
>     > > Gunnar
>     > >
>     > >
>     > >
>     > > Den 2019-11-06 kl. 17:29, skrev Christer Holmberg:
>     > > Bo, are you ok with the proposals?
>     > >
>     > > Regards,
>     > >
>     > > Christer
>     > >
>     > >
>     > > From: Gunnar Hellström mailto:gunnar.hellstrom@omnitor.se
>     > > Sent: Wednesday, November 6, 2019 5:16 PM
>     > > To: Christer Holmberg mailto:christer.holmberg@ericsson.com; Bo
> Burman
>     > > mailto:bo.burman=40ericsson.com@dmarc.ietf.org; mmusic
>     > > (mailto:mmusic@ietf.org) mailto:mmusic@ietf.org
>     > > Cc: 'mailto:mmusic-chairs@tools.ietf.org'
>     > > mailto:mmusic-chairs@tools.ietf.org
>     > > Subject: SV: [MMUSIC] Starting shepherd's review of
>     > > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical
> comments
>     > >
>     > > Christer,
>     > > I agree with your proposals.
>     > >
>     > > Regards
>     > > Gunnar
>     > >
>     > > ----------------------------------------------------------------------
>     > > Gunnar Hellström
>     > > Omnitor
>     > > mailto:gunnar.hellstrom@omnitor.se
>     > > +46 708 20 42 88
>     > >
>     > > Från: Christer Holmberg mailto:christer.holmberg@ericsson.com
>     > > Skickat: den 6 november 2019 09:58:30
>     > > Till: Gunnar Hellström mailto:gunnar.hellstrom@omnitor.se; Bo Burman
>     > > mailto:bo.burman=40ericsson.com@dmarc.ietf.org; mmusic
>     > > (mailto:mmusic@ietf.org) mailto:mmusic@ietf.org
>     > > Kopia: 'mailto:mmusic-chairs@tools.ietf.org'
>     > > mailto:mmusic-chairs@tools.ietf.org
>     > > Ämne: Re: [MMUSIC] Starting shepherd's review of
>     > > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical
> comments
>     > >
>     > > Hi,
>     > >
>     > > ---
>     > > 3) In section 4.2.1, it says that “If the 'fmtp' attribute is not included, it
>     > indicates that no maximum character transmission rate is indicated.  It
> does
>     > not mean that the default value of 30 applies”; >why is this deviation
> from
>     > RFC 4103 chosen? Does it introduce a risk for interoperability problems
> with
>     > systems that also doesn’t use fmtp but interprets it as maximum 30 cps?
>     > > Gunnar?
>     > > [GH] I don't know why this deviation was chosen. But I have not
>     > commented it. You are right that it may introduce an increased risk for
>     > interoperability problems. But RFC 4103 has a precaution. In chapter 6,
> where
>     > the cps is introduced, it is said:
>     > > "
>     > >     receivers of text/t140 MUST be designed so they can handle
> temporary
>     > >     reception of characters at a higher rate than this parameter
>     > >     specifies.  As a result malfunction due to buffer overflow is avoided
>     > >     for text conversation with human input."
>     > >
>     > > (the reason for this note is for backward compatibility with RFC 2793,
>     > > the obsoleted predecessor of RFC 4103, so it is not exactly our case, but
> still
>     > valid.) We have discussed the risk that implementations may not
> implement
>     > setting or reading the dcsa attributes because of the complexity to do so
>     > alongside with the WebRTC API. That situation may cause a situation
> where a
>     > sent cps parameter is not obeyed. So the case is quite similar to the case
> in
>     > RFC 4103, and applications would be required to prepare for handling
>     > temporary reception at high rates.
>     > > The intention of T.140 is to handle real-time text conversation between
>     > humans. Huge cut and paste chunks of text cannot be required to be
>     > handled rapidly. The highest speed human interaction would be with
> speech-
>     > to-text applications. A very rapid speaker may produce 200 words per
>     > minute. That is 17 characters per second. The speech-to-text applications
>     > often makes corrections by long backspaces and resendings. That may
> add 10
>     > characters per second in the total. That results in a practical need of up to
> 27
>     > characters per second for one stream.
>     > > This calculation shows that for two-party calls, it would not hurt to use
> the
>     > same convention regarding cps default as RFC 4103 (30).
>     > > For centralized conference solutions with just one data channel from
> the
>     > conference server discussed in section 5.5, the need would be a multiple
> of
>     > that rate (27) corresponding to the number of simultaneous text
> senders. In
>     > well managed conferences this multiple is very close to one.
>     > > The figures above are extremes. Currently most use of RTT is typing at
>     > maximum speeds of about 7 characters per second.
>     > > Leaving the default to unrestricted might attract some misuse by
>     > implementations or users trying to use the T.140 data channel for data
>     > transmission of data totally different from the intended real-time text.
>     > > Conclusion after all this discussion:
>     > > Neither leaving the default to unlimited, nor changing to a default of 30
> cps
>     > as in RFC 4103 seems very critical. Any solution will do.
>     > >
>     > > [Christer] I am pretty sure IESG would ask about this too, I suggest that
> we
>     > change the default to 30 cps.
>     > >
>     > > ---
>     > > ​5) In section 5.5, in the note, it says ‘…with limitations in real-time
>     > performance and presentation style’; I think it would be helpful to briefly
>     > elaborate on what type of limitations would be >expected and why.
>     > > I think it is explained in the other text of the section. For example, using
> a
>     > single data channel without any protocol extensions would not allow to
>     > separate the sources etc.
>     > > [GH] I think we can offer a bit more text at the end of the note to
> clarify.
>     > How about this:
>     > > "T.140 shows two examples of presentation layout for real-time text,
> one
>     > being column oriented, with one column per participant, another being
>     > arranged in one column with labels identifying the beginning of text from
>     > each participant and text from a number of participants received and
> placed
>     > in places corresponding to these different participants. With a
> conference
>     > mixer using one text stream and not applying any presentation protocol
>     > extension would only be able to produce a string for presentation in one
>     > column, including a source label in the beginning of text from one
> participant
>     > and only show text in real time from one participant at a time, shifting
> real-
>     > time presented participant at suitable points in the text stream. (end of
>     > phrase, end of sentence, line separator, long delay etc.). This
> presentation
>     > style may not be preferred by the user and it may cause delay before
>     > presentation of text from other than the currently presenting
> participant."
>     > > Pew, maybe too long and detailed....
>     > >
>     > > [Christer] Or, could we simply remove the last sentence ("Conference
>     > mixers that...")? The 1st paragraph already says why separate channels
> are
>     > needed, and the note says that future extensions may allow usage of a
> single
>     > channel, so I think it is pretty clear that using a single channel without any
>     > such extensions would come with limitations.
>     > >
>     > > ---
>     > >
>     > > 6) In section 6, bullet “If the gateway detects or suspects loss of data on
> the
>     > RTP stream…”; shouldn’t it await possible redundancy first and missing
> text
>     > marker is inserted only when the used >redundancy is not capable to
> repair
>     > the loss?
>     > > Gunnar?
>     > > [GH]The intention was that it would mean "after using possibly
> received
>     > redundant data".   You could interpret "loss of data" to mean that
> (instead of
>     > "loss of packets"), but let me try an improvement: "If the gateway
> detects or
>     > suspects loss of data on the RTP stream, after use of possibly received
>     > redundant data, …"
>     > >
>     > > [Christer] What about?
>     > >
>     > >
>     > > "If the gateway detects or suspects loss of data on the RTP stream, and
> the
>     > lost data has not been retrieved using a redundancy mechanism, the
>     > gateway SHOULD insert the T.140 missing text marker [T140ad1] in the
> data
>     > sent on the outgoing T.140 data channel."
>     > > ---
>     > >
>     > > 12) In section 11.1, in the [T140ad1] reference, is “aEUR” really part of
> the
>     > name? The name I find listed on the ITU-T web is “ITU-T T.140 (1998) Add.
> 1
>     > (02/2000)”, and the title in the document >itself seems to be “Protocol
> for
>     > multimedia application text conversation; Addendum 1”.
>     > > Interesting. There is no "aEUR" in the XML file, so this seems to be
>     > something created by XML2RFC.
>     > >
>     > > The intended title is:
>     > >
>     > >     Recommendation ITU-T.140 – Addendum 1  (02/2000), "Protocol for
>     > multimedia application text conversation"
>     > >
>     > > I will fix it.
>     > > [GH] I chased a number of such occurrences earlier. I think it was
> because
>     > your editor inserted an unusual slanting quotation mark. Note that there
> is
>     > also a double quotation mark on the third line of the same reference.
>     > >
>     > > [Christer] I will double check.
>     > >
>     > > ---
>     > >
>     > > Regards,
>     > >
>     > > Christer
>     > >
>     > >
>     > --
>     >
>     > + + + + + + + + + + + + + +
>     >
>     > Gunnar Hellström
>     > Omnitor
>     > gunnar.hellstrom@omnitor.se
>     > +46 708 204 288
>
>