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

Peter Saint-Andre - &yet <> Mon, 10 August 2015 15:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E748B1B3713 for <>; Mon, 10 Aug 2015 08:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id azOoG-RLCDe3 for <>; Mon, 10 Aug 2015 08:45:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B32301A885D for <>; Mon, 10 Aug 2015 08:45:15 -0700 (PDT)
Received: by pdrg1 with SMTP id g1so72843653pdr.2 for <>; Mon, 10 Aug 2015 08:45:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=4gKhfh3qIuYxKDbX6Om5JfhUYH+KtQ8AA0lOy1WrXsE=; b=ZPhyO/bnOlsNCjVkh47gdbtte3svt8hL0BCoUxhHRvfsPv4rIRgupCFqpm29jtN8Nv C9UNiWVia6x+mroAb92hTJ04oiVIYXojFPKuVK3ZHd3Zaptl/vF0cLkVtHzSNKZHlJ+L wnqcz1s6lz1Cv/JfIsBoeGAIrOksccBhTZR6MnqZAx808DMtYICRXrbP1xcRm/hiGc7t 07TsDqmOQeIuFtz5g16B/aPzy22fZJ4MhUhIO9tiKbUfQq8OzGiaxy9zwiHJRn18WxFS YC+ViHIALI+pQl0EotreNJ4IIk0Ngpb0ojPt1ZdS9TDXIMF61dPCnI4a+JYu7uELvvs3 dkug==
X-Gm-Message-State: ALoCoQl9Eb1nqwgKLBpsjgl2RNzAoMucQXnHx0b+bxzk0kjchlbKA586B2jC/ALmHupDbaJxDMDc
X-Received: by with SMTP id ew1mr26096104pdb.110.1439221515205; Mon, 10 Aug 2015 08:45:15 -0700 (PDT)
Received: from aither.local ([2601:282:4201:ef5b:d52f:7f28:4f42:28fd]) by with ESMTPSA id kx11sm10564727pab.13.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 08:45:13 -0700 (PDT)
To: "Isomaki Markus (Nokia-TECH/Espoo)" <>, ext Ben Campbell <>
References: <> <> <> <> <> <> <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Mon, 10 Aug 2015 09:45:10 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [Stox] Review for stox-7248bis-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Aug 2015 15:45:18 -0000

On 8/6/15 4:31 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote:
> Hi,
> This is very good feedback.

Indeed, thanks to you both.

> See inline.
> Ben Campbell [] wrote:
>> 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.
> I agree with this.


>> 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.
> This is my understanding too. One way to address this would be to change "SIP User" to "SIP User (Agent) or Presence Server" in 5.2.*. Section 4 would be modified to say that presence subscriptions can be handled directly by a SIP User (Agent) or by a Presence Server acting on SIP User's behalf. In either case the message flow from the X2S GW's perspective is identical. The interaction between the Presence Server (when present) and the User Agent (winfo, PUBLISH, ...) could be verbally explained as already in Section 4, but it can be said it is out of scope of the diagrams in Section 5.2.*, as that interaction is hidden from the XMPP-SIP interworking perspective.

I like that proposal.

>> 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"
> Perhaps just change it to "SIP Proxy" where applicable.


I'll work on a revised I-D this week.


>> Ben.
> Markus
> ---
>> 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

Peter Saint-Andre