IETF Logo Mail Archive

Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

Jose M Recio <jose@ch3m4.com> Thu, 14 May 2020 09:29 UTC

Return-Path: <jose@ch3m4.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 E181D3A0845 for <mmusic@ietfa.amsl.com>; Thu, 14 May 2020 02:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ch3m4.com header.b=B01OWbJx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IJvXjYqA
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 xtpX-PBjr2qC for <mmusic@ietfa.amsl.com>; Thu, 14 May 2020 02:29:38 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F323A0842 for <mmusic@ietf.org>; Thu, 14 May 2020 02:29:38 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DFA40AF2; Thu, 14 May 2020 05:29:36 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 14 May 2020 05:29:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ch3m4.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=4vHQlbZTck6yUVwBRorWtsYbStI a/TXebyvxzQXpWeg=; b=B01OWbJxzFIaiFHm7bt/DPN3ZM92h1LNvyUclPe/gel wyAqc1LV/zMGEU47A09/PPTnOh2ci+k7r9OR2ccsQvZHpUM/Ifjfe7d3ZW75+qFO UW1XEKdklXa7gkGfxwBISvLLtFqtigHwgjt7J3aFGsKlBR3exAhgFB4At7WM5D8e AbuPWSNf1a2YEsel4cUVHNK4xb3tv6dR1bLOf0lWq6Cvf6+LJrO+tKxgnLaXQ4ua GMcn7Ob8zOHpO2TnumIkNfXc16Ptb9Y4wk6Qeo0/j91npmljlR7YtiGtTvI1IX9s NedNwyCeNU4ON3dyLzZ+KXd90aIQ6pO+MrDcebpCiCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=4vHQlb ZTck6yUVwBRorWtsYbStIa/TXebyvxzQXpWeg=; b=IJvXjYqATAq8HtaFZUY54R R6fPQgTfS/GqKVG2EsvCS+2WQDv5nit8fvnXmpJO5QekmrvD2BsIsRNvZLCVsY1G wtNZUxROeQ7DOAslOuntXwsW4gHfQIoCjKoVIyTOSRH11ugWeJBe9kTp20lkscbv hTbTVN4HOJ/58GuwClcGw3LMYo3u5Eh5mEs3P32Wjww8s8C136nCrUMGIIrjXatR Aw/B6BP/PyDErbUILOpPwHVN0V9KL6ircAVxC17EXPvhvBCUEAKZaBEsUja5XvR7 rzBWVX/K+L+cVLn3QpVvLJmu6pVs8QWPF4AirEOFSed6OzOfdgVnYPi28GuHBDCQ ==
X-ME-Sender: <xms:gA-9XqAJun6q5fZo-FhYL7WGJ8UAiCRiPGYDhwFz7A5qjQtYAI6Ekg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleeigddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomheplfhoshgvucfo ucftvggtihhouceojhhoshgvsegthhefmhegrdgtohhmqeenucggtffrrghtthgvrhhnpe fgvdekffdtgfeugfdtiedvudfhtdelgedtjeevkeetueegkefgleefudeujeejvdenucfk phepudefkedrjeehrddvudeirdegtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehjohhsvgestghhfehmgedrtghomh
X-ME-Proxy: <xmx:gA-9Xkj1UQHnSQ253PxTbWFWE_icuhHiUaj_fDYpw74jl__sawxtNA> <xmx:gA-9Xtl3BLhLE4cWtTjm3X34MarpCIIqBfvo-Twe2cHR90ySe5mbDQ> <xmx:gA-9Xoxpg0xD4v33rWm5bDdwXI1eRBZc_xmY3ZLXAHQEgfiQ149szA> <xmx:gA-9XmcIZjLv1cnEj4dqoJiRKvGwoDcU2IKF-64Xj6T5vWbchmh1SA>
Received: from [192.168.0.102] (unknown [138.75.216.40]) by mail.messagingengine.com (Postfix) with ESMTPA id 799A5328005A; Thu, 14 May 2020 05:29:30 -0400 (EDT)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <HE1PR07MB4426ADA1E4B1D696A48BA9A98DA40@HE1PR07MB4426.eurprd07.prod.outlook.com> <66bc33b6-8a66-1da3-93c0-e7ddc31cc605@alum.mit.edu> <2F549E6E-1250-426F-8602-99CB44C84365@ericsson.com> <ef5b4ef8-4063-e38e-d300-185a933cc3dc@ch3m4.com> <AM7PR07MB7012D222A4AF5FD13FCC8C3793A00@AM7PR07MB7012.eurprd07.prod.outlook.com> <a3210a85-e69d-2bfc-a802-7649c70a6534@ch3m4.com> <60ab60db-f81a-904a-0481-935fa3156a9e@ch3m4.com> <80F9E944-16A1-4D14-8691-181A6089B4D1@ericsson.com>
From: Jose M Recio <jose@ch3m4.com>
Message-ID: <a44b2bcd-0877-3fe3-a554-df45ab8cf5e1@ch3m4.com>
Date: Thu, 14 May 2020 17:29:23 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <80F9E944-16A1-4D14-8691-181A6089B4D1@ericsson.com>
Content-Type: multipart/alternative; boundary="------------E0E1F506255BEE0241082CE6"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/65--h-3e_MJFmLJfENZZM1Et89U>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
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, 14 May 2020 09:29:40 -0000


On 12/05/20 20:32, Christer Holmberg wrote:
> I think we need to be a little more explicit, so I suggest something like:
>
> "When MSRP messages are transported on a data channel, the "path" 
> attribute is not used for routing of the messages. The MSRP data 
> channel is established using the SDP offer/answer procedures defined 
> in [I-D.ietf-rtcweb-data-channel], and the MSRP messages are then 
> transported on that data channel. Because of that an MSRP endpoint can 
> set the MSRP-URI authority value of the "path" attribute at its own 
> discretion, following the syntax and rules in [RFC4975]."
>
Thanks, this looks very good

> >- Updated examples removing the port
>
> Actually, I realized that 4975 mandates a port, so I think we should 
> keep it.
>
This was overlooked, reverted

> >- Replacing all SHALL with MUST for consistency
>
> I think we should do it. Currently it’s 50/50, without any logic 
> behind when SHALL or MUST is used.
>
Done

v2.23.0 | Report a Bug | By Email