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

"Ben Campbell" <ben@nostrum.com> Wed, 30 September 2015 14:16 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 55DF11A8757; Wed, 30 Sep 2015 07:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 72nrcMisde1h; Wed, 30 Sep 2015 07:16:30 -0700 (PDT)
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 AEF031A7023; Wed, 30 Sep 2015 07:16:30 -0700 (PDT)
Received: from [10.0.1.23] (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 t8UEGFRs061104 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Sep 2015 09:16:16 -0500 (CDT) (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.23]
From: "Ben Campbell" <ben@nostrum.com>
To: "=?utf-8?q?Sa=C3=BAl?= Ibarra =?utf-8?q?Corretg=C3=A9?=" <saul@ag-projects.com>
Date: Wed, 30 Sep 2015 09:16:17 -0500
Message-ID: <DF830FC2-315C-408F-82B1-A3B4F573B0AF@nostrum.com>
In-Reply-To: <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> <377E0E64-1BA5-477B-95C3-66CA44E4BDD4@ag-projects.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/TZRiSVXC6fjNlWNg1q6dGNQhi1Y>
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 14:16:31 -0000

On 30 Sep 2015, at 3:25, Saúl Ibarra Corretgé wrote:

> 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.

Also true.

Ben.