Subject: [Stox] My review on draft-ietf-stox-7284bis

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 13 Mar 2015 17:04:03 +0100

Hi Peter and all!

So, review time!

Sec 4.2.1

Not sure if this was discussed (memory is fuzzy right now), but that diagram feels a bit odd. The SIP Server + S2X gateway entity gets SIP traffic but responds with XMPP replies. In practice, there would only be a X2S entity in that scenario, because the subscription started on the XMPP side. The X2S gateway would do the translation, and the SIP server knows nothing about XMPP.

Example 2:

Maybe add a To header? 

Example 4:

From and To tags don’t match those of the SUBSCRIBE / 200 OK, but the CallID does.

Section 4..2.3

Same as above, looks weird that the S2X gateway generated the XMPP response without ever getting the request.

Example 8:

The SUBSCRIBE needs to be in-dialog, so From and To tags need to match, and so does the Call-ID. Also the CSeq would need to be higher. Maybe put 100, thus implying that there have been a bunch of NOTIFY requests already.

Section 4.3.1

Opposite of my 2 other comments :-) Maybe I’m super confused today or we can have a quick chat / call next week to go over it?

Example 10:

Missing To header

Example 14:

Call-ID missmatch

Example 16:

The SUBSCRIBE must be in-dialog, same problem as Example 8.

Section 4.3.3

Point 2 it’s not very clear to me, upon receiving the SUBSCRIBE request with Expires 0, there is no need to send it again.

Example 18:

Maybe we need to mention that the XMPP resource can contain unicode and xs:ID is ASCII only?

Point 5: To terminate the subscription from the notifier side, a NOTIFY with Subscription-State: terminated is sent, not a SUBSCRIBE with Expires 0, that is used from the subscriber side.

Example 22:

A presence probe was a one-off presence request, right? If so, the CSeq should be 1, since this would be a new dialog. Also, missing To header.

Example 23:

Same as above.

That’s all I got! :-)

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Mar 2015 16:36:19 -0600

Hi Saúl, thanks for the review.

On 3/13/15 10:04 AM, Saúl Ibarra Corretgé wrote:
> Hi Peter and all!
>
> So, review time!
>
> Sec 4.2.1
>
> Not sure if this was discussed (memory is fuzzy right now), but that
> diagram feels a bit odd. The SIP Server + S2X gateway entity gets SIP
> traffic but responds with XMPP replies. In practice, there would only
> be a X2S entity in that scenario, because the subscription started on
> the XMPP side. The X2S gateway would do the translation, and the SIP
> server knows nothing about XMPP.

Yes, I think that makes more sense and will adjust the diagrams and 
flows accordingly.

> Maybe add a To header?

Yes.

> From and To tags don’t match those of the SUBSCRIBE / 200 OK, but the

Good catch - the From and To need to be consistent.

> Section 4..2.3
>
> Same as above, looks weird that the S2X gateway generated the XMPP
> response without ever getting the request.

Agreed.

> Example 8:
>
> The SUBSCRIBE needs to be in-dialog, so From and To tags need to
> match, and so does the Call-ID. Also the CSeq would need to be
> higher. Maybe put 100, thus implying that there have been a bunch of
> NOTIFY requests already.

WFM.

> Section 4.3.1
>
> Opposite of my 2 other comments :-) Maybe I’m super confused today or
> we can have a quick chat / call next week to go over it?

Right: here again we'd pull out the S2X gateway from the XMPP service 
deployment.

> The SUBSCRIBE must be in-dialog, same problem as Example 8.

Noted, will fix those three.

> Section 4.3.3
>
> Point 2 it’s not very clear to me, upon receiving the SUBSCRIBE
> request with Expires 0, there is no need to send it again.

This is from the XMPP server (via the gateway), not from the SIP user to 
the XMPP user, in order to cancel the subscription in the other 
direction from what's shown in Example 16. Do you feel this isn't necessary?

> Maybe we need to mention that the XMPP resource can contain unicode

This is covered in RFC 7247, but a pointer to that spec can't hurt.

> Point 5: To terminate the subscription from the notifier side, a
> NOTIFY with Subscription-State: terminated is sent, not a SUBSCRIBE
> with Expires 0, that is used from the subscriber side.

I think that's right.

> Example 22:
>
> A presence probe was a one-off presence request, right? If so, the
> CSeq should be 1, since this would be a new dialog. Also, missing To
> header.

Yes.

> Same as above.

OK.

Thanks for the feedback!

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Mar 2015 17:20:23 -0600

> On 3/13/15 10:04 AM, Saúl Ibarra Corretgé wrote:

<snip/>

> direction from what's shown in Example 16. Do you feel this isn't

I looked at this more closely and you're right.

Peter

-- 
Peter Saint-Andre
https://andyet.com/