From stpeter@stpeter.im Thu Sep 5 18:12:39 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 92C5421E808A for ; Thu, 5 Sep 2013 18:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=-0.299, 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 lrofISUM8nyM for ; Thu, 5 Sep 2013 18:12:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8EADD21E8093 for ; Thu, 5 Sep 2013 18:12:32 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 26FC7415B2; Thu, 5 Sep 2013 19:16:41 -0600 (MDT) Message-ID: <52292BFD.7070207@stpeter.im> Date: Thu, 05 Sep 2013 19:12:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <521BDB79.9080809@stpeter.im> In-Reply-To: <521BDB79.9080809@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] stox-presence-03: a couple of comments 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, 06 Sep 2013 01:12:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/26/13 4:49 PM, Peter Saint-Andre wrote: > On 8/26/13 6:34 AM, Markus.Isomaki@nokia.com wrote: >> Hi, > > Hi Markus, thanks for the feedback. > >> I have a couple of comments on the presence-03 draft: >> >> * Some asymmetry between XMPP-to-SIP (3.2) and SIP-to-XMPP (3.3) >> directions >> >> - 3.2.1 explains the DNS operations an XMPP domain uses to >> determine that the foreign domain does not support XMPP but >> actually supports SIP/SIMPLE. Presumably something similar is >> needed in the reverse direction, but this is not explained in >> 3.3.1. - The case where the subscription is rejected is covered >> in 3.3.1 but not in 3.2.1. > > Good point. We'll add something about that. Actually, I think draft-ietf-stox-core already covers that: When an XMPP service receives an XMPP stanza whose 'to' address specifies or includes a domain other than the domain of the XMPP service, it needs to determine whether the destination domain offers an XMPP service or a SIP service. To do so, it performs one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in [RFC6120]. If the response returns a hostname, the service can attempt XMPP communication. If not, the service can attempt to locate a SIP service for that domain using the procedures specified in [RFC3263]. Similarly, when a SIP service receives a SIP message whose Request- URI specifies or includes a domain other than the domain of the SIP service, it needs to determine whether the destination domain offers a SIP service or an XMPP service. To do so, it uses the procedures specified in [RFC3263]. If that response returns a hostname, the service can attempt SIP communication. If not, the service can perform one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in [RFC6120]. IIRC, we planned to remove such text from all but the core document, since it applies to presence, im, chat, groupchat, media, etc. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKSv8AAoJEOoGpJErxa2phm0P/jdOQH+Zev5htJ4QJDA/U3bE LUO0yN4yXUpfoMXUTzWbwCDPx8kX566zRyhK1uqiOylUVA3hljOfWMc1Fm5mj0RS nFVUIV8E1sk8mWKvAjsctTuoCQ2Tlk9IfCVLnhP77XX7MoHY8bfU1v20UdwV8yGj AU92Bf6bJ/+LFPaZTIS3mxZHCPTTa91pItF0yQF0suwDUtIPJtV1Cz77R6zyqRQG 39AdFNUv0FdZ73rS3oeEeZHCcCZctiWdfXr1CRG79h706cfF08Lp3Z8sVi++4Nbp Yac6ypzkKmJRmaYVikV6lzkMYAg1muJ5SrBnSj54cRxz/2PYftuK3duvR3CaeCxk qx2f45vv2QL0bpZVU2JoINvTZtPB1pfm8PcdDBCbQ0iMkVhRjfy7CJgFbKHlDckW dhi5kKda2eBiWBcscKs+t33luUi8sKxMj+/1pjCL7gNM54oBKMY/n0XXupVEiikP YmFqnBP2LDW3dRIzpY+VdYMQGgS//omdIDPjjEyWBIvepZKrXQpAqKlBHYqEJxaE M0laUEvfkzfY1WOkUD7D1b1guiFHQ55i6BK/+KaHk7RibJbp5uqbvAhqY9OVUuqZ Zt/unJHBl7ONqhlPasbop9nlVRwTGfczuDBBWfiHkJSgjy+wztOcfSuuqMRNEDA8 pijKmqW3wwEIQ3237F34 =idjv -----END PGP SIGNATURE----- From internet-drafts@ietf.org Thu Sep 5 18:58:17 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 C70F021E81A4; Thu, 5 Sep 2013 18:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 Ki4dVW2MFzSq; Thu, 5 Sep 2013 18:58:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6873211E8212; Thu, 5 Sep 2013 18:58:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130906015817.10807.58690.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 18:58:17 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-presence-04.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, 06 Sep 2013 01:58:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Presence Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-presence-04.txt Pages : 24 Date : 2013-09-05 Abstract: This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-presence There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-presence-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-presence-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Thu Sep 5 19:29:03 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 D661B11E821E for ; Thu, 5 Sep 2013 19:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.035 X-Spam-Level: X-Spam-Status: No, score=-102.035 tagged_above=-999 required=5 tests=[AWL=-0.306, 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 vImi6ixIZkEB for ; Thu, 5 Sep 2013 19:28:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 99B5611E8218 for ; Thu, 5 Sep 2013 19:28:55 -0700 (PDT) Received: from sjc-vpn3-1040.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B3282415B2; Thu, 5 Sep 2013 20:33:03 -0600 (MDT) Message-ID: <52293DE2.6090309@stpeter.im> Date: Thu, 05 Sep 2013 20:28:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Olle E. Johansson" References: <521C15F8.4070201@stpeter.im> In-Reply-To: <521C15F8.4070201@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stox@ietf.org" Subject: Re: [Stox] review draft-ietf-stox-core 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, 06 Sep 2013 02:29:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/26/13 8:59 PM, Peter Saint-Andre wrote: > Hej Olle, thanks for the review. Thanks again. I have one follow-up comment inline. > On 8/22/13 2:10 AM, Olle E. Johansson wrote: >> I would also like to mention that Contacts can include display >> names, like "Olles superduperphone" or "Conference Room Jupiter >> Phone". I don't know if this can be translated into XMPP. > > XMPP doesn't have display names in addresses (as email and SIP > do), although those could be translated into a nickname / handle > using XEP-0172: > > http://xmpp.org/extensions/xep-0172.html > > So adding a note about that seems reasonable. I've looked into this further. The Contact header is specified on SIP INVITES, whereas the Nickname extension is specified on XMPP messages and presence. I don't think there's much if any overlap there, so it doesn't seem useful to specify a mapping in draft-ietf-stox-core. However, I'm open to further discussion on this matter. I've incoporated all the rest of your feedback and will submit a revised I-D now. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKT3hAAoJEOoGpJErxa2piycP/i7Rm9VjMYMsq3sPcfBCVSOT jItm2DhTjUnW2y73Pee6UFs/WvIn1gjDa6itfqw2B4OF8jaJxgSdT0VAfUERlrer OXuJ+utGm5sya4cIg4R1ZIykV/42dfaZ70QzvLtD4y+J73JZSebjhxDUoPos2xDd ExvXCSZJIOSXACPQtdoD7W4vCtC/aahFe7aCr2k6vloLlo2Y8G/OrM6OVeZSO+VR qgCzkoVKBtpwmIHBH6JtXhbFrGNPWjwzbwo//Q85lGMs8deIPjp29UlCj56bhugc gQ1KW6A20oAPmqrOIN0NiiHYLApadnZ8b6ZEX/TNgzkBs1jPT2PAVGTaWRPdUsTy HrS0JdfKdRV2qb9r7B1r+HLkSiF94IuxfNORcx/vgAANei/R1EhlKxLsWWMINOo3 4603gNZYAccPQCg+aUaExokDHDI4i3JieGZiwxusIMFxrqDLW/yNJh2dmT+yBwdI IYzA8Csni8PuTyUsaWKO3fgBXfdZFWf8b24QLFuzoLB6fORD1uXefLPfWRp8R4zh 1N6Wjkx7KIbc2HQfUkCGNEVKPheHmX42mvKbh2w4cOa4LsaJAoOZbvej+TbMUgTu sxvfjjmJm+IMiYe/t4oIC9xseBMRV5MSWIgEGSYdbmlFG8eIb0O+9wGQVEpP6hGF M3OSwMQuaqaE8w6omlzz =+e+7 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Thu Sep 5 19:39:25 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 8828D21E81A5; Thu, 5 Sep 2013 19:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.128 X-Spam-Level: X-Spam-Status: No, score=-102.128 tagged_above=-999 required=5 tests=[AWL=-0.398, 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 K+GfbI0yyEuQ; Thu, 5 Sep 2013 19:39:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 313DA11E812F; Thu, 5 Sep 2013 19:39:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130906023925.29142.82586.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 19:39:25 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-core-04.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, 06 Sep 2013 02:39:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Architecture,= Addresses, and Error Handling Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-core-04.txt Pages : 18 Date : 2013-09-05 Abstract: As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-core There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-core-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-core-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Sep 5 19:49:38 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 7747C21E81B3; Thu, 5 Sep 2013 19:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.126 X-Spam-Level: X-Spam-Status: No, score=-102.126 tagged_above=-999 required=5 tests=[AWL=-0.396, 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 g49iEoO3P+c3; Thu, 5 Sep 2013 19:49:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1511111E8155; Thu, 5 Sep 2013 19:49:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130906024937.14584.90912.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 19:49:37 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-im-02.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, 06 Sep 2013 02:49:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messa= ging Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-im-02.txt Pages : 11 Date : 2013-09-05 Abstract: This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-im-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-im-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Thu Sep 5 19:59:48 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 C21EC11E8220 for ; Thu, 5 Sep 2013 19:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 ETtN7E61U+f2 for ; Thu, 5 Sep 2013 19:59:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A1C5A11E81FB for ; Thu, 5 Sep 2013 19:59:35 -0700 (PDT) Received: from sjc-vpn3-1040.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 80DC9415B2; Thu, 5 Sep 2013 21:03:44 -0600 (MDT) Message-ID: <52294513.8080407@stpeter.im> Date: Thu, 05 Sep 2013 20:59:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "stox@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [Stox] current status 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, 06 Sep 2013 02:59:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, as far as I can tell I've addressed all feedback sent so far on the -core, -presence, and -im documents. I'll try to do the same for the -chat document by the end of next week. I'll also talk with Saúl about setting a schedule for the -groupchat document (perhaps also by the end of next week). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKUUTAAoJEOoGpJErxa2pyaQQAIQfLAoR2/DUKBXni7q1EUlT 2j+xIFz98hBvKvCtgKruj8/v3ld1AML4XN7HWBOQVfGnP9ynda/Mdv/mofmqUdZL ACyPK21W30dADMf+sCmz0k63dtIUUPhxJ859GpKDmFydPfrDGcx4ELz7UXMBfENb qNXgHNSUlikg89Eb3herB8NuIVmm3G1zRREI6QbwtVbySCEj7YGeaTYDsdIBIApC eg5mX6nUk+8OY5uxOBEJtLGU9osBAS3XuW6cFvw0RPdFeCVw1SlZrJzhnScTWMBe SMPhkQzwX3ZWz7CxapiXXoRc3doeRc2gc1ockoiclYVyeCjvCJv3LarxBDE/DDdV uSRuPgZFlfZDFCHcejlyD1QeW89hq9TuPphspNT9q0yunivZZuxhIePOd0o8Stvc 65pzu27oAaSxHZY8o7YsNsKEPLdixoTZYLrnE1Y+i7hFDkcviDA2IBiKU8JNRdtS WIlKUlN9ZGQg2Q3YKkWU7ukfZLM/MD2nngZlYkih43x108f8cf2P0NjBKLonSHu7 e6oCfnJ8Ld2xlDfTh4ZHtpFBjMBqwvTR9ipMc5ymDyNNe/4jM8TcPRd4NCO6OspB h+CIkWHSTVt33GNKkcYpRph7fjy3iWWXBKCj0wh7b36hvILCPVWtBrpBfPY/K5cv scrES7EtSBCFXNCxwgvb =6eKJ -----END PGP SIGNATURE----- From Markus.Isomaki@nokia.com Fri Sep 6 06:35:38 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 3A82811E8128 for ; Fri, 6 Sep 2013 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=-0.362, 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 02kWGCVuuFyN for ; Fri, 6 Sep 2013 06:35:34 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B1BA111E8140 for ; Fri, 6 Sep 2013 06:35:32 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.57]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r86DPhYB024806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 6 Sep 2013 16:25:45 +0300 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.88]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.03.0136.001; Fri, 6 Sep 2013 13:25:43 +0000 From: To: , Thread-Topic: [Stox] current status Thread-Index: AQHOqq0qg9qblya/s0KWirTx3JDOFJm4rF8A Date: Fri, 6 Sep 2013 13:25:43 +0000 Message-ID: References: <52294513.8080407@stpeter.im> In-Reply-To: <52294513.8080407@stpeter.im> 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: VgNFIFU9Hx+/nZJb9Kg7IulO1qCvm8En2VRIW+V9LtEkfnB+JBrLOQY7L/WBao7EFVKiEZvHemEz9atb8MiVcW8Gr5JjRlyAqXorWrEneXHHfMRItKJPBcYwZEUQgRv9PZZQGLxGwTo4m4InXalbdXDPk8g+PwDLCopuuJpQTZ6iWrr1+3IGFdgrh7nbKoLHo7LHFk3DQgyLyyTanLNATk5btvRRq4ZCcYLSHAtWgv4= x-originating-ip: [10.163.170.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [Stox] current status 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, 06 Sep 2013 13:35:38 -0000 Hi, There have been a fair number of comments on -core, -im and -presence since= the Berlin IETF. Please take a look at the new versions http://tools.ietf.org/id/draft-ietf-stox-core-04.txt http://tools.ietf.org/id/draft-ietf-stox-im-02.txt http://tools.ietf.org/id/draft-ietf-stox-presence-04.txt and see if your issues have been properly addressed, and/or whether you wan= t to still raise any new issues. If nothing specific comes up, the chairs will consider starting WG LC on th= ese documents in the near future.=20 One thing that I wonder about -core is whether it is a good idea to stabili= ze or last call it yet at this point, since there have been some issues rai= sed about -media that might have impact to -core, such as dealing with SIP = side forking or loop detection. So is it better to wait with -core until -m= edia is more stable? But let's move forward with -im and -presence unless there are issues left.= =20 Markus=20 > -----Original Message----- > From: stox-bounces@ietf.org [mailto:stox-bounces@ietf.org] On Behalf Of > ext Peter Saint-Andre > Sent: 06 September, 2013 06:00 > To: stox@ietf.org > Subject: [Stox] current status >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Folks, as far as I can tell I've addressed all feedback sent so far on th= e -core, - > presence, and -im documents. I'll try to do the same for the -chat docume= nt > by the end of next week. I'll also talk with Sa=FAl about setting a sched= ule for > the -groupchat document (perhaps also by the end of next week). >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJSKUUTAAoJEOoGpJErxa2pyaQQAIQfLAoR2/DUKBXni7q1E > UlT > 2j+xIFz98hBvKvCtgKruj8/v3ld1AML4XN7HWBOQVfGnP9ynda/Mdv/mofmqU > dZL > ACyPK21W30dADMf+sCmz0k63dtIUUPhxJ859GpKDmFydPfrDGcx4ELz7UXMB > fENb > qNXgHNSUlikg89Eb3herB8NuIVmm3G1zRREI6QbwtVbySCEj7YGeaTYDsdIBIA > pC > eg5mX6nUk+8OY5uxOBEJtLGU9osBAS3XuW6cFvw0RPdFeCVw1SlZrJzhnScT > WMBe > SMPhkQzwX3ZWz7CxapiXXoRc3doeRc2gc1ockoiclYVyeCjvCJv3LarxBDE/DDdV > uSRuPgZFlfZDFCHcejlyD1QeW89hq9TuPphspNT9q0yunivZZuxhIePOd0o8Stvc > 65pzu27oAaSxHZY8o7YsNsKEPLdixoTZYLrnE1Y+i7hFDkcviDA2IBiKU8JNRdtS > WIlKUlN9ZGQg2Q3YKkWU7ukfZLM/MD2nngZlYkih43x108f8cf2P0NjBKLonSHu > 7 > e6oCfnJ8Ld2xlDfTh4ZHtpFBjMBqwvTR9ipMc5ymDyNNe/4jM8TcPRd4NCO6O > spB > h+CIkWHSTVt33GNKkcYpRph7fjy3iWWXBKCj0wh7b36hvILCPVWtBrpBfPY/K5 > cv > scrES7EtSBCFXNCxwgvb > =3D6eKJ > -----END PGP SIGNATURE----- > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From Markus.Isomaki@nokia.com Fri Sep 6 06:36: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 C434B11E82AF for ; Fri, 6 Sep 2013 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.74 X-Spam-Level: X-Spam-Status: No, score=-5.74 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 gQkgz2pyd8mD for ; Fri, 6 Sep 2013 06:36:49 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id EAAB711E8140 for ; Fri, 6 Sep 2013 06:36:48 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.25]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r86DQaag000323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 6 Sep 2013 16:26:37 +0300 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.88]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.03.0136.001; Fri, 6 Sep 2013 13:26:36 +0000 From: To: Thread-Topic: [Stox] stox-presence-03: a couple of comments Thread-Index: Ac6iVdrqwMqQ2/nWQYe3VUtiNNDXRQAWKqyAAfvojoAAGJScEA== Date: Fri, 6 Sep 2013 13:26:35 +0000 Message-ID: References: <521BDB79.9080809@stpeter.im> <52292BFD.7070207@stpeter.im> In-Reply-To: <52292BFD.7070207@stpeter.im> 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: VgNFIFU9Hx+/nZJb9Kg7Ir8Ot/165xVANZyMNIPsIlB7RfrfOlsjCLjm8u8yndlD0yTGv6YewTS0sczzvEMCmLyQyMhZObMacVBraKZfJUZEuIjHAwsp2duOIgHtVkwwvNdArAW7Cg1BrHW4LwAHKRn94RoYyEsMqkwg8tTY2m4YkqVQEtLBW8amyOq3fAPGnZQxUqjGctZ1BRfkwFjk/KbNV2R0HAQTKM9OTWBv+tU/Xt05c5OQDtWyoi/94C8AP0puYv6fHAS/T9+ojnXrNQ== x-originating-ip: [10.163.170.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Cc: stox@ietf.org Subject: Re: [Stox] stox-presence-03: a couple of comments 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, 06 Sep 2013 13:36:53 -0000 Hi, OK. I do recall too that the intent was to put all DNS handling to -core an= d that has now happened. Thanks, it makes things clearer as there is less o= verlap between the documents. Markus=20 > -----Original Message----- > From: ext Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: 06 September, 2013 04:12 > To: Isomaki Markus (Nokia-CIC/Espoo) > Cc: stox@ietf.org > Subject: Re: [Stox] stox-presence-03: a couple of comments >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 8/26/13 4:49 PM, Peter Saint-Andre wrote: > > On 8/26/13 6:34 AM, Markus.Isomaki@nokia.com wrote: > >> Hi, > > > > Hi Markus, thanks for the feedback. > > > >> I have a couple of comments on the presence-03 draft: > >> > >> * Some asymmetry between XMPP-to-SIP (3.2) and SIP-to-XMPP (3.3) > >> directions > >> > >> - 3.2.1 explains the DNS operations an XMPP domain uses to determine > >> that the foreign domain does not support XMPP but actually supports > >> SIP/SIMPLE. Presumably something similar is needed in the reverse > >> direction, but this is not explained in 3.3.1. - The case where the > >> subscription is rejected is covered in 3.3.1 but not in 3.2.1. > > > > Good point. We'll add something about that. >=20 > Actually, I think draft-ietf-stox-core already covers that: >=20 > When an XMPP service receives an XMPP stanza whose 'to' address > specifies or includes a domain other than the domain of the XMPP > service, it needs to determine whether the destination domain offers > an XMPP service or a SIP service. To do so, it performs one or more > DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in > [RFC6120]. If the response returns a hostname, the service can > attempt XMPP communication. If not, the service can attempt to > locate a SIP service for that domain using the procedures specified > in [RFC3263]. >=20 > Similarly, when a SIP service receives a SIP message whose Request- > URI specifies or includes a domain other than the domain of the SIP > service, it needs to determine whether the destination domain offers > a SIP service or an XMPP service. To do so, it uses the procedures > specified in [RFC3263]. If that response returns a hostname, the > service can attempt SIP communication. If not, the service can > perform one or more DNS SRV lookups [RFC2782] for "_xmpp-server" > records as specified in [RFC6120]. >=20 > IIRC, we planned to remove such text from all but the core document, sinc= e > it applies to presence, im, chat, groupchat, media, etc. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJSKSv8AAoJEOoGpJErxa2phm0P/jdOQH+Zev5htJ4QJDA/U3 > bE > LUO0yN4yXUpfoMXUTzWbwCDPx8kX566zRyhK1uqiOylUVA3hljOfWMc1Fm5 > mj0RS > nFVUIV8E1sk8mWKvAjsctTuoCQ2Tlk9IfCVLnhP77XX7MoHY8bfU1v20UdwV8y > Gj > AU92Bf6bJ/+LFPaZTIS3mxZHCPTTa91pItF0yQF0suwDUtIPJtV1Cz77R6zyqRQG > 39AdFNUv0FdZ73rS3oeEeZHCcCZctiWdfXr1CRG79h706cfF08Lp3Z8sVi++4Nbp > Yac6ypzkKmJRmaYVikV6lzkMYAg1muJ5SrBnSj54cRxz/2PYftuK3duvR3CaeCxk > qx2f45vv2QL0bpZVU2JoINvTZtPB1pfm8PcdDBCbQ0iMkVhRjfy7CJgFbKHlDck > W > dhi5kKda2eBiWBcscKs+t33luUi8sKxMj+/1pjCL7gNM54oBKMY/n0XXupVEiikP > YmFqnBP2LDW3dRIzpY+VdYMQGgS//omdIDPjjEyWBIvepZKrXQpAqKlBHYqEJ > xaE > M0laUEvfkzfY1WOkUD7D1b1guiFHQ55i6BK/+KaHk7RibJbp5uqbvAhqY9OVUu > qZ > Zt/unJHBl7ONqhlPasbop9nlVRwTGfczuDBBWfiHkJSgjy+wztOcfSuuqMRNEDA > 8 > pijKmqW3wwEIQ3237F34 > =3Didjv > -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Sep 6 08:29:08 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 8B4E111E80EC for ; Fri, 6 Sep 2013 08:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.029 X-Spam-Level: X-Spam-Status: No, score=-102.029 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 LQCWoCalU9Q6 for ; Fri, 6 Sep 2013 08:29:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3066F21F9B80 for ; Fri, 6 Sep 2013 08:29:04 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 81DCC414D0; Fri, 6 Sep 2013 09:33:12 -0600 (MDT) Message-ID: <5229F4BA.8020706@stpeter.im> Date: Fri, 06 Sep 2013 09:28:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <521BDB79.9080809@stpeter.im> <52292BFD.7070207@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] stox-presence-03: a couple of comments 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, 06 Sep 2013 15:29:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/6/13 7:26 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > OK. I do recall too that the intent was to put all DNS handling to > -core and that has now happened. Thanks, it makes things clearer as > there is less overlap between the documents. I just realized that last night I pushed out a corrected version of the -im spec with DNS text still in there. I'll submit a revised I-D. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKfS6AAoJEOoGpJErxa2pxj0QAIkVDC3hrnD2hdIVSr0380Um GcGNK9Nj6t1OU/wnIi/86eTqcMPu74K06hemGuiQoWCNoxni+I3uSAVHo37Jcd+w xWoyJ7De0F5gH6MWcZ913JoMzPkxWf/bSDZisgkIcieOTz/LaPpCJlmH3xc1PD55 KUKQ7MBtXoAo0wjUfMkYhfMfojqBYWUlnfqSshlht/91uwm8bMcihCJh8imtwDfj zG0MfdFIMJ2mEQFitBF3CeK8zAZRIdAop70oAmlTdHtjv9eN8WmmAxNF0nqKsT2E 4IqGFn9BpNnaJvefJ8rJEi0R+blGqr/7DTpDRFmwwLFn4JLoZw5c3ukYKfeuaMIJ MC+uwzom1hxJXMy9Qd1Y0wGJuLZq6CdnAeDCrxcNxFqNbPEpwPdpYnH4y0rTIaBn QhBVxNrHNsSvbWtygd+a/Xdc2dV6vWMXpp4rd8o112xrYEvzvu6E71Fn0Ck2Hs9C 2Khn7DvhV+JoXIXzn0RcYdCdGfqiXiDQeTdhzhyCCeJMWh/FObX0e+mGuotYq22r MM0uFnRKHTv2e0cqcSqe5kX8F7jEyLD8DEQVy8yuaUhYIxW50u1+vq9HBk+2Q0Zf U4e4iN9C7QynF+EIat0P/S4zS2IVbVN9Mf26VXAeAxFC9L5lORbC+uQcwMB8jfSQ 1pvXaCprKRd+J6a5pGz/ =qyTS -----END PGP SIGNATURE----- From saul@ag-projects.com Fri Sep 6 09:17: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 DD90711E82B1 for ; Fri, 6 Sep 2013 09:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[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 dMcN1BzfTSfG for ; Fri, 6 Sep 2013 09:16:56 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E587511E82D0 for ; Fri, 6 Sep 2013 09:16:53 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 745BEB0180; Fri, 6 Sep 2013 18:16:48 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 939F4B0180; Fri, 6 Sep 2013 18:16:35 +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: Date: Fri, 6 Sep 2013 18:16:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EFEDB10-B1D2-4D58-80A1-BDC24BF1EA8E@ag-projects.com> References: <52294513.8080407@stpeter.im> To: X-Mailer: Apple Mail (2.1085) Cc: stox@ietf.org, stpeter@stpeter.im Subject: Re: [Stox] current status 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, 06 Sep 2013 16:17:01 -0000 On Sep 6, 2013, at 3:25 PM, = wrote: > Hi, >=20 > There have been a fair number of comments on -core, -im and -presence = since the Berlin IETF. Please take a look at the new versions > http://tools.ietf.org/id/draft-ietf-stox-core-04.txt > http://tools.ietf.org/id/draft-ietf-stox-im-02.txt > http://tools.ietf.org/id/draft-ietf-stox-presence-04.txt > and see if your issues have been properly addressed, and/or whether = you want to still raise any new issues. >=20 > If nothing specific comes up, the chairs will consider starting WG LC = on these documents in the near future.=20 >=20 > One thing that I wonder about -core is whether it is a good idea to = stabilize or last call it yet at this point, since there have been some = issues raised about -media that might have impact to -core, such as = dealing with SIP side forking or loop detection. So is it better to wait = with -core until -media is more stable? >=20 At some point we agreed that those issues would be handled in -media, = because in other cases (chat, presence, im) the gateway is itself the = endpoint and handles all the "media", so those didn't seem to apply. -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Fri Sep 6 09:36: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 7154811E81A5 for ; Fri, 6 Sep 2013 09:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.868 X-Spam-Level: X-Spam-Status: No, score=-101.868 tagged_above=-999 required=5 tests=[AWL=-0.439, 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 Gawd384BqHNE for ; Fri, 6 Sep 2013 09:35:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE2121F9D21 for ; Fri, 6 Sep 2013 09:35:57 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C6D4414D0; Fri, 6 Sep 2013 10:40:09 -0600 (MDT) Message-ID: <522A046A.3050105@stpeter.im> Date: Fri, 06 Sep 2013 10:35:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <52294513.8080407@stpeter.im> <8EFEDB10-B1D2-4D58-80A1-BDC24BF1EA8E@ag-projects.com> In-Reply-To: <8EFEDB10-B1D2-4D58-80A1-BDC24BF1EA8E@ag-projects.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, "" Subject: Re: [Stox] current status 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, 06 Sep 2013 16:36:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/6/13 10:16 AM, Saúl Ibarra Corretgé wrote: > > On Sep 6, 2013, at 3:25 PM, > wrote: > >> Hi, >> >> There have been a fair number of comments on -core, -im and >> -presence since the Berlin IETF. Please take a look at the new >> versions http://tools.ietf.org/id/draft-ietf-stox-core-04.txt >> http://tools.ietf.org/id/draft-ietf-stox-im-02.txt >> http://tools.ietf.org/id/draft-ietf-stox-presence-04.txt and see >> if your issues have been properly addressed, and/or whether you >> want to still raise any new issues. >> >> If nothing specific comes up, the chairs will consider starting >> WG LC on these documents in the near future. >> >> One thing that I wonder about -core is whether it is a good idea >> to stabilize or last call it yet at this point, since there have >> been some issues raised about -media that might have impact to >> -core, such as dealing with SIP side forking or loop detection. >> So is it better to wait with -core until -media is more stable? >> > > At some point we agreed that those issues would be handled in > -media, because in other cases (chat, presence, im) the gateway is > itself the endpoint and handles all the "media", so those didn't > seem to apply. That is my recollection, too. Thus I'd be in favor of stabilizing the -core spec, and hanlding the forking issues in the -media spec. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKgRqAAoJEOoGpJErxa2p4GUP/2bzG8+WbRPcn0JpREhws+T5 m3WBrq0OoJryDzxaA2HmBq15TBawWzsVce5dp4oOY73G9HsPxCyDHrPYiN/SBxhK VTSrIid3GCd9s0uTNEgPIwcQ6DFJy5f3nxdo2YWgmm+ncJ7hvuSXSGoDCammAyX0 nGci5VPoesbj+LZaebSPgFDHX7jtVElqloR2wpHYxmTh+P34sXGuKneQH43wYdM7 seOMpsD8yyfwRUqvhglUf4H46maQvYENTDCFsk5XjbcWoJLK52+N+Pwkw9ofr6DZ no/j5xPLY1mr3FTE0MTgMn0Nq3YSCD4M3jLrsjjdudvlQvLcItWIK4x9OO8JaaFx 5+AWtrCjn6yu/NKLgY8M5zhju51T8/srn1sBzxCQNkj5dNykbhp2W/Qo2Y+eahF1 cZEOhmTTALEpbqvtGxZBg/p9kSugwk3q4oAlP875JlBS+VLiiFXc6MIeXqWHS9yf X2KXJj3xNrh1Esp/Z2FG/W5+uz+e9tT2IlevhKcNozFs+gyJHeD/KwZZ3Oc3/Hqj 4RkFcLW+8iXFqH1EozpYFcr7WOhNRlh2KtbBON/w9o7481i35HRG8cR0TtFZ//By pqTdVWZhwYH3PR9B4+6cY53Lk5aWoL5RGX5DYMPluHuJGcPW99VORRE8RRo4eepC nTGO/i5/5W8SC+EE3hO7 =6RTC -----END PGP SIGNATURE----- From mary.ietf.barnes@gmail.com Fri Sep 6 09:42:35 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 28B2C11E81A0 for ; Fri, 6 Sep 2013 09:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PTLL+qa8WSBF for ; Fri, 6 Sep 2013 09:42:34 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29311E8199 for ; Fri, 6 Sep 2013 09:42:34 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id hu16so596347qab.14 for ; Fri, 06 Sep 2013 09:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HLziuEjQZV1wF0n09aXXvyuycb8L+CIcjM8Yz/co1Gs=; b=gNHYMcxLhPkOXyj6uUJDHlrBdKWMeBi+oXyEXk+P/zMuAgoqb81y+mPKIvQDLpz5qs ns9dCaG0dg0n/662wFb/ibHHSrdVXxamVGQTuqD10ZQjGK5O6hCi5kIiljoqQ03EuivP P32V1P3Wyda7GrzKcLlzvCdPgQA4u+9Y1ZWX3/aO3TrVOlHofSxMZMIr5iXpXMoLqaYj 3S6UH+IApXnpq1Tlpkd15IbY8AbzBEQuVMoCAiWwHrAAESTIrSptQ7Z+SIK99cOiFdrY J4Pw2ycg0ExwUbz3WjQ9PXGcDM/EfMLKcHe+uWVzxcUGTmsypzmihApaIdh2imYIKfQS xbDw== MIME-Version: 1.0 X-Received: by 10.224.120.1 with SMTP id b1mr2921462qar.96.1378485753631; Fri, 06 Sep 2013 09:42:33 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Fri, 6 Sep 2013 09:42:33 -0700 (PDT) In-Reply-To: <522A046A.3050105@stpeter.im> References: <52294513.8080407@stpeter.im> <8EFEDB10-B1D2-4D58-80A1-BDC24BF1EA8E@ag-projects.com> <522A046A.3050105@stpeter.im> Date: Fri, 6 Sep 2013 11:42:33 -0500 Message-ID: From: Mary Barnes To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a11c2d6e6ac5dfb04e5b9b9e0 Cc: stox@ietf.org, =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , "" Subject: Re: [Stox] current status 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, 06 Sep 2013 16:42:35 -0000 --001a11c2d6e6ac5dfb04e5b9b9e0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 6, 2013 at 11:35 AM, Peter Saint-Andre wrot= e: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/6/13 10:16 AM, Sa=FAl Ibarra Corretg=E9 wrote: > > > > On Sep 6, 2013, at 3:25 PM, > > wrote: > > > >> Hi, > >> > >> There have been a fair number of comments on -core, -im and > >> -presence since the Berlin IETF. Please take a look at the new > >> versions http://tools.ietf.org/id/draft-ietf-stox-core-04.txt > >> http://tools.ietf.org/id/draft-ietf-stox-im-02.txt > >> http://tools.ietf.org/id/draft-ietf-stox-presence-04.txt and see > >> if your issues have been properly addressed, and/or whether you > >> want to still raise any new issues. > >> > >> If nothing specific comes up, the chairs will consider starting > >> WG LC on these documents in the near future. > >> > >> One thing that I wonder about -core is whether it is a good idea > >> to stabilize or last call it yet at this point, since there have > >> been some issues raised about -media that might have impact to > >> -core, such as dealing with SIP side forking or loop detection. > >> So is it better to wait with -core until -media is more stable? > >> > > > > At some point we agreed that those issues would be handled in > > -media, because in other cases (chat, presence, im) the gateway is > > itself the endpoint and handles all the "media", so those didn't > > seem to apply. > > That is my recollection, too. > [MB] That was also what I thought when I reviewed -core. [/MB] Thus I'd be in favor of stabilizing the -core spec, and hanlding the > forking issues in the -media spec. > [MB] I agree. [/MB] > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSKgRqAAoJEOoGpJErxa2p4GUP/2bzG8+WbRPcn0JpREhws+T5 > m3WBrq0OoJryDzxaA2HmBq15TBawWzsVce5dp4oOY73G9HsPxCyDHrPYiN/SBxhK > VTSrIid3GCd9s0uTNEgPIwcQ6DFJy5f3nxdo2YWgmm+ncJ7hvuSXSGoDCammAyX0 > nGci5VPoesbj+LZaebSPgFDHX7jtVElqloR2wpHYxmTh+P34sXGuKneQH43wYdM7 > seOMpsD8yyfwRUqvhglUf4H46maQvYENTDCFsk5XjbcWoJLK52+N+Pwkw9ofr6DZ > no/j5xPLY1mr3FTE0MTgMn0Nq3YSCD4M3jLrsjjdudvlQvLcItWIK4x9OO8JaaFx > 5+AWtrCjn6yu/NKLgY8M5zhju51T8/srn1sBzxCQNkj5dNykbhp2W/Qo2Y+eahF1 > cZEOhmTTALEpbqvtGxZBg/p9kSugwk3q4oAlP875JlBS+VLiiFXc6MIeXqWHS9yf > X2KXJj3xNrh1Esp/Z2FG/W5+uz+e9tT2IlevhKcNozFs+gyJHeD/KwZZ3Oc3/Hqj > 4RkFcLW+8iXFqH1EozpYFcr7WOhNRlh2KtbBON/w9o7481i35HRG8cR0TtFZ//By > pqTdVWZhwYH3PR9B4+6cY53Lk5aWoL5RGX5DYMPluHuJGcPW99VORRE8RRo4eepC > nTGO/i5/5W8SC+EE3hO7 > =3D6RTC > -----END PGP SIGNATURE----- > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > --001a11c2d6e6ac5dfb04e5b9b9e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Sep 6, 2013 at 11:35 AM, Peter Saint-Andre <stpeter@stpet= er.im> wrote:
-----BEGIN PGP SIGNED MESS= AGE-----
Hash: SHA1

On 9/6/13 10:16 AM, Sa=FAl Ibarra Corretg=E9 wrote:=
>
> On Sep 6, 2013, at 3:25 PM, <Markus.Isomaki@nokia.com>
> <Markus.Isomaki@nokia.c= om> wrote:
>
>> Hi,
>>
>> There have been a fair number of comments on -core, -im and
>> -presence since the Berlin IETF. Please take a look at the new
>> versions http://tools.ietf.org/id/draft-ietf-stox-core-04.= txt
>> http://tools.ietf.org/id/draft-ietf-stox-im-02.txt
>> http://tools.ietf.org/id/draft-ietf-stox-presence-04.t= xt and see
>> if your issues have been properly addressed, and/or whether you >> want to still raise any new issues.
>>
>> If nothing specific comes up, the chairs will consider starting >> WG LC on these documents in the near future.
>>
>> One thing that I wonder about -core is whether it is a good idea >> to stabilize or last call it yet at this point, since there have >> been some issues raised about -media that might have impact to
>> -core, such as dealing with SIP side forking or loop detection. >> So is it better to wait with -core until -media is more stable? >>
>
> At some point we agreed that those issues would be handled in
> -media, because in other cases (chat, presence, im) the gateway is
> itself the endpoint and handles all the "media", so those di= dn't
> seem to apply.

That is my recollection, too.
=A0[MB] That was a= lso what I thought when I reviewed -core. [/MB]

Thus I'd be in favor of stabilizing the -core spec, and hanlding the forking issues in the -media spec.
[MB] I agree. [/MB]=

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http:= //gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSKgRqAAoJEOoGpJErxa2p4GUP/2bzG8+WbRPcn0JpREhws+T5
m3WBrq0OoJryDzxaA2HmBq15TBawWzsVce5dp4oOY73G9HsPxCyDHrPYiN/SBxhK
VTSrIid3GCd9s0uTNEgPIwcQ6DFJy5f3nxdo2YWgmm+ncJ7hvuSXSGoDCammAyX0
nGci5VPoesbj+LZaebSPgFDHX7jtVElqloR2wpHYxmTh+P34sXGuKneQH43wYdM7
seOMpsD8yyfwRUqvhglUf4H46maQvYENTDCFsk5XjbcWoJLK52+N+Pwkw9ofr6DZ
no/j5xPLY1mr3FTE0MTgMn0Nq3YSCD4M3jLrsjjdudvlQvLcItWIK4x9OO8JaaFx
5+AWtrCjn6yu/NKLgY8M5zhju51T8/srn1sBzxCQNkj5dNykbhp2W/Qo2Y+eahF1
cZEOhmTTALEpbqvtGxZBg/p9kSugwk3q4oAlP875JlBS+VLiiFXc6MIeXqWHS9yf
X2KXJj3xNrh1Esp/Z2FG/W5+uz+e9tT2IlevhKcNozFs+gyJHeD/KwZZ3Oc3/Hqj
4RkFcLW+8iXFqH1EozpYFcr7WOhNRlh2KtbBON/w9o7481i35HRG8cR0TtFZ//By
pqTdVWZhwYH3PR9B4+6cY53Lk5aWoL5RGX5DYMPluHuJGcPW99VORRE8RRo4eepC
nTGO/i5/5W8SC+EE3hO7
=3D6RTC
-----END PGP SIGNATURE-----
___________________________________= ____________
stox mailing list
stox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stox

--001a11c2d6e6ac5dfb04e5b9b9e0-- From internet-drafts@ietf.org Fri Sep 6 11:23:59 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 0199C21F9BB1; Fri, 6 Sep 2013 11:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=-0.395, 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 FeMqQwhPdoP2; Fri, 6 Sep 2013 11:23:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4190621F8F32; Fri, 6 Sep 2013 11:23:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130906182358.10966.12458.idtracker@ietfa.amsl.com> Date: Fri, 06 Sep 2013 11:23:58 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-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, 06 Sep 2013 18:23:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messa= ging Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-im-03.txt Pages : 10 Date : 2013-09-06 Abstract: This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-im-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-im-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ag@ag-projects.com Fri Sep 13 05:42:38 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 2B87E11E8202 for ; Fri, 13 Sep 2013 05:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 MPZyPxYejjVj for ; Fri, 13 Sep 2013 05:42:33 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5C21F9E43 for ; Fri, 13 Sep 2013 05:42:32 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id C027FB35DE; Fri, 13 Sep 2013 14:42:31 +0200 (CEST) Received: from [192.168.1.103] (r186-51-103-154.static.adinet.com.uy [186.51.103.154]) by mail.sipthor.net (Postfix) with ESMTPSA id 126D5B00EF for ; Fri, 13 Sep 2013 14:42:28 +0200 (CEST) From: Adrian Georgescu Content-Type: multipart/signed; boundary="Apple-Mail=_97D3C137-C35F-451F-85E9-11258DBF96A6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <9DFE605A-134A-4C41-B903-8C9955E61396@ag-projects.com> Date: Fri, 13 Sep 2013 09:42:28 -0300 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Stox] OTR encryption between SIP and XMPP 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, 13 Sep 2013 12:42:38 -0000 --Apple-Mail=_97D3C137-C35F-451F-85E9-11258DBF96A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I am not sure if this is relevant to any of the deliverables of the = working group, but just in case it is, we were able to create end-to-end = encryption for chat sessions using OTR protocol = http://www.cypherpunks.ca/otr/ between a SIP client using MSRP (that is = Blink) and XMPP client (Jitsi). The implementation is described here: http://projects.ag-projects.com/projects/blinkc/wiki/OTR Regards, Adrian --Apple-Mail=_97D3C137-C35F-451F-85E9-11258DBF96A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIzCDQACgkQBWdpqVEZtGdtoQCgwJFGEAKptcCv8O+FAssJHL9g mL4An28nvkR9qRd6VgvLp/byvsbga8Lz =Unah -----END PGP SIGNATURE----- --Apple-Mail=_97D3C137-C35F-451F-85E9-11258DBF96A6-- From Markus.Isomaki@nokia.com Wed Sep 18 04:17:43 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 C635811E8212 for ; Wed, 18 Sep 2013 04:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TiXg1+tX-A-W for ; Wed, 18 Sep 2013 04:17:33 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 48E6011E8200 for ; Wed, 18 Sep 2013 04:17:29 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.56]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8IBG83B025087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 18 Sep 2013 14:16:14 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.213]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.03.0136.001; Wed, 18 Sep 2013 11:16:13 +0000 From: To: , Thread-Topic: [Stox] current status Thread-Index: AQHOqq0qg9qblya/s0KWirTx3JDOFJm4rF8AgAA3LwCAAAVnAIAAAduAgBJ+KvA= Date: Wed, 18 Sep 2013 11:16:12 +0000 Message-ID: References: <52294513.8080407@stpeter.im> <8EFEDB10-B1D2-4D58-80A1-BDC24BF1EA8E@ag-projects.com> <522A046A.3050105@stpeter.im> In-Reply-To: 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: VgNFIFU9Hx+/nZJb9Kg7IulO1qCvm8En2VRIW+V9LtEkfnB+JBrLOQY7L/WBao7EFVKiEZvHemEz9atb8MiVcW8Gr5JjRlyAqXorWrEneXHHfMRItKJPBcYwZEUQgRv9PZZQGLxGwTo4m4InXalbdXDPk8g+PwDLCopuuJpQTZ6iWrr1+3IGFdgrh7nbKoLHo7LHFk3DQgyLyyTanLNATk5btvRRq4ZCcYLSHAtWgv4= x-originating-ip: [10.236.6.11] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A0B3F90008AM1MPN1043mg_" MIME-Version: 1.0 X-Nokia-AV: Clean Cc: stox@ietf.org, saul@ag-projects.com Subject: Re: [Stox] current status 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: Wed, 18 Sep 2013 11:17:44 -0000 --_000_E44893DD4E290745BB608EB23FDDB7620A0B3F90008AM1MPN1043mg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, There have been no further comments on this, so I think we can declare it d= ecided that we won't expand the scope of -core with topics like forking, bu= t leave that to the -media to handle. My proposed plan for the next steps of the WG is: - Before Vancouver: Issue WG Last Calls on -core, -im, and -presen= ce and see if they indeed are mature enough to be delivered forward. - For Vancouver: Get updated versions of especially -media, and po= ssibly -chat and -groupchat, and collect the open issues about them. - In Vancouver: Discuss the open issues about -media, and if neede= d -chat and -groupchat. - After Vancouver: Depending on the maturity and issues raised, sc= hedule WG Last Calls for the remaining deliverables. Let the chairs (Yana and me) know if you have issues with this plan or even= better, suggestions how to improve it. Markus From: ext Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 06 September, 2013 19:43 To: Peter Saint-Andre Cc: Sa=FAl Ibarra Corretg=E9; stox@ietf.org; Isomaki Markus (Nokia-CIC/Espo= o) Subject: Re: [Stox] current status On Fri, Sep 6, 2013 at 11:35 AM, Peter Saint-Andre > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/6/13 10:16 AM, Sa=FAl Ibarra Corretg=E9 wrote: > > On Sep 6, 2013, at 3:25 PM, > > > wrote: > >> Hi, >> >> There have been a fair number of comments on -core, -im and >> -presence since the Berlin IETF. Please take a look at the new >> versions http://tools.ietf.org/id/draft-ietf-stox-core-04.txt >> http://tools.ietf.org/id/draft-ietf-stox-im-02.txt >> http://tools.ietf.org/id/draft-ietf-stox-presence-04.txt and see >> if your issues have been properly addressed, and/or whether you >> want to still raise any new issues. >> >> If nothing specific comes up, the chairs will consider starting >> WG LC on these documents in the near future. >> >> One thing that I wonder about -core is whether it is a good idea >> to stabilize or last call it yet at this point, since there have >> been some issues raised about -media that might have impact to >> -core, such as dealing with SIP side forking or loop detection. >> So is it better to wait with -core until -media is more stable? >> > > At some point we agreed that those issues would be handled in > -media, because in other cases (chat, presence, im) the gateway is > itself the endpoint and handles all the "media", so those didn't > seem to apply. That is my recollection, too. [MB] That was also what I thought when I reviewed -core. [/MB] Thus I'd be in favor of stabilizing the -core spec, and hanlding the forking issues in the -media spec. [MB] I agree. [/MB] Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKgRqAAoJEOoGpJErxa2p4GUP/2bzG8+WbRPcn0JpREhws+T5 m3WBrq0OoJryDzxaA2HmBq15TBawWzsVce5dp4oOY73G9HsPxCyDHrPYiN/SBxhK VTSrIid3GCd9s0uTNEgPIwcQ6DFJy5f3nxdo2YWgmm+ncJ7hvuSXSGoDCammAyX0 nGci5VPoesbj+LZaebSPgFDHX7jtVElqloR2wpHYxmTh+P34sXGuKneQH43wYdM7 seOMpsD8yyfwRUqvhglUf4H46maQvYENTDCFsk5XjbcWoJLK52+N+Pwkw9ofr6DZ no/j5xPLY1mr3FTE0MTgMn0Nq3YSCD4M3jLrsjjdudvlQvLcItWIK4x9OO8JaaFx 5+AWtrCjn6yu/NKLgY8M5zhju51T8/srn1sBzxCQNkj5dNykbhp2W/Qo2Y+eahF1 cZEOhmTTALEpbqvtGxZBg/p9kSugwk3q4oAlP875JlBS+VLiiFXc6MIeXqWHS9yf X2KXJj3xNrh1Esp/Z2FG/W5+uz+e9tT2IlevhKcNozFs+gyJHeD/KwZZ3Oc3/Hqj 4RkFcLW+8iXFqH1EozpYFcr7WOhNRlh2KtbBON/w9o7481i35HRG8cR0TtFZ//By pqTdVWZhwYH3PR9B4+6cY53Lk5aWoL5RGX5DYMPluHuJGcPW99VORRE8RRo4eepC nTGO/i5/5W8SC+EE3hO7 =3D6RTC -----END PGP SIGNATURE----- _______________________________________________ stox mailing list stox@ietf.org https://www.ietf.org/mailman/listinfo/stox --_000_E44893DD4E290745BB608EB23FDDB7620A0B3F90008AM1MPN1043mg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

There have been no furthe= r comments on this, so I think we can declare it decided that we won’= t expand the scope of –core with topics like forking, but leave that to the –media to handle.

 <= /p>

My proposed plan for the = next steps of the WG is:

- = ;         Before Vancouver:= Issue WG Last Calls on –core, -im, and –presence and see if th= ey indeed are mature enough to be delivered forward.

- = ;         For Vancouver: Ge= t updated versions of especially –media, and possibly –chat and= –groupchat, and collect the open issues about them.

- = ;         In Vancouver: Dis= cuss the open issues about –media, and if needed –chat and R= 11;groupchat.

- = ;         After Vancouver: = Depending on the maturity and issues raised, schedule WG Last Calls for the= remaining deliverables.

 <= /p>

Let the chairs (Yana and = me) know if you have issues with this plan or even better, suggestions how = to improve it.

 <= /p>

Markus<= /p>

 <= /p>

 <= /p>

From: ext Mary Barnes [mailto:mary.ietf.barnes@gmai= l.com]
Sent: 06 September, 2013 19:43
To: Peter Saint-Andre
Cc: Sa=FAl Ibarra Corretg=E9; stox@ietf.org; Isomaki Markus (Nokia-C= IC/Espoo)
Subject: Re: [Stox] current status

 

 

 

On Fri, Sep 6, 2013 at 11:35 AM, Peter Saint-Andre &= lt;stpeter@stpeter.= im> wrote:

-----BEGIN PGP SIGNED= MESSAGE-----
Hash: SHA1

On 9/6/13 10:16 AM, S= a=FAl Ibarra Corretg=E9 wrote:
>
> On Sep 6, 2013, at 3:25 PM, <Markus.Isomaki@nokia.com>
> <Markus.Isomaki@nokia.c= om> wrote:
>
>> Hi,
>>
>> There have been a fair number of comments on -core, -im and
>> -presence since the Berlin IETF. Please take a look at the new
>> versions http://tools.ietf.org/id/draft-ietf-stox-core-04.txt
>> http://tools.ietf.org/id/draft-ietf-stox-im-02.txt
>> http://tools.ietf.org/id/draft-ietf-stox-presence-04.txt and see
>> if your issues have been properly addressed, and/or whether you >> want to still raise any new issues.
>>
>> If nothing specific comes up, the chairs will consider starting >> WG LC on these documents in the near future.
>>
>> One thing that I wonder about -core is whether it is a good idea >> to stabilize or last call it yet at this point, since there have >> been some issues raised about -media that might have impact to
>> -core, such as dealing with SIP side forking or loop detection. >> So is it better to wait with -core until -media is more stable? >>
>
> At some point we agreed that those issues would be handled in
> -media, because in other cases (chat, presence, im) the gateway is
> itself the endpoint and handles all the "media", so those di= dn't
> seem to apply.

That is my recollection, too.

 [MB] That was also what I thought when I revie= wed -core. [/MB]

 

Thus I'd be in favor of stabilizing the -core spec, = and hanlding the
forking issues in the -media spec.

[MB] I agree. [/MB]


Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http:= //gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSKgRqAAoJEOoGpJErxa2p4GUP/2bzG8+W= bRPcn0JpREhws+T5
m3WBrq0OoJryDzxaA2HmBq15TBawWzsVce5dp4oOY73G9HsPxCyDHrPYiN/SBxhK
VTSrIid3GCd9s0uTNEgPIwcQ6DFJy5f3nxdo2YWgmm+ncJ7hvuSXSGoDCammAyX0
nGci5VPoesbj+LZaebSPgFDHX7jtVElqloR2wpHYxmTh+P34sXGuKneQH43wYdM7 seOMpsD8yyfwRUqvhglUf4H46maQvYENTDCFsk5XjbcWoJLK52+N+Pwkw9ofr6DZ no/j5xPLY1mr3FTE0MTgMn0Nq3YSCD4M3jLrsjjdudvlQvLcItWIK4x9OO8JaaFx
5+AWtrCjn6yu/NKLgY8M5zhju51T8/srn1sBzxCQNkj5dNykbhp2W/Qo2Y+eahF1 cZEOhmTTALEpbqvtGxZBg/p9kSugwk3q4oAlP875JlBS+VLiiFXc6MIeXqWHS9yf
X2KXJj3xNrh1Esp/Z2FG/W5+uz+e9tT2IlevhKcNozFs+gyJHeD/KwZZ3Oc3/Hq= j
4RkFcLW+8iXFqH1EozpYFcr7WOhNRlh2KtbBON/w9o7481i35HRG8cR0TtFZ//By
pqTdVWZhwYH3PR9B4+6cY53Lk5aWoL5RGX5DYMPluHuJGcPW99VORRE8RRo4eepC
nTGO/i5/5W8SC+EE3hO7
=3D6RTC
-----END PGP SIGNATURE-----

_______________________________________________
stox mailing list
stox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stox

 

--_000_E44893DD4E290745BB608EB23FDDB7620A0B3F90008AM1MPN1043mg_-- From Markus.Isomaki@nokia.com Wed Sep 18 04:25:40 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 608D911E8231 for ; Wed, 18 Sep 2013 04:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 vO2puzgzhfDX for ; Wed, 18 Sep 2013 04:25:34 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1893F11E8210 for ; Wed, 18 Sep 2013 04:25:25 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.26]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8IBLHbw028954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 18 Sep 2013 14:21:20 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.213]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.03.0136.001; Wed, 18 Sep 2013 11:21:17 +0000 From: To: Thread-Topic: Meeting slot in Vancouver Thread-Index: Ac60YJkW/act0bo5TMKZTWtmwhA0xw== Date: Wed, 18 Sep 2013 11:21:16 +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: aZMi/WbTZrlATXhBcdW5gWGLKIi7GVAX5yI7gEnvWobc7ssuf3gbo/L0nOmh5rRwbTeJhGXHtLek8nUKaVN2J/VrFvin9+XcqcxRB+n5PRxOhp4w8IcBtvkqQJJUK/ezcPjVDWRtWOLqhe9dfhcWwFiyf4KvRG84YLNhT/NeZTMU3G4oRpfbtr6HBsxeqNe/ApqaWNYbAmO/LXRDjsQoVZnLXrQ0PrBYJPTmgYJN2Vs= x-originating-ip: [10.236.6.11] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A0B3FA2008AM1MPN1043mg_" MIME-Version: 1.0 X-Nokia-AV: Clean Subject: [Stox] Meeting slot in Vancouver 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: Wed, 18 Sep 2013 11:25:40 -0000 --_000_E44893DD4E290745BB608EB23FDDB7620A0B3FA2008AM1MPN1043mg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Following the plan below means also that STOX would need a meeting slot in = Vancouver meeting. The main topic would be the -media draft. So the chairs = are planning to submit a request for a 1 hour slot. Peter, Emil, S=E1ul, as= co-authors of the -media draft we would need at minimum one of you to be p= resent to lead that discussion. Markus From: Isomaki Markus (Nokia-CIC/Espoo) Sent: 18 September, 2013 14:16 To: 'ext Mary Barnes'; Peter Saint-Andre Cc: Sa=FAl Ibarra Corretg=E9; stox@ietf.org Subject: RE: [Stox] current status Hi, There have been no further comments on this, so I think we can declare it d= ecided that we won't expand the scope of -core with topics like forking, bu= t leave that to the -media to handle. My proposed plan for the next steps of the WG is: - Before Vancouver: Issue WG Last Calls on -core, -im, and -presen= ce and see if they indeed are mature enough to be delivered forward. - For Vancouver: Get updated versions of especially -media, and po= ssibly -chat and -groupchat, and collect the open issues about them. - In Vancouver: Discuss the open issues about -media, and if neede= d -chat and -groupchat. - After Vancouver: Depending on the maturity and issues raised, sc= hedule WG Last Calls for the remaining deliverables. Let the chairs (Yana and me) know if you have issues with this plan or even= better, suggestions how to improve it. Markus --_000_E44893DD4E290745BB608EB23FDDB7620A0B3FA2008AM1MPN1043mg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Following the plan below = means also that STOX would need a meeting slot in Vancouver meeting. The ma= in topic would be the –media draft. So the chairs are planning to submit a request for a 1 hour slot. Peter, Emil, S=E1ul, as co-authors = of the –media draft we would need at minimum one of you to be present= to lead that discussion.

 <= /p>

Markus

 <= /p>

 <= /p>

From: Isomaki Markus (Nokia-CIC/Espoo)
Sent: 18 September, 2013 14:16
To: 'ext Mary Barnes'; Peter Saint-Andre
Cc: Sa=FAl Ibarra Corretg=E9; stox@ietf.org
Subject: RE: [Stox] current status

 

Hi,

 <= /p>

There have been no furthe= r comments on this, so I think we can declare it decided that we won’= t expand the scope of –core with topics like forking, but leave that to the –media to handle.

 <= /p>

My proposed plan for the = next steps of the WG is:

- = ;         Before Vancouver:= Issue WG Last Calls on –core, -im, and –presence and see if th= ey indeed are mature enough to be delivered forward.

- = ;         For Vancouver: Ge= t updated versions of especially –media, and possibly –chat and= –groupchat, and collect the open issues about them.

- = ;         In Vancouver: Dis= cuss the open issues about –media, and if needed –chat and R= 11;groupchat.

- = ;         After Vancouver: = Depending on the maturity and issues raised, schedule WG Last Calls for the= remaining deliverables.

 <= /p>

Let the chairs (Yana and = me) know if you have issues with this plan or even better, suggestions how = to improve it.

 <= /p>

Markus<= /p>

 <= /p>

--_000_E44893DD4E290745BB608EB23FDDB7620A0B3FA2008AM1MPN1043mg_-- From saul@ag-projects.com Wed Sep 18 05:02:09 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 8B7AA11E8243 for ; Wed, 18 Sep 2013 05:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[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 7iZYUVj5N26O for ; Wed, 18 Sep 2013 05:02:03 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9B11E8264 for ; Wed, 18 Sep 2013 05:02:03 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8D740B35DD; Wed, 18 Sep 2013 14:02:01 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 94496B00EF; Wed, 18 Sep 2013 14:01:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 18 Sep 2013 14:01:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1085) Cc: stox@ietf.org Subject: Re: [Stox] Meeting slot in Vancouver 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: Wed, 18 Sep 2013 12:02:10 -0000 On Sep 18, 2013, at 1:21 PM, = wrote: > Hi, > =20 > Following the plan below means also that STOX would need a meeting = slot in Vancouver meeting. The main topic would be the =96media draft. = So the chairs are planning to submit a request for a 1 hour slot. Peter, = Emil, S=E1ul, as co-authors of the =96media draft we would need at = minimum one of you to be present to lead that discussion. > =20 Hi Markus, Unfortunately I won't be present in Vancouver, I'll participate remotely = though. -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Wed Sep 18 05:55:09 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 AA75A11E82D4 for ; Wed, 18 Sep 2013 05:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.014 X-Spam-Level: X-Spam-Status: No, score=-102.014 tagged_above=-999 required=5 tests=[AWL=-0.585, 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 q7O-yC1y7l6M for ; Wed, 18 Sep 2013 05:54:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6F37411E8234 for ; Wed, 18 Sep 2013 05:54:24 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 26C144169C; Wed, 18 Sep 2013 06:59:13 -0600 (MDT) Message-ID: <5239A280.30404@stpeter.im> Date: Wed, 18 Sep 2013 06:54:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, "" Subject: Re: [Stox] Meeting slot in Vancouver 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: Wed, 18 Sep 2013 12:55:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/18/13 6:01 AM, Saúl Ibarra Corretgé wrote: > > On Sep 18, 2013, at 1:21 PM, > wrote: > >> Hi, >> >> Following the plan below means also that STOX would need a >> meeting slot in Vancouver meeting. The main topic would be the >> –media draft. So the chairs are planning to submit a request for >> a 1 hour slot. Peter, Emil, Sául, as co-authors of the –media >> draft we would need at minimum one of you to be present to lead >> that discussion. I will almost certainly be there. > Unfortunately I won't be present in Vancouver, I'll participate > remotely though. We might want to make sure our session is earlier in the day so that Saúl (and other folks in Europe) aren't joining at 2 AM. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOaKAAAoJEOoGpJErxa2p7sAP/16UWVLqtJNrte6qQ7U5AGyy 5u6J2YLCWTtmYt+glHo39Mslwe2U1z2KSZ/gxF1Gu/+Z6YQ9tVlkgmWkMZaJDu9e KkF7saoXOzcMXCzYs5FYPuqz9ZYOY7Y2GxyveTdVKYpL7P/QzTlv/P66Py6CZiUs SWR+SIc6VOWLk3c1m60gYImgeFQfPITdCVyCO0HPMl3FlNH9/5gZZoHpF56Ro8BE rnZgl2mwFhfb9m8Hct++Cq7x2QSBnewE3BJLwWymOtxfMMDemRFPLMaiU9u4+xDI wE8VXai6yPk76PqsvqwGg0hch5//Ubg76DiN8xTUm++u+tmJt5oQbKSz53ff/DnP 2hZrTzdQ4ZfJNzgbGj+TFqooSO/J/pMVUc2N/Ud8YGKHUaYnMrld0O2HedbcpsZV fG+knQidDPabYV3OaBtiICXlzl0pfaNyaJFCPgwZTFcft7/ORoVZxJ18BKhsQ1SV lFUWKy13Xlz5itdDo5m/T9GL8yBR4VZEgHioudOeIGk8oKALAPHkbY7NUtCFo7Dh 6LDmkM2xUwc1BnK4edPd2Rvjl6nuGPcsCkCWtKx1kC+RWwyqnx7YpAjR3csc6pj+ DHnVhe48BxLBr1RZG2tYyszKhigFm1MteIlXBlAyL40diPtxnkb8KesJj9nVl1JE j9r3OuLZD6Qc5UytQCUG =PLIu -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Sep 18 05:56:42 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 9F0EB11E8217 for ; Wed, 18 Sep 2013 05:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.767 X-Spam-Level: X-Spam-Status: No, score=-101.767 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 hAyK3uqLWD9D for ; Wed, 18 Sep 2013 05:56:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF7A11E82C9 for ; Wed, 18 Sep 2013 05:55:55 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7E5D94169C; Wed, 18 Sep 2013 07:00:40 -0600 (MDT) Message-ID: <5239A2D7.3010006@stpeter.im> Date: Wed, 18 Sep 2013 06:55:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <52294513.8080407@stpeter.im> <8EFEDB10-B1D2-4D58-80A1-BDC24BF1EA8E@ag-projects.com> <522A046A.3050105@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, mary.ietf.barnes@gmail.com, saul@ag-projects.com Subject: Re: [Stox] current status 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: Wed, 18 Sep 2013 12:56:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/18/13 5:16 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > > > There have been no further comments on this, so I think we can > declare it decided that we won?t expand the scope of ?core with > topics like forking, but leave that to the ?media to handle. > > > > My proposed plan for the next steps of the WG is: > > - Before Vancouver: Issue WG Last Calls on ?core, -im, > and ?presence and see if they indeed are mature enough to be > delivered forward. > > - For Vancouver: Get updated versions of especially > ?media, and possibly ?chat and ?groupchat, and collect the open > issues about them. > > - In Vancouver: Discuss the open issues about ?media, and > if needed ?chat and ?groupchat. > > - After Vancouver: Depending on the maturity and issues > raised, schedule WG Last Calls for the remaining deliverables. That all sounds good. I will work to update at least the -chat draft very soon, and work with Saúl on the groupchat draft too. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOaLXAAoJEOoGpJErxa2pdzUP/3O5sqGCzCJC4tlLim+l0GN9 MPlBar29R/p7EZl4PtidflGlcChKBBFZ3i15vPUNmZEvkzZGe/Qw2IeapLFPkuWK 5XPswVKfXX3beqiy3CtoWoaXIFSWZWudVemwR+TQDDvx++i48GTsRK+MUXMq1Tn/ kgMP7QgUF5bn/JbKugXy91ahIepZBG57sKLLLWBugfDE0UdVpRWtbEiL7Z+5hrwE pqazBo6w5rvf9y1lokw1pXUj+v/+H9Ijs7/+jnU6lxtcxzUzZQwBeu2Do/AnShDi jKeeb1Wr9OqQ8eXX1azfzTS4qeMjk9v8uPoz19KSSfEbGFciXMQz3nr88XEnpl3g MXWWpezpLU7CcqLfhuSRmtEf+N6MO2WhlyXk1GSq35Y51Bup+N1G9wfx82cbmwnw yrqba+LbOagM0dNkHmGGYPEmAcnYPstmBZ8Hnr5hv3bvfEBjUGk7tZv/O53j6YXN 45HAxpvKFD6AUpbAO16E2M/Gs5vCsKvtaXDvLO2vMYvk1P9A0kQpdoRLYlu9EfHC Nu6aRfNdq2xq+9JotN+8rKg4LmHFRoR6dFDQzD49Ahj+dSfdviXACkjoopJL76kF TodDoplDPak8pgNAj5PLfgSt5E/ZykVhlAjsYRBdIN6qI68bhUoiSrkUjCR8NHNI ttjYQhwAdfqOah1iguAn =GDU+ -----END PGP SIGNATURE----- From fippo@goodadvice.pages.de Wed Sep 18 06:25: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 0BDE211E824C for ; Wed, 18 Sep 2013 06:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 h5Dy8g-9AaXf for ; Wed, 18 Sep 2013 06:25:45 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id BB02611E8289 for ; Wed, 18 Sep 2013 06:25:39 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8IDPbFD009741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 15:25:37 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id r8IDPbdw009736; Wed, 18 Sep 2013 15:25:37 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Wed, 18 Sep 2013 15:25:37 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: stox@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: jingle@xmpp.org Subject: [Stox] media: rejecting an m-line in jingle 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: Wed, 18 Sep 2013 13:25:50 -0000 I just stumbled over a case where I have to map a rejected m-line over jingle... i.e. the port in the m-line is set to 0. Jingle doesn't have a mapping for the port in the m-line. So how can one reject a single m-line (content) in jingle? While jingle has a content-reject option that only happens in response to a content-add. A XEP-0177 (raw udp) element with port set to zero might be an option... but that seems onerous and I doubt that anything which currently implement 0177 handles it correctly. From stpeter@stpeter.im Wed Sep 18 07:15:25 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 BE94B11E82E8 for ; Wed, 18 Sep 2013 07:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.124 X-Spam-Level: X-Spam-Status: No, score=-102.124 tagged_above=-999 required=5 tests=[AWL=-0.395, 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 h3heWxRU+Y2w for ; Wed, 18 Sep 2013 07:15:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B7B5E11E811E for ; Wed, 18 Sep 2013 07:15:20 -0700 (PDT) Received: from sjc-vpn6-917.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7C08B4169C; Wed, 18 Sep 2013 08:20:10 -0600 (MDT) Message-ID: <5239B578.10208@stpeter.im> Date: Wed, 18 Sep 2013 08:15:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adrian Georgescu References: <9DFE605A-134A-4C41-B903-8C9955E61396@ag-projects.com> In-Reply-To: <9DFE605A-134A-4C41-B903-8C9955E61396@ag-projects.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stox@ietf.org" Subject: Re: [Stox] OTR encryption between SIP and XMPP 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: Wed, 18 Sep 2013 14:15:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/13/13 6:42 AM, Adrian Georgescu wrote: > Hello, > > I am not sure if this is relevant to any of the deliverables of the > working group, but just in case it is, we were able to create > end-to-end encryption for chat sessions using OTR protocol > http://www.cypherpunks.ca/otr/ between a SIP client using MSRP > (that is Blink) and XMPP client (Jitsi). > > The implementation is described here: > > http://projects.ag-projects.com/projects/blinkc/wiki/OTR Cool! Given that OTR is an "over-the-top" encryption method that's agnostic about the underlying messaging transport, it does seem like a reasonable approach. I'm not sure whether we need or want to say anything about that in draft-ietf-stox-chat. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSObV4AAoJEOoGpJErxa2pdGMP/jIKZpUYvjvSW9U915e0NDO+ Fm/smDy5D9gVDDO/q9aK5BZP8Yon69oYZA8zFYfq1q5iZcf0LmMMkyX0imOSQ7nJ N031RP3jaMDp10Rph+kbsOetUXCHkqFJNN1SSVeT/FjZcC9s0SjI8lxXA5VbSucp BtJ/HODaLXHYjVRgMDHp9ltqvw2UazDqTyY8M35VQXCRzsCHgVSWVLGEimox4OqT 1rd7OJalE2QtXuVi0yetBdyZqjys2VWMxaRjkH+n1fw6PzCNBiNMJ0j8wL/UEOJg oYtvolaH1Qkn//f4uihcI1DMEqPKc6T1f2LOwbWs0sbztYIiMKoilwhOcBASUuKr mVh+hAR1b/s1XaIf5QhVfjrb73TP0j+i4aAq15lX+sCDK2ioVvHM9JGYIk7uOoTS SNBEXBv7z3nB64Iq47yJdeiNEOeXhBb/9+UrPsa45Sj3NHp8mkPa3TOLoxstO4vY auvOwbsFWKteLVuIy3pTwrREDoY+zgzJcPm/4k4qD4tE42wsUfbPm6BoRnWBvM46 Ed1UQ6tJ6coPMrP617U9GlI+4lYdWAm3XeZROR0hSq2cfBI1iXLS9vpxhIjqMtDy xDf79EtzaRwe462Qx3T9XAgtsLK5ls6pe2Rw9DmLGuuWvfmBiDHK1gaEbknYM9HN SneeK/LPlV9Se82p7EEe =204U -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Sep 18 08:10: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 2935E11E826B for ; Wed, 18 Sep 2013 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 ZjTEvLEsfjhE for ; Wed, 18 Sep 2013 08:10:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BEE4911E811E for ; Wed, 18 Sep 2013 08:10:48 -0700 (PDT) Received: from sjc-vpn6-917.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9F8EA4163C; Wed, 18 Sep 2013 09:15:37 -0600 (MDT) Message-ID: <5239C275.9080402@stpeter.im> Date: Wed, 18 Sep 2013 09:10:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "stox@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [Stox] chat states <-> isComposing 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: Wed, 18 Sep 2013 15:10:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've taken a look at the mapping between XMPP chat states (XEP-0085) and the isComposing event (RFC 3994). RFC 3994 has two states: idle and active. RFC 3994 has only two states because it's really just about composing (in messaging, whether or not the sender is actively typing or otherwise creating text for sending to the recipient -- simply toggling between the two, changing to active if the user is composing a message and changing to idle when not composing a message). XEP-0085 has five states: active, inactive, gone, composing, and paused. XEP-0085 has more states than RFC 3994 because it's not just about composing, but about the sender's involvement with the chat session. Thus in XEP-0085, "active" means "paying attention to the conversation", which ironically maps best to RFC 3994 "idle", I think. It might be best if we don't map XEP-0085 chat states other than composing and paused to RFC 3994 isComposing events, since RFC 3994 is just about composing. However, in XEP-0085 it is possible to have state transitions such as composing to active (not paused). Thus the safest mapping might be isComposing => chat states idle => active active => composing chat states => isComposing active => idle inactive => idle gone => ??? composing => active paused => idle This mapping loses some of the granularity on the XMPP side (i.e., the paused and inactive states), but that might be fine in this context. I know Saúl has looked at this mapping, so I would appreciate his feedback (and input from other folks, too). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOcJ1AAoJEOoGpJErxa2pQbkP/0stwD2MJn7MkjTB4wHmtJeC onCVl5tzG/I4F98U5RkNKn03zkdt6Q3p4eF/SOPnK1tf7wxTDvuxAaokZXt1IUlX 0rwx4OdMwJ8hdF20s+lWSdhoR1NXcIK5BLgqva5RF9u+Id5UNQzGls9E1KrGcre5 4MZ41ArZEmxAyrqXYH7bqGcVR9nnF6bhHV0pjQ4mL4uGWQ9DPeJLU3Xe7/FBANFH W1TWB68GXP2JyQ/gp7Y+dl/e7XZfTwybOpj+B4JqmtIXMPrpde6RlAKGzjfdAdWh cGlcqDQA33MDFYAQxew6lpLNYUCll2sXia58mjxmX/QrQyUUe5UIL4v/PCHsdcMH hszH2gZm55qVrSj26pSaUcLLRnzSEuN9nAPLukp5lK1QFHoZOPsLI1CVHE5mNY60 /IWmbSUTOpbPsUkV5CONYYJQk9wGAGZ626DWdJQ4LDYdHT+rQKOqgvYOafApmVzp vBgrN03mtv27YQz55+T2R/UAuzyavCD6KFhg+vV18JdjuzjsvgWd9gLT1Mz2udFt 5X/zNGV7rmnIAcssYODhmcrsi7+rLGzirtIqwRqM1SHvgep6yO0qIl+97kMZnjSX WrOUGp3JxnGnjfHgah7SXBJzPJz2Qa29oYf+qzG7qJEgF6ibuwAAgUVWZRQhGfNo ZFePT1EC0Y7Kb0VzI2gT =t9Qo -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Sep 18 20:22:17 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 1A38111E80E9; Wed, 18 Sep 2013 20:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.413, 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 DF+oDrqDmYGo; Wed, 18 Sep 2013 20:22:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B33E011E80D7; Wed, 18 Sep 2013 20:22:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130919032216.30618.70861.idtracker@ietfa.amsl.com> Date: Wed, 18 Sep 2013 20:22:16 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-chat-01.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 03:22:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Te= xt Chat Author(s) : Peter Saint-Andre Salvatore Loreto Eddy Gavita Nazin Hossain Filename : draft-ietf-stox-chat-01.txt Pages : 16 Date : 2013-09-18 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-chat-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-chat-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Wed Sep 18 20:23:35 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 B008311E817F for ; Wed, 18 Sep 2013 20:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.975 X-Spam-Level: X-Spam-Status: No, score=-101.975 tagged_above=-999 required=5 tests=[AWL=-0.246, 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 BUgySdome6tD for ; Wed, 18 Sep 2013 20:23:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3E411E8176 for ; Wed, 18 Sep 2013 20:23:31 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C163C206F7; Wed, 18 Sep 2013 21:28:21 -0600 (MDT) Message-ID: <523A6E2F.5070601@stpeter.im> Date: Wed, 18 Sep 2013 21:23:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stox@ietf.org References: <20130919032216.30618.70861.idtracker@ietfa.amsl.com> In-Reply-To: <20130919032216.30618.70861.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Stox] I-D Action: draft-ietf-stox-chat-01.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: Thu, 19 Sep 2013 03:23:35 -0000 A first attempt at including composing notifications and delivery receipts... Peter On 9/18/13 9:22 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. > > Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat > Author(s) : Peter Saint-Andre > Salvatore Loreto > Eddy Gavita > Nazin Hossain > Filename : draft-ietf-stox-chat-01.txt > Pages : 16 > Date : 2013-09-18 > > Abstract: > This document defines a bidirectional protocol mapping for the > exchange of instant messages in the context of a one-to-one chat > session between a user of the Session Initiation Protocol (SIP) and a > user of the Extensible Messaging and Presence Protocol (XMPP). > Specifically for SIP text chat, this document specifies a mapping to > the Message Session Relay Protocol (MSRP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-chat > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stox-chat-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-chat-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 18 20:53:11 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 5010D11E8175 for ; Wed, 18 Sep 2013 20:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.345 X-Spam-Level: X-Spam-Status: No, score=-101.345 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, 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 kwGWTboyhgzF for ; Wed, 18 Sep 2013 20:53:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EE40311E80E9 for ; Wed, 18 Sep 2013 20:53:06 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9EC8B206F7; Wed, 18 Sep 2013 21:57:58 -0600 (MDT) Message-ID: <523A7520.70002@stpeter.im> Date: Wed, 18 Sep 2013 21:53:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stox@ietf.org References: <5203E484.4050902@goodadvice.pages.de> In-Reply-To: <5203E484.4050902@goodadvice.pages.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Stox] review of core, chat, groupchat and presence 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: Thu, 19 Sep 2013 03:53:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/8/13 12:33 PM, Philipp Hancke wrote: > chat: example f2: call-id: contain jid? how about uniqueness?. Is > there any text on the use of ? in -im @example.com callid > is used a=lang could be taken xml:lang? before example F4: the > gateway acknowledges on behalf of juliet? > > example f5: the initial message in F1 should have an id attribute > which gets mapped in f5. Does a786hjs2 map to thread/call id? > > example f6: shouldn't message-id should be different from f5? > mapping of message-id to id attribute, should be randomly generated > if not present > > section 4: sessinos -> sessions; Sorry, I neglected to incorporate this feedback into version -01. I'll do that for -02. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOnUgAAoJEOoGpJErxa2p3RAP/jJhnhrY4aSVqHZ7+jLyhqJb 3xZfMmnhCd5dfXO6uFnNrGYRVfLFcWEBJbOqjHpIUpFde4Gwg2jGBAzk+7oASNhp UyCThR60xo+xnLSMCZe7/btJhXObJaYfUx2TSHyF9cu9RFaAS1a9MMXGriw+dAyy 7Cg7WtEs6dQ1+rYUGYx9fELf865PDSwVgNbiYaz478iVJ0U8E0WGnWd4dy2LAp1d beOPrlcHSPb4Aof6J10GrrA2ec7DJJO2Jaq2Uet531H4DiImfe1I6cwM5pHA5zvg DlX9efK10HeLtcR5Ut7iUg4HCAn/iqFqURQCN722UlwZgVCzdNqHp9GCIzjv8Yoo cBvbqQIHHFbfBSrWAyNAWnG+hLzSYHwKqXDMMyDxlEFXJP0w5Jh6omTQ9ZyULq0T vEsi25Fpp5lXTXxdKo3R0dzPxwSRXYTnEoIOemh2l+Dnq2lbceMkhfZJdJuT9UkW K79AVj3aob3FbtmXAIHW/RUUr8xNdGGsyYgFQZhXhT2MRxakL+eMwPCSN/6P09AL EtjSAmLGDQywfJW3jlYtIInHVDoHd3of8/qlXO0Q+rNRGW1SP5CLUzpMUOfSo28w u2nSvg1nP8GvMdfW/sUk9c3rCQnpQZ1iTtroShZee17V9EelO0Lz1rZi/D40vqal uaDGsVbqrIih2q7JzMEE =YbBi -----END PGP SIGNATURE----- From saul@ag-projects.com Thu Sep 19 00:44: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 3322D21F99C0 for ; Thu, 19 Sep 2013 00:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[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 Wx54l55Moq0Z for ; Thu, 19 Sep 2013 00:44:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19D21F99C3 for ; Thu, 19 Sep 2013 00:44:08 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4B157344002; Thu, 19 Sep 2013 09:44:03 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 52E5CB00EF; Thu, 19 Sep 2013 09:44:03 +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: <5239C275.9080402@stpeter.im> Date: Thu, 19 Sep 2013 09:44:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5239C275.9080402@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Cc: "stox@ietf.org" Subject: Re: [Stox] chat states <-> isComposing 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: Thu, 19 Sep 2013 07:44:22 -0000 Hi Peter! Thanks for looking into this, I think it's really useful. On Sep 18, 2013, at 5:10 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I've taken a look at the mapping between XMPP chat states (XEP-0085) > and the isComposing event (RFC 3994). >=20 > RFC 3994 has two states: idle and active. RFC 3994 has only two states > because it's really just about composing (in messaging, whether or not > the sender is actively typing or otherwise creating text for sending > to the recipient -- simply toggling between the two, changing to > active if the user is composing a message and changing to idle when > not composing a message). >=20 > XEP-0085 has five states: active, inactive, gone, composing, and > paused. XEP-0085 has more states than RFC 3994 because it's not just > about composing, but about the sender's involvement with the chat > session. Thus in XEP-0085, "active" means "paying attention to the > conversation", which ironically maps best to RFC 3994 "idle", I think. >=20 > It might be best if we don't map XEP-0085 chat states other than > composing and paused to RFC 3994 isComposing events, since RFC 3994 is > just about composing. However, in XEP-0085 it is possible to have > state transitions such as composing to active (not paused). >=20 > Thus the safest mapping might be >=20 > isComposing =3D> chat states > idle =3D> active > active =3D> composing >=20 Yes, I implemented this mapping following my intuition and feels ok in = actual usage. > chat states =3D> isComposing > active =3D> idle > inactive =3D> idle > gone =3D> ??? > composing =3D> active > paused =3D> idle >=20 Here comes the dilemma: that gone state. Not many clients implement the = 'gone' state, but those who do tend to render a message such as "Peter = left the conversation" if they get one, and likewise, send it if you = close the conversation tab. Based on this non-scientific testing I = mapped it to a SIP BYE, both ways. That is, if we are having a chat = session (I am on MSRP and you on XMPP) if I end the SIP session, the = gateway would send a gone chatstate, and if your client would send it, = the gateway would terminate the SIP session. I know this looks weird, since we are mixing payload translation with = session management, but since the gateway needs to handle all chat media = I don't see a problem with that. Thoughts? > This mapping loses some of the granularity on the XMPP side (i.e., the > paused and inactive states), but that might be fine in this context. >=20 We'll need to adjust to the minimum common denominator, like we do in = groupchat :-) Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From fippo@goodadvice.pages.de Thu Sep 19 00:53:34 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 99D6321F9AD2 for ; Thu, 19 Sep 2013 00:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] 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 ntso7lK+a56t for ; Thu, 19 Sep 2013 00:53:09 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id BED3D21F9AA7 for ; Thu, 19 Sep 2013 00:53:08 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8J7r2Cl003222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 09:53:02 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id r8J7r2Tb003217; Thu, 19 Sep 2013 09:53:02 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Thu, 19 Sep 2013 09:53:02 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: XMPP Jingle In-Reply-To: <1379521739.4061.2.camel@TesterBox.lan> Message-ID: References: <1379521739.4061.2.camel@TesterBox.lan> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="683466026-431934476-1379577182=:3051" Cc: stox@ietf.org Subject: Re: [Stox] [Jingle] media: rejecting an m-line in jingle 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: Thu, 19 Sep 2013 07:53:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --683466026-431934476-1379577182=:3051 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 18 Sep 2013, Olivier Crête wrote: > On Wed, 2013-09-18 at 15:25 +0200, Philipp Hancke wrote: >> Jingle doesn't have a mapping for the port in the m-line. So how can one >> reject a single m-line (content) in jingle? > > You just send a "content-remove" stanza. The jingle design tries to > avoid nasty hack such as the port=0 SIP/SDP thing. So you'd send a content-remove before sending the session-accept? FWIW, it's not actually clear to me whether jingle imposes a "session-accept must have the same number of contents as session-initiate" constraint (3264 is only used for the inclusion of payloads). If it doesn't then not sending rejected contents in the answer would be valid, but I doubt gateways will appreciate that more than the content-remove way :-) --683466026-431934476-1379577182=:3051-- From stpeter@stpeter.im Thu Sep 19 05:50:32 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 0266521F935A for ; Thu, 19 Sep 2013 05:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.704 X-Spam-Level: X-Spam-Status: No, score=-101.704 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 w7qjP9r8OsCD for ; Thu, 19 Sep 2013 05:50:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B574A21F9344 for ; Thu, 19 Sep 2013 05:50:27 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0AD04206F1; Thu, 19 Sep 2013 06:55:20 -0600 (MDT) Message-ID: <523AF313.4010509@stpeter.im> Date: Thu, 19 Sep 2013 06:50:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <5239C275.9080402@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "stox@ietf.org" Subject: Re: [Stox] chat states <-> isComposing 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: Thu, 19 Sep 2013 12:50:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [removing areas of agreement] On 9/19/13 1:44 AM, Saúl Ibarra Corretgé wrote: > On Sep 18, 2013, at 5:10 PM, Peter Saint-Andre wrote: > >> gone => ??? >> > > Here comes the dilemma: that gone state. Not many clients > implement the 'gone' state, but those who do tend to render a > message such as "Peter left the conversation" if they get one, and > likewise, send it if you close the conversation tab. Based on this > non-scientific testing I mapped it to a SIP BYE, both ways. That > is, if we are having a chat session (I am on MSRP and you on XMPP) > if I end the SIP session, the gateway would send a gone chatstate, > and if your client would send it, the gateway would terminate the > SIP session. > > I know this looks weird, since we are mixing payload translation > with session management, but since the gateway needs to handle all > chat media I don't see a problem with that. That makes a lot of sense to me, given that the gone chat state is kind of like in-session unavailable presence. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOvMSAAoJEOoGpJErxa2po5AQAKoiJGfNVsgFC/SkuCIyhwjl 585PuyxKRyPnsCVo7G7bu5hN3ZvOJY56yvam60WvdOqiJF9LJfx+6gd8Dr3+v3jy M0xWQtqGD5lmQmQn3KAJNrYPDvq+wvUd1oFyarkbZUcjvLDyQ+DtlZB6jlEUtiM8 rh65/pOAIDjAZRhrO1xrKbfSZDrprGmb2nnnNJGku1SOT1Hm/ncJRmtwet1Mw4M8 wpj6ryl9CfTGe/7qrf3xa+IU74+ywPiNyZtv/U827QHKAZSKenF9TjgVqFO4X+4F /imhrv2onV6LFgIu+mevZ+YbopI1on4/cqd7CZc5S0Wq0SoxUIicCQwf6DOVsi10 NtJil7HB7Z8HR3/EuuZItqkeG/I/xs6YvfaD+G93gpSgsBtfhk8JkahYeKEPJGbw v0b9wUrvc411N7ONEgxTuyqGNhI8Cn0463SCV+OsUySLTAldfpd9wIfUd8xyTKWW PRSUqHjSv9AFzRrxL+AYLEVrgWDMz/3xK2fgFN/YYD4YC42AVLknGkB7UkMr+tEM /ejwXcYzRq9FWUop6fcydc88Jr7DmgJ+RIBuw3OkRx0Qn+xJvLZ35wCA0IhvkiNu peP49Od2/TXFsbC/lXWZmhDWBQsplI/RqnCdrGviJJW2M41kNebrvKtoQqDc0mWY 6Y8SUg+gxsYwJlPA/Iuh =x09Y -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Sep 19 09:47:20 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 34E1321F95DD for ; Thu, 19 Sep 2013 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.51 X-Spam-Level: X-Spam-Status: No, score=-101.51 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, 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 ftUu52VaiHGe for ; Thu, 19 Sep 2013 09:47:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8272C21F9951 for ; Thu, 19 Sep 2013 09:47:01 -0700 (PDT) Received: from sjc-vpn6-839.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 798CB206F1; Thu, 19 Sep 2013 10:51:55 -0600 (MDT) Message-ID: <523B2A83.7080302@stpeter.im> Date: Thu, 19 Sep 2013 10:46:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stox@ietf.org References: <5203E484.4050902@goodadvice.pages.de> <523A7520.70002@stpeter.im> In-Reply-To: <523A7520.70002@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Stox] review of core, chat, groupchat and presence 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: Thu, 19 Sep 2013 16:47:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp, thanks for the review. Comments inline. On 9/18/13 9:53 PM, Peter Saint-Andre wrote: > On 8/8/13 12:33 PM, Philipp Hancke wrote: > >> chat: example f2: call-id: contain jid? how about uniqueness?. Yes, RFC 3261 says they need to be unique: In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. I was unthinkingly following the examples in specs like RFC 4975. I'll change them to be UUIDs. >> Is there any text on the use of ? There is text about this in draft-ietf-stox-im, which says to map Call-ID to and vice-versa. However, that probably belongs in the -chat document, since thread isn't really used in pager-mode single messages. >> in -im @example.com callid is used As mentioned, I'll make them UUIDs. >> a=lang could be taken xml:lang? In the -im I-D we map xml:lang to the Content-Language header. I think that's more appropriate than a=lang, which has some subtleties I'd prefer to avoid -- see draft-gellens-mmusic-negotiating-human-language for some related considerations. >> before example F4: the gateway acknowledges on behalf of juliet? Yours was a very brief comment and I'm not sure I understand the force of your question. Are you wondering why there's an ACK at this point in the negotiation? That's what I see in RFC 4975: Alice Bob | | | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| |(4) (MSRP) SEND | |----------------------->| >> example f5: the initial message in F1 should have an id >> attribute Agreed. >> which gets mapped in f5. Does a786hjs2 map to thread/call id? That's an MSRP transaction identifier, which IMHO maps to a stanza 'id' attribute in XMPP. This too needs to be documented in the -chat I-D. >> example f6: shouldn't message-id should be different from f5? Yes, I think so, because that's a different transaction. >> mapping of message-id to id attribute, should be randomly >> generated if not present Hmm. In MSRP, the message-id can be used to identify an overall message, which might be chunked into separate transactions. XMPP doesn't have the concept of a message in the MSRP sense when we're talking about IM. In XMPP, In-Band Bytestreams (XEP-0047) enables you to chunk a large piece of data into smaller pieces, but that's used only for file transfer, not for IM. We could add a note about this in the -chat I-D, but for IM purposes I think we don't want to map the MSRP message-id to anything on the XMPP side. >> section 4: sessinos -> sessions; Yes, my fingers often make that mistake while typing. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOyqDAAoJEOoGpJErxa2pLcoQAK6DaWqEMjTVA5rDHwP2ilpc hO7YCUOU9tig4y1F/75ySwg+zqERkotmj6o3PVl108LgUnCKYXThqr0qOyQ2ic4z k0/cVe4/dCqq4V0/HoKri2CEMpL1hoc5LK+Kwy1v8jnr/JtuCyoQ7tW/zXBK+VyR KRxoSaokmoZ/HAITLd2sVc0s90u0La73dggdy1xqp8uPXWEv12rnJ1cEdm0Vjdlk 2mS6Tn5XEx2yM5/C2/liJOcN7ntAcqRZ9P+4JLOkSHuJx++wKYrsu8gx7V3wET5A buxQcJUXQWCz7z628QC2rt30bo5BcDtow+MaEX5hyKi8Olmzo4062Bpc5sEijVHM TU43Dbk2BjusvtyYeVq44yOHhHnRFPeRqv5LhaGMaGpT6IcJNfm7PS/TZ/F94EZS +kMjIbGBbm4vW7CKQ98J9T9w4+qQG61TodgLs3pG53r0yYnsYpOD6Lq+5gJlUvcS t0cGezv2aEkgNRlr449JxOjihMqK4OyCsN4hL9wLbnNfxSXYCwiEJ8hCYaMEN6L7 KmI04FMVX70etWlV8LndYBeRBFDJGYQOCtPxhp71F+Q0Nkue4rFo+ebLwj9ywbVK 7KanGtPvrilPo6tqldGAH0VjB/HFEO9cOB/eZ9JBBTNrP/OI9HgazLITQmWv69bV qxrHafVj3/Fq/xk73RIv =0b1p -----END PGP SIGNATURE----- From fippo@goodadvice.pages.de Thu Sep 19 10:13:46 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 B78E021F9433 for ; Thu, 19 Sep 2013 10:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, 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 fWjC3838Neq0 for ; Thu, 19 Sep 2013 10:13:41 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5727B21F94FF for ; Thu, 19 Sep 2013 10:13:38 -0700 (PDT) Received: from [192.168.2.100] (p54970393.dip0.t-ipconnect.de [84.151.3.147]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8JHDZPi013046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Sep 2013 19:13:36 +0200 Message-ID: <523B30B9.4030509@goodadvice.pages.de> Date: Thu, 19 Sep 2013 19:13:29 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stox@ietf.org References: <5203E484.4050902@goodadvice.pages.de> <523A7520.70002@stpeter.im> <523B2A83.7080302@stpeter.im> In-Reply-To: <523B2A83.7080302@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Stox] review of core, chat, groupchat and presence 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: Thu, 19 Sep 2013 17:13:46 -0000 Am 19.09.2013 18:46, schrieb Peter Saint-Andre: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Philipp, thanks for the review. Comments inline. Stuff that is done removed. Thanks for addressing the issues. [...] >>> chat: example f2: call-id: contain jid? how about uniqueness?. > > Yes, RFC 3261 says they need to be unique: > > In a new request created by a UAC outside of any dialog, the Call-ID > header field MUST be selected by the UAC as a globally unique > identifier over space and time unless overridden by method-specific > behavior. All SIP UAs must have a means to guarantee that the Call- > ID header fields they produce will not be inadvertently generated by > any other UA. > > I was unthinkingly following the examples in specs like RFC 4975. I'll > change them to be UUIDs. I think what I mean was "the call id should be something along the lines of 711609sa.juliet.example.com". The intent was the same however. [...] >>> before example F4: the gateway acknowledges on behalf of juliet? > > Yours was a very brief comment and I'm not sure I understand the force > of your question. Are you wondering why there's an ACK at this point > in the negotiation? That's what I see in RFC 4975: What I meant (and i needed to parse this again, too) was that I think the gateway acknowledges on behalf of Juliet, not Romeo as the text says. The example itself is ok. philipp From internet-drafts@ietf.org Thu Sep 19 20:39: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 1464121F8517; Thu, 19 Sep 2013 20:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.413, 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 UELn3FoldIiE; Thu, 19 Sep 2013 20:39:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A7C21F8416; Thu, 19 Sep 2013 20:39:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130920033915.23588.64543.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 20:39:15 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-chat-02.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 03:39:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Te= xt Chat Sessions Author(s) : Peter Saint-Andre Salvatore Loreto Eddy Gavita Nazin Hossain Filename : draft-ietf-stox-chat-02.txt Pages : 17 Date : 2013-09-19 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-chat-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-chat-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From salvatore.loreto@ericsson.com Fri Sep 20 02:39:17 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 6FFAE21F8DDD for ; Fri, 20 Sep 2013 02:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.988 X-Spam-Level: X-Spam-Status: No, score=-103.988 tagged_above=-999 required=5 tests=[AWL=1.390, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 iNMkQzXk31Ai for ; Fri, 20 Sep 2013 02:39:12 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AFEEA21F8EA8 for ; Fri, 20 Sep 2013 02:39:07 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-7e-523c17ba3921 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 46.7C.22048.AB71C325; Fri, 20 Sep 2013 11:39:06 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.16) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.328.9; Fri, 20 Sep 2013 11:39:06 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3DD8A11024B for ; Fri, 20 Sep 2013 12:39:06 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2DBA254647 for ; Fri, 20 Sep 2013 12:38:59 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E4B8F54416 for ; Fri, 20 Sep 2013 12:38:58 +0300 (EEST) Message-ID: <523C17B9.2070408@ericsson.com> Date: Fri, 20 Sep 2013 12:39:05 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Content-Type: multipart/alternative; boundary="------------010107040405070707030104" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvje4ucZsgg5cLjCz+72hidWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxscLJ1gKtopXLJm+gKWB8YZQFyMnh4SAicTVZQsYIWwxiQv3 1rN1MXJxCAkcZpT4/uMLI4SznlHi679+ZgjnIqPEj73zocoOMUoc6nsHVXaaUeLyia9MIMN4 BbQlrp+/wQpiswioSmx/cAosziZgJvH84RZmEFtUIFmi6fJ9Foh6QYmTM5+A2SICwhLN59+B HSUsICsx7eBqMJtZIExixaEtUMeqSVw9twlsjpCAlkTv2U6mCYyCs5CMmoWkBcK2lbgw5zpU XF5i+9s5zBC2rsSF/1NQxBcwsq1iZM9NzMxJLzffxAgM54NbfhvsYNx0X+wQozQHi5I472a9 M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGN3nrIlduqutuW+mvv7qWUEFnzQWJnCuf6pj 8GnzmVn/w27ef+7nsa31gpDiw7ct02w/sJ21n9uzzkTvwQ7hmFsMTqt83zGufqwqqbPXfs/l 7GNM0/wvTUtNMuv5ssltnsgqphduLV7//rU4/tpYrGwrcCn4vea8h5U5fxSjXqdIzJx9+tsD 431KLMUZiYZazEXFiQC/6O5YNQIAAA== Subject: [Stox] review: stox-core-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, 20 Sep 2013 09:39:17 -0000 --------------010107040405070707030104 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I have reviewed the core-04 draft, and I think that is almost ready for the WGLC I have one general comment (btw I apologize in advance if this has already been discussed and I have overlooked or forgot it) and it is about the fact that draft does not talk at all about the inter working when secure URIs are involved. I think that at least we should say something about in the Security consideration. * Editorial nits -In section 6.2, the following sentence The codes listed below are limited to those defined in the core SIP specification [RFC3261 ] and in RFCs that formally update [RFC3261 ]. It suggests, at least to me, that in the list below are listed all the codes defined in 3261 and in RFC that formally update 3261, but this is not the case. -first paragraph section 5.1 s/spports/supports Cheers Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------010107040405070707030104 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I have reviewed the core-04 draft, and I think that is almost ready for the WGLC

I have one general comment
(btw I apologize in advance if this has already been discussed and I have overlooked or forgot it)
and it is about the fact that draft does not talk at all about the inter working when secure URIs are involved.
I think that at least we should say something about in the Security consideration.

* Editorial nits

-In section 6.2, the following sentence
   The codes listed below are limited to those defined in the core SIP
   specification [RFC3261] and in RFCs that formally update [RFC3261].
It suggests, at least to me, that in the list below are listed all the codes defined
in 3261 and in RFC that formally update 3261, but this is not the case.

-first paragraph section 5.1
    s/spports/supports

Cheers
Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------010107040405070707030104-- From salvatore.loreto@ericsson.com Fri Sep 20 03:42:32 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 CF52A21F92DA for ; Fri, 20 Sep 2013 03:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, HTML_MESSAGE=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 poguzo-+Tu-F for ; Fri, 20 Sep 2013 03:42:27 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CEEA621F92CD for ; Fri, 20 Sep 2013 03:42:26 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-4d-523c26918e51 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C3.6C.25272.1962C325; Fri, 20 Sep 2013 12:42:25 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Fri, 20 Sep 2013 12:42:25 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3E8D81102E6 for ; Fri, 20 Sep 2013 13:42:25 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2191F55D8C for ; Fri, 20 Sep 2013 13:42:18 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D451255B07 for ; Fri, 20 Sep 2013 13:42:17 +0300 (EEST) Message-ID: <523C2690.6090306@ericsson.com> Date: Fri, 20 Sep 2013 13:42:24 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <523C17B9.2070408@ericsson.com> In-Reply-To: <523C17B9.2070408@ericsson.com> Content-Type: multipart/alternative; boundary="------------080702040708090707010406" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvje5ENZsgg5sLTSz+72hidWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsMa04K9UhVPj61hb2BcJdLFyMkhIWAiMWvzFnYIW0ziwr31 bF2MXBxCAkcZJQ5d3wLlbGCUWLFpBTuEc5FR4t2WZUwQziFGiVldb1khnNOMEic3LmMFGcYr oC1x4eptZhCbRUBVom/yNbA4m4CZxPOHW8DiogLJEk2X77NA1AtKnJz5BMwWERCWaD7/jhHE FhaQlljzZxJYrxDQzHVfTwHZHBycAjoSHxdEg4SZBcIkTv09ywTxg5rE1XObmCHKtSR6z3Yy TWAUnoVkwywkLRC2rcSFOdeh4vIS29/OYYawdSUu/J+CIr6AkW0VI0dxanFSbrqRwSZGYPAf 3PLbYgfj5b82hxilOViUxHm36J0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCY8ia/MqjE dj/TRVYuua+7Yl6xhTuxJtyfmB1jf0FAJdOr0lVdrePp8y42T80oJTejGd7rDIM2Mv0MvPuu 1vXulOt3m4vWbZ5xa3tK4rMQHelnrhxyZrN3zLstP/XUwcwD2w31ZPu3tJXd8dfde/zb5rkn onQsjGxm7xXzYQmXfDDDeaHHrB4lluKMREMt5qLiRABGXutmTAIAAA== Subject: [Stox] review: stox-im-03 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, 20 Sep 2013 10:42:32 -0000 --------------080702040708090707010406 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I have reviewed the core-04 draft, and I think that is almost ready for the WGLC my only comments is about the fact that section 3. XMPP to SIP implies that the MESSAGE is always (and maybe can only be) delivered over a TCP connection; RFC3428 states Whenever possible, MESSAGE requests SHOULD be sent over transports that implement end-to-end congestion control, such as TCP or SCTP. However, SIP does not provide a mechanism to prevent a downstream hop from sending a request over UDP. so you can delivery it over UDP as well and that has also being raised in a previous thread while talking on the Call-ID mapping to . Actually you will be forced to deliver over UDP if the SIMPLE server only supports UDP. So I would suggest to change Here we assume that the XMPP server has determined the foreign domain is serviced by a SIMPLE server, in Here we assume that the XMPP server has determined the foreign domain is serviced by a SIMPLE TCP server, best regards Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------080702040708090707010406 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
I have reviewed the core-04 draft, and I think that is almost ready for the WGLC

my only comments is about the fact that section 3. XMPP to SIP
implies that the MESSAGE is always (and maybe can only be) delivered over a TCP connection;
RFC3428 states
   Whenever possible, MESSAGE requests SHOULD be sent over transports
   that implement end-to-end congestion control, such as TCP or SCTP.
   However, SIP does not provide a mechanism to prevent a downstream hop
   from sending a request over UDP.
so you can delivery it over UDP as well and that has also being raised in a previous thread
while talking on the Call-ID mapping to <thread/>.
Actually you will be forced to deliver over UDP if the SIMPLE server only supports UDP.

So I would suggest to change 

   Here we assume that the XMPP server has
   determined the foreign domain is serviced by a SIMPLE server,
in

   Here we assume that the XMPP server has
   determined the foreign domain is serviced by a SIMPLE TCP server,

best regards
Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------080702040708090707010406-- From stpeter@stpeter.im Fri Sep 20 05:52: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 1721C21F9926 for ; Fri, 20 Sep 2013 05:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.326 X-Spam-Level: X-Spam-Status: No, score=-101.326 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, SARE_OEM_OBFU=1, 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 RuxdNWYSAX+R for ; Fri, 20 Sep 2013 05:52:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BECEB21F991E for ; Fri, 20 Sep 2013 05:52:45 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 82B1341699; Fri, 20 Sep 2013 06:57:42 -0600 (MDT) Message-ID: <523C44FE.3080407@stpeter.im> Date: Fri, 20 Sep 2013 06:52:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] IETF 87 minutes 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, 20 Sep 2013 12:52:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/14/13 1:19 PM, Markus.Isomaki@nokia.com wrote: > * Groupchat > > - Issue: Need to define what to do in case of multiple clients. Use > and mapping of JID, AoR, contact. I think I'll need to listen to the audio recording to remember exactly what the issue is here. Will do and report further. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSPET9AAoJEOoGpJErxa2pXMwP/it1hvRpWMUDrH4nx1MLFyNt jmlYXPMf4YSo8RNSakvThDYPtxFje1GUbjVFOxTJXbA3dhI5LhmQCOKTSabVLlMy injBr14EgoXjRQLcDa3a8uaWocV3SVagAyCwyyM8qKgdwluaODmhSXs9MF3iAPz7 q5YRUq4LTmGcfW3rUV2EOLmHhKBhZVRa8t5iP2OfYXCsvlIGmTsG0RpLKP6sUzx6 TuVW8Sl27kqDsU7YYBzA0InYcqzppNtBBbEk52Kq1YbeRJFChugc2gpG3lnOqQ37 +AHOVCL3rruXI41eecrQMgLmOLKR5EPjLMEwTDe2SsSsF1lRx0B+69tuCLhU/03m 7vtWTEstXv7J9+uykh+2uFWXXVV8gEv6XT91z7k/GqoC6yU7mDOJtl32n/d+INqP kSuvt6u0fsEWStVv/Qlp2dfM6k+9xCWGRw56xlHTFNYU5XWrSYUkAHvxTIgjEESr bHgIfluX9f/8tNfI2SSo+cu5+G8VlhR8nw1b1EbH2ZzkR2enw3aRKlqeSU1io2uY iV/SYxbx6iVqoP1/195k2wAV4DDjHhEHqrXVFa09HsXCTYK/gR7/1/xuc+9kwwDF DKgze9QlfS3fipUxIS3btbTo6yciiKFGa7dV2wdSi/+iPcsRLHz2w+ACPh/B/z4U skHqUHROjSG9K6tA5b8i =/6UZ -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Sep 22 21:12:36 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 B94E811E80D2 for ; Sun, 22 Sep 2013 21:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 C5iSev6Xms8L for ; Sun, 22 Sep 2013 21:12:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9B11E8186 for ; Sun, 22 Sep 2013 21:12:25 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2A1E341639; Sun, 22 Sep 2013 22:17:26 -0600 (MDT) Message-ID: <523FBFA2.3050902@stpeter.im> Date: Sun, 22 Sep 2013 22:12:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Philipp Hancke References: <5203E484.4050902@goodadvice.pages.de> In-Reply-To: <5203E484.4050902@goodadvice.pages.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] review of core, chat, groupchat and presence 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, 23 Sep 2013 04:12:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks again for the review. Comments inline. On 8/8/13 12:33 PM, Philipp Hancke wrote: > groupchat: 2: at least in RFC 6120, jid stands for jabber id, not > jabber identifier. Correct. Will fix. > 3.1: Room Nickname -> lowercase? Sure. > 3.1: example f2: conversion->conversation? More like conversion->mapping :-) BTW in the -chat spec I numbered all the examples sequentially, and I'll start doing that here too. > table 1: thread<->call id Yes. > 3.2: example f7: possibly use by= on the error element? Sure, by='verona@chat.example.org' seems good. > xep 0045 has the conflicting resource in the from Correct. Will fix. > 3.4: "Occupant JID in another room" -- i don't think mediated > invites work across different rooms. Section 7.8.2 of XEP-0045 states in part: ### It may be wondered why the invitee does not send the decline message directly to the inviter. The main reason is that certain implementations might choose to base invitations on occupant JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service needs to handle both the invites and declines. ### However, I'm not sure how widely that feature is implemented. > example f1: hecate is benvolio? c&p error from 0045 Will fix. > example f2: contact juliet@juliet.example.com has a wrong host? You are right. > reeived -> received Yes. > example f3 is not shown I don't feel that we need to show every 200 OK. Yes, we put the example in example.com, but sometimes you really can have too many examples. :-) > below f4 there is a sip/2.0 200 ok on its own? Will fix. > 3.5: table 2: xmpp From/To -> from/to Will fix. > ex f9: where is juliets own presence in msrp? Good catch. Will fix. > ex f11: where is juliets own presence with code 110? Will fix. > ex f14: mapping to Message-ID does msrp have a > concept of room history? I'm not sure. > 3.6.2: do we have an equivalent disco feature for muc? No, it's assumed by support for 'http://jabber.org/protocol/muc'. > 3.7: does xmpp still support the when in muc? In IRC > this has caused PART spam Yes: http://xmpp.org/extensions/xep-0045.html#changepres > 4.1: ex f5: lack of error until when? must wait until receiving > 110 status? We might way "within a reasonable amount of time, such as 5 seconds". > 4.4: presence broadcast before ack? must buffer until receiving > 110 ack? Your comment is a bit cryptic. Would you please expand it? > 4.5.1: use message id instead of guessing? Good idea. Thanks for the feedback! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSP7+iAAoJEOoGpJErxa2p658P/Rau0avsqCSulg1MmKj2YBrQ I6VCkLROogGZ7HU2UvARdey4btzmbmZt4QJgJeCf31DV08KqkXnEdiGuJi1i/4AA lcKiCmPR4F5XOEOee50z0p3Ol/jRSBACljVClKTHlyr6k0aT8ZO3AufhxZSVPfLb QfxG08uudwXzgNoodup1cJnPfCLj32cGop8WqexWEeLmCEYQYGdkrPAEBz57AC56 KsCP9AIfs/Y6KLJ/LF0ap49fuv6klWQ9QOBocQDU8fd8MpzZkeHn+nR8g+EpfA9W KFAYJ+HI9/ZQ2BhAFm7xHf8K3Iez9W4FkSTyO11w3M30vyChS32U/l5YBOcXxwRM ejwLfpNaD2aLoMYZgHWR5fgOox7r24sRu+/74eHzeuH83lkkE+CVzYy272HFxRWY qufE5m/4Tss02WpY5Aw1DSqIruEVZ6Z1IQF0Oy4iBLFxyKO7XTiG38xy8PaDL3J7 6O1vcDC2fHMPQ6b+45R2mhssevpLOPDEIDbgd3Feql4LzSjsrCQaKa12gp6jvFmm DMguJGHYXq6wvM2fN3GH4y/T5v0DKbH/y2VZq+ZIn9t8QxoJbo8ysFCpu6yvH5r9 zg5qvmB6n5rMEe+KxCx8WxmUDDwAB9wjKAy3Qm9topD5nSnjd2K+OFwv/bvTfII/ Vmqa8IKbS0bNxgo14XIo =XPXt -----END PGP SIGNATURE----- From fippo@goodadvice.pages.de Sun Sep 22 22:58: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 D698011E8195 for ; Sun, 22 Sep 2013 22:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_20=-0.74, 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 deHHksXGHmVc for ; Sun, 22 Sep 2013 22:57:56 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id C183911E8199 for ; Sun, 22 Sep 2013 22:57:55 -0700 (PDT) Received: from [192.168.2.100] (p54972204.dip0.t-ipconnect.de [84.151.34.4]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8N5vrLX005270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Sep 2013 07:57:54 +0200 Message-ID: <523FD85C.6010600@goodadvice.pages.de> Date: Mon, 23 Sep 2013 07:57:48 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stox@ietf.org References: <5203E484.4050902@goodadvice.pages.de> <523FBFA2.3050902@stpeter.im> In-Reply-To: <523FBFA2.3050902@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Stox] review of core, chat, groupchat and presence 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, 23 Sep 2013 05:58:02 -0000 > Thanks again for the review. Comments inline. As before, removing items done. new nit: [length] looks like it should be replaced with the examples actual length in three places. Only seen in -groupchat. [...] >> example f3 is not shown > > I don't feel that we need to show every 200 OK. Yes, we put the > example in example.com, but sometimes you really can have too many > examples. :-) Right. But then it might make sense to either add a "not shown" marker in the ascii art or not number them. I'll check if that happens often enough to make sense. [...] >> 4.4: presence broadcast before ack? must buffer until receiving >> 110 ack? > > Your comment is a bit cryptic. Would you please expand it? Hah, that was the only comment you found cryptic? :-) btw: it might make sense to reuse the caption from XEP-0045 (7.2.3 Presence Broadcast) for the caption of F7 (which is raw, unbridled xmpp and not translated; current text seems copy-paste from F11 in sect 3.5): "Service Sends Presence from Existing Occupants to New Occupant" Now the attempt to decipher my comments: First part: In MUC, the participant lists is sent to the new occupant (muc example 21) before the new occupants own presence (muc example 24) and therefore potentially before any acknowledgements that might be required on the MSRP side. Is that a problem? Second part: In example F10, two (or more) stanzas are translated into a single event. Unless you can do partial updates (Emil? I think you mentioned such a thing for COIN) here, the gateway needs to know when it can dispatch example 4.4 -- upon receiving the participants own presence, which might come with a 110 status code. Since I don't think all xmpp serveers do 110, i think there is some text required that the gateway needs to be able to recognize the self-presence and not mistake it as part of the participants list. (should it be participant_s_ presence in the caption?) Is that clearer? From stpeter@stpeter.im Mon Sep 23 16:45:56 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 01B4921F8FF5 for ; Mon, 23 Sep 2013 16:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.897 X-Spam-Level: X-Spam-Status: No, score=-101.897 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 Cx2lp3SeZIyr for ; Mon, 23 Sep 2013 16:45:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 185A921F8F6D for ; Mon, 23 Sep 2013 16:45:37 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9A163415F9; Mon, 23 Sep 2013 17:50:43 -0600 (MDT) Message-ID: <5240D29F.9070901@stpeter.im> Date: Mon, 23 Sep 2013 17:45:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Salvatore Loreto References: <523C17B9.2070408@ericsson.com> <523C2690.6090306@ericsson.com> In-Reply-To: <523C2690.6090306@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] review: stox-im-03 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, 23 Sep 2013 23:45:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sal, thanks for the review. On 9/20/13 4:42 AM, Salvatore Loreto wrote: > my only comments is about the fact that section 3. XMPP to SIP > implies that the MESSAGE is always (and maybe can only be) > delivered over a TCP connection; RFC3428 states > > Whenever possible, MESSAGE requests SHOULD be sent over transports > that implement end-to-end congestion control, such as TCP or SCTP. > However, SIP does not provide a mechanism to prevent a downstream > hop from sending a request over UDP. > > so you can delivery it over UDP as well and that has also being > raised in a previous thread while talking on the Call-ID mapping to > . Actually you will be forced to deliver over UDP if the > SIMPLE server only supports UDP. It's not clear to me why the XMPP-to-SIP gateway couldn't communicate with the SIMPLE server over UDP. Which text in Section 3 do you think implies that only TCP connections are supported? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQNKeAAoJEOoGpJErxa2p4GsP/i2SppGYjm4g1tOel6+z4G+q zmhA+198I9ETLhCGP340z0g/eR/E0mZazti4d/82mMdQuxaAYL4ECCBCcEfWOdi7 8jyt1HrGNX73rYI9cF4PN7b07REu4A7KIHzPmHme8RrAceuizkyts7sQtIiNcjoY bA+zIduglXWOsYRkIhLPQtT3MX5//wERzdtwjtP0SC9TiuioOXkr0gRQl2rjPY/D /kI3fT1XppxMdyaMO7tCkYcgzeXBKpFExpDmFXcKDuVGQfYIwsHsj58iZo9WgGf8 rJXJhGeUcm4sU4HordkkfcD7h2QKyikoYAcyqyFNdfyW756psG2H/OV2eg4TJ6Zp Z9mpcel1QY44CByT6Mzy722JbFl9QYrB1KhjgspuGABZxRcAkKEO+z4prGNuvXHF y4c2q1yPaPxJFUQw5IgJUddqo+U7NXpI2w5Jg5Jrb557hPlKPTivIrfrUvCMJVR5 0ck1mfrrX6wMQU0vH5cASYYBZgwGtHlqcdVOCNSssl26FIvfaVUvaLW9SkcMR4OD EoW18vZ7XvrK6fJ8ec4tMIF6Cng/R1QM/MPpkgBTMBcPGmilAlGB+jBr8GAtwuql kzSl91IVZwMI66Fimi/knjaJCwotBdY7jjqa8CYHIvXhsZcma5wSyb37IwP1bTTN l+3Dhvz1tB4444evLgcG =5aYJ -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Sep 23 16:54:39 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 A405511E80FC for ; Mon, 23 Sep 2013 16:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.885 X-Spam-Level: X-Spam-Status: No, score=-101.885 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 AOuzh5x9uMR5 for ; Mon, 23 Sep 2013 16:54:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 43B0911E80FB for ; Mon, 23 Sep 2013 16:54:35 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 27F5B415F9; Mon, 23 Sep 2013 17:59:43 -0600 (MDT) Message-ID: <5240D4BA.3090108@stpeter.im> Date: Mon, 23 Sep 2013 17:54:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Salvatore Loreto References: <523C17B9.2070408@ericsson.com> In-Reply-To: <523C17B9.2070408@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] review: stox-core-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: Mon, 23 Sep 2013 23:54:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/20/13 3:39 AM, Salvatore Loreto wrote: > I have reviewed the core-04 draft, and I think that is almost ready > for the WGLC > > I have one general comment (btw I apologize in advance if this has > already been discussed and I have overlooked or forgot it) and it > is about the fact that draft does not talk at all about the inter > working when secure URIs are involved. I think that at least we > should say something about in the Security consideration. Good catch. After reading and re-reading Section 26.4.4 of RFC 3261, I have to admit that I'm not sure exactly how SIP entities are supposed to handle SIPS URIs. Even if we understand those requirements, I'm also not sure how they would apply to the XMPP side of the communications path. At the least, it seems we'd want to specify that if the To header or Request-URI is a SIPS URI, then the SIP-to-XMPP gateway needs to connect to the XMPP server over a TLS-protected stream. However, do we also need to stipulate that the XMPP server-to-client connection is TLS-protected? If so, how would the gateway associated with the XMPP server ensure that? (The gateway might be an external component of the XMPP server, without control over how the XMPP server communicates with XMPP clients.) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQNS6AAoJEOoGpJErxa2pueYQAJFMEL4C00F37XDdk9uvADsP 3MM9Si1gIYTmIdI4bW4HY8A5LfggByoT17SD/fYjDoescHfhxO4nb8EP/ElUq0lY uTeUBl9fi+PQUwQweZS4O/inQAucUTWjf6NAk3x4ETN6ct0dUwXgzj1avmu7oO9G t4STEtxtxSHMMjFUacCyHxTYp0b9fSCExUScsGHeM7RJtS4oUrxI8Rb8QNDH8bZV CFo52opkkYBkjZFfIjMGHLzrMNR66G0C9Cbvx+SIy1hhM2iCqWtS50+KMcWBzg7c Vog96pNL/li27U18ZAR5kXMT7hbNj/eV2Na6WXPw0ITJ1LtcR2TNbyvJ66U//b0g Ba5R6Dwk7QfBjW1MQ1W79VOZsRga9RYjEuxKtJ+acZeoL/kLSikEZn0o1N+FXtzt A0sR0Hovx6jyPDodkrP4R62uhdUdDWXIcLgVOiNTtS9Hbu+RPhDOmsvAA/OyFt23 u8nqBLocb57Mxwvk2b9FMGrBa5aQD2dsSiyfEXtMDlOYlxlBYa7vBoVyI8GPLIbm sTRPDjN0NvAmokzSWlcA8T2PwnXu06N3UOctw7eVZPoFIE6yk0t/kMNhofMxq/EV 4K+tnU1I3w/irDTYA8g3zRfCpbs+RlmGG9pgpN9iOFdas9AQe1jS1rZp3H8C/TGU DM4DbC4CrD0Itj2y0pBp =VUg1 -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Sep 23 17:25:37 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 5D12621F9C7B for ; Mon, 23 Sep 2013 17:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.876 X-Spam-Level: X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=-0.147, 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 QILFDgQo0qpt for ; Mon, 23 Sep 2013 17:25:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CD9D521F9B21 for ; Mon, 23 Sep 2013 17:25:32 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2FCE5415F9; Mon, 23 Sep 2013 18:30:40 -0600 (MDT) Message-ID: <5240DBFB.4010607@stpeter.im> Date: Mon, 23 Sep 2013 18:25:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Philipp Hancke References: <5203E484.4050902@goodadvice.pages.de> <523FBFA2.3050902@stpeter.im> <523FD85C.6010600@goodadvice.pages.de> In-Reply-To: <523FD85C.6010600@goodadvice.pages.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] review of core, chat, groupchat and presence 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, 24 Sep 2013 00:25:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/13 11:57 PM, Philipp Hancke wrote: >> Thanks again for the review. Comments inline. > > As before, removing items done. > > new nit: [length] looks like it should be replaced with the > examples actual length in three places. Only seen in -groupchat. Will fix. > [...] >>> example f3 is not shown >> >> I don't feel that we need to show every 200 OK. Yes, we put the >> example in example.com, but sometimes you really can have too >> many examples. :-) > > Right. But then it might make sense to either add a "not shown" > marker in the ascii art or not number them. I'll check if that > happens often enough to make sense. Well, maybe we'll just add the examples for the sake of completeness. > [...] >>> 4.4: presence broadcast before ack? must buffer until >>> receiving 110 ack? >> >> Your comment is a bit cryptic. Would you please expand it? > > Hah, that was the only comment you found cryptic? :-) I think that I managed to decryptify the others. ;-) > btw: it might make sense to reuse the caption from XEP-0045 (7.2.3 > Presence Broadcast) for the caption of F7 (which is raw, unbridled > xmpp and not translated; current text seems copy-paste from F11 in > sect 3.5): "Service Sends Presence from Existing Occupants to New > Occupant" WFM. > Now the attempt to decipher my comments: First part: In MUC, the > participant lists is sent to the new occupant (muc example 21) > before the new occupants own presence (muc example 24) and > therefore potentially before any acknowledgements that might be > required on the MSRP side. Is that a problem? Well, neither RFC 4975 nor draft-ietf-simple-chat really specifies the handling of participant lists. There is a passing mention in the latter document, but it's not very detailed: Typically the conference focus acts as a notifier of the conference event package, RFC 4575 [RFC4575]. It is RECOMMENDED that conference foci and endpoints support RFC 6502 [RFC6502] for providing information regarding the conference, and in particular, supplying information of the roaster of the conference. It is also RECOMMENDED that conference foci and endpoints support RFC 6501 [RFC6501], which extends the element originally specified in RFC 4575 [RFC4575] with a new 'nickname' attribute. This allows endpoints to learn the nicknames of participants of the chat room. However, in draft-ietf-stox-groupchat we assume that the conference focus does support the conference-info package for the room roster. [ Hopefully the RFC Editor will correct "roaster" to "roster" :-) ] > Second part: In example F10, two (or more) stanzas are translated > into a single event. Unless you can do partial updates (Emil? I > think you mentioned such a thing for COIN) here, the gateway needs > to know when it can dispatch example 4.4 -- upon receiving the > participants own presence, which might come with a 110 status code. > That's all correct. > Since I don't think all xmpp serveers do 110, i think there is some > text required that the gateway needs to be able to recognize the > self-presence and not mistake it as part of the participants list. > (should it be participant_s_ presence in the caption?) The SIP-to-XMPP gateway will need to maintain state about the MSRP session that the SIP user agent has requested. This implies that the gateway will need to know the user's SIP URI and the mapping of that URI into an XMPP address, then based on that mapping determine when it has received a complete room roster from the MUC room (with or without a 110 status code), i.e., when it has received the in-room presence of the SIP user (which according to XEP-0045 is the last presence stanza received in the initial batch sent after joining). Once that happens, the SIP-to-XMPP gateway can construct the conference-info document containg the complete room roster and send that to the SIP user. And yes, we need to make that clear in the spec. > Is that clearer? Yes, thanks. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQNv7AAoJEOoGpJErxa2pEyEQAIHGdqVKbOennCCZDfRpK9pp R053CSZHn/ejjzO7uHKvMDUStC5SZ9dknP7AKR5UhxzEqp+JxSLGQSLthaeaI+qc v8POpg2CZKyEujsgpKBqjAFh5Ju/zCH776LznHh0g6ih5agHIizKd+nibAgICAdd AwL0NjNFGsXGj0JJAJaXPeMTL6oX4uRTfXkNNaSmnEZHZjQPB/fUG8MNhMpizGe2 yhKbs5MLkfxspTLK5nEovfhfxticXLv/lRPjSUgfEfUj9eF56tcfkvv/SMUWHiTt 1W8d5IsvvcWmGA+ld5md1IZiDXjivxenQh9fBYs05B4w8lQtdFlVWrtRKngxul3F FQP/dq+58Rz33TQH0zN6MBD1RCouACsoJbdruI0oXjCHwLAxdTmYiIVY07PAZ3b2 vV6XWhkh332EZdsfD1GsuC6XcVe8t8Jr41J6Lx3utED85PvkY7fqbpdBHpqx7iCF MU+pOsiCGe+YewWgCZNjosJ+X2BBDh2OMh6kF+mrr80+2BhvqN1qQTm5uVo3g5XD v5Hmr+0Gpx9e7QgU9FfbMaB+YyMMX7ADSRjoJXG0AcL2F5afXq7vRBcc0y90iI0r tkCEHgKafCVB+0EjZd1TFVX2sbSVDeljCwxvOhIzfbW4z/WKG0qfvbp689dWMjr4 ZZzfSyaEokN7oc4AMv9j =BPvj -----END PGP SIGNATURE----- From salvatore.loreto@ericsson.com Mon Sep 23 23:03: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 C4DD021F9D44 for ; Mon, 23 Sep 2013 23:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.756 X-Spam-Level: X-Spam-Status: No, score=-104.756 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 9-iujMEYrFpN for ; Mon, 23 Sep 2013 23:02:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC8821F9DCE for ; Mon, 23 Sep 2013 23:02:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-d3-52412b12e26c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 50.E8.16099.21B21425; Tue, 24 Sep 2013 08:02:58 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Tue, 24 Sep 2013 08:02:58 +0200 Received: from Salvatore-Loretos-MacBook-Pro.local (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 014A011045A; Tue, 24 Sep 2013 09:02:57 +0300 (EEST) Message-ID: <52412B11.1030305@ericsson.com> Date: Tue, 24 Sep 2013 09:02:57 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Saint-Andre References: <523C17B9.2070408@ericsson.com> <523C2690.6090306@ericsson.com> <5240D29F.9070901@stpeter.im> In-Reply-To: <5240D29F.9070901@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3VldI2zHI4OV3FYv/O5pYLY7t6Wd2 YPJYsuQnk8fcPS+YA5iiuGxSUnMyy1KL9O0SuDK+dB9mKTgvVPHx127WBsZ7/F2MnBwSAiYS Xz7NZoSwxSQu3FvPBmILCRxmlLh8CijOBWRvYJQ4sW82M0TiGKPE1IURXYwcHLwC2hINj0tA wiwCqhKLd19hAbHZBMwknj/cAlYuKpAs0XT5PlicV0BQ4uTMJ2C2iICWxKVrfewgNrOAsETn /U5GkJHCAmoSJ/4lQWzKlFjzbhPYGE6g8icftzFBlNtKXJhznQXClpfY/nYO1GVaEr1nO5km MArNQrJtFpKWWUhaFjAyr2Jkz03MzEkvN9zECAzTg1t+6+5gPHVO5BCjNAeLkjjvJr0zgUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYtf6c/DS30fPlCo1fHkVC6ksZEiKq/ydtXZxo/cf5 7G3Dcze+TpE10vld/mvDaqUg2X2hER84vIo2T1rYk7/kM6tAFq9qziXx2w/v5X9W7Ju/N8Ll zQZ9xaefzrRPOGo2MfBFH8fKFa+ZHjQftdKd45nz7nPvP9b3Z5c+y1397HhLT61n0ILDckos xRmJhlrMRcWJADzV6UQhAgAA Cc: stox@ietf.org Subject: Re: [Stox] review: stox-im-03 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, 24 Sep 2013 06:03:04 -0000 On 9/24/13 2:45 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Sal, thanks for the review. > > On 9/20/13 4:42 AM, Salvatore Loreto wrote: > >> my only comments is about the fact that section 3. XMPP to SIP >> implies that the MESSAGE is always (and maybe can only be) >> delivered over a TCP connection; RFC3428 states >> >> Whenever possible, MESSAGE requests SHOULD be sent over transports >> that implement end-to-end congestion control, such as TCP or SCTP. >> However, SIP does not provide a mechanism to prevent a downstream >> hop from sending a request over UDP. >> >> so you can delivery it over UDP as well and that has also being >> raised in a previous thread while talking on the Call-ID mapping to >> . Actually you will be forced to deliver over UDP if the >> SIMPLE server only supports UDP. > It's not clear to me why the XMPP-to-SIP gateway couldn't communicate > with the SIMPLE server over UDP. Which text in Section 3 do you think > implies that only TCP connections are supported? there is not text at all, and that is the problem. When I read the Section 3 and the example I got the impression that I can only use TCP to forward the message on the SIP side but maybe it is only me! cheers Salvatore > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSQNKeAAoJEOoGpJErxa2p4GsP/i2SppGYjm4g1tOel6+z4G+q > zmhA+198I9ETLhCGP340z0g/eR/E0mZazti4d/82mMdQuxaAYL4ECCBCcEfWOdi7 > 8jyt1HrGNX73rYI9cF4PN7b07REu4A7KIHzPmHme8RrAceuizkyts7sQtIiNcjoY > bA+zIduglXWOsYRkIhLPQtT3MX5//wERzdtwjtP0SC9TiuioOXkr0gRQl2rjPY/D > /kI3fT1XppxMdyaMO7tCkYcgzeXBKpFExpDmFXcKDuVGQfYIwsHsj58iZo9WgGf8 > rJXJhGeUcm4sU4HordkkfcD7h2QKyikoYAcyqyFNdfyW756psG2H/OV2eg4TJ6Zp > Z9mpcel1QY44CByT6Mzy722JbFl9QYrB1KhjgspuGABZxRcAkKEO+z4prGNuvXHF > y4c2q1yPaPxJFUQw5IgJUddqo+U7NXpI2w5Jg5Jrb557hPlKPTivIrfrUvCMJVR5 > 0ck1mfrrX6wMQU0vH5cASYYBZgwGtHlqcdVOCNSssl26FIvfaVUvaLW9SkcMR4OD > EoW18vZ7XvrK6fJ8ec4tMIF6Cng/R1QM/MPpkgBTMBcPGmilAlGB+jBr8GAtwuql > kzSl91IVZwMI66Fimi/knjaJCwotBdY7jjqa8CYHIvXhsZcma5wSyb37IwP1bTTN > l+3Dhvz1tB4444evLgcG > =5aYJ > -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Sep 24 05:35: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 2F81021F9A16 for ; Tue, 24 Sep 2013 05:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.839 X-Spam-Level: X-Spam-Status: No, score=-101.839 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FUZZY_VLIUM=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 yEVIOLTTLWb0 for ; Tue, 24 Sep 2013 05:35:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE3021F99ED for ; Tue, 24 Sep 2013 05:35:37 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1DC9A415DF; Tue, 24 Sep 2013 06:40:47 -0600 (MDT) Message-ID: <52418719.4060401@stpeter.im> Date: Tue, 24 Sep 2013 06:35:37 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Salvatore Loreto References: <523C17B9.2070408@ericsson.com> <523C2690.6090306@ericsson.com> <5240D29F.9070901@stpeter.im> <52412B11.1030305@ericsson.com> In-Reply-To: <52412B11.1030305@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] review: stox-im-03 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, 24 Sep 2013 12:35:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/24/13 12:02 AM, Salvatore Loreto wrote: > On 9/24/13 2:45 AM, Peter Saint-Andre wrote: Hi Sal, thanks for the > review. > > On 9/20/13 4:42 AM, Salvatore Loreto wrote: > >>>> my only comments is about the fact that section 3. XMPP to >>>> SIP implies that the MESSAGE is always (and maybe can only >>>> be) delivered over a TCP connection; RFC3428 states >>>> >>>> Whenever possible, MESSAGE requests SHOULD be sent over >>>> transports that implement end-to-end congestion control, such >>>> as TCP or SCTP. However, SIP does not provide a mechanism to >>>> prevent a downstream hop from sending a request over UDP. >>>> >>>> so you can delivery it over UDP as well and that has also >>>> being raised in a previous thread while talking on the >>>> Call-ID mapping to . Actually you will be forced to >>>> deliver over UDP if the SIMPLE server only supports UDP. > It's not clear to me why the XMPP-to-SIP gateway couldn't > communicate with the SIMPLE server over UDP. Which text in Section > 3 do you think implies that only TCP connections are supported? >> there is not text at all, and that is the problem. When I read >> the Section 3 and the example I got the impression that I can >> only use TCP to forward the message on the SIP side but maybe it >> is only me! I doubt it is only you. :-) Because there is no such thing as XMPP over UDP, the gateway from SIP to XMPP will need to communicate over TCP. However, I see no reason why the gateway from XMPP to SIP could not be "smart" and send SIP messages over TCP or UDP depending on what the far SIP server supports. I'll work to add some clarifying text on these points. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQYcZAAoJEOoGpJErxa2ppRwP/3qjYeINoTqqJRlMDYj+BUfH 0h3HzIB/V2gMINn7n7vN0Nwm0e2uniTzmTkzj30d4H0Qc6kNwzaCJpdINpQItJHZ Sb7Mg03DbTfhhrfL+L5m6eM3NtAiTsq6TzoLkhYRXtTEFNaDC/6VuBI+KFqmQWie M8znm+eQ+3RHSCVWUzH4my6KHvQca8SV864RjvfAjDZCP3iDILE9NyTh2PlRE8Pk pArridDLgecU/jX+70fUJs0pMs2yOeOfnbkf8FR70wWVyOs3iw2jcNfWq1aawJjX FZvDrsRpky3TCxreE2roxSP0Y0sEq4wghPozuzWrYrt47P7HEke2sD/VJx7QIdIK gac7vvo2FK3b/CoDyMwY5R7iTPPltG1Uhn/3WvOMLRGKTqqjbhGfRbM0uu7VzVSc W85JJ0HyU8sPXDdHW1Ur1IVMCgBii3LggKwqPSyZw/lbD0LFraPUiViP+m04XoHn N4ZgPDFpj3uBBK1Tvoh1aPEykUkLNJqW+wQjH/ou3qj5WqURi5Z5UZf5uEItj2ZE N6dOajLoJ1Li5F4EbNM1z/TsHNp906KDk0TpOb7pcD2MTw62DwytoQhMCIJBjRod 2dKd8+3hwwC14Lt3jDncHYUpG/PBoUYDBfeJH2ne4FjqOEJSwCVcYGN+L4FlMjon 49mjfp3uxcFNzxnwiork =VAX3 -----END PGP SIGNATURE----- From salvatore.loreto@ericsson.com Tue Sep 24 05:37: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 E1AB321F9946 for ; Tue, 24 Sep 2013 05:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.378 X-Spam-Level: X-Spam-Status: No, score=-105.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_VLIUM=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 OV6FL3PdkMKQ for ; Tue, 24 Sep 2013 05:37:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC6EA11E812A for ; Tue, 24 Sep 2013 05:37:02 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-84-5241876d9830 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C2.3B.16099.D6781425; Tue, 24 Sep 2013 14:37:01 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.228]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 24 Sep 2013 14:37:01 +0200 From: Salvatore Loreto To: "stpeter@stpeter.im" Thread-Topic: [Stox] review: stox-im-03 Thread-Index: Ac65IsO1p7JAEQL9aEmO5oEIBkR/Dw== Date: Tue, 24 Sep 2013 12:37:00 +0000 Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A2A443A@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvrW5uu2OQQXe7ssX/HU2sFsf29DM7 MHksWfKTyWPunhfMAUxRXDYpqTmZZalF+nYJXBmdzy6zFmyRrDi64gpbA+M90S5GTg4JAROJ f58us0DYYhIX7q1n62Lk4hASOMwo8f7vZ3YIZwmjxLxtbxlBqtgEzCSeP9zCDGKLCOhK3Pxy AaiIg4NZQFni0BRZEFNYQE3ixL8kiAp1iZPLzrNB2HoSt69cAdvFIqAqMXXiVTCbV8BbYlfP SlYQmxHohu+n1jCB2MwC4hK3nsxngrhNQGLJnvPMELaoxMvH/1ghbCWJHxsusUDU60gs2P2J DcLWlli28DUzxHxBiZMzn7BMYBSZhWTsLCQts5C0zELSsoCRZRUje25iZk56ueEmRmDAH9zy W3cH46lzIocYpTlYlMR5N+mdCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKG+bdP/1z2lV FW5tiukFgVvL/TJXFEx9LWNkczo65+Lt/eVecTG3c0/+bBfhdyt8uLS9e5u6wZfk0/s37Fr/ YOmGpSXNh7gPXMgPd2a9Yunsu8SgMZTz0PE3az0225i6n7pmz68fsZ7bjjmr8rbdby+9+KpV na6Z8i1GKWuSK+b+zQuJUliixFKckWioxVxUnAgACZ3PwkYCAAA= Cc: "stox@ietf.org" Subject: Re: [Stox] review: stox-im-03 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, 24 Sep 2013 12:37:15 -0000 =0A= Thanks Peter=0A= =0A= =0A= --Original message---=0A= Sender: "Peter Saint-Andre" =0A= Time: Tue Sep 24 15:35:00 EEST 2013=0A= Cc: stox@ietf.org, =0A= Subject: Re: [Stox] review: stox-im-03=0A= =0A= -----BEGIN PGP SIGNED MESSAGE-----=0A= Hash: SHA1=0A= =0A= On 9/24/13 12:02 AM, Salvatore Loreto wrote:=0A= > On 9/24/13 2:45 AM, Peter Saint-Andre wrote: Hi Sal, thanks for the=0A= > review.=0A= > =0A= > On 9/20/13 4:42 AM, Salvatore Loreto wrote:=0A= > =0A= >>>> my only comments is about the fact that section 3. XMPP to=0A= >>>> SIP implies that the MESSAGE is always (and maybe can only=0A= >>>> be) delivered over a TCP connection; RFC3428 states=0A= >>>> =0A= >>>> Whenever possible, MESSAGE requests SHOULD be sent over=0A= >>>> transports that implement end-to-end congestion control, such=0A= >>>> as TCP or SCTP. However, SIP does not provide a mechanism to=0A= >>>> prevent a downstream hop from sending a request over UDP.=0A= >>>> =0A= >>>> so you can delivery it over UDP as well and that has also=0A= >>>> being raised in a previous thread while talking on the=0A= >>>> Call-ID mapping to . Actually you will be forced to=0A= >>>> deliver over UDP if the SIMPLE server only supports UDP.=0A= > It's not clear to me why the XMPP-to-SIP gateway couldn't=0A= > communicate with the SIMPLE server over UDP. Which text in Section=0A= > 3 do you think implies that only TCP connections are supported?=0A= >> there is not text at all, and that is the problem. When I read=0A= >> the Section 3 and the example I got the impression that I can=0A= >> only use TCP to forward the message on the SIP side but maybe it=0A= >> is only me!=0A= =0A= I doubt it is only you. :-)=0A= =0A= Because there is no such thing as XMPP over UDP, the gateway from SIP=0A= to XMPP will need to communicate over TCP. However, I see no reason=0A= why the gateway from XMPP to SIP could not be "smart" and send SIP=0A= messages over TCP or UDP depending on what the far SIP server=0A= supports. I'll work to add some clarifying text on these points.=0A= =0A= Peter=0A= =0A= - -- =0A= Peter Saint-Andre=0A= https://stpeter.im/=0A= =0A= =0A= -----BEGIN PGP SIGNATURE-----=0A= Version: GnuPG/MacGPG2 v2.0.19 (Darwin)=0A= Comment: GPGTools - http://gpgtools.org=0A= Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/=0A= =0A= iQIcBAEBAgAGBQJSQYcZAAoJEOoGpJErxa2ppRwP/3qjYeINoTqqJRlMDYj+BUfH=0A= 0h3HzIB/V2gMINn7n7vN0Nwm0e2uniTzmTkzj30d4H0Qc6kNwzaCJpdINpQItJHZ=0A= Sb7Mg03DbTfhhrfL+L5m6eM3NtAiTsq6TzoLkhYRXtTEFNaDC/6VuBI+KFqmQWie=0A= M8znm+eQ+3RHSCVWUzH4my6KHvQca8SV864RjvfAjDZCP3iDILE9NyTh2PlRE8Pk=0A= pArridDLgecU/jX+70fUJs0pMs2yOeOfnbkf8FR70wWVyOs3iw2jcNfWq1aawJjX=0A= FZvDrsRpky3TCxreE2roxSP0Y0sEq4wghPozuzWrYrt47P7HEke2sD/VJx7QIdIK=0A= gac7vvo2FK3b/CoDyMwY5R7iTPPltG1Uhn/3WvOMLRGKTqqjbhGfRbM0uu7VzVSc=0A= W85JJ0HyU8sPXDdHW1Ur1IVMCgBii3LggKwqPSyZw/lbD0LFraPUiViP+m04XoHn=0A= N4ZgPDFpj3uBBK1Tvoh1aPEykUkLNJqW+wQjH/ou3qj5WqURi5Z5UZf5uEItj2ZE=0A= N6dOajLoJ1Li5F4EbNM1z/TsHNp906KDk0TpOb7pcD2MTw62DwytoQhMCIJBjRod=0A= 2dKd8+3hwwC14Lt3jDncHYUpG/PBoUYDBfeJH2ne4FjqOEJSwCVcYGN+L4FlMjon=0A= 49mjfp3uxcFNzxnwiork=0A= =3DVAX3=0A= -----END PGP SIGNATURE-----= From stpeter@stpeter.im Tue Sep 24 05:40:17 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 B57A711E812E for ; Tue, 24 Sep 2013 05:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.834 X-Spam-Level: X-Spam-Status: No, score=-101.834 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 AceuEkaELq3D for ; Tue, 24 Sep 2013 05:40:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1420F11E8121 for ; Tue, 24 Sep 2013 05:40:11 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0D1CD415DF; Tue, 24 Sep 2013 06:45:21 -0600 (MDT) Message-ID: <5241882B.6000203@stpeter.im> Date: Tue, 24 Sep 2013 06:40:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Salvatore Loreto References: <2B9B48179856DC4FA00C93C79EB7E64A2A443A@ESESSMB109.ericsson.se> In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A2A443A@ESESSMB109.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stox@ietf.org" Subject: Re: [Stox] review: stox-im-03 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, 24 Sep 2013 12:40:17 -0000 Oh, and this text probably belongs in the -core document, I think... On 9/24/13 6:37 AM, Salvatore Loreto wrote: > > Thanks Peter > > > --Original message--- > Sender: "Peter Saint-Andre" > Time: Tue Sep 24 15:35:00 EEST 2013 > Cc: stox@ietf.org, > Subject: Re: [Stox] review: stox-im-03 > > On 9/24/13 12:02 AM, Salvatore Loreto wrote: >> On 9/24/13 2:45 AM, Peter Saint-Andre wrote: Hi Sal, thanks for the >> review. > >> On 9/20/13 4:42 AM, Salvatore Loreto wrote: > >>>>> my only comments is about the fact that section 3. XMPP to >>>>> SIP implies that the MESSAGE is always (and maybe can only >>>>> be) delivered over a TCP connection; RFC3428 states >>>>> >>>>> Whenever possible, MESSAGE requests SHOULD be sent over >>>>> transports that implement end-to-end congestion control, such >>>>> as TCP or SCTP. However, SIP does not provide a mechanism to >>>>> prevent a downstream hop from sending a request over UDP. >>>>> >>>>> so you can delivery it over UDP as well and that has also >>>>> being raised in a previous thread while talking on the >>>>> Call-ID mapping to . Actually you will be forced to >>>>> deliver over UDP if the SIMPLE server only supports UDP. >> It's not clear to me why the XMPP-to-SIP gateway couldn't >> communicate with the SIMPLE server over UDP. Which text in Section >> 3 do you think implies that only TCP connections are supported? >>> there is not text at all, and that is the problem. When I read >>> the Section 3 and the example I got the impression that I can >>> only use TCP to forward the message on the SIP side but maybe it >>> is only me! > > I doubt it is only you. :-) > > Because there is no such thing as XMPP over UDP, the gateway from SIP > to XMPP will need to communicate over TCP. However, I see no reason > why the gateway from XMPP to SIP could not be "smart" and send SIP > messages over TCP or UDP depending on what the far SIP server > supports. I'll work to add some clarifying text on these points. > > Peter > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Sep 24 19:18:09 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 2A4EF11E81A6 for ; Tue, 24 Sep 2013 19:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 yCpmjh1g7J5D for ; Tue, 24 Sep 2013 19:18:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6F00711E81A4 for ; Tue, 24 Sep 2013 19:17:59 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 115FD415F4; Tue, 24 Sep 2013 20:23:09 -0600 (MDT) Message-ID: <524247D5.4040406@stpeter.im> Date: Tue, 24 Sep 2013 20:17:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Salvatore Loreto References: <2B9B48179856DC4FA00C93C79EB7E64A2A443A@ESESSMB109.ericsson.se> <5241882B.6000203@stpeter.im> In-Reply-To: <5241882B.6000203@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stox@ietf.org" Subject: Re: [Stox] review: stox-im-03 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: Wed, 25 Sep 2013 02:18:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is proposed text for placement at the end of Section 4 ("Interdomain Federation") in the -core document: Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from SIP to XMPP will need to support TCP as the underlying transport protocol. By contrast, as specified in [RFC3261], either TCP or UDP can be used as the underlying transport for SIP messages, and a given SIP deployment might support only UDP; therefore, a gateway from XMPP to SIP might need to communicate with a SIP service using either TCP or UDP. Peter On 9/24/13 6:40 AM, Peter Saint-Andre wrote: > Oh, and this text probably belongs in the -core document, I > think... > > On 9/24/13 6:37 AM, Salvatore Loreto wrote: >> >> Thanks Peter >> >> >> --Original message--- Sender: "Peter Saint-Andre" >> Time: Tue Sep 24 15:35:00 EEST 2013 Cc: >> stox@ietf.org, Subject: Re: [Stox] review: stox-im-03 >> >> On 9/24/13 12:02 AM, Salvatore Loreto wrote: >>> On 9/24/13 2:45 AM, Peter Saint-Andre wrote: Hi Sal, thanks for >>> the review. >> >>> On 9/20/13 4:42 AM, Salvatore Loreto wrote: >> >>>>>> my only comments is about the fact that section 3. XMPP >>>>>> to SIP implies that the MESSAGE is always (and maybe can >>>>>> only be) delivered over a TCP connection; RFC3428 states >>>>>> >>>>>> Whenever possible, MESSAGE requests SHOULD be sent over >>>>>> transports that implement end-to-end congestion control, >>>>>> such as TCP or SCTP. However, SIP does not provide a >>>>>> mechanism to prevent a downstream hop from sending a >>>>>> request over UDP. >>>>>> >>>>>> so you can delivery it over UDP as well and that has >>>>>> also being raised in a previous thread while talking on >>>>>> the Call-ID mapping to . Actually you will be >>>>>> forced to deliver over UDP if the SIMPLE server only >>>>>> supports UDP. >>> It's not clear to me why the XMPP-to-SIP gateway couldn't >>> communicate with the SIMPLE server over UDP. Which text in >>> Section 3 do you think implies that only TCP connections are >>> supported? >>>> there is not text at all, and that is the problem. When I >>>> read the Section 3 and the example I got the impression that >>>> I can only use TCP to forward the message on the SIP side but >>>> maybe it is only me! >> >> I doubt it is only you. :-) >> >> Because there is no such thing as XMPP over UDP, the gateway from >> SIP to XMPP will need to communicate over TCP. However, I see no >> reason why the gateway from XMPP to SIP could not be "smart" and >> send SIP messages over TCP or UDP depending on what the far SIP >> server supports. I'll work to add some clarifying text on these >> points. >> >> Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQkfUAAoJEOoGpJErxa2pI7AP/RPh4ufdyM5wD0psc0T+e3HG zPm/JAoCbu4mlApChuj17eCWKdV7nBKkUCO94WLIHiz0fu7CHsW0f6zhxx6n/ZVy nDiLCvmP5FifzMeewPh0zV4anFuQmQX8PwauJ2jb5p11gxMok+BefCToZIlLGb60 tvqgDwfEpRL/N+4EN6tdydBBaL6r1pXHxXWgDK1qwF9t766eW1c8iPUwn51IZekd SB+Pzr3QPvU9vAYey5jNvtv5ltPhicHkA1FKfPBj/JcTcRFuY7FJy1IGP29jY2EV 4sap6CXs8IgUa/t+vnd6UWuLuh5lO/J+uBYKepSeo/pF6wF4lmc30mPwcYfyhnUl iwqhW+HHSbfEVruovhfUed2pgwa1FPWqVMn4XJEd6JR/uX/4xj+UDfZJqfBL0ZNb HnhtuiDajfkWaSDNJCqyjr2ndmpAD9ZhVOfN8QIjTuT+KVDfWUPfJzqTCpl4qHa9 zWqcd7vr0sU4BgOOjg9FvXcJUdzvXYWn55ANUZYPEZA++EbcKdBngKBlh7g75Zqp fUQeqjkBfavvd2f3Ipc5tsWXJhDdfbwEn8hWknYVxqSU5eJzfqNeIngtwPWAgGdz QAczm9/dSZAbZqxOI7eUq6pCr2Lq0oLYgchdFk7iMJgnkxyHUsU0ZDJr+JLOcoAJ GFSmrSuS2qzMzL3F/XPS =Y5pc -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Sep 24 19:24: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 091C011E81AB for ; Tue, 24 Sep 2013 19:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.825 X-Spam-Level: X-Spam-Status: No, score=-101.825 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 dbXTmLxaBSH0 for ; Tue, 24 Sep 2013 19:23:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6764711E81A4 for ; Tue, 24 Sep 2013 19:23:58 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 12D6A415F4; Tue, 24 Sep 2013 20:29:09 -0600 (MDT) Message-ID: <5242493D.20709@stpeter.im> Date: Tue, 24 Sep 2013 20:23:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Philipp Hancke References: <5203E484.4050902@goodadvice.pages.de> <523FBFA2.3050902@stpeter.im> <523FD85C.6010600@goodadvice.pages.de> <5240DBFB.4010607@stpeter.im> In-Reply-To: <5240DBFB.4010607@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] review of core, chat, groupchat and presence 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: Wed, 25 Sep 2013 02:24:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/23/13 6:25 PM, Peter Saint-Andre wrote: > On 9/22/13 11:57 PM, Philipp Hancke wrote: >>> Thanks again for the review. Comments inline. > >> As before, removing items done. > >> new nit: [length] looks like it should be replaced with the >> examples actual length in three places. Only seen in -groupchat. > > Will fix. > >> [...] >>>> example f3 is not shown >>> >>> I don't feel that we need to show every 200 OK. Yes, we put the >>> example in example.com, but sometimes you really can have too >>> many examples. :-) > >> Right. But then it might make sense to either add a "not shown" >> marker in the ascii art or not number them. I'll check if that >> happens often enough to make sense. > > Well, maybe we'll just add the examples for the sake of > completeness. > >> [...] >>>> 4.4: presence broadcast before ack? must buffer until >>>> receiving 110 ack? >>> >>> Your comment is a bit cryptic. Would you please expand it? > >> Hah, that was the only comment you found cryptic? :-) > > I think that I managed to decryptify the others. ;-) > >> btw: it might make sense to reuse the caption from XEP-0045 >> (7.2.3 Presence Broadcast) for the caption of F7 (which is raw, >> unbridled xmpp and not translated; current text seems copy-paste >> from F11 in sect 3.5): "Service Sends Presence from Existing >> Occupants to New Occupant" > > WFM. > >> Now the attempt to decipher my comments: First part: In MUC, the >> participant lists is sent to the new occupant (muc example 21) >> before the new occupants own presence (muc example 24) and >> therefore potentially before any acknowledgements that might be >> required on the MSRP side. Is that a problem? > > Well, neither RFC 4975 nor draft-ietf-simple-chat really specifies > the handling of participant lists. There is a passing mention in > the latter document, but it's not very detailed: > > Typically the conference focus acts as a notifier of the > conference event package, RFC 4575 [RFC4575]. It is RECOMMENDED > that conference foci and endpoints support RFC 6502 [RFC6502] for > providing information regarding the conference, and in particular, > supplying information of the roaster of the conference. It is also > RECOMMENDED that conference foci and endpoints support RFC 6501 > [RFC6501], which extends the element originally specified in > RFC 4575 [RFC4575] with a new 'nickname' attribute. This allows > endpoints to learn the nicknames of participants of the chat room. > > However, in draft-ietf-stox-groupchat we assume that the > conference focus does support the conference-info package for the > room roster. > > [ Hopefully the RFC Editor will correct "roaster" to "roster" :-) > ] > >> Second part: In example F10, two (or more) stanzas are >> translated into a single event. Unless you can do partial updates >> (Emil? I think you mentioned such a thing for COIN) here, the >> gateway needs to know when it can dispatch example 4.4 -- upon >> receiving the participants own presence, which might come with a >> 110 status code. > > That's all correct. > >> Since I don't think all xmpp serveers do 110, i think there is >> some text required that the gateway needs to be able to recognize >> the self-presence and not mistake it as part of the participants >> list. (should it be participant_s_ presence in the caption?) > > The SIP-to-XMPP gateway will need to maintain state about the MSRP > session that the SIP user agent has requested. This implies that > the gateway will need to know the user's SIP URI and the mapping of > that URI into an XMPP address, then based on that mapping determine > when it has received a complete room roster from the MUC room (with > or without a 110 status code), i.e., when it has received the > in-room presence of the SIP user (which according to XEP-0045 is > the last presence stanza received in the initial batch sent after > joining). Once that happens, the SIP-to-XMPP gateway can construct > the conference-info document containg the complete room roster and > send that to the SIP user. > > And yes, we need to make that clear in the spec. Here is proposed text: Because the "room roster" is communicated in XMPP by means of multiple presence stanzas (one for each participant) whereas the participant list is communicated in SIP by means of a single conference-info document, the SIP-to-XMPP gateway will need to keep track of the user's SIP URI and the mapping of that URI into an XMPP address; then, based on that mapping, it will need to determine when it has received a complete room roster from the MUC room, i.e., when it has received the in-room presence of the SIP user (which according to XEP-0045 is the last presence stanza received in the initial batch sent after joining). Once that happens, the SIP-to-XMPP gateway can construct the conference-info document containing the complete room roster and send that to the SIP user. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQkk8AAoJEOoGpJErxa2p/kIQAJd9sCq6DvXa4VgKBLKqWigZ Cl0tTN/IFiyK/1pxsbUJ3V2gH4kKELDa2vtY3GPnuklwaFkI05e/n8VJsqWmMe+H myKWz5RYJ3899/qOGVfzFBp6l+Tx1z1aZ/+TM3Kk/KI74/Jo8ylOMPsNUdMRIXS9 cOZGV93BVrqLWtAT/0ma2vH2o4BrBHrDpwW3jpo94PSLsJxmnYgWraGdfnrrW72W LVVCNSfXgp1hwwQ2B8h/cam6pL67hcHzkr65dUyh2SIYNSh39sYqrnYFeoauXxnN qMWdZ6pYRL7pf2NsTVYD/qSxeZv3X7bKcjFVrfn/dVIuma3RRBUtTT0VIqJllufM 8sd9cto3S8+8OhNgM30Uj4eGE41rReSza5lS9yKeO9bRshFg5bOa8hpVFTl9CzHP ZbAhBtAYE7cB5Vxuh1peqwGyPCT7KJGQgu4NGmj2A8JmQTCT0BS0nDwrayBXfhmz 7xAYR11BwdNvm+Rp+02fbRnCPFLqIM1Q5Z9nlgXxS8FvtTrLJqqYfmukKN13OCjq kqeex+OOxTXLnyaurs7cJcDFQPWIWW8r7mTascwdp1WjIHQvUwmSEO5jZXuimK6x ux5Y9NuxXRm6e9lDinbyCJf/7/BTohc0DW/Eudel/gRU29L3LyDnNYQxLW8QknM9 5I3/g1VENOFtydUugWhI =5mmx -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Sep 25 13:52:44 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 5851B21F9DBD; Wed, 25 Sep 2013 13:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=-0.416, 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 CoGKvSqdtcHG; Wed, 25 Sep 2013 13:52:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7547B21F9A05; Wed, 25 Sep 2013 13:52:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130925205243.29986.8785.idtracker@ietfa.amsl.com> Date: Wed, 25 Sep 2013 13:52:43 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-core-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 20:52:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Architecture,= Addresses, and Error Handling Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-core-05.txt Pages : 18 Date : 2013-09-25 Abstract: As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-core There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-core-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-core-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Markus.Isomaki@nokia.com Fri Sep 27 04:54: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 28A4721F967F for ; Fri, 27 Sep 2013 04:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=-0.360, 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 xNkzaG+QDFEo for ; Fri, 27 Sep 2013 04:54:08 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 98A7121F99E8 for ; Fri, 27 Sep 2013 04:54:04 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8RBhF4A015591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 27 Sep 2013 14:43:15 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.224]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0136.001; Fri, 27 Sep 2013 11:43:15 +0000 From: To: , , , Thread-Topic: SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-04 Thread-Index: Ac67dlH5EGOYZG19TBikH7B+J+lQvw== Date: Fri, 27 Sep 2013 11:43:14 +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: 2PrCjJ7f5poVv9TjWbkmknDJpXPw7WE8ChV/db8mkahw5MISpLcagY0XhXESR7pR5DXNxXX9RUkhax3VmNpYXAM5mP/FbyEqTb7Es2OTH/hFo2IYamy+LNWHywEXLMcpZwPvw+44PgJZYPJEns75Dn4Fgz4vpSYBqGg/0h2LBD/wujJSuv2UiAqmTZwLaSeZsvzI55p/8eSc9k4X5PIFpQH1gyVvbk3DDwv3a6nbW9XwUyKtZic+zSBiy0SWhxEd6E56y464JU0/qBa2ixx75w== x-originating-ip: [172.21.80.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Cc: stox@ietf.org Subject: [Stox] SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-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, 27 Sep 2013 11:54:17 -0000 Hi, There was many years ago a lot confusion and discussion about the semantics= of the SIPS URIs. Robert, Cullen: I recall you were there :-) Would you have guidance to the = STOX WG how SIPS URIs should be dealt with when SIP/XMPP gateways are invol= ved. Please check Peter's exact question from below. Regards, Markus > -----Original Message----- > From: stox-bounces@ietf.org [mailto:stox-bounces@ietf.org] On Behalf Of > ext Peter Saint-Andre > Sent: 24 September, 2013 02:55 > To: Salvatore Loreto > Cc: stox@ietf.org > Subject: Re: [Stox] review: stox-core-04 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 9/20/13 3:39 AM, Salvatore Loreto wrote: > > I have reviewed the core-04 draft, and I think that is almost ready > > for the WGLC > > > > I have one general comment (btw I apologize in advance if this has > > already been discussed and I have overlooked or forgot it) and it is > > about the fact that draft does not talk at all about the inter working > > when secure URIs are involved. I think that at least we should say > > something about in the Security consideration. >=20 > Good catch. After reading and re-reading Section 26.4.4 of RFC 3261, I ha= ve to > admit that I'm not sure exactly how SIP entities are supposed to handle S= IPS > URIs. Even if we understand those requirements, I'm also not sure how the= y > would apply to the XMPP side of the communications path. At the least, it > seems we'd want to specify that if the To header or Request-URI is a SIPS > URI, then the SIP-to-XMPP gateway needs to connect to the XMPP server > over a TLS-protected stream. However, do we also need to stipulate that t= he > XMPP server-to-client connection is TLS-protected? If so, how would the > gateway associated with the XMPP server ensure that? (The gateway might > be an external component of the XMPP server, without control over how the > XMPP server communicates with XMPP clients.) >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJSQNS6AAoJEOoGpJErxa2pueYQAJFMEL4C00F37XDdk9uvA > DsP > 3MM9Si1gIYTmIdI4bW4HY8A5LfggByoT17SD/fYjDoescHfhxO4nb8EP/ElUq0lY > uTeUBl9fi+PQUwQweZS4O/inQAucUTWjf6NAk3x4ETN6ct0dUwXgzj1avmu7o > O9G > t4STEtxtxSHMMjFUacCyHxTYp0b9fSCExUScsGHeM7RJtS4oUrxI8Rb8QNDH8b > ZV > CFo52opkkYBkjZFfIjMGHLzrMNR66G0C9Cbvx+SIy1hhM2iCqWtS50+KMcWBz > g7c > Vog96pNL/li27U18ZAR5kXMT7hbNj/eV2Na6WXPw0ITJ1LtcR2TNbyvJ66U//b0 > g > Ba5R6Dwk7QfBjW1MQ1W79VOZsRga9RYjEuxKtJ+acZeoL/kLSikEZn0o1N+FXtz > t > A0sR0Hovx6jyPDodkrP4R62uhdUdDWXIcLgVOiNTtS9Hbu+RPhDOmsvAA/OyF > t23 > u8nqBLocb57Mxwvk2b9FMGrBa5aQD2dsSiyfEXtMDlOYlxlBYa7vBoVyI8GPLIb > m > sTRPDjN0NvAmokzSWlcA8T2PwnXu06N3UOctw7eVZPoFIE6yk0t/kMNhofMx > q/EV > 4K+tnU1I3w/irDTYA8g3zRfCpbs+RlmGG9pgpN9iOFdas9AQe1jS1rZp3H8C/TG > U > DM4DbC4CrD0Itj2y0pBp > =3DVUg1 > -----END PGP SIGNATURE----- > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From rjsparks@nostrum.com Fri Sep 27 06:46:56 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 A60ED21F9DBA for ; Fri, 27 Sep 2013 06:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, SPF_PASS=-0.001, 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 QllIckVxWwYx for ; Fri, 27 Sep 2013 06:46:55 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA8C21F9CA4 for ; Fri, 27 Sep 2013 06:46:53 -0700 (PDT) Received: from unnumerable.local (pool-71-170-125-188.dllstx.fios.verizon.net [71.170.125.188]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8RDkkqC072845 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 27 Sep 2013 08:46:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <52458C47.1010702@nostrum.com> Date: Fri, 27 Sep 2013 08:46:47 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 71.170.125.188 is authenticated by a trusted mechanism) Cc: salvatore.loreto@ericsson.com, fluffy@cisco.com, Jon Peterson , stpeter@stpeter.im, stox@ietf.org Subject: Re: [Stox] SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-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, 27 Sep 2013 13:46:56 -0000 (Adding Jon) Peter - is there nothing in XMPP that lets a client say "I want this to use secure transports only - have it fail rather than use an insecure transport anywhere along its delivery path?" That's the primary property you should discuss. Without putting a lot of thinking into it, I suspect that if you _don't_ have a way to express that available (which is what I'm taking away from your last sentence), the right guidance in the document is to refuse to gateway a SIP request that expresses that requirement. Maybe Jon has a different opinion? We can dive into the details of where to look for a sips: URI once we think we're on the same page on that high level principle. RjS On 9/27/13 6:43 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > There was many years ago a lot confusion and discussion about the semantics of the SIPS URIs. > > Robert, Cullen: I recall you were there :-) Would you have guidance to the STOX WG how SIPS URIs should be dealt with when SIP/XMPP gateways are involved. Please check Peter's exact question from below. > > Regards, > Markus > > >> -----Original Message----- >> From: stox-bounces@ietf.org [mailto:stox-bounces@ietf.org] On Behalf Of >> ext Peter Saint-Andre >> Sent: 24 September, 2013 02:55 >> To: Salvatore Loreto >> Cc: stox@ietf.org >> Subject: Re: [Stox] review: stox-core-04 >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/20/13 3:39 AM, Salvatore Loreto wrote: >>> I have reviewed the core-04 draft, and I think that is almost ready >>> for the WGLC >>> >>> I have one general comment (btw I apologize in advance if this has >>> already been discussed and I have overlooked or forgot it) and it is >>> about the fact that draft does not talk at all about the inter working >>> when secure URIs are involved. I think that at least we should say >>> something about in the Security consideration. >> Good catch. After reading and re-reading Section 26.4.4 of RFC 3261, I have to >> admit that I'm not sure exactly how SIP entities are supposed to handle SIPS >> URIs. Even if we understand those requirements, I'm also not sure how they >> would apply to the XMPP side of the communications path. At the least, it >> seems we'd want to specify that if the To header or Request-URI is a SIPS >> URI, then the SIP-to-XMPP gateway needs to connect to the XMPP server >> over a TLS-protected stream. However, do we also need to stipulate that the >> XMPP server-to-client connection is TLS-protected? If so, how would the >> gateway associated with the XMPP server ensure that? (The gateway might >> be an external component of the XMPP server, without control over how the >> XMPP server communicates with XMPP clients.) >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJSQNS6AAoJEOoGpJErxa2pueYQAJFMEL4C00F37XDdk9uvA >> DsP >> 3MM9Si1gIYTmIdI4bW4HY8A5LfggByoT17SD/fYjDoescHfhxO4nb8EP/ElUq0lY >> uTeUBl9fi+PQUwQweZS4O/inQAucUTWjf6NAk3x4ETN6ct0dUwXgzj1avmu7o >> O9G >> t4STEtxtxSHMMjFUacCyHxTYp0b9fSCExUScsGHeM7RJtS4oUrxI8Rb8QNDH8b >> ZV >> CFo52opkkYBkjZFfIjMGHLzrMNR66G0C9Cbvx+SIy1hhM2iCqWtS50+KMcWBz >> g7c >> Vog96pNL/li27U18ZAR5kXMT7hbNj/eV2Na6WXPw0ITJ1LtcR2TNbyvJ66U//b0 >> g >> Ba5R6Dwk7QfBjW1MQ1W79VOZsRga9RYjEuxKtJ+acZeoL/kLSikEZn0o1N+FXtz >> t >> A0sR0Hovx6jyPDodkrP4R62uhdUdDWXIcLgVOiNTtS9Hbu+RPhDOmsvAA/OyF >> t23 >> u8nqBLocb57Mxwvk2b9FMGrBa5aQD2dsSiyfEXtMDlOYlxlBYa7vBoVyI8GPLIb >> m >> sTRPDjN0NvAmokzSWlcA8T2PwnXu06N3UOctw7eVZPoFIE6yk0t/kMNhofMx >> q/EV >> 4K+tnU1I3w/irDTYA8g3zRfCpbs+RlmGG9pgpN9iOFdas9AQe1jS1rZp3H8C/TG >> U >> DM4DbC4CrD0Itj2y0pBp >> =VUg1 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox From stpeter@stpeter.im Fri Sep 27 09:14:38 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 7872A21E80FD for ; Fri, 27 Sep 2013 09:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.015 X-Spam-Level: X-Spam-Status: No, score=-102.015 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 xYS-XxRKUjHD for ; Fri, 27 Sep 2013 09:14:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE5321E8050 for ; Fri, 27 Sep 2013 09:14:34 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A61C2414CD; Fri, 27 Sep 2013 10:19:52 -0600 (MDT) Message-ID: <5245AEE7.4010000@stpeter.im> Date: Fri, 27 Sep 2013 10:14:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Robert Sparks References: <52458C47.1010702@nostrum.com> In-Reply-To: <52458C47.1010702@nostrum.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: salvatore.loreto@ericsson.com, fluffy@cisco.com, stox@ietf.org, Jon Peterson , Markus.Isomaki@nokia.com Subject: Re: [Stox] SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-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, 27 Sep 2013 16:14:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/27/13 7:46 AM, Robert Sparks wrote: > (Adding Jon) > > Peter - is there nothing in XMPP that lets a client say "I want > this to use secure transports only - have it fail rather than use > an insecure transport anywhere along its delivery path?" No. That doesn't mean we don't need it (although in general people have thought we *wouldn't* need it if we could just define an end-to-end encryption method that solve all the relevant use cases). > That's the primary property you should discuss. Without putting a > lot of thinking into it, I suspect that if you _don't_ have a way > to express that available (which is what I'm taking away from your > last sentence), the right guidance in the document is to refuse to > gateway a SIP request that expresses that requirement. Indeed, that seems correct. Thanks for the guidance. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSRa7mAAoJEOoGpJErxa2p6S4P/jaAJ4+xGEETfoibeB9TvWHp WdYkNZRElevCJBBVQoR47r92paCBoIsTREKh59ImHTNfxRa6CUojUvPhyGNDZ9E5 qLbPUI1C9sBbn53Q7lJwfkgBDYlcBRiv06SipoGBuVJaHbgYtGKYaI/ZsmUAHqGn CHT9BxlxZdYbgiS3pqwYPpunD9FiJ0/hXEA5/VchONJVh1PGL+/FX/c/UkOjZd3Z ZSoGzwltwqgRshwxK92gMkvcmq87qgdYUFJxPXbzRj8BYpy92W92lThpBpK8Bh8W RzwV8zBYppFea/SSBk8dnBZv27FJQ/Z1+q510zlcjEL0KIG582HfqsrJy1BELT9Q ZbltLm4GSAzFqyIGRFE81Xh4PUXJx5TRXeIJa5aA2iornq8lpiJsEsANh9zbHASR G8dACj45gLrL1k6hVsvCsNFjze4dUWSdtk1HCDqXSxkTpF280HleqCQ2wumNaiyp zuMDt4MPq1Afv/E1sxCglkTT8n/9rpIxEGOVzsT9RDEnMR9VeH1dBk6vYbjJBbOp j0Et24tb3DfGbwywLhu7HoyKxfroehx8MNaVt26ZeBUfX/XVpNOL7R1oUsV4s10Y rVsNpiiWV1hgLny76hxS3371BIdVhuWKU8PQtdf6B+WsBpsL9v/X4mk7+9jkn+R8 MiV0YiTqHpLT2GZtJO1R =/e37 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Sat Sep 28 20:40: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 C594C21E80B0; Sat, 28 Sep 2013 20:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=-0.406, 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 PWiLfrEuAYks; Sat, 28 Sep 2013 20:40:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D7D21F9697; Sat, 28 Sep 2013 20:40:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130929034054.9951.96331.idtracker@ietfa.amsl.com> Date: Sat, 28 Sep 2013 20:40:54 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-01.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 03:40:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Author(s) : Peter Saint-Andre Saul Ibarra Salvatore Loreto Filename : draft-ietf-stox-groupchat-01.txt Pages : 34 Date : 2013-09-28 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 SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-groupchat-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-groupchat-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Sun Sep 29 18:56: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 2D49021F9B25 for ; Sun, 29 Sep 2013 18:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.848 X-Spam-Level: X-Spam-Status: No, score=-101.848 tagged_above=-999 required=5 tests=[AWL=-0.119, 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 n6lkqpV3nQBt for ; Sun, 29 Sep 2013 18:56:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 14A6F21F9B21 for ; Sun, 29 Sep 2013 18:56:00 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9536C414CD; Sun, 29 Sep 2013 20:01:26 -0600 (MDT) Message-ID: <5248DA2D.7080809@stpeter.im> Date: Sun, 29 Sep 2013 19:55:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Robert Sparks References: <52458C47.1010702@nostrum.com> <5245AEE7.4010000@stpeter.im> In-Reply-To: <5245AEE7.4010000@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: salvatore.loreto@ericsson.com, fluffy@cisco.com, Markus.Isomaki@nokia.com, Jon Peterson , stox@ietf.org Subject: Re: [Stox] SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-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: Mon, 30 Sep 2013 01:56:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/27/13 10:14 AM, Peter Saint-Andre wrote: > On 9/27/13 7:46 AM, Robert Sparks wrote: >> (Adding Jon) > >> Peter - is there nothing in XMPP that lets a client say "I want >> this to use secure transports only - have it fail rather than >> use an insecure transport anywhere along its delivery path?" > > No. That doesn't mean we don't need it (although in general people > have thought we *wouldn't* need it if we could just define an > end-to-end encryption method that solve all the relevant use > cases). > >> That's the primary property you should discuss. Without putting >> a lot of thinking into it, I suspect that if you _don't_ have a >> way to express that available (which is what I'm taking away from >> your last sentence), the right guidance in the document is to >> refuse to gateway a SIP request that expresses that requirement. > > Indeed, that seems correct. > > Thanks for the guidance. Here is proposed text: As specified in Section 26.4.4 of [RFC3261], a To header or a Request-URI containing a SIPS URI is used to indicate that all hops in a communication path need to be protected using Transport Layer Security [RFC5246]. Because XMPP lacks a way to signal that all hops need to be encrypted, if the To header or Request-URI of a SIP message is a SIPS URI then the SIP-to-XMPP gateway MUST NOT translate the SIP message into an XMPP stanza and MUST NOT route it to the destination XMPP server. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSSNotAAoJEOoGpJErxa2pAbMQALNKvkSDQLr5yj/4GBaR0qep AMI3pFQ9DdjYPQHaNt/OZRJ22K0XfSbRTEHPRsuld1r2vmMLKRoCh6dxc35TGCYw 5DyolpraQfPE+3zBvlLONtisIbTxNeha20taL6Sbb67pnLJ8xPArn/yHY56Pwq30 PRcffweaNEBlIB26nGiEKshTn/zdmhls59lW6tM+1NuO0DsYdydtO8Ikm4PjLFST GoEihN06Uttw3Jgt08kl1q6fsy3GAjsUaikItjijuKGhQG598YQTE7SbKqxo5mwX h5FT+mdTsGO9lPvPg/+MqMAcXFZOHFbixHMNK/kHmDnnDBbq3EOyDj7Jtn5RuSbw OSgz0vXtmJnCrWkMHMmZtJdS9ixYu3/FEbolagjGte2Ug+1atO8kJPn0zXgZsMk2 qg3eK2SpRjWrT7aB8mC9Pquj0YSL6KXUDW4G7it16XGd0mome0FqdNjBWXmnBEfK 5C7vGTXbp9xswLPki/ga3i9dM1scSnKOsL16MaTOysAyNZAelcwB7Xgds5AJGN5g qJ/sLpzTagC1njDulceHHnTYqS9gnkeR1lBcnBsuS6baDtWBcHDfI8vdpu5qQm8k 1QTDnkFjTBeij3PF1SCcP8M2bIYJhwnaaC0Vp8SmygvgaWiD4ttJinC6PlBuY9MQ guqUK2QaJI+SvnADH69K =aHme -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Sep 29 19:22: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 427F621F9D7C for ; Sun, 29 Sep 2013 19:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 nSIR7fs0KmOB for ; Sun, 29 Sep 2013 19:21:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BCDD621F9D7A for ; Sun, 29 Sep 2013 19:21:50 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2AF19414CD; Sun, 29 Sep 2013 20:27:18 -0600 (MDT) Message-ID: <5248E03D.5090300@stpeter.im> Date: Sun, 29 Sep 2013 20:21:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "stox@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Stox] inconsistent text 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, 30 Sep 2013 02:22:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All of the specs *should* now reference the -core I-D when describing how a SIP server or an XMPP server routes data to a remote domain that supports the other protocol. However, I've noticed that not all of the specs do this (or do so consistently). I'll make an effort to clean up the specs and submit revised I-Ds. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSSOA8AAoJEOoGpJErxa2pXOQP/2AzrsMau9Vqr1N3B5IWsxW2 ZIxuWDwxB3wIB6WdEnfrMwI80G6K/qO4gnBM6P+GGnw6SIAN2imRGzl+YD9V79FN AM3lXz2RalB5bejxiCxy21PE74xMymztbkJNvglV2svB+GxrgIO5WppZSzc0hrML lOHpqaJKYuEvIxPUjOZ2gSoEWBO1oknxRdzeWdEfsmVuC+YmphLuWXyL3+akwMMz xA18jGuVDxCbSslKlBEeOSc+LyytIV65jWOxHmeXCTTtNoSJepgvzzCFxfVEr9lW v9Zt4WQKtmS5axPXO46t93gconvRGHB77IzHzwaxyVl9dRjMlzMX8GVlO/Ax8RwP S2zBeRjKz0ewBBo/Xw+Ber0mp78/sa12AFxfOplbHSsOazt09/Adh3GkJ7sUcRcQ QJ6gFcXK2Q0OIRspBHpqWDZuamHBA04eXePGgwh2UGKl8XCddGwLDm0+yWp3Jdsq TYYLR9ooWgMTVfkTt0D7l5X0wz0GQg801qJcLQq8rpdbUbH9LWffq7HS5C5xqQLz tuk4K/ra9W679fLS8jwfrDl1wHNTC0axsA5sQKsOmCfFou/CLR9JkCZaByJ/irdx hmugM4qlhqdHPmJyMgy1+Dq9Z78ql6nE9DIN4ENFzTr7idzWf9YC/ZXh4jsyAPl/ XdI9mWea5dmNsq7zMoa9 =Mg1O -----END PGP SIGNATURE----- From Markus.Isomaki@nokia.com Mon Sep 30 04:08:25 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 9EE7921F9C46 for ; Mon, 30 Sep 2013 04:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.756 X-Spam-Level: X-Spam-Status: No, score=-5.756 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, 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 sOG8cMd3OG-2 for ; Mon, 30 Sep 2013 04:08:21 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id A9AC821F8BD8 for ; Mon, 30 Sep 2013 04:08:19 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.25]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8UB1Dq3025671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 30 Sep 2013 14:01:15 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.224]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.03.0136.001; Mon, 30 Sep 2013 11:01:13 +0000 From: To: , Thread-Topic: [Stox] inconsistent text Thread-Index: AQHOvYPgYfpeYtGpnEWzJra+Rg2F3pneHQ3g Date: Mon, 30 Sep 2013 11:01:12 +0000 Message-ID: References: <5248E03D.5090300@stpeter.im> In-Reply-To: <5248E03D.5090300@stpeter.im> 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: VgNFIFU9Hx+/nZJb9Kg7ItjosoedgZIfLS0d13o2XgIdREoAGg6oYh3VXs56BGn+L6vbWHAvhDVWVv4/w0NV913Cqr6MYFDqoGGyH6E65k1iFbILXc+gOYZVcnqdu8Uzkebl2UZZgaBBOYkpcxH6zcnvnd6CSvkKtHTUy9le6wkBKhoLAiaatOZjntPh6ll4SMPrY/M1XMzlvXjg7NMSvdzoMM0ArJfK1MFSvRafj8E= x-originating-ip: [10.236.14.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [Stox] inconsistent text 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, 30 Sep 2013 11:08:26 -0000 Hi Peter, OK. After you have updated both the routing related part and the sips URI h= andling in -core and submitted the updated versions, we can initiate WG las= t calls on -core, -im and -presence with those updated versions. Markus=20 > -----Original Message----- > From: stox-bounces@ietf.org [mailto:stox-bounces@ietf.org] On Behalf Of > ext Peter Saint-Andre > Sent: 30 September, 2013 05:22 > To: stox@ietf.org > Subject: [Stox] inconsistent text >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > All of the specs *should* now reference the -core I-D when describing how= a > SIP server or an XMPP server routes data to a remote domain that supports > the other protocol. However, I've noticed that not all of the specs do th= is (or > do so consistently). I'll make an effort to clean up the specs and submit > revised I-Ds. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJSSOA8AAoJEOoGpJErxa2pXOQP/2AzrsMau9Vqr1N3B5IWs > xW2 > ZIxuWDwxB3wIB6WdEnfrMwI80G6K/qO4gnBM6P+GGnw6SIAN2imRGzl+YD9 > V79FN > AM3lXz2RalB5bejxiCxy21PE74xMymztbkJNvglV2svB+GxrgIO5WppZSzc0hrML > lOHpqaJKYuEvIxPUjOZ2gSoEWBO1oknxRdzeWdEfsmVuC+YmphLuWXyL3+ak > wMMz > xA18jGuVDxCbSslKlBEeOSc+LyytIV65jWOxHmeXCTTtNoSJepgvzzCFxfVEr9lW > v9Zt4WQKtmS5axPXO46t93gconvRGHB77IzHzwaxyVl9dRjMlzMX8GVlO/Ax8R > wP > S2zBeRjKz0ewBBo/Xw+Ber0mp78/sa12AFxfOplbHSsOazt09/Adh3GkJ7sUcRc > Q > QJ6gFcXK2Q0OIRspBHpqWDZuamHBA04eXePGgwh2UGKl8XCddGwLDm0+y > Wp3Jdsq > TYYLR9ooWgMTVfkTt0D7l5X0wz0GQg801qJcLQq8rpdbUbH9LWffq7HS5C5xq > QLz > tuk4K/ra9W679fLS8jwfrDl1wHNTC0axsA5sQKsOmCfFou/CLR9JkCZaByJ/irdx > hmugM4qlhqdHPmJyMgy1+Dq9Z78ql6nE9DIN4ENFzTr7idzWf9YC/ZXh4jsyAPl > / > XdI9mWea5dmNsq7zMoa9 > =3DMg1O > -----END PGP SIGNATURE----- > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From stpeter@stpeter.im Mon Sep 30 05:48:52 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 82FF821F8578 for ; Mon, 30 Sep 2013 05:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 ndy5-ohjXRvt for ; Mon, 30 Sep 2013 05:48:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5E821F9BF7 for ; Mon, 30 Sep 2013 05:48:45 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8475D414CD; Mon, 30 Sep 2013 06:54:14 -0600 (MDT) Message-ID: <5249732D.5090702@stpeter.im> Date: Mon, 30 Sep 2013 06:48:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <5248E03D.5090300@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] inconsistent text 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, 30 Sep 2013 12:48:52 -0000 On 9/30/13 5:01 AM, Markus.Isomaki@nokia.com wrote: > Hi Peter, > > OK. After you have updated both the routing related part and the sips URI handling in -core and submitted the updated versions, we can initiate WG last calls on -core, -im and -presence with those updated versions. Sounds good. I made those fixes last night, so I can submit the I-Ds this morning. Peter -- Peter Saint-Andre https://stpeter.im/ From rjsparks@nostrum.com Mon Sep 30 06:37:28 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 A87F521F9B6A for ; Mon, 30 Sep 2013 06:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.078 X-Spam-Level: X-Spam-Status: No, score=-102.078 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, SPF_PASS=-0.001, 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 aGJK9s8pR5Yu for ; Mon, 30 Sep 2013 06:37:12 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3B621F9AD2 for ; Mon, 30 Sep 2013 06:37:10 -0700 (PDT) Received: from unnumerable.local (pool-71-170-125-188.dllstx.fios.verizon.net [71.170.125.188]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8UDb568057074 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 30 Sep 2013 08:37:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <52497E86.5020302@nostrum.com> Date: Mon, 30 Sep 2013 08:37:10 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Saint-Andre References: <52458C47.1010702@nostrum.com> <5245AEE7.4010000@stpeter.im> <5248DA2D.7080809@stpeter.im> In-Reply-To: <5248DA2D.7080809@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 71.170.125.188 is authenticated by a trusted mechanism) Cc: salvatore.loreto@ericsson.com, fluffy@cisco.com, Markus.Isomaki@nokia.com, Jon Peterson , stox@ietf.org Subject: Re: [Stox] SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-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: Mon, 30 Sep 2013 13:37:28 -0000 On 9/29/13 8:55 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/27/13 10:14 AM, Peter Saint-Andre wrote: >> On 9/27/13 7:46 AM, Robert Sparks wrote: >>> (Adding Jon) >>> Peter - is there nothing in XMPP that lets a client say "I want >>> this to use secure transports only - have it fail rather than >>> use an insecure transport anywhere along its delivery path?" >> No. That doesn't mean we don't need it (although in general people >> have thought we *wouldn't* need it if we could just define an >> end-to-end encryption method that solve all the relevant use >> cases). >> >>> That's the primary property you should discuss. Without putting >>> a lot of thinking into it, I suspect that if you _don't_ have a >>> way to express that available (which is what I'm taking away from >>> your last sentence), the right guidance in the document is to >>> refuse to gateway a SIP request that expresses that requirement. >> Indeed, that seems correct. >> >> Thanks for the guidance. > Here is proposed text: > > As specified in Section 26.4.4 of [RFC3261], a To header or a > Request-URI containing a SIPS URI is used to indicate that all hops > in a communication path need to be protected using Transport Layer > Security [RFC5246]. Because XMPP lacks a way to signal that all hops > need to be encrypted, if the To header or Request-URI of a SIP > message is a SIPS URI then the SIP-to-XMPP gateway MUST NOT translate > the SIP message into an XMPP stanza and MUST NOT route it to the > destination XMPP server. wfm. You might also talk about not using sips when going XMPP->SIP. If you haven't found it already, see also RFC5630. RjS > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSSNotAAoJEOoGpJErxa2pAbMQALNKvkSDQLr5yj/4GBaR0qep > AMI3pFQ9DdjYPQHaNt/OZRJ22K0XfSbRTEHPRsuld1r2vmMLKRoCh6dxc35TGCYw > 5DyolpraQfPE+3zBvlLONtisIbTxNeha20taL6Sbb67pnLJ8xPArn/yHY56Pwq30 > PRcffweaNEBlIB26nGiEKshTn/zdmhls59lW6tM+1NuO0DsYdydtO8Ikm4PjLFST > GoEihN06Uttw3Jgt08kl1q6fsy3GAjsUaikItjijuKGhQG598YQTE7SbKqxo5mwX > h5FT+mdTsGO9lPvPg/+MqMAcXFZOHFbixHMNK/kHmDnnDBbq3EOyDj7Jtn5RuSbw > OSgz0vXtmJnCrWkMHMmZtJdS9ixYu3/FEbolagjGte2Ug+1atO8kJPn0zXgZsMk2 > qg3eK2SpRjWrT7aB8mC9Pquj0YSL6KXUDW4G7it16XGd0mome0FqdNjBWXmnBEfK > 5C7vGTXbp9xswLPki/ga3i9dM1scSnKOsL16MaTOysAyNZAelcwB7Xgds5AJGN5g > qJ/sLpzTagC1njDulceHHnTYqS9gnkeR1lBcnBsuS6baDtWBcHDfI8vdpu5qQm8k > 1QTDnkFjTBeij3PF1SCcP8M2bIYJhwnaaC0Vp8SmygvgaWiD4ttJinC6PlBuY9MQ > guqUK2QaJI+SvnADH69K > =aHme > -----END PGP SIGNATURE----- From oej@edvina.net Mon Sep 30 06:43:38 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 9929E21F9B7F for ; Mon, 30 Sep 2013 06:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, 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 cxzZS8EMDX1Y for ; Mon, 30 Sep 2013 06:43:38 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C66E821F9399 for ; Mon, 30 Sep 2013 06:43:36 -0700 (PDT) Received: from [192.168.40.76] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id F2CCA93C2A3; Mon, 30 Sep 2013 13:43:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Olle E. Johansson" In-Reply-To: <52497E86.5020302@nostrum.com> Date: Mon, 30 Sep 2013 15:43:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77B75929-D2A5-4B75-821B-E637C55B0C95@edvina.net> References: <52458C47.1010702@nostrum.com> <5245AEE7.4010000@stpeter.im> <5248DA2D.7080809@stpeter.im> <52497E86.5020302@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1510) Cc: fluffy@cisco.com, Jon Peterson , stox@ietf.org, "Olle E. Johansson" , Markus.Isomaki@nokia.com, Peter Saint-Andre , salvatore.loreto@ericsson.com Subject: Re: [Stox] SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-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: Mon, 30 Sep 2013 13:43:38 -0000 30 sep 2013 kl. 15:37 skrev Robert Sparks : > On 9/29/13 8:55 PM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 9/27/13 10:14 AM, Peter Saint-Andre wrote: >>> On 9/27/13 7:46 AM, Robert Sparks wrote: >>>> (Adding Jon) >>>> Peter - is there nothing in XMPP that lets a client say "I want >>>> this to use secure transports only - have it fail rather than >>>> use an insecure transport anywhere along its delivery path?" >>> No. That doesn't mean we don't need it (although in general people >>> have thought we *wouldn't* need it if we could just define an >>> end-to-end encryption method that solve all the relevant use >>> cases). >>>=20 >>>> That's the primary property you should discuss. Without putting >>>> a lot of thinking into it, I suspect that if you _don't_ have a >>>> way to express that available (which is what I'm taking away from >>>> your last sentence), the right guidance in the document is to >>>> refuse to gateway a SIP request that expresses that requirement. >>> Indeed, that seems correct. >>>=20 >>> Thanks for the guidance. >> Here is proposed text: >>=20 >> As specified in Section 26.4.4 of [RFC3261], a To header or a >> Request-URI containing a SIPS URI is used to indicate that all = hops >> in a communication path need to be protected using Transport Layer >> Security [RFC5246]. Because XMPP lacks a way to signal that all = hops >> need to be encrypted, if the To header or Request-URI of a SIP >> message is a SIPS URI then the SIP-to-XMPP gateway MUST NOT = translate >> the SIP message into an XMPP stanza and MUST NOT route it to the >> destination XMPP server. > wfm. You might also talk about not using sips when going XMPP->SIP. > If you haven't found it already, see also RFC5630. Agree. It will help a lot of developers to explain that even if you find = NAPTR records indicating that a destination ONLY supports TLS connections, you will look up _sips._tcp in SRV but this does NOT mean that you are = going to use a SIPS: uri. The _sips SRV tag and the SIPS: uri are = unfortunately very similar but not directly related in a confusing way :-) /O= From fippo@goodadvice.pages.de Mon Sep 30 07:12:33 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 A0BC421F9C8B for ; Mon, 30 Sep 2013 07:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, 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 TraE0SML+JPf for ; Mon, 30 Sep 2013 07:12:28 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5075721F89F7 for ; Mon, 30 Sep 2013 07:12:28 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8UECQbm021548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Sep 2013 16:12:26 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id r8UECQOr021544; Mon, 30 Sep 2013 16:12:26 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Mon, 30 Sep 2013 16:12:26 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: Peter Saint-Andre In-Reply-To: <5240DBFB.4010607@stpeter.im> Message-ID: References: <5203E484.4050902@goodadvice.pages.de> <523FBFA2.3050902@stpeter.im> <523FD85C.6010600@goodadvice.pages.de> <5240DBFB.4010607@stpeter.im> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stox@ietf.org Subject: Re: [Stox] review of core, chat, groupchat and presence 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, 30 Sep 2013 14:12:33 -0000 >>> I don't feel that we need to show every 200 OK. Yes, we put the >>> example in example.com, but sometimes you really can have too >>> many examples. :-) >> >> Right. But then it might make sense to either add a "not shown" >> marker in the ascii art or not number them. I'll check if that >> happens often enough to make sense. > > Well, maybe we'll just add the examples for the sake of completeness. humm, just noticed that -groupchat is odd here while checking this. X4 is called ACK in both the diagram and example 4 (and is a sip ack) whereas the S3 ACK in the diagram is a 200 in example 28. I think it should be ACK in example 28. I think not numbering things that are not shown (e.g. S2) would be consistent. From stpeter@stpeter.im Mon Sep 30 07:56: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 3AB7F21F9A19 for ; Mon, 30 Sep 2013 07:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.851 X-Spam-Level: X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=-0.122, 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 JG6WoCL82XjL for ; Mon, 30 Sep 2013 07:56:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1854F21F9A65 for ; Mon, 30 Sep 2013 07:56:48 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D3D9B414CD; Mon, 30 Sep 2013 09:02:16 -0600 (MDT) Message-ID: <5249912E.6060104@stpeter.im> Date: Mon, 30 Sep 2013 08:56:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Olle E. Johansson" References: <52458C47.1010702@nostrum.com> <5245AEE7.4010000@stpeter.im> <5248DA2D.7080809@stpeter.im> <52497E86.5020302@nostrum.com> <77B75929-D2A5-4B75-821B-E637C55B0C95@edvina.net> In-Reply-To: <77B75929-D2A5-4B75-821B-E637C55B0C95@edvina.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, Jon Peterson , stox@ietf.org, Markus.Isomaki@nokia.com, salvatore.loreto@ericsson.com, Robert Sparks Subject: Re: [Stox] SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-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: Mon, 30 Sep 2013 14:56:53 -0000 On 9/30/13 7:43 AM, Olle E. Johansson wrote: > > 30 sep 2013 kl. 15:37 skrev Robert Sparks : > >> On 9/29/13 8:55 PM, Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 9/27/13 10:14 AM, Peter Saint-Andre wrote: >>>> On 9/27/13 7:46 AM, Robert Sparks wrote: >>>>> (Adding Jon) >>>>> Peter - is there nothing in XMPP that lets a client say "I want >>>>> this to use secure transports only - have it fail rather than >>>>> use an insecure transport anywhere along its delivery path?" >>>> No. That doesn't mean we don't need it (although in general people >>>> have thought we *wouldn't* need it if we could just define an >>>> end-to-end encryption method that solve all the relevant use >>>> cases). >>>> >>>>> That's the primary property you should discuss. Without putting >>>>> a lot of thinking into it, I suspect that if you _don't_ have a >>>>> way to express that available (which is what I'm taking away from >>>>> your last sentence), the right guidance in the document is to >>>>> refuse to gateway a SIP request that expresses that requirement. >>>> Indeed, that seems correct. >>>> >>>> Thanks for the guidance. >>> Here is proposed text: >>> >>> As specified in Section 26.4.4 of [RFC3261], a To header or a >>> Request-URI containing a SIPS URI is used to indicate that all hops >>> in a communication path need to be protected using Transport Layer >>> Security [RFC5246]. Because XMPP lacks a way to signal that all hops >>> need to be encrypted, if the To header or Request-URI of a SIP >>> message is a SIPS URI then the SIP-to-XMPP gateway MUST NOT translate >>> the SIP message into an XMPP stanza and MUST NOT route it to the >>> destination XMPP server. >> wfm. You might also talk about not using sips when going XMPP->SIP. >> If you haven't found it already, see also RFC5630. > > Agree. It will help a lot of developers to explain that even if you find NAPTR > records indicating that a destination ONLY supports TLS connections, > you will look up _sips._tcp in SRV but this does NOT mean that you are going > to use a SIPS: uri. The _sips SRV tag and the SIPS: uri are unfortunately > very similar but not directly related in a confusing way :-) Thanks for the notes. I'll review those today. Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Mon Sep 30 14:52: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 694BC21F9BC1; Mon, 30 Sep 2013 14:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.427, 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 Dokz11VDogM8; Mon, 30 Sep 2013 14:52:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F4521F9B10; Mon, 30 Sep 2013 14:51:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130930215152.31558.89919.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 14:51:52 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-core-06.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 21:52:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Architecture,= Addresses, and Error Handling Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-core-06.txt Pages : 19 Date : 2013-09-30 Abstract: As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-core There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-core-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-core-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Sep 30 14:52:26 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 4812521F9C7D; Mon, 30 Sep 2013 14:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=-0.408, 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 qgjwurbvgvkl; Mon, 30 Sep 2013 14:52:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7F721F9C47; Mon, 30 Sep 2013 14:52:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130930215200.31558.38507.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 14:52:00 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-presence-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 21:52:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Presence Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-presence-05.txt Pages : 23 Date : 2013-09-30 Abstract: This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-presence There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-presence-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-presence-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Sep 30 14:56:31 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 B9F6E21F88DD; Mon, 30 Sep 2013 14:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.121 X-Spam-Level: X-Spam-Status: No, score=-102.121 tagged_above=-999 required=5 tests=[AWL=-0.391, 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 BJ1nNje2fDKw; Mon, 30 Sep 2013 14:56:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5849521F84B7; Mon, 30 Sep 2013 14:56:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130930215620.31558.59064.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 14:56:20 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-im-04.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 21:56:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SI= P) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messa= ging Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-im-04.txt Pages : 10 Date : 2013-09-30 Abstract: This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-im-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-im-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From miconda@gmail.com Mon Sep 30 23:48:57 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 6302321F9BBD for ; Mon, 30 Sep 2013 23:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 NgHV4s02o0Ld for ; Mon, 30 Sep 2013 23:48:56 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB321F8F29 for ; Mon, 30 Sep 2013 23:48:56 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id m14so3124390eaj.6 for ; Mon, 30 Sep 2013 23:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gQJpvkt8Oaw4TKs2KJN8yGQvG36wUOyTGJLuSBPhwXg=; b=cmZdYIpqnq0XVnijMJkMY07P9ynR7nANHjUoG5/N99/7M1SevNPphS/r8hivD+rzJc g1N4G1bl+xuxI3fYp7KThQZCo7QW3d3VsyldpUDzVD/o1D2ohjCadcCayifSWijcrbsU JKbxXP8i9pEL4b4uIjeDbw1xYKP1XjYbh0BXVeohcsINCJtv8t3y2mWtAZvheXyWGUQZ FvchO9jrRyixPmsYWue12KiJdXIdC2tagRdXc3o6FNAg0JuI+IRRgczVFgoZgz00Zuy0 BKPCLG3p1oetA/BiM8nD+5HLBqygEnzuMlk9/cLtDYzYCMrjiDhIFVfLg1hEwzYUo0Zv h5SA== X-Received: by 10.15.67.131 with SMTP id u3mr43530956eex.34.1380610135526; Mon, 30 Sep 2013 23:48:55 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id v8sm9510741eeo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 23:48:54 -0700 (PDT) Message-ID: <524A7056.20900@gmail.com> Date: Tue, 01 Oct 2013 08:48:54 +0200 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 CC: stox@ietf.org References: <20130930215620.31558.59064.idtracker@ietfa.amsl.com> In-Reply-To: <20130930215620.31558.59064.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: miconda@gmail.com List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 06:48:57 -0000 Hello, the SIP message example in chapter 4. SIP to XMPP has the From header without tag parameter. Should be like: From: ;tag=xyz Daniel On 9/30/13 11:56 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. > > Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging > Author(s) : Peter Saint-Andre > Avshalom Houri > Joe Hildebrand > Filename : draft-ietf-stox-im-04.txt > Pages : 10 > Date : 2013-09-30 > > Abstract: > This document defines a bidirectional protocol mapping for the > exchange of single instant messages between the Session Initiation > Protocol (SIP) and the Extensible Messaging and Presence Protocol > (XMPP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-im > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stox-im-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013 - more details about Kamailio trainings at http://www.asipto.com -