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

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

This is the substantive modification:

OLD

  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

NEW

  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

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:
> 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.
>
> On 4 Dec 2015, at 21:24, Peter Saint-Andre wrote:
>
>> 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
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox