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

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

A few additional notes...

On 9/12/16 8:36 PM, Peter Saint-Andre wrote:
> Thanks for the feedback. Comments inline.
>
> On 9/12/16 8:26 AM, Ben Campbell wrote:
>> 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".
>
> Good idea, will do.

    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
    "closed"):

>>     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?)
>
> I was tempted to add "outbound" or "inbound" in all cases to make this
> crystal clear...

Changed to "cancel her outbound presence authorization"

<snip/>

>>     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.
>
> I will look into this. What you say sounds plausible but I'd like to
> 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:[e-mail] SIP/2.0
    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
    |  From: <sip:[e-mail]>;tag=j89d
    |  Call-ID: 2398B737-566F-4CBB-A21A-1F8EEF7AF423
    |  Event: presence
    |  Max-Forwards: 70
    |  CSeq: 1 SUBSCRIBE
    |  Contact: <sip:[e-mail]>;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).

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

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