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

Peter Saint-Andre - &yet <peter@andyet.net> Thu, 23 July 2015 06:04 UTC

Return-Path: <peter@andyet.net>
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 7B5161A870B for <stox@ietfa.amsl.com>; Wed, 22 Jul 2015 23:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVBkcogvOenP for <stox@ietfa.amsl.com>; Wed, 22 Jul 2015 23:04:34 -0700 (PDT)
Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50EA1A70FD for <stox@ietf.org>; Wed, 22 Jul 2015 23:04:34 -0700 (PDT)
Received: by padck2 with SMTP id ck2so151190831pad.0 for <stox@ietf.org>; Wed, 22 Jul 2015 23:04:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nqykrjsgITkOa7aKCIYUOm51c04J6v6wYBUmSGTqWVA=; b=dzuuMPobAR5VQM2KSugsXqll3mGQOpZfIVSe4Sb99UQZVHqhsixn+St234fJ7DnhFS soRZShPGPEfcf565DPSb+GJriuvPNc3U/ppH88Saj/eCToxkUSsoz1NEy4Gc/HbavNuO vlZmB/j39rJQh3fDd19khqNLPqXBnSMbMwvMfRGl6m8BV9T5isZYOiFzQe3EM/81xM8H WCrB/vaXvt8k4n4GPTx5xH8saTjNnYs6eDZCwE/UGdvmu9NNAmWQvxc36ya0Z5jdmHoI Mal4CoZE5/o+NbYGLb2lVUDVitmTznDe5OhtjX4PoVGYsGES3FkOUpfP2Dc/1beAIwYv g6nA==
X-Gm-Message-State: ALoCoQm9c7WKtZdHPwAgh79ECt5Jx9gKTGK9pGWBKCEFD4y792fstckgIzyZiVPJqWxOlmVEZsXh
X-Received: by 10.66.221.226 with SMTP id qh2mr15091079pac.64.1437631474018; Wed, 22 Jul 2015 23:04:34 -0700 (PDT)
Received: from aither.local ([67.131.2.150]) by smtp.googlemail.com with ESMTPSA id lj7sm5889805pab.38.2015.07.22.23.04.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jul 2015 23:04:32 -0700 (PDT)
To: "Isomaki Markus (Nokia-TECH/Espoo)" <markus.isomaki@nokia.com>, "stox@ietf.org" <stox@ietf.org>, Ben Campbell <ben@nostrum.com>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
References: <9315d702a9534242b9c36b4b93e19a45@NOKWDCFIEXCH02P.nnok.nokia.com> <55AD1E2A.9060102@andyet.net> <c2f86c086d1240f789f1c9f096b6fa58@NOKWDCFIEXCH02P.nnok.nokia.com>
From: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <55B083ED.3090801@andyet.net>
Date: Wed, 22 Jul 2015 23:04:29 -0700
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: <c2f86c086d1240f789f1c9f096b6fa58@NOKWDCFIEXCH02P.nnok.nokia.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/NJ91pv1F4p99gpP6JAptAmuwaVk>
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, 23 Jul 2015 06:04:36 -0000

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
https://andyet.com/