Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-t140-usage-data-channel-12: (with COMMENT) - Christer's 2nd reply

Benjamin Kaduk <kaduk@mit.edu> Thu, 09 April 2020 19:08 UTC

Return-Path: <kaduk@mit.edu>
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 2FCC33A0C35; Thu, 9 Apr 2020 12:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KnerlnjmH24s; Thu, 9 Apr 2020 12:08:01 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5960B3A0C2B; Thu, 9 Apr 2020 12:08:01 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 039J7lEX024415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 15:07:50 -0400
Date: Thu, 9 Apr 2020 12:07:47 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= <gunnar.hellstrom@omnitor.se>, The IESG <iesg@ietf.org>, "fandreas@cisco.com" <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "draft-ietf-mmusic-t140-usage-data-channel@ietf.org" <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>
Message-ID: <20200409190747.GE88064@kduck.mit.edu>
References: <96271E3C-9242-442F-9BB9-74F23BA3C575@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <96271E3C-9242-442F-9BB9-74F23BA3C575@ericsson.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/th8UKPS4bkhf6TD7PZJTahRLx0Y>
Subject: Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-t140-usage-data-channel-12: (with COMMENT) - Christer's 2nd reply
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, 09 Apr 2020 19:08:03 -0000

Hi Christer, Gunnar,

Thanks for all the replies: with the changes already in github I think
we're all set here.

-Ben

On Wed, Apr 08, 2020 at 09:01:25PM +0000, Christer Holmberg wrote:
> Hi,
> 
> 
> 
> I noted there were one more place where Gunnar asked for my input. I am addressing that in this reply.
> 
> 
> 
> (Gunnar, let me know if there is something I've missed.)
> 
> 
> 
>     ----------------------------------------------------------------------
> 
>     COMMENT:
> 
>     ----------------------------------------------------------------------
> 
>     .....
> 
> 
> 
>     Section 5.2
> 
>     >>
> 
>     >>     Each T140block is sent on the SCTP stream [RFC4960] used to realize
> 
>     >>     the T.140 data channel using standard T.140 transmission procedures
> 
>     >>     [T140].  [...]
> 
>     >>
> 
>     >> I'm not really sure what is meant by "standard T.140 transmission
> 
>     >> procedures" -- is that supposed to cover the process by which the webrtc
> 
>     >> stack receives the T.140 input or something done within webrtc?
> 
>     >
> 
>     > This is esseentially chapter 7 of T.140. It is at least to use UTF-8
> 
>     > coding as specified in T.140. And start after channel establishment by
> 
>     > sending UTF-8 BOM. It is also to not buffer longer than 500 ms, even if
> 
>     > that is also said in another place.
> 
>     >>
> 
>     >>     Data sending and reporting procedures conform to [T140].
> 
>     >>
> 
>     >> I don't see any instance of the string "report" in
> 
>     >> file:///home/bkaduk/Downloads/T-REC-T.140-199802-I!!PDF-E.pdf; am I
> 
>     >> missing something?
> 
>     >
> 
>     > Right. There is only one response specified in T.140. It is the
> 
>     > "Unsupported request" in section 8.7. But that cannot really be called a
> 
>     > report.  Maybe another reference was intended here.
> 
>     > draft-ietf-rtcweb-data-channel could be intended for the sending, but it
> 
>     > has nothing on reporting. W3C webrtc has requirements on reporting for
> 
>     > statistics, but I doubt that that was intended.   Over to Christer...
> 
> 
> 
>     I don’t know where “reporting” is coming from. It was already in the old schwarz draft (that this draft replaced).
> 
> 
> 
>     I also had a look in T.140, and couldn’t find anything related to reporting.
> 
> 
> 
>     My suggestion is to remove it.
> 
> 
> 
>     Regards,
> 
> 
> 
>     Christer
> 
> 
> 
> 
> 
>