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

Saúl Ibarra Corretgé <saul@ag-projects.com> Mon, 27 July 2015 07:52 UTC

Return-Path: <saul@ag-projects.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0D01AD09D for <stox@ietfa.amsl.com>; Mon, 27 Jul 2015 00:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG25tAsLJU9e for <stox@ietfa.amsl.com>; Mon, 27 Jul 2015 00:52:12 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8681ACEC0 for <stox@ietf.org>; Mon, 27 Jul 2015 00:52:12 -0700 (PDT)
Received: from [192.168.99.53] (g95173.upc-g.chello.nl [80.57.95.173]) by mail.sipthor.net (Postfix) with ESMTPSA id 0078716DC6B2; Mon, 27 Jul 2015 09:52:09 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Content-Type: multipart/signed; boundary="Apple-Mail=_864A60EE-8FD9-46F8-9109-042C1F431534"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: =?utf-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= <saul@ag-projects.com>
In-Reply-To: <55B54FB1.8090009@andyet.net>
Date: Mon, 27 Jul 2015 09:52:01 +0200
Message-Id: <1DD49C5A-355B-4627-A644-416BDB2BD1B3@ag-projects.com>
References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <c2f86c086d1240f789f1c9f096b6fa58@NOKWDCFIEXCH02P.nnok.nokia.com> <55B083ED.3090801@andyet.net> <55B54FB1.8090009@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/RifhhH3cvVcI6BgcXD80oA3LO_Q>
Cc: "stox@ietf.org" <stox@ietf.org>, Ben Campbell <ben@nostrum.com>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>, "Isomaki Markus \(Nokia-TECH/Espoo\)" <markus.isomaki@nokia.com>
Subject: Re: [Stox] Review for stox-7248bis-02
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2015 07:52:14 -0000

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 <peter@andyet.net> 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
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox

--
Saúl Ibarra Corretgé
AG Projects