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

["Ben Campbell" <[e-mail]>]

Hi,

A few comments inline.

Thanks!

Ben.

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

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

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

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

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?)

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

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.

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