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

"Isomaki Markus (Nokia-TECH/Espoo)" <markus.isomaki@nokia.com> Thu, 06 August 2015 10:31 UTC

Return-Path: <prvs=653a6e296=markus.isomaki@nokia.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 9FB3A1B2C3E for <stox@ietfa.amsl.com>; Thu, 6 Aug 2015 03:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 9wwXhOBRGhMa for <stox@ietfa.amsl.com>; Thu, 6 Aug 2015 03:31:33 -0700 (PDT)
Received: from nok-msg-2.service.capgemini.fi (nok-msg-2.service.capgemini.fi [145.247.12.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666131B2C3D for <stox@ietf.org>; Thu, 6 Aug 2015 03:31:32 -0700 (PDT)
Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-2.service.capgemini.fi with ESMTP; 06 Aug 2015 13:31:30 +0300
Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH01P.nnok.nokia.com (10.50.38.49) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 6 Aug 2015 13:31:29 +0300
Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.1044.021; Thu, 6 Aug 2015 13:31:29 +0300
From: "Isomaki Markus (Nokia-TECH/Espoo)" <markus.isomaki@nokia.com>
To: ext Ben Campbell <ben@nostrum.com>, Peter Saint-Andre - &yet <peter@andyet.net>
Thread-Topic: [Stox] Review for stox-7248bis-02
Thread-Index: AdC/0cUiLOk2SX8aQIy0VVTyZI/MLQDHBn4AAGBCokAAIVglgAC284uAAY7taIAAiU2PEA==
Date: Thu, 6 Aug 2015 10:31:28 +0000
Message-ID: <09f0827aae654a01947fd2c5f234b80c@NOKWDCFIEXCH02P.nnok.nokia.com>
References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <c2f86c086d1240f789f1c9f096b6fa58@NOKWDCFIEXCH02P.nnok.nokia.com> <55B083ED.3090801@andyet.net> <55B54FB1.8090009@andyet.net> <702EC8DF-B6E6-4298-B7C0-44404BB9B849@nostrum.com>
In-Reply-To: <702EC8DF-B6E6-4298-B7C0-44404BB9B849@nostrum.com>
Accept-Language: en-US, fi-FI
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.50.32.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/R1e24JDkjfMSqZp03vwtXRayqpg>
Cc: "stox@ietf.org" <stox@ietf.org>, "rjsparks@nostrum.com" <rjsparks@nostrum.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: Thu, 06 Aug 2015 10:31:35 -0000

Hi,

This is very good feedback. See inline.

Ben Campbell [mailto:ben@nostrum.com] 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.

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

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