Re: [Stox] Review on -presence

Peter Saint-Andre <stpeter@stpeter.im> Sat, 03 August 2013 08:48 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5789D11E815C for <stox@ietfa.amsl.com>; Sat, 3 Aug 2013 01:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.851
X-Spam-Level:
X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYhjCUIRgQkk for <stox@ietfa.amsl.com>; Sat, 3 Aug 2013 01:48:04 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6299911E810C for <stox@ietf.org>; Sat, 3 Aug 2013 01:48:03 -0700 (PDT)
Received: from bxb-vpn3-613.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6B552206DC; Sat, 3 Aug 2013 02:50:26 -0600 (MDT)
Message-ID: <51FCC3C0.3040200@stpeter.im>
Date: Sat, 03 Aug 2013 10:48:00 +0200
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
References: <0CB65FBA-7262-4189-8852-5FC08A34D50D@ag-projects.com> <51F99063.30203@stpeter.im>
In-Reply-To: <51F99063.30203@stpeter.im>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: "stox@ietf.org" <stox@ietf.org>
Subject: Re: [Stox] Review on -presence
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sat, 03 Aug 2013 08:48:09 -0000

On 8/1/13 12:32 AM, Peter Saint-Andre wrote:
> On 7/30/13 5:33 PM, Saúl Ibarra Corretgé wrote:
>> Hi,
>>
>> Here is my review of the -presence document:
>>
>> - Sec 3.3.2 suggests that if the subscription is maintained but we
>> have no presence state, a PIDF would be generated with a basic status
>> of closed, but what would be the tuple ID, if we don't know any
>> resource for this user anymore? 

Actually, in this scenario the gateway does know the status because the
XMPP user is still online -- it's just that the SIP user's subscription
to the XMPP user's status has expired.

>> We could also send an empty NOTIFY,
>> which would achieve the same goal.
> 
> The empty NOTIFY sounds more consistent with the spirit of SIP presence.

I've looked into this further. Here is what I find in RFC 3856 (Section
6.6.2):

   If the resource is not in a meaningful state, RFC 3265 [2] allows the
   body of the initial NOTIFY to be empty.  In the case of presence,
   that NOTIFY MAY contain a presence document.  This document would
   indicate whatever presence state the subscriber has been authorized
   to see; it is interpreted by the subscriber as the current presence
   state of the presentity.  For pending subscriptions, the state of the
   presentity SHOULD include some kind of textual note that indicates a
   pending status.

And in RFC 3265:

3.1.6.2. Confirmation of Subscription Creation/Refreshing

   Upon successfully accepting or refreshing a subscription, notifiers
   MUST send a NOTIFY message immediately to communicate the current
   resource state to the subscriber.  This NOTIFY message is sent on the
   same dialog as created by the SUBSCRIBE response.  If the resource
   has no meaningful state at the time that the SUBSCRIBE message is
   processed, this NOTIFY message MAY contain an empty or neutral body.

Everything there is about an initial NOTIFY confirming a presence
subscription. However, Section 3.3.2 of the stox-presence spec discusses
what to do if the SIP user's subscription expires:

   It is the responsibility of the SIMPLE-XMPP gateway to properly
   handle the difference between short-lived SIP presence subscriptions
   and long-lived XMPP presence subscriptions.  The gateway has two
   options when the SIP user's subscription expires...

It seems to me that there's a false assumption here, because in general
doesn't the SIP user agent initiate a refresh to maintain the
subscription (as long as it's online)? So I think there are two cases here:

(1) SIP user agent is online and generates a refresh by re-subscribing.
In this case, the empty NOTIFY might make sense (although you could
argue that it's not truly an "initial NOTIFY").

(2) SIP user agent goes offline and the subscription truly expires. In
this case, the handling we currently describe seems generally correct to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/