Subject: [dispatch] Review of draft-ivov-xmpp-cusax-02

From: <[email-masked]>
Date: Sun, 27 Jan 2013 21:15:46 +0000

Hi,

I did a review of draft-ivov-xmpp-cusax-02.

* Overview

The draft describes good practices for providing a full set of telephony, video call, IM and presence type of services with complementary use of SIP and XMPP. SIP is used for telephony and video calls, while XMPP in practice for the rest. The draft does not propose any new SIP or XMPP protocol extensions to achieve this, but explains how client developers and service providers can use the protocols' existing capabilties in a smart way to offer good user experience. 

* General comments

I personally believe there is a lot of merit in the approach presented in the draft. Although it might not become a massively popular deployment case, there are a number of interested client developers and service providers, and the document gives them useful guidance. For some currently not yet interested it might give new ideas. So I'm in favor of publishing this as BCP, but I think at least one more revision is needed. 

Some clarification could still be added about the deployment cases considered: 
- A single combined SIP + XMPP service provider vs. an opportunistic SIP ´+ XMPP client making use of two indepdendent services. I belive the former is the primary case but the latter is not totally scoped out either?
- Intra vs. inter-domain use: Some features seem to be more realistic in single domain communication as compared to inter-domain?

One or two ascii art figures might be useful to explain the setups. 

The document is quite short. However, it would be good to consider if the actual recommendations could be summarized at the end of each Section, or make them stand out better in some other way. Especially when there is a recommendation to implement and use a particular SIP or XMPP extension. 

A potentially interesting case these days that is not covered in the draft is the interconnection between two WebRTC service providers. SIP is usually expected to be the poison of choice for telephony or video calls, but if messaging and presence type of services are included, perhaps CUSAX approach might make sense. On the other hand including this type of scenario might confuse the draft a bit too much.

* Detailed comments

-- Abstract:

- "This document describes current practices..."

I understanding this wording comes from Best Current Practices. For me, however, something like "recommended practices" would make more sense, since I believe for most part the proposed practices are not yet in use. 

-- Introduction:

- The targeted deployment scenarious could be explained here in a bit more detail. 

- Short description of document organization at the end of Introduction would be useful, even if this is a very simple document.

-- Client bootstrap

The draft says: "While it should be possible for CUSAX users to manually configure
   their separate SIP and XMPP accounts, dual-stack SIP/XMPP clients
   ought to provide means of online provisioning.  While the specifics
   of such mechanisms are outside the scope of this specification, they
   should make it possible for a service provider to remotely configure
   the clients based on minimal user input (e.g., only a user ID and
   password)."

It is clearly said the mechanisms are out of scope. But in terms of interoperability and deployment scenarios this is an important question. Naturally any proprietary mechanisms can be used, but that limits the deployment to cases where there is some kind of special relationship between the SIP + XMPP client and at least some part of the server infra. For independent clients, it would be useful to at least point out and probably recommend some mechanisms. In SIP there is the relatively recent UA configuration work, and I believe XMPP has something directly targeted for account/client provisioning. Those should be brought up. 

-- Operation

- "An alternate mechanism would be for CUSAX clients to add to their SIP
   invite requests a Contact header containing the XMPP URI
   corresponding to their JID as per [RFC5122]."

The mechanism is mentioned but it is not clear how seriously it should be taken by client developers. Shouldn't it be more clearly recommended for the clients to support?

-- Federation

- Some text seems to be missing here.

Regards,
	Markus