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

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

On 6/11/14, 10:56 AM, Matt Ryan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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:
>> 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.)
>
> It is simultaneously a clever acronym and too harsh a criticism. :)
>
>>
>> On 5/12/14, 8:08 AM, Matt Ryan wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>>
>>> Review of draft-ietf-stox-chat-06:
>>>
>
> (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.

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.

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

Great, thanks for reviewing the document again!

Peter