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

[Peter Saint-Andre <[e-mail]>]

Hi Matt, thanks for the review. Comments inline.

(As mentioned in another thread, this document also needs to be updated 
to address what I jokingly called the "FAIL" issue.)

On 5/12/14, 8:08 AM, Matt Ryan wrote:
> -----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".

Sure.

> 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.

We haven't done that in all the other specs. Are you suggesting that we 
update them all? Do you feel that this would add value? Note also that 
we don't address every possible interaction (e.g., various error flows).

> 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.

Yes, that's the FAIL issue.

> 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.

More FAIL-ure.

> 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.

I haven't found a good way in these "swim-lane" diagrams to notate that 
things don't need to be sent in lockstep. We could at least add some 
text along those lines.

> 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.

Good point, will do.

> 6. In the discussion of the "gone" XMPP chat state:
>    a. I suggest referencing [XEP-0085] which describes this state.

Where do you suggest referencing this? It's already mentioned in 
paragraph 2 of Section 6.

>    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.

That seems sensible in this context.

>    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

(or has not sent a "gone" chat state, I suppose)

> , 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.

Would you also suggest that the gateway send a gone event to the XMPP 
user, indicating that the session is ended?

> Should the XMPP User choose to
> continue the conversation at a later date, a new SIP session can be
> established.

For sure.

> 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.

Simply citing XEP-0085 might be reasonable, unless MSRP has explicit 
recommendations about timeout values (I don't see anything in RFC 4975 
but I might be missing something).

Peter