Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 13 Feb 2014 15:17:42 +0000

Hi Mary - 

Thanks for taking the time to review the document.  We have published an -05 that (hopefully) addresses all your feedback.  

Inline, trimming to only the points requiring responses...

On Jan 10, 2014, at 5:58 PM, Mary Barnes <[email-masked]> wrote:

> I have agreed to shepherd this document.  I've reviewed the document in anticipation of doing the PROTO write-up and have the following comments and questions.  Ben Campbell has agreed to do the required expert review and that should be posted within the next week or so.    This is also a good time for anyone in the WG that hasn't previously reviewed this document to review and provide any final comments.  Note, that this document was agreed to be AD sponsored around the IETF-86 timeframe.
> 
> Regards,
> Mary. 
> 
> Review Summary: Almost ready. Comments & questions below.

<snip/>

> 5) Section 10.1. Since securing the connection is just RECOMMENDED, what are the implications and risks if the MSRP traffic isn't transported over a secure connection? 

Other review comments indicated that it was problematic to downgrade the 4976 MUST requirement for TLS between a client and a server. Thus, the document has been updated so that MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (i.e., using TLS).  I believe this renders this point moot.

<snip/>

> 8) It's typical for documents that are updating existing RFCs to have a section that summarizes the updates to the existing RFCs that are made by this document.  

This was the intent of Sections 5.2 and 5.3.  Is this sufficient? Or did you have something else in mind?

Regards,

Gonzalo

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 13 Feb 2014 16:38:52 +0100

Hi,

We also have recently published a different draft for BFCP over websockets:
http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00

I beleive that we should harmonize who the WS transport is signaled and 
how to signal the WS version if also the "normal" TCP version is supported.

In your case you seem to be using the same transport line TCP/MSRP and 
use the path to signal the ws part, in our case, we choose to signal it 
in the transport TCP/WS/BFCP and include a new attribute ws-uri to 
signal the full url (I could not reuse the path attribute as it is 
restricted to msrp urls only).

Best regards
Sergio
El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribió:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Mary Barnes <[email-masked]>
Date: Thu, 13 Feb 2014 09:49:26 -0600

Sergio,

The draft you mention is being discussed in the BFCPBIS WG and any comments
that others might have on that document should go to that list.

It's not clear to me whether your suggestion is that changes are needed to
this MSRP document or whether you are just proposing to make the BFCPBIS
consistent with this MSRP document?

Mary.

On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

> In your case you seem to be using the same transport line TCP/MSRP and use
> the path to signal the ws part, in our case, we choose to signal it in the
> transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full
> url (I could not reuse the path attribute as it is restricted to msrp urls
> only).
>
> Best regards
> Sergio
>> Thanks for taking the time to review the document.  We have published an
>> -05 that (hopefully) addresses all your feedback.
>>
>>  I have agreed to shepherd this document.  I've reviewed the document in
>>> anticipation of doing the PROTO write-up and have the following comments
>>> and questions.  Ben Campbell has agreed to do the required expert review
>>> and that should be posted within the next week or so.    This is also a
>>> good time for anyone in the WG that hasn't previously reviewed this
>>> document to review and provide any final comments.  Note, that this
>>> document was agreed to be AD sponsored around the IETF-86 timeframe.
>>>
>>> Regards,
>>> Mary.
>>>
>>  5) Section 10.1. Since securing the connection is just RECOMMENDED, what
>>> are the implications and risks if the MSRP traffic isn't transported over a
>>> secure connection?
>>>
>> Other review comments indicated that it was problematic to downgrade the
>> 4976 MUST requirement for TLS between a client and a server. Thus, the
>> document has been updated so that MSRP traffic transported over WebSockets
>> MUST be protected by using a secure WebSocket connection (i.e., using TLS).
>>  I believe this renders this point moot.
>>
>> <snip/>
>>
>>  8) It's typical for documents that are updating existing RFCs to have a
>>> section that summarizes the updates to the existing RFCs that are made by
>>> this document.
>>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 13 Feb 2014 17:07:25 +0100

What I mean is that I expect quite a lot of "over websocekts" drafts and we
should try to use the same solution for advertising it in the SDP, and not
have each one have their own way of handling it.

Best regards
Sergio
El 13/02/2014 16:49, "Mary Barnes" <[email-masked]> escribió:

> Sergio,
>
> The draft you mention is being discussed in the BFCPBIS WG and any
> comments that others might have on that document should go to that list.
>
>> use the path to signal the ws part, in our case, we choose to signal it in
>> the transport TCP/WS/BFCP and include a new attribute ws-uri to signal the
>> full url (I could not reuse the path attribute as it is restricted to msrp
>> urls only).
>>
>> Best regards
>> Sergio
>>>  5) Section 10.1. Since securing the connection is just RECOMMENDED,
>>>> what are the implications and risks if the MSRP traffic isn't transported
>>>> over a secure connection?
>>>>

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 13 Feb 2014 16:26:02 +0000

Hello,

The method chosen for advertising WebSockets in the SDP for MSRP was picked
because it was would enable interoperability with existing MSRP
implementations through an MSRP relay without requiring changes to those
implementations.  In this scenario advertising WebSockets in the SDP would
mean that the existing implementation - which does not need to support
WebSockets (the MSRP relay deals with this) - would need to be able to cope
with seeing TCP/WSS/MSRP in the SDP.  In all probability existing
implementations will not cope with seeing "TCP/WSS/MSRP" in the SDP instead
of "TCP/TLS/MSRP" - this would be a big problem.

I have no issue with consistency between the drafts using WebSockets where
possible, but in this case doing what is done in the BFCP draft (explicitly
putting TCP/WSS/MSRP into the SDP) may not be practical (and in fact may be
quite undesirable).

Regards,

Peter

On 13 February 2014 16:07, Sergio Garcia Murillo <
[email-masked]> wrote:

> What I mean is that I expect quite a lot of "over websocekts" drafts and
> we should try to use the same solution for advertising it in the SDP, and
> not have each one have their own way of handling it.
>
> Best regards
> Sergio
>> It's not clear to me whether your suggestion is that changes are needed
>> to this MSRP document or whether you are just proposing to make the BFCPBIS
>>>> Thanks for taking the time to review the document.  We have published
>>>> an -05 that (hopefully) addresses all your feedback.
>>>>
>>>>  I have agreed to shepherd this document.  I've reviewed the document
>>>>> in anticipation of doing the PROTO write-up and have the following comments
>>>> Other review comments indicated that it was problematic to downgrade
>>>> the 4976 MUST requirement for TLS between a client and a server. Thus, the
>>>>  8) It's typical for documents that are updating existing RFCs to have
>>>>> a section that summarizes the updates to the existing RFCs that are made by
>>>>> this document.
>>>>>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Feb 2014 13:38:35 -0500

On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote:
> we should try to use the same solution for advertising it in the SDP,
> and not have each one have their own way of handling it.

Sigh. Yes, once we had the first of these, it was only a matter of time 
before the flood began.

What concerns me is that for every "X over websockets" there is probably 
also a good argument for "X over WebRTC Data Channel".

Are we going to let that happen?

Or for each X are we going to have a beauty contest between websockets 
and data channel?

Or what?

	Thanks,
	Paul

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 13 Feb 2014 21:28:16 +0100

El 13/02/2014 19:38, Paul Kyzivat escribió:
> Sigh. Yes, once we had the first of these, it was only a matter of 
> time before the flood began.
>
> What concerns me is that for every "X over websockets" there is 
> probably also a good argument for "X over WebRTC Data Channel".
>

Completely agree, we should try to "close" that discussion once and for 
all and not have the same arguments and discussions in each draft. I am 
not really aware of the IETF process, but could be possible to create a 
draft to address it?

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 13 Feb 2014 21:40:41 +0100

Hi Mary,

My point is exactly the opposite. We should not choose one or the other, 
it is an issue that affects both drafts, and any upcoming X over 
websocket draft, so I don't think it is a good idea to isolate the 
discussion in a single draft and ignore what is happening outside. If 
not we will end up with lots of different solutions for the same issue 
and developers (like me) will get crazy when trying to implement it.

Best regards
Sergio
El 13/02/2014 16:49, Mary Barnes escribió:
> It's not clear to me whether your suggestion is that changes are 
> needed to this MSRP document or whether you are just proposing to make 
> the BFCPBIS consistent with this MSRP document?
>
> Mary.
>
>
> On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     I beleive that we should harmonize who the WS transport is
>     signaled and how to signal the WS version if also the "normal" TCP
>     version is supported.
>
>     In your case you seem to be using the same transport line TCP/MSRP
>     and use the path to signal the ws part, in our case, we choose to
>     signal it in the transport TCP/WS/BFCP and include a new attribute
>     ws-uri to signal the full url (I could not reuse the path
>     attribute as it is restricted to msrp urls only).
>
>     Best regards
>     Sergio
>         Thanks for taking the time to review the document.  We have
>         published an -05 that (hopefully) addresses all your feedback.
>
>         On Jan 10, 2014, at 5:58 PM, Mary Barnes
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             I have agreed to shepherd this document.  I've reviewed
>             the document in anticipation of doing the PROTO write-up
>             and have the following comments and questions.  Ben
>             Campbell has agreed to do the required expert review and
>             that should be posted within the next week or so.    This
>             is also a good time for anyone in the WG that hasn't
>             previously reviewed this document to review and provide
>             any final comments.  Note, that this document was agreed
>             to be AD sponsored around the IETF-86 timeframe.
>
>             Regards,
>             Mary.
>
>             5) Section 10.1. Since securing the connection is just
>             RECOMMENDED, what are the implications and risks if the
>             MSRP traffic isn't transported over a secure connection?
>
>         Other review comments indicated that it was problematic to
>         downgrade the 4976 MUST requirement for TLS between a client
>         and a server. Thus, the document has been updated so that MSRP
>         traffic transported over WebSockets MUST be protected by using
>         a secure WebSocket connection (i.e., using TLS).  I believe
>         this renders this point moot.
>
>         <snip/>
>
>             8) It's typical for documents that are updating existing
>             RFCs to have a section that summarizes the updates to the
>             existing RFCs that are made by this document.
>
>         This was the intent of Sections 5.2 and 5.3.  Is this
>         sufficient? Or did you have something else in mind?
>
>         Regards,
>
>         Gonzalo
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Feb 2014 15:57:24 -0500

> not really aware of the IETF process, but could be possible to create a

It's kind of late to do anything about it before the draft cutoff.

Continuing to discuss here on the dispatch list isn't such a bad way to 
start out. Then maybe some hallway discussion in London.

After that, maybe a draft for dispatch or RAI Area would be helpful.

If we wanted to do both for everything, then ISTM that some of the 
mapping can be the same for websockets and data channel. The part that 
is hard to unify is the SDP negotiation. Could we come up with some 
approach where doing these is easy and consistent?

	Thanks,
	Paul

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 13 Feb 2014 21:01:36 +0000

Hello,

Wasn't Sergio's point about what the terminology (for example, within SDP)
should be rather than whether WebSockets is appropriate as a transport or
not?  And isn't this a totally separate issue from the WebSockets vs.
WebRTC question?

I honestly don't see what the problem is with having some protocols over
WebSockets, some protocols over DataChannel, and some over both.  I am sure
it is technically possible to have all of these protocols over one, or the
other, or both, but what is important is which makes sense from a use-case
point-of-view.  Surely the fact that someone is prepared to spend the time
putting together (possibly multiple) versions of a draft is a good
indication that there is interest in using a particular protocol over a
particular transport?

In the MSRP example, when talking about an MSRP client communicating with
an MSRP relay (not two MSRP peers communicating directly), MSRP over
WebSockets makes a lot of sense.  The WebSocket server is much less effort
to implement than the WebRTC DataChannel server.  Further, to generate the
SDP for an INVITE when using MSRP you have to AUTH to the relay, doing this
with WebRTC DataChannel would require:

   - Setting up a session to establish the DataChannel (INVITE, SDP, etc)
   - Sending an AUTH on the DataChannel
   - Setting up a second session for the MSRP connection

or, you could totally redesigning the MSRP relay protocol - which would
miss the point.

Regards,

Peter

On 13 February 2014 20:28, Sergio Garcia Murillo <
[email-masked]> wrote:

> all and not have the same arguments and discussions in each draft. I am not
> really aware of the IETF process, but could be possible to create a draft
> to address it?
>
> Best regards
> Sergio
>
>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 13 Feb 2014 21:08:29 +0000

Hello,

The problem with attempting to specify something like "TCP/WS/xxx" or
"TCP/WSS/xxx" is that it will make the drafts easy to understand but might
not actually help from an implementation point-of-view.

Sure it'll help the implementer with respect to the specific RFC, but in
the case of MSRP over WebSockets it won't help with the implementer create
something that interoperates with legacy peers through the MSRP relay.
 This is a problem that BFCP might not suffer from, but this kind of
interoperability is desirable and as a result even if this had been
defined/recommended before the work on MSRP over WebSockets started
"TCP/TLS/MSRP" would probably still be used in that draft (unless someone
could find another way to ensure that legacy peers would accept the new SDP
content without issue).

Regards,

Peter

On 13 February 2014 20:40, Sergio Garcia Murillo <
[email-masked]> wrote:

> it is an issue that affects both drafts, and any upcoming X over websocket
> draft, so I don't think it is a good idea to isolate the discussion in a
> single draft and ignore what is happening outside. If not we will end up
> with lots of different solutions for the same issue and developers (like
> me) will get crazy when trying to implement it.
>
> Best regards
> Sergio

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 13 Feb 2014 22:18:27 +0100

Hi Peter,

I think that you misunderstood me. I was not asking you to change the 
MSRP over websocket draft to set the transport to TCP/WSS/MSRP and do it 
like the BFCP over websocket draft, but to find a way that we could both 
use the same solution with the principles that you are mentioning, that is:

-Do not break backward compatibility
-Allow easy implementation for servers which wants to support both 
TCP/TLS and WS/WSS "flavors"

In my case, I will implement both BFCP and MSRP over TCP and Websockets 
in my MCU, so my interest is genuine.. :)

I have a doubt regarding the draft. If I understood it correctly, you 
are only considering P2P in he examples and using a msrp relay in the 
middle to be able to connect a WS to a non WS, but I am not sure how 
would you handle the case when you don't use a relay. Is that possible 
at all?

Best regards
Sergio
El 13/02/2014 17:26, Peter Dunkley escribió:
> Hello,
>
> The method chosen for advertising WebSockets in the SDP for MSRP was 
> picked because it was would enable interoperability with existing MSRP 
> implementations through an MSRP relay without requiring changes to 
> those implementations.  In this scenario advertising WebSockets in the 
> SDP would mean that the existing implementation - which does not need 
> to support WebSockets (the MSRP relay deals with this) - would need to 
> be able to cope with seeing TCP/WSS/MSRP in the SDP.  In all 
> probability existing implementations will not cope with seeing 
> "TCP/WSS/MSRP" in the SDP instead of "TCP/TLS/MSRP" - this would be a 
> big problem.
>
> I have no issue with consistency between the drafts using WebSockets 
> where possible, but in this case doing what is done in the BFCP draft 
> (explicitly putting TCP/WSS/MSRP into the SDP) may not be practical 
> (and in fact may be quite undesirable).
>
> Regards,
>
> Peter
>
>
>
> On 13 February 2014 16:07, Sergio Garcia Murillo 
>     What I mean is that I expect quite a lot of "over websocekts"
>     drafts and we should try to use the same solution for advertising
>     it in the SDP, and not have each one have their own way of
>     handling it.
>
>     Best regards
>     Sergio
>
>     El 13/02/2014 16:49, "Mary Barnes" <[email-masked]
>     <mailto:[email-masked]>> escribió:
>
>         Sergio,
>
>         The draft you mention is being discussed in the BFCPBIS WG and
>         any comments that others might have on that document should go
>         to that list.
>
>         It's not clear to me whether your suggestion is that changes
>         are needed to this MSRP document or whether you are just
>         proposing to make the BFCPBIS consistent with this MSRP document?
>
>         Mary.
>
>
>             signaled and how to signal the WS version if also the
>             "normal" TCP version is supported.
>
>             In your case you seem to be using the same transport line
>             TCP/MSRP and use the path to signal the ws part, in our
>             case, we choose to signal it in the transport TCP/WS/BFCP
>             and include a new attribute ws-uri to signal the full url
>             (I could not reuse the path attribute as it is restricted
>             to msrp urls only).
>
>             Best regards
>             Sergio
>                 Thanks for taking the time to review the document.  We
>                 have published an -05 that (hopefully) addresses all
>                 your feedback.
>
>                     I have agreed to shepherd this document.  I've
>                     reviewed the document in anticipation of doing the
>                     PROTO write-up and have the following comments and
>                     questions.  Ben Campbell has agreed to do the
>                     required expert review and that should be posted
>                     within the next week or so.    This is also a good
>                     time for anyone in the WG that hasn't previously
>                     reviewed this document to review and provide any
>                     final comments.  Note, that this document was
>                     agreed to be AD sponsored around the IETF-86
>                     timeframe.
>
>                     Regards,
>                     Mary.
>
>                     5) Section 10.1. Since securing the connection is
>                     just RECOMMENDED, what are the implications and
>                     risks if the MSRP traffic isn't transported over a
>                     secure connection?
>
>                 Other review comments indicated that it was
>                 problematic to downgrade the 4976 MUST requirement for
>                 TLS between a client and a server. Thus, the document
>                 has been updated so that MSRP traffic transported over
>                 WebSockets MUST be protected by using a secure
>                 WebSocket connection (i.e., using TLS).  I believe
>                     8) It's typical for documents that are updating
>                     existing RFCs to have a section that summarizes
>                     the updates to the existing RFCs that are made by
>                     this document.
>

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 13 Feb 2014 21:24:54 +0000

Hello,

Because WebSockets is an asynchronous protocol two MSRP peers (that are
clients) cannot use MSRP over WebSockets.

It could be possible for a WebSocket server to be an MSRP peer (for
example, in the scenario where the server is B2B'ing MSRP like an SBC will
do in IMS for CEMA).  Christer Holmberg has expressed an interest in this
scenario and may provide language relating to it for the draft - but for
now this is out of the scope of the draft which explicitly deals just with
with the MSRP through relay scenario.  If Christer does provide some
additional language then the draft will cover this without relay scenario,
but if not nothing in the draft should prevent someone from addressing it
in the future with an additional document (should there be interest).

>From my point-of-view I am only interested in the with relay scenario at
this time.

Regards,

Peter

On 13 February 2014 21:18, Sergio Garcia Murillo <
[email-masked]> wrote:

>  Hi Peter,
>
> I think that you misunderstood me. I was not asking you to change the MSRP
> over websocket draft to set the transport to TCP/WSS/MSRP and do it like
> the BFCP over websocket draft, but to find a way that we could both use the
> same solution with the principles that you are mentioning, that is:
>
> -Allow easy implementation for servers which wants to support both TCP/TLS
> and WS/WSS "flavors"
>
> In my case, I will implement both BFCP and MSRP over TCP and Websockets in
> my MCU, so my interest is genuine.. :)
>
> I have a doubt regarding the draft. If I understood it correctly, you are
> only considering P2P in he examples and using a msrp relay in the middle to
> be able to connect a WS to a non WS, but I am not sure how would you handle
> the case when you don't use a relay. Is that possible at all?
>
> Best regards
> Sergio
> (explicitly putting TCP/WSS/MSRP into the SDP) may not be practical (and in
> fact may be quite undesirable).
>
>  Regards,
>
>  Peter
>
>
>
>>> needed to this MSRP document or whether you are just proposing to make the
>>> BFCPBIS consistent with this MSRP document?
>>>
>>>  Mary.
>>>
>>>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 13 Feb 2014 22:26:27 +0100

El 13/02/2014 22:01, Peter Dunkley escribió:
> Hello,
>
> Wasn't Sergio's point about what the terminology (for example, within 
> SDP) should be rather than whether WebSockets is appropriate as a 
> transport or not?  And isn't this a totally separate issue from the 
> WebSockets vs. WebRTC question?

Yes and no. My point was that all "X over websockets" will have some 
common issues, so instead of having the same discussion every time, it 
would be better if we could address them once and for all, so when 
someone wants to propose a new "X", it does not have to spend time and 
effort on that issues.

Best regards
Sergio

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 13 Feb 2014 21:32:26 +0000

My point was more that if we are going to have a discussion about how we
refer to WebSockets (in SDP or elsewhere) then let's have it, but let's
also keep it separate from a reopening of the WebSockets vs DataChannel
discussion.

Which is the right transport (WebSockets/DataChannel) is a use-case
specific thing.  I don't see the need for any sort of "beauty contest" as
this is more like the difference between using TCP vs UDP - some things
work on both and some are better suited to one than the other.  Why would
we having this "contest" at all, it just doesn't make sense to me.  Some
things will be on WebSockets, some things will be on DataChannel, some
things will be on both, and what is wrong with that?

On 13 February 2014 21:26, Sergio Garcia Murillo <
[email-masked]> wrote:

>> SDP) should be rather than whether WebSockets is appropriate as a transport
>> or not?  And isn't this a totally separate issue from the WebSockets vs.
>> WebRTC question?
>>
>
> would be better if we could address them once and for all, so when someone
> wants to propose a new "X", it does not have to spend time and effort on
> that issues.
>
>
> Best regards
> Sergio
>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 13 Feb 2014 22:37:47 +0100

I completely agree, and I have argued and discussed about it in the 
past, but the topic keeps showing up in each draft discussion. So I 
would prefer to do something to prevent having the same discussion again 
and again in the future.

Best regards
Sergio
El 13/02/2014 22:32, Peter Dunkley escribió:
> My point was more that if we are going to have a discussion about how 
> we refer to WebSockets (in SDP or elsewhere) then let's have it, but 
> let's also keep it separate from a reopening of the WebSockets vs 
> DataChannel discussion.
>
> specific thing.  I don't see the need for any sort of "beauty contest" 
> as this is more like the difference between using TCP vs UDP - some 
> things work on both and some are better suited to one than the other. 
>  Why would we having this "contest" at all, it just doesn't make sense 
> to me.  Some things will be on WebSockets, some things will be on 
> DataChannel, some things will be on both, and what is wrong with that?
>
>
>
> On 13 February 2014 21:26, Sergio Garcia Murillo 
>         Wasn't Sergio's point about what the terminology (for example,
>         within SDP) should be rather than whether WebSockets is
>         appropriate as a transport or not?  And isn't this a totally
>         separate issue from the WebSockets vs. WebRTC question?
>
>
>     Yes and no. My point was that all "X over websockets" will have
>     some common issues, so instead of having the same discussion every
>     time, it would be better if we could address them once and for
>     all, so when someone wants to propose a new "X", it does not have
>     to spend time and effort on that issues.
>
>
>     Best regards
>     Sergio
>

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 13 Feb 2014 21:38:55 +0000

BTW, just looking at MSRP:

MSRP through relay:

   - WebSockets makes sense
   - WebRTC DataChannel does not make sense (due to the need to establish a
   session for the DataChannel so you can send an AUTH to get the information
   you need to establish (another) session for MSRP)

MSRP to peer (which might be a client or might be server)

   - WebSockets makes sense from client to server - the CEMA scenario that
   Christer may provide language for
   - WebRTC DataChannel makes sense between clients
   - WebRTC DataChannel may make sense from clients to server - but
   WebSockets will be lighter weight

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 13 Feb 2014 22:47:13 +0100

El 13/02/2014 22:24, Peter Dunkley escribió:
> Hello,
>
> Because WebSockets is an asynchronous protocol two MSRP peers (that 
> are clients) cannot use MSRP over WebSockets.
>
> example, in the scenario where the server is B2B'ing MSRP like an SBC 
> will do in IMS for CEMA).  Christer Holmberg has expressed an interest 
> in this scenario and may provide language relating to it for the draft 
> - but for now this is out of the scope of the draft which explicitly 
> deals just with with the MSRP through relay scenario.  If Christer 
> does provide some additional language then the draft will cover this 
> without relay scenario, but if not nothing in the draft should prevent 
> someone from addressing it in the future with an additional document 
> (should there be interest).
>
> From my point-of-view I am only interested in the with relay scenario 
> at this time.

Fair enough, but then maybe the draft should be named "MSRP over 
webscokets via MSRP relay" to avoid confusions .. ;)

In that case, using the TCP/WS/MSRP wouldn't be correct in my point of 
view and the draft is ok as it is. I was thinking more in the scenario 
of the MSRP peer also been the Websocket server, that is very similar to 
the scenario we have in BFCP over websockets.

Best regards
Sergio

---

From: Mary Barnes <[email-masked]>
Date: Thu, 13 Feb 2014 16:02:53 -0600

This topic has previously been raised (a year ago and periodically since
then):
http://www.ietf.org/mail-archive/web/dispatch/current/msg04693.html

The suggestion was to have a "foo" over websocket discussion on the RAI
list (which is really a lonely and largely ignored mailing list) but no one
has taken that up:
http://www.ietf.org/mail-archive/web/dispatch/current/msg04749.html

Also, no one has put forth a concrete proposal to deal with it and we don't
do work unless someones willing to put in the cycles.

Thus, these work items have been trickling in (and out).  Since they are
deemed useful in some contexts (and not harmful), they've been moving
forward.  But, it certainly would be good for someone to put in some cycles
to define a model and some guidelines for using websockets for any number
of RAI protocols.

Mary.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Feb 2014 11:59:33 -0500

On 2/13/14 5:02 PM, Mary Barnes wrote:
> list (which is really a lonely and largely ignored mailing list) but no
> one has taken that up:
> Also, no one has put forth a concrete proposal to deal with it and we
> don't do work unless someones willing to put in the cycles.
>
> forward.  But, it certainly would be good for someone to put in some
> cycles to define a model and some guidelines for using websockets for
> any number of RAI protocols.

Mary,

I don't know how to distinguish what belongs on the RAI list vs. the 
dispatch list. But I have a perception that the dispatch list has a 
greater following.

	Thanks,
	Paul

> Mary.
>
>
> On Thu, Feb 13, 2014 at 2:28 PM, Sergio Garcia Murillo
>         Sigh. Yes, once we had the first of these, it was only a matter
>         of time before the flood began.
>
>         Or for each X are we going to have a beauty contest between
>         websockets and data channel?
>
>         Or what?
>
>
>     Completely agree, we should try to "close" that discussion once and
>     for all and not have the same arguments and discussions in each
>     draft. I am not really aware of the IETF process, but could be
>     possible to create a draft to address it?
>
>     Best regards
>     Sergio
>
>
>     _________________________________________________
>     dispatch mailing list
>     https://www.ietf.org/mailman/__listinfo/dispatch
>     <https://www.ietf.org/mailman/listinfo/dispatch>
>
>
>
>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 14 Feb 2014 11:27:22 -0600

On Fri, Feb 14, 2014 at 10:59 AM, Paul Kyzivat <[email-masked]>wrote:

> dispatch list. But I have a perception that the dispatch list has a greater
> following.
>
[MB] It was the ADs that suggested the topic was to be discussed on the RAI
list. But, you are absolutely correct, there are about 200 more people on
the DISPATCH list. However, as I regularly state there are some periodic
discussions on the RAI list that are also of interest so folks really
should consider subscribing to that one:
https://www.ietf.org/mailman/listinfo/rai
For example, Gonzalo started a RAI process discussion a while back:
http://www.ietf.org/mail-archive/web/rai/current/msg01372.html
And, Richard posted an important reminder note about deadlines for IETF-89:
http://www.ietf.org/mail-archive/web/rai/current/msg01430.html

BTW, it's a Friday (today!) for the first time that I can recall in case
anyone was thinking it was another Monday deadline as usual.

I think in one sense, we've ended up with DISPATCH serving as a RAI Area WG
since we don't have the latter.  This "new" process has now been in place
for 5 years, so maybe it is time to reconsider how the area is organized.
 But, of course that discussion should happen on the RAI list and involve
the ADs ;)

[/MB]

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 15 Feb 2014 08:38:13 +1100

On Feb 14, 2014, at 5:38 AM, Paul Kyzivat <[email-masked]> wrote:

> Or for each X are we going to have a beauty contest between websockets and data channel?

Both is the reality of what IETF will probably end up doing 

> Or what?

This really screams for a common framework that guides how to write a spec for X over web sockets or data channels.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 15 Feb 2014 08:42:52 +1100

On Feb 14, 2014, at 8:24 AM, Peter Dunkley <[email-masked]> wrote:

> Because WebSockets is an asynchronous protocol two MSRP peers (that are clients) cannot use MSRP over WebSockets.

Just sort of curios, why can’t this work?

---

From: Peter Dunkley <[email-masked]>
Date: Sun, 16 Feb 2014 21:17:34 +0000

I suppose you could have each peer implementing both the WebSocket client
and server so that they can both send and handle WebSocket handshakes, but
this isn't going to work particularly well when there are NAT devices in
between.  It certainly won't work for peers that are implemented using
Javascript and run in-browser at the moment as the browsers (as far as I
know) only implement the WebSocket client.

An MSRP relay that is a WebSocket can be used for NAT traversal (in the
same way that an ordinary MSRP relay can be) and that is the focus of this
draft.  In the 3GPP world MSRP is B2B'd through an SBC like device and in
that case the peer (which is not a client) could be a WebSocket server -
this is something that Christer may be providing language for in the draft.

Regards,

Peter

On 14 February 2014 21:42, Cullen Jennings <[email-masked]> wrote:

> Just sort of curios, why can't this work?
>
>
>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 16 Feb 2014 22:23:31 +0100

El 14/02/2014 22:38, Cullen Jennings escribió:
> This really screams for a common framework that guides how to write a 
> spec for X over web sockets or data channels.

Agree, that was my point from the beginning. I am willing to collaborate 
in writing that framework.

Best regards
Sergio