IETF Logo Mail Archive

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

Peter Saint-Andre <stpeter@stpeter.im> Sat, 05 December 2015 03:24 UTC

Return-Path: <stpeter@stpeter.im>
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 57C2A1B36A1; Fri, 4 Dec 2015 19:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 G_avJrpkdzjB; Fri, 4 Dec 2015 19:24:31 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4631B36A2; Fri, 4 Dec 2015 19:24:30 -0800 (PST)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9D401411F4; Fri, 4 Dec 2015 20:27:24 -0700 (MST)
To: Ben Campbell <ben@nostrum.com>, draft-ietf-stox-7248bis.all@ietf.org, stox@ietf.org
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <566258EC.6040900@stpeter.im>
Date: Fri, 04 Dec 2015 20:24:28 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <56036577.3000204@andyet.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/DXAsBFhTJaKCygjj7P1avw9vLcA>
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: Sat, 05 Dec 2015 03:24:32 -0000

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

v2.23.0 | Report a Bug | By Email