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

From: Mary Barnes <[email-masked]>
Date: Fri, 10 Jan 2014 16:58:57 -0600

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.

1)  Section 2 & General.  I'm not sure the documented approach for
separating normative text from non-normative is quite so helpful.  In
general, we expect that in the case of standards track document use RFC
2119 language to indicate normative behaviors.  I think the first sentence
is good, but that's not a terminology thing.   I just don't see a lot of
value in writing the document this way.  For example, the definitions
aren't stated to be non-normative, but I don't see anything normative about
the definitions.  I think you could easily title Section 3 as "WebSocket
Protocol overview" and that would clearly imply non-normative behavior.
 There are also several places in the document in sections that I believe
are intended to provide normative behavior, but there is certainly
non-normative text in those sections (e.g., section 5.2.2, second
paragraph).  I would suggest this document follow the typical (and
accepted) style of identifying normative behavior with 2119 language
(consistently using upper case for normative behavior and avoiding using
2119 language in cases where alternative words can be substituted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear
to me this is normative behavior.  I don't think it is since it's referring
to existing 4975 behavior. However, I didn't see that the reference given
in 4975 relates to the second part of that sentence stating that
implementations "should" already be allowing unrecognized transports.  It
would be quite useful to have the exact reference here as I was trying to
double check this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would
be non-normative.  In particular given that 2119 language is clearly being
used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered
non-normative. AGain, you have 2119 language in this section.

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?

6) Section 11.  You should change the name of the registry to be the exact
name of the IANA registry to avoid any confusion.- i.e.,:
OLD:
  registry of WebSocket sub-protocols
NEW:
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I
would suggest you use the same information as the pointer to the
Subprotocol Definition (i.e., this RFC).

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.

On Thu, Dec 12, 2013 at 6:57 PM, <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : The WebSocket Protocol as a Transport for the
> Message Session Relay Protocol (MSRP)
>         Author(s)       : Peter Dunkley
>                           Gavin Llewellyn
>                           Victor Pascual
>                           Anton Roman
>                           Gonzalo Salgueiro
>         Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>         Pages           : 21
>         Date            : 2013-12-12
>
> Abstract:
>    The WebSocket protocol enables two-way real-time communication
>    between clients and servers.  This document specifies a new WebSocket
>    sub-protocol as a reliable transport mechanism between MSRP (Message
>    Session Relay Protocol) clients and relays to enable usage of MSRP in
>    new scenarios.  This document normatively updates RFC 4975 and RFC
>    4976.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-pd-dispatch-msrp-websocket-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Jan 2014 08:52:49 +0000

Hi,

I have not followed the work on this draft, so I appologize if the following has been discussed.

While I do understand that a WS Client has to establish the WebSocket with the Web Server, I don't understand why we need to mandate the WS Server to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.

Regards,

Christer

Lähettäjä: dispatch [mailto:[email-masked]] Puolesta Mary Barnes
Lähetetty: 11. tammikuuta 2014 0:59
Vastaanottaja: DISPATCH
Kopio: Ben Campbell; [email-masked]
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

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.

1)  Section 2 & General.  I'm not sure the documented approach for separating normative text from non-normative is quite so helpful.  In general, we expect that in the case of standards track document use RFC 2119 language to indicate normative behaviors.  I think the first sentence is good, but that's not a terminology thing.   I just don't see a lot of value in writing the document this way.  For example, the definitions aren't stated to be non-normative, but I don't see anything normative about the definitions.  I think you could easily title Section 3 as "WebSocket Protocol overview" and that would clearly imply non-normative behavior.  There are also several places in the document in sections that I believe are intended to provide normative behavior, but there is certainly non-normative text in those sections (e.g., section 5.2.2, second paragraph).  I would suggest this document follow the typical (and accepted) style of identifying normative behavior with 2119 language (consistently using upper case for normative behavior and avoiding using 2119 language in cases where alternative words can be substituted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear to me this is normative behavior.  I don't think it is since it's referring to existing 4975 behavior. However, I didn't see that the reference given in 4975 relates to the second part of that sentence stating that implementations "should" already be allowing unrecognized transports.  It would be quite useful to have the exact reference here as I was trying to double check this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would be non-normative.  In particular given that 2119 language is clearly being used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered non-normative. AGain, you have 2119 language in this section.

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?

6) Section 11.  You should change the name of the registry to be the exact name of the IANA registry to avoid any confusion.- i.e.,:
OLD:
  registry of WebSocket sub-protocols
NEW:
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I would suggest you use the same information as the pointer to the Subprotocol Definition (i.e., this RFC).

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.

On Thu, Dec 12, 2013 at 6:57 PM, <[email-masked]<mailto:[email-masked]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
        Author(s)       : Peter Dunkley
                          Gavin Llewellyn
                          Victor Pascual
                          Anton Roman
                          Gonzalo Salgueiro
        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
        Pages           : 21
        Date            : 2013-12-12

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

---

From: Peter Dunkley <[email-masked]>
Date: Sun, 19 Jan 2014 13:52:57 +0000

Hello,

Perhaps the document title should be corrected. MSRP-CEMA is outside of the
scope of this document as this document is intended to describe connecting
to a WebSocket server that is an MSRP relay.

I can see no reason why MSRP-CEMA can't be used over WebSockets, but if
anyone has an interest in this I think that they should put it in a
document of its own.

Regards,

Peter

On 18 January 2014 08:52, Christer Holmberg
<[email-masked]>wrote:

> While I do understand that a WS Client has to establish the WebSocket with
> the Web Server, I don’t understand why we need to mandate the WS Server to
> be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *Lähettäjä:* dispatch [mailto:[email-masked]] *Puolesta *Mary
> Barnes
> *Lähetetty:* 11. tammikuuta 2014 0:59
> *Vastaanottaja:* DISPATCH
> *Kopio:* Ben Campbell; [email-masked]
> *Aihe:* Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
>
>
>
> 2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not
> clear to me this is normative behavior.  I don't think it is since it's
> referring to existing 4975 behavior. However, I didn't see that the
> reference given in 4975 relates to the second part of that sentence stating
> that implementations "should" already be allowing unrecognized transports.
>  It would be quite useful to have the exact reference here as I was trying
> to double check this point and I couldn't find it.
>
>
>
> 3) Section 6.  I'm really puzzled as to why the Connection Keep-alive
> would be non-normative.  In particular given that 2119 language is clearly
> being used.
>
>
>
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories:
> http://www.ietf.org/shadow.html

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Jan 2014 03:28:50 +0000

Hi,

I see no reason why it should be a separate document, as it should not have any affect on the websocket specific procedures, which is the main scope of the document.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Peter Dunkley <[email-masked]> wrote:

Hello,

Perhaps the document title should be corrected. MSRP-CEMA is outside of the scope of this document as this document is intended to describe connecting to a WebSocket server that is an MSRP relay.

I can see no reason why MSRP-CEMA can't be used over WebSockets, but if anyone has an interest in this I think that they should put it in a document of its own.

Regards,

Peter

On 18 January 2014 08:52, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

While I do understand that a WS Client has to establish the WebSocket with the Web Server, I don’t understand why we need to mandate the WS Server to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.

Regards,

Christer

Lähettäjä: dispatch [mailto:[email-masked]<mailto:[email-masked]>] Puolesta Mary Barnes
Lähetetty: 11. tammikuuta 2014 0:59
Vastaanottaja: DISPATCH
Kopio: Ben Campbell; [email-masked]<mailto:[email-masked]>
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Regards,
Mary.

Abstract:

Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> directories: http://www.ietf.org/shadow.html

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Ben Campbell <[email-masked]>
Date: Sun, 19 Jan 2014 22:32:21 -0600

> I see no reason why it should be a separate document, as it should not have any affect on the websocket specific procedures, which is the main scope of the document.

Christer, I assume you mean for a WebSocket MSRP "server" acting on behalf of a WS MSRP client to be able to use CEMA between itself and a third party client? Not between a WebSocket MSRP client and a WebSocket MSRP server, right?

> On 18 January 2014 08:52, Christer Holmberg <[email-masked]> wrote:
> Hi,
> 
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Jan 2014 06:12:58 +0000

Hi Ben,

My thinking is that the WS client could indicate support of CEMA.

Regards,

Christer

Sent from Windows Mail

From: Ben Campbell<mailto:[email-masked]>
Sent: ‎Monday‎, ‎January‎ ‎20‎, ‎2014 ‎6‎:‎32‎ ‎AM
To: Christer Holmberg<mailto:[email-masked]>
Cc: Peter Dunkley<mailto:[email-masked]>, Mary Barnes<mailto:[email-masked]>, DISPATCH<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

---

From: Peter Dunkley <[email-masked]>
Date: Mon, 20 Jan 2014 09:44:53 +0000

Hi Christer,

There is working code for the document as-is and plans for more
implementations. I think that if someone has a need for MSRP-CEMA in this
scenario then they should join with the current authors to contribute the
text and working code for this.

Regards,

Peter

On 20 January 2014 03:28, Christer Holmberg
<[email-masked]>wrote:

>  Perhaps the document title should be corrected. MSRP-CEMA is outside of
> the scope of this document as this document is intended to describe
> connecting to a WebSocket server that is an MSRP relay.
>
>> While I do understand that a WS Client has to establish the WebSocket
>> with the Web Server, I don’t understand why we need to mandate the WS
>> Server to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>>
>>
>>
>>
>> 6) Section 11.  You should change the name of the registry to be the
>> exact name of the IANA registry to avoid any confusion.- i.e.,:
>>
>> OLD:
>>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Jan 2014 09:55:18 +0000

Hi Peter,

I am willing to help, and contribute text.

But, I request that we don't move the document forward before I've had a chance to do that :)

(3GPP also has a requirement to specify the usage of MSRP over WebSocket.)

Regards,

Christer

Lähettäjä: Peter Dunkley [mailto:[email-masked]]
Lähetetty: 20. tammikuuta 2014 11:45
Vastaanottaja: Christer Holmberg
Kopio: Mary Barnes; DISPATCH; Ben Campbell; [email-masked]
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Hi Christer,

There is working code for the document as-is and plans for more implementations. I think that if someone has a need for MSRP-CEMA in this scenario then they should join with the current authors to contribute the text and working code for this.

Regards,

Peter

On 20 January 2014 03:28, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

Peter Dunkley <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Regards,

Peter

Regards,

Christer

Regards,
Mary.

Abstract:

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jan 2014 08:43:20 +0000

Hi,

I made a false statement earlier, regarding 3GPP.

3GPP does not have requirement to transport MSRP over WebSocket.

Sorry for the confusion.

Regards,

Christer

Lähettäjä: dispatch [mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 20. tammikuuta 2014 11:55
Vastaanottaja: Peter Dunkley
Kopio: DISPATCH; Ben Campbell; [email-masked]
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Hi Peter,

Regards,

Christer

Kopio: Mary Barnes; DISPATCH; Ben Campbell; [email-masked]<mailto:[email-masked]>

Hi Christer,

Regards,

Peter

Hi,

Regards,

Christer

Hello,

Regards,

Peter

Regards,

Christer

Regards,
Mary.

Abstract:

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jan 2014 09:43:14 +0000

Hi,

>I believe current approach for 3GPP (WebRTC access to IMS) is datachannel transport for both MSRP and BFCP being open to other mechanisms like websocket.

Correct.

Regards,

Christer

2014/1/21 Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Hi,

Sorry for the confusion.

Regards,

Christer

Lähettäjä: dispatch [mailto:[email-masked]<mailto:[email-masked]>] Puolesta Christer Holmberg
Lähetetty: 20. tammikuuta 2014 11:55
Vastaanottaja: Peter Dunkley
Kopio: DISPATCH; Ben Campbell; [email-masked]<mailto:[email-masked]>

Hi Peter,

Regards,

Christer

Hi Christer,

Regards,

Peter

Hi,

Regards,

Christer

Hello,

Regards,

Peter

Regards,

Christer

Regards,
Mary.

Abstract:

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 21 Jan 2014 14:31:47 +0000

So just to be explicit; despite DC being the preferred transport for 3GPP, are we are still waiting on supplementary text from you on MSRP-CEMA for this MSRPoWS draft?  If so, when do we expect to have that so we can progress the draft?  We have some pending edits to make after Ben and Mary's reviews, but we plan to publish a new version soon. It would be good to incorporate this new text along with those other edits.

Cheers,

Gonzalo

On Jan 21, 2014, at 4:43 AM, Christer Holmberg <[email-masked]> wrote:

> 2014/1/21 Christer Holmberg <[email-masked]>
> Hi,
>  
> But, I request that we don’t move the document forward before I’ve had a chance to do that :)
>  
> On 20 January 2014 03:28, Christer Holmberg <[email-masked]> wrote:
> Hi,
>  
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Victor Pascual <[email-masked]>
Date: Tue, 21 Jan 2014 10:33:35 +0100

I believe current approach for 3GPP (WebRTC access to IMS) is datachannel
transport for both MSRP and BFCP being open to other mechanisms like
websocket.

*Victor Pascual*
Chief Strategy Officer @ Quobis <http://www.quobis.com/> | e:
[email-masked] | m:  +34630169875 | t: +34902999465

> *Lähettäjä:* dispatch [mailto:[email-masked]] *Puolesta *Christer
> Holmberg
> *Lähetetty:* 20. tammikuuta 2014 11:55
> *Vastaanottaja:* Peter Dunkley
> *Kopio:* DISPATCH; Ben Campbell;
> [email-masked]
>
> *Lähettäjä:* Peter Dunkley [mailto:[email-masked]<[email-masked]>]
>
> *Lähetetty:* 20. tammikuuta 2014 11:45
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* Mary Barnes; DISPATCH; Ben Campbell;
> [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jan 2014 11:00:09 +0000

Hi Gonzalo,

> So just to be explicit; despite DC being the preferred transport for 3GPP, are we are still waiting on supplementary text from you on MSRP-CEMA 
> for this MSRPoWS draft?  If so, when do we expect to have that so we can progress the draft?  We have some pending edits to make after Ben 
> and Mary's reviews, but we plan to publish a new version soon. It would be good to incorporate this new text along with those other edits.

As there is no 3GPP connection, I would have to put this pretty far down on my priority list. And, as I don't want to hold the work, I guess the best thing is for you to move on with the work.

Mabye you could add a note to the draft, saying something like:

"NOTE: As the WebSocket server acts as a MSRP relay, the usage of MSRP-CEMA [RFC6714] will be disabled in most cases. A mechanism where the WebServer does not act as a MSRP relay is outside the scope of this document, and would have to be defined in a specification."

In addition, I think it would be good to point out that RFC 6135 (An Alternative Connection Model for the MSRP) CAN be used with MSRP over WebSocket. That has no impact on the mechanism itself, and is not impacted by the usage of relays.

Regards,

Christer

> 2014/1/21 Christer Holmberg <[email-masked]> Hi,
>  
> Kopio: DISPATCH; Ben Campbell; 
> Kopio: Mary Barnes; DISPATCH; Ben Campbell; 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  
> 
> 
>  
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
> 
> 
>  
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 22 Jan 2014 16:20:49 +0000

Hi Christer - 

> As there is no 3GPP connection, I would have to put this pretty far down on my priority list. And, as I don't want to hold the work, I guess the best thing is for you to move on with the work.

OK. I didn't think the text contribution you would be proposing would be that significant.  Were you?  I'm happy to work with you on it if you'd like or we can discuss in London if you prefer.  I certainly don't want to lock you out from making the contribution you wanted.
> In addition, I think it would be good to point out that RFC 6135 (An Alternative Connection Model for the MSRP) CAN be used with MSRP over WebSocket. That has no impact on the mechanism itself, and…

Sounds reasonable, but it doesn't need to be in lieu of the more detailed contribution you suggested earlier if we can get it done in a reasonable amount of time.

Cheers,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jan 2014 16:26:30 +0000

Hi,

I don't think there would be much text needed to cover CEMA. But, I thought you wanted the text yesterday:ish 😊

But, if you want to talk about it, and we have some time, I’ll be happy to contribute.

Regards,

Christer

Sent from Windows Mail

From: [email-masked]<mailto:[email-masked]>
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎6‎:‎20‎ ‎PM
To: Hans-Christer Holmberg<mailto:[email-masked]>
Cc: DISPATCH<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Hi Christer -

Cheers,

Gonzalo

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 22 Jan 2014 16:33:37 +0000

> I don't think there would be much text needed to cover CEMA. But, I thought you wanted the text yesterday:ish 😊

That would be nice, but this is the IETF after all and such speeds could get folks hurt ;-)
> But, if you want to talk about it, and we have some time, I’ll be happy to contribute.

Then let's plan to do that.  I think if we could agree on some early text by the draft deadline (Feb 14) that would be good. Would that work for you?

Gonzalo
 
> From: [email-masked]
> To: Hans-Christer Holmberg
> Cc: DISPATCH, [email-masked]
> 
> Hi Christer - 
> 
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 29 Jan 2014 18:14:41 +0000

On Jan 18, 2014, at 1:52 AM, Christer Holmberg <[email-masked]> wrote:

> While I do understand that a WS Client has to establish the WebSocket with the Web Server, I don’t understand why we need to mandate the WS Server to be an MSRP Relay. 

Any comments on Christer’s original question here ?