Re: [Stox] Review for stox-7248bis-02

["Isomaki Markus (Nokia-TECH/Espoo)" <[e-mail]>]

Hi Peter,

I checked the revised draft (-03) and it addresses the issues I raised below. But that brought up another thing still.  It's been really long since I've been dealing with SIP Presence, but I think that the message flows in 4.2.1 may still need a couple of clarifications:

1.) 

In SIP, if the subscription is not immediately authorized (neither accepted or rejected), it is possible that a 200 OK response to the SUBSCRIBE is sent immediately followed by a NOTIFY with subscription state "pending". If the SIP User later on positively authorizes the subscription, another NOTIFY with subscription state "active" is generated. The potential "pending" state does not seem to be covered in the current diagram, but it probably should be. The question is just what happens in XMPP-to-SIP GW if it gets a NOTIFY with "pending" subscription state. To my understanding the subscription state would remain "neutral" on the XMPP side. Would that mean that the XMPP-to-SIP GW would not send anything to the XMPP side in that case, i.e. only a NOTIFY indicating subscription state as "active" would cause the message (F10) to be triggered? In that case, maybe this kind of addition would be enough:

OLD:

   In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider
   the subscription state to be "neutral" until it receives a NOTIFY
   message.  Therefore, the SIP user or SIP server at the SIP user's
   domain SHOULD immediately send a NOTIFY message containing a
   Subscription-State header [RFC6665] whose value contains the string
   "active" (see Section 5 below).

NEW:

   In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider
   the subscription state to be "neutral" until it receives a NOTIFY
   message.  Therefore, the SIP user or SIP server at the SIP user's
   domain SHOULD immediately send a NOTIFY message containing a
   Subscription-State header [RFC6665] with value "active" (see Section 5 
   below). In case the XMPP-to-SIP gateway initially receives one or more 
   NOTIFY messages with Subscription-State "pending", it MUST respond
   to them on the SIP side, but not generate any presence stanzas towards the 
   XMPP User. 

2.) 

If you look at RFCs 3856 and 3857, the typical scenario in SIP presence is: There is a SIP Presence Server handling the subscriptions to the presence event package. That is where the SUBSCRIBE (F2) in 4.2.1 goes. But typically the Presence Server would not forward the SUBSCRIBE to the SIP User in way shown in (F3). Instead, the Presence Server and SIP User would interact via the 'presence.winfo' event package (RFC 3857), to which the SIP User would be subcribed. So, when the Presence Server gets a SUBSCRIBE to SIP User's Presence, it generates a 'presence.winfo' NOTIFY the SIP User, who will that way learn about the new subscription. The SIP User would then authorize the subscription by some interaction (for instance using XCAP) with the Presence Server. In this scenario, presence updates from the SIP User would also not be sent as NOTIFYs, but as PUBLISH messages to the Presence Server, who would then generate NOTIFYs to all active subscribers. 

It is however possible that the Presence Server acts in a Proxy mode, in which case (as far as I remember), it just passes the SUBSCRIBEs and NOTIFYs through as in the current diagram in 4.2.1. If we don't want to go into the more complex diagrams, it would suffice just to say (already in terminology or in 4.2.1): "In these examples it is assumed that the SIP Server acts as a proxy for Presence event package and the actual Presence Agent resides with the SIP User."

(I'm sure Ben and Robert would know exactly what is the best way of handling these issues, so I included them in To:.)

Regards,
	Markus 


> -----Original Message-----
> From: ext Peter Saint-Andre - &yet [mailto:[e-mail]]
> Sent: Monday, July 20, 2015 7:14 PM
> To: Isomaki Markus (Nokia-TECH/Espoo); [e-mail]
> Subject: Re: [Stox] Review for stox-7248bis-02
> 
> Hi Markus, thanks for the review.
> 
> On 7/16/15 8:18 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote:
> > Hi Peter, all,
> >
> > I did a review for the 7248bis-02 draft and unless I'm missing
> > something, there seem to be still a few confusing things  about the
> > message flow diagrams and the terminology about SIP-to-XMPP and
> > XMPP-to-SIP gateways. (The reason to go for 7248bis was indeed to fix
> > the message flows so they are really the main part of it.)
> >
> > A minor issue:
> > - In the diagrams abbreviations S2X GW and X2S GW are used. While most
> readers can guess what they mean, it would be good to open them explicitly,
> perhaps in Section 3, Terminology.
> 
> Yes, we borrow those terms from RFC 7247 but I agree it would be good to
> spell them out again here.
> 
> > Bigger issues:
> > - The diagram in Section 4.2.1: It looks weird that the SIP server
> > already generates the (F7) 200 OK message,
> 
> By my reading of RFC 3856 the presence server sends the 200 OK as soon as
> the subscription request is approved. Do you think it shouldn't send the 200
> OK until later (e.g., after it sends the NOTIFY)?
> 
> > while the (F8) NOTIFY does not get any response. Shouldn't it be that the
> 200 OK is generated by the "X2S GW" and then passed forward by the SIP
> server?
> 
> I agree that the gateway needs to send a 200 OK in response to the NOTIFY,
> and that would happen right after the current step F8.
> 
> > - The text in 4.2.1 is somewhat confusing as well, as it first (understandably)
> talks about XMPP-to-SIP GW as shown in the diagram ("S2X"), but then (after
> Example 2) talks a few times about SIP-to-XMPP GW as well. I believe this is
> coming from 7248, which does have the two GWs as explicit entities in the
> diagram. But in 7248bis they are merged, and the current text makes the
> reader wonder if SIP-to-XMPP GW refers to the same entity as XMPP-to-SIP
> GW as shown, or whether there is another implicit/invisible GW function
> included.
> 
> You are right - the text needs to be scrubbed a bit more.
> 
> > - The same issue occurs in 4.3.1 in reverse. There, the diagram only has
> "S2X GW" but the text contains both SIP-to-XMPP and XMPP-to-SIP.
> 
> Correct.
> 
> > So we have gotten rid of the double gateways of 7248 in the diagrams, but
> they still somehow loom in the text and terminology. I think there are a
> couple of options to clarify this: Either always refer to the gateway as XMPP-
> to-SIP (X2S) in those sections that are about XMPP-to-SIP, and vice versa. Or,
> make the gateway direction neutral and just call it something like SIP-XMPP
> GW everywhere. Or, explain some more about the directions.
> 
> Those gateways really don't want to be removed, do they? ;-) I'll clean up the
> text and diagrams, then post a revised I-D.
> 
> > Sorry to be late about this, but I guess this is the last chance and
> > we should definitely get the gateways right this time :-O
> 
> Um, yes. :-)
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://andyet.com/