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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Jun 2014 21:32:28 -0600

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

---

From: Matt Ryan <[email-masked]>
Date: Wed, 11 Jun 2014 10:56:55 -0600

Thank you for considering my review. I have reviewed
draft-ietf-stox-chat-07 and feel that it addresses the issues I raised
in my review.

I do have a couple of comments inline below.

On 6/3/14, 9:32 PM, Peter Saint-Andre wrote:
> (As mentioned in another thread, this document also needs to be
> updated to address what I jokingly called the "FAIL" issue.)

It is simultaneously a clever acronym and too harsh a criticism. :)

>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>> 

(snip)

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

That's fair.

My argument to include them is that RFC 3261 Section 17.2.1 indicates
this is a requirement for the SIP Server in this case, so it is
essential to the session establishment flow, which makes this case
different from error flows.  However, relevant diagrams are examples
and presumably not normative, and since leaving them out eliminates
clutter from the diagram making it easier to understand, I am okay
with leaving them out.

The new diagrams look great, by the way, much easier to understand now
that the receiving-side gateway is not in the picture anymore.

- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  mryan at getjive dot com

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Jun 2014 21:36:23 -0600

> clutter from the diagram making it easier to understand, I am okay

I see the SIP 100 TRYING messages as analogous to XEP-0198 stream 
acknowledgements - we could include them (if XEP-0198 were part of RFC 
6120, if you will), but they would indeed clutter up the diagrams and 
IMHO what we're trying to do in the diagrams is help developers 
understand the overall flows.

But perhaps a note to that effect would be helpful.

> that the receiving-side gateway is not in the picture anymore.

Great, thanks for reviewing the document again!

Peter