Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25

"Roni Even (A)" <> Sun, 14 April 2019 05:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE98F12014C for <>; Sat, 13 Apr 2019 22:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Cei2pWslr3S for <>; Sat, 13 Apr 2019 22:37:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CA8712014A for <>; Sat, 13 Apr 2019 22:37:22 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id B3DFCC2F1FFA600FB50B for <>; Sun, 14 Apr 2019 06:37:19 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 14 Apr 2019 06:37:19 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Sun, 14 Apr 2019 13:37:13 +0800
From: "Roni Even (A)" <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
Thread-Index: AdTwT5OIKFVlXaa2S8ClvVSnITuzDv//4tSA//t+d7A=
Date: Sun, 14 Apr 2019 05:37:13 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 Apr 2019 05:37:25 -0000

Hi Paul,
Section of (normative reference in SDPNEG) registers usage level dcsa and dcsa (subprotocol) for the IANA att-field and point at the data-channel-sdpneg document for the definition. I think it will be simple to keep as is and just have the definition  in sdpneg but I have no strong feeling. So just decide, if you change RFC4566bis , we will need to keep section 9.3 in data-channel-sdpneg and just clarify what we register.


-----Original Message-----
From: mmusic [] On Behalf Of Paul Kyzivat
Sent: Thursday, April 11, 2019 7:32 PM
Subject: Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25

On 4/11/19 6:34 AM, Roni Even (A) wrote:
> Hi,
> I got the following comment from IANA:
> Third, Section 9.3 of the current document appears to request the 
> creation of a new registry in the Session Description Protocol (SDP) 
> Parameters registry located at:
> IANA Question --> The new registry might be modeled upon the existing 
> att-field (. . . level) registries but instead be a registry for 
> att-field (dcsa level). Is this correct? Would the new registry have 
> the same characteristics as other att-field registries on the registry page?
> Could the draft be revised to explicitly create the registry, if this 
> is correct? Are there any initial registrations in this new registry?
> My response was
> We are not asking for a new registry,  see
> 5 for  the Reorganization of the att-field Registries.  I now think 
> that this third action is not really needed since it is now defined in 
> rfc4566bis section 8.5 and 8.4
> So I suggest to remove section 9.3 and add to the end of section 
> section
> 5.2.1

ISTM we actually got a little ahead of ourselves in 4566bis by mentioning dcsa and msrp-usage-datachannel.

While 4566bis reorganizes the attribute registries so that we don't need a new registry for dcsa, is is draft-ietf-mmusic-data-channel-sdpneg
that defines the dcsa usage level. The publication of it should result in addition of a reference to it in the attribute registry. So I think we need an IANA action just to accomplish that.

And maybe the references to dcsa and msrp-usage-data-channel should be removed from 4566bis if it isn't too late to do so.

I don't find section 5.2.1 to be an appropriate place for this kind of information.


> A data channel specific usage of a subprotocol attribute is expected 
> to be specified
>     in the same document that registers the subprotocol's identifier 
> for
>     data channel usage.
>          SDP attributes that are only defined for use at the
>     dcsa usage level, SHALL use the dcsa usage level when registering 
> the
>     attribute.  If existing media attributes are used in a datachannel
>     subprotocol specific way, then a new dcsa usage level
>     MUST be defined for the existing media attribute.  Where the SDP
>    attribute is applicable to a particular subprotocol/s this SHALL 
> also
>     be registered by indicating the applicable subprotocol identifiers
>     (see
> 5)
> along with the dcsa usage level.
> Roni Even
> _______________________________________________
> mmusic mailing list

mmusic mailing list