From nobody Fri Dec  4 19:24:34 2015
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 57C2A1B36A1; Fri,  4 Dec 2015 19:24:32 -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 G_avJrpkdzjB; Fri,  4 Dec 2015 19:24:31 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4631B36A2; Fri,  4 Dec 2015 19:24:30 -0800 (PST)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9D401411F4; Fri,  4 Dec 2015 20:27:24 -0700 (MST)
To: Ben Campbell <ben@nostrum.com>, draft-ietf-stox-7248bis.all@ietf.org, stox@ietf.org
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <566258EC.6040900@stpeter.im>
Date: Fri, 4 Dec 2015 20:24:28 -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: <56036577.3000204@andyet.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/DXAsBFhTJaKCygjj7P1avw9vLcA>
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: Sat, 05 Dec 2015 03:24:32 -0000

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 nobody Sun Dec  6 16:48:45 2015
Return-Path: <ben@nostrum.com>
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 413341A9006; Sun,  6 Dec 2015 16:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J-n9pGA1w4b8; Sun,  6 Dec 2015 16:48:43 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F151A9005; Sun,  6 Dec 2015 16:48:43 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB70mfpm092992 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 6 Dec 2015 18:48:43 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: "Ben Campbell" <ben@nostrum.com>
To: "Peter Saint-Andre" <stpeter@stpeter.im>
Date: Sun, 06 Dec 2015 18:48:41 -0600
Message-ID: <3FA757FB-FE65-4BC8-AAB1-C5B0A153B996@nostrum.com>
In-Reply-To: <566258EC.6040900@stpeter.im>
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net> <566258EC.6040900@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/6PJRAOJ8fOa5Ua_wldpirR1Wsc0>
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:48:45 -0000

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


From nobody Sun Dec  6 16:51:49 2015
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


From nobody Mon Dec 14 21:08:44 2015
Return-Path: <wwwrun@rfc-editor.org>
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 439B81B2AFE; Mon, 14 Dec 2015 21:08:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.912
X-Spam-Level: 
X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 1L4lC6lGY3SY; Mon, 14 Dec 2015 21:08:41 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 142AF1B2ADE; Mon, 14 Dec 2015 21:08:16 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 74A93187DBF; Mon, 14 Dec 2015 21:05:53 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20151215050553.74A93187DBF@rfc-editor.org>
Date: Mon, 14 Dec 2015 21:05:53 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/Lvxgo5d_ayVr-F3Z0GxF4tB158g>
Cc: stox@ietf.org, rfc-editor@rfc-editor.org
Subject: [Stox] RFC 7702 on Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
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: Tue, 15 Dec 2015 05:08:43 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7702

        Title:      Interworking between the Session Initiation 
                    Protocol (SIP) and the Extensible Messaging 
                    and Presence Protocol (XMPP): Groupchat 
        Author:     P. Saint-Andre, S. Ibarra, S. Loreto
        Status:     Standards Track
        Stream:     IETF
        Date:       December 2015
        Mailbox:    peter@andyet.com, 
                    saul@ag-projects.com, 
                    Salvatore.Loreto@ericsson.com
        Pages:      43
        Characters: 86457
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-stox-groupchat-11.txt

        URL:        https://www.rfc-editor.org/info/rfc7702

        DOI:        http://dx.doi.org/10.17487/RFC7702

This document defines a bidirectional protocol mapping for the
exchange of instant messages in the context of a multi-party chat
session among users of the Session Initiation Protocol (SIP) and
users of the Extensible Messaging and Presence Protocol (XMPP).
Specifically, this document defines a mapping between the SIP-based
Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat
(MUC) extension.

This document is a product of the SIP-TO-XMPP Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC