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

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 4 Dec 2015 20:24:28 -0700

On 9/23/15 8:52 PM, Peter Saint-Andre - &yet wrote:

>> "... whenever an XMPP-to-SIP gateway seeks to refresh an XMPP user’s
>> long-lived subscription to a SIP user’s presence, it MUST first send an
>> XMPP <presence/> stanza of type "probe" ..."
>>
>> I would have liked to see that discussed in the relevant procedures
>> section(s).
>
> OK, I'll see if we can include it earlier in the document.

How is this?

OLD

    For as long as a SIP user is online and interested in receiving
    presence notifications from the XMPP contact, the user's SIP User
    Agent is responsible for periodically refreshing the subscription by
    sending an updated SUBSCRIBE request with an appropriate value for
    the Expires header.  In response, the presence-aware SIP-to-XMPP
    gateway MUST send a SIP NOTIFY to the user agent (per [RFC6665]); if
    the SIP-to-XMPP gateway has meaningful information about the
    availability state of the XMPP user (e.g., obtained from the core
    presence session in the XMPP server) then the NOTIFY MUST communicate
    that information (e.g., by including a PIDF body [RFC3863] with the
    relevant data), whereas if the SIP-to-XMPP gateway does not have
    meaningful information about the availability state of the XMPP user
    then the NOTIFY MUST be empty as allowed by [RFC6665].

NEW

    For as long as a SIP user is online and interested in receiving
    presence notifications from the XMPP contact, the user's SIP User
    Agent is responsible for periodically refreshing the subscription by
    sending an updated SUBSCRIBE request with an appropriate value for
    the Expires header.  In response, the presence-aware SIP-to-XMPP
    gateway sends a SIP NOTIFY to the user agent (per [RFC6665]); if the
    SIP-to-XMPP gateway has meaningful information about the availability
    state of the XMPP user (e.g., obtained from the core presence session
    in the XMPP server or learned by sending a presence probe as
    described under Section 7) then the NOTIFY communicates that
    information (e.g., by including a PIDF body [RFC3863] with the
    relevant data), whereas if the SIP-to-XMPP gateway does not have
    meaningful information about the availability state of the XMPP user
    then the NOTIFY MUST be empty as allowed by [RFC6665].

Do you think we need more detail?

Peter

---

From: "Ben Campbell" <[email-masked]>
Date: Sun, 06 Dec 2015 18:48:41 -0600

I read this as removing the 2119 keywords for descriptions 6665 stuff, 
correct? If so, that's a fine change, but it doesn't seem to address the 
context of refreshing the subscription on behalf of an XMPP subscriber. 
Maybe the wrong comment was quoted?

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 6 Dec 2015 17:51:44 -0700

Yes, I'm cleaning up the conformance keywords, too.

This is the substantive modification:

OLD

  if
  that information

NEW

  if the
  information

I looked for another place to add a forward reference to Section 7 but I 
haven't found it yet. However, adding it only to this parenthetical 
clause seems a bit weak.

Peter

On 12/6/15 5:48 PM, Ben Campbell wrote:
> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox