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/
- [Stox] Review on -presence Saúl Ibarra Corretgé
- Re: [Stox] Review on -presence Peter Saint-Andre
- Re: [Stox] Review on -presence Saúl Ibarra Corretgé
- Re: [Stox] Review on -presence Peter Saint-Andre
- Re: [Stox] Review on -presence Peter Saint-Andre
- Re: [Stox] Review on -presence Saúl Ibarra Corretgé
- Re: [Stox] Review on -presence Saúl Ibarra Corretgé
- Re: [Stox] Review on -presence Peter Saint-Andre
- Re: [Stox] Review on -presence Peter Saint-Andre
- Re: [Stox] Review on -presence Peter Saint-Andre
- Re: [Stox] Review on -presence Paul Kyzivat
- Re: [Stox] Review on -presence Peter Saint-Andre
- Re: [Stox] Review on -presence Paul Kyzivat
- Re: [Stox] Review on -presence Paul Kyzivat
- Re: [Stox] Review on -presence Peter Saint-Andre
- Re: [Stox] Review on -presence Saúl Ibarra Corretgé
- Re: [Stox] Review on -presence Peter Saint-Andre