Re: [Stox] I-D Action: draft-ietf-stox-groupchat-06.txt

[Saúl Ibarra Corretgé <[e-mail]>]

On 17 Oct 2014, at 03:44, Peter Saint-Andre - &yet <[e-mail]> wrote:

> On 10/15/14, 2:57 PM, Saúl Ibarra Corretgé wrote:
> 
>> We have been using “SIP-to-XMPP” and “XMPP-to-SIP” all along, but now
>> some sections make the distinction and a new "XMPP-to-MSRP” thing
>> appears. Do we want to make this distinction all across or just in
>> the architecture section? For the purpose of gatewaying, SIP and MSRP
>> go together, even if technically they can be different entities. To
>> be clear, the only thing that sounds a bit weird to me is
>> “XMPP-to-MSRP”.
> 
> Hi Saúl, thanks for the feedback!
> 
> Section 4 currently has the following paragraph:
> 
>   These are logical entities, and several of them might be co-located
>   in the same physical entity; e.g., the SIP conference focus and MSRP
>   switch and associated gateways, or the XMPP server and MUC service
>   and associated gateways, might be part of the same deployed code.
> 
> I propose that we change it to:
> 
>   These are logical entities, and several of them might be co-located
>   in the same physical entity.  For example, the SIP conference focus
>   and MSRP switch and associated gateways, or the XMPP server and MUC
>   service and associated gateways, might be part of the same deployed
>   code.  In addition, it is likely that an XMPP service would not have
>   separate gateways for XMPP-to-SIP translation and XMPP-to-MSRP
>   translation, but would instead have a single gateway.
> 
> I agree with you that the concept of a dedicated gateway from XMPP to MSRP seems strange. In particular, I somewhat doubt that, in practice, an XMPP server would separately resolve the hostname of the MSRP switch (as described in Section 6.2 of RFC 4975) and send MSRP traffic over a separate connection; instead, in practice I think it would piggyback the MSRP traffic over its connection to the conference focus, which it would already be using for SIP traffic. However, for the sake of a clear description I think it is best to keep the logical entities and protocols separate from the physical implementation and deployment, as we have done in the latest version of the -groupchat document. The modified paragraph above covers the matter in enough depth that a smart implementer could figure it out.
> 

Agreed! LGTM.


--
Saúl Ibarra Corretgé
AG Projects