CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)
draft-ivov-xmpp-cusax-09

[Ballot discuss]
Section 2, third paragraph:

The first sentence is ungrammatical. I think you mean:

  A CUSAX client should make it possible for a user to configure a
  default protocol to use for any given feature (say, SIP for video
  conferencing and XMPP for textual chat).

But I'm still awfully confused. The second sentence has no object. Are you saying that the *user* be allowed to disable video and audio features over XMPP? Or is this sentence saying that the client should *default* to disabling those features? If the former, then the last sentence makes no sense (and it conflicts with the first sentence too). If the latter, then "In particular" makes no sense.

[Ballot comment]
Introduction: I suggest the following change:

OLD
  This document explains how such hybrid offerings can be achieved with
  a minimum of modifications to existing software while providing an
  optimal user experience.
NEW
  This document suggests different configuration options and minimal
  modifications to existing software so that clients and servers can
  offer these hybrid services while providing an optimal user
  experience.

The passive construction of "can be achieved" (by whom?), along with never truly stating in the introduction what precisely this document is doing (suggesting software changes and configuration particulars),  caused a bit of my confusion about some of this document. This parallels recent changes to the Abstract.

Section 3.1, first sentence: Shouldn't it really say:

  In order for CUSAX to function properly, XMPP service administrators
  should make sure that at least one of the vCard [RFC6350] "tel"
  fields for each contact is properly populated with the SIP URI for
  the SIP audio/video service provided by the CUSAX server.

I don't understand why a phone number would be useful for CUSAX purposes.

Section 3.1, third paragraph: Do you really mean "mostly" and not "only"? How could an XMPP service "know" the right URI if it's not part of a CUSAX service?

Section 3.3, second paragraph: Can you change the parenthetical to say instead:

  (e.g., if there is no "video" tel type for a particular contact, the
  client could disable the "video call" button for that contact.)

I don't want you to say things that will encourage clients to *take away* functionality.

Section 3.4: The first paragraph and last paragraph make it sound like you are addressing the confusion on the telephony side of things. I now get that you meant it for the IM side of things as well. Perhaps clarify to indicate that the confusion could occur for either IM or telephony.

[Ballot discuss]
Section 2, third paragraph:

The first sentence is ungrammatical. I think you mean:

  A CUSAX client should make it possible for a user to configure a
  default protocol to use for any given feature (say, SIP for video
  conferencing and XMPP for textual chat).

But I'm still awfully confused. The second sentence has no object. Are you saying that the *user* be allowed to disable video and audio features over XMPP? Or is this sentence saying that the client should *default* to disabling those features? If the former, then the last sentence makes no sense (and it conflicts with the first sentence too). If the latter, then "In particular" makes no sense.

Section 3.1, first sentence: Shouldn't it really say:

  In order for CUSAX to function properly, XMPP service administrators
  should make sure that at least one of the vCard [RFC6350] "tel"
  fields for each contact is properly populated with the SIP URI for
  the SIP audio/video service provided by the CUSAX server.

I don't understand why a phone number would be useful for CUSAX purposes.

[Ballot comment]
Introduction: I suggest the following change:

OLD
  This document explains how such hybrid offerings can be achieved with
  a minimum of modifications to existing software while providing an
  optimal user experience.
NEW
  This document suggests different configuration options and minimal
  modifications to existing software so that clients and servers can
  offer these hybrid services while providing an optimal user
  experience.

The passive construction of "can be achieved" (by whom?), along with never truly stating in the introduction what precisely this document is doing (suggesting software changes and configuration particulars),  caused a bit of my confusion about some of this document. This parallels recent changes to the Abstract.

Section 3.1, third paragraph: Do you really mean "mostly" and not "only"? How could an XMPP service "know" the right URI if it's not part of a CUSAX service?

Section 3.3, second paragraph: Can you change the parenthetical to say instead:

  (e.g., if there is no "video" tel type for a particular contact, the
  client could disable the "video call" button for that contact.)

I don't want you to say things that will encourage clients to *take away* functionality.

Section 3.4: The first paragraph and last paragraph make it sound like you are addressing the confusion on the telephony side of things. I now get that you meant it for the IM side of things as well. Perhaps clarify to indicate that the confusion could occur for either IM or telephony.

[Ballot discuss]
As far as technical concerns:

Section 2, third paragraph:

The first sentence is ungrammatical. I think you mean:

  A CUSAX client should make it possible for a user to configure a
  default protocol to use for any given feature (say, SIP for video
  conferencing and XMPP for textual chat).

But I'm still awfully confused. The second sentence has no object. Are you saying that the *user* be allowed to disable video and audio features over XMPP? Or is this sentence saying that the client should *default* to disabling those features? If the former, then the last sentence makes no sense (and it conflicts with the first sentence too). If the latter, then "In particular" makes no sense.

Section 3.1, first sentence: Shouldn't it really say:

  In order for CUSAX to function properly, XMPP service administrators
  should make sure that at least one of the vCard [RFC6350] "tel"
  fields for each contact is properly populated with the SIP URI for
  the SIP audio/video service provided by the CUSAX server.

I don't understand why a phone number would be useful for CUSAX purposes.

[Ballot comment]
Introduction: I suggest the following change:

OLD
  This document explains how such hybrid offerings can be achieved with
  a minimum of modifications to existing software while providing an
  optimal user experience.
NEW
  This document suggests different configuration options and minimal
  modifications to existing software so that clients and servers can
  offer these hybrid services while providing an optimal user
  experience.

The passive construction of "can be achieved" (by whom?), along with never truly stating in the introduction what precisely this document is doing (suggesting software changes and configuration particulars),  caused a bit of my confusion about some of this document. This parallels recent changes to the Abstract.

Section 3.1, third paragraph: Do you really mean "mostly" and not "only"? How could an XMPP service "know" the right URI if it's not part of a CUSAX service?

Section 3.3, second paragraph: Can you change the parenthetical to say instead:

  (e.g., if there is no "video" tel type for a particular contact, the
  client could disable the "video call" button for that contact.)

I don't want you to say things that will encourage clients to *take away* functionality.

Section 3.4: The first paragraph and last paragraph make it sound like you are addressing the confusion on the telephony side of things. I now get that you meant it for the IM side of things as well. Perhaps clarify to indicate that the confusion could occur for either IM or telephony.

[Ballot comment]
Thanks for addressing Benson's OPS DIR review.

-
One open question for section 3.2. Service Management: Any impact on the network operations when you switch between SIP/XMPP. Do you foresee the case where the end user could select SIP/XMPP for different features?
In this case, there is an impact on the network operation. For example: QoS, security?
Ex: the suggestion is to prefer SIP for audio and video. So QoS would be set up for SIP in the network.
If the end user now selects XMPP, the network operations must take this into account, to have the same QoS.
Ex: in an enterprise, a file transfer within a chat window, might have to checked for document leakage issues.
If the end user changes the XMPP <-> SIP, network operations must take this into account.
So basically my message is that changing the SIP/XMPP feature options in the client might has some impact: QoS, security, ... basically the flow treatment. In other words, the network operations must foresee, in advance, all the potential combinations of features between XMPP and SIP
Should we say a few words about this?

-
"Despite these advances, SIP remains the protocol of choice for telephony-like services, especially in enterprises where users are accustomed to features such as voice mail, call park, call queues, conference bridges and many others that are rarely (if at all) available in Jingle-based software. "

I don't understand "Despite these advances, SIP remains the protocol of choice"
Which advances? XMPP?

[Ballot comment]
Thanks for addressing Benson's OPS DIR review.

-
One open question for section 3.2. Service Management: Any impact on the network operations when you switch between SIP/XMPP. Do you foresee the case where the end user could select SIP/XMPP for different features?
In this case, there is an impact on the network operation. For example: QoS, security?
Ex: the suggestion is to prefer SIP for audio and video. So QoS would be set up for SIP in the network.
If the end user now selects XMPP, the network operations must take this into account, to have the same QoS.
Ex: in an enterprise, a file transfer within a chat window, might have to checked for document leakage issues.
If the end user changes the XMPP <-> SIP, network operations must take this into account.
So basically my message is that changing the SIP/XMPP feature options in the client might has some impact: QoS, security, ... basically the flow treatment. In other words, the network operations must foresee, in advance, all the potential combinations of features between XMPP and SIP
Should we say a few words about this?

-
"Despite these advances, SIP remains the protocol of choice for telephony-like services, especially in enterprises where users are accustomed to features such as voice mail, call park, call queues, conference bridges and many others that are rarely (if at all) available in Jingle-based software. "

I don't understand "Despite these advances, SIP remains the protocol of choice"
Which advances? XMPP?


-

  Finally, this document makes a further simplifying assumption by
  discussing only the use of a single client, not use of and
  coordination among multiple endpoints controlled by the same user

"of and"

[Ballot comment]
I have to say that in this case I do not share the concerns of my distinguished colleague from Urbana.  I find this document mostly reasonable, by way of considered advice to those trying to deployed a mixed SIP/XMPP application environment.  I do agree that saying more strongly that this is just that -- considered advice -- and no more, would be good.

You missed an opportunity to give examples using John, Joan, Bill, and Susie (a bunch of CUSAX).  Pity.

Three non-blocking comments; feel free to chat with me about them if you please:

-- Section 2 --

  Because many of the features that a CUSAX client would prefer in one
  protocol would also be available in the other, clients should make it
  possible for such features to be disabled for a specific account.  In
  particular, it is suggested that clients allow for audio and video
  calling features to be disabled for XMPP accounts, and that instant
  messaging and presence features should also be made optional for SIP
  accounts.

Hm.
This document is talking about how to use SIP and XMPP alongside each other, not at different ends of the same pipe.  So, isn't it likely that, say, John might want to make voice calls to both Joan and Susie, where he needs SIP to talk with Joan and XMPP to talk with Susie (and similarly for IM services)?  Wouldn't it, therefore, be better to allow preference settings for calling features, which might be customizable by user or overridable by instance?

-- Section 6 --
I agree with the idea that the document should be clearer about these recommendations being very soft, and the first paragraph of Section 6 would be one good place to say that.  As it is, the two non-bullet paragraphs make it sound pretty close to BCP advice.

-- References --
I'm a believer that Informational documents do merit normative references, and for this document I think SIP and XMPP are normative references.  I'm not putting this at DISCUSS level, so it's non-blocking, but I strongly urge you to make that change.

[Ballot comment]
This looks a lot like work that someone already did e.g. at jitsi. I am curious if they could reference that work. becuase that takes it from the realm of "here's what you can do", to "here's what we did"

[Ballot discuss]
I would like to hear why this is being put forward now as informational instead of bringing this to STOX (or a different WG) and doing the proper work to do either a BCP or standards track document. There are quite a few problems still in this document that should get proper review, and I'm afraid that the instructions in here will be taken as IETF consensus to do these things, statements about not being normative notwithstanding.

As far as technical concerns:

Section 2:

  Because many of the features that a CUSAX client would prefer in one
  protocol would also be available in the other, clients should make it
  possible for such features to be disabled for a specific account.

Disabled by whom? I believe in Jingle there is a way for the client to discover whether or not voice or video features are available; I presume that SIP has something similar to indicate the lack of IM/presence features. Are you simply saying that clients should be able to track which features are available per protocol, even if they show the combination of features on a per-remote-user basis?

Section 3.1:

I understand the desire for the server to pre-populate XMPP vcards with the SIP URI it knows about, but that's no different than the server pre-populating any fields (e.g., email address, web page) that it knows about because the server is providing all of those services, so I'm not sure why this case is special. But I don't get this:

  To ensure that the foregoing approach is always respected, service
  providers might consider (1) preventing clients (and hence users)
  from modifying the vCard "tel" fields...
 
That encourages horribly unfriendly server behavior. It's one thing for a server to keep it's own particular locked field in a vcard for information that it knows about, and it's fine for server policy _independent of CUSAX_ to be that users can't change their contact information, but this suggestion amounts to "If you have been letting users change *any* of their vcard telephone information (be it their lab extension, their home phone number, their fax number), and you decide to provide CUSAX services, lock down the tel fields in their vcards completely." That's terrible advice and harmful to users. Applying validation is the only good advice to give here.

Section 3.3, second paragraph, does not take into account out of band information. If you had stuck to the first part of the sentence, where it's only talking about using the information as a hint, I would not complain, but what appears in the roster entry is far from the only place this information is gleaned by clients. (I wish clients would update the rest of the vcard in rosters from directory information they possess, but they often don't.) Don't say things that will encourage clients to *take away* functionality.

Section 3.4, last paragraph. I don't get this. You seem to be talking about the case where I have an XMPP roster entry with a tel URI in it, and I am on a CUSAX client that is also talking to a SIP service. Assuming I (the user) have not configured the client to only use SIP, I'm *always* going to offer XMPP telephony if it's available and I don't have a pre-existing relationship configured between the URI and a particular service. I don't understand what the last sentence adds.

Section 4, first paragraph: s/would normally be disabled/might be disabled. Also, the same problem exists here with figuring out who is providing the information. Do you mean that a CUSAX-aware SIP conference server can provide an XMPP MUC and a CUSAX-aware MUC server can provide a SIP URI?

[Ballot comment]
Figure 2 has all sorts of implications that I don't get. Why is that User Directory a single box, and why is there an arrow *to* it from the Provisioning Server? What's the expectation there?

Section 3.4, second paragraph, s/XMPP and SIP/telephony-capable. That there are multiple accounts of a particular protocol doesn't affect this issue; it's only telephony-capable accounts, whatever the protocol.

Section 3.5, first paragraph: It was confusing to figure out which client was which. The first and second "clients" refers to clients that *receive* calls. AFAICT, the last "clients" in that paragraph refers to *calling* clients providing that data to avoid effort on the part of *receiving* clients. Right?

Section 3.5, second paragraph: s/a vCard entry/a vCard entry in the roster.

Section 4, third paragraph: Please make clear at the beginning of the paragraph that you've switched from talking about clients to talking about servers. I was very confused for a few sentences.

Section 5, second to last paragraph: A CUSAX service can't provide a user interface warning; only the client can.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ivov-xmpp-cusax-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the
  Extensible Messaging and Presence Protocol (XMPP)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-07-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes suggested practices for combined use of the
  Session Initiation Protocol (SIP) and the Extensible Messaging and
  Presence Protocol (XMPP).  Such practices aim to provide a single
  fully featured real-time communication service by using complementary
  subsets of features from each of the protocols.  Typically such
  subsets would include telephony capabilities from SIP and instant
  messaging and presence capabilities from XMPP.  This specification
  does not define any new protocols or syntax for either SIP or XMPP.
  However, implementing the practices outlined in this document may
  require modifying or at least reconfiguring existing client and
  server-side software.  Also, it is not the purpose of this document
  to make recommendations as to whether or not such combined use should
  be preferred to the mechanisms provided natively by each protocol
  (for example, SIP's SIMPLE or XMPP's Jingle).  It merely aims to
  provide guidance to those who are interested in such a combined use.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO questionnaire for: draft-ivov-xmpp-cusax-06

To be Published as: Informational

Prepared by: Mary Barnes (mary.ietf.barnes@gmail.com) on 13 June 2013


  (1) What type of RFC is being requested (BCP, Proposed Standard,
      Internet Standard, Informational, Experimental, or Historic)?
      Why is this the proper type of RFC?  Is this type of RFC indicated
      in the title page header?

This document is requested to be published as Informational. This is
the proper type of RFC as it defines no new protocol elements nor does
it require any IANA registrations.  This RFC type is indicated on the
title page.

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up.
        Recent examples can be found in the "Action" announcements for
        approved documents. The approval announcement contains the
        following sections:

        Technical Summary:

This document describes suggested practices for combined use of the
Session Initiation Protocol (SIP) and the Extensible Messaging and
Presence Protocol (XMPP).  Such practices aim to provide a single
fully featured real-time communication service by using complementary
subsets of features from each of the protocols.  Typically such
subsets would include telephony capabilities from SIP and instant
messaging and presence capabilities from XMPP.  This specification
does not define any new protocols or syntax for either SIP or XMPP.
However, implementing it may require modifying or at least
reconfiguring existing client and server-side software.  Also, it is
not the purpose of this document to make recommendations as to
whether or not such combined use should be preferred to the
mechanisms provided natively by each protocol (for example, SIP's
SIMPLE or XMPP's Jingle).  It merely aims to provide guidance to
those who are interested in such a combined use.

        Working Group Summary:
        Was the document considered in any WG, and if so, why was
        it not adopted as a work item there? Was there controversy
        about particular points that caused the WG to not adopt the
        document?

Per the RAI area process for new work, this document has been reviewed
in the DISPATCH WG. The DISPATCH WG does not progress any documents as
WG documents.  The DISPATCH WG selects one the following actions for
contributions to the WG that have been adequately reviewed and
discussed:
- None in the case of work items for which there is inadequate
interest or feedback indicates that the work should not be progressed
(e.g., it's a bad idea or not within scope for RAI area or IETF)
- New work item in currently chartered WG
- New WG or mini-WG in the case where the deliverable is likely a
single document - e.g. a new SIP header
- IETF official BoF - typically for work items that are of broad
interest and potential impact within the RAI area and across areas.
- Individual/AD sponsored - for items limited in scope and applicability

Individual/AD sponsored was the consensus of the DISPATCH WG for this
document and the AD(s) agreed to progress the document.  There was no
controversy around this decision.

        Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

This document provides suggested practices for the combined usage of
two existing protocols: SIP and XMPP.  There are folks that support
both SIP and XMPP in their products that plan to follow the practices
as outlined in this document.  Aaron Evans and Dan Christian Bogos
both reviewed the -04 version of this document and deemed it a useful
reference that they plan to follow for their implementations.  Markus
Isomaki reviewed the -02 version and his comments were incorporated in
a subsequent revision.  In addition, other experts/implementers have
reviewed the document as described in the Acknowledgement section of
the document.

        Personnel
        Who is the Document Shepherd? Who is the Responsible Area
        Director?

Mary Barnes (DISPATCH WG co-chair) is the Document Shepherd.  Gonzalo
Camarillo is the Responsible AD.

    (3) Briefly describe the review of this document that was
        performed by the Document Shepherd.  If this version of
        the document is not ready for publication, please explain
        why the document is being forwarded to the IESG.

The Document Shepherd has thoroughly reviewed this version of the document.

    (4) Does the document Shepherd have any concerns about the depth
        or breadth of the reviews that have been performed?

There are no concerns about the depth or breadth of the reviews.

    (5) Do portions of the document need review from a particular
        or from broader perspective, e.g., security, operational
        complexity, AAA, DNS, DHCP, XML, or internationalization?
        If so, describe the review that took place.
No.

    (6) Describe any specific concerns or issues that the Document
        Shepherd has with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document,
        or has concerns whether there really is a need for it. In any
        event, if the interested community has discussed those issues
        and has indicated that it still wishes to advance the document,
        detail those concerns here.

There are no specific concerns or issues.

    (7) Has each author confirmed that any and all appropriate IPR
        disclosures required for full conformance with the provisions
        of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.

    (8) Has an IPR disclosure been filed that references this document?
        If so, summarize any discussion and conclusion regarding the IPR
        disclosures.

No.

    (9) How solid is the consensus of the interested community behind this
        document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

There is WG consensus that AD sponsored is the best approach for
progressing this document. No one has expressed concerns about its
progression.

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        publicly available.)

No.

    (11) Identify any ID nits the Document Shepherd has found in this
        document. (See http://www.ietf.org/tools/idnits/ and the
        Internet-Drafts Checklist). Boilerplate checks are not enough;
        this check needs to be thorough.

The document was checked using idnits 2.12.17. There is one warning
about the date which is innocuous as well as a reference to an earlier
version of a draft.  Both those will naturally be addressed by the RFC
editor.

    (12) Describe how the document meets any required formal review
        criteria, such as the MIB Doctor, media type, and URI type
        reviews.

No formal reviews other than review in the DISPATCH WG are required
for this document.

    (13) Have all references within this document been identified as
        either normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready
        for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the plan for their
        completion?

No.

    (15) Are there downward normative references references (see RFC 3967)?
        If so, list these downward references to support the Area Director
        in the Last Call procedure.

No.

    (16) Will publication of this document change the status of any
        existing RFCs? Are those RFCs listed on the title page header,
        listed in the abstract, and discussed in the introduction?
        If the RFCs are not listed in the Abstract and Introduction,
        explain why, and point to the part of the document where the
        relationship of this document to the other RFCs is discussed.
        If this information is not in the document, explain why the
        interested community considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body
        of the document. Confirm that all protocol extensions that the
        document makes are associated with the appropriate reservations
        in IANA registries. Confirm that any referenced IANA registries
        have been clearly identified. Confirm that newly created IANA
        registries include a detailed specification of the initial
        contents for the registry, that allocations procedures for future
        registrations are defined, and a reasonable name for the new
        registry has been suggested (see RFC 5226).

This document requires no IANA considerations.

    (18) List any new IANA registries that require Expert Review for
        future allocations. Provide any public guidance that the IESG
        would find useful in selecting the IANA Experts for these new
        registries.

This document defines no new IANA registries.

    (19) Describe reviews and automated checks performed by to validate
        sections of the document written in a formal language, such as
        XML code, BNF rules, MIB definitions, etc.

No reviews or automated checks were required as this document does not
use any formal language requiring such.