Re: [Stox] Review on -presence

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 14 August 2013 17:47 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 C956821E80C7 for <stox@ietfa.amsl.com>; Wed, 14 Aug 2013 10:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.093
X-Spam-Level:
X-Spam-Status: No, score=0.093 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_MLH_Stock1=0.87]
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 uBcZfJhdfOip for <stox@ietfa.amsl.com>; Wed, 14 Aug 2013 10:47:15 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 98E0421E80B0 for <stox@ietf.org>; Wed, 14 Aug 2013 10:47:14 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id Cd5Z1m0081ZXKqc57hnEiy; Wed, 14 Aug 2013 17:47:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id ChnD1m01A3ZTu2S3hhnDpo; Wed, 14 Aug 2013 17:47:14 +0000
Message-ID: <520BC2A0.4020703@alum.mit.edu>
Date: Wed, 14 Aug 2013 19:47:12 +0200
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
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>
In-Reply-To: <520BC1A7.1030104@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376502434; bh=r7GcCwCi9eRyK5eSVQY4uTIyWVDyKoYQvFf/cRyKS+k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bjmZvomXX5ZUMaXaTT2ScKFWeslPv5v9+NjYC8o+ZLAHTDbRjV2Iaa4aeOq1ezR9X WJ6CwaMLt5WIB+kJyPg0WbvuNCOMZnxxmdP3fHbpCPjZDwisFlvOp0wIhaN1vOMHwC wiXfBXqoZmw6LTyQFhv6xV8nfne7FV0Et3FG70cz+KhcaNvv2zWkXDDE8nASKnMYNU dKWvOJdQFj5MHh28shwEAOG5g/RCNp+KwWo1wmQNFCUeaP3Vmqqdew/iP/rTzWycij qzxdAPeaAPlZedHp4sczQBbrNeFx/tHkMR1v9gdRcMxrtFLdVBZ92uCs3w9+qYIAFG kA9zJiUBOdzoA==
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 17:47:20 -0000

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.

	Thanks,
	Paul