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

From: "Isomaki Markus (Nokia-TECH/Espoo)" <[email-masked]>
Date: Thu, 16 Jul 2015 14:18:40 +0000

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. 

Bigger issues:
- The diagram in Section 4.2.1: It looks weird that the SIP server already generates the (F7) 200 OK message, 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? 
- 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. 
- 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. 

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.

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

Markus

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 20 Jul 2015 10:13:30 -0600

Hi Markus, thanks for the review.

> - 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…

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 r…

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/

---

From: "Isomaki Markus (Nokia-TECH/Espoo)" <[email-masked]>
Date: Wed, 22 Jul 2015 12:30:41 +0000

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:[email-masked]]
> Sent: Monday, July 20, 2015 7:14 PM
> To: Isomaki Markus (Nokia-TECH/Espoo); [email-masked]
> Subject: Re: [Stox] Review for stox-7248bis-02
> 
> > 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.
> 
> > - 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.
> 
> > - 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/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 22 Jul 2015 23:04:29 -0700

Hi Markus, thanks for the continued review.

>     to them on the SIP side, but not generate any presence stanzas towards the

That it better. The only further change I would make is:

    In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider
    the subscription state to be "neutral" until it receives a NOTIFY
    message with a Subscription-State header [RFC6665] whose value is
    "active".

Also, I think it would make sense to change SHOULD to MUST here.

> 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…

Yes, the latter seems reasonable. However, also pointing to RFC 3857 
seems like a good idea.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Sun, 26 Jul 2015 15:22:57 -0600

I've posted -04 to address this feedback.

Peter

On 7/23/15 12:04 AM, Peter Saint-Andre - &yet wrote:
>> 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:
>>
>> 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."
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 27 Jul 2015 09:52:01 +0200

Sorry folks, I’ve been AFK for the past few days. I’ll review this version and get the writeup done.

> On 26 Jul 2015, at 23:22, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 
> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 27 Jul 2015 07:41:50 -0600

Thanks much! :)

> On Jul 27, 2015, at 1:52 AM, Saúl Ibarra Corretgé <[email-masked]> wrote:
>