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

From: Bo Burman <[email-masked]>
Date: Wed, 6 May 2020 15:20:53 +0000

Greetings MMUSIC ,

This is to announce a 2 week WGLC on the draft:

https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-data-chan
nel-16 

as Proposed Standard. Please review and provide any comments you may have on
the document by

Wednesday, May 20, 2020.

Comments should be sent to the document authors and the MMUSIC WG list.

If you review the document but do not have any comments, please send a note
to that effect as well. 

Thanks,

/Bo

(MMUSIC co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 7 May 2020 12:01:12 -0400

(Its good to see this is almost done!)

I took a fresh look at the document. I found a number of small things 
but nothing monumental:

1) NIT:

In Section 3.1, in the table, the value for Label has a lot of white 
space between "See" and "Section 4.3". It would look better with a 
single space.

2) MINOR ISSUE:

In section 4.1, the abnf says:

    transport  /= "dc" / 1*ALPHANUM

The /= means this is an added alternative to what is present in RFC4975. 
Hence it is equivalent to:

    transport = "tcp" / 1*ALPHANUM / "dc" / 1*ALPHANUM

What you should really have is just:

    transport  /= "dc"

3) NIT:

Section 4.4 says:

    An offerer and answerer MUST include a dcsa attribute for the
    following MSRP-specific SDP attributes:

I suggest: s/for the/for each of the/

Similarly, where it says:

    An offerer and answerer MAY include a dcsa attribute for the

I suggest: s/for the/for any of the/

4) QUESTION:

Does section 4.6 this mean it is an error to use SDP to close the 
DTLS/SCTP association (via m=0) without all the added SDP attributes to 
close each data channel?

Could it not be implied that closing the association implicitly closes 
all the data channels?

5) QUESTION:

The example in section 4.8 includes use of the "path" attribute. How 
does that square with the following in section 4.4:

    The path attribute SHALL NOT be used for transport negotiation.

I guess you mean that some usages of path are ok and others are not. 
Could you be more explicit about this?

6) ISSUE:

Section 7.1 registers "MSRP" as if it was a totally new websocket 
protocol name, but it isn't. It is already registered as a websocket 
protocol referencing RFC7977.

I think you instead need to specify that the existing registration be 
updated.

That's all.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 May 2020 19:33:02 +0000

Hi Paul,

Thank You for the comments! Please see inline.

---
    
>    space between "See" and "Section 4.3". It would look better with a 
  
That's a bug. Will be fixed.

---

>    What you should really have is just:
 
Will modify as suggested.

---

>    I suggest: s/for the/for each of the/

Will modify as suggested.
    
>    I suggest: s/for the/for any of the/
  
Will modify as suggested.

---
  
>    Could it not be implied that closing the association implicitly closes 
  
The procedures follow what is defined in Section 6.6.1 of draft-ietf-mmusic-data-channel-sdpneg.

Whether closing the SCTP association, without explicitly closing the data channel(s) first, is an "error", or just "something one should not do",  I think should have been specified in draft-ietf-mmusic-data-channel-sdpneg.

---

>    Could you be more explicit about this?

I have got the same questions from others too, so I guess it needs to be clarified.

As the MSRP messages will be "routed" on the established data channel, the path attribute won't be used for routing.

Maybe something like this:

"When MSRP messages are transported on a data channel, the "path" attribute is not used for routing of the messages. Because of that an MSRP endpoint 
can set the MSRP-URI authority value of the "path" attribute at its own discretion. However, when an MSRP endpoint receives an MSRP message on
a data channel it MUST still check the MSRP-URI in the To-Path of the MSRP message, as described in [RFC4975]."

---

>    protocol referencing RFC7977.

True.

That shows for how long we have been working on this document, because when we started RFC 7977 didn't exist...

>    I think you instead need to specify that the existing registration be updated.

Something like:

7.1.  Subprotocol Identifier MSRP

   NOTE to RFC Editor: Please replace "XXXX" with the number of this
   RFC.

   This document adds a reference to RFC XXXX for the subprotocol identifier "msrp" in
   the "WebSocket Subprotocol Name Registry".

---

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 7 May 2020 15:52:43 -0400

> Thank You for the comments! Please see inline.

I'm fine with these.

	Thanks,
	Paul

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Bo Burman <[email-masked]>
Date: Fri, 8 May 2020 14:38:01 +0000

Taking Christer's proposed changes to Paul's comments into account, I think
this is in pretty good shape.

These are my -16 review comments:

1.	NIT:
In section 1, suggest changing "RTCWeb" to "WebRTC" since I assume the
technology rather than the IETF WG is meant?
2.	MINOR:
In sections 3.1 and 4.3 the subprotocol parameter values use capital "MSRP".
Based on Paul's comment #6 that there is an existing IANA "msrp"
registration, I think you should use lowercase, because that IANA registry
is case-sensitive (see RFC 7936 Section 2
<https://tools.ietf.org/html/rfc7936#section-2> ).
3.	NIT:
Sections 4.6, 4.7, and 4.8 use '"m" line'; suggest aligning with many other
recent documents and add an equal sign to use '"m=" line' instead.
4.	MINOR:
In section 7.2, you use MMUSIC Chairs as contact; please use IESG and
[email-masked] <mailto:[email-masked]>  instead to align with recent practice
and avoid becoming dependent on the existence of a WG.

Cheers,

/Bo (as individual)

From: Bo Burman <[email-masked]> 
Sent: den 6 maj 2020 17:21
To: mmusic <[email-masked]>
Cc: [email-masked]
Subject: WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

Greetings MMUSIC ,

Wednesday, May 20, 2020.

Thanks,

/Bo

(MMUSIC co-chair)

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 9 May 2020 20:30:24 +0200

Hi,

I agree that the draft seems to be in good shape.

I have the following comments/questions:

1. Should the draft say that it updates RFC 4975?

In section 4.2 msrp-scheme, it is said that the msrps scheme is used and 
that it means using DTLS.

In RFC 4975, section 5.4 and 6. it is said that under the msrps scheme, 
TLS must be used.

The msrps scheme is also IANA-registered in RFC 4975 section 15.5.2. 
Please check if that registration need update because of the reuse of 
the msrps scheme.

2. Data reception is not mentioned.

Section 5.5 is about data sending and reporting. There is no section 
about data receiving.

It seems that as for sending, it would be sufficient to refer to RFC 4975.

I suggest that data reception is included in section 5.5.

3. Channel or association failure handling should be specified

There is nothing said about channel failures or SCTP association 
failures. I assume that transmission failures are handled under 
"reporting" in section 5.5, but that does not cover channel or 
association failures.

RFC 4975 has a section 5.4 "MSRP Connection Model" that includes 
connection failures, and considerations for retrying a failed 
connection. Please check if it can be sufficient to refer to that 
section for this issue.

Sections 4.6 and 5.3 in the draft are about session closing, requiring 
SDP signaling for session closing. Consider adding some words about that 
nomal closing requires SDP signaling, while connection failure may 
result in session closing without sdp exchange.

Regards

Gunnar

Den 2020-05-06 kl. 17:20, skrev Bo Burman:
> https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-data-channel-16 
>
>
> as Proposed Standard. Please review and provide any comments you may 
> have on the document by
>
> Wednesday, May 20, 2020.
>
> If you review the document but do not have any comments, please send a 
> note to that effect as well.
>
> Thanks,
>
> /Bo
>
> (MMUSIC co-chair)
>
>

-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Jose M Recio <[email-masked]>
Date: Sun, 10 May 2020 14:22:09 +0800

About #5, as Christer comments, path is not to be used for transport 
negotiation or routing over the data channel. But path is still used by 
MSRP endpoints for a number of procedures, and can be negotiated as 
specified in 4.4

Underlying all this are historical reasons: original MSRP used path used 
to negotiate tranport, but that created problems, so CEMA 
(https://tools.ietf.org/html/rfc6714) was specified, but keeping path 
for other uses.

Previous draft versions included wording about CEMA, but that was found 
very confusing, so agreement was to concisely state that path is not to 
be used for routing or transport negotiation, implicitly assuming 
implementors would know that path can still be included and used for 
other purposes.

We could even simplify Christer's suggestion:

"The path attribute SHALL NOT be used for transport negotiation. MSRP 
endpoints communicating over a data channel can specify and use path 
attribute for other purposes, as specified by RFC4975."

If that is still confusing, I will take Christer wording.

All other changes in 
https://github.com/josemrecio/draft-msrp-data-channel/pull/13, I have 
also updated the examples.

---

From: Jose M Recio <[email-masked]>
Date: Sun, 10 May 2020 14:49:54 +0800

Thanks for your comments, Gunnar,

> Please check if that registration need update because of the reuse of 
Thanks for bringing this back. WG was asked for feedback about updating 
IANA registry or keeping as it is, with the argument that data channel 
uses DTLS so it would conform original “msrps” requirement, that refers 
to TLS. There was no clear outcome.

If there are no comments opposing this, I would follow your comment and 
add it to IANA updates section.

> I suggest that data reception is included in section 5.5.
I propose:
"Data sending, receiving and reporting procedures SHALL conform to RFC4975"
> connection. Please check if it can be sufficient to refer to that 
I think RFC4975 should be enough, failures detected at transport (data 
channel) level should trigger the actions specified in RFC4975. I will 
add a comment.

> SDP signaling for session closing. Consider adding some words about 
> that nomal closing requires SDP signaling, while connection failure 
> may result in session closing without sdp exchange.
>
What about this:

Changing "The closure of an MSRP session MUST be signaled via an SDP" -> 
"Normal closure of an MSRP session MUST be signaled via an SDP"

Adding "Connection failure may result in session closing without SDP 
exchange. If the endpoint attempts to re-create the session, procedures 
specified in RFC4975 SHALL be followed"

>> If you review the document but do not have any comments, please send 
>> a note to that effect as well.
>>
>> Thanks,
>>
>> /Bo
>>
>> (MMUSIC co-chair)
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 10 May 2020 13:29:07 +0000

Hi,

...

>If that is still confusing, I will take Christer wording.

I would prefer my solution (I have no problem if it can be simplfied), because the problem with "SHALL NOT" is that you CAN NOT use the path for routing - even if you wanted to :)

Usage of the path for routing is simply not defined when using a data channel (as the MSRP messages will be sent over the data channel).

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 10 May 2020 18:13:30 +0200

Hi Jose

Den 2020-05-10 kl. 08:49, skrev Jose M Recio:
> Thanks for bringing this back. WG was asked for feedback about 
> updating IANA registry or keeping as it is, with the argument that 
> data channel uses DTLS so it would conform original “msrps” 
> requirement, that refers to TLS. There was no clear outcome.
>
> If there are no comments opposing this, I would follow your comment 
> and add it to IANA updates section.

Good.

Would it also be suitable to say that the draft updates RFC 4975, 
because of this?

> "Data sending, receiving and reporting procedures SHALL conform to 
Fine.
>> Sections 4.6 and 5.3 in the draft are about session closing, 
>> requiring SDP signaling for session closing. Consider adding some 
>> words about that nomal closing requires SDP signaling, while 
>> connection failure may result in session closing without sdp exchange.
>>
> What about this:
>
> Changing "The closure of an MSRP session MUST be signaled via an SDP" 
> -> "Normal closure of an MSRP session MUST be signaled via an SDP"
>
> exchange. If the endpoint attempts to re-create the session, 
> procedures specified in RFC4975 SHALL be followed"
>
I think you are also obliged to do some actions to clean up from the 
lost channel or association. Please check the data channel specs if 
anything more is needed. E.g. sdpneg section 6.6.1, but I am not sure 
that the channel close that is specified there is close because of failure.

Regards

Gunnar

-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 10 May 2020 17:57:43 +0000

​Hi,

>>>Please check if that registration need update because of the reuse of the msrps scheme.
>>
>>Thanks for bringing this back. WG was asked for feedback about updating IANA registry or
>>keeping as it is, with the argument that data channel uses DTLS so it would conform
>>original “msrps” requirement, that refers to TLS. There was no clear outcome.
>>
>>If there are no comments opposing this, I would follow your comment and add it to IANA updates section

>Would it also be suitable to say that the draft updates RFC 4975, because of this?

I agree that a reference to the document should be added to the IANA registry for the "msrps" scheme.

And, if people think 4975 should be updated, I guess we could say something like:

"This document RFC 4975, by allowing the usage of the "msrps" scheme when the underlying connection is protected with DTLS."

---

>>>Section 5.5 is about data sending and reporting. There is no section about data receiving.

I am ok with that.

On a more generic level, should be replace "SHALL" with "MUST" throughout the document? Currently we are using both "MUST" and "SHALL", and I think it would be good to be consistant.

---

>>>There is nothing said about channel failures or SCTP association failures. I assume
>>>that transmission failures are handled under "reporting" in section 5.5, but that does
>>>not cover channel or association failures.
>>>
>>>RFC 4975 has a section 5.4 "MSRP Connection Model" that includes connection failures, and
>>>considerations for retrying a failed connection. Please check if it can be sufficient to refer to
>>>that section for this issue.
>>
>>I think RFC4975 should be enough, failures detected at transport (data channel) level should
>>trigger the actions specified in RFC4975. I will add a comment.
>>
>>> Sections 4.6 and 5.3 in the draft are about session closing, requiring SDP signaling for session closing.
>>> Consider adding some words about that nomal closing requires SDP signaling, while connection failure
>Changing "The closure of an MSRP session MUST be signaled via an SDP" -> "Normal closure of an MSRP session MUST be signaled via an SDP"
>
>Adding "Connection failure may result in session closing without SDP exchange. If the endpoint attempts to re-create the session,

Actually, I would suggest some re-wording.

Some details can be removed, since we are following the procedures in draft-mmusic-data-channel-sdpneg: we don't need to talk about offer/answer, and we don't need to talk about which endpoint triggers the actual data channel closure procedure.

Also, there is no need for a MUST, because we simply describe how the MSRP session is closed.

OLD:

   The closure of an MSRP session MUST be signaled via an SDP offer/
   answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute
   lines associated with the MSRP session from the associated DTLS/SCTP
   based media description.  This results in the associated data channel
   being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg],
   where the actual data channel closure procedure is typically
   initiated by the SDP answerer right after having accepted the SDP
   offer.

NEW:

   An MSRP session is closed by closing the associated data channel,
   fllowing the procedures in [I-D.ietf-mmusic-data-channel-sdpneg].

>I think you are also obliged to do some actions to clean up from the lost channel or association. Please check the

>data channel specs if anything more is needed. E.g. sdpneg section 6.6.1, but I am not sure that the channel close

>that is specified there is close because of failure.

Per 4975, if the connection fails, endpoints MUST consider the MSRP session failed. There is no requirement to do any clean-up, or try to re-establish the connection.

We could add something like:

"If the SCTP association [RFC4960] used to realize the MSRP data channel fails and gets torn down, the endpoints MUST consider the MSRP session

failed. An MSRP endpoint MAY, based on local policy, try to re-establish the SCTP association, and negotiate a new MSRP data channel."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 May 2020 15:14:58 -0400

On 5/10/20 1:57 PM, Christer Holmberg wrote:

> updating IANA registry or
> and add it to IANA updates section
> 
>  >Good.
> 
> "This document RFC 4975, by allowing the usage of the "msrps" scheme 
> when the underlying connection is protected with DTLS."

The key is ensuring that the required usage is clear and unambiguous. 
Specifically, ISTM that a "msrps" URI together with a "dc" parameter 
implies that connecting to this requires use of a data channel over a 
DTLS association established using the address in the URI.

Following up on that, a question about the example in 4.8:

The path attribute includes:

    msrps://bob.example.com:54111/si438dsaodes;dc

but the corresponding c= is:

    c=IN IP4 198.51.100.79

Am I to infer that =IN IP4 198.51.100.79 is the resolution of 
bob.example.com:54111? If so, why doesn't the c= reference 
bob.example.com:54111?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 10 May 2020 19:29:05 +0000

Hi Paul,

> bob.example.com:54111? If so, why doesn't the c= reference

I think we should remove the port number for the path attribute.

As you know, we have tried to make it clear that the msrp URI is not used for routing, and that the path can be set to anything.

Do you want the address and port of the path URI to match the c= line?

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 10 May 2020 22:47:18 +0200

Hi,

> when the underlying connection is protected with DTLS."
I assume you mean that the sentence starts: "This document updates RFC 
4975 ...."
> On a more generic level, should be replace "SHALL" with "MUST" 
> throughout the document? Currently we are using both "MUST" and 
> "SHALL", and I think it would be good to be consistant.
>
> ---
>
> failures. I assume
> connection failures, and
> requiring SDP signaling for session closing.
> Some details can be removed, since we are following the procedures in 
> draft-mmusic-data-channel-sdpneg: we don't need to talk about 
> offer/answer, and we don't need to talk about which endpoint triggers 
> the actual data channel closure procedure.
>

Yes.

But I think the draft lacks general requirements to apply procedures 
from RFC 4975 and just modify them by msrp channel specific procedures.

It may be felt as obvious, but I cannot find it stated anywhere.

Especially in the beginning of section 5. MSRP Considerations :

Current text: "

  This section describes the MSRP considerations specific to a MSRP
    data channel.

"

Proposed text:

" The procedures specified in RFC 4975 apply except when specifications 
in the present document introduces other procedures.

This section describes the MSRP considerations specific to a MSRP

    data channel."

> lost channel or association. Please check the
>
> >data channel specs if anything more is needed. E.g. sdpneg section 
> 6.6.1, but I am not sure that the channel close
>
> Per 4975, if the connection fails, endpoints MUST consider the MSRP 
> session failed. There is no requirement to do any clean-up, or try to 
> re-establish the connection.
>
Yes, but I meant clean-up after the lost MSRP data channel, e.g. sdpneg 
section 6.6.1, and maybe something more if the closure is because of a 
connection failure.
> "If the SCTP association [RFC4960] used to realize the MSRP data 
> channel fails and gets torn down, the endpoints MUST consider the MSRP 
> session
>
> failed. An MSRP endpoint MAY, based on local policy, try to 
> re-establish the SCTP association, and negotiate a new MSRP data channel."
>
Yes, but I suggest adding  both sdpneg section 6.6.1 and RFC 4975 
section 5.4 Connection model.

(I think there may be a general lack of specification in the RTCWeb and 
WebRTC and data channel documents about how to handle connection and 
association failures, but that is a topic for another discussion)

Thanks,

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 10 May 2020 23:07:28 +0200

Hi,

A minor observation.

In the introducttion, first paragraph, the sentence:
"MSRP is currently defined to work over TCP and TLS connections, and 
over a WebSocket subprotocol specified by [RFC7977 
<https://tools.ietf.org/html/rfc7977>]."

The word "currently" will not be well selected if this specification 
gets approved and published.

I suggest:

"MSRP was initially in RFC 4975 defined to work over TCP and TLS 
connections, and over a WebSocket subprotocol specified by [RFC7977 
<https://tools.ietf.org/html/rfc7977>]."

Regards

Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 May 2020 17:19:35 -0400

On 5/10/20 3:29 PM, Christer Holmberg wrote:

> As you know, we have tried to make it clear that the msrp URI is not 
> used for routing, and that the path can be set to anything.
> 

My thought is: what do I start with in order to establish communication 
with you? In this case I'm thinking it is the msrps URI. Starting with 
only that as my knowledge about you, how do I set up a connection?

I hope it isn't necessary to know anything else. If not, then I suggest 
that the example proceed on that basis.

	Thanks,
	Paul

---

From: Keith Drage <[email-masked]>
Date: Sun, 10 May 2020 22:43:11 +0100

This would be better worded as:

In RFC 4975, MSRP is defined to work over TCP and TLS connections, and 
over a WebSocket subprotocol specified by [RFC7977]."

Keith

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 May 2020 06:46:14 +0000

Hi Paul,

In order to establish communication you need to establish the data channel, and then you include the MSRP URI in the MSRP messages sent on that data channel.

But, again, you don't need the MSRP URI for establishing the data channel.

Regards,

Christer

________________________________
From: mmusic <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Monday, May 11, 2020 12:19 AM
To: [email-masked] <[email-masked]>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 May 2020 07:12:49 +0000

Hi,

> I assume you mean that the sentence starts: "This document updates RFC 4975 ...."

Correct.

---

---

>> Some details can be removed, since we are following the procedures in draft-mmusic-data-channel-sdpneg: we don't need to talk about
>> offer/answer, and we don't need to talk about which endpoint triggers the actual data channel closure procedure.
>>
> But I think the draft lacks general requirements to apply procedures from RFC 4975 and just modify them by msrp channel specific procedures. 
> " The procedures specified in RFC 4975 apply except when specifications in the present document introduces other procedures.   
> This section describes the MSRP considerations specific to a MSRP data channel."

With some minor editorial changes I think that sounds good.

> Yes, but I meant clean-up after the lost MSRP data channel, e.g. sdpneg section 6.6.1, and maybe something more if the closure is because of a connection failure. 

There is no requirement to do anything.

>> Yes, but I suggest adding  both sdpneg section 6.6.1 and RFC 4975 section 5.4 Connection model. 
>
> (I think there may be a general lack of specification in the RTCWeb and WebRTC and data channel documents about how to handle
> connection and association failures, but that is a topic for another discussion)
 
Yes __

Based on the feedback I have received, isolated SCTP association failures isn't a big problem. If the connectivity goes away then most likely your signaling won't work either. 

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 11 May 2020 10:20:47 +0200

Hi,

> Based on the feedback I have received, isolated SCTP association failures isn't a big problem. If the connectivity goes away then most likely your signaling won't work either.

It doesn't matter if it is a big problem or not. If there is something 
that needs to be done that is not automatic, in the lower layers, then 
it should be specified.

But you may be right that nothing needs to be specified on this level. I 
found in rtcweb-data-channel, section 6.2 SCTP Association Management 
the following:

" If an SCTP association is closed in a graceful way, all of its data
    channels are closed.  In case of a non-graceful teardown, all data
    channels are also closed, but an error indication SHOULD be provided
    if possible."

So that calls for nothing that needs specification.

In the WebRTC API, there is a bit more to do, but mainly for the 
graceful teardown. The non-graceful is just mentioned that it comes with 
an error indication.

See https://w3c.github.io/webrtc-pc/#closing-procedure

But I think that is on another level and not MSRP specific and that it 
is included in what the implementer will find when using the API.

So, I agree that your proposed addition for the SCTP association 
tear-down is sufficient.

Regards

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 11 May 2020 11:22:19 +0200

Hi,

A nit: I noticed that the reference RFC 4145 is included in the 
reference list, but is not used anymore. The wording around the setup is 
simplified. So, RFC 4145 can be deleted from the reference list.

Regards

Gunnar

---

From: Jose M Recio <[email-masked]>
Date: Tue, 12 May 2020 15:58:44 +0800

Agreed, my worry was not being concise enough.

On 10/05/20 21:29, Christer Holmberg wrote:
> I would prefer my solution (I have no problem if it can be simplfied), 
> because the problem with "SHALL NOT" is that you CAN NOT use the path 
> for routing - even if you wanted to :)
>
> Usage of the path for routing is simply not defined when using a data 
> channel (as the MSRP messages will be sent over the data channel).
>
> Regards,
>
> Christer
>
>
>
> > Whether closing the SCTP association, without explicitly closing the 
> data channel(s) first, is an "error", or just "something one should 
> not do",  I think should have been specified in 
> draft-ietf-mmusic-data-channel-sdpneg.
> >
> > ---
> >
> >>     5) QUESTION:
> >>
> > As the MSRP messages will be "routed" on the established data 
> channel, the path attribute won't be used for routing.
> >
> > "When MSRP messages are transported on a data channel, the "path" 
> attribute is not used for routing of the messages. Because of that an 
> MSRP endpoint
> > can set the MSRP-URI authority value of the "path" attribute at its 
> own discretion. However, when an MSRP endpoint receives an MSRP message on
> > a data channel it MUST still check the MSRP-URI in the To-Path of 
> the MSRP message, as described in [RFC4975]."
> >
> > ---
> >
> >>     6) ISSUE:
> >>
> > That shows for how long we have been working on this document, 
> because when we started RFC 7977 didn't exist...
> >

---

From: Jose M Recio <[email-masked]>
Date: Tue, 12 May 2020 17:59:57 +0800

Many thanks for the comments, I have consolidated the following comments 
in an ongoing PR

https://github.com/josemrecio/draft-msrp-data-channel/pull/14:

- Draft states that it updates RFC4975 and adds an IANA consideration to 
update the msrps registration, to include DTLS

- Removed RFC4145 and other dangling references

- Introduction corrected "MSRP is currently defined ... " -> "MSRP was 
initially defined in ..."

- 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

- Simplified SDP session closing section, referring back to 
mmusic-data-channel-sdpneg

- Updated examples removing the port

- Updated introduction to MSRP considerations section "This section 
describes the MSRP ... " -> "The procedures specified in RFC4975 apply 
except ..."

- Clarification on MSRP session closing section, explicitly stating that 
MSRP session should be considered failed when data channels are torn down

Pending:

- Replacing all SHALL with MUST for consistency

On 12/05/20 15:58, Jose M Recio wrote:
>> I would prefer my solution (I have no problem if it can be 
>> simplfied), because the problem with "SHALL NOT" is that you CAN NOT 
>> use the path for routing - even if you wanted to :)
>>
>> > Whether closing the SCTP association, without explicitly closing 
>> the data channel(s) first, is an "error", or just "something one 
>> should not do",  I think should have been specified in

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 May 2020 12:32:09 +0000

Hi,

>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]."

>- Updated examples removing the port

Actually, I realized that 4975 mandates a port, so I think we should keep it.

>- 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.
Regards,
Christer

...

Regards,

Christer

On 08/05/20 03:33, Christer Holmberg wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 May 2020 09:39:00 -0400

On 5/12/20 8:32 AM, Christer Holmberg wrote:
> 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
> 
> 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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 May 2020 13:58:45 +0000

Hi,
    > case, both the transport setup and the path attribute would be derived 

    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.

    Regards,

    Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 May 2020 10:24:15 -0400

Christer,

Comment at end.

>     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*.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 May 2020 17:17:58 +0000

Hi,

    >>      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.
    >> 

    You know that you are going to send the MSRP message on the data channel - that's all you need to know.

    Regards,

    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 May 2020 17:21:16 +0000

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.

Regards,

Christer

On 13/05/2020, 20.18, "mmusic on behalf of Christer Holmberg" <[email-masked] on behalf of christer.holmberg=[email-masked]> wrote:

    Hi,

        Regards,

        Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 May 2020 14:16:44 -0400

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 May 2020 18:37:53 +0000

Hi,

    > do that? Or can I derive the c/m- line data from it?

    I don't think an MSRP-URI is something you would put in your address book. If you use SIP to negotiate the MSRP session, then you would have a SIP-URI in your address book, and you would use that to establish a SIP session in order to negotiate the MSRP session.

    Even in RFC 4975, you use SIP and offer/answer to negotiate the MSRP session. You don't just start sending MSRP messages without exchanging the MSPR session parameters (including path) first.

     But, maybe I completely misunderstand your issue. 

     Please suggest some text that you would to be included, if that perhaps helps me understand.

     Regards,

     Christer

---

From: Jose M Recio <[email-masked]>
Date: Thu, 14 May 2020 17:29:23 +0800

On 12/05/20 20:32, Christer Holmberg wrote:
> 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 
Thanks, this looks very good

> Actually, I realized that 4975 mandates a port, so I think we should 
This was overlooked, reverted

> behind when SHALL or MUST is used.
Done

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 May 2020 11:57:28 -0400

>       But, maybe I completely misunderstand your issue.

I don't know. I'm trying to understand the intended usage and how it 
plays out in the example. If what I have in my address book for you is 
just your sip URI, then how do I figure out how to establish a chat 
session? How do I decide to use a data channel rather than MSRP over 
TLS? And do I just somehow derive the msrp URL from your sip URL?

I guess if I am running in a browser and using WebRTC then I try a data 
channel because there is no alternative I can use. But that isn't this 
example. Must I have something else in my address book to tell me what 
you support? Or should I be trying both in my invite and seeing what you 
accept? (That also isn't this example.)

I would hope that the draft doesn't require magical thinking for the 
example to work.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 May 2020 16:46:06 +0000

Hi,
  
  >  TLS? 

   That is based on your local preferences, whatever your SIP (or whatever signaling protocol you use) client puts in the offer. In the same way it decides if it offers audio, video etc.

   > And do I just somehow derive the msrp URL from your sip URL?

   You don't need to derive it. The applications will create the msrp URLs and exchange them in O/A.

    > accept? (That also isn't this example.)

    You don't need to have anything. You send an offer, offer me MSRP, and if I support/accept it I send you MSRP back in the answer.

    This is no different from any other type of media...

    Regards,

    Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 May 2020 12:20:53 -0400

>     That is based on your local preferences, whatever your SIP (or whatever signaling protocol you use) client puts in the offer. In the same way it decides if it offers audio, video etc.

I'll comment on this below.

>     You don't need to derive it. The applications will create the msrp URLs and exchange them in O/A.

What I meant was that the values have to come from somewhere. Where do 
they come from? In the example, the c= is 198.51.100.79, but the path 
has bob.example.com. How does that happen? Where did bob.example.com 
come from?

ISTM that it would make the most sense to use the same value in both 
places. Or else use some fixed dummy placeholder value in path.

>      This is no different from any other type of media...

The problem is that there are multiple ways to set up a chat session 
under sip. This is much like the old problem of whether to IPv4 or IPv6 
in a c= line when you could do both. It took ICE to solve *that* problem 
in an acceptable way. AFAICT it isn't solved for chat. (The only likely 
solution that comes to mind is capability negotiation. But hardly 
anybody implements that do they?)

I don't think it is necessary to solve it in this draft. But it would be 
good to at least acknowledge the problem.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 May 2020 17:46:29 +0000

> places. Or else use some fixed dummy placeholder value in path.

    Ok, so we'll put the same value in both places, if that makes things clearer. 

    > good to at least acknowledge the problem.

    This draft does *not* cover how you establish the SCTP association, and how you choose between IPv4, IPv6 etc for that association. There is a separate draft for that.

    This draft does *not* even cover the generic procedures for negotiation a data channel. There is a separate draft for that. 

    This draft only describes the specifics associated with negotiation a data channel for MSRP usage. 

    Regards,

    Christer

---

From: Jose M Recio <[email-masked]>
Date: Sun, 17 May 2020 22:52:28 +0800

>      This draft only describes the specifics associated with negotiation a data channel for MSRP usage.
I believe part of the confusion is that using data channels, transport 
negotiation and MSRP negotiation are not as tightly related as with 
other transports.

Given an example with the following sequence of steps on a web-based 
user UI:
- Alice wants to chat with Bob, opens a web page, logs in, selects Bob 
in an application-based address book, writes "Hello" and clicks Send

What this triggers, assuming that a) there is no pre-existing WebRTC 
PeerConnection between Alice and Bob; and b) session is established 
directly between Alice and Bob, i.e., no MSRP data channel gateway is used:
1. Alice and Bob setup a WebRTC PeerConnection that includes a SCTP 
association. An out-of-band signaling channel, provided by the web 
application, is used to exchange the messages required for the negotiation
2. WebRTC PeerConnection and SCTP association are established. As part 
of that, Alice and Bob web endpoints have found ICE candidates through 
which communicate
3. MSRP data channel is negotiated according to this draft. It will be 
instantiated as a new stream over the existing SCTP association, so the 
underlying transport (SCTP association, DTLS, ICE) is already setup, in 
advance. As this draft builds on mmusic-data-channel-sdpneg, an 
out-of-band signalling protocol is needed to exchange the SDPs, 
tipycally the same used to establish the WebRTC PeerConnection, provided 
by the web application.
3.1. Alice web endpoint fills up the SDP used to negotiate a MSRP data 
channel over the already existing SCTP association, in particular:
3.1.1 IP address and port for m= and c= lines are obtained from the 
appropriate ICE candidate in the WebRTC PeerConnection
3.1.2 domain part of the MSRP URI are obtained from application policy, 
configuration, or address book
3.2. Bob receives the MSRP data channel SDP offer from Alice, fills up 
the response also using the IP address and port from the ICE candiate in 
the WebRTC PeerConnection for the m= and c= lines, and so on
3.3. MSRP data channel negotiation succeeds, and MSRP session is open
4. Alice MSRP stack sends "Hello" over the negotiated MSRP data channel 
and message is received by Bob MSRP stack

This is not so complicated in practice. For browser endpoints, steps 1 
and 2 are hidden behind the W3C WebRTC JS API. Steps 3 and 4 can reuse 
existing MSRP stacks, unchanged for the most part, and driven by 
negotiation code

---

From: Jose M Recio <[email-masked]>
Date: Thu, 21 May 2020 19:46:42 +0800

PR with latest comments in 
https://github.com/josemrecio/draft-msrp-data-channel/pull/15

---

From: Bo Burman <[email-masked]>
Date: Wed, 27 May 2020 09:04:37 +0000

Authors, WG,

I have not seen any objections to the proposed ways to resolve the WGLC
comments, I find no unhandled WGLC comments, and the WGLC period has passed.
The WGLC of draft-ietf-mmusic-msrp-usage-data-channel is therefore
concluded.

Authors, please submit an updated version addressing the WGLC comments at
your earliest convenience.

Thanks,
Bo
MMUSIC co-chair

> -----Original Message-----
> From: mmusic <[email-masked]> On Behalf Of Jose M Recio
> Sent: den 21 maj 2020 13:47
> To: [email-masked]
> https://protect2.fireeye.com/v1/url?k=387d3580-66dd8fee-387d751b-
> 86b1886cfa64-fea60e72061166bf&q=1&e=9bcec126-851f-44c1-8fed-
> 667b5ac89725&u=https%3A%2F%2Fgithub.com%2Fjosemrecio%2Fdraft-
> msrp-data-channel%2Fpull%2F15
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 30 May 2020 12:16:50 +0000

Hi,

The latest version (-17) implements to outcomes of the WGLC review.

Regards,

Christer

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Bo Burman
Sent: keskiviikko 27. toukokuuta 2020 12.05
To: Jose M Recio <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

Authors, WG,

I have not seen any objections to the proposed ways to resolve the WGLC comments, I find no unhandled WGLC comments, and the WGLC period has passed.
The WGLC of draft-ietf-mmusic-msrp-usage-data-channel is therefore concluded.

Authors, please submit an updated version addressing the WGLC comments at your earliest convenience.

Thanks,
Bo
MMUSIC co-chair

> > I believe part of the confusion is that using data channels, 
> > transport negotiation and MSRP negotiation are not as tightly 
> > related as with other transports.
>