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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 07 December 2015 00:51 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402921A9036; Sun, 6 Dec 2015 16:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In7N4Z7TqIBy; Sun, 6 Dec 2015 16:51:46 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 892D11A9032; Sun, 6 Dec 2015 16:51:46 -0800 (PST)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3432841158; Sun, 6 Dec 2015 17:54:47 -0700 (MST)
To: Ben Campbell <ben@nostrum.com>
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net> <566258EC.6040900@stpeter.im> <3FA757FB-FE65-4BC8-AAB1-C5B0A153B996@nostrum.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <5664D820.8070606@stpeter.im>
Date: Sun, 6 Dec 2015 17:51:44 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <3FA757FB-FE65-4BC8-AAB1-C5B0A153B996@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/CtApqzQunb9hDBmEZe1NAH5EsXg>
Cc: stox@ietf.org, draft-ietf-stox-7248bis.all@ietf.org
Subject: Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2015 00:51:48 -0000

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