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

[Matt Ryan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
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  |  [e-mail]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTcNXKAAoJEPyFiw1u4O0cYO0H/0K0ar7cWL6leMPAaoZIVAIz
2arUoJf3mB8zNfUqSTjknwizzBkxL+AwXqyD/hP0d6LCf/a5qo3A0Xr7xApBrRxJ
rYmoQcZN/r9e8MdJ8h6/1ngm4EjdqnsDFuqxKs95Cyl1D9dO9Kth06zH+gSt8jYp
m4+TzXAL9iVA7VbEbCsRtuuTltHV3Chn5u37kBuVb/NK/KMB6hR6zjZYDZ8bsFuw
rKEYjRdAM5ghZ1Sr6d/AoHGoXrp3MfnTsd1F7Z7TdHMm8MfVCVy75ivkeGXNAzDd
U+pIg1hGerC9Nh3fDvWulQArwMbgtgyXAfEXRcoeAniifNenG3kuZ6OjBPtd89k=
=d2SP
-----END PGP SIGNATURE-----