Re: [MMUSIC] T140: Usage of "-"fmt value in dcsa encapsulated fmtp attribute

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 13 December 2019 23:27 UTC

Return-Path: <pkyzivat@alum.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 B852B120089 for <mmusic@ietfa.amsl.com>; Fri, 13 Dec 2019 15:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=alum.mit.edu
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 gD-QAxlcXmOD for <mmusic@ietfa.amsl.com>; Fri, 13 Dec 2019 15:27:46 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2061.outbound.protection.outlook.com [40.107.244.61]) (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 C107912013D for <mmusic@ietf.org>; Fri, 13 Dec 2019 15:27:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dk0PWp5yY5dTP5x7odD9wksgSUDe/0gXTnWGkQSa1jpBW2Nu5yx9kXuki/IPZcP1IKV+fxaUY0Rzd1pZEL8X74wfVjwnulhx9YaKSpekXAwvKUqTiqXn6r/QcvrlMLA4UGqkz0NcPchNxSVQ6gIoPN8vER47kAUEyMtk9qBQxvY76cD4L6XJ9vVJwPHmrRTr82OaNhicQlDXF1oSPRF3NLgQUuNCFRpn9j/24mya0+xBTxNw685FZVv5xSGO50xcwuYo33paR0/dh2w77sUV00mthUCfnAznNNfLHwMkGMQBTKw4nH3mhb47prWNmw+ZF6xJ8PNy9bmWv+f8dUEWVg==
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=DuKDd6cHQ0cjQg0N6xzbLmDU3eaAr+tBlgy5rXgFcQo=; b=etdEpYgqTAR0BCdGnEXIMMXIfUU2HjaY7SFyAJvP20B+JfgbDu5RXqySm6uA/Wx0XJus0Iuwl3LLifya7C8douWmWUTX5ugJ9LovaIJBFLOxfQU7qRkQWV/Df7Neh4ju7XsyrXLk5Fbc7x1lgr76eGAkDVObXfwYK04EtRXm1BFh5Gm3zubgFRTdQGpS5tceQg3Qo9vV6PHrESUgumRfCYkCS8Zd8RM21X/+9o5tYcFLYONxfuhTZ2LDLnsReIaqeKXQjZjNcg/gnZJVW8VjH0dCQ7/4QcJBVbimRxTSFIOIaW5DlCTCUBmfO5RYkRJbjnUEpcBVEtZ2gExUOpFLgA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DuKDd6cHQ0cjQg0N6xzbLmDU3eaAr+tBlgy5rXgFcQo=; b=i4NPtRFpMXTyLoKTwFjB2GOeGVECmWNvUD07BLzvJUqFwyIBeY1VE/wcYCVQ1F+07cnknJ7r8zWQ2b/cDOlsmnoxdT+mO2pr93GkYAiNJuMAba4g+ITJF1+x/cYyuJt02YmNGVOqam76Q0oCDH721wb0mgLYXqAT5lXrdwF/huc=
Received: from SN2PR01CA0081.prod.exchangelabs.com (2603:10b6:800::49) by DM5PR12MB1770.namprd12.prod.outlook.com (2603:10b6:3:108::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18; Fri, 13 Dec 2019 23:27:45 +0000
Received: from SN1NAM02FT043.eop-nam02.prod.protection.outlook.com (2603:10b6:800:0:cafe::c1) by SN2PR01CA0081.outlook.office365.com (2603:10b6:800::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15 via Frontend Transport; Fri, 13 Dec 2019 23:27:45 +0000
Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT043.mail.protection.outlook.com (10.152.72.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14 via Frontend Transport; Fri, 13 Dec 2019 23:27:44 +0000
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id xBDNRgFE005848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Fri, 13 Dec 2019 18:27:43 -0500
To: mmusic@ietf.org
References: <DB6PR0701MB24219718E7408022DB6F256493550@DB6PR0701MB2421.eurprd07.prod.outlook.com> <1b757fea-b5ce-c498-8100-cb54a4a431fa@omnitor.se> <5FF684F2-955E-4E52-AED5-69D9EA8D39F5@ericsson.com> <dc08b134-7c31-e466-3fcd-287105c1f455@cisco.com> <8CBAF448-882E-4C0C-96AD-8DCFF3D06BD2@ericsson.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <32338b16-b79c-abac-0031-b6f7677627ff@alum.mit.edu>
Date: Fri, 13 Dec 2019 18:27:42 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <8CBAF448-882E-4C0C-96AD-8DCFF3D06BD2@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(376002)(346002)(189003)(199004)(336012)(86362001)(966005)(26005)(956004)(186003)(75432002)(36906005)(6916009)(2906002)(316002)(786003)(31686004)(8936002)(31696002)(76130400001)(53546011)(8676002)(478600001)(70206006)(26826003)(356004)(246002)(5660300002)(7596002)(4001150100001)(70586007)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR12MB1770; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 9646f91c-e248-4d4f-8335-08d780240e55
X-MS-TrafficTypeDiagnostic: DM5PR12MB1770:
X-Microsoft-Antispam-PRVS: <DM5PR12MB1770928455A2EDB6C911850FF9540@DM5PR12MB1770.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0250B840C1
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: /0gPy5tE2rfau+JUoML6FekI0fv0wtfvZ2Z9vH+P+ppHMQGZPV8WiuCULafaBOx851+dPWBCli5Xaa1NDW1um3c8UZ4GxOrlj+ZW9KIXh5/gYnC7ivtFXqVgLzrpfTvlySbCwwK0pxTO+Iy18fPPC9gS52ljJssDjD1ZjS1vWZgnSHdTMcvMHBZasq3w3hr65SEsmIMWWU/jgZkKyf28tRJxO6EPe4yzgTulp8TBjw6+eifn4naBs14CVZZWKVo01TxXT67JTP/X7upm1QX1RfAfiSI95eOIon6xrEa3qycD/Rw3YlEbauLauA5ig+OLl/C70oXy/48ZoimVy6Rshlf9dtASi5xVXdBAs/jXOLDaj9d1XprIKR5OiON9al5wZpqTzll4e8LZ4RR1OYqCkNBXzbkDHSu9r2ZLOtSVyLS3mozgjfLTchqUhmMA08avLhCa7HazIMry40RNraYgNsOcAP+PCPy8UlYNrUFNVH4=
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2019 23:27:44.2396 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9646f91c-e248-4d4f-8335-08d780240e55
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1770
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/xYXDQaOZak70DWxmlaesUmq08fE>
Subject: Re: [MMUSIC] T140: Usage of "-"fmt value in dcsa encapsulated fmtp attribute
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: Fri, 13 Dec 2019 23:27:50 -0000

On 12/13/19 3:30 PM, Christer Holmberg wrote:
> Hi,
> 
> ...
> 
>>>> The question is whether it in such definition is allowed to "override" the 4566bis statement saying that the format
>>>> must be one of the formats specified for the media. As far as SDP is concerned, the only format is 'webrtc-datachannel'.
>>>
>>> Again, I personally think we should keep "-" (I don't like to omit information elements), and add whatever text needed to
>>> indicate that the 4566bis text does not apply to sub-protocol specific fmtp attributes.
>>
>> Syntactical consistency and strict adherence to the wording in 4566bis would argue for "webrtc-datachannel",
>> whereas conceptual consistency would argue more for "t140". I'm not in favor of "-", since it doesn't seem to add anything.
> 
> There is nothing to add, and that's why we are using "-" to indicate that. I believe there are cases where we use "-" for the fmt in the m= line, aren't there?
> 
> Having said that, if the community prefers "webrtc-datachannel" I can live with that. I think it is a waste of characters, but the ship to keep SDP bodies small and compact sailed a long time ago, so... :)

IMO using "webrtc-datachannel" would be wrong and confusing.

Using the subprotocol would make sense, but is then redundant. Using "-" 
seems reasonable to me.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> Den 2019-12-12 kl. 20:12, skrev Christer Holmberg:
> Hi,
> 
> When the chairs reviewed the T.140 data channel usage draft, the following issue was raised:
> 
> Currently, when we send an fmtp attribute encapsulated in a dcsa attribute, we use "-" as the fmt value.
> 
>       Example: a=dcsa:2 fmtp:- cps=20
> 
> However, 4566bis says the following about the fmtp attribute:
> 
> "The format must be one of the formats specified for the media."
> 
> Now, the format is 'webrtc-datachannel', so one could claim that should be used.
> 
>       Example: a=dcsa:2 fmtp:webrtc-datachannel cps=20
> 
> 
>   But, that applies to the whole SCTP association, and the dcsa attribute is associated with a specific data channel usage. In addition, the usage and syntax of the fmtp attribute may vary depending on data channel usage.
> 
> Another option could be to include the sub-protocol:
> 
>       Example: a=dcsa:2 fmtp:t140 cps=20
> 
> 
> But, the dcsa attribute already maps the fmtp attribute to the sub-protocol.
> 
> 
> So, what to do?
> 
> 
> My personal suggestion would be to keep "-", and perhaps add a note somewhere. Not sure we would need to update 4566bis, but if people want to do that we could for sure do it.
> 
> Anyone having a different opinion?
> 
> 
> Regards,
> 
> 
> Christer
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mailto:mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>