Re: [Stox] Review on -presence

Peter Saint-Andre <stpeter@stpeter.im> Wed, 14 August 2013 18:28 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 B0B2521E80CE for <stox@ietfa.amsl.com>; Wed, 14 Aug 2013 11:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.729
X-Spam-Level:
X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cM8tAMzQGtQL for <stox@ietfa.amsl.com>; Wed, 14 Aug 2013 11:28:13 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5986A21F9E8B for <stox@ietf.org>; Wed, 14 Aug 2013 11:28:07 -0700 (PDT)
Received: from ergon.local (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 79668E8346; Wed, 14 Aug 2013 12:31:06 -0600 (MDT)
Message-ID: <520BCC35.2040909@stpeter.im>
Date: Wed, 14 Aug 2013 12:28:05 -0600
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: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <0CB65FBA-7262-4189-8852-5FC08A34D50D@ag-projects.com> <51F99063.30203@stpeter.im> <51FCC3C0.3040200@stpeter.im> <520BA7EC.6050604@alum.mit.edu> <520BC1A7.1030104@stpeter.im> <520BC2A0.4020703@alum.mit.edu>
In-Reply-To: <520BC2A0.4020703@alum.mit.edu>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 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: Wed, 14 Aug 2013 18:28:18 -0000

On 8/14/13 11:47 AM, Paul Kyzivat wrote:
> On 8/14/13 7:43 PM, Peter Saint-Andre wrote:
>> On 8/14/13 9:53 AM, Paul Kyzivat wrote:
>>> On 8/3/13 10:48 AM, Peter Saint-Andre wrote:
>>>
>>>> (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").
>>>
>>> An initial notify is the one directly in response to a SUBSCRIBE, even a
>>> re-SUBSCRIBE. So I don't think there should be any controversy.
>>
>> Thanks for the verification.
>>
>> So under this model, the SIP user agent would send a re-SUBSCRIBE and it
>> seems to me that the gateway then SHOULD (?) respond with a NOTIFY from
>> the SIP representation of the XMPP user/resource. There are two cases
>> for the NOTIFY:
>>
>> 1. If the XMPP user/resource is not in a "meaningful state" (cf. RFC
>> 3856 and RFC 3265), the NOTIFY SHOULD (?) be empty.
> 
> I think this is probably ok.
> 
>> 2. If the XMPP user/resource is in a meaningful state, the NOTIFY SHOULD
>> (?) contain data about the user/resource.
>>
>> Does that sound right?
> 
> Yeah.

OK, good. Here is proposed text for Section 3.3.2:

   For as long as a SIP user is online and interested in receiving
   presence notifications from the XMPP users, the user's SIP user agent
   is responsible for periodically refreshing the subscription by
   sending an updated SUBSCRIBE request with an appropriate value for
   the Expires header.  In response, the SIMPLE-XMPP gateway SHOULD send
   a SIP NOTIFY to the user agent; if the gateway has meaningful
   information about the availability state of the XMPP user then the
   NOTIFY SHOULD communicate that information (e.g., by containing a
   PIDF body [RFC3863] with the relevant data), whereas if the gateway
   does not have meaningful information about the availability state of
   the XMPP user then the NOTIFY SHOULD be empty as allowed by
   [RFC3265].

That would come before the existing discussion of handling by the
SIMPLE-XMPP gateway.

Peter

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