Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05

"Ben Campbell" <ben@nostrum.com> Mon, 07 December 2015 00:48 UTC

Return-Path: <ben@nostrum.com>
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 413341A9006; Sun, 6 Dec 2015 16:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 J-n9pGA1w4b8; Sun, 6 Dec 2015 16:48:43 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D4F151A9005; Sun, 6 Dec 2015 16:48:43 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB70mfpm092992 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 6 Dec 2015 18:48:43 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: "Ben Campbell" <ben@nostrum.com>
To: "Peter Saint-Andre" <stpeter@stpeter.im>
Date: Sun, 06 Dec 2015 18:48:41 -0600
Message-ID: <3FA757FB-FE65-4BC8-AAB1-C5B0A153B996@nostrum.com>
In-Reply-To: <566258EC.6040900@stpeter.im>
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net> <566258EC.6040900@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/6PJRAOJ8fOa5Ua_wldpirR1Wsc0>
Cc: stox@ietf.org, draft-ietf-stox-7248bis.all@ietf.org
Subject: Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05
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: Mon, 07 Dec 2015 00:48:45 -0000

I read this as removing the 2119 keywords for descriptions 6665 stuff, 
correct? If so, that's a fine change, but it doesn't seem to address the 
context of refreshing the subscription on behalf of an XMPP subscriber. 
Maybe the wrong comment was quoted?

Thanks!

Ben.

On 4 Dec 2015, at 21:24, Peter Saint-Andre wrote:

> On 9/23/15 8:52 PM, Peter Saint-Andre - &yet wrote:
>
>>> "... whenever an XMPP-to-SIP gateway seeks to refresh an XMPP 
>>> user’s
>>> long-lived subscription to a SIP user’s presence, it MUST first 
>>> send an
>>> XMPP <presence/> stanza of type "probe" ..."
>>>
>>> I would have liked to see that discussed in the relevant procedures
>>> section(s).
>>
>> OK, I'll see if we can include it earlier in the document.
>
> How is this?
>
> OLD
>
>  For as long as a SIP user is online and interested in receiving
>  presence notifications from the XMPP contact, 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 presence-aware SIP-to-XMPP
>  gateway MUST send a SIP NOTIFY to the user agent (per [RFC6665]); if
>  the SIP-to-XMPP gateway has meaningful information about the
>  availability state of the XMPP user (e.g., obtained from the core
>  presence session in the XMPP server) then the NOTIFY MUST communicate
>  that information (e.g., by including a PIDF body [RFC3863] with the
>  relevant data), whereas if the SIP-to-XMPP gateway does not have
>  meaningful information about the availability state of the XMPP user
>  then the NOTIFY MUST be empty as allowed by [RFC6665].
>
> NEW
>
>  For as long as a SIP user is online and interested in receiving
>  presence notifications from the XMPP contact, 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 presence-aware SIP-to-XMPP
>  gateway sends a SIP NOTIFY to the user agent (per [RFC6665]); if the
>  SIP-to-XMPP gateway has meaningful information about the availability
>  state of the XMPP user (e.g., obtained from the core presence session
>  in the XMPP server or learned by sending a presence probe as
>  described under Section 7) then the NOTIFY communicates that
>  information (e.g., by including a PIDF body [RFC3863] with the
>  relevant data), whereas if the SIP-to-XMPP gateway does not have
>  meaningful information about the availability state of the XMPP user
>  then the NOTIFY MUST be empty as allowed by [RFC6665].
>
> Do you think we need more detail?
>
> Peter