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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 09 April 2020 19:57 UTC

Return-Path: <christer.holmberg@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 8E2823A0D17; Thu, 9 Apr 2020 12:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.268
X-Spam-Level:
X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 sQIYPwzTJ9Ys; Thu, 9 Apr 2020 12:57:11 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00087.outbound.protection.outlook.com [40.107.0.87]) (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 C74913A0D16; Thu, 9 Apr 2020 12:57:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CvY+2kNUEgFMHUbc2TSmXTD53Bi6P3WC67JkFqhTE0fSHBsDY7vhC3UyFOjYVGP2asMaudKzOBWvm0an0ZszyV5KyEgye88RUFgdwhYmVfzN7FrrQpBecPgvLz5Qv9d38Fi9T7Q36ObNmQNJR1TOK9ucuMaWPaAFVjOCxLC9PmwnKwGy18EL51cBPaoRjBj5pX8ODVKVt/8IxF+UvKgunaerIVit13Hw3RwEZiUv7qj0lEHeYBrIdsNLm//0oEH2mW6RwO8TQJrIP0B6+u56VLIvu+lh9stWv9YOR+vPmm0BIRlD3Eoc6Ju2nvNTpMaaqQUeGMzLJuv+ih+Gg3qoyA==
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=tvCNdkabcNtW/9ZQhHHTpcQUY+oa1zh3DKGTr0/4YpM=; b=kzMGDCgKiYkA5UDwXVU4TEf7OeuXNBOyUlTBlpUyBDpIBahDERyd1iNalgGsoMQ7Dl13B3v6r2O2PQExnRyJqZShS5YwHAK2ZiaDL0aYGkaJvQK5XAVIBTTQBWOXksgDLte3NUaNmqDBL8aaLNCkh1weVWmA/MdAwf4nLE2zzehYWGfMLvIto3V33ad1byyuK34BuL6Eyk2cO3BYSswPCmSTKWDDzZvx+xLnHEyyaNBLJLbTPSd1siQA/09Yi3/d4yBVaXXQMyytW8CA2N9N6yUKcQTsbg++eOO8yzZdNqPf4DvrB4cUEg+B9Ui+/dkf4moPi5CxBRNrQEkGpOQjCg==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tvCNdkabcNtW/9ZQhHHTpcQUY+oa1zh3DKGTr0/4YpM=; b=YLAXRe6zUQgrv8FQUuYUVgiJ77ett2OMVB1WjVdqDAkE15t3f4s5ne8cMl46+vAp6nDi5q1DKXAIZef23wA7ALNZqotg4162rsEqPcsgp3L8+M76BFdwsTbsCTlWV0rQPJ1FHFdTraZgBNMFCx0BiX9nBpWSEI7RW+SKKWGOcVg=
Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6100.eurprd07.prod.outlook.com (2603:10a6:208:117::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Thu, 9 Apr 2020 19:57:08 +0000
Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2900.015; Thu, 9 Apr 2020 19:57:08 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <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>
Thread-Topic: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-t140-usage-data-channel-12: (with COMMENT) - Christer's 2nd reply
Thread-Index: AQHWDejdeoIe25oXrUOv4/26GBTL36hxKH2AgABAFQA=
Date: Thu, 9 Apr 2020 19:57:08 +0000
Message-ID: <24FB1FEA-0428-4E35-AF34-3A4150A6FF95@ericsson.com>
References: <96271E3C-9242-442F-9BB9-74F23BA3C575@ericsson.com> <20200409190747.GE88064@kduck.mit.edu>
In-Reply-To: <20200409190747.GE88064@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [188.127.223.154]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f53b590d-4584-4555-b7ba-08d7dcc02f7b
x-ms-traffictypediagnostic: AM0PR07MB6100:
x-microsoft-antispam-prvs: <AM0PR07MB61003BBB9152EA52583A342093C10@AM0PR07MB6100.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0368E78B5B
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(6512007)(5660300002)(71200400001)(66946007)(86362001)(33656002)(64756008)(76116006)(66476007)(91956017)(186003)(66446008)(26005)(66556008)(44832011)(8676002)(81166007)(6506007)(81156014)(2616005)(478600001)(6916009)(2906002)(8936002)(36756003)(54906003)(4326008)(6486002)(316002); DIR:OUT; SFP:1101;
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: clIPMXrCwPBqu4PNwN39dhiWtqeL2ZN3qJfXGqPeTjzM+mDFG3jNQ8SU9FPoKO2Md5QUZuxdPKbtyZGo+3UwX6PBWN+fOvA4pRU2BSBWwnRlTRPeqDGcJlCMJIZI3yFTsl5GxDJtYQBHYj39E3OHVKAECz6kblz+1KbgyMRCDR5HWOayCst4QPbiwEalbyRyw4hcfH135GGiyGa3qGhZM4DVk4ZqtI0xXWpHrQUPdWVAnTWYm6QY6EgMvI6Hm1wVcvqKg02FVFaCmFIGpk85fAr7xSuCwuvr4W8WaxNr4tvZMG9T54n4tlcCFroVOexvFBWiMo2DAC6UWcPYBo8ewbNuUaPsP93iltxQ80erjLQztogceRTzkBv8mfVZqnunl05zVD3dmBzgfkdyiuCmuXec2QekAaJ8jN1VPLsoIcgbCCZcfrWTv1byil6vegic
x-ms-exchange-antispam-messagedata: aChWZk6OSJ1tkoZ2p9RX3iZI8MPQKJrvcc+T7AzvdB2VuEUAEMEatSqVEXfMtkdr52bjS16QxGaIVxZmPIjoio5LsDRA3zLZKI9Of7kKmkxgXUmchEpyxONfk7NAZxSynEFKe35SLfpSt4tyFfeFBg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <85724950101C49418E0C8D8AF0FF3850@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f53b590d-4584-4555-b7ba-08d7dcc02f7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 19:57:08.4043 (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: 8WHByo7NK6TXivNTMdPpTXhB1G6z3iTbcSMAKd69T+ezgjne4ZR1Z61U59SadEBc4RrpVRVvTo1ybSa2aAEI2n9iCogCaIJUy4PS09vnYCk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6100
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Wa4XGEK8CTlAfc5e8-gOaSzSNhY>
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:57:13 -0000

Thanks! :)

Regards,

Christer

On 09/04/2020, 22.08, "Benjamin Kaduk" <kaduk@mit.edu> wrote:

    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
    > 
    > 
    > 
    > 
    > 
    >