[Stox] Review - draft-ietf.stox-chat-06

Matt Ryan <mryan@getjive.com> Mon, 12 May 2014 14:08 UTC

Return-Path: <mryan@getjive.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ED4691A0328 for <stox@ietfa.amsl.com>; Mon, 12 May 2014 07:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7ldsdmLe226K for <stox@ietfa.amsl.com>; Mon, 12 May 2014 07:08:22 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6AC1A029C for <stox@ietf.org>; Mon, 12 May 2014 07:08:21 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id at1so3684572iec.19 for <stox@ietf.org>; Mon, 12 May 2014 07:08:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ZSkHiTYLiE9eKtCwxyxQQ8FKP7avMpvpnAQ/thlwSYk=; b=hyBrG4DIaFkj0cDfVBHS3Ov4z70i7qsg8rS22V84KRjNZTQ3+KdPdY27gjuV5qrQH4 DrJPkRyxE1Jo5IgCjB3DMPJn2OnM6VSBvg7Grjfr7jEhYbXoZ0GXYehhtbPBvcyidlVD i4X8egDKgs/uYYYkrBmLquaGFP9txdWTxjwHw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=ZSkHiTYLiE9eKtCwxyxQQ8FKP7avMpvpnAQ/thlwSYk=; b=OOIxKttIiOKj1VSIMIBN8Z0DlykSBd+b5ZqrB2ifsZAn0I3ydgPr8d5VkudTS/LXlq Q1rAvMtVDntb2FmCQ+1lcr9IBFxGP9QWU81z83dZdqiOPgQ3WdJgLkZVhGiLW25K2rF2 QyNqPe3V4Z3clm6+r0CimnvCj1qrmWFhCCRjxMbodrg+6jiQ3eCTyGQhloL0EDgl2xiy L5PbKVFFc2dp8oT9aNqCwa/wQdoUA6uszvhepn/a6aqEvEElGawVGg1rNqz2h5LKlLgc IEazXJSjRBOMpk4+pS3kXvfMkjaW1GnI51WyD463v2B30iyB58riTV+SUbr/igiAhCAh EjxQ==
X-Gm-Message-State: ALoCoQl9dvmHYRBafATKxipyYova1GHxVkgYoniyWK9Gowa32St8lVhVsPK5aC6inNOFH+WI1FJl
X-Received: by with SMTP id ii10mr43763883igb.34.1399903695425; Mon, 12 May 2014 07:08:15 -0700 (PDT)
Received: from [] (32.251.sfcn.org. []) by mx.google.com with ESMTPSA id q2sm5630944ign.2.2014. for <stox@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 07:08:14 -0700 (PDT)
Message-ID: <5370D5CD.4010800@getjive.com>
Date: Mon, 12 May 2014 08:08:13 -0600
From: Matt Ryan <mryan@getjive.com>
Organization: Jive Communications, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: stox@ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/BUnXfnBIo1lqkHW0dzq29klQj9w
Subject: [Stox] Review - draft-ietf.stox-chat-06
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 May 2014 14:08:26 -0000

Hash: SHA512

Review of draft-ietf-stox-chat-06:

1. I suggest labeling the state diagrams in Section 4 and Section 5
describing XMPP to MSRP order of events and MSRP to XMPP order of
events, respectively, e.g. "Figure 1", "Figure 2".

2. I suggest that both the state diagram in Section 4 and the state
diagram in Section 5 should enumerate all of the SIP messages that are
sent in the establishment of the session.
  a. In the state diagram in Section 4, after event F3 but before
event F4, the SIP Server sends SIP 100 TRYING back to the
XMPP-to-Server Gateway.
  b. In the state diagram in Section 4, after event F4 but before
event F5, the SIP user sends SIP 100 TRYING back to the SIP server.
  c. In the state diagram in Section 5, after event F19 but before
event F20, the SIP Server sends SIP 100 TRYING back to the SIP User.
  d. In the state diagram in Section 5, after event F20 but before
event F21, the SIP-to-XMPP Gateway sends SIP 100 TRYING back to the
SIP Server.

2. Considering the first state diagram in Section 4, the first portion
of this diagram from event F1 through event F10 inclusive:
  a. The SIP Server should complete the establishment of the SIP
Session with the XMPP-to-SIP Gateway; the SIP-to-XMPP Gateway should
not be involved in this interaction.  This is more consistent with
[I-D.ietf-stox-core] Section 4 which indicates, "If the XMPP user
initiates the interaction, then the XMPP server would invoke its
XMPP-to-SIP gateway and thus the communication would occur over SIP",
and with Figure 1 of that same section.  Until the XMPP-to-SIP Gateway
receives confirmation that the session originated by event F3 is
established, the interaction started by the XMPP User (event F1) is
incomplete.  In other words:
    i. Event F6 should be sent from the SIP Server to the XMPP-to-SIP
Gateway instead of the SIP-to-XMPP Gateway.
    ii. Events F7 and F8 should be sent to the SIP Server from the
XMPP-to-SIP Gateway instead of the SIP-to-XMPP Gateway.

3. Considering the first state diagram in Section 4, the last portion
of this diagram from event F15 through event F18 inclusive:
  a. Because the original SIP session should be established between
the XMPP-to-SIP Gateway and the SIP Server as I mentioned above in
2.a., event F16 should be sent from the SIP Server to the XMPP-to-SIP
Gateway instead of the SIP-to-XMPP Gateway; likewise, event F17 should
be sent to the SIP Server from the XMPP-to-SIP Gateway instead of the
SIP-to-XMPP Gateway.

4. The state diagrams in Sections 4 and 5 identify events representing
SIP ACK messages and subsequent MSRP SEND, e.g. the event groupings
numbered F7 and F8, F9 and F10, F23 and F24, and F25 and F26.
Grouping these messages in this way suggests that they must be
transferred in lockstep.  For example, consider the event sequence F7,
F8, F9, and F10.  The diagram seems to suggest that the SIP Server
would receive the SIP ACK (event F7) and then wait for the MSRP SEND
(event F8) before forwarding the SIP ACK to the SIP User (event F9).
However, the SIP Server should forward the SIP ACK immediately.

5. At the end of Section 4, Examples 8 and 9 describe how the SIP User
may terminate the session.  Similar examples are given in Section 5,
Examples 17 and 18.  I suggest that a mention is made in both sections
recognizing the lack of a corresponding sequence of events from the
XMPP User, due to the fact that XMPP does not establish sessions like
SIP does, along with a reference to Section 6 where this is discussed
in the context of the "gone" XMPP chat state.  Further, I suggest
labeling that portion of Section 6 to facilitate it being referenced
from Sections 4 and 5.

6. In the discussion of the "gone" XMPP chat state:
  a. I suggest referencing [XEP-0085] which describes this state.
  b. I suggest that an XMPP-to-SIP Gateway MUST support the "gone"
XMPP chat state.  This is a change from the support requirements for
the "gone" XMPP chat state as outlined in [XEP-0085] Section 5.2 Table
2 which indicate that XMPP agents SHOULD support the "gone" state.
  c. I suggest we recommend that the XMPP-to-SIP Gateway implement a
timeout as described in [XEP-0085] Section 2 Table 1, such that if the
XMPP User has not sent a message for a previously created XMPP-to-SIP
chat session for some period of time, and no SIP BYE has been received
to terminate the session from the SIP User, that a message with the
"gone" XMPP chat state be generated from the XMPP-to-SIP Gateway to
the SIP Server to end the session.  Should the XMPP User choose to
continue the conversation at a later date, a new SIP session can be
established.  Further, we should suggest a timeout value but indicate
that such a value is implementation dependent, as is done by
[XEP-0085] Section 2 Table 1.

- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  mryan@getjive.com
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/