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

Saúl Ibarra Corretgé <saul@ag-projects.com> Wed, 30 September 2015 08:25 UTC

Return-Path: <saul@ag-projects.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 8E4C31A1B27; Wed, 30 Sep 2015 01:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.289
X-Spam-Level:
X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 dOJa8-a1XUHe; Wed, 30 Sep 2015 01:25:27 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0671A1B2A; Wed, 30 Sep 2015 01:25:26 -0700 (PDT)
Received: from [192.168.0.48] (92-111-25-226.static.chello.nl [92.111.25.226]) by mail.sipthor.net (Postfix) with ESMTPSA id E4AB916DC6C5; Wed, 30 Sep 2015 10:25:24 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9766DC53-17E7-4B00-8BC4-405DC3F3D551"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: =?utf-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= <saul@ag-projects.com>
In-Reply-To: <BD08A7FA-9722-4444-B5B7-3640D4AC2D56@nostrum.com>
Date: Wed, 30 Sep 2015 10:25:19 +0200
Message-Id: <377E0E64-1BA5-477B-95C3-66CA44E4BDD4@ag-projects.com>
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net> <1794408B-8BE1-4F24-8A26-F40B1A0804EF@nostrum.com> <5609F9D5.2080306@andyet.net> <BD08A7FA-9722-4444-B5B7-3640D4AC2D56@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/NXZSoZFimlgr4uQOG2QHDSdPkns>
Cc: stox@ietf.org, draft-ietf-stox-7248bis.all@ietf.org, Peter Saint-Andre - &yet <peter@andyet.net>
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: Wed, 30 Sep 2015 08:25:28 -0000

Sorry for coming late folks, looks like you got almost everything sorted out :-)

>> 
>>>>> -2nd paragraph after example 11:
>>>>> This also needs a NOTIFY. You mention one in the following paragraph for
>>>>> the declined case, but you need one in either case.
>>>> 
>>>> Yes. The XMPP server will generate a presence notification in this
>>>> case, so that's the primary NOTIFY of interest here, I think.
>>> 
>>> I think it's still worth mentioning that it happens. And that brings up
>>> another question: A RFC 6665 notifier is required to send an "immediate"
>>> NOTIFY. Do you think the presence stanza will reliably arrive at the
>>> gateway in time to be considered "immediate"? If there's any likelihood
>>> of delay, the gateway may need to send a "pending" NOTIFY.
>> 
>> Not sure. I'll think about that some more.
> 
> It might be reasonable to punt this to the implementation to decide, with some guidance about what to do if you can't immediately send a "real" NOTIFY. And on reflection, this gets tangled up with authorization--the "pending" NOTIFY is more to say the authorization has not yet been determined. If the subscriber is known to be authorized, then rather than a "pending" NOTIFY it might just send a normal NOTIFY with some default presence state, then send the real presence when it gets it. (The subscriber's user experience might be a to initially see the entity as "closed" then quickly transition to "open”.

You could still send an empty NOTIFY with subscription state “active”, to indicate that the it has been allowed by the policy, but there is no presence state to show at this moment. How to interpret that is of course implementation specific.


--
Saúl Ibarra Corretgé
AG Projects