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

[Saúl Ibarra Corretgé <[e-mail]>]

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