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

[Peter Saint-Andre <[e-mail]>]

Hi Ben, thanks for your comments. My apologies for the delayed reply.

On 6/9/16 4:37 PM, Ben Campbell wrote:
> Hi Peter,
>
>
> I have a couple of questions about the implications of the new "presence
> authorization" concept, and a couple of editorial nits. Otherwise, I
> think this is ready for IETF last call. It might make sense to go ahead
> with the last call, and address these with any last call comments--but
> I'd like to have an initial round of conversation about the presence
> authorization first.
>
> - in 5.2.3, whose "authorization" is canceled?

The use cases in §5.2 originate on the XMPP side and the use cases in 
§5.3 originate on the SIP side, so §5.2.3 describes what happens when 
the XMPP user no longer wishes to receive presence notifications from 
the SIP contact.

> If the SIP contact has a
> reciprocal subscription back to the xmpp contact’s presence, is that
> impacted by this unsubscribe action?

It shouldn't be, because we're not assuming that authorization to 
receive presence notifications needs to be bidirectional. So this flow 
results in the XMPP user (here, Juliet) no longer receiving presence 
notifications from the SIP contact (here, Romeo); however, Romeo can 
still happily receive presence notifications from Juliet.

> Or is the SIP user expected to
> remove the authorization for the xmpp user to see her presence info?

Romeo would also need to inform Juliet that he no longer wishes to 
receive presence notifications from her, i.e., he would need to complete 
the flow in §5.3.3.

I can see that the phrasing in §5.2.3 and §5.3.3 is confusing, i.e.:

   5.2.3

     cancelling an XMPP user's presence authorization to a SIP contact

   5.3.3

     cancel the presence authorization

That wording doesn't make the directionality clear. I'll rephrase these 
sentences to clarify matters.

> - in 5.3.1, I _think_ the flow creates both an authorization and a
> notification dialog.

To prevent confusion, we're now using the term "notification dialog" for 
SIP->XMPP and "presence authorization" for XMPP->SIP. When you say 
"authorization" here, are you referring to a presence authorization from 
the XMPP user to the SIP user? If so, how would the notification dialog 
from the SIP user to the XMPP trigger that? If not, then let's make sure 
we're on the same page about what's happening here.

(Yes, I know, presence state machines are horribly complicated!)

> If the SIP user unsubscribes, and resubscribes
> (that is, tears down the notification dialog and creates a new one),

That is, completes the flow in §5.3.1, then completes the flow in 
§5.3.3, then initiates the flow in §5.3.1 again - correct?

> is
> there any difference in the flow due to the fact the XMPP server has
> authorization state for the SIP user? (Would F29 and F30 still happen?)

You are correct - the XMPP server would still consider the SIP user to 
be authorized, and so it would not prompt the XMPP client for approval 
of an authorization request. See §3.1.3, point #2, of RFC 6121.

> Nits:
>
> - 1, 5th paragraph: s/specfic/specific/
>
> - 5.2.2, first paragraph, last sentence: I suspect "whenever" should be
> "... sufficiently in advance of when..."

Good catch.

After we settle on a common understanding of the foregoing points, I'll 
submit -09 so that we have clean text ready for IETF Last Call.

Thanks again,

Peter