Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt

Peter Saint-Andre <> Tue, 30 August 2016 03:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C929E12D0E1 for <>; Mon, 29 Aug 2016 20:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQiOhPJW8LnH for <>; Mon, 29 Aug 2016 20:43:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9EF88127A90 for <>; Mon, 29 Aug 2016 20:43:21 -0700 (PDT)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id DC200F075D; Mon, 29 Aug 2016 21:46:00 -0600 (MDT)
To: Ben Campbell <>
References: <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Mon, 29 Aug 2016 21:43:19 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Aug 2016 03:43:23 -0000

On 8/29/16 4:56 PM, Ben Campbell wrote:
> Hi Peter,
> I'm going to try to be more responsive on this, and break the apology
> loop :-)


> I agree we are zeroing in on things here. I think, with this version, I
> can better clarify my remaining concern. (I think it's the only thing
> left.)
> 5.2.3 talks about canceling a presence authorization. But from Romeo's
> perspective, it does do that; it only cancels the notification session.
> SIP has no way for Juliet to explicitly say "I want my permission to see
> Romeo's presence info to go away". If Juliet never wants to be notified
> again, she simply doesn't subscribe again. Maybe Romeo's system has some
> policy that ages out such authorizations over time, but that's not
> really relevant to this draft. (It's also possible for Romeo to
> unilaterally cancel that authorization, but that's probably more detail
> than is needed here.) In simpler terms, Romeo's presence server asks him
> if he wants to let Juliet subscribe the first time she tries. For future
> subscriptions, it won't ask. If Romeo later decides he prefers less
> star-crossed relationships, he can withdraw that permission. Other than
> than the initial subscription request, Juliet has no say in the matter.
> This is also true for _requesting_ authorization. For example, the only
> thing that makes 5.2.1 into a request for authorization (on the SIP
> side) is the fact that Juliet is subscribing for the first time. (I'm
> not saying 5.2.1 needs to change; I just mention this for background).
> Likewise in 5.3.3, Romeo is not asking to be deauthorized. He's just
> asking to end the notification session. Now that may not matter, he just
> gets re-authorized next time hie sends a SUBSCRIBE request. But he might
> be surprised to find that Juliet thought he had requested to be
> deauthorized. (Not to mention, that Juliet might feel, well,
> "unfriended" :-)  )
> This all goes counter to the statement in the 2nd to last paragraph of
> 5.1 that SIP presence authorizations are managed with SUBSCRIBE
> requests. The real situation is that the watcher (Juliet) doesn't manage
> these authorizations at all--they are unilaterally managed by the
> presentity (Romeo). A SUBSCRIBE request from Juliet may cause Romeo to
> be notified that he needs to make an authorization decision if he has
> not previously given permission.

Your description really clarified things for me, so thanks!

> So, how to fix this? I'm not sure I have the answer. But one approach
> might be to extend 5.1 to be more clear about the difference in
> authorization models, then have sections 5.2.x and 5.3.x talk more about
> notification sessions than authorization, but mention authorization
> state changes in the commentary about the message detail as needed.

Yes, that seems sensible. I will work on an updated I-D along those 
lines very soon.