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

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

Thanks much! :)

> On Jul 27, 2015, at 1:52 AM, Saúl Ibarra Corretgé <[e-mail]> wrote:
> 
> 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 <[e-mail]> wrote:
>> 
>> I've posted -04 to address this feedback.
>> 
>> Peter
>> 
>>> On 7/23/15 12:04 AM, Peter Saint-Andre - &yet wrote:
>>> Hi Markus, thanks for the continued review.
>>> 
>>>> On 7/22/15 6:30 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote:
>>>> 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.
>>> 
>>> 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.
>>> 
>>>> 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."
>>> 
>>> Yes, the latter seems reasonable. However, also pointing to RFC 3857
>>> seems like a good idea.
>>> 
>>> Peter
>> 
>> _______________________________________________
>> stox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stox
> 
> --
> Saúl Ibarra Corretgé
> AG Projects
> 
> 
>