Re: [MMUSIC] Reviving draft-ietf-mmusic-msrp-usage-data-channel

"Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <> Thu, 21 March 2019 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DE2A130EFA; Thu, 21 Mar 2019 05:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wo9fCUjvW9-l; Thu, 21 Mar 2019 05:57:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10E34130FF3; Thu, 21 Mar 2019 05:55:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d1GOm7NMYssSdLwHmb/cyXUWyFA25sSEcvszZZhO7Ow=; b=qJGfBQs3YcOmxCW9ZSHZlL4M4s96eIF4zBRx3pn1ioMaW3LJTODWswwoLKO16Ju5ENizhsu5en2eXgmrXqNXVbQbl1fssJAS+osDvULjFkhifClsskLi/a9F2UNYxLrdv+7h/c4krcLJbhqORgw23FcyTiluyn6w8bGNhQktXZE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.11; Thu, 21 Mar 2019 12:55:14 +0000
Received: from ([fe80::940b:13c7:a054:a351]) by ([fe80::940b:13c7:a054:a351%2]) with mapi id 15.20.1709.015; Thu, 21 Mar 2019 12:55:14 +0000
From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <>
To: Ben Campbell <>, Flemming Andreasen <>, "" <>, "" <>, Christer Holmberg <>
Thread-Topic: [MMUSIC] Reviving draft-ietf-mmusic-msrp-usage-data-channel
Thread-Index: AQHU2DVgLOqmRnA70kON+TtfZFDXbaYGxK4AgA6tqYCAAHy6oA==
Date: Thu, 21 Mar 2019 12:55:14 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 62204361-b8a9-4c38-5dda-08d6adfc7603
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:HE1PR07MB4236;
x-ms-traffictypediagnostic: HE1PR07MB4236:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0983EAD6B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(396003)(39860400002)(366004)(189003)(199004)(53546011)(256004)(2906002)(7696005)(102836004)(71200400001)(71190400001)(6506007)(25786009)(99286004)(105586002)(106356001)(14444005)(8676002)(26005)(2201001)(14454004)(790700001)(81156014)(966005)(6116002)(81166006)(76176011)(52536014)(3846002)(5660300002)(2501003)(606006)(86362001)(9686003)(8936002)(66066001)(186003)(11346002)(6306002)(236005)(486006)(6246003)(478600001)(97736004)(53936002)(54896002)(33656002)(55016002)(68736007)(7736002)(316002)(446003)(74316002)(110136005)(229853002)(6436002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB4236;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: LKpHiEnJ7ZzlttvjtWlbvU0palwBZXYOdplcBVz2Hm7oGqFs/x9PrSdEYyw8RTmJP4gZmrEsJdR1y75/F5eJlJe+JCUI0YwdNTch/2a0NDzHuMipWpn5p2ZL9z/Cd0gnUTB2rc3K9dPm9VTALMt6CpVlRlpGIc4x4QpHx2MrI8Ycjzxjs3T9JfNv1wQsZFOcBVSoB1XBsO+A5W6Bwd4XnhmZ71e/O/Xyg4swpaci8eHmwSo4nsf490AdtALOsni1I0ryVth9K1ERrCLphbTlWPQrQs4PjMJL9mppaPhIyUi0NzKqQsPoJQdwLpr4vQM7L4SpzFwEMOSVkWxmwumHeepgp5El3RbN/ZTqTFCey/URJIcIXVS1vYyHLHdgJsp2VLTfJgGbotj1j+thmjvVRVJGSU8IVIwjAb87OBNi2uA=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB34663173C252C22F3D09E38992420HE1PR07MB3466eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 62204361-b8a9-4c38-5dda-08d6adfc7603
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2019 12:55:14.0588 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4236
Archived-At: <>
Subject: Re: [MMUSIC] Reviving draft-ietf-mmusic-msrp-usage-data-channel
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: Thu, 21 Mar 2019 12:57:46 -0000


I understand the concern of not losing the WG’s time with pointless work or prolonged idleness.
But here we have a draft that :

  *   Is referenced and used in a published 3GPP specification in link with RCS
  *   Is filling a gap for which 3GPP needs an interworking mechanism (if the draft dies, 3GPP needs to work on another solution)
  *   has been implemented and tested by a number of companies (logically all that have implemented said 3GPP specification)
  *   has at least four people committing to review it and help address its shortcomings, several being implementers
  *   has a committed editor and at least one of the original authors involved , willing to contribute
  *   is part of an ecosystem of msrp live drafts that are making progress
What risk is the WG taking by allowing it to move forward ?

Best regards,
Julien Maisonneuve, Nokia Corporate Standards.

From: mmusic <> On Behalf Of Ben Campbell
Sent: Thursday, March 21, 2019 3:54 AM
To: Flemming Andreasen <>
Cc:;; Christer Holmberg <>
Subject: Re: [MMUSIC] Reviving draft-ietf-mmusic-msrp-usage-data-channel

+1 to what Flemming said. Over the last week a few people have said they would review the draft. I wonder how many would be willing to contribute text.


On Mar 11, 2019, at 1:45 PM, Flemming Andreasen <<>> wrote:

That is correct. As part of that process, the chairs would like to see a reasonable level of interest and contributions from more than just a couple of people.


-- Flemming (with chair hat on)
On 3/11/19 2:08 PM, Christer Holmberg wrote:

As far as I understand, the WG will have to agree to continue the work, as the draft has been declared “dead” and removed from the list of deliverables.



From: mmusic <><> on behalf of "Makaraju, Raju (Nokia - US/Naperville)" <><>
Date: Monday, 11 March 2019 at 15.44
To: ""<> <><>, ""<> <><>
Subject: [MMUSIC] Reviving draft-ietf-mmusic-msrp-usage-data-channel

After a pause, we are putting renewed efforts to revive, resume draft-ietf-mmusic-msrp-usage-data-channel<> and complete the document to make it as an RFC.
This document is complete for the most part with some remaining comments, alignment with drafts/RFCs it refers to to be incorporated.
3gpp refers to this draft for MSRP over data channels interworking with MSRP/TLS (or TCP) and Nokia has an active implementation on as part of 3gpp ePCSCF based on this draft as well for this. Without reviving this draft 3gpp will remove the reference, but sooner or later an equivalent draft may have to be written (thus need to start fresh).

Julien will be representing Nokia for this draft while Jose M Recio <<>>  (thank you both!) and I will be providing  support for the technical discussion and most of the technical updates to the draft.

As usual, please provide your comments, concerns on this revival.

Thanks for your support!


mmusic mailing list<>

mmusic mailing list<>