From Markus.Isomaki@nokia.com Fri May 3 02:54:06 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A33221F8619 for ; Fri, 3 May 2013 02:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.378 X-Spam-Level: X-Spam-Status: No, score=-4.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww3WlYn5mVFI for ; Fri, 3 May 2013 02:54:00 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A5B2C21F9015 for ; Fri, 3 May 2013 02:53:49 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r439ri7r009851 for ; Fri, 3 May 2013 12:53:45 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 May 2013 12:53:44 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.144]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0328.011; Fri, 3 May 2013 09:53:44 +0000 From: To: Thread-Topic: test Thread-Index: Ac5H5BEJglfhdKygQm+DKih0Hg7QaA== Date: Fri, 3 May 2013 09:53:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: QYoRBtnynnTV/bAp8JVwv1SDhZatvjpwwaNuH4dLKrUNPuY/5R3Q3Ld3HzC+NDB2jQ8fyp2d3nuGFfxDx8Ju+SjS0Imor1SnygUNTAgd+O50TuU0v+JMfCn685hgkRfjKjZ3qNmmDxtzwYc1padgcV7tIqd9UleG7PoBwvWv26T32uAN9RpV8Qk70P/dXZSrDmbRFlPmwJZnypdxqeiBkw== x-originating-ip: [172.21.81.160] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB76209FD1CA4008AM1MPN1042mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2013 09:53:44.0855 (UTC) FILETIME=[19A2FA70:01CE47E4] X-Nokia-AV: Clean Subject: [Stox] test X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 09:54:06 -0000 --_000_E44893DD4E290745BB608EB23FDDB76209FD1CA4008AM1MPN1042mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Test. --_000_E44893DD4E290745BB608EB23FDDB76209FD1CA4008AM1MPN1042mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Test.

--_000_E44893DD4E290745BB608EB23FDDB76209FD1CA4008AM1MPN1042mg_-- From Markus.Isomaki@nokia.com Fri May 3 03:00:00 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCE621F8477; Fri, 3 May 2013 03:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.053 X-Spam-Level: X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuQP-lEYkkuz; Fri, 3 May 2013 02:59:55 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id C328C21F8619; Fri, 3 May 2013 02:59:55 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r439wkJI010880; Fri, 3 May 2013 12:59:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 May 2013 12:59:38 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.144]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0328.011; Fri, 3 May 2013 09:59:38 +0000 From: To: , Thread-Topic: New mailing list for the proposed SIP-to-XMPP (STOX) WG technical discussions Thread-Index: Ac5H44SB7qghBpRLS7yulBkbZF1apA== Date: Fri, 3 May 2013 09:59:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GMd8Xehk+cvfBfEd3KpxcUGh/F1G/EtNvyjF+e9tYh2QDr14hifrzQTKlSmwy+r3G+GJ3NFsQjKj4nqcuvVJcJL6Sek9+VNqWSO9nLu+Z/8Ypi0LxIY7MXOB4MyfkCBLNG4ODLvETek9CPvjMUt4i12CqMgJOlcP3vvatgsjfZzk4yWJFMrBE4dpMLZ0YzZ2s5f7+Ic/BbKdHzkdhOK53Tl6g5OAsyMAIt24VRP7biYbWQxYpzmLmxtOAXciGUe8Qst6jCxYdo147nP8wKgPYt4= x-originating-ip: [172.21.81.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2013 09:59:38.0463 (UTC) FILETIME=[EC6746F0:01CE47E4] X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 03 May 2013 03:49:20 -0700 Cc: yana@jitsi.org, rai@ietf.org, rlb@ipv.sx, fabio@bluendo.com, emcho@jitsi.org, saul@ag-projects.com, Gonzalo.Camarillo@ericsson.com, stpeter@stpeter.im, Salvatore.Loreto@ericsson.com Subject: [Stox] New mailing list for the proposed SIP-to-XMPP (STOX) WG technical discussions X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 10:00:00 -0000 Hi all, The proposed SIP-to-XMPP (STOX) WG is still in the chartering phase, please= see: http://datatracker.ietf.org/wg/stox/charter/ However, there are already various related drafts, like the '-groupchat' (s= ee below) and all the others starting with 'draft-saintandre-sip-xmpp-', th= at people are working on. In order to offload the related technical discuss= ion from DISPATCH list, we have created a dedicated STOX list (stox@ietf.or= g) for that purpose.=20 You can subscribe to it at: https://www.ietf.org/mailman/listinfo/stox So, everyone interested in the SIP-to-XMPP topic, please subscribe to the S= TOX list and use that for the further discussion, such as commenting on the= '-groupchat' draft, from now on. If and when STOX becomes an official RAI = WG, the same list will continue as a WG list. Regards, Markus=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Peter Saint-Andre Sent: 03 May, 2013 05:07 To: dispatch@ietf.org list Subject: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-groupchat-03= .txt FYI, Saul and I have submitted -03 of this interworking I-D... -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-groupchat-03.txt Date: Thu, 02 May 2013 19:05:08 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Author(s) : Peter Saint-Andre Salvatore Loreto Saul Ibarra Fabio Forno Filename : draft-saintandre-sip-xmpp-groupchat-03.txt Pages : 28 Date : 2013-05-02 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty 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 XMPP Multi- User Chat (MUC) extension and the SIP-based Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-saintandre-sip-xmpp-groupchat-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From stpeter@stpeter.im Fri May 3 09:13:10 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4621F9C02 for ; Fri, 3 May 2013 09:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwqvsODh-NaH for ; Fri, 3 May 2013 09:13:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1C22021F9820 for ; Fri, 3 May 2013 08:13:16 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6516A410F9; Fri, 3 May 2013 09:24:36 -0600 (MDT) Message-ID: <5183D409.9020804@stpeter.im> Date: Fri, 03 May 2013 09:13:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> <515E40A6.90508@stpeter.im> <868045FC-9C51-4F7A-A061-DF04A6C3A2C4@ag-projects.com> In-Reply-To: <868045FC-9C51-4F7A-A061-DF04A6C3A2C4@ag-projects.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 16:13:10 -0000 [moving to the STOX mailing list] On 4/7/13 10:47 AM, Saúl Ibarra Corretgé wrote: > Hi Peter, > > Are you planning to include mappings for MSRP REPORT chunks and > XEP-0184 delivery receipts? (not sure if I asked this earlier, I may > have forgotten). Hmm. I see that as a more advanced feature, not something that we'd expect most implementations to support. However, if MSRP REPORT chunks are widely used then I think it makes sense to define the mapping. I know that delivery receipts are not all that common in XMPP (yet?). Peter From stpeter@stpeter.im Fri May 3 12:30:58 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9021E21F8E6D for ; Fri, 3 May 2013 12:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm0ScVjRkEQJ for ; Fri, 3 May 2013 12:30:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 713A521F8B5F for ; Fri, 3 May 2013 12:30:49 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9D19640031; Fri, 3 May 2013 13:42:12 -0600 (MDT) Message-ID: <51841069.7030008@stpeter.im> Date: Fri, 03 May 2013 13:30:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <20130405023718.11095.85523.idtracker@ietfa.amsl.com> <515E391A.3030800@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-im-03.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:30:58 -0000 On 4/7/13 10:43 AM, Saúl Ibarra Corretgé wrote: > Hi Peter, > > I did a quick read of this version, in section 4, shouldn't we be > looking at the RURI, instead of the To header? I don't quite understand your statement. Could you expand it a bit or propose specific text that you think needs to change? Thanks! Peter From stpeter@stpeter.im Fri May 3 12:33:22 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E24E21F8E6D for ; Fri, 3 May 2013 12:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YISBncYNrRRh for ; Fri, 3 May 2013 12:33:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D0CD421F88D8 for ; Fri, 3 May 2013 12:33:16 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6405640031; Fri, 3 May 2013 13:44:40 -0600 (MDT) Message-ID: <518410FD.4020307@stpeter.im> Date: Fri, 03 May 2013 13:33:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Lundberg References: <515BAAEE.2070305@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] [dispatch] Comments on draft-saintandre-sip-xmpp-presence-04 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:33:22 -0000 On 4/5/13 2:13 PM, Michael Lundberg wrote: > Peter, > > Thanks. I think the updates look good. One additional suggestion is > to add the element to Table 7, with a note similar to the one > provided in Table 6. This will provide a method for mapping 'away' > and 'dnd' information in the opposite direction. Similar to the note > in Table 6, this would require the SIP implementation to support the > 'jabber:client' namespace. If the SIP implementation supports the > namespace, the gateway can then map the values directly into the > element of the XMPP presence messages. Michael, I think we addressed this feedback in version -05, but please let me know if that's not the case. Peter From stpeter@stpeter.im Fri May 3 12:47:23 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD3421F863B for ; Fri, 3 May 2013 12:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGznD-fp20ni for ; Fri, 3 May 2013 12:47:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 07ACF21F901A for ; Fri, 3 May 2013 12:47:17 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EBA5940031; Fri, 3 May 2013 13:58:39 -0600 (MDT) Message-ID: <51841444.6070603@stpeter.im> Date: Fri, 03 May 2013 13:47:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> <515BAA15.9050704@stpeter.im> <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> In-Reply-To: <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:47:23 -0000 On 4/7/13 11:44 AM, Saúl Ibarra Corretgé wrote: > Hi Peter, > > Here are some comments on revision 5: > > - Section 3.3.1: The initial SUBSCRIBE should have an empty to tag. Really? That doesn't seem consistent with RFC 3856. > - Section 4.3: Tuple id should be ID-orchard Agreed. > - Section 4.3, table 7: The reference to looks like a c&p > error ;-) Yep! > I think we should make sue of the 'contact' child element of the PIDF > tuple to provide the full (translated as per the core draft) URI of > the presence entity. From/To headers cannot have GRUUs in them IIRC, RFC 5627 implies so, yes. (BTW, both draft-saintandre-sip-xmpp-chat and draft-saintandre-sip-xmpp-groupchat mistakenly have GRUUs in From: headers; we'll need to fix those.) > so the contact element seems like the right place to hold this piece > of information. This way the endpoint which processes this presence > information will learn how to contact *this* particular instance. Good point. I agree that the Contact header is the right place to put that information. > In addition, the draft currently only considers the case where a > single NOTIFY is generated for a presence stanza, but if RLS is used > a presence agent will aggregate multiple PIDF documents in a single > RLMI document and send it in a single NOTIFY, so not relying in the > From header would help. Resource lists have always frightened me. Care to propose some text? ;-) But in any case I need to re-read RFC 4662... Peter From ag@ag-projects.com Fri May 3 13:00:16 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8783721F8B8F for ; Fri, 3 May 2013 13:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE98M3-ymeMk for ; Fri, 3 May 2013 13:00:10 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id F3AB821F87CB for ; Fri, 3 May 2013 13:00:09 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id C04D5B01BE; Fri, 3 May 2013 22:00:07 +0200 (CEST) Received: from ag-retina.fritz.box (xs4all.dns-hosting.info [82.161.39.123]) by mail.sipthor.net (Postfix) with ESMTPSA id A9C22B01BE; Fri, 3 May 2013 21:59:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <51841444.6070603@stpeter.im> Date: Fri, 3 May 2013 21:59:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8749A3D1-7F92-4A54-A0BE-E4925514E57E@ag-projects.com> References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> <515BAA15.9050704@stpeter.im> <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> <51841444.6070603@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1283) Cc: stox@ietf.org, =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:00:16 -0000 On May 3, 2013, at 9:47 PM, Peter Saint-Andre wrote: > On 4/7/13 11:44 AM, Sa=FAl Ibarra Corretg=E9 wrote: >> Hi Peter, >>=20 >> Here are some comments on revision 5: >>=20 >> - Section 3.3.1: The initial SUBSCRIBE should have an empty to tag. >=20 > Really? That doesn't seem consistent with RFC 3856. >=20 To tag is generated by the end-point that receives the Subscribe. The = end-points that create a Subscribe knows only its own from tag, he = cannot know the to tag of a counter party that will received the = message. Adrian From stpeter@stpeter.im Fri May 3 13:09:04 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4853D21F8B65 for ; Fri, 3 May 2013 13:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKF45M3Au7Oh for ; Fri, 3 May 2013 13:08:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 856A621F88D8 for ; Fri, 3 May 2013 13:08:58 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0DC1C40031; Fri, 3 May 2013 14:20:21 -0600 (MDT) Message-ID: <5184195A.9050102@stpeter.im> Date: Fri, 03 May 2013 14:08:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Georgescu References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> <515BAA15.9050704@stpeter.im> <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> <51841444.6070603@stpeter.im> <8749A3D1-7F92-4A54-A0BE-E4925514E57E@ag-projects.com> In-Reply-To: <8749A3D1-7F92-4A54-A0BE-E4925514E57E@ag-projects.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:09:04 -0000 On 5/3/13 1:59 PM, Adrian Georgescu wrote: > On May 3, 2013, at 9:47 PM, Peter Saint-Andre wrote: > >> On 4/7/13 11:44 AM, Saúl Ibarra Corretgé wrote: >>> Hi Peter, >>> >>> Here are some comments on revision 5: >>> >>> - Section 3.3.1: The initial SUBSCRIBE should have an empty to tag. >> >> Really? That doesn't seem consistent with RFC 3856. >> > > To tag is generated by the end-point that receives the Subscribe. The end-points that create a Subscribe knows only its own from tag, he cannot know the to tag of a counter party that will received the message. Oh, I see, it contains only a Request-URI, not a To: header. Correct? Peter From stpeter@stpeter.im Fri May 3 13:13:23 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5A621F8B8F for ; Fri, 3 May 2013 13:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xa29oSdYhjp for ; Fri, 3 May 2013 13:13:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AC9F521F8A74 for ; Fri, 3 May 2013 13:13:13 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4C1FA40031; Fri, 3 May 2013 14:24:37 -0600 (MDT) Message-ID: <51841A59.1070208@stpeter.im> Date: Fri, 03 May 2013 14:13:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Georgescu References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> <515BAA15.9050704@stpeter.im> <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> <51841444.6070603@stpeter.im> <8749A3D1-7F92-4A54-A0BE-E4925514E57E@ag-projects.com> <5184195A.9050102@stpeter.im> In-Reply-To: <5184195A.9050102@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:13:23 -0000 On 5/3/13 2:08 PM, Peter Saint-Andre wrote: > On 5/3/13 1:59 PM, Adrian Georgescu wrote: >> On May 3, 2013, at 9:47 PM, Peter Saint-Andre wrote: >> >>> On 4/7/13 11:44 AM, Saúl Ibarra Corretgé wrote: >>>> Hi Peter, >>>> >>>> Here are some comments on revision 5: >>>> >>>> - Section 3.3.1: The initial SUBSCRIBE should have an empty to tag. >>> >>> Really? That doesn't seem consistent with RFC 3856. >>> >> >> To tag is generated by the end-point that receives the Subscribe. The end-points that create a Subscribe knows only its own from tag, he cannot know the to tag of a counter party that will received the message. > > Oh, I see, it contains only a Request-URI, not a To: header. Correct? Nevertheless, the examples in Section 8 of RFC 3856 include the To: header... Peter From ag@ag-projects.com Fri May 3 13:16:45 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E44421F8B15 for ; Fri, 3 May 2013 13:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCGp+Rq48h8D for ; Fri, 3 May 2013 13:16:40 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF8B21F84B2 for ; Fri, 3 May 2013 13:16:40 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id C7798B35DE; Fri, 3 May 2013 22:16:39 +0200 (CEST) Received: from ag-retina.fritz.box (xs4all.dns-hosting.info [82.161.39.123]) by mail.sipthor.net (Postfix) with ESMTPSA id 7D5C1B017C; Fri, 3 May 2013 22:16:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_AB775E7C-E0A4-4670-922A-E77A9EEBF40A" From: Adrian Georgescu In-Reply-To: <51841A59.1070208@stpeter.im> Date: Fri, 3 May 2013 22:16:40 +0200 Message-Id: <03059DAF-7003-49EE-BCAC-0FFA237AB765@ag-projects.com> References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> <515BAA15.9050704@stpeter.im> <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> <51841444.6070603@stpeter.im> <8749A3D1-7F92-4A54-A0BE-E4925514E57E@ag-projects.com> <5184195A.9050102@stpeter.im> <51841A59.1070208@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1283) Cc: stox@ietf.org, =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:16:45 -0000 --Apple-Mail=_AB775E7C-E0A4-4670-922A-E77A9EEBF40A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 8. Example Message Flow F1 SUBSCRIBE watcher->example.com server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/TCP watcherhost.example.com;branch=3Dz9hG4bKnashds7 To: From: ;tag=3Dxfg9 The tag is the ;tag attribute you see in =46rom header. The To header = does not have one, it is populated by the responding end-point. Adrian On May 3, 2013, at 10:13 PM, Peter Saint-Andre wrote: > On 5/3/13 2:08 PM, Peter Saint-Andre wrote: >> On 5/3/13 1:59 PM, Adrian Georgescu wrote: >>> On May 3, 2013, at 9:47 PM, Peter Saint-Andre wrote: >>>=20 >>>> On 4/7/13 11:44 AM, Sa=FAl Ibarra Corretg=E9 wrote: >>>>> Hi Peter, >>>>>=20 >>>>> Here are some comments on revision 5: >>>>>=20 >>>>> - Section 3.3.1: The initial SUBSCRIBE should have an empty to = tag. >>>>=20 >>>> Really? That doesn't seem consistent with RFC 3856. >>>>=20 >>>=20 >>> To tag is generated by the end-point that receives the Subscribe. = The end-points that create a Subscribe knows only its own from tag, he = cannot know the to tag of a counter party that will received the = message. >>=20 >> Oh, I see, it contains only a Request-URI, not a To: header. Correct? >=20 > Nevertheless, the examples in Section 8 of RFC 3856 include the To: > header... >=20 > Peter >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox >=20 --Apple-Mail=_AB775E7C-E0A4-4670-922A-E77A9EEBF40A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

8.  Example Message Flow

F1 SUBSCRIBE   watcher->example.com server

      SUBSCRIBE sip:resource@example.com SIP/2.0
      Via: SIP/2.0/TCP watcherhost.example.com;branch=
=3Dz9hG4bKnashds7
      To: <sip:resource@example.com>
      From: <sip:user@example.com>;tag=3Dxfg9
The tag is the ;tag attribute you see in =46rom =
header. The To header does not have one, it is populated by the =
responding =
end-point.

Adrian


On May 3, 2013, at 10:13 PM, Peter Saint-Andre =
wrote:

On 5/3/13 2:08 PM, Peter Saint-Andre =
wrote:
On 5/3/13 1:59 PM, Adrian Georgescu =
wrote:
On May 3, 2013, at 9:47 PM, Peter Saint-Andre =
wrote:

On =
4/7/13 11:44 AM, Sa=FAl Ibarra Corretg=E9 =
wrote:
Hi =
Peter,

Here are some comments on =
revision =
5:

- Section 3.3.1: The initial =
SUBSCRIBE should have an empty to =
tag.

Really? =
That doesn't seem consistent with RFC =
3856.


To tag is generated by the =
end-point that receives the Subscribe. The end-points that create a =
Subscribe knows only its own from tag, he cannot know the to tag of a =
counter party that will received the =
message.

Oh, I see, it =
contains only a Request-URI, not a To: header. =
Correct?

Nevertheless, the examples in Section 8 of =
RFC 3856 include the =
To:
header...

Peter

_____________________________________=
__________
stox mailing list
stox@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/stox


=

--Apple-Mail=_AB775E7C-E0A4-4670-922A-E77A9EEBF40A--

From saul@ag-projects.com  Fri May  3 13:22:14 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5FD21F8EB9 for ; Fri,  3 May 2013 13:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlCaKrmm14Mt for ; Fri,  3 May 2013 13:22:08 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 91F7521F8EC9 for ; Fri,  3 May 2013 13:22:05 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id F2721B35DE; Fri,  3 May 2013 22:22:04 +0200 (CEST)
Received: from [192.168.99.48] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 54BDAB017C; Fri,  3 May 2013 22:21:52 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <5183D409.9020804@stpeter.im>
Date: Fri, 3 May 2013 22:21:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <78AF23C8-C110-4DAC-8051-FE1CD1267FF7@ag-projects.com>
References: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> <515E40A6.90508@stpeter.im> <868045FC-9C51-4F7A-A061-DF04A6C3A2C4@ag-projects.com> <5183D409.9020804@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1503)
Cc: stox@ietf.org
Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 May 2013 20:22:14 -0000

On May 3, 2013, at 5:13 PM, Peter Saint-Andre  =
wrote:

> [moving to the STOX mailing list]
>=20
> On 4/7/13 10:47 AM, Sa=FAl Ibarra Corretg=E9 wrote:
>> Hi Peter,
>>=20
>> Are you planning to include mappings for MSRP REPORT chunks and
>> XEP-0184 delivery receipts? (not sure if I asked this earlier, I may
>> have forgotten).
>=20
> Hmm. I see that as a more advanced feature, not something that we'd
> expect most implementations to support. However, if MSRP REPORT chunks
> are widely used then I think it makes sense to define the mapping. I
> know that delivery receipts are not all that common in XMPP (yet?).
>=20

The MSRP REPORT chunk is defined in the core MSRP spec, so all =
implementations must support it AFAIK. While this is not the case in =
XMPP, I guess it wouldn't hurt to specify how it should be done, would =
it?

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From saul@ag-projects.com  Fri May  3 13:26:53 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C28921F8EC2 for ; Fri,  3 May 2013 13:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHCfNMFRbutH for ; Fri,  3 May 2013 13:26:47 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 29EA621F8BDE for ; Fri,  3 May 2013 13:26:47 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 8A3CBB35DE; Fri,  3 May 2013 22:26:46 +0200 (CEST)
Received: from [192.168.99.48] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id C173EB017C; Fri,  3 May 2013 22:26:45 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <51841069.7030008@stpeter.im>
Date: Fri, 3 May 2013 22:26:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C0D4541-66B5-4126-805A-9AD9D27D2188@ag-projects.com>
References: <20130405023718.11095.85523.idtracker@ietfa.amsl.com> <515E391A.3030800@stpeter.im>  <51841069.7030008@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1503)
Cc: stox@ietf.org
Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-im-03.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 May 2013 20:26:53 -0000

On May 3, 2013, at 9:30 PM, Peter Saint-Andre  =
wrote:

> On 4/7/13 10:43 AM, Sa=FAl Ibarra Corretg=E9 wrote:
>> Hi Peter,
>>=20
>> I did a quick read of this version, in section 4, shouldn't we be
>> looking at the RURI, instead of the To header?
>=20
> I don't quite understand your statement. Could you expand it a bit or
> propose specific text that you think needs to change?
>=20

Hi!

Section 4 has the following text:

" Therefore
   we assume that the To header of a request received by a SIMPLE-XMPP
   gateway will contain a sip: or sips: URI.  The gateway SHOULD resolve
   that address to an im: URI for SIP MESSAGE requests,"

I think we should say RURI instead of To header there, because the To =
header is not used for routing and in case of GRUU usage (like in the =
example) the only way for a request to be properly routed would be to =
put it in the RURI. So I'd say:

" Therefore
   we assume that the  Request-URI of a request received by a =
SIMPLE-XMPP
   gateway will contain a sip: or sips: URI.  The gateway SHOULD resolve
   that address to an im: URI for SIP MESSAGE requests,"


Cheers,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From saul@ag-projects.com  Fri May  3 13:29:50 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F3D21F92CF for ; Fri,  3 May 2013 13:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QfHQV6uiYz8 for ; Fri,  3 May 2013 13:29:45 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5E721F91BC for ; Fri,  3 May 2013 13:29:45 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 632FFB35DE; Fri,  3 May 2013 22:29:44 +0200 (CEST)
Received: from [192.168.99.48] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 215CEB017C; Fri,  3 May 2013 22:29:42 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <51841444.6070603@stpeter.im>
Date: Fri, 3 May 2013 22:29:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> <515BAA15.9050704@stpeter.im> <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> <51841444.6070603@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1503)
Cc: stox@ietf.org
Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 May 2013 20:29:51 -0000

>=20
>> I think we should make sue of the 'contact' child element of the PIDF
>> tuple to provide the full (translated as per the core draft) URI of
>> the presence entity. From/To headers cannot have GRUUs in them IIRC,
>=20
> RFC 5627 implies so, yes. (BTW, both draft-saintandre-sip-xmpp-chat =
and
> draft-saintandre-sip-xmpp-groupchat mistakenly have GRUUs in From:
> headers; we'll need to fix those.)
>=20

Oh, right!

>=20
>> In addition, the draft currently only considers the case where a
>> single NOTIFY is generated for a presence stanza, but if RLS is used
>> a presence agent will aggregate multiple PIDF documents in a single
>> RLMI document and send it in a single NOTIFY, so not relying in the
>> =46rom header would help.
>=20
> Resource lists have always frightened me. Care to propose some text? =
;-)
>=20

I'll have another read at what we have right now and propose some text.


--
Sa=FAl Ibarra Corretg=E9
AG Projects




From stpeter@stpeter.im  Sun May  5 19:19:01 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485AE21F8972 for ; Sun,  5 May 2013 19:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.78
X-Spam-Level: 
X-Spam-Status: No, score=-101.78 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1OzqTrx+t4Y for ; Sun,  5 May 2013 19:18:55 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6CA21F896B for ; Sun,  5 May 2013 19:18:55 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7C2CD40035; Sun,  5 May 2013 20:30:23 -0600 (MDT)
Message-ID: <51871303.6020208@stpeter.im>
Date: Sun, 05 May 2013 20:18:43 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
References: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> <515E40A6.90508@stpeter.im> <868045FC-9C51-4F7A-A061-DF04A6C3A2C4@ag-projects.com> <5183D409.9020804@stpeter.im> <78AF23C8-C110-4DAC-8051-FE1CD1267FF7@ag-projects.com>
In-Reply-To: <78AF23C8-C110-4DAC-8051-FE1CD1267FF7@ag-projects.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: stox@ietf.org
Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 May 2013 02:19:01 -0000

On 5/3/13 2:21 PM, Saúl Ibarra Corretgé wrote:
> 
> On May 3, 2013, at 5:13 PM, Peter Saint-Andre 
> wrote:
> 
>> [moving to the STOX mailing list]
>> 
>> On 4/7/13 10:47 AM, Saúl Ibarra Corretgé wrote:
>>> Hi Peter,
>>> 
>>> Are you planning to include mappings for MSRP REPORT chunks and 
>>> XEP-0184 delivery receipts? (not sure if I asked this earlier, I
>>> may have forgotten).
>> 
>> Hmm. I see that as a more advanced feature, not something that
>> we'd expect most implementations to support. However, if MSRP
>> REPORT chunks are widely used then I think it makes sense to define
>> the mapping. I know that delivery receipts are not all that common
>> in XMPP (yet?).
>> 
> 
> The MSRP REPORT chunk is defined in the core MSRP spec, so all
> implementations must support it AFAIK. While this is not the case in
> XMPP, I guess it wouldn't hurt to specify how it should be done,
> would it?

In general, there's a wide range of things we *could* specify. Whether
it makes sense to specify everything now, or in the documents we've been
working on so far, is another question. If a WG is formed, I'm sure we
might have some interesting discussions on this topic. :-)

In part, the question is: how widely implemented is the feature? You
might have noticed that there is a large diff between versions 04 and 05
of draft-saintandre-sip-xmpp-chat. That's because I deleted everything
about negotiation of formal one-to-one chat sessions in XMPP, which is
defined in XEP-0155 but not implemented in any of the clients.

Message receipts (XEP-0184) is more widely implemented, but it's not a
universal feature by any means. Furthermore, I think we'd need to
compare it to the MSRP REPORT chunk to understand if it is really
solving the same problem.

(BTW, while we are chatting about chat sessions, a more popular feature
for which to define mappings might be is-typing notifications.)

Peter

From stpeter@stpeter.im  Sun May  5 19:20:45 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810A221F8972 for ; Sun,  5 May 2013 19:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.722
X-Spam-Level: 
X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cevm9WI-ceR for ; Sun,  5 May 2013 19:20:39 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AB3B421F896B for ; Sun,  5 May 2013 19:20:39 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 93EC540035; Sun,  5 May 2013 20:32:10 -0600 (MDT)
Message-ID: <51871376.4000908@stpeter.im>
Date: Sun, 05 May 2013 20:20:38 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> <515BAA15.9050704@stpeter.im> <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> <51841444.6070603@stpeter.im> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: stox@ietf.org
Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 May 2013 02:20:45 -0000

On 5/3/13 2:29 PM, Saúl Ibarra Corretgé wrote:
>>
>>> I think we should make sue of the 'contact' child element of the PIDF
>>> tuple to provide the full (translated as per the core draft) URI of
>>> the presence entity. From/To headers cannot have GRUUs in them IIRC,
>>
>> RFC 5627 implies so, yes. (BTW, both draft-saintandre-sip-xmpp-chat and
>> draft-saintandre-sip-xmpp-groupchat mistakenly have GRUUs in From:
>> headers; we'll need to fix those.)
>>
> 
> Oh, right!

Those are all fixed in source control now, by the way.

>>> In addition, the draft currently only considers the case where a
>>> single NOTIFY is generated for a presence stanza, but if RLS is used
>>> a presence agent will aggregate multiple PIDF documents in a single
>>> RLMI document and send it in a single NOTIFY, so not relying in the
>>> From header would help.
>>
>> Resource lists have always frightened me. Care to propose some text? ;-)
>>
> 
> I'll have another read at what we have right now and propose some text.

Great, thanks!

Peter



From stpeter@stpeter.im  Sun May  5 19:23:23 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28F021F8A6B for ; Sun,  5 May 2013 19:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.68
X-Spam-Level: 
X-Spam-Status: No, score=-101.68 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uDMjlHXMszN for ; Sun,  5 May 2013 19:23:17 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBEB21F8A48 for ; Sun,  5 May 2013 19:23:17 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D477640035; Sun,  5 May 2013 20:34:47 -0600 (MDT)
Message-ID: <51871414.70504@stpeter.im>
Date: Sun, 05 May 2013 20:23:16 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
References: <20130405023718.11095.85523.idtracker@ietfa.amsl.com> <515E391A.3030800@stpeter.im>  <51841069.7030008@stpeter.im> <5C0D4541-66B5-4126-805A-9AD9D27D2188@ag-projects.com>
In-Reply-To: <5C0D4541-66B5-4126-805A-9AD9D27D2188@ag-projects.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: stox@ietf.org
Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-im-03.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 May 2013 02:23:24 -0000

On 5/3/13 2:26 PM, Saúl Ibarra Corretgé wrote:
> 
> On May 3, 2013, at 9:30 PM, Peter Saint-Andre  wrote:
> 
>> On 4/7/13 10:43 AM, Saúl Ibarra Corretgé wrote:
>>> Hi Peter,
>>>
>>> I did a quick read of this version, in section 4, shouldn't we be
>>> looking at the RURI, instead of the To header?
>>
>> I don't quite understand your statement. Could you expand it a bit or
>> propose specific text that you think needs to change?
>>
> 
> Hi!
> 
> Section 4 has the following text:
> 
> " Therefore
>    we assume that the To header of a request received by a SIMPLE-XMPP
>    gateway will contain a sip: or sips: URI.  The gateway SHOULD resolve
>    that address to an im: URI for SIP MESSAGE requests,"
> 
> I think we should say RURI instead of To header there, because the To header is not used for routing and in case of GRUU usage (like in the example) the only way for a request to be properly routed would be to put it in the RURI. So I'd say:
> 
> " Therefore
>    we assume that the  Request-URI of a request received by a SIMPLE-XMPP
>    gateway will contain a sip: or sips: URI.  The gateway SHOULD resolve
>    that address to an im: URI for SIP MESSAGE requests,"

Yes, that is better. Thanks for the correction. To track this fix, I've
also updated Table 5 in source control.

Peter


From saul@ag-projects.com  Mon May  6 01:24:02 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA5121F8EDA for ; Mon,  6 May 2013 01:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.253
X-Spam-Level: 
X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXIwPgF2eBFR for ; Mon,  6 May 2013 01:23:47 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA7A21F8F0C for ; Mon,  6 May 2013 01:23:42 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 8E8F8B0180; Mon,  6 May 2013 10:23:40 +0200 (CEST)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 7CDADB0180; Mon,  6 May 2013 10:23:27 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <51871303.6020208@stpeter.im>
Date: Mon, 6 May 2013 10:23:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> <515E40A6.90508@stpeter.im> <868045FC-9C51-4F7A-A061-DF04A6C3A2C4@ag-projects.com> <5183D409.9020804@stpeter.im> <78AF23C8-C110-4DAC-8051-FE1CD1267FF7@ag-projects.com> <51871303.6020208@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1085)
Cc: stox@ietf.org
Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 May 2013 08:24:02 -0000

>>>=20
>>=20
>> The MSRP REPORT chunk is defined in the core MSRP spec, so all
>> implementations must support it AFAIK. While this is not the case in
>> XMPP, I guess it wouldn't hurt to specify how it should be done,
>> would it?
>=20
> In general, there's a wide range of things we *could* specify. Whether
> it makes sense to specify everything now, or in the documents we've =
been
> working on so far, is another question. If a WG is formed, I'm sure we
> might have some interesting discussions on this topic. :-)
>=20
> In part, the question is: how widely implemented is the feature? You
> might have noticed that there is a large diff between versions 04 and =
05
> of draft-saintandre-sip-xmpp-chat. That's because I deleted everything
> about negotiation of formal one-to-one chat sessions in XMPP, which is
> defined in XEP-0155 but not implemented in any of the clients.
>=20
> Message receipts (XEP-0184) is more widely implemented, but it's not a
> universal feature by any means. Furthermore, I think we'd need to
> compare it to the MSRP REPORT chunk to understand if it is really
> solving the same problem.
>=20

Basically, it allows for end to end acknowledgement of a chunk (when not =
using partial reports). I had no idea about XEP-0184 but I found it =
while looking at XMPP traces and I thought it matched the idea of a =
REPORT, that's why I ended up implementing it in SylkServer :-) However, =
the XEP says the following: "The recipient simply does not wish to =
return a receipt for the content message." which means that if a client =
which does support receipts but choses not to send them leaves us in a =
weird state in which we don't know if the message was received or not, =
so I chose to send a negative REPORT back after a reasonable amount of =
time. But we can look into this later on.

> (BTW, while we are chatting about chat sessions, a more popular =
feature
> for which to define mappings might be is-typing notifications.)
>=20

Oh, we did that in SylkServer, I can probably propose some text based on =
how we translated RFC3994 into XMPP chatstates and vice versa, I can =
send something over next week.

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From stpeter@stpeter.im  Mon May  6 20:25:22 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EF821F85C9 for ; Mon,  6 May 2013 20:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.429
X-Spam-Level: 
X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz80qwBxQOBu for ; Mon,  6 May 2013 20:25:16 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9914521F8D6A for ; Mon,  6 May 2013 20:25:13 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2FF3F4110A; Mon,  6 May 2013 21:36:47 -0600 (MDT)
Message-ID: <51887417.2010402@stpeter.im>
Date: Mon, 06 May 2013 21:25:11 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
References: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> <515E40A6.90508@stpeter.im> <868045FC-9C51-4F7A-A061-DF04A6C3A2C4@ag-projects.com> <5183D409.9020804@stpeter.im> <78AF23C8-C110-4DAC-8051-FE1CD1267FF7@ag-projects.com> <51871303.6020208@stpeter.im> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: stox@ietf.org
Subject: Re: [Stox] [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2013 03:25:22 -0000

On 5/6/13 2:23 AM, Saúl Ibarra Corretgé wrote:
>>>> 
>>> 
>>> The MSRP REPORT chunk is defined in the core MSRP spec, so all 
>>> implementations must support it AFAIK. While this is not the case
>>> in XMPP, I guess it wouldn't hurt to specify how it should be
>>> done, would it?
>> 
>> In general, there's a wide range of things we *could* specify.
>> Whether it makes sense to specify everything now, or in the
>> documents we've been working on so far, is another question. If a
>> WG is formed, I'm sure we might have some interesting discussions
>> on this topic. :-)
>> 
>> In part, the question is: how widely implemented is the feature?
>> You might have noticed that there is a large diff between versions
>> 04 and 05 of draft-saintandre-sip-xmpp-chat. That's because I
>> deleted everything about negotiation of formal one-to-one chat
>> sessions in XMPP, which is defined in XEP-0155 but not implemented
>> in any of the clients.
>> 
>> Message receipts (XEP-0184) is more widely implemented, but it's
>> not a universal feature by any means. Furthermore, I think we'd
>> need to compare it to the MSRP REPORT chunk to understand if it is
>> really solving the same problem.
>> 
> 
> Basically, it allows for end to end acknowledgement of a chunk (when
> not using partial reports). I had no idea about XEP-0184 but I found
> it while looking at XMPP traces and I thought it matched the idea of
> a REPORT, that's why I ended up implementing it in SylkServer :-)
> However, the XEP says the following: "The recipient simply does not
> wish to return a receipt for the content message." which means that
> if a client which does support receipts but choses not to send them
> leaves us in a weird state in which we don't know if the message was
> received or not, so I chose to send a negative REPORT back after a
> reasonable amount of time. But we can look into this later on.

Well, several times a year someone asks whether XEP-0184 can tell you
whether the recipient actually has read the message, and we tell them
no. If MSRP REPORT chunks make that kind of guarantee, then the two
technologies are not equivalent. XEP-0184 is very careful to specify
what it does and does not provide. :-)

>> (BTW, while we are chatting about chat sessions, a more popular
>> feature for which to define mappings might be is-typing
>> notifications.)
>> 
> 
> Oh, we did that in SylkServer, I can probably propose some text based
> on how we translated RFC3994 into XMPP chatstates and vice versa, I
> can send something over next week.

Great, thanks.

Peter



From iesg-secretary@ietf.org  Fri May 31 08:37:54 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AF821F962B; Fri, 31 May 2013 08:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.129
X-Spam-Level: 
X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrEGsu6+-4OX; Fri, 31 May 2013 08:37:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E084621F8EC1; Fri, 31 May 2013 08:37:53 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.50
Message-ID: <20130531153753.17170.54746.idtracker@ietfa.amsl.com>
Date: Fri, 31 May 2013 08:37:53 -0700
Cc: stox WG , Peter Saint-Andre 
Subject: [Stox] WG Review: SIP-TO-XMPP (stox)
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 May 2013 15:37:54 -0000

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2013-06-10.

SIP-TO-XMPP (stox)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Markus Isomaki 
  Yana Stamcheva 

Assigned Area Director:
  Gonzalo Camarillo 

Mailing list
  Address: stox@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/stox
  Archive: http://www.ietf.org/mail-archive/web/stox/

Charter:

Problem Statement

The IETF has defined two signalling technologies that can be used
for multimedia session negotiation, instant messaging, presence,
file transfer, capabilities discovery, notifications, and other types 
of real-time functionality:

o  The Session Initiation Protocol (SIP), along with various SIP
   extensions developed within the SIP for Instant Messaging and
   Presence Leveraging Extensions (SIMPLE) Working Group.

o  The Extensible Messaging and Presence Protocol (XMPP), along
   with various XMPP extensions developed by the IETF as well as by
   the XMPP Standards Foundation.

SIP has been focused primarily on media session negotiation (e.g., audio
and video), whereas XMPP has been focused primarily on messaging and
presence.  As a result, the technologies are mostly complementary.
However, there is also some overlap between SIP and XMPP, since there
are SIP extensions for messaging, presence, groupchat, file transfer,
etc., and there are XMPP extensions for multimedia session negotiation.
This overlap has practical implications, since some deployed services
use SIP for both media and messaging/presence, whereas other deployed
services use XMPP for both messaging/presence and media.  When such 
services wish to exchange information, they often need to translate 
their native protocol (either SIP or XMPP) to the other protocol (either 
XMPP or SIP).

Implementers needing to perform such protocol mappings have often worked
out their own heuristics for doing so.  Unfortunately, these heuristics
are not always consistent, which can lead to interoperability problems.

Objectives

To make it easier for implementers to enable interworking between
SIP-based systems and XMPP-based systems, several Internet-Drafts have
defined guidelines for protocol mapping between SIP and XMPP, starting
with draft-saintandre-xmpp-simple-00 in early 2004.  The current
documents are:

draft-saintandre-sip-xmpp-core
draft-saintandre-sip-xmpp-presence
draft-saintandre-sip-xmpp-im
draft-saintandre-sip-xmpp-chat
draft-saintandre-sip-xmpp-groupchat
draft-saintandre-sip-xmpp-media

These documents are fairly stable and the authors have received feedback
from a number of implementers over the years.  However, implementers do
not always know about these documents because they are Internet-Drafts
and sometimes they have become expired due to inactivity.  Thus it would 
be helpful to polish them off and publish them as RFCs.

It might also be helpful to at some point publish additional documents in

the same series, covering topics like capabilities discovery and file 
transfer.  However, any such work would require a recharter.

The group shall not be tasked with defining any new protocols, only with
specifying mappings between existing protocols that have been defined for
SIP and XMPP.

Deliverables

1. Address mapping and error handling
2. Presence mapping
3. Mapping for single instant messages
4. Mapping for one-to-one text chat sessions
5. Mapping for multi-user text chat sessions
6. Mapping for media signaling

All of the foregoing deliverables are standards track, since they are
subject to interoperability testing.

Milestones:
TBD


From iesg@ietf.org  Fri May 31 09:13:14 2013
Return-Path: 
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47F021F84B2; Fri, 31 May 2013 09:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.131
X-Spam-Level: 
X-Spam-Status: No, score=-99.131 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK4mbSAgkXcK; Fri, 31 May 2013 09:13:14 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D54221F8F83; Fri, 31 May 2013 09:13:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: The IESG 
To: IETF Announcement List 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.50
Message-ID: <20130531161307.18262.6235.idtracker@ietfa.amsl.com>
Date: Fri, 31 May 2013 09:13:07 -0700
Cc: stox@ietf.org, stpeter@stpeter.im
Subject: [Stox] Correction: WG Review: SIP-TO-XMPP (stox)
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: iesg@ietf.org
List-Id: SIP-TO-XMPP Working Group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 May 2013 16:13:14 -0000

(Corrected CC line above.)

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2013-06-10.

SIP-TO-XMPP (stox)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Markus Isomaki 
  Yana Stamcheva 

Assigned Area Director:
  Gonzalo Camarillo 

Mailing list
  Address: stox@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/stox
  Archive: http://www.ietf.org/mail-archive/web/stox/

Charter:

Problem Statement

The IETF has defined two signalling technologies that can be used
for multimedia session negotiation, instant messaging, presence,
file transfer, capabilities discovery, notifications, and other types =

of real-time functionality:

o  The Session Initiation Protocol (SIP), along with various SIP
   extensions developed within the SIP for Instant Messaging and
   Presence Leveraging Extensions (SIMPLE) Working Group.

o  The Extensible Messaging and Presence Protocol (XMPP), along
   with various XMPP extensions developed by the IETF as well as by
   the XMPP Standards Foundation.

SIP has been focused primarily on media session negotiation (e.g., audio
and video), whereas XMPP has been focused primarily on messaging and
presence.  As a result, the technologies are mostly complementary.
However, there is also some overlap between SIP and XMPP, since there
are SIP extensions for messaging, presence, groupchat, file transfer,
etc., and there are XMPP extensions for multimedia session negotiation.
This overlap has practical implications, since some deployed services
use SIP for both media and messaging/presence, whereas other deployed
services use XMPP for both messaging/presence and media.  When such =

services wish to exchange information, they often need to translate =

their native protocol (either SIP or XMPP) to the other protocol (either =

XMPP or SIP).

Implementers needing to perform such protocol mappings have often worked
out their own heuristics for doing so.  Unfortunately, these heuristics
are not always consistent, which can lead to interoperability problems.

Objectives

To make it easier for implementers to enable interworking between
SIP-based systems and XMPP-based systems, several Internet-Drafts have
defined guidelines for protocol mapping between SIP and XMPP, starting
with draft-saintandre-xmpp-simple-00 in early 2004.  The current
documents are:

draft-saintandre-sip-xmpp-core
draft-saintandre-sip-xmpp-presence
draft-saintandre-sip-xmpp-im
draft-saintandre-sip-xmpp-chat
draft-saintandre-sip-xmpp-groupchat
draft-saintandre-sip-xmpp-media

These documents are fairly stable and the authors have received feedback
from a number of implementers over the years.  However, implementers do
not always know about these documents because they are Internet-Drafts
and sometimes they have become expired due to inactivity.  Thus it would =

be helpful to polish them off and publish them as RFCs.

It might also be helpful to at some point publish additional documents in

the same series, covering topics like capabilities discovery and file =

transfer.  However, any such work would require a recharter.

The group shall not be tasked with defining any new protocols, only with
specifying mappings between existing protocols that have been defined for
SIP and XMPP.

Deliverables

1. Address mapping and error handling
2. Presence mapping
3. Mapping for single instant messages
4. Mapping for one-to-one text chat sessions
5. Mapping for multi-user text chat sessions
6. Mapping for media signaling

All of the foregoing deliverables are standards track, since they are
subject to interoperability testing.

Milestones:
TBD