Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 26 May 2021 16:38 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE833A0A19 for <avt@ietfa.amsl.com>; Wed, 26 May 2021 09:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 ye7XVp8aSVBz for <avt@ietfa.amsl.com>; Wed, 26 May 2021 09:38:13 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130052.outbound.protection.outlook.com [40.107.13.52]) (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 BE4653A0A13 for <avt@ietf.org>; Wed, 26 May 2021 09:38:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dIOtY4fQa0HTfHWr4RDzHDGp03b/OGdEZdwGN32okYGar+eNo3bCxMnxq7jfj8S8nEDseH/CvA16JxRtK4Vm6Af97N/a+cjzD+Yb/jyPhPPdnDe9gC1SNnsFkanI6HYAKU7yjMaI3uJyyDB1khIx2zDbsMjpaZpymQI/njP9G8et89Vys9jGzitN3M8kWRC/VfyM7m9eZL946at/ugQ5qV6BmH8XFHI8bb+q3/JUmoxsES7vIyftdz0c6vTAlXtRHHIBpfIqpKJ11X+VZUtLQwB93dbEWO67K6btRIuPpvQcgxXo+CVjYDKHyIkfJs6DVK2Ax25Qo80GZdmCVcsRdg==
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=wQRo3ge6+4AbOgmLpE1jHyywvGrkZ9yVVxeM+GZggXI=; b=IzDFHMm9Gx9HMRccfg1A/HSJAw4Q3QsDPtzKXEcmmRFKVGgiQpG+XZXjgDNqPFG0kuangQXe2rYfzJAW+7JdKZK9Ae+kD5kfeAUsyLix+lY/uOKda5MCw34YbxBlb2j8HcggkZEzP4QrKTf0yqURa/GfZS2GAa6I9llJAZHCmCkoGOI0IPyx7quI7oeZ/7KNSp1f8oyrmYe19vbw6vPqdVyXivq01u625jZNTwrNyaS+n/+OemLnARgqd42ZfDGOBokw2/cMNYmoaMDmCSJcGoBWs0yuqzocP1lPLOjQ8SD0Nn+y8mDz9FHq+RIvzpoyfmq7dpE/l9f09n4ImTFZOg==
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=wQRo3ge6+4AbOgmLpE1jHyywvGrkZ9yVVxeM+GZggXI=; b=m6rlv1zAp4VBo8IH3F8lYoKdOz4fYNsL1ceeRnRrPLJuo98CTwPUwDOG6Qxwe6jNqj1qohjsuwOhFZ/vN/e6YsdD9HcvDIxmD/HgYmMTbJYHJZICvoPTN5aw62Lp0FlUlM5gWGU6YJQ/c2GYHGaBFXcPN7ex82tzG2/+51XrKRY=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM4PR07MB3313.eurprd07.prod.outlook.com (2603:10a6:205:e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.15; Wed, 26 May 2021 16:38:10 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4173.021; Wed, 26 May 2021 16:38:10 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Thomas Richter <thomas.richter@iis.fraunhofer.de>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQ
Date: Wed, 26 May 2021 16:38:10 +0000
Message-ID: <AM0PR07MB386047058704E75B425ED82493249@AM0PR07MB3860.eurprd07.prod.outlook.com>
References: <AM0PR07MB38605C82DE3B4A8F677C8557932D9@AM0PR07MB3860.eurprd07.prod.outlook.com> <PR3P192MB0748357C78FECBB3CA63BE93AC269@PR3P192MB0748.EURP192.PROD.OUTLOOK.COM> <AM0PR07MB38607E9DDEB4FC8B86FC3FBB93269@AM0PR07MB3860.eurprd07.prod.outlook.com> <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>
In-Reply-To: <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: iis.fraunhofer.de; dkim=none (message not signed) header.d=none;iis.fraunhofer.de; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5063eb4b-46ee-49ac-898f-08d92064a64b
x-ms-traffictypediagnostic: AM4PR07MB3313:
x-microsoft-antispam-prvs: <AM4PR07MB3313EE17B18E63C5748AC4D293249@AM4PR07MB3313.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VFJyrW+QrwypAqWFFPgVE9dNWhm6ZZKOSV0L45Q1voQZjyoDiSt3VVlAELEIFTN99hhoxAVLle/TN315ld0rWlAKJwXQ9toHo62eRt82xsNfcx4d9tSt+EgpHCCnVCUDcbv5STBiiiMVR0FYU9HDVKO6sWGVxm4HLdI4u9fRarXXIUiL4h4CK6oJaQnXX8DwZHa+YP9vBfe17Ih6C3SpEGVod+3tGADPHlVQfDGydal5tRsOXzsl5Z8Zm6ER57VUubBY9NWne0KPeKbVxdw08PJA5EMLwjgMVXQMKHpStW7ByqR+WPobmJ2osrpDvVDePxipEStn7F1KzMZc3hLKSM3QAV90AgSXZx+dFht1K1Xjf/l+/h6cQZg/vyNcxBiA0kcbvST89qDu0YtkBphCWjhbsf/dBw23RHL/RnB+6D1q1T1YiEOZ+Nkhh6P0idrF/elY1rhSTPoMGy/1J7gjBwvDy4mhsDUoHYJBwKIKyY7mpK4mRO6NCRawWCD0Zxl0MxyEjr0zK5Z+WITw3kEwwvTJModRmU+glOuQTWFW4ts/iS3lZcHNefBjWbwMtkhC/oRi1jrUblSmkdA/8ykaVETh+GJ/iLYcns6nSjA1FpU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(396003)(39860400002)(376002)(366004)(38100700002)(110136005)(316002)(5660300002)(33656002)(186003)(76116006)(478600001)(122000001)(8676002)(55016002)(66446008)(44832011)(66476007)(64756008)(66946007)(66556008)(9686003)(52536014)(26005)(7696005)(86362001)(6506007)(2906002)(71200400001)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?bJRZMCbsz8kuBH/Vx7/jyRgC2DYJDC2hMObTBxmqE2UI2cukENLSLOXdUvRu?= =?us-ascii?Q?06oMbhf3zkpzbq/K0DqOSuKaSma1NKD8DZ0fPjW0L/yVf6a1uTiMeJJJ0AoF?= =?us-ascii?Q?xlv4F15QzEKYS3naKUKL9yJ39TFYZwTqTy45AboB2LAu/cI5f10AOyykU36I?= =?us-ascii?Q?6GHTOizyvy1sZ1TnaKwjaR2oSarhSnr/nIX8H4HKtCuz1EtZb3sCK/CnxQPx?= =?us-ascii?Q?KOio1EzlurVVGeT7RKsEJ/TIpfo3myFLnPoe7+XX0/qozmkSRm6dShkmAnSq?= =?us-ascii?Q?yyxn3QRDolDmm6jAvsm89txew9Vz0552lJHKYapWf78ehMaM9vfizlAKoyQG?= =?us-ascii?Q?qSQmBsbxSSiJH/XA+IqJyTaDepXw6wuYBUQJCK9CTMiBN0WBcYfZCmqDji84?= =?us-ascii?Q?Lpp16H5k2kUiZ3Nmh4a6SwEydMU1YZcLSEfc3xUd0ahZdLruptd1BGSoKeC+?= =?us-ascii?Q?rPff4loHMWy9BuaexhVwDa0yot3FAJW9WB3jtpHGDuLtAnD9HYBxPU8o264u?= =?us-ascii?Q?jhSBSLXQDdqvlshpQekooVBmOfQzTvcEks0WSqDqE7pYVl5nfbPHeLXmd4Ek?= =?us-ascii?Q?B/icdLPKJkIEM/7Ks5UA03R+OspDl15IpuW+Jdxh55MEdtgjjxnuD+Ln930E?= =?us-ascii?Q?9AblFP0gcgkvG1CNFnrisBhZq4AkDJSQsRQaUlF4HgNG+hotQV5RI9BaKECM?= =?us-ascii?Q?UeCevxDrB9MPXVAM4h2hnNMYMOBTBPHj23Bb23Av4ZCzlCIy0nB8JJ03Lto7?= =?us-ascii?Q?ZnTazMVh5uB2cii0jOasGHm+eMxgvqRm195mA+o5i5eZrcmCbU5bUFoh9vCB?= =?us-ascii?Q?jJ45OCes6duk4D6dbbMY74VCZSrOy/hXKf+OwnM80fFkyhRBK65kkxXx+JYk?= =?us-ascii?Q?ewbmbGp5f+KylCthacsysi1PIsaExystJN+qsmlZcjOUqhmcBikEoxMUR7rt?= =?us-ascii?Q?8YYl3snaNNrLlz6E8K3mrJqg+qyBA7Ze9aaXoCpzZU2Qa1Q5vgEbZLeAEMg2?= =?us-ascii?Q?BDLCp9B1acW/0EXOhUjtKbIyRp9HDw2QWzUKEjb5aD2tf2LMURjQZmTSTALH?= =?us-ascii?Q?GL0pU+Y0k+xTrQEQNgX2gs0N2vlwecs6DJycRF5bY5lyOou/LY5eBGNJ5yyM?= =?us-ascii?Q?Gl5hXrSSoGDOGrcQTDcbe1zVDxIBVnH2Y/qJcFiexKF/8jFw4n28ifJ6cpCI?= =?us-ascii?Q?wc9hu5oCv6AGMt4U7KVHkh/DWf5YLaTuUblk20R8ebdhl6HYDbJLbKs7tPUm?= =?us-ascii?Q?UMgH56cyYgKPRzAz2NLRq74ILPo0LHB3V+7RZ9sg+0nO8Nd8Vr9s83WQOVyV?= =?us-ascii?Q?6pWxdqwbOYM6KD/p6efYsxV+?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5063eb4b-46ee-49ac-898f-08d92064a64b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2021 16:38:10.7443 (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: 2rZvcnUWo8fEf8k346gpNgk3tFsFcSkDB0QCdmLVxr5XlevtsX+6YHU0mpqLEWR6Y6iZxVb2d3qWpjreyw4b573uP24cCHJffbuCXDIMZH4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3313
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/gS0pZr7ohYi6D5wru_JQvhtecdE>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2021 16:38:18 -0000

Hi,

>> Unfortunately I don't think what you explain above is very clear in 
>> the text.
>> 
>> Consider the following.
>> 
>> The offerer sends an offer. The offerer specifies the characteristics 
>> that the offerer wants to receive. Similarly, the answer specifies the 
>> characteristics that the answerer wants to receive - the answerer does 
>> NOT specify what it is going to send. which I think the text is 
>> currently describing.
>
> Sorry to sound confused, but maybe you could explain a bit better. To my understanding, it is the offerer that describes what it offers to send, and not the other way around? 
> Maybe I misunderstand something very fundamental? Sorry to ask these elementary questions, but this is important for the text.

In SDP Offer/Answer, the default is to indicate what you are willing to RECEIVE :)

Typically your receiving capabilities also implicitly indicate what you are able to send. For example, if I am indicating that I am willing to receive codec X it normally means that I am also able to send codec X.

 But, there are cases where that is not true, especially when it comes to video codes where you typically have more parameters associated with the codec, and one needs to explicitly indicate sending capabilities. 

---

>> "The receiver SHALL ignore any unrecognized parameter or invalid 
>> parameter value."
>> 
>> First, In my opinion invalid parameters values shall trigger an error.
>> 
>> Second, what is an unrecognized parameter?
>
> I wonder why we need to specify this, i.e. what a receive does about parameters it does not recognize? Essentially, this is a problem of "foreward compatibility". Wouldn't it
> be a matter of implementation whether the receiver accepts an offer (note well, the receiver), and attempts to decode a stream on a "best effort" basis, keeping in mind that
> the stream itself includes additional means to identify required capabilities necessary for a successful decode.
>
> If that is not an option, we would/could need means to identify the type of parameters in a foreward compatible way. I.e., conventions by which we would identify in the future
> parameters a receiver can safely ignore and attempt to decode, and parameters a receiver cannot safely ignore.

I think it is fine to say that unrecognized parameters shall be ignored. It is then up to future specifications to worry about backward compatibility, rather than this specification worrying about forward compatibility.

>> Also, the text does not say what restrictions (if any) there are when 
>> it comes to modify the stream during a session. Is it allowed to 
>> modify any/all characteristics?
>
> My understanding is that you cannot modify characteristics during a session. If you need to modify, you need to setup a new session and cancel the current one. For JPEG XS stream decoders,
> one cannot expect that an instanciated decoder can decode from modified parameters in mid-stream level. That is, if you start decoding in full-HD, and then stream parameters become 8K, the
> decoder will have to abort.

These kind of things need to be specified. I don't think it needs to be forbidden to try to modify something, because there could be text that strongly recommends against doing it.

Regards,

Christer