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

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 2 Sep 2016 16:23:53 -0600

On 8/29/16 9:43 PM, Peter Saint-Andre wrote:
> 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 :-)
>
> Likewise!
>
>> 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!

Looking at the I-D more closely, I think that the protocol flow diagram 
in §5.2.3 is fine, but that some clarifying text would help. I propose 
the following change to the first paragraph of that section.

OLD

    The following diagram illustrates the protocol flow by which an XMPP
    user cancels her outbound presence authorization to a SIP contact
    (i.e., indicates that she no longer wishes to be authorized to see
    the SIP contact's presence), as further explained in the text and
    examples after the diagram.

NEW

    The following diagram illustrates the protocol flow by which an XMPP
    user cancels her outbound presence authorization to a SIP contact
    (i.e., indicates that she no longer wishes to be authorized to see
    the SIP contact's presence).  As can be seen, because SIMPLE does not
    have a construct that enables a contact to cancel her presence
    authorization, this flow instead results in cancellation of the
    contact's notification dialog (with the implication on the XMPP side
    that the contact will not request a subsequent notification dialog).
    Additional details are explained in the text and examples after the
    diagram.

Similarly in §5.3.3...

OLD

    At any time, the SIP user can cancel his outbound presence
    authorization to the XMPP contact (i.e., indicate that he no longer
    wishes to be authorized to receive presence notifications from the
    XMPP contact) by sending a SUBSCRIBE message whose Expires header is
    set to a value of zero ("0"):

NEW

    SIP does not directly have a construct for cancelling an outbound
    presence authorization.  Instead, the SIP user would terminate his
    outbound notification dialog by sending a SUBSCRIBE message whose
    Expires header is set to a value of zero ("0"), and then never renew
    it:

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

Given the changes proposed above, do you think we also need to modify 
§5.1? We could add a sentence or clause there, too, but I'm not sure 
it's really necessary.

Thanks!

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 2 Sep 2016 20:19:35 -0600

> §5.1? We could add a sentence or clause there, too, but I'm not sure

Actually I think the following changes would help to clarify matters.

OLD

    As described in [RFC3856], SIP notification dialogs and presence
    authorizations are managed through the use of SIP SUBSCRIBE events
    sent from a SIP User Agent or Presence Server to an intended
    recipient who is most generally referenced by a Presence URI of the
    form <pres:user@domain> but who might be referenced by a SIP or SIPS
    (Session Initiation Protocol Secure) URI of the form
    <sip:user@domain> or <sips:user@domain>.  In practice, 'pres' URIs
    are rarely used, which is why the examples in this document use 'sip'
    URIs.

NEW

    As described in [RFC3856], SIP presence authorizations are
    effectively implicit: when a SIP user receives an initial SIP
    SUBSCRIBE event from a contact, the recipient's SIP User Agent will
    prompt the user to approve or deny the request.  This decision is
    recorded in the User Agent or in a Presence Server, so that in the
    future any notification dialogs from the contact are automatically
    approved.  (Note that addresses for SIP users and contacts are most
    generally referenced by a Presence URI of the form <pres:user@domain>
    but might be referenced by a SIP or SIPS (Session Initiation Protocol
    Secure) URI of the form <sip:user@domain> or <sips:user@domain>;
    because in practice 'pres' URIs are rarely used, the examples in this
    document use 'sip' URIs.)

I'm going to submit a revised I-D with these changes and we'll take it 
from there. :-)

Peter

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 07 Sep 2016 15:39:44 -0500

Hi Peter,

I think version 10 is very close to ready. I have two minor comments; 
for the most part these don't change the interaction. I've actually 
suggested text this time :-)

-4, list item 1:

OLD:
   Instead of forwarding a SUBSCRIBE message to the SIP user, the 
Presence Server
   would act on the basis of a policy set by the SIP User Agent using 
the ’
   presence.winfo’ event package, for which the SIP user would receive 
events.
NEW:
   Instead of forwarding a SUBSCRIBE message to the SIP user, the 
Presence Server
   would inform the user of subscription activity using the 
’presence.winfo’
   event package.

-5.1, paragraph after bullet list:
OLD:
    As described in [RFC3856], SIP presence authorizations are
    effectively implicit: when a SIP user receives an initial SIP
    SUBSCRIBE event from a contact, the recipient’s SIP User Agent 
will
    prompt the user to approve or deny the request.
NEW:
    As described in [RFC3856], in SIP the subscriber does not explicitly
    request the creation or removal of presence authorizations. Rather,
    the authorizations are triggered by subscription activity. When a
    SIP user receives an initial SIP SUBSCRIBE event from a contact,
    the recipient’s SIP User Agent or presence server notifies the
    user to make an authorization policy decision.

Thanks!

Ben.

On 2 Sep 2016, at 21:19, Peter Saint-Andre wrote:

> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 7 Sep 2016 14:45:11 -0600

On 9/7/16 2:39 PM, Ben Campbell wrote:
>   would act on the basis of a policy set by the SIP User Agent using the ’
>   would inform the user of subscription activity using the ’presence.winfo’
>   event package.
>
>    SUBSCRIBE event from a contact, the recipient’s SIP User Agent will

Definite improvements. Would you like me to submit a revised I-D? Easy 
enough. :-)

Peter

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 07 Sep 2016 15:47:53 -0500

> Definite improvements. Would you like me to submit a revised I-D? Easy 

If you agree to the changes, please do. Am I correct to assume that 
there are no more outstanding issues? If so, I think we can take that 
version to IETF last call.

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 7 Sep 2016 14:50:33 -0600

On 9/7/16 2:47 PM, Ben Campbell wrote:
> If you agree to the changes, please do.

Submitting now.

> Am I correct to assume that
> there are no more outstanding issues?

That's how I see it.

> If so, I think we can take that

Great! The document shepherd might need to update his writeup.

Peter

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 07 Sep 2016 16:00:04 -0500

(+ shepherd)

> Great! The document shepherd might need to update his writeup.

On a quick scan, I think the shepherd writeup is okay, but we should let 
Saul verify that (and also confirm that he agrees this is ready to go to 
last call.)

Saul, do you agree on on both (or either)?

Thanks!

Ben.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 9 Sep 2016 10:55:46 +0100

> On 07 Sep 2016, at 22:00, Ben Campbell <[email-masked]> wrote:
> 
> (+ shepherd)
> 
> On a quick scan, I think the shepherd writeup is okay, but we should let Saul verify that (and also confirm that he agrees this is ready to go to last call.)
> 

Hi,

I just came across this, sorry! I’ll take a look on Monday since I’ll be ask the new couple of days, sorry about that!

Cheers!

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 12 Sep 2016 10:42:44 +0100

Review time!

Page 10: " As described in Section 6
, the XMPP-to-SIP gateway also generates a
   presence notification addressed to the XMPP user:
“

Should we say “if the NOTIFY contains a body” or is it obvious enough? It’s possible the SIP user is offline, but the XMPP is user is already authorised, so the NOTIFY will contain Subscription-State: active, but no body.

Page 11: "As can be seen, because SIMPLE does not
   have a construct that enables a contact to cancel her presence
   authorization,”

There is: remove the user from the corresponding XCAP rule.  Next time presence is requested, it will be denied.  (the SUBSCRIBE dialog still needs to be terminated though).

Page 14: example 10

Since the Content-Length is 0, maybe omit Content-Type?

Page 15: flow example

Add a NOTIFY with state as “pending” before sending the subscribe stanza to the XMPP server?

Page 19: [RFC6121] defines how XMPP

Missing RFC link?

Page 27: " As described in [RFC3856
], this cancels any notification dialog but
   causes a NOTIFY to be sent to the subscriber, just as a presence
   probe does (the transformation rules for presence notifications have
   been previously described in
Section 6.2 of this document).”

A probe would be implemented as a new SUBSCRIBE dialog with expires 0, which does’t cancel all other dialogs.  So while the mechanism is the same, using a *new* SUBSCRIBE request with Expires: 0 would just be a probe, not a cancellation.

General note: the examples with "<show xmlns='jabber:client'>away</show>” lack the XML namespace declaration for “jabber”.

These are all quite minor things, I think we are good to go for WGLC after small fixes for those.

Cheers!

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 12 Sep 2016 10:26:32 -0400

Hi,

A few comments inline.

Thanks!

Ben.

On 12 Sep 2016, at 5:42, Saúl Ibarra Corretgé wrote:

> Should we say “if the NOTIFY contains a body” or is it obvious 
> enough? It’s possible the SIP user is offline, but the XMPP is user 
> is already authorised, so the NOTIFY will contain Subscription-State: 
> active, but no body.

It's probably worth adding an example of how the the gateway might 
interpret an empty body. I assume that if this is the first NOTIFY in 
the dialog (notification session), the gateway would interpret that as 
unknown or possibly "closed". If previous NOTIFYs have in the same 
notification session, it should probably mean "no change".

> There is: remove the user from the corresponding XCAP rule.  Next time 
> presence is requested, it will be denied.  (the SUBSCRIBE dialog still 
> needs to be terminated though).

The text is about the subscriber, not the presentity. So if Juliet 
subscribes to Romeo's presence, Romeo can change the authorization rule 
(via xcap or otherwise). But _Juliet_ cannot.

I suppose "her authorization" can be a bit ambiguous. (If Romeo 
authorizes Juliet, whose authorization is it?)

> stanza to the XMPP server?

That's a good question for the xmpp side. Is there an equivalent to the 
pending state? It's not really illegal to go directly to active. It 
might look unusual from the SIP side--but it's no different than 
subscribing to something you are already authorized to see.

> A probe would be implemented as a new SUBSCRIBE dialog with expires 0, 
> which does’t cancel all other dialogs.  So while the mechanism is 
> the same, using a *new* SUBSCRIBE request with Expires: 0 would just 
> be a probe, not a cancellation.
>
> General note: the examples with "<show 
> xmlns='jabber:client'>away</show>” lack the XML namespace 
> declaration for “jabber”.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2016 20:36:55 -0600

Thanks for the feedback. Comments inline.

On 9/12/16 8:26 AM, Ben Campbell wrote:
>     is already authorised, so the NOTIFY will contain
>     Subscription-State: active, but no body.
>

Good idea, will do.

>     There is: remove the user from the corresponding XCAP rule. Next
>     time presence is requested, it will be denied. (the SUBSCRIBE dialog
>     still needs to be terminated though).
>
> (via xcap or otherwise). But /Juliet/ cannot.
>

I was tempted to add "outbound" or "inbound" in all cases to make this 
crystal clear...

>     Since the Content-Length is 0, maybe omit Content-Type?

Good catch.

> pending state?

There are indeed pending states in XMPP:

https://tools.ietf.org/html/rfc6121#appendix-A.1

However, I excluded them in these mappings to avoid too much complexity.

> It's not really illegal to go directly to active. It

We can make mention of them here but I'd prefer not to describe them in 
great detail. :-)

>     Page 19: [RFC6121] defines how XMPP

Not really, but the wording could be improved.

>     A probe would be implemented as a new SUBSCRIBE dialog with expires
>     0, which does’t cancel all other dialogs. So while the mechanism is

I will look into this. What you say sounds plausible but I'd like to 
double-check it against my reading of RFC 3856.

>     declaration for “jabber”.

Another good catch.

>     after small fixes for those.

Great, I'll work on a slightly revised I-D this week.

Thanks!

Peter

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 13 Sep 2016 11:01:06 +0100

> The text is about the subscriber, not the presentity. So if Juliet subscribes to Romeo's presence, Romeo can change the authorization rule (via xcap or otherwise). But Juliet cannot.
> 
> I suppose "her authorization" can be a bit ambiguous. (If Romeo authorizes Juliet, whose authorization is it?)
> 
> 

Ah, gotha. Maybe some clarification would help indeed.

Cheers,

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 13 Sep 2016 09:39:10 -0400

Oops, I missed a comment:

> after small fixes for those.

The draft is currently in the AD Evaluation state, meaning that the WGLC 
has already completed and publication has been requested. Did you mean 
to say that we need to repeat the WGLC, or did you mean IETF last call?

There's probably enough changes that a repeat WGLC would be reasonable. 
OTOH, I am skeptical that the working group still has enough active 
participants for a repeated WGLC to add value.

Thanks!

Ben.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 13 Sep 2016 16:35:22 +0100

> On 13 Sep 2016, at 14:39, Ben Campbell <[email-masked]> wrote:
> 
> The draft is currently in the AD Evaluation state, meaning that the WGLC has already completed and publication has been requested. Did you mean to say that we need to repeat the WGLC, or did you mean IETF last call?
> 
> There's probably enough changes that a repeat WGLC would be reasonable. OTOH, I am skeptical that the working group still has enough active participants for a repeated WGLC to add value.
> 

Sorry, wrong terminology :-) IETF last call.  These are not big structural changes, I don’t think we need another WGLC.

Cheers!

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Sep 2016 09:24:04 -0600

A few additional notes...

>> notification session, it should probably mean "no change".

    As described in Section 6, if this first NOTIFY in the notification
    session contains a body then the XMPP-to-SIP gateway also generates a
    presence notification addressed to the XMPP user (if the NOTIFY does
    not contain a body then the gateway would interpret it as unknown or

> I was tempted to add "outbound" or "inbound" in all cases to make this

Changed to "cancel her outbound presence authorization"

<snip/>

> double-check it against my reading of RFC 3856.

Yes, that looks right. I would change things as follows (note the new 
Call-ID, too):

    A SIP-to-XMPP gateway would transform the presence probe into its SIP
    equivalent, which is a SUBSCRIBE request with an Expires header value
    of zero in a new dialog:

    Example 23: SIP Transformation of XMPP Presence Probe

    |  SUBSCRIBE sip:[email-masked] SIP/2.0
    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
    |  From: <sip:[email-masked]>;tag=j89d
    |  Call-ID: 2398B737-566F-4CBB-A21A-1F8EEF7AF423
    |  Event: presence
    |  Max-Forwards: 70
    |  CSeq: 1 SUBSCRIBE
    |  Contact: <sip:[email-masked]>;gr=yn0cl4bnw0yr3vym
    |  Accept: application/pidf+xml
    |  Expires: 0
    |  Content-Length: 0

    As described in [RFC3856], this causes a NOTIFY to be sent to the
    subscriber, just as a presence probe does (the transformation rules
    for presence notifications have been previously described in
    Section 6.2 of this document).

>>     declaration for “jabber”.

Actually, 'jabber' is not a prefix here and the namespace name is indeed 
"jabber:client" - this was defined in the very early days of XML 
namespaces and we Jabberites didn't fully understand what a namespace 
name was supposed to look like. :(

If that all looks good, I will publish a revised I-D soon.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Sep 2016 09:25:28 -0600

> If that all looks good, I will publish a revised I-D soon.

A diff is here:

https://github.com/stpeter/sip-xmpp/commit/a3ded08cbf1cc527f3f648813b3ecc46d5039094#diff-7f5e67ec097d24a4490853a1770f411b

Peter

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 14 Sep 2016 17:27:50 +0100

> On 14 Sep 2016, at 16:25, Peter Saint-Andre <[email-masked]> wrote:
> 

LGTM.  No objections from me!

--
Saúl Ibarra Corretgé
AG Projects