Re: [MMUSIC] Data channel dcsa attribute usage and IANA

"Roni Even (A)" <roni.even@huawei.com> Thu, 29 August 2019 14:46 UTC

Return-Path: <roni.even@huawei.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 62B081200F4 for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 07:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wn6wQQ-OqyMd for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 07:46:25 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D789C1200C3 for <mmusic@ietf.org>; Thu, 29 Aug 2019 07:46:24 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2445F3AFF81F784B4709 for <mmusic@ietf.org>; Thu, 29 Aug 2019 15:46:22 +0100 (IST)
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 29 Aug 2019 15:46:21 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.195]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0439.000; Thu, 29 Aug 2019 22:46:15 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Data channel dcsa attribute usage and IANA
Thread-Index: AQHVXkujg9M91RaR+EiTe/MX9Cr3VacR4OVQ///CqwCAAI+loA==
Date: Thu, 29 Aug 2019 14:46:15 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD23D43BA4@dggemm526-mbx.china.huawei.com>
References: <FA58AC4B-B7CF-488A-A287-ACB14C9D9056@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD23D439E1@dggemm526-mbx.china.huawei.com> <e209505e-3ff6-7cd3-c3b6-7cfec897c98b@alum.mit.edu>
In-Reply-To: <e209505e-3ff6-7cd3-c3b6-7cfec897c98b@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/sflAaxEzZWSzjYCVSCs408DpYEM>
Subject: Re: [MMUSIC] Data channel dcsa attribute usage and IANA
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, 29 Aug 2019 14:46:28 -0000

Hi,
I think that it does not make sense to a usage level as dcsa without the subprotocol. 
 If there was such usage it should have been defined in the draft-ietf-mmusic-data-channel-sdpneg document or in a non subprotocol specific document for general use.
Roni

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Thursday, August 29, 2019 5:08 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Data channel dcsa attribute usage and IANA

On 8/29/19 5:49 AM, Roni Even (A) wrote:
> Hi,
> 
> I think that dcsa(subprotocol) would have been enough, at least based 
> on channel-sdpneg document, maybe Paul can help

I'm sorry that this is coming up so late. In retrospect I think it deserved more discussion about how this is to work. IIRC this got tucked in quite some time ago, early in the definition of dcsa.

I don't recall why both forms are shown. I don't know what "dcsa" alone would mean. The guess it could be a wildcard meaning that it can be used with all subprotocols. But that doesn't make any sense to me.

So I'm inclined to only use the "dcsa(subprotocol)" form. Perhaps we should file an errata against rfc4566bis as soon as it becomes an RFC.

	Thanks,
	Paul

> Roni
> 
> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> *Sent:* Thursday, August 29, 2019 12:25 PM
> *To:* Roni Even (A); mmusic@ietf.org; pkyzivat@alum.mit.edu
> *Cc:* mmusic-chairs@ietf.org
> *Subject:* Re: [MMUSIC] Data channel dcsa attribute usage and IANA
> 
> Hi,
> 
> One question for clarification:
> 
> Section 8.2.4.1 of RFC4566bis says:
> 
>        “Usage Level: Usage level(s) of the attribute.  This MUST be 
> one or
> 
>        more of the following: session, media, source, *dcsa and*
> 
> *      dcsa(subprotocol)*.”
> 
> …and in the Table in Section 8.2.4 it says:
> 
> “dcsa,dcsa(msrp)”
> 
> Q1: Why does it need to say both ‘dcsa’ and ‘dcsa(subprotocol)’? Isn’t 
> it enough with ‘dcsa(subprotocol)’?
> 
> Regards,
> 
> Christer
> 
> *From: *mmusic <mmusic-bounces@ietf.org 
> <mailto:mmusic-bounces@ietf.org>> on behalf of Christer Holmberg 
> <christer.holmberg@ericsson.com 
> <mailto:christer.holmberg@ericsson.com>>
> *Date: *Thursday, 29 August 2019 at 11.27
> *To: *"Roni Even (A)" <roni.even@huawei.com 
> <mailto:roni.even@huawei.com>>, "mmusic@ietf.org 
> <mailto:mmusic@ietf.org>" <mmusic@ietf.org <mailto:mmusic@ietf.org>>
> *Cc: *"mmusic-chairs@ietf.org <mailto:mmusic-chairs@ietf.org>" 
> <mmusic-chairs@ietf.org <mailto:mmusic-chairs@ietf.org>>
> *Subject: *Re: [MMUSIC] Data channel dcsa attribute usage and IANA
> 
> Hi,
> 
> Thanks for the information! The last paragraph clarifies it.
> 
> So, draft-t140-usage-data-channel will update the IANA registry for 
> the SDP attributes used inside the SDP dcsa attribute.
> 
> Regards,
> 
> Christer
> 
> *From: *"Roni Even (A)" <roni.even@huawei.com 
> <mailto:roni.even@huawei.com>>
> *Date: *Thursday, 29 August 2019 at 11.08
> *To: *Christer Holmberg <christer.holmberg@ericsson.com 
> <mailto:christer.holmberg@ericsson.com>>, "mmusic@ietf.org 
> <mailto:mmusic@ietf.org>" <mmusic@ietf.org <mailto:mmusic@ietf.org>>
> *Cc: *"mmusic-chairs@ietf.org <mailto:mmusic-chairs@ietf.org>" 
> <mmusic-chairs@ietf.org <mailto:mmusic-chairs@ietf.org>>
> *Subject: *RE: Data channel dcsa attribute usage and IANA
> 
> Hi Christer,
> 
> To add to Paul’s response
> 
> Look at the last 2 paragraphs of section 5.2.1
> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-28#s
> ection-5.2.1
> 
> Roni
> 
> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer 
> Holmberg
> *Sent:* Wednesday, August 28, 2019 1:33 PM
> *To:* mmusic@ietf.org <mailto:mmusic@ietf.org>
> *Cc:* mmusic-chairs@ietf.org <mailto:mmusic-chairs@ietf.org>
> *Subject:* [MMUSIC] Data channel dcsa attribute usage and IANA
> 
> Hi,
> 
> Section 7.2 of draft-ietf-mmusic-msrp-usage-data-channel updates the 
> IANA registry for the SDP ‘setup’ attribute, by indicating that it can 
> be used inside an SDP ‘dcsa’ attribute.
> 
> Do we really need to update the IANA registry for all SDP attributes 
> that can be included in an ‘dcsa’ attribute???
> 
> There is no text in draft-mmusic-data-channel-neg about having to 
> modify the IANA registry for such attributes.
> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic