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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 13 May 2020 18:16 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 4F6F13A0743 for <mmusic@ietfa.amsl.com>; Wed, 13 May 2020 11:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, 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 Ms303IALMFIs for <mmusic@ietfa.amsl.com>; Wed, 13 May 2020 11:16:49 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::627]) (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 2E74D3A0736 for <mmusic@ietf.org>; Wed, 13 May 2020 11:16:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ArLs7dmI974CEtuGYBgbUZLgLAgPJVMpPY6aOW9tgof4Yg3lA/DfhLJ/Bn+FOWdNOeDIWETt607cHgv5q6k94V/A8H11ymRquouovXCB7il7e9flvs3UsO0nCi4Y7oTVv2CuvC5l9wYoxG0tIArCZux0wlXxSu9/ZaU0YWetj0rckLzhoQ3vPeMdZR+OeJJ4UDaMZfNsTwId9ZzmV7Q+h7ZBPY8UCfdwSBLJcteF5SEcgNwoucSYf97VBl52jtH0IL+um12M5nIBwK2JcAuNLBauRpbT3yjONw6rNnsYQ21n+8CLcslZLvsVUvUGaYhZonOAAc9tzG7HIPmJj5jkSw==
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=nuk8lZalCQgWAwMWtLTtu41whOQtzRwOSs3hHFGw/rA=; b=NZ1Mpw9XEPHY9pTmkHlAzWhSVz6bT0TC/3dwKQpEKDr3665VEn4wvEd2HVjtfXlkwJYbEhG+bLpitPT982tADOa1sIVvvb76FChvf+ApiN2JoOHTlTsRaMofbmTvl3NYXJcPfNXpbraTQ9FOvGNYvkLjAKXrYPuQRHnXH8+WuIIylI1J1gs0bV0h89IgEmGILoJ7Ie8FXmAOJ/EA4HO2z7ksqQKD71atr97yYia43sSRChdJQtpc9dGdgDyWpPYjoZJ2hiev8afJHbWqrqP2wJCTZP9nVYAMa952R7chX5g0pscA38qZC9lVrfxW6TQqlzew174aHPcI7S4rvg7zAQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none 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=nuk8lZalCQgWAwMWtLTtu41whOQtzRwOSs3hHFGw/rA=; b=YbcdBFCKQwzU5y9Svfn2g0+BXKTlYosnYfYVUBtSW1zuAJFFpvBJyeA41T8K//03sbMm7nsomo3U5fZQ8zaNVNdqm9q1POXuS/6vQsUQzOR15cgQ3asNZqhEBGzf2rdg3mJG8CAy0YwgGfRBGRmitxuH50EPASl71osRS3HCUlo=
Received: from SN4PR0401CA0016.namprd04.prod.outlook.com (2603:10b6:803:21::26) by MW2PR12MB2490.namprd12.prod.outlook.com (2603:10b6:907:9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20; Wed, 13 May 2020 18:16:47 +0000
Received: from SN1NAM02FT032.eop-nam02.prod.protection.outlook.com (2603:10b6:803:21:cafe::f8) by SN4PR0401CA0016.outlook.office365.com (2603:10b6:803:21::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.30 via Frontend Transport; Wed, 13 May 2020 18:16:47 +0000
Authentication-Results: spf=permerror (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=none action=none header.from=alum.mit.edu;
Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism)
Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT032.mail.protection.outlook.com (10.152.72.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29 via Frontend Transport; Wed, 13 May 2020 18:16:46 +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 04DIGi0w023703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Wed, 13 May 2020 14:16:45 -0400
To: 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> <822e1c54-77fd-bf15-1139-94a8e08442aa@alum.mit.edu> <F8C86ECB-9489-40AD-8BA0-CF89EC370CF2@ericsson.com> <308616ac-cd24-341e-be31-4b348d803889@alum.mit.edu> <E3EB3037-335E-4121-AA72-230B7353CEDF@ericsson.com> <668DE0D3-8E9E-4137-87DC-620858F05DA5@ericsson.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <43071726-f305-a620-6529-db7d42752959@alum.mit.edu>
Date: Wed, 13 May 2020 14:16:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <668DE0D3-8E9E-4137-87DC-620858F05DA5@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; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(39860400002)(376002)(136003)(346002)(396003)(46966005)(33430700001)(956004)(2616005)(966005)(82740400003)(5660300002)(316002)(33440700001)(47076004)(2906002)(336012)(786003)(8936002)(8676002)(86362001)(31696002)(82310400002)(53546011)(75432002)(186003)(70206006)(36906005)(31686004)(70586007)(478600001)(7596003)(6916009)(356005)(26005)(383974003)(43740500002); DIR:OUT; SFP:1101;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b61b136c-74e7-4647-3198-08d7f769cc42
X-MS-TrafficTypeDiagnostic: MW2PR12MB2490:
X-Microsoft-Antispam-PRVS: <MW2PR12MB2490939387CF5B5BB6FEF273F9BF0@MW2PR12MB2490.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:6108;
X-Forefront-PRVS: 0402872DA1
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Jl+oTFk7Jo2nHaD1VZDU0KdQQOZMc4w36pO9qTT+Ajf2e3KYz8zTzrtmeLvtU/WlWAkYzLGRZhv1q0OHTeGbkicWLHIGOo3NukXXRkYwWXsn9HrklOdohyPwB+5YkHR/6cVRdnseKs5tk04E9ydht7Z8fHisen9PCnuQBUJO3MxjDpuDAf9IPEMRV8r9uAL8V4sZ1oEwyIcq0mkUcZu2NJpp6alCfGGVLjfGJUKCF7ktNXLcIJuasD3lIxHtXxjFcM888u2OHGJln+6HgJDjc41hfG/JHRKpqJvDC8ytod7UetYLi+caOY5qQCDh+Cw+GJEbWesQI86bpMQuu8uvKiTapGk5rvX8lMcOUPL5rcQdDvsGvFt3ZthKNq8HOgDB12D7OvEGY2GVDNAcgQ4ZfriRTLjlNvEk8OgwTdOO+XGXiWCBQIblhSFJX7D7YiQ1s0F0tASKLNFagCz0QaA34wfpGePt54QM4P3r+kLdBfAXlhx+wV4Dy3ygA1BpovCNAQoCsuFi+IzCTyIaFTAJBVgwi0LtPVOmqaupfOPfhNKiBEz+gbM8tA1Kt33BuS/mNXYOWtdrgXfsMqbTyOb7m4u0DeEY/2V8uo2k1X4qEnxS8OdlAgNVZzmJToVqFIEiTxqHQ8FFeLGBamEbs0RHBTMKWegflI0Yi+L7ELueijtvRqZ+1PEajHeLjUb7dSTYjDoTi32tm2flkAnz0EviaA==
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2020 18:16:46.3596 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b61b136c-74e7-4647-3198-08d7f769cc42
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: MW2PR12MB2490
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/D_qf0CusUloCUrnbQyvn9_p7tM8>
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: Wed, 13 May 2020 18:16:52 -0000

On 5/13/20 1:21 PM, Christer Holmberg wrote:
> One more thing: if you by "destination" mean the IP address and port of the remote peer, you get that from the c/m- line.

And where does *the* m line get the fqdn/ip from???

Assume you gave me your msrp address once, and I have it in my address 
book. Today I decide I want to chat with you. I need to set up a session 
with you, and your msrp url is what I have to work with.

Because the URL has the "dc" parameter I can infer that I will need a 
data channel. I must set up the the DTLS session and then create a data 
channel to do that. How do I know what to put into the c/m- line? Are 
you saying that I need some *other* information about you before I can 
do that? Or can I derive the c/m- line data from it?

For that matter, to be doing O/A, I need a sip connection. How do I 
figure that out?

	Thanks,
	Paul


> Regards,
> 
> Christer
> 
> On 13/05/2020, 20.18, "mmusic on behalf of Christer Holmberg" <mmusic-bounces@ietf.org on behalf of christer.holmberg=40ericsson.com@dmarc.ietf.org> wrote:
> 
>      Hi,
> 
>          >>>>>- Added text to make more clear the scope of path and MSRP URI:
>          >>>>
>          >>>>>Data channels are negotiated independently of the value of the "path"
>          >>>> attribute. This means that when MSRP messages are transported on a data
>          >>>> channel, the "path" attribute
>          >>>>
>          >>>>>is not used for transport negotiation or routing of the messages. MSRP
>          >>>> endpoints using data channels can set the value of the "path" attribute,
>          >>>> including the MSRP URI, and use it as described in RFC4975
>          >>>>
>          >>>> 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]."
>          >>>
>          >>> I'm concerned that this might imply that an msrp(s) URI is not
>          >>> sufficient information to establish communication. (That some additional
>          >>> information, received out-of-band, might be a prerequisite.)
>          >>>
>          >>> Do you intend that to be a possible situation?
>          >>>
>          >>> I would hope that it is not - that an msrp(s) URI is sufficient. In that
>          >>> case, both the transport setup and the path attribute would be derived
>          >>> from the same source.
>          >>
>          >>      I am not sure I understand....
>          >>
>          >>      The MSRP URI is *not* enough to establish the SCTP association and the data channel. The procedures
>          >>      for establishing a data channel are defined in [I-D.ietf-rtcweb-data-channel], and then each usage have some specific attribute values etc.
>          >>
>          >>     We are not modifying the procedures how to establish a data channel - we are defining how to send MSRP messages over a data channel.
>          >
>          > [I-D.ietf-rtcweb-data-channel] defines *procedures* for establishing a
>          > data channel, just as SIP provides procedures for establishing a sip
>          > session. In both cases, those procedures must be parameterized. In the
>          > case of SIP a sip URI is generally sufficient. (In some environments you
>          > might need some extra environmental information, such as how to get
>          > yourself registered first and the need to use an access proxy.)
>          >
>          > In this case, the msrp(s) uri should provide all the parameterizing
>          > information I need to send msrp messages to this destination, over and
>          > above info about my environment and basic standards. The "dc" parameter
>          > in the URI tells me that I need use a data channel.
>          >
>          > I shouldn't need to supply any extra information *about the destination*.
> 
>          You know that you are going to send the MSRP message on the data channel - that's all you need to know.
> 
>          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
>