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

["Ben Campbell" <[e-mail]>]

Hi,

A couple of thoughts on this:

The additional text in 04 about waiting for a NOTIFY with an active 
state helps. But it might be worth adding an initial "pending" notify 
exchange to (at least) 5.2.1.

On the architectural question: I think that the "more complex" 
architecture is also the more relevant one. But, you could ignore this 
completely by just changing "SIP User" to "Presence Server" in 5.2.* . 
Unless I'm forgetting something, the architectural questions should not 
change the interactions to the left of the presence server. Then the 
architectural note could simply state that this may be a separate 
presence server, or it may be co-located with the SIP UA, but the 
relevant XMPP to SIP flow is the same either way.

Also,the idea of a SIP "server" is architecturally vague--there's no 
such animal defined in the SIP standards. I suggest calling it a SIP 
Proxy in 5.2.*. In 5.3.*, it could either be a "SIP Proxy + S2X GW", or 
just a "S2X GW"

Ben.



On 26 Jul 2015, at 16:22, Peter Saint-Andre - &yet 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
>>