From yana@sip-communicator.org Mon Jul 1 06:19:24 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 4BE5321F9991 for ; Mon, 1 Jul 2013 06:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 p79Bs2xxfh5L for ; Mon, 1 Jul 2013 06:19:19 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9644311E830F for ; Mon, 1 Jul 2013 06:17:39 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so3749124wgg.20 for ; Mon, 01 Jul 2013 06:17:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qETCXMo0es9MUAAcY+VhweFNTcnQ9MqRujXkeGVgkUw=; b=K+Fy+XsvJsO3JQa9YHIK7tprQvymCHLtgpYYYWc0FT2nzmpTwrSzgCufPNNgLxDBgZ FXalFZm5JIl/jfDmKbsJsvRBopnIqtEDlb8XrQaaRHc4K+33/SlE1YWrFDMnzJrfNlwO xJ2h4jF2Fy98uwnCiZbXQdIyEwJTyb+TThBdkYl1rK4VhLArCVOs021UEv2I73Of00iK m4SN3ecFKuoFic6yl0YzMullDFnQgyPE1MhLy6kPoujvpwqtsjdED4PzTefGuk02yKav WABlE23I8e9tP0KROOdBHQLxc7fyeqx4LnwAmCaY/TTwl4J9u/1d59O1dWMs1lc0F605 SQ6Q== X-Received: by 10.194.21.138 with SMTP id v10mr19940049wje.16.1372684658513; Mon, 01 Jul 2013 06:17:38 -0700 (PDT) Received: from [192.168.1.31] (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPSA id fo10sm16236231wib.8.2013.07.01.06.17.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 06:17:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Yana Stamcheva In-Reply-To: Date: Mon, 1 Jul 2013 15:17:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E18B834-8230-4E72-A20C-4DC6B6155392@jitsi.org> References: To: "stox@ietf.org" X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQlUC03F12UB7gQz7l447utT3KVJV+CYRVQtoh1ILFjR0jdJsH4fXnT/7YkpM5OVziwbHQBC Subject: Re: [Stox] Consensus call: Adopting the "current" drafts as WG documents to match the planned deliverables 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, 01 Jul 2013 13:19:24 -0000 Hi, On June 19 the chairs have started a consensus call on adopting the = following drafts as WG documents: draft-saintandre-sip-xmpp-core (Peter Saint-Andre, Avshalom Houri, Joe = Hildebrand) draft-saintandre-sip-xmpp-presence (Peter Saint-Andre, Avshalom Houri, = Joe Hildebrand) draft-saintandre-sip-xmpp-im (Peter Saint-Andre, Avshalom Houri, Joe = Hildebrand) draft-saintandre-sip-xmpp-chat (Peter Saint-Andre, Salvatore Loreto, = Eddy Gavita, Nazin Hossain) draft-saintandre-sip-xmpp-groupchat (Peter Saint-Andre, Salvatore = Loreto, Saul Ibarra Corretge, Fabio Forno) draft-saintandre-sip-xmpp-media (Peter Saint-Andre) - as I understand = Emil and Saul will also be co-authors on this one Since no objections were made and no alternative proposals were = submitted we hereby conclude that the WG accepts the adoption of the = drafts. We would like to ask the co-authors of the drafts to proceed with = submitting the -00 WG documents, so that they can be submitted as such = by the IETF 87 -00 cut-off date (July 8). Regards, Yana & Markus On Jun 19, 2013, at 12:30 PM, Markus.Isomaki@nokia.com wrote: > Hi, >=20 > The chartered deliverables of STOX are: >=20 > 1. Address mapping and error handling > 2. Presence mapping > 3. Mapping for single instant messages > 4. Mapping for one-to-one text chat sessions > 5. Mapping for multi-user text chat sessions > 6. Mapping for media signaling >=20 > The plan is that a separate RFC will be published for each of these.=20= >=20 > As the SIP-to-XMPP mapping effort has been going on for some years = already even before the WG for it has been setup, we already have a set = of relatively mature (individual) drafts to match these deliverables: >=20 > draft-saintandre-sip-xmpp-core (Peter Saint-Andre, Avshalom Houri, Joe = Hildebrand) > draft-saintandre-sip-xmpp-presence (Peter Saint-Andre, Avshalom Houri, = Joe Hildebrand) > draft-saintandre-sip-xmpp-im (Peter Saint-Andre, Avshalom Houri, Joe = Hildebrand) > draft-saintandre-sip-xmpp-chat (Peter Saint-Andre, Salvatore Loreto, = Eddy Gavita, Nazin Hossain) > draft-saintandre-sip-xmpp-groupchat (Peter Saint-Andre, Salvatore = Loreto, Saul Ibarra Corretge, Fabio Forno) > draft-saintandre-sip-xmpp-media (Peter Saint-Andre) >=20 > The first milestone of our charter is: >=20 > Jun 2013 Accept starting-point mapping specifications as WG items >=20 > To meet this on time, we are hereby starting a consensus call on = adopting these drafts as WG items, so that they can be submitted as such = by the IETF 87 -00 cut-off date (July 8). So, please send your comments = on this to the STOX list by the end of next week (June 30), after which = the chairs determine if there is a consensus for the WG adoption of = these documents. Please send also simple "yes" or "+1" statements to the = list, since we want to also see how many active participants we = currently have. If you have issues about why the current drafts should = not be adopted, please raise them ASAP.=20 >=20 > The other question is about the editors/co-authors of the WG = documents. By default we will continue with the same list of co-authors = as in the individual documents. So, we would like all the current = co-authors to send a note to the chairs whether they are willing to = continue (and let us know about your realistic time commitment too). One = change has already been agreed: sip-xmpp-media draft will be taken over = by Saul Ibarra Corretge and Emil Ivov. In case someone else is willing = to volunteers as a co-chair for one or more of the drafts, let the = chairs know. >=20 > The 'sip-xmpp-media' draft (or the to-be RFC) will still also need a = decision about its scope. We'll send a separate mail on that. >=20 > Regards, > Markus & Yana >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From stpeter@stpeter.im Mon Jul 1 10:29:30 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 AF43221F9A12 for ; Mon, 1 Jul 2013 10:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x5X845M6NFn for ; Mon, 1 Jul 2013 10:29:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 46BDC11E80D7 for ; Mon, 1 Jul 2013 10:29:25 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 11F2341346; Mon, 1 Jul 2013 11:30:01 -0600 (MDT) Message-ID: <51D1BC72.2070600@stpeter.im> Date: Mon, 01 Jul 2013 11:29:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yana Stamcheva References: <0E18B834-8230-4E72-A20C-4DC6B6155392@jitsi.org> In-Reply-To: <0E18B834-8230-4E72-A20C-4DC6B6155392@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stox@ietf.org" Subject: Re: [Stox] Consensus call: Adopting the "current" drafts as WG documents to match the planned deliverables 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, 01 Jul 2013 17:29:30 -0000 On 7/1/13 7:17 AM, Yana Stamcheva wrote: > We would like to ask the co-authors of the drafts to proceed with > submitting the -00 WG documents, so that they can be submitted as > such by the IETF 87 -00 cut-off date (July 8). Done! Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 1 10:36:29 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 0F53711E80FF for ; Mon, 1 Jul 2013 10:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R00ZOYDGh69D for ; Mon, 1 Jul 2013 10:36:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9E43111E80E8 for ; Mon, 1 Jul 2013 10:36:24 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E9CD41346; Mon, 1 Jul 2013 11:37:01 -0600 (MDT) Message-ID: <51D1BE16.9050006@stpeter.im> Date: Mon, 01 Jul 2013 11:36:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yana Stamcheva References: <0E18B834-8230-4E72-A20C-4DC6B6155392@jitsi.org> <51D1BC72.2070600@stpeter.im> In-Reply-To: <51D1BC72.2070600@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stox@ietf.org" Subject: Re: [Stox] Consensus call: Adopting the "current" drafts as WG documents to match the planned deliverables 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, 01 Jul 2013 17:36:29 -0000 On 7/1/13 11:29 AM, Peter Saint-Andre wrote: > On 7/1/13 7:17 AM, Yana Stamcheva wrote: > >> We would like to ask the co-authors of the drafts to proceed with >> submitting the -00 WG documents, so that they can be submitted as >> such by the IETF 87 -00 cut-off date (July 8). > > Done! Also checked into source control: http://svn.tools.ietf.org/svn/wg/stox/ Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Mon Jul 1 14:49:13 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 5A9F921F9C3D; Mon, 1 Jul 2013 14:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=-0.327, 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 cyqFqqs0W6LB; Mon, 1 Jul 2013 14:49:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D02B21F9C32; Mon, 1 Jul 2013 14:49:13 -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.51.p2 Message-ID: <20130701214912.16856.43194.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 14:49:12 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-core-00.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:49:13 -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): Addresses and= Error Conditions Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-core-00.txt Pages : 14 Date : 2013-07-01 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 1 14:49: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 5123921F9C82; Mon, 1 Jul 2013 14:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.05 X-Spam-Level: X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=-0.320, 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 NboubpQeLJly; Mon, 1 Jul 2013 14:49:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6C421F9C72; Mon, 1 Jul 2013 14:49: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.51.p2 Message-ID: <20130701214958.29115.28687.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 14:49:58 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-im-00.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:49: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-00.txt Pages : 11 Date : 2013-07-01 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 1 14:50:29 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 07CD521F9C8D; Mon, 1 Jul 2013 14:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=-0.313, 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 07JQXv1o4Dri; Mon, 1 Jul 2013 14:50:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E9411E829B; Mon, 1 Jul 2013 14:50:24 -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.51.p2 Message-ID: <20130701215023.30782.67125.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 14:50:23 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-chat-00.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:50:29 -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-00.txt Pages : 13 Date : 2013-07-01 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 1 14:50: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 CF8A511E82B0; Mon, 1 Jul 2013 14:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=-0.306, 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 QUlllMVcK2TM; Mon, 1 Jul 2013 14:50:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCFE11E82AA; Mon, 1 Jul 2013 14:50: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.51.p2 Message-ID: <20130701215052.16078.58800.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 14:50:52 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-00.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:50: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): Groupchat Author(s) : Peter Saint-Andre Saul Ibarra Salvatore Loreto Filename : draft-ietf-stox-groupchat-00.txt Pages : 32 Date : 2013-07-01 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 1 14:51: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 E1A1C11E82C3; Mon, 1 Jul 2013 14:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.03 X-Spam-Level: X-Spam-Status: No, score=-102.03 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 Q6By5cSlTmly; Mon, 1 Jul 2013 14:51:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8972711E82B0; Mon, 1 Jul 2013 14:51: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.51.p2 Message-ID: <20130701215115.10301.4493.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 14:51:15 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-media-00.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:51: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): Media Sessions Author(s) : Peter Saint-Andre Saul Ibarra Emil Ivov Filename : draft-ietf-stox-media-00.txt Pages : 17 Date : 2013-07-01 Abstract: This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-media There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-media-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yana@sip-communicator.org Mon Jul 1 15:04: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 1FA4E21F9A85 for ; Mon, 1 Jul 2013 15:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Ti37iTUz158b for ; Mon, 1 Jul 2013 15:04:33 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFCD11E82B8 for ; Mon, 1 Jul 2013 15:04:19 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so3560280wiv.11 for ; Mon, 01 Jul 2013 15:04:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4B8b8M5ry/5zHeHKRqoUWHSyJPpzeCsyrFlxEQCxPAE=; b=WnpCP3t+5b9R8+d/6vsFZkjss+WOrlLjfRfwmw77MC/dVI9120b6KojqbpMYH34Vkh /HQapEGtFL3eBSSgOz6omGH+fb7KjPoqHxRpGb53d9AjK897D0c85mu0XLlbsaXCOh+M E3+ZfVI7rgYK9amTiX8k/52jcOsVBOMhjHKCS8whxxRGVm3P+0s0tzWYBIacvffmGRZG aksuq+nqJzG87vOuPIWSqlJlDsm308cIx/Q7nquPwp/UUskHroOtuWfpcmb1sYCb0wX3 V7+a48vOx7zk478PopbHTsQgs8Z7wGsA3xjJjz0fM19OW2Fc92vZLkxwoTAOEzx08r// t7UA== X-Received: by 10.194.122.103 with SMTP id lr7mr21398240wjb.15.1372716257875; Mon, 01 Jul 2013 15:04:17 -0700 (PDT) Received: from [192.168.50.84] (LNantes-156-75-40-217.w82-127.abo.wanadoo.fr. [82.127.243.217]) by mx.google.com with ESMTPSA id j20sm19140775wie.7.2013.07.01.15.04.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 15:04:16 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Yana Stamcheva In-Reply-To: <51D1BE16.9050006@stpeter.im> Date: Tue, 2 Jul 2013 00:04:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E18B834-8230-4E72-A20C-4DC6B6155392@jitsi.org> <51D1BC72.2070600@stpeter.im> <51D1BE16.9050006@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmxEzka//STFwqhkqP/zv6OfzIJAMxqyNJQz3NsKN7ELM+Ij/7P66zzZ8VjNNpE+tY6Bv6J Cc: "stox@ietf.org" Subject: Re: [Stox] Consensus call: Adopting the "current" drafts as WG documents to match the planned deliverables 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, 01 Jul 2013 22:04:38 -0000 Hi Peter, On Jul 1, 2013, at 7:36 PM, Peter Saint-Andre = wrote: > On 7/1/13 11:29 AM, Peter Saint-Andre wrote: >> On 7/1/13 7:17 AM, Yana Stamcheva wrote: >>=20 >>> We would like to ask the co-authors of the drafts to proceed with >>> submitting the -00 WG documents, so that they can be submitted as >>> such by the IETF 87 -00 cut-off date (July 8). >>=20 >> Done! >=20 > Also checked into source control: >=20 > http://svn.tools.ietf.org/svn/wg/stox/ Thanks! They're now approved as WG documents. However I didn't see a submission for draft-ietf-stox-presence-00. Is = this one coming later? Cheers, Yana >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 From stpeter@stpeter.im Mon Jul 1 15:35: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 2182711E8324 for ; Mon, 1 Jul 2013 15:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.333 X-Spam-Level: X-Spam-Status: No, score=-100.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 RBwSgRaf6umf for ; Mon, 1 Jul 2013 15:35:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B980611E8318 for ; Mon, 1 Jul 2013 15:35:21 -0700 (PDT) Received: from [10.194.4.130] (unknown [166.147.80.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C4881412F9; Mon, 1 Jul 2013 16:35:48 -0600 (MDT) References: <0E18B834-8230-4E72-A20C-4DC6B6155392@jitsi.org> <51D1BC72.2070600@stpeter.im> <51D1BE16.9050006@stpeter.im> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <54556D47-2B00-4903-821E-9742DD8E13CD@stpeter.im> X-Mailer: iPhone Mail (10B329) From: Peter Saint-Andre Date: Mon, 1 Jul 2013 16:35:06 -0600 To: Yana Stamcheva Cc: "stox@ietf.org" Subject: Re: [Stox] Consensus call: Adopting the "current" drafts as WG documents to match the planned deliverables 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, 01 Jul 2013 22:35:26 -0000 That was an oversight. Will fix tonight.=20 Sent from mobile, might be terse=20 On Jul 1, 2013, at 4:04 PM, Yana Stamcheva wrote: > Hi Peter, >=20 > On Jul 1, 2013, at 7:36 PM, Peter Saint-Andre wrote: >=20 >> On 7/1/13 11:29 AM, Peter Saint-Andre wrote: >>> On 7/1/13 7:17 AM, Yana Stamcheva wrote: >>>=20 >>>> We would like to ask the co-authors of the drafts to proceed with >>>> submitting the -00 WG documents, so that they can be submitted as >>>> such by the IETF 87 -00 cut-off date (July 8). >>>=20 >>> Done! >>=20 >> Also checked into source control: >>=20 >> http://svn.tools.ietf.org/svn/wg/stox/ >=20 > Thanks! >=20 > They're now approved as WG documents. >=20 > However I didn't see a submission for draft-ietf-stox-presence-00. Is this= one coming later? >=20 > Cheers, > Yana >=20 >>=20 >> Peter >>=20 >> --=20 >> Peter Saint-Andre >> https://stpeter.im/ >=20 From internet-drafts@ietf.org Mon Jul 1 23:31: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 7AE6E11E8309; Mon, 1 Jul 2013 23:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=-0.309, 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 uDKZvSrK2tGl; Mon, 1 Jul 2013 23:31:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB6311E826E; Mon, 1 Jul 2013 23:31:56 -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.51.p2 Message-ID: <20130702063156.13539.50719.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 23:31:56 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-presence-00.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 06:31:56 -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-00.txt Pages : 20 Date : 2013-07-01 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yana@sip-communicator.org Tue Jul 9 14:38: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 52CF621F9CD7 for ; Tue, 9 Jul 2013 14:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 NRdd2RrCfoLo for ; Tue, 9 Jul 2013 14:38:20 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 65CD621F9CFE for ; Tue, 9 Jul 2013 14:38:13 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so5260703wgg.10 for ; Tue, 09 Jul 2013 14:38:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer:x-gm-message-state; bh=6y9Xk2qGtn7e22V7Iq/2vx4s6xbbVg/kh68qOxZw2F4=; b=Y0ofQp1xJ51yAxDRYG5KfYfjogGAad7o2AYuLTTwiWnyzilF5H0KjDJELq5A7rSHvk MV7Gk2b25LqCZdIjkpHPHMQM7cY6Vu7wKYydTBfvlNNVMFj6lLit511pcK32yqkPAxPo ua0HU7JnRpx/cGspu19fVyB2Lf53VRGeK7kjC5rqBGimScixyz1Xz9p/hwp03QdrVx4U +zs9b4VOja85SNtKssF4qSGebisNr6+6eKgIUCwIN6Dev2ls67PHWfjHBe2Ek8foSgo+ eLcmi9wxk1eOfA85yHRU6mKXlWV0IZt7B/cQj8DUSP6jrLP7IEGmpqWw0YplQ0Nno75E tXGA== X-Received: by 10.194.243.129 with SMTP id wy1mr16144867wjc.47.1373405892512; Tue, 09 Jul 2013 14:38:12 -0700 (PDT) Received: from [192.168.1.31] (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPSA id o10sm32430836wiz.5.2013.07.09.14.38.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 14:38:11 -0700 (PDT) From: Yana Stamcheva Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 9 Jul 2013 23:38:08 +0200 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnmvZm+VuIHRwN71wkpRK3ykRQczUxkbDx7EgxoLdptIXRHGoEwwrICMIaQmAw3QdiH7VAI Subject: [Stox] Preliminary Agenda for IETF 87 STOX Meeting 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, 09 Jul 2013 21:38:26 -0000 Hello Everyone, Here's the preliminary agenda for the IETF 87 STOX meeting = (http://tools.ietf.org/agenda/87/#THURSDAY): * 5 min: Introduction: Note well, Administrativia, Agenda overview: = Chairs * 5 min: Status update and forthcoming milestones: Chairs * 10 min: Peter Saint-Andre draft-ietf-stox-core draft-ietf-stox-presence draft-ietf-stox-im draft-ietf-stox-chat * 10 min: Sa=FAl Ibarra Corretg=E9 draft-ietf-stox-groupchat * 40 min: Sa=FAl Ibarra Corretg=E9, Emil Ivov draft-ietf-stox-media * 20 min: Summary and next steps: Chairs In the above agenda we have tried to devote as much time as possible to = the draft with the most open issues. Please let us know if you have any suggestions and/or comments. Cheers, Yana & Markus From yana@sip-communicator.org Wed Jul 10 07:37: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 8FF9E21F9FA7 for ; Wed, 10 Jul 2013 07:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CWEO9joeR4Ze for ; Wed, 10 Jul 2013 07:37:16 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8556821F9FA1 for ; Wed, 10 Jul 2013 07:37:16 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so5997307wev.30 for ; Wed, 10 Jul 2013 07:37:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer:x-gm-message-state; bh=gfSBLKaYdd4BgWMLrbeJpmwwCiuR9tyTwTLWEak6q/8=; b=Mp7oqrAd1Q/MojQRyyujz9RLHW8nQ8Ad196u5lCepb2dRu0Pqa1IT7gujH/AiBNoZj 78cwKXnsQJ1yqCIur5BX7vnxiC2U0kIXKwyACys5Jbfvp0DqR8eiHPLfzX807xWp6kHk H2s1Bx8Xmosb/xzc2yi5Na5l+HUP4GzSEAW8lTCn5M5jH6tR4gf2Sy4CtiuIA+5J/B+w dFLfktT6B6f4BM0VUfWfvGfte4q5oqcgi64ytbCs6PsCP9r52MsmUAGhrAoVAC8BM7tT 0Hf7VMkY24uKiYlgahYYMZcnYNG2eP8c8gL5yFS3evNWMX74/SjxgntS+SDRR483UPrS m6aA== X-Received: by 10.180.73.68 with SMTP id j4mr18892718wiv.10.1373467034211; Wed, 10 Jul 2013 07:37:14 -0700 (PDT) Received: from [192.168.1.31] (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPSA id d8sm36500708wiz.0.2013.07.10.07.37.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 07:37:13 -0700 (PDT) From: Yana Stamcheva Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6533B4F2-F2D5-41C5-8E0E-BA954971D924@jitsi.org> Date: Wed, 10 Jul 2013 16:37:11 +0200 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQkaRsPkhSm9nuElfzXqOGLqXOJdDQ4Mv2xpxFXVzwEyltXXU6teFecDWLFJ08EHD2mNOoPQ Subject: [Stox] Preliminary timetable for draft reviews 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, 10 Jul 2013 14:37:22 -0000 Hello Everyone, In order to make sure we stay on track and respect our milestones we = would like to propose a preliminary timeline for the draft review = deadlines and at the same time ask for volunteers to review! Here's the preliminary timeline for the draft review deadlines: August 16: draft-ietf-stox-core draft-ietf-stox-presence August 30: draft-ietf-stox-im draft-ietf-stox-chat September 13: draft-ietf-stox-groupchat September 27 **: draft-ietf-stox-media ** We still have to see if the media draft would be mature enough at = this point, but we expect that to be the case. Note that these will also be the WG last call deadlines for each of = these drafts. The final timeline would be determined at the meeting in = Berlin. Please contact the chairs if you're ready to volunteer as a reviewer on = any of the above drafts. Cheers, Yana & Markus= From prvs=9011ec0d2=devries_michael@bah.com Mon Jul 15 09:36: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 9F2D621E80AC for ; Mon, 15 Jul 2013 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=0.001, 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 hUKJKxeS1m8q for ; Mon, 15 Jul 2013 09:36:35 -0700 (PDT) Received: from mclniron02-ext.bah.com (mclniron02-ext.bah.com [128.229.5.22]) by ietfa.amsl.com (Postfix) with ESMTP id C6AC121E80E7 for ; Mon, 15 Jul 2013 09:36:23 -0700 (PDT) x-SBRS: None X-REMOTE-IP: 10.12.10.216 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAM0j5FEKDArY/2dsb2JhbABahAnBUoEpdIIlBTpRASoUQiYBBBu9eY8zg0NtA6w7gig X-IPAS-Result: Ap8EAM0j5FEKDArY/2dsb2JhbABahAnBUoEpdIIlBTpRASoUQiYBBBu9eY8zg0NtA6w7gig X-IronPort-AV: E=Sophos;i="4.89,670,1367985600"; d="scan'208";a="500768835" Received: from ashbcshb05.resource.ds.bah.com ([10.12.10.216]) by mclniron02-int.bah.com with ESMTP; 15 Jul 2013 12:36:17 -0400 Received: from ASHBDAG1M2.resource.ds.bah.com ([169.254.2.93]) by ASHBCSHB05.resource.ds.bah.com ([10.12.10.216]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 12:36:17 -0400 From: "De Vries, Michael [USA]" To: "stox@ietf.org" Thread-Topic: STOX Error Condition/Response code translation Thread-Index: Ac6BeW3GprYlO9XDTaec9Xmhavny5g== Date: Mon, 15 Jul 2013 16:36:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.230.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Stox] STOX Error Condition/Response code translation 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, 15 Jul 2013 16:36:40 -0000 Hello Everyone,=0A= =0A= The draft-ietf-stox-core-00 document specifies mappings between XMPP error = conditions and SIP response codes, but does not specify any requirements/re= commendations for handling the SIP "Reason-Phrase" in the "Status-Line" hea= der or the XMPP entry in the block. According to the SIP = and XMPP RFCs, the Reason-Phrase and block appear to effectively s= erve the same purpose in conveying additional error information intended fo= r the human user, so a direct translation between the two (when present) se= ems reasonable to me. =0A= =0A= Additionally, this could potentially help to distinguish errors which are c= urrently mapped down from many possibilities into a single entry, such as S= IP response codes 413-423 (and others) all being mapped to the XMPP Error Condition, assuming that the SIP responses provide a Reason-P= hrase. Additionally, it may even be possible to provide the additional dis= tinguishing information in the XMPP block even if the SIP response = does not contain a Reason-Phrase for direct translation.=0A= =0A= For example: Assume the XMPP-SIP gateway receives a SIP 415 response code = (Unsupported Media Type) in response to some gateway-mediated action betwee= n an XMPP user and SIP user. As per the draft-ieftf-stox-core-00 document, = this response code should be translated and sent to the XMPP user effective= ly as:=0A= =0A= =0A= =0A= =0A= =0A= =0A= If this 415 response contains a Reason-Phrase (though it does not appear to= be mandated as per RFC3261), then the gateway could instead send to the XM= PP user:=0A= =0A= =0A= =0A= =0A= [ ... Reason-Phrase translated here ... ]=0A= =0A= =0A= =0A= =0A= Additionally, if this 415 response does not contain a Reason-Phrase, then t= he gateway could send the following to the XMPP user as a means of distingu= ishing from other errors:=0A= =0A= =0A= =0A= =0A= Unsupported Media Type=0A= =0A= =0A= =0A= =0A= Similarly, a 416 response (Unsupported URI Scheme) without a Reason-Phrase = could be translated into:=0A= =0A= =0A= =0A= =0A= Unsupported URI Scheme=0A= =0A= =0A= =0A= =0A= thus distinguishing between the 415 and 416 responses for the XMPP human us= er, but effectively requiring some textual injection into the message strea= m by the gateway which would need to be specified in the document. That sa= id, as these fields are all optional and not related to actual SIP/XMPP app= lication-level handling of messages, there is no reason that the XMPP-SIP g= ateway must perform such a translation, but I figured it might be worth exp= loring in this discussion group.=0A= =0A= =0A= Thanks,=0A= --Mike DeVries= From internet-drafts@ietf.org Mon Jul 15 13:37: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 BA75621E811F; Mon, 15 Jul 2013 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.373, 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 dETOJZxVlIDp; Mon, 15 Jul 2013 13:37:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA9111E8122; Mon, 15 Jul 2013 13:37:37 -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.51.p2 Message-ID: <20130715203737.5668.65746.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 13:37:37 -0700 Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-media-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: Mon, 15 Jul 2013 20:37:37 -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): Media Sessions Author(s) : Peter Saint-Andre Saul Ibarra Emil Ivov Filename : draft-ietf-stox-media-01.txt Pages : 15 Date : 2013-07-15 Abstract: This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-media There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-media-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-media-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From saul@ag-projects.com Mon Jul 15 13:39:12 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 F23D221E815C for ; Mon, 15 Jul 2013 13:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.046 X-Spam-Level: X-Spam-Status: No, score=-0.046 tagged_above=-999 required=5 tests=[AWL=0.772, 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 XZ49hJdarKiS for ; Mon, 15 Jul 2013 13:39:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 19F3A21E811F for ; Mon, 15 Jul 2013 13:39:07 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D899EB35DF; Mon, 15 Jul 2013 22:39:05 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E6845B00EF for ; Mon, 15 Jul 2013 22:39:04 +0200 (CEST) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jul 2013 22:39:04 +0200 References: <20130715203737.5668.65746.idtracker@ietfa.amsl.com> To: stox@ietf.org Message-Id: <769F9EB7-C1B8-45D4-AED2-C688EB301771@ag-projects.com> Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [Stox] Fwd: I-D Action: draft-ietf-stox-media-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: Mon, 15 Jul 2013 20:39:12 -0000 I uploaded a (very) raw -01 version os the media draft, looking forward = to working on this in Berlin :-) Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 15, 2013 10:37:37 PM GMT+02:00 > To: i-d-announce@ietf.org > Cc: stox@ietf.org > Subject: [Stox] I-D Action: draft-ietf-stox-media-01.txt >=20 >=20 > 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. >=20 > Title : Interworking between the Session Initiation = Protocol (SIP) and the Extensible Messaging and Presence Protocol = (XMPP): Media Sessions > Author(s) : Peter Saint-Andre > Saul Ibarra > Emil Ivov > Filename : draft-ietf-stox-media-01.txt > Pages : 15 > Date : 2013-07-15 >=20 > Abstract: > This document defines a bi-directional protocol mapping for use by > gateways that enable the exchange of media signalling messages > between systems that implement the Jingle extensions to the > Extensible Messaging and Presence Protocol (XMPP) and those that > implement the Session Initiation Protocol (SIP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-media >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stox-media-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-media-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Wed Jul 17 20:23: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 8788321F9A05 for ; Wed, 17 Jul 2013 20:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.056 X-Spam-Level: X-Spam-Status: No, score=-102.056 tagged_above=-999 required=5 tests=[AWL=-0.327, 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 FC+IZ3c24mve for ; Wed, 17 Jul 2013 20:23:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4F621F991F for ; Wed, 17 Jul 2013 20:23:24 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 052E2413BC; Wed, 17 Jul 2013 21:24:53 -0600 (MDT) Message-ID: <51E75FA9.7060104@stpeter.im> Date: Wed, 17 Jul 2013 21:23:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stox@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Stox] STOX Error Condition/Response code translation 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, 18 Jul 2013 03:23:33 -0000 Hi Mike, thank you very much for the feedback! On 7/15/13 10:36 AM, De Vries, Michael [USA] wrote: > Hello Everyone, > > The draft-ietf-stox-core-00 document specifies mappings between XMPP > error conditions and SIP response codes, but does not specify any > requirements/recommendations for handling the SIP "Reason-Phrase" in > the "Status-Line" header or the XMPP entry in the > block. According to the SIP and XMPP RFCs, the Reason-Phrase and > block appear to effectively serve the same purpose in > conveying additional error information intended for the human user, > so a direct translation between the two (when present) seems > reasonable to me. RFC 3261 says (Section 7.2): The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase. And RFC 6120 says (Section 8.3.2): The element is OPTIONAL. If included, it is to be used only to provide descriptive or diagnostic information that supplements the meaning of a defined condition or application-specific condition. It MUST NOT be interpreted programmatically by an application. It SHOULD NOT be used as the error message presented to a human user, but MAY be shown in addition to the error message associated with the defined condition element (and, optionally, the application-specific condition element). Despite the caveat about clients not directly copying the element and using it as the error message shown to a user, I tend to agree that they are mostly equivalent and can reasonably be mapped to each other for interworking purposes. > Additionally, this could potentially help to distinguish errors which > are currently mapped down from many possibilities into a single > entry, such as SIP response codes 413-423 (and others) all being > mapped to the XMPP Error Condition, assuming that the > SIP responses provide a Reason-Phrase. Additionally, it may even be > possible to provide the additional distinguishing information in the > XMPP block even if the SIP response does not contain a > Reason-Phrase for direct translation. > > For example: Assume the XMPP-SIP gateway receives a SIP 415 response > code (Unsupported Media Type) in response to some gateway-mediated > action between an XMPP user and SIP user. As per the > draft-ieftf-stox-core-00 document, this response code should be > translated and sent to the XMPP user effectively as: > > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> > > > If this 415 response contains a Reason-Phrase (though it does not > appear to be mandated as per RFC3261), then the gateway could instead > send to the XMPP user: > > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'> [ ... Reason-Phrase > translated here ... ] > > > Additionally, if this 415 response does not contain a Reason-Phrase, > then the gateway could send the following to the XMPP user as a means > of distinguishing from other errors: > > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'> Unsupported Media Type > > > > Similarly, a 416 response (Unsupported URI Scheme) without a > Reason-Phrase could be translated into: > > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'> Unsupported URI Scheme > > > > thus distinguishing between the 415 and 416 responses for the XMPP > human user, but effectively requiring some textual injection into the > message stream by the gateway which would need to be specified in the > document. That said, as these fields are all optional and not > related to actual SIP/XMPP application-level handling of messages, > there is no reason that the XMPP-SIP gateway must perform such a > translation, but I figured it might be worth exploring in this > discussion group. IMHO your proposal is reasonable as suggested behavior, although I don't think it rises to the level of a MUST or SHOULD requirement. I will look into it further and propose some text on the list. Peter -- Peter Saint-Andre https://stpeter.im/ From yana@sip-communicator.org Thu Jul 18 07:09: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 7EFD021E80F6 for ; Thu, 18 Jul 2013 07:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 hVxiuAy2Xy8b for ; Thu, 18 Jul 2013 07:08:55 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0467A21F9C37 for ; Thu, 18 Jul 2013 07:08:48 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so2956931wgh.30 for ; Thu, 18 Jul 2013 07:08:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer:x-gm-message-state; bh=/pyvQKlblIxmSc7aI0iGzNy8hDKUy2OUlopoFsRGjj8=; b=cBcutqB3G5iPGq97Wa4nf1j71KjiUcFVkYo35AQPvO0L+ARqZn15uONIv9DPFhC0bc 0syZwp8VMbSmul3Lz6dBxEqsB6IFZNvMCCWhkQn74iulB3wXdkWdMMzgNAdoSZ+edOid wmYk0/8TodYLwh0k0IcN8hMiyZMR4B3IOaC7H5b4GrMYILD8/wJ/P/Vb0L3sxOqZn/Cf F/xmNrbqQeqmTjyHwBFp3FNxMW4xDf5840jxKMuALhZ4YbtMOMNZwfPBnh0ILexShEQ5 dupjzwBB9H8t2z8A0p5Qf/nrrgKsvvLjtkQ/Qkq+Ro4Rn3DpORlbeDZHpLQh3jOQLaeW hrIQ== X-Received: by 10.194.87.9 with SMTP id t9mr9129472wjz.39.1374156528116; Thu, 18 Jul 2013 07:08:48 -0700 (PDT) Received: from reserve-yana.u-strasbg.fr (reserve-yana.u-strasbg.fr. [130.79.90.241]) by mx.google.com with ESMTPSA id fd3sm42208982wic.10.2013.07.18.07.08.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 07:08:47 -0700 (PDT) From: Yana Stamcheva Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <2ED41C2C-1872-4F0D-ACA8-01A21BA92B73@jitsi.org> Date: Thu, 18 Jul 2013 16:08:44 +0200 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQlGrGWk+wpcIDNNpa1Y5pSL+7T7qTngcKYG9+dpw+l2Z96Zssm0nMjvFWshY7flndvm9qzI Subject: [Stox] Agenda for IETF 87 STOX Meeting 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, 18 Jul 2013 14:09:00 -0000 Hello Everyone, We have submitted the agenda for the IETF 87 STOX meeting = (http://tools.ietf.org/agenda/87/#THURSDAY): = http://www.ietf.org/proceedings/87/agenda/agenda-87-stox . Quick summary: 17:00-17:10 Introduction and Status Update, Forthcoming milestones = (Chairs, 10 mins) =20 17:10-17:20 draft-ietf-stox-core-00 (Peter Saint-Andre, 10 mins) draft-ietf-stox-presence-00 draft-ietf-stox-im-00 draft-ietf-stox-chat-00 17:20-17:40 draft-ietf-stox-groupchat-00 (Sa=FAl Ibarra Corretg=E9, = 20 mins) 17:40-18:10 draft-ietf-stox-media-00 (Sa=FAl Ibarra Corretg=E9, Emil = Ivov, 30 mins) =20 18:10-18:30, Summary and Next Steps (Chairs, 20 mins) As we have mentioned earlier, in the above agenda we have tried to = devote as much time as possible to the drafts with most open issues. Thanks to all of you who have sent us feedback. Cheers, Yana & Markus= From michaellundberg.ietf@gmail.com Fri Jul 19 05:01: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 752BE11E8105 for ; Fri, 19 Jul 2013 05:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKVUZvu4cKl6 for ; Fri, 19 Jul 2013 05:01:08 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B9D5311E80F8 for ; Fri, 19 Jul 2013 05:01:07 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id t58so449939wes.12 for ; Fri, 19 Jul 2013 05:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hqgVEVfJR3B5gZGVwksMMVD/ig6g1GBL0jJ9/6jHV9U=; b=ToQ6OtHlr3Aeq640Fdny0skBMSJDN0o4mjzB25NQkNM9jLaWWbQNmDp0EFUqupOmlm Zd1NhrLNbVkIGpWlpe69zq8zwQ1hCZovYq9OctECV7B1HvahbLyeGwh9xFADVRtpzlAN 4lSF1xi3wIbDZfPSRffkSmhxtbSq8sdaLVR8Is48dZOu8Oa2RDxmXMA/JMBeyyBq6fKy PUXmF8QQ6GcPzqD4GfzZZILOF+NmUpPc+BkDLmyjb6Llu00zSeIlwSWYtmTr7D86w4He PKqPPiM0jrcIyp8NQHpmdHM3paEW/TQyOzH/puZlt9OdiuMjN8YTDYaVtXUx/SOyXV0T 2RdA== MIME-Version: 1.0 X-Received: by 10.194.174.137 with SMTP id bs9mr11778958wjc.59.1374235266856; Fri, 19 Jul 2013 05:01:06 -0700 (PDT) Received: by 10.216.202.10 with HTTP; Fri, 19 Jul 2013 05:01:06 -0700 (PDT) Date: Fri, 19 Jul 2013 08:01:06 -0400 Message-ID: From: Michael Lundberg To: stox@ietf.org, Peter Saint-Andre Content-Type: multipart/alternative; boundary=089e0149331eeb3e1704e1dc14d1 Subject: [Stox] Comments on draft-ietf-stox-presence-00 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, 19 Jul 2013 12:01:08 -0000 --089e0149331eeb3e1704e1dc14d1 Content-Type: text/plain; charset=ISO-8859-1 Peter, I think draft-ietf-stox-presence-00 looks good. I had a previous comment to an earlier version that was not addressed that I'm incuding it again as I think it is important for the document. I think it would be good to add the element to Table 7, with a note similar to the one provided in Table 6. This will provide a method for mapping 'away' and 'dnd' information in the opposite direction. Similar to the note in Table 6, this would require the SIP implementation to support the 'jabber:client' namespace. If the SIP implementation supports the namespace, the gateway can then map the values directly into the element of the XMPP presence messages. The only other thing I saw was that the below sentence in Section 3.2.3 is missing the word "send" after SHOULD. Current: Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway SHOULD a presence stanza of type "unsubscribed" to the XMPP user: New: Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway SHOULD send a presence stanza of type "unsubscribed" to the XMPP user: Regards, Michael --089e0149331eeb3e1704e1dc14d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Peter,

I think draft-ietf-stox-presence-00 look= s good.=A0 I had a previous comment to an earlier version that was not addr= essed that I'm incuding it again as I think it is important for the doc= ument.
=A0
I think it would be good to add the <show/> elemen= t to Table 7, with a note similar to the one provided in Table 6.=A0 This w= ill provide a method for mapping 'away' and 'dnd' informati= on in the opposite direction.=A0 Similar to the note in Table 6, this would= require the SIP implementation to support the 'jabber:client' name= space.=A0 If the SIP implementation supports the namespace, the gateway can= then map the values directly into the <show/> element of the XMPP pr= esence messages.

The only other thing I saw was that the below sentence in Section 3.2.3 = is missing the word "send" after SHOULD.

Current:

Up= on sending the transformed unsubscribe, the XMPP-SIMPLE gateway SHOULD a pr= esence stanza of type "unsubscribed" to the XMPP user:

New:

Upon sending the transformed unsubscribe, the XMPP-SIMPLE ga= teway SHOULD send a presence stanza of type "unsubscribed" to the= XMPP user:

Regards,
Michael

--089e0149331eeb3e1704e1dc14d1-- From prvs=9053bd65d=devries_michael@bah.com Fri Jul 19 16:07: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 E75F011E81BA for ; Fri, 19 Jul 2013 16:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, 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 zdE8f3Adc-6L for ; Fri, 19 Jul 2013 16:07:27 -0700 (PDT) Received: from mclniron01-ext.bah.com (mclniron01-ext.bah.com [128.229.5.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7488411E81B7 for ; Fri, 19 Jul 2013 16:07:27 -0700 (PDT) x-SBRS: None X-REMOTE-IP: 10.12.10.218 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAAvF6VEKDAra/2dsb2JhbABbhAvAS4EndIImBTpRASoUQiYBBBu/U49eg0huA6w8gio X-IPAS-Result: Ap8EAAvF6VEKDAra/2dsb2JhbABbhAvAS4EndIImBTpRASoUQiYBBBu/U49eg0huA6w8gio X-IronPort-AV: E=Sophos;i="4.89,705,1367985600"; d="scan'208";a="248430260" Received: from ashbcshb06.resource.ds.bah.com ([10.12.10.218]) by mclniron01-int.bah.com with ESMTP; 19 Jul 2013 19:07:24 -0400 Received: from ASHBDAG1M2.resource.ds.bah.com ([169.254.2.214]) by ASHBCSHB06.resource.ds.bah.com ([10.12.10.218]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 19:07:23 -0400 From: "De Vries, Michael [USA]" To: "stox@ietf.org" Thread-Topic: Nickname Usage Conflict Resolution Thread-Index: Ac6Ejowa9Oxuzw0USjSgmP9ujOftBA== Date: Fri, 19 Jul 2013 23:07:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.230.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Stox] Nickname Usage Conflict Resolution 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, 19 Jul 2013 23:07:33 -0000 Hello everyone, I have a concern with the suggested possible resolutions for a Nickname Usa= ge Conflict in the draft-ietf-stox-groupchat-00 document. In section 3.2, = the document says | Alternatively [to translating the MSRP 425 message to a err= or], | the gateway might generate a new nickname request on | behalf of the XMPP user, thus shielding the XMPP client from handling | the conflict error. Additionally, section 5 says | If there is a conflict between the SIP nickname and the XMPP | nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible for | adjusting the nickname to avoid the conflict and for informing the | SIP or XMPP client of the unique nickname used to join the chatroom. First, section 3.2 suggests that the gateway may choose to generate a new n= ickname, but can instead merely forward on the translated MSRP 425 or error, whereas section 5 says that the gateway is responsible for (a= ka MUST) adjusting the nickname in the event of a conflict. Both of these = sections suggest that in the case of a nickname conflict the gateway may ac= t independently of the client to change the client-generated nickname to on= e which is unique within the context of the chatroom. I'm not certain this= is the most appropriate approach. Nicknames are important in that they ar= e needed to facilitate private messaging and other features, as well as bei= ng an important part of user identification. It seems risky to automatical= ly generate a new nickname when a conflict is found, instead of merely pres= enting the error to the user (via MSRP 425 message or error) so= that they can choose a new nickname via their client. Additionally, a cur= sory examination of the XMPP, MSRP, and MUC RFCs/XEPs does not appear to sh= ow any recommendation that nicknames be automatically generated in the even= t of a conflict. I believe that it would be better to require that the gateway merely forwar= d on the translated MSRP 425 or error instead of attempting to = address the conflict automatically, but I may not sufficiently understand t= he reasoning behind the automated nickname resolution. Thanks, --Mike DeVries From saul@ag-projects.com Sat Jul 20 06:48: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 CCBBC11E8101 for ; Sat, 20 Jul 2013 06:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=0.386, 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 D7v5--FDt5ox for ; Sat, 20 Jul 2013 06:48:27 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBE2F11E810A for ; Sat, 20 Jul 2013 06:48:26 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 340CFB35DC; Sat, 20 Jul 2013 15:48:17 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 5AD97B017C; Sat, 20 Jul 2013 15:48:17 +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: Sat, 20 Jul 2013 15:48:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <31EA9B37-9F4C-4473-A1BC-2B18759B865D@ag-projects.com> References: To: "De Vries, Michael [USA]" X-Mailer: Apple Mail (2.1085) Cc: "stox@ietf.org" Subject: Re: [Stox] Nickname Usage Conflict Resolution 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: Sat, 20 Jul 2013 13:48:32 -0000 Hi Michael, On Jul 20, 2013, at 1:07 AM, De Vries, Michael [USA] wrote: > Hello everyone, >=20 > I have a concern with the suggested possible resolutions for a = Nickname Usage Conflict in the draft-ietf-stox-groupchat-00 document. = In section 3.2, the document says >=20 > | Alternatively [to translating the MSRP 425 message to a = error], > | the gateway might generate a new nickname request on > | behalf of the XMPP user, thus shielding the XMPP client from = handling > | the conflict error. >=20 > Additionally, section 5 says >=20 > | If there is a conflict between the SIP nickname and the XMPP > | nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible = for > | adjusting the nickname to avoid the conflict and for informing the > | SIP or XMPP client of the unique nickname used to join the = chatroom. >=20 > First, section 3.2 suggests that the gateway may choose to generate a = new nickname, but can instead merely forward on the translated MSRP 425 = or error, whereas section 5 says that the gateway is = responsible for (aka MUST) adjusting the nickname in the event of a = conflict. Both of these sections suggest that in the case of a nickname = conflict the gateway may act independently of the client to change the = client-generated nickname to one which is unique within the context of = the chatroom. I'm not certain this is the most appropriate approach. = Nicknames are important in that they are needed to facilitate private = messaging and other features, as well as being an important part of user = identification. It seems risky to automatically generate a new nickname = when a conflict is found, instead of merely presenting the error to the = user (via MSRP 425 message or error) so that they can choose = a new nickname via their client. Additionally, a cursory examinatio > n of the XMPP, MSRP, and MUC RFCs/XEPs does not appear to show any = recommendation that nicknames be automatically generated in the event of = a conflict. >=20 > I believe that it would be better to require that the gateway merely = forward on the translated MSRP 425 or error instead of = attempting to address the conflict automatically, but I may not = sufficiently understand the reasoning behind the automated nickname = resolution. >=20 I agree. This is how things are usually handled in MSRP. When testing = things in XMPP however, not every client is able to properly deal with = nickname conflicts though. Peter, maybe this was the reason why that = text was added? Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ralphm@ik.nu Mon Jul 22 08:06:13 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 D5E7E21E80B6; Mon, 22 Jul 2013 08:06:13 -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 hB--a1FzGdpT; Mon, 22 Jul 2013 08:06:08 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [IPv6:2001:16f8:4::61]) by ietfa.amsl.com (Postfix) with ESMTP id 7341B11E80F2; Mon, 22 Jul 2013 08:06:08 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id D664FA1047; Mon, 22 Jul 2013 17:06:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id IcMi5T779wHw; Mon, 22 Jul 2013 17:05:43 +0200 (CEST) Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id E3E6DA1021; Mon, 22 Jul 2013 17:05:42 +0200 (CEST) Message-ID: <51ED4A45.9000703@ik.nu> Date: Mon, 22 Jul 2013 17:05:41 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: public-webrtc@w3.org, rtcweb@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stox@ietf.org, XMPP Jingle Subject: [Stox] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. 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, 22 Jul 2013 15:06:13 -0000 Hi all, I would like to inform the group of the recent formation [1] of the Jingle Special Interest Group (SIG) at the XMPP Standards Foundation (XSF). The recent increase of activity in the WebRTC and rtcweb working groups and related high-profile product developments and announcements were reasons for the XMPP Council to decide to concentrate efforts around Jingle in a SIG. Jingle [2] is a general framework for managing media sessions between XMPP Sessions, including, but not limited to, audio/video streams, file transfer and application sharing. There are several documents describing applications of Jingle and the used transports, most linked from the overall framework specification [3]. The specification of Jingle RTP Sessions [4], most relevant to these working groups, defines a Jingle application type for negotiating RTP sessions. It has been designed such that interoperability with SIP-based systems is possible. This includes mapping negotiation parameters to and from SDP, while remaining a signaling protocol in its own right (not merely SDP in angle brackets). The following work items were defined in the kick-off meeting last Wednesday, July 17 [5, raw log 6]: * Re-examining the state of the various Jingle proposals. * Polishing Jingle File Transfer. * Updating the SDP mapping in [4], including BUNDLE and Trickle-ICE improvements. * Documenting and communicating the value proposition of Jingle/XMPP. This SIG already includes a number of people participating in discussions on the WebRTC and rtcweb mailing lists and is lead by Dave Cridland (chair), Philipp Hancke, Lance Stout and myself. It is open to anyone, and we are looking forward to cooperate with the WebRTC and rtcweb working groups to improve both WebRTC and Jingle. The discussion venues are the Jingle mailing list [7] and the Jingle XMPP multi-user chat room [8]. Our next meeting in the MUC room is Wednesday July 24 at 15:30 UTC. This group's experience and input would be highly appreciated, and your participation in both the meeting and the on-going discussion would be most welcome. Thanks, Ralph Meijer [1] [2] [3] [4] [5] [6] [7] [8] From ralphm@ik.nu Mon Jul 22 08:47: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 401C211E8125; Mon, 22 Jul 2013 08:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMKd4+rt5zzI; Mon, 22 Jul 2013 08:47:12 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [83.98.201.61]) by ietfa.amsl.com (Postfix) with ESMTP id 09ECA11E80D9; Mon, 22 Jul 2013 08:47:11 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 9A748A1030; Mon, 22 Jul 2013 17:47:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 2gEMjMyogze3; Mon, 22 Jul 2013 17:46:48 +0200 (CEST) Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id 16F6FA100F; Mon, 22 Jul 2013 17:46:48 +0200 (CEST) Message-ID: <51ED53E6.10400@ik.nu> Date: Mon, 22 Jul 2013 17:46:46 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51ED4A45.9000703@ik.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: stox@ietf.org, XMPP Jingle , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: [Stox] XSF Jingle Special Interest Group. 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, 22 Jul 2013 15:47:26 -0000 On 2013-07-22 17:14, I=C3=B1aki Baz Castillo wrote: > Great. First thing you should complain about is the fact that current > WebRTC specification makes unfeasible for a browser to use SDP-XML as > defined by XEP-0167. So if you have a SIP server you will be able to > directly connect from the browser, but if you have a Jingle server you > will need a gateway. Hi I=C3=B1aki, I have been following the recent discussions for a while now, and think=20 I understand the various stand points, including yours. As I mentioned in my announcement, mapping SDP to Jingle's negotiation=20 parameters is indeed one of the concerns we are going to look into.=20 Philipp's work on his WebRTC plugin for Strophe.js [1], which uses=20 Jingle signalling, has shown that it indeed takes quite some effort to=20 map and mangle SDP to get things going. The spreadsheet questionnaire=20 that Peter Thatcher asked people to fill in (thanks!) also has several=20 comments to that effect. During our discussions on the Jingle mailing=20 list and the meeting last week, more of such comments were made. I want to stress, again, that Jingle's negotiation parameters should not=20 be referred to as a flavor of SDP expressed in XML. This is misleading,=20 as it is not managed by MMUSIC, and actually weakens your point of not=20 wanting SDP as an API surface. I can understand that looking at the=20 current specification could give that impression, though. The Jingle=20 examples are currently interleaved by SDP examples to show the mapping,=20 and we are looking into making the distinction clearer, maybe even as a=20 document separate from this one. [1] https://github.com/ESTOS/strophe.jingle PS. Yes, I messed up the subject header of the original announcement. --=20 ralphm From ibc@aliax.net Mon Jul 22 08:15: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 1D22811E8102 for ; Mon, 22 Jul 2013 08:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Qnk3oFRqDZEU for ; Mon, 22 Jul 2013 08:14:58 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id C208011E8113 for ; Mon, 22 Jul 2013 08:14:58 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bs12so864458qab.14 for ; Mon, 22 Jul 2013 08:14:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=e4BtpNM+wPUGcYN+3ZLUpSJN2CvgqTOQiTSueWegWdU=; b=JSYYA8v4uloaCtQRt6HUbuzeqbMXQGJYbV2ovNX1hD69qLh02uKPSeEI12yKVN4YOj 1SsJkm+Rjk19+mW8mWPwOviDBoVhIy47MVaCxlFxYFpGica5GyNu3LPFRIfJj39bT8Uh J1FcPae8TKK0ZsVf2PNTALWSwpb+SnyXQ+0nxi3OOGAbYLcv1DZyNvPXj+Kk0D21LsPN i8zuV632sswZZzde3kH6o2i18ZnUjRhGRQ5dvjXvfCdpNoQafLOQFQfAMWAexq94TiHy dUlhzpMNBLuTPnPCoh4yTXBGDCCzBRSwu1x+/3hs6QZ1s7MCk2dJ4yxyjy5fUvWg2GFm Od3A== X-Received: by 10.49.48.19 with SMTP id h19mr33440892qen.9.1374506096969; Mon, 22 Jul 2013 08:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 22 Jul 2013 08:14:36 -0700 (PDT) In-Reply-To: <51ED4A45.9000703@ik.nu> References: <51ED4A45.9000703@ik.nu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 22 Jul 2013 17:14:36 +0200 Message-ID: To: Ralph Meijer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn1RjL8v7KKFRjj0XRtD8t/D6hKBBMC/Hwd8OmWSFkJdnVubJ3fpdW8ksDw6JYAOPB2/v+s X-Mailman-Approved-At: Mon, 22 Jul 2013 09:13:07 -0700 Cc: stox@ietf.org, XMPP Jingle , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [Stox] [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. 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, 22 Jul 2013 15:15:04 -0000 Great. First thing you should complain about is the fact that current WebRTC specification makes unfeasible for a browser to use SDP-XML as defined by XEP-0167. So if you have a SIP server you will be able to directly connect from the browser, but if you have a Jingle server you will need a gateway. 2013/7/22 Ralph Meijer : > Hi all, > > I would like to inform the group of the recent formation [1] of the Jingl= e > Special Interest Group (SIG) at the XMPP Standards Foundation (XSF). The > recent increase of activity in the WebRTC and rtcweb working groups and > related high-profile product developments and announcements were reasons = for > the XMPP Council to decide to concentrate efforts around Jingle in a SIG. > > Jingle [2] is a general framework for managing media sessions between XMP= P > Sessions, including, but not limited to, audio/video streams, file transf= er > and application sharing. There are several documents describing applicati= ons > of Jingle and the used transports, most linked from the overall framework > specification [3]. > > The specification of Jingle RTP Sessions [4], most relevant to these work= ing > groups, defines a Jingle application type for negotiating RTP sessions. I= t > has been designed such that interoperability with SIP-based systems is > possible. This includes mapping negotiation parameters to and from SDP, > while remaining a signaling protocol in its own right (not merely SDP in > angle brackets). > > The following work items were defined in the kick-off meeting last > Wednesday, July 17 [5, raw log 6]: > > * Re-examining the state of the various Jingle proposals. > * Polishing Jingle File Transfer. > * Updating the SDP mapping in [4], including BUNDLE and Trickle-ICE > improvements. > * Documenting and communicating the value proposition of Jingle/XMPP. > > This SIG already includes a number of people participating in discussions= on > the WebRTC and rtcweb mailing lists and is lead by Dave Cridland (chair), > Philipp Hancke, Lance Stout and myself. It is open to anyone, and we are > looking forward to cooperate with the WebRTC and rtcweb working groups to > improve both WebRTC and Jingle. > > The discussion venues are the Jingle mailing list [7] and the Jingle XMPP > multi-user chat room [8]. Our next meeting in the MUC room is Wednesday J= uly > 24 at 15:30 UTC. This group's experience and input would be highly > appreciated, and your participation in both the meeting and the on-going > discussion would be most welcome. > > Thanks, > > Ralph Meijer > > [1] > [2] > [3] > [4] > [5] > [6] > [7] > [8] > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jul 22 08:45: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 4151711E812C for ; Mon, 22 Jul 2013 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 9hfxB3XWCm8r for ; Mon, 22 Jul 2013 08:45:29 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0175A21E80B2 for ; Mon, 22 Jul 2013 08:45:14 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so3714846qcz.14 for ; Mon, 22 Jul 2013 08:45:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Lx+7hA2TdkVdBD+AF7SUuwm7iwPmhnynu9CRMQ3L2yI=; b=X3BU3Uz2PbTddT/HU4wTMMvGzQccP4pcepQzfVxX4vii8e5TfZEOlY2uOvEv+63ocF 23k1SA184fa0cLiYDeZ34AkSPfuYXiBq8tOM5tTHKItjFibN1FUg2HeGXt7+5scprVKL u7FW4hk+66TRiiYYx0aDOx4i8IR28WOcK3HaP42OXZIxv4CQc/TEsQSLDuZ6l79sA4tn 0bRSY+DDSnJbEz9K2aQ4XRxN44c5338MoiXXBgcci6BXsqSaEwJeSGHD2DFc5JEfl1TO cRlMdo68YtBYZm49UbdmjYgc0Pq/sQ9OFkSR9UOosl7xd7U122NAvwE+AxeO5wXdFkQM bGVQ== X-Received: by 10.49.116.176 with SMTP id jx16mr33090928qeb.52.1374507914450; Mon, 22 Jul 2013 08:45:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 22 Jul 2013 08:44:54 -0700 (PDT) In-Reply-To: <51ED4FA2.8070603@gmail.com> References: <51ED4A45.9000703@ik.nu> <51ED4FA2.8070603@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 22 Jul 2013 17:44:54 +0200 Message-ID: To: Daniel-Constantin Mierla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnPcKLqFLXAgAgkKBKmpwFzqb4r5Z4mpfuZhhA76ofQScMmJmFhGyBi0R0CgPng5MxgJAAk X-Mailman-Approved-At: Mon, 22 Jul 2013 09:13:26 -0700 Cc: stox , XMPP Jingle , "public-webrtc@w3.org" , Ralph Meijer Subject: Re: [Stox] [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. 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, 22 Jul 2013 15:45:37 -0000 2013/7/22 Daniel-Constantin Mierla : > On 7/22/13 5:14 PM, I=C3=B1aki Baz Castillo wrote: >> >> Great. First thing you should complain about is the fact that current >> WebRTC specification makes unfeasible for a browser to use SDP-XML as >> defined by XEP-0167. So if you have a SIP server you will be able to >> directly connect from the browser, but if you have a Jingle server you >> will need a gateway. > > You are obviously misinforming here. SIP is the signaling protocol and a = SIP > server has really little to deal with SDP -- I'm sure you know that. I was talking about a SIP device also implementing WebRTC in the media plane. Current WebRTC spec mandates plain-SDP usage in the wire to signal your media description and transport/ICE information to the peer. So if you want to communicate with a XEP-0167 compliant server/endpoint, then you need a gateway to convert the plain-SDP generated by the browser into the SDP-XML version defined by XEP-0167. > And one > cannot call directly a SIP endpoint from the browser, as SIP is not a > mandatory signaling protocol, so there is extensive need of coding a > javascript SIP stack (or reusing an existing one). Reusing existing JavaScript SIP stacks is something good, don't you agree? Please, let's focus: Today from a browser you can speak SIP over WebSocket and connect to a SIP media server/gateway understanding the SDP of WebRTC. So yes, you can talk SIP fom a browser. Today fom a browser you cannot speak XMPP/Jingle (XEP-0167) over WebSocket (or over AJAX) because the browser produces a plain SDP blob, while you need a XML based SDP as XEP-1067 states. You can parse such a SDP blob string in JavaScript and map it into a XML body, but... good luck with that... Hope it is clear now. Regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jul 22 08:55:30 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 8CC8F11E80F6 for ; Mon, 22 Jul 2013 08:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 zFIEs6g2r44w for ; Mon, 22 Jul 2013 08:55:30 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E8D8011E80F7 for ; Mon, 22 Jul 2013 08:55:24 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id f11so902242qae.10 for ; Mon, 22 Jul 2013 08:55:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=IcXN3skJLTWZTHMpoZhv869xvUwIdlddARQUv3Eb+/A=; b=WsZMEpfMO9N2FcrF5w6NsLTHH4qudOQzknrA7V+SEOI4q4tlU5IZk0UoDAPkGHmg/j qhboZp2A4ghvlWNiBgB1sHroRawUXfMOqooeXcd8udLDiOZzcvBu+r3miNSxFsAdH/f8 /FFlEVsQcHUxgD7/ES+JAqdQVb4rNgVTdmVqIkLt8FHFhWZehoW2mPRqh4F921SZoKVN qVPTyq1rM7iNXp3mNI8WOKLRcbPuh/BznRJK0NUGjmIy/QjuTlkrpoTWZbjKJ/ddTsz3 KG4D85ze9WP+Gsyz8NOEIY8CqRcXJbtdrh5PTjbkVS2mZFqvQSmkfK+HqPn35U1qM0+r JZ4g== X-Received: by 10.224.182.79 with SMTP id cb15mr34885234qab.48.1374508519821; Mon, 22 Jul 2013 08:55:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 22 Jul 2013 08:54:59 -0700 (PDT) In-Reply-To: <51ED53E6.10400@ik.nu> References: <51ED4A45.9000703@ik.nu> <51ED53E6.10400@ik.nu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 22 Jul 2013 17:54:59 +0200 Message-ID: To: Ralph Meijer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnDfZOEFKjckS2qvSemzoFQAef3B/Wv0l2lJff3huSXw18LtniIXQifduSzVb7pdKSu5Se+ X-Mailman-Approved-At: Mon, 22 Jul 2013 09:13:45 -0700 Cc: stox@ietf.org, XMPP Jingle , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [Stox] XSF Jingle Special Interest Group. 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, 22 Jul 2013 15:55:30 -0000 2013/7/22 Ralph Meijer : > Hi I=C3=B1aki, > > I have been following the recent discussions for a while now, and think I > understand the various stand points, including yours. > > As I mentioned in my announcement, mapping SDP to Jingle's negotiation > parameters is indeed one of the concerns we are going to look into. > Philipp's work on his WebRTC plugin for Strophe.js [1], which uses Jingle > signalling, has shown that it indeed takes quite some effort to map and > mangle SDP to get things going. The spreadsheet questionnaire that Peter > Thatcher asked people to fill in (thanks!) also has several comments to t= hat > effect. During our discussions on the Jingle mailing list and the meeting > last week, more of such comments were made. > > I want to stress, again, that Jingle's negotiation parameters should not = be > referred to as a flavor of SDP expressed in XML. This is misleading, as i= t > is not managed by MMUSIC, and actually weakens your point of not wanting = SDP > as an API surface. I can understand that looking at the current > specification could give that impression, though. The Jingle examples are > currently interleaved by SDP examples to show the mapping, and we are > looking into making the distinction clearer, maybe even as a document > separate from this one. Thanks for the clarification. So Jingle's session description is not just a plain-to-XML mapping of a common SDP. Good to know. However, wouldn't you prefer to have a pure JS Object with all the media and transport information you require to build your Jingle XML-SDP instead of having to parse a plain SDP string blob? Thanks a lot. -- I=C3=B1aki Baz Castillo From miconda@gmail.com Mon Jul 22 08:28:51 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 CD80521E8099; Mon, 22 Jul 2013 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoHQUwISgXv3; Mon, 22 Jul 2013 08:28:45 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8E21E8063; Mon, 22 Jul 2013 08:28:44 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so6066654wgh.33 for ; Mon, 22 Jul 2013 08:28:37 -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:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=o6UMUpZEhoUIpw5I1Jay1Rj9KBBc7YjlcpB6J5wEiwE=; b=ULHKBZV54+im4RzAcqD+EBHbRBnzpeXK2mMel5m3/d3akv8ijTsOj9mL1mTVEi6Ha9 26jH37VBLGoUqDdr1lK4KBOMH6zmfOBlGgN/7mV6ZKWSVD2krt0n5dBWZY3VoD8zhHoS Ih21beRSPmUvICEz9xr0lo1/fP5DshxIFpz7/VF299obwHeMP82XIzBFBdaZNNjFzKyZ ibgnPkhSqGPkqFcrAyfQVAZd0QzfC+dLDDpDSwGT9H9v2yIJltgHF1DY3FWdf1g9zLyX vH5NH2YWxwpEEBIDtg3bweOvT8TsDiMOWxPNgqTUsSrI34H5nWpBmNqHEufl8SEgr9d7 DGqA== X-Received: by 10.194.179.129 with SMTP id dg1mr20473131wjc.38.1374506917008; Mon, 22 Jul 2013 08:28:37 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id i1sm66815367wiz.6.2013.07.22.08.28.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 08:28:36 -0700 (PDT) Message-ID: <51ED4FA2.8070603@gmail.com> Date: Mon, 22 Jul 2013 17:28:34 +0200 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Ralph Meijer References: <51ED4A45.9000703@ik.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 22 Jul 2013 09:14:01 -0700 Cc: stox@ietf.org, "public-webrtc@w3.org" , "rtcweb@ietf.org" , XMPP Jingle Subject: Re: [Stox] [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. 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: Mon, 22 Jul 2013 15:28:52 -0000 On 7/22/13 5:14 PM, Iñaki Baz Castillo wrote: > Great. First thing you should complain about is the fact that current > WebRTC specification makes unfeasible for a browser to use SDP-XML as > defined by XEP-0167. So if you have a SIP server you will be able to > directly connect from the browser, but if you have a Jingle server you > will need a gateway. You are obviously misinforming here. SIP is the signaling protocol and a SIP server has really little to deal with SDP -- I'm sure you know that. And one cannot call directly a SIP endpoint from the browser, as SIP is not a mandatory signaling protocol, so there is extensive need of coding a javascript SIP stack (or reusing an existing one). Cheers, Daniel > > 2013/7/22 Ralph Meijer : >> Hi all, >> >> I would like to inform the group of the recent formation [1] of the Jingle >> Special Interest Group (SIG) at the XMPP Standards Foundation (XSF). The >> recent increase of activity in the WebRTC and rtcweb working groups and >> related high-profile product developments and announcements were reasons for >> the XMPP Council to decide to concentrate efforts around Jingle in a SIG. >> >> Jingle [2] is a general framework for managing media sessions between XMPP >> Sessions, including, but not limited to, audio/video streams, file transfer >> and application sharing. There are several documents describing applications >> of Jingle and the used transports, most linked from the overall framework >> specification [3]. >> >> The specification of Jingle RTP Sessions [4], most relevant to these working >> groups, defines a Jingle application type for negotiating RTP sessions. It >> has been designed such that interoperability with SIP-based systems is >> possible. This includes mapping negotiation parameters to and from SDP, >> while remaining a signaling protocol in its own right (not merely SDP in >> angle brackets). >> >> The following work items were defined in the kick-off meeting last >> Wednesday, July 17 [5, raw log 6]: >> >> * Re-examining the state of the various Jingle proposals. >> * Polishing Jingle File Transfer. >> * Updating the SDP mapping in [4], including BUNDLE and Trickle-ICE >> improvements. >> * Documenting and communicating the value proposition of Jingle/XMPP. >> >> This SIG already includes a number of people participating in discussions on >> the WebRTC and rtcweb mailing lists and is lead by Dave Cridland (chair), >> Philipp Hancke, Lance Stout and myself. It is open to anyone, and we are >> looking forward to cooperate with the WebRTC and rtcweb working groups to >> improve both WebRTC and Jingle. >> >> The discussion venues are the Jingle mailing list [7] and the Jingle XMPP >> multi-user chat room [8]. Our next meeting in the MUC room is Wednesday July >> 24 at 15:30 UTC. This group's experience and input would be highly >> appreciated, and your participation in both the meeting and the on-going >> discussion would be most welcome. >> >> Thanks, >> >> Ralph Meijer >> >> [1] >> [2] >> [3] >> [4] >> [5] >> [6] >> [7] >> [8] >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From miconda@gmail.com Mon Jul 22 09:22: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 3A66811E8122 for ; Mon, 22 Jul 2013 09:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeyQleikPhqX for ; Mon, 22 Jul 2013 09:22:32 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C71321F8267 for ; Mon, 22 Jul 2013 09:22:03 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id d10so3949857eaj.41 for ; Mon, 22 Jul 2013 09:22:02 -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:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GI5kKrCIoU/VW/s/VAmYbfPJjafjSoQxcZd4ncKu55E=; b=tlSO9JXH9C1jtLg6EZudiVanIWJTc/MWnCa3AZ1CEzID7hRBAxXyoOJllUJ8Cwi/Bk vOFfWPWF1EcrtzVqzg8YiGlDYjsOK4UBInQW1nBAwopxUz3iFiHEdJfg5blc9UShKBYU c9vz630hYencpW0f3OCpIIjB7W0BRANYyzj4AEfjoT7uBjIFKX3KbRreUTPnQ21RLaNA UYTh2T5auRHtFjhXErJ9++OoAklCgkFGZYDF2kMNMawbHfjPTE6nmvXU3dANXjQICC3B CXQoS0eOH56XQpq8Q3f6r9HnYV4M6X5dTEmvo42fu1rzaUSV4if42CPRD154sfUP60DY ZBHQ== X-Received: by 10.14.69.206 with SMTP id n54mr27965055eed.154.1374510122406; Mon, 22 Jul 2013 09:22:02 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id r54sm51909376eev.8.2013.07.22.09.22.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 09:22:01 -0700 (PDT) Message-ID: <51ED5C27.6040406@gmail.com> Date: Mon, 22 Jul 2013 18:21:59 +0200 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51ED4A45.9000703@ik.nu> <51ED4FA2.8070603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 22 Jul 2013 09:26:39 -0700 Cc: stox , XMPP Jingle , "public-webrtc@w3.org" , Ralph Meijer Subject: Re: [Stox] [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. 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: Mon, 22 Jul 2013 16:22:39 -0000 On 7/22/13 5:44 PM, Iñaki Baz Castillo wrote: > 2013/7/22 Daniel-Constantin Mierla : >> On 7/22/13 5:14 PM, Iñaki Baz Castillo wrote: >>> Great. First thing you should complain about is the fact that current >>> WebRTC specification makes unfeasible for a browser to use SDP-XML as >>> defined by XEP-0167. So if you have a SIP server you will be able to >>> directly connect from the browser, but if you have a Jingle server you >>> will need a gateway. >> You are obviously misinforming here. SIP is the signaling protocol and a SIP >> server has really little to deal with SDP -- I'm sure you know that. > I was talking about a SIP device also implementing WebRTC in the media > plane. You wrote a SIP server, just read above. And producing a xml blob instead of text plain blob does not make much difference from the architecture point of view, if that was your concern, nor simplifies things. Cheers, Daniel > Current WebRTC spec mandates plain-SDP usage in the wire to > signal your media description and transport/ICE information to the > peer. So if you want to communicate with a XEP-0167 compliant > server/endpoint, then you need a gateway to convert the plain-SDP > generated by the browser into the SDP-XML version defined by XEP-0167. > > > >> And one >> cannot call directly a SIP endpoint from the browser, as SIP is not a >> mandatory signaling protocol, so there is extensive need of coding a >> javascript SIP stack (or reusing an existing one). > Reusing existing JavaScript SIP stacks is something good, don't you agree? > > > Please, let's focus: > > > Today from a browser you can speak SIP over WebSocket and connect to a > SIP media server/gateway understanding the SDP of WebRTC. So yes, you > can talk SIP fom a browser. > > Today fom a browser you cannot speak XMPP/Jingle (XEP-0167) over > WebSocket (or over AJAX) because the browser produces a plain SDP > blob, while you need a XML based SDP as XEP-1067 states. You can parse > such a SDP blob string in JavaScript and map it into a XML body, > but... good luck with that... > > > Hope it is clear now. > > > Regards. > > > > > -- > Iñaki Baz Castillo > -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From emil@sip-communicator.org Mon Jul 22 09:28:06 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5245321F9E88 for ; Mon, 22 Jul 2013 09:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Pe+8kutJ8lhE for ; Mon, 22 Jul 2013 09:27:30 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id C85D811E8127 for ; Mon, 22 Jul 2013 09:26:48 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so6299894wgh.16 for ; Mon, 22 Jul 2013 09:26:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=sBLwGr2RRxUfZuqqDAVE8oOAeHqmr63o16Hab11zz+U=; b=BevPedp+MT/zWkZBmtPnCHmTYCjLLLNg72WpDObmnNmsyIAiB5IbD6FvQdpX0BuJov oZtONJFgpfV1Q9o+6mUx0cWHoIKw6iAq5UbSEinLg3BOLDRfOe49Ogoxshv3TNW1b9YB U4ohD1UV2G4yFo52RVGnPCChS8OLfi57tHq5hrd/2rygdUXkhfkp9kAbZes0LSELe+pU ABQEmO8lxQYQN9y5IixkeMViLDGRqin30o9gEr9xo+v78MliAkRcZzHYpL3ZMrHjRNd4 rIQQOE/vnNgN5b8ap1oSrHZGFUiTitFbWqcOrJXgpQowj8eFVvV5GwzgyWAXBjRDpPA6 ck5A== X-Received: by 10.180.38.37 with SMTP id d5mr26810867wik.37.1374510369217; Mon, 22 Jul 2013 09:26:09 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:cc7b:5fa5:6ef9:f634]) by mx.google.com with ESMTPSA id l2sm5763200wif.8.2013.07.22.09.26.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 09:26:08 -0700 (PDT) Message-ID: <51ED5D1E.1020000@jitsi.org> Date: Mon, 22 Jul 2013 18:26:06 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51ED4A45.9000703@ik.nu> <51ED4FA2.8070603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk6wztnDm5yXzaeYO7Sda28BbJ3MCSBBfNvZqGmkYKhzWKgzjYanVIfGpebuz/gbuQnXsU/ Cc: Daniel-Constantin Mierla , stox , XMPP Jingle , "public-webrtc@w3.org" , Ralph Meijer Subject: Re: [Stox] [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. 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, 22 Jul 2013 16:28:07 -0000 On 22.07.13, 17:44, I=C3=B1aki Baz Castillo wrote: > 2013/7/22 Daniel-Constantin Mierla : >> On 7/22/13 5:14 PM, I=C3=B1aki Baz Castillo wrote: >>> >>> Great. First thing you should complain about is the fact that current= >>> WebRTC specification makes unfeasible for a browser to use SDP-XML as= >>> defined by XEP-0167. So if you have a SIP server you will be able to >>> directly connect from the browser, but if you have a Jingle server yo= u >>> will need a gateway. >> >> You are obviously misinforming here. SIP is the signaling protocol and= a SIP >> server has really little to deal with SDP -- I'm sure you know that. > > I was talking about a SIP device also implementing WebRTC in the media > plane. Current WebRTC spec mandates plain-SDP usage in the wire to > signal your media description and transport/ICE information to the > peer. I don't think this is true. You can very well translate the SDP to=20 Jingle in the browser and then only send XML on the wire. I completely agree that this would be a pain, but there is nothing that=20 "mandates" against it. Emil --=20 https://jitsi.org From thp@westhawk.co.uk Mon Jul 22 09:29:51 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 5E2AE11E80FB for ; Mon, 22 Jul 2013 09:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 yo3M6H+JlC74 for ; Mon, 22 Jul 2013 09:29:36 -0700 (PDT) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 37B8B21F9E88 for ; Mon, 22 Jul 2013 09:29:32 -0700 (PDT) Received: (qmail 91482 invoked from network); 22 Jul 2013 16:29:30 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 22 Jul 2013 16:29:30 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id BBA4818A059C; Mon, 22 Jul 2013 17:29:29 +0100 (BST) Received: from [192.168.157.113] (unknown [192.67.4.41]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7FF8818A0341; Mon, 22 Jul 2013 17:29:29 +0100 (BST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: tim panton In-Reply-To: <51ED5D1E.1020000@jitsi.org> Date: Mon, 22 Jul 2013 17:29:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1BCF6D21-3FC9-4E2C-A190-50B37440C48C@westhawk.co.uk> References: <51ED4A45.9000703@ik.nu> <51ED4FA2.8070603@gmail.com> <51ED5D1E.1020000@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Mon, 22 Jul 2013 09:31:07 -0700 Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Daniel-Constantin Mierla , stox , "public-webrtc@w3.org" , Ralph Meijer , XMPP Jingle Subject: Re: [Stox] [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. 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, 22 Jul 2013 16:29:52 -0000 On 22 Jul 2013, at 17:26, Emil Ivov wrote: >=20 >=20 > On 22.07.13, 17:44, I=F1aki Baz Castillo wrote: >> 2013/7/22 Daniel-Constantin Mierla : >>> On 7/22/13 5:14 PM, I=F1aki Baz Castillo wrote: >>>>=20 >>>> Great. First thing you should complain about is the fact that = current >>>> WebRTC specification makes unfeasible for a browser to use SDP-XML = as >>>> defined by XEP-0167. So if you have a SIP server you will be able = to >>>> directly connect from the browser, but if you have a Jingle server = you >>>> will need a gateway. >>>=20 >>> You are obviously misinforming here. SIP is the signaling protocol = and a SIP >>> server has really little to deal with SDP -- I'm sure you know that. >>=20 >> I was talking about a SIP device also implementing WebRTC in the = media >> plane. Current WebRTC spec mandates plain-SDP usage in the wire to >> signal your media description and transport/ICE information to the >> peer. >=20 > I don't think this is true. You can very well translate the SDP to = Jingle in the browser and then only send XML on the wire. >=20 > I completely agree that this would be a pain, but there is nothing = that "mandates" against it. It is a pain - but it is do-able - take a look at PhonoSDK on github. T. >=20 > Emil >=20 > --=20 > https://jitsi.org >=20 >=20 From fippo@goodadvice.pages.de Mon Jul 22 10:37:18 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 BA35111E80FB for ; Mon, 22 Jul 2013 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[AWL=-0.435, 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 DbJzVpGO8-aW for ; Mon, 22 Jul 2013 10:37:12 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 9450911E80DE for ; Mon, 22 Jul 2013 10:36:56 -0700 (PDT) Received: from [192.168.2.100] (p54970320.dip0.t-ipconnect.de [84.151.3.32]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6MHarrT013744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 19:36:54 +0200 Message-ID: <51ED6DAF.9010004@goodadvice.pages.de> Date: Mon, 22 Jul 2013 19:36:47 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stox@ietf.org References: <51ED4A45.9000703@ik.nu> In-Reply-To: <51ED4A45.9000703@ik.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Jingle Subject: Re: [Stox] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. 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, 22 Jul 2013 17:37:19 -0000 Am 22.07.2013 17:05, schrieb Ralph Meijer: > Hi all, > > I would like to inform the group of the recent formation [1] of the > Jingle Special Interest Group (SIG) at the XMPP Standards Foundation > (XSF). The recent increase of activity in the WebRTC and rtcweb working > groups and related high-profile product developments and announcements > were reasons for the XMPP Council to decide to concentrate efforts > around Jingle in a SIG. The point where this is interesting for STOX is mostly the -media draft. For example we can fix some of the bugs (like a=fmtp) in XSF territory. Potentially, the -media draft is even the place where to define the mapping between jingles xmlish session description and SDP. Even though I would attempt to clearly separate that from jingle signalling conceptually and in the document. From stpeter@stpeter.im Tue Jul 23 19:57:41 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 0D6ED11E81C3 for ; Tue, 23 Jul 2013 19:57:41 -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 LMIU-Wnh4yyg for ; Tue, 23 Jul 2013 19:57:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6283611E81C0 for ; Tue, 23 Jul 2013 19:57:33 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ABD03414B4; Tue, 23 Jul 2013 20:59:22 -0600 (MDT) Message-ID: <51EF429A.3010506@stpeter.im> Date: Tue, 23 Jul 2013 20:57:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <31EA9B37-9F4C-4473-A1BC-2B18759B865D@ag-projects.com> In-Reply-To: <31EA9B37-9F4C-4473-A1BC-2B18759B865D@ag-projects.com> X-Enigmail-Version: 1.5.1 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "stox@ietf.org" , "De Vries, Michael \[USA\]" Subject: Re: [Stox] Nickname Usage Conflict Resolution 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, 24 Jul 2013 02:57:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/20/13 7:48 AM, Saúl Ibarra Corretgé wrote: > Hi Michael, > > On Jul 20, 2013, at 1:07 AM, De Vries, Michael [USA] wrote: > >> Hello everyone, >> >> I have a concern with the suggested possible resolutions for a >> Nickname Usage Conflict in the draft-ietf-stox-groupchat-00 >> document. In section 3.2, the document says >> >> | Alternatively [to translating the MSRP 425 message to a >> error], | the gateway might generate a new >> nickname request on | behalf of the XMPP user, thus shielding >> the XMPP client from handling | the conflict error. >> >> Additionally, section 5 says >> >> | If there is a conflict between the SIP nickname and the XMPP >> | nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is >> responsible for | adjusting the nickname to avoid the conflict >> and for informing the | SIP or XMPP client of the unique >> nickname used to join the chatroom. >> >> First, section 3.2 suggests that the gateway may choose to >> generate a new nickname, but can instead merely forward on the >> translated MSRP 425 or error, whereas section 5 says >> that the gateway is responsible for (aka MUST) adjusting the >> nickname in the event of a conflict. Both of these sections >> suggest that in the case of a nickname conflict the gateway may >> act independently of the client to change the client-generated >> nickname to one which is unique within the context of the >> chatroom. I'm not certain this is the most appropriate approach. >> Nicknames are important in that they are needed to facilitate >> private messaging and other features, as well as being an >> important part of user identification. It seems risky to >> automatically generate a new nickname when a conflict is found, >> instead of merely presenting the error to the user (via MSRP 425 >> message or error) so that they can choose a new >> nickname via their client. Additionally, a cursory examinatio n >> of the XMPP, MSRP, and MUC RFCs/XEPs does not appear to show any >> recommendation that nicknames be automatically generated in the >> event of a conflict. >> >> I believe that it would be better to require that the gateway >> merely forward on the translated MSRP 425 or error >> instead of attempting to address the conflict automatically, but >> I may not sufficiently understand the reasoning behind the >> automated nickname resolution. >> > > I agree. This is how things are usually handled in MSRP. When > testing things in XMPP however, not every client is able to > properly deal with nickname conflicts though. Peter, maybe this was > the reason why that text was added? I doubt that was the reason, since I don't believe in designing protocols around buggy software. :-) Many XMPP clients will indeed shield the user from making a decision about the nickname (e.g., if "stpeter" is taken they will cycle through nicks like "stpeter1" or "stpeter_" or whatever). So pushing an error back to the originating client seems fine to me in all cases. Question: if the gateway were to choose a nick on behalf of the client, are we sure that the chosen nick would get communicated back to the originating client? In any case, I think that what Mike proposes is sensible. 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/ iQIcBAEBAgAGBQJR70KaAAoJEOoGpJErxa2p478P/RLyVu5bqCMkC6ZgsPg8d1+0 KLcn1lwfsY/ivbXnDfugo0jrqH/hIr323K2Fjrmghdsg5kQnZ64ZG5afKyzP38gT c2HRYVSPhiPzqxD3h3Sm4w3GOjlJUqmWe8qijkszhkkbOMWuZC9DhWg738G2Kpwc AraKbB0OXmChJmdSlhIeps5cWfxtSyPQ1Gf6KCNoyAsloVVRjoGJymOZkm2YKnCI yQJsDT/ugkCpdNghUE9IiOXXtJ5uS2JAVfqdxJ1wrelRLBo++b+fBsGTz+5R7szt eQ7VnOyYX2smPD4gYlkcYHZ1gfvCT7a/4lXX5vOKwqxP3QcBoZp55ahFIzEmfkub zecoBhQonKZ06uXiWH6X7rQR+RhMhnPd63MkjxfJ0N0LsWQBhk+5Zge1bSvfqWLa 1XegEZuuVgj1ylytBjkLdePZc4kkK8ESG5u5gm300F6AeKBG3pW4qvft3jZ3ITxM PbhMfOJK+Pxn5roxy0wljBbQC3GWrC2KZTkpSoQXK2Wgh4SAI6IMfqJMVq4GPvCH Vd/IY6Ap9OiRyoPvDfmBag0qu1BXHK4tQGTpnCRMj3fXbU55OJ6I0ZhkTsde858M gb5CsHmW7an6cvgMYoxx/d95C/mZ4nc40U3nnZBX03cN2L9elhbX5V+Co/02OBLl flUT0UI8+ETldks/3q8u =BOf5 -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Jul 23 20:08:41 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 D9C1111E81CF for ; Tue, 23 Jul 2013 20:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.969 X-Spam-Level: X-Spam-Status: No, score=-101.969 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 slQVbOeG5kXL for ; Tue, 23 Jul 2013 20:08:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5012E11E81C0 for ; Tue, 23 Jul 2013 20:08:35 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B74DC414B4; Tue, 23 Jul 2013 21:10:25 -0600 (MDT) Message-ID: <51EF4531.6090902@stpeter.im> Date: Tue, 23 Jul 2013 21:08:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Lundberg References: In-Reply-To: X-Enigmail-Version: 1.5.1 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] Comments on draft-ietf-stox-presence-00 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, 24 Jul 2013 03:08:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mike, thanks for the feedback. On 7/19/13 6:01 AM, Michael Lundberg wrote: > Peter, > > I think draft-ietf-stox-presence-00 looks good. I had a previous > comment to an earlier version that was not addressed that I'm > incuding it again as I think it is important for the document. Sorry I missed that. > I think it would be good to add the element to Table 7, > with a note similar to the one provided in Table 6. This will > provide a method for mapping 'away' and 'dnd' information in the > opposite direction. Agreed. (BTW, these are actually Table 1 and Table 2 -- we need to fix the numbering.) > Similar to the note in Table 6, this would require the SIP > implementation to support the 'jabber:client' namespace. If the > SIP implementation supports the namespace, the gateway can then map > the values directly into the element of the XMPP presence > messages. True. One clarifying question: when you say "if the SIP implementation supports the namespace", do you mean the XMPP-to-SIP gateway or the SIP user agent? > The only other thing I saw was that the below sentence in Section > 3.2.3 is missing the word "send" after SHOULD. > > Current: > > Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway > SHOULD a presence stanza of type "unsubscribed" to the XMPP user: > > New: > > Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway > SHOULD send a presence stanza of type "unsubscribed" to the XMPP > user: Noted. :-) 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/ iQIcBAEBAgAGBQJR70UxAAoJEOoGpJErxa2pGHgP/3egwP1prfQ0se36jXI6wlR4 LaYerbpXqnTBrlHXft1sVvCCVFHpCbRgRecUYm5sFwC5nDtxN83u4UpVEuijO7Wv ajMYLNNz3m0z/Vo2nfK94FzH5wK2tVNWBV5orAbIfc+SH60WTw2HOgSntoK/yvTK iiX8hpfYTv09ZX3iE4ZnBoPVEqG2oxo9CKouCRl4WxwPEE3rZF+PcOn6PvmPWpvE Xf5htIDKmvOv53mM4OU7KpR0j+2QyS6egkbOOsxki0gT/m5ZYm1HmF2WA4b5LXOl 1/mM+KQM2qukcr5BHVy2HV53cybkCx8Nf5DhtkXOG5Ti57jiWgvomeLDOTqgLf3w 8yFgLKHD4RFb6z/9k8k4EdHx9aMO+HhCMkKK2qeHPc6cf96vjMKAASMdjcRsmlOu 0pzudOpe9cfRnzSQamn6/0/H7JX/9O8fZ2Ya7/Cb6qdr7KUCrOAIRIgK07fmMDIY G3lgXSkzQTrYuIQ34mp+jXEdZf3+J4B422y8UvoZ5QmgVMNNrkARuv+DWnGprCrQ EnKnbFGJbdNfLuof5RTg8FaJofKeWPCj2UAsRbVn0le1sbjoy43hvRF9r5Gv5KzG 2K9Ei8/XoYPkZRWdst6/RpQ/R5Nox40xK/SCWs067P7qsTKGByciEJVAjm336vAy vFM/cMMZUGP6KyKTxwaJ =YNJV -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Jul 24 11:09: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 4FA4411E8229 for ; Wed, 24 Jul 2013 11:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 aBRmyzkbw1PT for ; Wed, 24 Jul 2013 11:09:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 041D011E8125 for ; Wed, 24 Jul 2013 11:09:29 -0700 (PDT) Received: from sjc-vpn5-361.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 89C2C40044; Wed, 24 Jul 2013 12:11:21 -0600 (MDT) Message-ID: <51F01857.1050803@stpeter.im> Date: Wed, 24 Jul 2013 12:09:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "stox@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Stox] draft slides for core, presence, im, chat 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, 24 Jul 2013 18:09:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Draft slides for discussion of the -core, -presence, -im, and -chat specfications are here: https://stpeter.im/files/ietf87-stox-core-presence.pdf As you can see, there are very few open issues. If folks provide further feedback about these specs in the next few days, I'll update the slides accordingly. If not, mine will be a very short presentation and we'll have more time to discuss the -groupchat and -media 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/ iQIcBAEBAgAGBQJR8BhWAAoJEOoGpJErxa2p0i0P/2oQRzJcvny4sckDFoJjvEDl XyWFlObB5EsmHXQ6D70F+3Zvi5r8SeR6lNlt/0sxmFpgCOymEqPMO+9DKvV9gGd0 EysRlE1XwYB8PFWS7xbGO5Ivswk3qCuP7Rz6H5f0kRDDAvcTDM7rlFMDtO8qChAI oXPKfLs96AXl9JBxApvyOnA+mRa6d6DXV628G6HhaZ5mi87bQi2hoLt5jns5q7/C fOQYLSSVEQdnxfo4nLOoYDN0w/NpObc41g6vPjUxnSDodS+w27lQA/hItZYHmw2D Wfbk+bC63U1pJVS+MPKMf0VbJfctgoOHUe/Lz0IIpVwCMdFL6mxeX9bRetNKMVvV h2OSj+vWqvNjrGnkXAZ79SwuWYIxwsx15XFSBO/8H0ByhSt/KdFEXepa/um5YeAh 5+yYWbCU4ngDciLgZGeWe5b9M9WOQ6LM+R7Zb27vAGq85YyArIut+6fDHgcAIBNx uAg5iWiWzwfEcWLg82UeVQQac+HBR4aF7q+YlCwCXmkz2uKZfQoXWem5NNhnMK7F YjIfNcyXrui0LBqJU0VsZSy3tT46KORymP4rPo8hDZWUwgaMit8sXMva7WP2twn2 3K6RfH2CHXGiP9BBlWV/X2hsLhe9EgvgvI7fikL7KxSEFV4qyLYt1Uu50WOBcjUe R6A1AOT7uIT4JyuMroAK =heGC -----END PGP SIGNATURE----- From saul@ag-projects.com Fri Jul 26 06:43: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 694C021F98AD for ; Fri, 26 Jul 2013 06:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfIAjG9aG+hi for ; Fri, 26 Jul 2013 06:43:17 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E021F88FE for ; Fri, 26 Jul 2013 06:43:17 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id F3185B35DB; Fri, 26 Jul 2013 15:43:15 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D5107B017A for ; Fri, 26 Jul 2013 15:43:14 +0200 (CEST) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jul 2013 15:43:14 +0200 Message-Id: <602FFF00-D276-4659-9B75-C45A89A3C15E@ag-projects.com> To: stox@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [Stox] draft slides for groupchat, media 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, 26 Jul 2013 13:43:37 -0000 Hi, Here are draft slides for the groupchat and media documents: = https://dl.dropboxusercontent.com/u/2243619/stox-ietf87.pdf I didn't have time to process Philipp's feedback, I'll incorporate it = ASAP. Also, I'll be AFK until sunday, but if further feedback is = provided in the meantime I'll have the slides modified on monday. Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From michaellundberg.ietf@gmail.com Fri Jul 26 07:50: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 9B80F21F918C for ; Fri, 26 Jul 2013 07:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWQ3LuUl5vQU for ; Fri, 26 Jul 2013 07:50:38 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 07CBA21F8AA1 for ; Fri, 26 Jul 2013 07:50:37 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x55so1990076wes.32 for ; Fri, 26 Jul 2013 07:50:36 -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=QIfV9X7ZoJXUXWvRVhNcDrtzypEhBqasJzcJEkiGPHA=; b=yb9SPItnuG3B01PFOSS8Z7HJog/4Skw44E41/EHf+JiKzZ4IlSfWDj7nNwUzghNRvq ANJe8eu7LkWpgliyz8DRJ8d6nss4/XswEzXM9qL0Cp5B4CTCwlEaYr6WMUnsWq6NDH5j fFKteCM217RU8qWJlftUQIjwoKCd2YCHV5B8VM/ZABDYi68IPkE3iU3bL0EzV+2+KvyF VcZwx98bYoSJpjJbehCw9aeKoDcMA6cZTtSn6ZWfuJ6grAv4qgP9SL2S25HNpr5ZVFSM x1o1R6y4oafmvzQTZY+C2k+RBbHH5ZUNlaSZHJjgSIVMYotI4tW611C4fHZuMZ+Tcvsl D4Yw== MIME-Version: 1.0 X-Received: by 10.180.108.129 with SMTP id hk1mr5983184wib.42.1374850235871; Fri, 26 Jul 2013 07:50:35 -0700 (PDT) Received: by 10.216.202.10 with HTTP; Fri, 26 Jul 2013 07:50:35 -0700 (PDT) In-Reply-To: <51EF4531.6090902@stpeter.im> References: <51EF4531.6090902@stpeter.im> Date: Fri, 26 Jul 2013 10:50:35 -0400 Message-ID: From: Michael Lundberg To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: stox@ietf.org Subject: Re: [Stox] Comments on draft-ietf-stox-presence-00 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, 26 Jul 2013 14:50:40 -0000 Peter, Thanks. See below for a response to your question. Thanks, Michael On Tue, Jul 23, 2013 at 11:08 PM, Peter Saint-Andre wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Mike, thanks for the feedback. > > On 7/19/13 6:01 AM, Michael Lundberg wrote: > > Peter, > > > > I think draft-ietf-stox-presence-00 looks good. I had a previous > > comment to an earlier version that was not addressed that I'm > > incuding it again as I think it is important for the document. > > Sorry I missed that. > > > I think it would be good to add the element to Table 7, > > with a note similar to the one provided in Table 6. This will > > provide a method for mapping 'away' and 'dnd' information in the > > opposite direction. > > Agreed. > > (BTW, these are actually Table 1 and Table 2 -- we need to fix the > numbering.) > > > Similar to the note in Table 6, this would require the SIP > > implementation to support the 'jabber:client' namespace. If the > > SIP implementation supports the namespace, the gateway can then map > > the values directly into the element of the XMPP presence > > messages. > > True. > > One clarifying question: when you say "if the SIP implementation > supports the namespace", do you mean the XMPP-to-SIP gateway or the > SIP user agent? Good question. It would be benificial if both supported the namespace, but only the gateway is probably required to. If the client supports the namespace, then the gateway would just need to map between the elements described in this document. If the client doesn't support the namespace, the gateway would most likely need to do an additional translation into a namespace the client does understand. In this case, the values might not be the same between the two namespaces, and therefore things are 'lost' in translation. This is one of the big issues with presence mapping today as many implementations have thier own implementation specific namespace, which makes it hard to map between different implementations. Both the implementation specific and common namespaces could coexist, where the implementation specific namespace is used for internal communication and a common, standard namespace (e.g., 'jabber:client' ) is used when communicating between different implementations. > > The only other thing I saw was that the below sentence in Section > > 3.2.3 is missing the word "send" after SHOULD. > > > > Current: > > > > Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway > > SHOULD a presence stanza of type "unsubscribed" to the XMPP user: > > > > New: > > > > Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway > > SHOULD send a presence stanza of type "unsubscribed" to the XMPP > > user: > > Noted. :-) > > 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/ > > iQIcBAEBAgAGBQJR70UxAAoJEOoGpJErxa2pGHgP/3egwP1prfQ0se36jXI6wlR4 > LaYerbpXqnTBrlHXft1sVvCCVFHpCbRgRecUYm5sFwC5nDtxN83u4UpVEuijO7Wv > ajMYLNNz3m0z/Vo2nfK94FzH5wK2tVNWBV5orAbIfc+SH60WTw2HOgSntoK/yvTK > iiX8hpfYTv09ZX3iE4ZnBoPVEqG2oxo9CKouCRl4WxwPEE3rZF+PcOn6PvmPWpvE > Xf5htIDKmvOv53mM4OU7KpR0j+2QyS6egkbOOsxki0gT/m5ZYm1HmF2WA4b5LXOl > 1/mM+KQM2qukcr5BHVy2HV53cybkCx8Nf5DhtkXOG5Ti57jiWgvomeLDOTqgLf3w > 8yFgLKHD4RFb6z/9k8k4EdHx9aMO+HhCMkKK2qeHPc6cf96vjMKAASMdjcRsmlOu > 0pzudOpe9cfRnzSQamn6/0/H7JX/9O8fZ2Ya7/Cb6qdr7KUCrOAIRIgK07fmMDIY > G3lgXSkzQTrYuIQ34mp+jXEdZf3+J4B422y8UvoZ5QmgVMNNrkARuv+DWnGprCrQ > EnKnbFGJbdNfLuof5RTg8FaJofKeWPCj2UAsRbVn0le1sbjoy43hvRF9r5Gv5KzG > 2K9Ei8/XoYPkZRWdst6/RpQ/R5Nox40xK/SCWs067P7qsTKGByciEJVAjm336vAy > vFM/cMMZUGP6KyKTxwaJ > =YNJV > -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Jul 26 08:55: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 E47ED21F9929 for ; Fri, 26 Jul 2013 08:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[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 hnUhrrkmKv8V for ; Fri, 26 Jul 2013 08:55:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CE00921F9130 for ; Fri, 26 Jul 2013 08:55:41 -0700 (PDT) Received: from che-vpn-cluster-2-509.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E67F40042; Fri, 26 Jul 2013 09:57:39 -0600 (MDT) Message-ID: <51F29BF9.3070506@stpeter.im> Date: Fri, 26 Jul 2013 17:55:37 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Lundberg References: <51EF4531.6090902@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] Comments on draft-ietf-stox-presence-00 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, 26 Jul 2013 15:55:47 -0000 On 7/26/13 4:50 PM, Michael Lundberg wrote: > One clarifying question: when you say "if the SIP implementation > supports the namespace", do you mean the XMPP-to-SIP gateway or the > SIP user agent? > >> Good question. It would be benificial if both supported the >> namespace, but only the gateway is probably required to. If the >> client supports the namespace, then the gateway would just need to map >> between the elements described in this document. > >> If the client doesn't support the namespace, the gateway would most >> likely need to do an additional translation into a namespace the >> client does understand. In this case, the values might not be the >> same between the two namespaces, and therefore things are 'lost' in >> translation. This is one of the big issues with presence mapping today >> as many implementations have thier own implementation specific >> namespace, which makes it hard to map between different >> implementations. Both the implementation specific and common >> namespaces could coexist, where the implementation specific namespace >> is used for internal communication and a common, standard namespace >> (e.g., 'jabber:client' ) is used when communicating between different >> implementations. Yes, I think that makes sense. I'm not sure exactly how to translate that into text (especially the part about proprietary / non-standard namespaces), but I'll work something up for consideration by the list. Peter -- Peter Saint-Andre https://stpeter.im/ From fippo@goodadvice.pages.de Sat Jul 27 13:14: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 3EA2F21F99C2 for ; Sat, 27 Jul 2013 13:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 iuYvHK5SjODN for ; Sat, 27 Jul 2013 13:14:47 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 39AA821F99C1 for ; Sat, 27 Jul 2013 13:14:46 -0700 (PDT) Received: from [10.0.0.23] (f052137206.adsl.alicedsl.de [78.52.137.206]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6RKEbKh001482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jul 2013 22:14:41 +0200 Message-ID: <51F42A2C.7010300@goodadvice.pages.de> Date: Sat, 27 Jul 2013 22:14:36 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <602FFF00-D276-4659-9B75-C45A89A3C15E@ag-projects.com> In-Reply-To: <602FFF00-D276-4659-9B75-C45A89A3C15E@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] draft slides for groupchat, media 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: Sat, 27 Jul 2013 20:14:53 -0000 > I didn't have time to process Philipp's feedback, I'll incorporate it ASAP. Also, I'll be AFK until sunday, but if further feedback is provided in the meantime I'll have the slides modified on monday. Those were minor inconsistencies if I recall correctly. The examples in the draft and some text is based on an old version of the jingle specs. We can sit down some time next week and sort this out. From stpeter@stpeter.im Sun Jul 28 03:20: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 20BA521F9D4C for ; Sun, 28 Jul 2013 03:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[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 ZxH6HtNPibX9 for ; Sun, 28 Jul 2013 03:20:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C384E21F9DA1 for ; Sun, 28 Jul 2013 03:20:03 -0700 (PDT) Received: from ergon.local (unknown [195.202.153.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DB23240049; Sun, 28 Jul 2013 04:22:06 -0600 (MDT) Message-ID: <51F4F050.2040309@stpeter.im> Date: Sun, 28 Jul 2013 12:20:00 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <51C1F1AB.1040701@jitsi.org> 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, emcho@jitsi.org, saul@ag-projects.com Subject: Re: [Stox] Mapping for media signaling: still about the scope 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: Sun, 28 Jul 2013 10:20:37 -0000 On 6/20/13 1:12 PM, Markus.Isomaki@nokia.com wrote: > Hi Emil, Hi Markus, at the XMPP hackfest yesterday I chatted about related issues with Philipp Hancke, which triggered a few thoughts... > See inline. > > Emil Ivov [mailto:emcho@jitsi.org] wrote: > >> On 19.06.13, 13:56, Markus.Isomaki@nokia.com wrote: >>> Hi Emil, Saul, Peter, and others, >>> >>> Recently I raised some questions about the scope of the >>> 'sip-xmpp-media' and the related deliverable on the 'mapping for >>> media signaling': >>> http://www.ietf.org/mail-archive/web/stox/current/msg00025.html >>> >>> Now that STOX is officially up and running I'd like us to make >>> an actual plan on what the scope of this document should be, i.e. >>> what features are explicitly going to be part of this mapping >>> spec. Although people have successfully implemented SIP-to-XMPP >>> media signaling gateways, I at least see this topic to have some >>> complexity due to: >>> >>> -SDP offer/answer is a moving target as new features are being >>> added as we speak, >> >> Well ... it is and it isn't. 3264 isn't really changing and all >> extensions are supposed to keep backward compatibility with it. >> > > Right. That's good. > >>> including "bundle" and "trickle-ICE". We can't know about what >>> features will be added later on. >> >> No, but we could include some that we know of ... like "bundle" and >> "trickle- ICE" :). >> >> Trickle ICE would be easier because we already have it in Jingle >> and the SIP version shouldn't take long. >> > > That's one of the "administrative" decisions we should make about the > "first release" of the media signaling mapping *RFC*. Do we only take > in features/extensions that are completed RFCs or XSF XEPs, so that > we for quite big certainty can get a mature document to IESG in > October. And then extend it with new features once they complete, > perhaps one or two years later, perhaps in multiple small steps. Or, > do we already take features like "bundle" and "trickle-ICE" in, and > aim to get the document to IESG at some later point, for instance > March 2014. Trickle-ICE for SIP may not take long, but I bet it will > at least take longer than this WG is supposed to live ;-) > > I don't have an opinion about this as a co-chair. This is a question > to people implementing and deploying the gateways or relying on them. > What is the most useful initial scope for you? How important it is to > have an RFC out this year vs. covering as many features as possible? > I mean technically a draft might be as useful to an implementer as an > RFC on those parts that are stable while others are developed, but > would there be some > interoperability/technical/political/marketing/getting-actually-something-completed > reason to get an RFC out ASAP? > > The only guidance we have at this point is that our charter expects > us to complete in October, and in this case, unlike the normal IETF > WG process, I at least as a co-chair intend to take that seriously > :-) > >>> -There are features currently supported in XMPP that are not >>> currently supported in SIP (and perhaps vice versa?), such as the >>> trickle-ICE support in Jingle. >> >> As mentioned. I don't think trickle-ICE would be a problem. I >> believe separating transport and encoding information would be a >> bigger hurdle but if we accept that urn:ietf:rfc:3264 means one >> shouldn't do this. >> >>> -Regardless of what is supported in each protocol in general, >>> the actual SIP and XMPP clients will support different sets of >>> features. >> >> Right. >> >>> Ideally, some things might be mapped transparently in the gateway >>> in an "algorithmic" manner. >> >> I don't believe this would be possible. >> > > Good, then my understanding seems to be correct. > >>> And ideally, the clients supporting different feature sets can >>> negotiate end-to-end without needing for the gateway to mediate. >>> However, I'm not sure how easy this will be in practice. >>> >>> Actually one reason why I see these complications may be that I >>> don't have a very good overall understanding about how SDP O/A >>> (as in RFC 3264 syntax and semantics) is mapped to XMPP/Jingle >>> (as in its XML based syntax) are in general kept "in synch". For >>> instance, if IETF extends SDP O/A in some way, will that always >>> require an explicit corresponding extension XEP by the XSF, or is >>> there some more straightforward "algorithmic" way to convey >>> something new on the SIP/SDP side to the XMPP/Jingle side. >> >> Well, the good thing about O/A extensions is that they generally >> preserve backward compatibility. This is valid for things like ICE, >> trickle ICE, rtcp-mux, bundle. So as long as we support 3264 we >> should be OK. I think :) >> > > Yes, let's stick to that theory ;-) > > ... > >> >>> -What will happen to features supported on one or either side of >>> the gateway that the gateway is not aware of- can some things be >>> "transparently" mapped or will the gateway become the "blocking >>> factor" in the middle. (I.e., will the session setup be limited >>> to the features the gateway explicitly needs to "understand".) >> >> I don't think the gateway could just forward anything because this >> would imply a straightforward mapping from any SDP attribute to a >> Jingle element. >> >> Maybe gateways could behave as regular SIP B2BUAs: they forward >> the things that they understand and they remove those that they >> don't understand or support. >> > > OK, that simplifies things as well. (Again was just checking I'm not > missing any end-to-end magic that might exist. But apparently not > ;-) > >> Thoughts? >> >>> -How will we extend the mapping spec in the future and how should >>> the initial spec take this into account. >> >> As in administratively? >> > > In some sense yes. I would expect perhaps some brief section that > gives guidelines to the authors who in the future want to extend this > mapping spec with some new feature. > > And would be rather do a full-fledged '-bis' spec at some point or a > bunch or incremental extension drafts on top of the baseline. As an > example "An extension to SIP-XMPP media signaling mapping to support > trickle-ICE". I like that approach. The Jingle XEPs already define SDP mappings for the base use cases, and that content could be moved to the stox-media I-D. If additional features are defined in SIP, SDP, or Jingle (trickle-ICE, BUNDLE, multistream, etc.) then we can specify those in incremental extensions. Peter -- Peter Saint-Andre https://stpeter.im/ From fippo@goodadvice.pages.de Sun Jul 28 03:56:49 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 7D1E421F9DCB for ; Sun, 28 Jul 2013 03:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[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 kJBTIogTh-7U for ; Sun, 28 Jul 2013 03:56:43 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 7681D21F9DA1 for ; Sun, 28 Jul 2013 03:56:43 -0700 (PDT) Received: from [130.129.18.133] (dhcp-1285.meeting.ietf.org [130.129.18.133]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6SAuaXJ016638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 28 Jul 2013 12:56:41 +0200 Message-ID: <51F4F8E4.2070105@goodadvice.pages.de> Date: Sun, 28 Jul 2013 12:56:36 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: stox@ietf.org References: <51C1F1AB.1040701@jitsi.org> <51F4F050.2040309@stpeter.im> In-Reply-To: <51F4F050.2040309@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Stox] Mapping for media signaling: still about the scope 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: Sun, 28 Jul 2013 10:56:49 -0000 Am 28.07.2013 12:20, schrieb Peter Saint-Andre: [...] > I like that approach. The Jingle XEPs already define SDP mappings for > the base use cases, and that content could be moved to the stox-media > I-D. If additional features are defined in SIP, SDP, or Jingle > (trickle-ICE, BUNDLE, multistream, etc.) then we can specify those in > incremental extensions. Right. The problem on the XSF side is that this mapping is currently spread over (from the top of my head) XEPs 0166, 0167, 0176, (0177 doesn't bother mapping), 0293, 0294 and 0320. This is something that needs to be more centralized anyway and the stox-media draft might be the normative place to do this. From Markus.Isomaki@nokia.com Sun Jul 28 07:15: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 1DB7F21F9CAD for ; Sun, 28 Jul 2013 07:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[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 HXJHn4m0DLAd for ; Sun, 28 Jul 2013 07:15:29 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id BE1A021F9CAC for ; Sun, 28 Jul 2013 07:15:29 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6SEFJew015016; Sun, 28 Jul 2013 17:15:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Jul 2013 17:15:19 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.18]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0136.001; Sun, 28 Jul 2013 14:15:18 +0000 From: To: , Thread-Topic: [Stox] Mapping for media signaling: still about the scope Thread-Index: Ac5s3MA7fW54rEx1RRO+pgL1gkj4zQAOhceAACMblMAHdi+XAAABRzsAAAZD1WA= Date: Sun, 28 Jul 2013 14:15:17 +0000 Message-ID: References: <51C1F1AB.1040701@jitsi.org> <51F4F050.2040309@stpeter.im> <51F4F8E4.2070105@goodadvice.pages.de> In-Reply-To: <51F4F8E4.2070105@goodadvice.pages.de> 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+/nZJb9Kg7Iv/YdXDG3jsbgoPRJrYyGPl+RLUy5o34pe1STuA2RpMSi077FMJtsQYCEodI7KBWg9ffclhoduPnayiFhwzReIw/VnMKcsz//oIBJDXVwpuXFGRIJZxiYjmuaNKS9a3pbBGCq5tU95fJcY5rB307tGcWSGlGkQ4tCxi2vH+3ZcePW5GHk1IeGyJogUs0wTjBSPiIeXeQaIpUBFFcmTWmh/ngZQRJKyH4cNW+CFlzU2cBE2iQQHlNE0jhpOByZKSJVg== x-originating-ip: [91.152.96.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jul 2013 14:15:19.0367 (UTC) FILETIME=[E3D1F570:01CE8B9C] X-Nokia-AV: Clean Subject: Re: [Stox] Mapping for media signaling: still about the scope 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: Sun, 28 Jul 2013 14:15:35 -0000 Hi Peter, Philipp, Philipp Hancke wrote, >=20 > Am 28.07.2013 12:20, schrieb Peter Saint-Andre: > [...] > > I like that approach. The Jingle XEPs already define SDP mappings for > > the base use cases, and that content could be moved to the stox-media > > I-D. If additional features are defined in SIP, SDP, or Jingle > > (trickle-ICE, BUNDLE, multistream, etc.) then we can specify those in > > incremental extensions. >=20 > Right. The problem on the XSF side is that this mapping is currently spre= ad > over (from the top of my head) XEPs 0166, 0167, 0176, (0177 doesn't bothe= r > mapping), 0293, 0294 and 0320. This is something that needs to be more > centralized anyway and the stox-media draft might be the normative place = to > do this. > It sounds to me then that the STOX WG should: - Consolidate the mappings for all stable specs and features into the curre= nt -media document and aim to publish it as an RFC according to the current= charter, i.e. deliver it to the IESG (hopefully) already before IETF 88. T= he value of stabilizing and publishing that document would be that the mapp= ings would be found in one place. - Start, first as individual (non-WG) drafts, incremental extensions for th= e relevant new features (mentioned above). Perhaps one draft is enough for = all of the listed ones if their timeline is roughly identical and there is = interest to cover all of them. That draft would evolve as the actual extens= ions in IETF and XSF develop, and would get published as an RFC around the = same time as them (next year?). If things progress well, we could adopt tha= t draft as a STOX WG item around IETF 88. I believe it does fit content-wis= e ("mapping for media signaling") to our charter, we just need to create an= additional milestone for it. I don't know if we should keep the WG active = for just one document, but given the overhead of creating new WGs etc., I t= hink that would make sense. Saul's slides for next Thursday (https://dl.dropboxusercontent.com/u/224361= 9/stox-ietf87.pdf) seem to assume that approach. The chairs can perhaps cre= ate one-slider to be more explicit about the plan and scope.=20 Markus From stpeter@stpeter.im Sun Jul 28 07:48: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 387DE21F9DA1 for ; Sun, 28 Jul 2013 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[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 0D8sLWPdzNf3 for ; Sun, 28 Jul 2013 07:47:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED6121F9DAF for ; Sun, 28 Jul 2013 07:47:56 -0700 (PDT) Received: from che-vpn-cluster-2-459.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5D4314004A; Sun, 28 Jul 2013 08:49:59 -0600 (MDT) Message-ID: <51F52F17.5040607@stpeter.im> Date: Sun, 28 Jul 2013 16:47:51 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <51C1F1AB.1040701@jitsi.org> <51F4F050.2040309@stpeter.im> <51F4F8E4.2070105@goodadvice.pages.de> 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, fippo@goodadvice.pages.de Subject: Re: [Stox] Mapping for media signaling: still about the scope 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: Sun, 28 Jul 2013 14:48:01 -0000 On 7/28/13 4:15 PM, Markus.Isomaki@nokia.com wrote: > Hi Peter, Philipp, > > Philipp Hancke wrote, >> >> Am 28.07.2013 12:20, schrieb Peter Saint-Andre: [...] >>> I like that approach. The Jingle XEPs already define SDP mappings >>> for the base use cases, and that content could be moved to the >>> stox-media I-D. If additional features are defined in SIP, SDP, >>> or Jingle (trickle-ICE, BUNDLE, multistream, etc.) then we can >>> specify those in incremental extensions. >> >> Right. The problem on the XSF side is that this mapping is >> currently spread over (from the top of my head) XEPs 0166, 0167, >> 0176, (0177 doesn't bother mapping), 0293, 0294 and 0320. This is >> something that needs to be more centralized anyway and the >> stox-media draft might be the normative place to do this. >> > > It sounds to me then that the STOX WG should: - Consolidate the > mappings for all stable specs and features into the current -media > document and aim to publish it as an RFC according to the current > charter, i.e. deliver it to the IESG (hopefully) already before IETF > 88. The value of stabilizing and publishing that document would be > that the mappings would be found in one place. - Start, first as > individual (non-WG) drafts, incremental extensions for the relevant > new features (mentioned above). Perhaps one draft is enough for all > of the listed ones if their timeline is roughly identical and there > is interest to cover all of them. That draft would evolve as the > actual extensions in IETF and XSF develop, and would get published as > an RFC around the same time as them (next year?). I think that is a reasonable approach. > If things progress > well, we could adopt that draft as a STOX WG item around IETF 88. I > believe it does fit content-wise ("mapping for media signaling") to > our charter, we just need to create an additional milestone for it. I > don't know if we should keep the WG active for just one document, but > given the overhead of creating new WGs etc., I think that would make > sense. I am not fully sure about keeping the WG around, but I leave such decisions up to the chairs and ADs. ;-) > Saul's slides for next Thursday > (https://dl.dropboxusercontent.com/u/2243619/stox-ietf87.pdf) seem to > assume that approach. The chairs can perhaps create one-slider to be > more explicit about the plan and scope. That sounds helpful! Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Sun Jul 28 08:15: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 68C4D21F99A9 for ; Sun, 28 Jul 2013 08:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[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 BvA3uj2uJVaI for ; Sun, 28 Jul 2013 08:15:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCF421F999C for ; Sun, 28 Jul 2013 08:15:04 -0700 (PDT) Received: from che-vpn-cluster-2-459.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A44B3E8318; Sun, 28 Jul 2013 09:17:08 -0600 (MDT) Message-ID: <51F53575.50009@stpeter.im> Date: Sun, 28 Jul 2013 17:15:01 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Philipp Hancke References: <602FFF00-D276-4659-9B75-C45A89A3C15E@ag-projects.com> <51F42A2C.7010300@goodadvice.pages.de> In-Reply-To: <51F42A2C.7010300@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, =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [Stox] draft slides for groupchat, media 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: Sun, 28 Jul 2013 15:15:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/27/13 10:14 PM, Philipp Hancke wrote: >> I didn't have time to process Philipp's feedback, I'll >> incorporate it ASAP. Also, I'll be AFK until sunday, but if >> further feedback is provided in the meantime I'll have the slides >> modified on monday. > > Those were minor inconsistencies if I recall correctly. The > examples in the draft and some text is based on an old version of > the jingle specs. We can sit down some time next week and sort this > out. That sounds productive. 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/ iQIcBAEBAgAGBQJR9TV1AAoJEOoGpJErxa2pls4P/2S0vDEYRLEIrJxV79nHckMK SQi8byQ7D4F/JtgOOi1e2cCSXssHCxVJuslN3VOYvrcTlXmaOlEGykRIIRQ/0rHJ 5tjPFkEQmCTm3h357vSMBKQS3K4GmEpjnqXcfEtbKPcpy/8qrl3N2bJTN6kUwmyN XnCqreTzRmpcs5e9igyA5wQ+/X7NbP2tDg5UC3NSZ9PD8PAtsf/OeAqu1JE6jLDa WbarWZ5cVk803MIN+jXj6AeLNuOXCIRuIzRiVHUxB9D2LVEIRVXp4SmaecCktFEJ Z+LeJ6aWfLoMToYYQUClTp75Zih3C9JS0KKPpVwi8RBpT7Qg8L02bFoNeGcshk4W Bu+AkJhGQgqURyzkHEAKc4ugL77ZrPS0BkMOB1mDzeV6nW7Q2PzAnifYotCiIxmx nHQFadvle/uoSIb0djh+Dz33xzt6E5UXC5dwip9eQIdKusDbgaKH1oowChbFub6S OjsEteOrsvNIdmvorScNcL433Ln0valOpuwejrR26lrrQ6YXI0Abrx/Oey2MbSaG JuMxAJHl+gx/3Rwkoex5CT5c1NXZYYvv3rCPgrwuZRcH4vi7iB/am1ZueYG6WYOL BZ7gDwthuRTnBbbFn9EBDx7nP4elM5qS8hE4nRJLQiAgMPu8pLclbKhlsspS12Rm t7gXlu0EUAY92n0lJ9cO =1nNk -----END PGP SIGNATURE----- From yana@sip-communicator.org Sun Jul 28 10:11: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 A31C621F9C3D for ; Sun, 28 Jul 2013 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 MwVA8eoyZpho for ; Sun, 28 Jul 2013 10:11:21 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 86DEA21F9B98 for ; Sun, 28 Jul 2013 10:11:20 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id t10so2472967eei.41 for ; Sun, 28 Jul 2013 10:11:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer:x-gm-message-state; bh=McLiYONICkNbid4ZpBGq7lMu+OqcIyZ8IWN6fyciJ+c=; b=hxOP9JIq/oUFn+Pq5nm64e8Y5CJzA5Sk1WimbHPQFgpvqpWH02bPcEFYQUE0Qp2QNz Svr7EAdKXJqGX0wYJQe8+Er6agRiT6sbmvY02Z43bpXxZoGcSyWa7HtA3F8q4Qap+wn2 BCA4whb3bKdvIX7EzYDA5Hb8P38MNfnBe5ndP5XE3Iek/O0VkW64ULcQBjEPkbvcl56x GXt7C2Py40psN3e2amOCMo+6ZADt6aqUWeFgF1S+38L+ncJXBxKr3igSomyziRlcq8kH Jo98YJN/gKmCT1JcPazHpKIJxgLT33aHBKN+LNt+DaOvPWFBRwVm+wx4i79N/KlC5Box /spA== X-Received: by 10.14.224.6 with SMTP id w6mr3170069eep.99.1375031479421; Sun, 28 Jul 2013 10:11:19 -0700 (PDT) Received: from [192.168.54.136] ([46.189.28.96]) by mx.google.com with ESMTPSA id k3sm24815634een.16.2013.07.28.10.11.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 10:11:18 -0700 (PDT) From: Yana Stamcheva Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <99528D40-B675-4DB0-B925-8F6A411378EF@jitsi.org> Date: Sun, 28 Jul 2013 19:11:18 +0200 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQkTu36l3TmDq6Fgg7yTcGPstcv3qSkJvBT90MbzlWcOvg8y7s5IhhYfjBpiRioEvtfUNB8l Subject: [Stox] STOX @ IETF 87 Note takers 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: Sun, 28 Jul 2013 17:11:25 -0000 Hi all, We are looking for note takers and a jabber scribe for the STOX session = on Thursday in Berlin (http://tools.ietf.org/agenda/87/#THURSDAY). If you are attending and would be able to take notes, please contact the = chairs. Thanks, Yana & Markus= From saul@ag-projects.com Sun Jul 28 14:38:21 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 B0A9021F89C3 for ; Sun, 28 Jul 2013 14:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.024 X-Spam-Level: X-Spam-Status: No, score=-0.024 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_43=0.6, 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 xt6gswq8dakY for ; Sun, 28 Jul 2013 14:38:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id CA77E21F9635 for ; Sun, 28 Jul 2013 14:38:14 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 711FFB35DE; Sun, 28 Jul 2013 23:38:13 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 2D9E9B017A; Sun, 28 Jul 2013 23:38:12 +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: Sun, 28 Jul 2013 23:38:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <15FFF4CE-4860-4796-8F7E-F0523FFDE486@ag-projects.com> References: <51C1F1AB.1040701@jitsi.org> <51F4F050.2040309@stpeter.im> <51F4F8E4.2070105@goodadvice.pages.de> To: X-Mailer: Apple Mail (2.1085) Cc: stox@ietf.org, fippo@goodadvice.pages.de Subject: Re: [Stox] Mapping for media signaling: still about the scope 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: Sun, 28 Jul 2013 21:38:21 -0000 On Jul 28, 2013, at 4:15 PM, = wrote: > Hi Peter, Philipp, >=20 > Philipp Hancke wrote, >>=20 >> Am 28.07.2013 12:20, schrieb Peter Saint-Andre: >> [...] >>> I like that approach. The Jingle XEPs already define SDP mappings = for >>> the base use cases, and that content could be moved to the = stox-media >>> I-D. If additional features are defined in SIP, SDP, or Jingle >>> (trickle-ICE, BUNDLE, multistream, etc.) then we can specify those = in >>> incremental extensions. >>=20 >> Right. The problem on the XSF side is that this mapping is currently = spread >> over (from the top of my head) XEPs 0166, 0167, 0176, (0177 doesn't = bother >> mapping), 0293, 0294 and 0320. This is something that needs to be = more >> centralized anyway and the stox-media draft might be the normative = place to >> do this. >>=20 >=20 > It sounds to me then that the STOX WG should: > - Consolidate the mappings for all stable specs and features into the = current -media document and aim to publish it as an RFC according to the = current charter, i.e. deliver it to the IESG (hopefully) already before = IETF 88. The value of stabilizing and publishing that document would be = that the mappings would be found in one place. > - Start, first as individual (non-WG) drafts, incremental extensions = for the relevant new features (mentioned above). Perhaps one draft is = enough for all of the listed ones if their timeline is roughly identical = and there is interest to cover all of them. That draft would evolve as = the actual extensions in IETF and XSF develop, and would get published = as an RFC around the same time as them (next year?). If things progress = well, we could adopt that draft as a STOX WG item around IETF 88. I = believe it does fit content-wise ("mapping for media signaling") to our = charter, we just need to create an additional milestone for it. I don't = know if we should keep the WG active for just one document, but given = the overhead of creating new WGs etc., I think that would make sense. >=20 That sounds good to me! > Saul's slides for next Thursday = (https://dl.dropboxusercontent.com/u/2243619/stox-ietf87.pdf) seem to = assume that approach. The chairs can perhaps create one-slider to be = more explicit about the plan and scope.=20 >=20 Yeah, I somewhat assumed that,but it's definitely up for discussion. = Since I'm not all that familiar with all the process, please do let me = know if you rather have some extra items added to the slides and I'll = gladly do so. Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Mon Jul 29 03:49:47 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 5A95521F9A59 for ; Mon, 29 Jul 2013 03:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.435, 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 ESPG0-u0jw6E for ; Mon, 29 Jul 2013 03:49:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB021F9808 for ; Mon, 29 Jul 2013 03:49:36 -0700 (PDT) Received: from dhcp-10f3.meeting.ietf.org (unknown [130.129.16.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9BF2040049; Mon, 29 Jul 2013 04:51:44 -0600 (MDT) Message-ID: <51F648BE.3040004@stpeter.im> Date: Mon, 29 Jul 2013 12:49:34 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Lundberg References: <51EF4531.6090902@stpeter.im> <51F29BF9.3070506@stpeter.im> In-Reply-To: <51F29BF9.3070506@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] Comments on draft-ietf-stox-presence-00 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, 29 Jul 2013 10:49:47 -0000 On 7/26/13 5:55 PM, Peter Saint-Andre wrote: > On 7/26/13 4:50 PM, Michael Lundberg wrote: > >> One clarifying question: when you say "if the SIP implementation >> supports the namespace", do you mean the XMPP-to-SIP gateway or the >> SIP user agent? >> >>> Good question. It would be benificial if both supported the >>> namespace, but only the gateway is probably required to. If the >>> client supports the namespace, then the gateway would just need to map >>> between the elements described in this document. >> >>> If the client doesn't support the namespace, the gateway would most >>> likely need to do an additional translation into a namespace the >>> client does understand. In this case, the values might not be the >>> same between the two namespaces, and therefore things are 'lost' in >>> translation. This is one of the big issues with presence mapping today >>> as many implementations have thier own implementation specific >>> namespace, which makes it hard to map between different >>> implementations. Both the implementation specific and common >>> namespaces could coexist, where the implementation specific namespace >>> is used for internal communication and a common, standard namespace >>> (e.g., 'jabber:client' ) is used when communicating between different >>> implementations. > > Yes, I think that makes sense. I'm not sure exactly how to translate > that into text (especially the part about proprietary / non-standard > namespaces), but I'll work something up for consideration by the list. Here is some proposed text: OLD 5. Some implementations support custom extensions to encapsulate this information; however, there is no need to standardize a PIDF extension for this purpose, since PIDF is already extensible and thus the element can be included directly, qualified by the 'jabber:client' namespace in the PIDF XML. The examples in this document illustrate this usage, which is RECOMMENDED. The most useful values are likely "away" and "dnd", although note that the latter value merely means "busy" and does not imply that a server or client ought to block incoming traffic while the user is in that state. NEW 5. Some implementations support custom extensions to encapsulate detailed information about availability; however, there is no need to standardize a PIDF extension for this purpose, since PIDF is already extensible and thus the element (qualified by the 'jabber:client' namespace) can be included directly in the PIDF XML. The examples in this document illustrate this usage, which is RECOMMENDED. The most useful values are likely "away" and "dnd", although note that the latter value merely means "busy" and does not imply that a server or client ought to block incoming traffic while the user is in that state. Naturally, a gateway can choose to translate a custom extension into an established value of the element [RFC6121], or translate a element into a custom extension that the gateway knows is supported by the user agent of the intended recipient. Unfortunately, this behavior does not guarantee that information will not be lost; to help prevent information loss, a gateway ought to include both the element and the custom extension if the gateway cannot suitably translate the custom value into a value. Mike, does that text address your concern? Do we need to say more (or less) than that? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 30 05:15: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 9958011E81D2 for ; Tue, 30 Jul 2013 05:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.045 X-Spam-Level: X-Spam-Status: No, score=-102.045 tagged_above=-999 required=5 tests=[AWL=-0.316, 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 qi46DWzLSPuw for ; Tue, 30 Jul 2013 05:15:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 39F3611E81CC for ; Tue, 30 Jul 2013 05:15:06 -0700 (PDT) Received: from che-vpn-cluster-2-219.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D0F604010C; Tue, 30 Jul 2013 06:17:17 -0600 (MDT) Message-ID: <51F7AE48.1090507@stpeter.im> Date: Tue, 30 Jul 2013 14:15:04 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "stox@ietf.org" References: <51F01857.1050803@stpeter.im> In-Reply-To: <51F01857.1050803@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Stox] draft slides for core, presence, im, chat 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, 30 Jul 2013 12:15:11 -0000 After a hallway discussion with Robert Sparks, I have updated these slides. I will post to the list about the issue he raised. On 7/24/13 8:09 PM, Peter Saint-Andre wrote: > Draft slides for discussion of the -core, -presence, -im, and -chat > specfications are here: > > https://stpeter.im/files/ietf87-stox-core-presence.pdf > > As you can see, there are very few open issues. If folks provide > further feedback about these specs in the next few days, I'll update > the slides accordingly. If not, mine will be a very short presentation > and we'll have more time to discuss the -groupchat and -media I-Ds. :-) > > Peter > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From stpeter@stpeter.im Tue Jul 30 05:24: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 11C2B21F89EB for ; Tue, 30 Jul 2013 05:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 I2vhhpMtcl6T for ; Tue, 30 Jul 2013 05:24:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7A90421E80B1 for ; Tue, 30 Jul 2013 05:24:23 -0700 (PDT) Received: from che-vpn-cluster-2-219.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 98A0C4010C; Tue, 30 Jul 2013 06:26:33 -0600 (MDT) Message-ID: <51F7B073.9050101@stpeter.im> Date: Tue, 30 Jul 2013 14:24:19 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 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] 503 / 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, 30 Jul 2013 12:24:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Sparks pointed out to me in person today that the usage of SIP error 503 is broken in stox-core. RFC 3261 says: 21.5.4 503 Service Unavailable The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response. A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable). Thus the applicability of 503 in SIP is quite different from that of in XMPP. In XMPP, a client (or, more often, a server on its behalf) can return to mean "sorry, I can't provide the service you've requested for the user@host you've tried to contact, but that applies only to that user@host". If the XMPP-to-SIP gateway returns for a single account in that way, the SIP-to-XMPP gateway on the other side won't be able to send *anything* to the peer domain. This breaks all server-to-server communication. Thus Robert suggested that we take a very close look at our mapping into SIP 503, and very probably never use it (or only in very rare cases). I haven't had time yet to look at this in detail, but I will do so before the STOX session on Thursday. 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/ iQIcBAEBAgAGBQJR97BzAAoJEOoGpJErxa2poNsQAJSUWcTdBymR3H3UrWe490vY Q5aX7WEiljJ8ZiORPA+DEJdnlxhR0DJ5WGBMrJ6SLW+cDELTtb0q1bs7nTyG6ozH ys7Cy7sbWFL7MBnUDQP4xcSwQXQURe728TIjLl5rZOXsvKz7ItgkogRHCpavPEea tcL153WA0hpNdYemq2j1dDDwnhpygy2HqJLWOntUs060jPXXgTEsr9+dl2s92rWF YfXe6qFYVtRslMk7joIh3gmBFDTXz7YtwTflBqpx0BinsQ3tbKMIY683qeFeZRSR zvyf6X6cZAs26/oOtzUwVH95oDvdFaXfNbS2f25XOHOwv8fcL9hOcOIyDgxO1BOJ AB+9j2T4hGnwWxagtYq/kDUiUuQuCHb/XV6dgOtkRoFxYRkNpCMGqcbtsWMZAMFR tkMG3W+w0uyQCbnx+S6vZVwFV6yIE2JfTPCh3bRJUmSH9WKM4XsGNMhbhC0TNXCF RbpvobMgSRXJ9n8gFIHx4g8GfTYVEkctYQC5yf6tvL4hFJ4ZIbRpYw26x0BMtFjc H83QTfvmRobKnC4Ga8QiOjP4HymUyfqgMOuLj2HilitbeggkPGi9KcIOTwTHT9WR ib5X6AeyDc9rVfiV39OxJMQgxoN9Zz5QNNJ7sjE3jPwYV6dvx3aUmUdtQjF8zqCv mz2huiy0YOm9vnTuLjB0 =yvwy -----END PGP SIGNATURE----- From yana@sip-communicator.org Tue Jul 30 05:59:27 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 C848121E8091 for ; Tue, 30 Jul 2013 05:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 97sPNt2U397R for ; Tue, 30 Jul 2013 05:59:22 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 830CB21E80E3 for ; Tue, 30 Jul 2013 05:59:19 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so2387148pbc.21 for ; Tue, 30 Jul 2013 05:59:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=gmKAwMFhWyaQPQFh/ko2wIgI+YVYR4yxTzBPSHSWo0A=; b=FUb1RZEqqxNQoCCLm0rTorz0CzvlPS0YrVjFPlqhlemwpgHwPVrVSVgECg+frEa90f 4UG3hHPyGOT3QdXN8xV/DByyuq4SLCvDH7dAjlmWoFhK28g7mfFloeIBfF6nQAutCg1g 0QM6qJfF+jdNB6yseyQuo9ip8qZiZe+fi4SsAWz00lEr07259vcn30F9ZwYOWItxvNh5 SC3ZV4pV1piIufDRTLRVuV/JZ7xgt6GkO/nGKTGuyJ14IYNeWu7QnsTtKfRoiV7TNq3b TW6Js9O73nGuicJPDVjlUkIqL2K6Y4MXZ/hTfxCFENxD5HOnbjiHw+I75C8TSKtotIj5 wmzA== X-Received: by 10.68.237.3 with SMTP id uy3mr34846380pbc.155.1375189159508; Tue, 30 Jul 2013 05:59:19 -0700 (PDT) Received: from dhcp-1346.meeting.ietf.org (dhcp-1346.meeting.ietf.org. [130.129.19.70]) by mx.google.com with ESMTPSA id sz3sm54651503pbc.5.2013.07.30.05.59.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 05:59:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Yana Stamcheva In-Reply-To: <51F7AE48.1090507@stpeter.im> Date: Tue, 30 Jul 2013 14:59:15 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7DF21815-06AE-40BF-8AF2-B9A9E8421E17@jitsi.org> References: <51F01857.1050803@stpeter.im> <51F7AE48.1090507@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQndkh5wmDEbKdE1dNbxY8055xfW2WOADhRNvQKbXlYqm9wlN60p5xRXJjdgJ7UPER0GKle1 Cc: "stox@ietf.org" Subject: Re: [Stox] draft slides for core, presence, im, chat 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, 30 Jul 2013 12:59:27 -0000 Hi Peter, Thanks! Your new slides are uploaded. Yana On Jul 30, 2013, at 2:15 PM, Peter Saint-Andre wrote: > After a hallway discussion with Robert Sparks, I have updated these > slides. I will post to the list about the issue he raised. > > On 7/24/13 8:09 PM, Peter Saint-Andre wrote: >> Draft slides for discussion of the -core, -presence, -im, and -chat >> specfications are here: >> >> https://stpeter.im/files/ietf87-stox-core-presence.pdf >> >> As you can see, there are very few open issues. If folks provide >> further feedback about these specs in the next few days, I'll update >> the slides accordingly. If not, mine will be a very short presentation >> and we'll have more time to discuss the -groupchat and -media I-Ds. :-) >> >> Peter >> >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox >> > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From saul@ag-projects.com Tue Jul 30 06:41: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 D46A311E8225 for ; Tue, 30 Jul 2013 06:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ8b3RUgIA23 for ; Tue, 30 Jul 2013 06:41:49 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4711E8219 for ; Tue, 30 Jul 2013 06:41:48 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 49033B35DE; Tue, 30 Jul 2013 15:41:44 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id B0255B017A for ; Tue, 30 Jul 2013 15:41:43 +0200 (CEST) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 30 Jul 2013 15:41:42 +0200 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Stox] Review of -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: Tue, 30 Jul 2013 13:41:55 -0000 Hi, As promised, here is my review of the -core document: - Sec 4.3 defines instant specific mapping, which maps a public GRUU to = a full JID and vice versa, but doesn't contain any text on temporary = GRUUs. They take the following form: = sip:yyd894uue094ur4@1.2.3.4:5060;gr. I don't think we can work with = those, since there is nothing we can map to the resource part of the = full JID, so I think we need some text to clarify this. - Sec 5.1 maps the XMPP unexpected-request error to SIP code 491, which = is very tied to the dialog semantics IMHO. I tried to find a better = matching code but I couldn't though. Maybe a 500 with a reasonable = Retry-After header value? - Sec 5.1 should me map the SIP outbound (RFC5626) error codes? Those = are 430, and 439 which could be translated to bad-request. * Editorial nits: - Sec 3: "This assumption not meant" -> "This assumption is not meant" Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Tue Jul 30 07:02: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 7579F11E81E4 for ; Tue, 30 Jul 2013 07:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDCVUXiPrcqk for ; Tue, 30 Jul 2013 07:01:54 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5CC21F88FB for ; Tue, 30 Jul 2013 07:01:47 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 1D10DB35DF; Tue, 30 Jul 2013 16:01:44 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 6C981B017A for ; Tue, 30 Jul 2013 16:01:44 +0200 (CEST) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> Date: Tue, 30 Jul 2013 16:01:43 +0200 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Stox] Review of -chat 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, 30 Jul 2013 14:02:00 -0000 Hi, Here is my review of the -chat document. - What should a gateway do when it gets a message with XHTML-IM body? I = guess send it with content-type text/html, but is there any translation = required? - Section 4 mentions what should happen if no formal sessions are used, = but doesn't say anything of the opposite. Should we say that those are = out of the scope of this specification? - I think we should define a mapping between XMPP chatstates (XEP-0085) = and the iscomosing indication (RFC 3994) particularly, the "gone" state = in XMPP should trigger a BYE on the SIP side, and vice versa. - Should we add text to map MSRP reports to XMPP receipts (XEP-0184)? = They do map very well semantically. Now, XEP-0184 says that the ack may = not be sent if "The recipient simply does not wish to return a receipt = for the content message.", which pretty much renders it useless. Anyway, = I think we do need some text explaining how MSRP success and failure = ports should be dealt with. - In general: we don't have any example using CPIM, not sure if we = should say anything about it. * Editorial nits - Examples (multiple): the gr parameter is a URI parameter, not a header = parameter, so: "To: ;gr=3Dbalcony" should be = "To: ". This applies to both To and = Contact headers. - Sec 1: "using the SIP INVITE and SEND request" -> "using the SIP = INVITE and MSRP SEND request" Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Tue Jul 30 07:06: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 871A321F9DE9 for ; Tue, 30 Jul 2013 07:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o69jziiMF9lK for ; Tue, 30 Jul 2013 07:06:38 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6F73B11E820D for ; Tue, 30 Jul 2013 07:06:38 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 954BEB35DE; Tue, 30 Jul 2013 16:06:37 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id B3302B017C for ; Tue, 30 Jul 2013 16:06:36 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> Date: Tue, 30 Jul 2013 16:06:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96A5E265-F3BB-4ED6-9D76-19AFC984C93A@ag-projects.com> References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> To: "stox@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Stox] Review of -chat 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, 30 Jul 2013 14:06:43 -0000 One more thing: the -chat document doesn't have the detailed DNS lookup = mechanism description that the IM document does, I guess it should also = contain it, right? On Jul 30, 2013, at 4:01 PM, Sa=FAl Ibarra Corretg=E9 = wrote: > Hi, >=20 > Here is my review of the -chat document. >=20 >=20 > - What should a gateway do when it gets a message with XHTML-IM body? = I guess send it with content-type text/html, but is there any = translation required? >=20 > - Section 4 mentions what should happen if no formal sessions are = used, but doesn't say anything of the opposite. Should we say that those = are out of the scope of this specification? >=20 > - I think we should define a mapping between XMPP chatstates = (XEP-0085) and the iscomosing indication (RFC 3994) particularly, the = "gone" state in XMPP should trigger a BYE on the SIP side, and vice = versa. >=20 > - Should we add text to map MSRP reports to XMPP receipts (XEP-0184)? = They do map very well semantically. Now, XEP-0184 says that the ack may = not be sent if "The recipient simply does not wish to return a receipt = for the content message.", which pretty much renders it useless. Anyway, = I think we do need some text explaining how MSRP success and failure = ports should be dealt with. >=20 > - In general: we don't have any example using CPIM, not sure if we = should say anything about it. >=20 >=20 > * Editorial nits >=20 > - Examples (multiple): the gr parameter is a URI parameter, not a = header parameter, so: "To: ;gr=3Dbalcony" should = be "To: ". This applies to both To = and Contact headers. >=20 > - Sec 1: "using the SIP INVITE and SEND request" -> "using the SIP = INVITE and MSRP SEND request" >=20 >=20 > Cheers, >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Sa=FAl Ibarra Corretg=E9 AG Projects From salvatore.loreto@ericsson.com Tue Jul 30 07:09:51 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 3FFEA21F9966 for ; Tue, 30 Jul 2013 07:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.989 X-Spam-Level: X-Spam-Status: No, score=-103.989 tagged_above=-999 required=5 tests=[AWL=-2.260, 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 NtthgyFx-wP8 for ; Tue, 30 Jul 2013 07:09:46 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 459B921F9011 for ; Tue, 30 Jul 2013 07:09:38 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-df-51f7c91e3bb8 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CA.43.11907.E19C7F15; Tue, 30 Jul 2013 16:09:34 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Tue, 30 Jul 2013 16:09:33 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B89D711043A for ; Tue, 30 Jul 2013 17:09:33 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 46D785570A for ; Tue, 30 Jul 2013 17:09:29 +0300 (EEST) Received: from dhcp-17dd.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EE00155295 for ; Tue, 30 Jul 2013 17:09:28 +0300 (EEST) Message-ID: <51F7C91C.6070508@ericsson.com> Date: Tue, 30 Jul 2013 16:09:32 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> <96A5E265-F3BB-4ED6-9D76-19AFC984C93A@ag-projects.com> In-Reply-To: <96A5E265-F3BB-4ED6-9D76-19AFC984C93A@ag-projects.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvra7cye+BBqdbRSz+72hidWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtddJ1gLZopU/L/3iLmBcaFAFyMnh4SAicSWj7OYIGwxiQv3 1rN1MXJxCAkcZZToWtzJCuGsZ5S4OGcRO4RzkVFi3+zrLBDOIUaJ01P2MMI5fZ/ns4EM4xXQ lrj85AiYzSKgKrF/ywMWEJtNwEzi+cMtzCC2qECyxPsrd5gh6gUlTs58AlYjIiAs0Xz+HSOI LSygLDFjxz12EFtIoFKiceZFMJtTwFni0/NVYL3MArYSF+ZcZ4Gw5SWat85mhnhITeLquU3M EL1aEr1nO5kmMIrMQrJuFpL2WUjaFzAyr2LkKE4tTspNNzLYxAgM6INbflvsYLz81+YQozQH i5I47xa9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGJtC80UOBCsdSTyW3mcm8GVRs3Bs qHKU5b89OquWJbXssdNX9tPoVj1z38A42frrpo53XabNaio6cXed11lNb3u+XsH3mIXpjyIB 8xLnjuJZrs+PRiz+GCCcE3mR/aKnfolbZ46e5fSWiuJO6/rNyf6drh2b9upUP38blypdHpq4 ZueTUDclluKMREMt5qLiRACCeoGeNgIAAA== Subject: Re: [Stox] Review of -chat 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, 30 Jul 2013 14:09:51 -0000 On 7/30/13 4:06 PM, Saúl Ibarra Corretgé wrote: > One more thing: the -chat document doesn't have the detailed DNS lookup mechanism description that the IM document does, I guess it should also contain it, right? I would prefer not to duplicate the same text among the different documents unless there is not some specific DNS lookup detail that is specific for chat. Is this the case? we can maybe think if the right place for the DNS lookup mechanism is IM document or we want to have it in the Core draft /Salvatore > > > On Jul 30, 2013, at 4:01 PM, Saúl Ibarra Corretgé wrote: > >> Hi, >> >> Here is my review of the -chat document. >> >> >> - What should a gateway do when it gets a message with XHTML-IM body? I guess send it with content-type text/html, but is there any translation required? >> >> - Section 4 mentions what should happen if no formal sessions are used, but doesn't say anything of the opposite. Should we say that those are out of the scope of this specification? >> >> - I think we should define a mapping between XMPP chatstates (XEP-0085) and the iscomosing indication (RFC 3994) particularly, the "gone" state in XMPP should trigger a BYE on the SIP side, and vice versa. >> >> - Should we add text to map MSRP reports to XMPP receipts (XEP-0184)? They do map very well semantically. Now, XEP-0184 says that the ack may not be sent if "The recipient simply does not wish to return a receipt for the content message.", which pretty much renders it useless. Anyway, I think we do need some text explaining how MSRP success and failure ports should be dealt with. >> >> - In general: we don't have any example using CPIM, not sure if we should say anything about it. >> >> >> * Editorial nits >> >> - Examples (multiple): the gr parameter is a URI parameter, not a header parameter, so: "To: ;gr=balcony" should be "To: ". This applies to both To and Contact headers. >> >> - Sec 1: "using the SIP INVITE and SEND request" -> "using the SIP INVITE and MSRP SEND request" >> >> >> Cheers, >> >> -- >> Saúl Ibarra Corretgé >> AG Projects >> >> >> >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox > -- > Saúl Ibarra Corretgé > AG Projects > > > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Salvatore Loreto, PhD www.sloreto.com From saul@ag-projects.com Tue Jul 30 07:21: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 EFA5D21F855F for ; Tue, 30 Jul 2013 07:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5GV7fq5z9kv for ; Tue, 30 Jul 2013 07:21:00 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 615DF21F9A21 for ; Tue, 30 Jul 2013 07:19:42 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 1F35CB01BE; Tue, 30 Jul 2013 16:19:40 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 82A37B019B for ; Tue, 30 Jul 2013 16:19:30 +0200 (CEST) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> Date: Tue, 30 Jul 2013 16:19:29 +0200 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Stox] Review on -im 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, 30 Jul 2013 14:21:09 -0000 Hi, Here is my review on the -im document: - Section 3 suggests that the thread element in XMPP should be mapped to = the Call-ID header. I see why this was done, but it looks a bit like = abusing it. I would probably take it out or define it as a CPIM header, = in case CPIM is used. Thoughts? - Section 5 only mentions text/plain and text/html, I think we should = add message/cpim in there. - Similarly to chat, I think we should define a mapping between XMPP = chatstates (XEP-0085) and the iscomosing indication (RFC 3994), but in = this case there would be no mapping for the 'gone' state. * Editorial nits: - In the examples: From, To and Contact header URIs are not enclosed in = angle brackets - In the example in section 4, the RURI should have the gr parameter as = well,as the To header is not used for routing Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Tue Jul 30 08:03: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 72E0811E81FD for ; Tue, 30 Jul 2013 08:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.04 X-Spam-Level: X-Spam-Status: No, score=-102.04 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 zo+BwNZ8zoQt for ; Tue, 30 Jul 2013 08:03:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC6211E81FB for ; Tue, 30 Jul 2013 08:03:32 -0700 (PDT) Received: from ergon.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 33C7E4010C; Tue, 30 Jul 2013 09:05:43 -0600 (MDT) Message-ID: <51F7D5C1.6010200@stpeter.im> Date: Tue, 30 Jul 2013 17:03:29 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Salvatore Loreto References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> <96A5E265-F3BB-4ED6-9D76-19AFC984C93A@ag-projects.com> <51F7C91C.6070508@ericsson.com> In-Reply-To: <51F7C91C.6070508@ericsson.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] Review of -chat 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, 30 Jul 2013 15:03:38 -0000 On 7/30/13 4:09 PM, Salvatore Loreto wrote: > On 7/30/13 4:06 PM, Saúl Ibarra Corretgé wrote: >> One more thing: the -chat document doesn't have the detailed DNS >> lookup mechanism description that the IM document does, I guess it >> should also contain it, right? > I would prefer not to duplicate the same text among the different documents > unless there is not some specific DNS lookup detail that is specific for > chat. Is this the case? > > we can maybe think if the right place for the DNS lookup mechanism is IM > document or we want to have it > in the Core draft As I recall, we already discussed the topic, starting here: http://www.ietf.org/mail-archive/web/stox/current/msg00069.html I think we *might* be able to provide some informational guidance, but I don't know how strong it can be. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 30 08:06: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 0D3A321F999D for ; Tue, 30 Jul 2013 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=-0.290, 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 0u627QDLNY6x for ; Tue, 30 Jul 2013 08:06:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B62AE21F999E for ; Tue, 30 Jul 2013 08:06:20 -0700 (PDT) Received: from ergon.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A8FB14010C; Tue, 30 Jul 2013 09:08:26 -0600 (MDT) Message-ID: <51F7D664.3050305@stpeter.im> Date: Tue, 30 Jul 2013 17:06:12 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Salvatore Loreto References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> <96A5E265-F3BB-4ED6-9D76-19AFC984C93A@ag-projects.com> <51F7C91C.6070508@ericsson.com> <51F7D5C1.6010200@stpeter.im> In-Reply-To: <51F7D5C1.6010200@stpeter.im> 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] Review of -chat 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, 30 Jul 2013 15:06:44 -0000 On 7/30/13 5:03 PM, Peter Saint-Andre wrote: > On 7/30/13 4:09 PM, Salvatore Loreto wrote: >> On 7/30/13 4:06 PM, Saúl Ibarra Corretgé wrote: >>> One more thing: the -chat document doesn't have the detailed DNS >>> lookup mechanism description that the IM document does, I guess it >>> should also contain it, right? >> I would prefer not to duplicate the same text among the different documents >> unless there is not some specific DNS lookup detail that is specific for >> chat. Is this the case? >> >> we can maybe think if the right place for the DNS lookup mechanism is IM >> document or we want to have it >> in the Core draft > > As I recall, we already discussed the topic, starting here: > > http://www.ietf.org/mail-archive/web/stox/current/msg00069.html > > I think we *might* be able to provide some informational guidance, but I > don't know how strong it can be. But, if we do have text, I think it belongs in stox-core. Peter -- Peter Saint-Andre https://stpeter.im/ From saul@ag-projects.com Tue Jul 30 08:33: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 F172E21E80B7 for ; Tue, 30 Jul 2013 08:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFld1gGLpBmV for ; Tue, 30 Jul 2013 08:33:20 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 19DF721F9974 for ; Tue, 30 Jul 2013 08:33:20 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 7A418B35DD; Tue, 30 Jul 2013 17:33:19 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id CC3A6B017C for ; Tue, 30 Jul 2013 17:33:18 +0200 (CEST) From: =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <0CB65FBA-7262-4189-8852-5FC08A34D50D@ag-projects.com> Date: Tue, 30 Jul 2013 17:33:18 +0200 To: "stox@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Stox] Review on -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, 30 Jul 2013 15:33:26 -0000 Hi, Here is my review of the -presence document: - Sec 3.3.2 suggests that if the subscription is maintained but we have = no presence state, a PIDF would be generated with a basic status of = closed, but what would be the tuple ID, if we don't know any resource = for this user anymore? We could also send an empty NOTIFY, which would = achieve the same goal. - Sec 3.3.2 specifies how to handle the case when a gateway translated a = SIP subscription into an XMPP subscription and then the SIP side decided = to end it, but doesn't mention what to do in case the XMPP side decides = to end it. It should send a NOTIFY with Subscription-State: = terminated;reason=3Drejected. - Sec 4.1, "Instant Message URI of the form " - = shouldn't this be "Presence URI of the form=85" ? - Using ID-123kdklejd doesn't seem to work as a valid xs:ID, TID-1234 = does work though, so we could use TID- as the prefix for tuple = identifiers in examples and such. - Table 6 suggests that the Call-ID header should be matched to the = presence stanza id, but the called won't change throughout the whole = dialog, so we should use something else, which changes for each SIP = transaction, what about the Via branch? Table 7 uses CSeq, FWIW. - Table 6 suggests that priority is translated as the PIDF priority for = a tuple, but that's an attribute of the contact element, which we don't = mention, but I guess we should. Also, the priority in PIDF is a float = between 0 and 1, is it the same for XMPP? - Sec 4.3, the translated XMPP stanza contains the full JID of Juliet, = but where did we get the resource from? Shouldn't it go to the bare JID? * Editorial nits: - Many example requests lack a To header - Sec 3.2.3: "gateway SHOULD a presence stanza" -> "gateway SHOULD send = a presence stanza" Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Tue Jul 30 08:54: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 BA6BC21F8546 for ; Tue, 30 Jul 2013 08:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, 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 SZDkb1bDGjYw for ; Tue, 30 Jul 2013 08:54:38 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A0A3F21F9A35 for ; Tue, 30 Jul 2013 08:54:34 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 7A6ECB35DB; Tue, 30 Jul 2013 17:54:27 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 70CCAB017C for ; Tue, 30 Jul 2013 17:54:26 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> Date: Tue, 30 Jul 2013 17:54:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08B37233-F92B-49C9-AC75-6A82B9FDBF21@ag-projects.com> References: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> To: "stox@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [Stox] Review on -im 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, 30 Jul 2013 15:54:44 -0000 One more thing: IMHO we should also mention that "headline" XMPP = messages should be translated like the normal ones in this spec. Not in = -chat though. On Jul 30, 2013, at 4:19 PM, Sa=FAl Ibarra Corretg=E9 = wrote: > Hi, >=20 > Here is my review on the -im document: >=20 > - Section 3 suggests that the thread element in XMPP should be mapped = to the Call-ID header. I see why this was done, but it looks a bit like = abusing it. I would probably take it out or define it as a CPIM header, = in case CPIM is used. Thoughts? >=20 > - Section 5 only mentions text/plain and text/html, I think we should = add message/cpim in there. >=20 > - Similarly to chat, I think we should define a mapping between XMPP = chatstates (XEP-0085) and the iscomosing indication (RFC 3994), but in = this case there would be no mapping for the 'gone' state. >=20 >=20 > * Editorial nits: >=20 > - In the examples: From, To and Contact header URIs are not enclosed = in angle brackets > - In the example in section 4, the RURI should have the gr parameter = as well,as the To header is not used for routing >=20 >=20 > Cheers, >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Tue Jul 30 09:06: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 3C50A21E8091 for ; Tue, 30 Jul 2013 09:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.86 X-Spam-Level: X-Spam-Status: No, score=-101.86 tagged_above=-999 required=5 tests=[AWL=-0.431, 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 Q8PaPPP+w5H6 for ; Tue, 30 Jul 2013 09:06:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1013121E8110 for ; Tue, 30 Jul 2013 09:03:59 -0700 (PDT) Received: from ergon.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 57D50F1DDB; Tue, 30 Jul 2013 10:06:09 -0600 (MDT) Message-ID: <51F7E3EB.8010105@stpeter.im> Date: Tue, 30 Jul 2013 18:03:55 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> <08B37233-F92B-49C9-AC75-6A82B9FDBF21@ag-projects.com> In-Reply-To: <08B37233-F92B-49C9-AC75-6A82B9FDBF21@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] Review on -im 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, 30 Jul 2013 16:06:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/30/13 5:54 PM, Saúl Ibarra Corretgé wrote: > One more thing: IMHO we should also mention that "headline" XMPP > messages should be translated like the normal ones in this spec. > Not in -chat though. Agreed. 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/ iQIcBAEBAgAGBQJR9+PqAAoJEOoGpJErxa2p2nAQAJZ9TgxMjCKziTVuvQkXp4kN YcQO0ghQmUuOb2dPwQgm3xWRRGz3iN+dFRyY11c/j97fwF0J/+NPtkcvr/36sRo2 LV8S+bPqV29LZIm983hKq/pLq6hsUh8X4aaVdJaq+d29/OoZPpX43uc/HkF8WqS8 0sVKbitZL+udgBFSPcSYjhz18+/FGJ+V5NBDv3Ewhc/CNb3KRBpeB0vpgfk0Bqd8 fDCnzf9mFSlOV89bFykd/fhEH6w51cQNtlui7oBTg7/MAOMT9BsL6/CDgUwtKgup rB2Kysk8WbyX+EL+abw62URuCPlSjRr7oWcGUKIZrMab2Fxva4jRcz6YcJEPBeJp b8Ns19cgFOaJjB23CRGO/jkwkM1d9JN4iUYKrEV/rFZND/MhIGmV95PwAf4np5I6 P7syS1AcCJ919V1fVB8xbKvhgzq9gcHauwkuVK0zcu1V4mhmCA20zccTQ0kAh8sA 9gJA1Wsi2qsmPnXmTZNUOMMHmX9koh7bF10aMxr8txW2miE/gwqthGY+p6yUnOFm xyhI/szpfG/y72idu1jSCpFQ2H+pueRLBybzdFKraBr4QJf+vDkqf5wro3lN2O+P xuoOdNwFtLR4n15x4/I0gvLKWvXpc6niIAxqDCa2woC5DfWUEjTifXgMjuYWSiDc nLQf2s+Nl9PSBx+qAdRp =db3+ -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Jul 30 22:30: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 4FF3421F9B18 for ; Tue, 30 Jul 2013 22:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.986 X-Spam-Level: X-Spam-Status: No, score=-101.986 tagged_above=-999 required=5 tests=[AWL=-0.258, 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 iMRspLk5TovD for ; Tue, 30 Jul 2013 22:30:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3344221F9B3F for ; Tue, 30 Jul 2013 22:30:20 -0700 (PDT) Received: from ergon.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CFE03F1DDC; Tue, 30 Jul 2013 23:32:32 -0600 (MDT) Message-ID: <51F89504.9040808@stpeter.im> Date: Wed, 31 Jul 2013 06:39:32 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yana Stamcheva References: <51F01857.1050803@stpeter.im> <51F7AE48.1090507@stpeter.im> <7DF21815-06AE-40BF-8AF2-B9A9E8421E17@jitsi.org> In-Reply-To: <7DF21815-06AE-40BF-8AF2-B9A9E8421E17@jitsi.org> 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] draft slides for core, presence, im, chat 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, 31 Jul 2013 05:30:25 -0000 This is just a warning that I'll be providing updated slides to address some points that Saúl made in his reviews. I'll try to do that as early today as possible. On 7/30/13 2:59 PM, Yana Stamcheva wrote: > Hi Peter, > > Thanks! Your new slides are uploaded. > > Yana > > On Jul 30, 2013, at 2:15 PM, Peter Saint-Andre wrote: > >> After a hallway discussion with Robert Sparks, I have updated these >> slides. I will post to the list about the issue he raised. >> >> On 7/24/13 8:09 PM, Peter Saint-Andre wrote: >>> Draft slides for discussion of the -core, -presence, -im, and -chat >>> specfications are here: >>> >>> https://stpeter.im/files/ietf87-stox-core-presence.pdf >>> >>> As you can see, there are very few open issues. If folks provide >>> further feedback about these specs in the next few days, I'll update >>> the slides accordingly. If not, mine will be a very short presentation >>> and we'll have more time to discuss the -groupchat and -media I-Ds. :-) >>> >>> Peter >>> From saul@ag-projects.com Wed Jul 31 05:28: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 60E9D11E8182 for ; Wed, 31 Jul 2013 05:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_05=-1.11, 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 791z29mgA5BR for ; Wed, 31 Jul 2013 05:28:40 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 02D9C11E8109 for ; Wed, 31 Jul 2013 05:28:33 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 77CBCB35DF; Wed, 31 Jul 2013 14:28:25 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id D9E5FB017A; Wed, 31 Jul 2013 14:28:23 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <602FFF00-D276-4659-9B75-C45A89A3C15E@ag-projects.com> Date: Wed, 31 Jul 2013 14:28:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7FFBECE9-56EA-4D50-8998-DF2A2E315D89@ag-projects.com> References: <602FFF00-D276-4659-9B75-C45A89A3C15E@ag-projects.com> To: stox@ietf.org X-Mailer: Apple Mail (2.1508) Cc: Yana Stamcheva Subject: Re: [Stox] draft slides for groupchat, media 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, 31 Jul 2013 12:28:44 -0000 Hi, I just updated my slides after I reviewed the group chat draft and = incorporated some feedback I got from discussions with Phillip. I don't = expect to change them again unless there is a world-ending-problem that = would need to be addressed :-) On Jul 26, 2013, at 3:43 PM, Sa=FAl Ibarra Corretg=E9 = wrote: > Hi, >=20 > Here are draft slides for the groupchat and media documents: = https://dl.dropboxusercontent.com/u/2243619/stox-ietf87.pdf >=20 > I didn't have time to process Philipp's feedback, I'll incorporate it = ASAP. Also, I'll be AFK until sunday, but if further feedback is = provided in the meantime I'll have the slides modified on monday. >=20 >=20 > Cheers, >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Wed Jul 31 07:24: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 274FC11E818B for ; Wed, 31 Jul 2013 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.904 X-Spam-Level: X-Spam-Status: No, score=-101.904 tagged_above=-999 required=5 tests=[AWL=-0.475, 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 gKCrJMeVsz7w for ; Wed, 31 Jul 2013 07:24:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2FBD11E81A5 for ; Wed, 31 Jul 2013 07:24:39 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9B4A040046; Wed, 31 Jul 2013 08:26:46 -0600 (MDT) Message-ID: <51F91E1D.7020606@stpeter.im> Date: Wed, 31 Jul 2013 16:24:29 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: 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] Review of -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: Wed, 31 Jul 2013 14:24:45 -0000 On 7/30/13 3:41 PM, Saúl Ibarra Corretgé wrote: > Hi, > > As promised, here is my review of the -core document: Many thanks for the review. > - Sec 4.3 defines instant specific mapping, which maps a public GRUU > to a full JID and vice versa, but doesn't contain any text on > temporary GRUUs. They take the following form: > sip:yyd894uue094ur4@1.2.3.4:5060;gr. I don't think we can work with > those, since there is nothing we can map to the resource part of the > full JID, so I think we need some text to clarify this. Agreed on temporary GRUUs. IMHO we'll need to add a note about that (but I haven't yet had time to propose text). > - Sec 5.1 maps the XMPP unexpected-request error to SIP code 491, > which is very tied to the dialog semantics IMHO. I tried to find a > better matching code but I couldn't though. Maybe a 500 with a > reasonable Retry-After header value? It seems to me that we'd want it to be a 4xx series error, but I don't see a good one in RFC 3261. > - Sec 5.1 should me map the SIP outbound (RFC5626) error codes? Those > are 430, and 439 which could be translated to bad-request. Could you explain the scenarios where outbound-related error codes might be used? Feel free to say "just read RFC 5626". :-) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 31 07:37: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 5B0A521E8125 for ; Wed, 31 Jul 2013 07:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.89 X-Spam-Level: X-Spam-Status: No, score=-101.89 tagged_above=-999 required=5 tests=[AWL=-0.461, 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 2Dh1odB6fLJ8 for ; Wed, 31 Jul 2013 07:37:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 08A2921F9A3C for ; Wed, 31 Jul 2013 07:37:24 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E63D440046; Wed, 31 Jul 2013 08:39:38 -0600 (MDT) Message-ID: <51F92121.6010902@stpeter.im> Date: Wed, 31 Jul 2013 16:37:21 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> In-Reply-To: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@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] Review of -chat 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, 31 Jul 2013 14:37:36 -0000 On 7/30/13 4:01 PM, Saúl Ibarra Corretgé wrote: > Hi, > > Here is my review of the -chat document. > > - What should a gateway do when it gets a message with XHTML-IM body? > I guess send it with content-type text/html, but is there any > translation required? I know about the use of XHTML in XMPP, but I don't know much about the use in SIP. Is there a profile of (X)HTML that most SIP entities implement? > - Section 4 mentions what should happen if no formal sessions are > used, but doesn't say anything of the opposite. Should we say that > those are out of the scope of this specification? Precursors to this document talked about formal chat sessions in XMPP (XEP-0155), however no clients support that model so I remove all of that text. The first paragraph of Section 4 reflects the earlier specs. I think we just need to remove a few words from Section 4... OLD When an MSRP client sends messages through a gateway to an XMPP client that does not support formal sessinos, the order of events is as follows. NEW When an MSRP client sends messages through a gateway to an XMPP client, the order of events is as follows. > - I think we should define a mapping between XMPP chatstates > (XEP-0085) and the iscomosing indication (RFC 3994) particularly, the > "gone" state in XMPP should trigger a BYE on the SIP side, and vice > versa. Could you describe a bit why you think that would be useful? (You explained it to me in person, but I think it would be helpful to discuss it on the list so that it's in the records of the WG. And for the record I am pretty sure I agree with you.) > - Should we add text to map MSRP reports to XMPP receipts (XEP-0184)? > They do map very well semantically. Now, XEP-0184 says that the ack > may not be sent if "The recipient simply does not wish to return a > receipt for the content message.", which pretty much renders it > useless. Anyway, I think we do need some text explaining how MSRP > success and failure ports should be dealt with. I wonder if this belongs in the stox-chat spec or in an extension document. (And BTW XMPP message receipts can be used outside of chat sessions, so I think it applies more broadly than the stox-chat spec.) > - In general: we don't have any example using CPIM, not sure if we > should say anything about it. What do you have in mind for CPIM examples? Do you mean examples other than MSRP, or examples with CPIM payloads? Peter -- Peter Saint-Andre https://stpeter.im/ From saul@ag-projects.com Wed Jul 31 07:42: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 5463E11E81A4 for ; Wed, 31 Jul 2013 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 Iiqay73mJZPf for ; Wed, 31 Jul 2013 07:42:31 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 51CBF11E817A for ; Wed, 31 Jul 2013 07:42:31 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 90C70B35E1; Wed, 31 Jul 2013 16:42:30 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id EDC28B01BE; Wed, 31 Jul 2013 16:42:29 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51F91E1D.7020606@stpeter.im> Date: Wed, 31 Jul 2013 16:42:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <835410ED-B7B9-4DD9-8E58-8DF6C7AE4BB2@ag-projects.com> References: <51F91E1D.7020606@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" Subject: Re: [Stox] Review of -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: Wed, 31 Jul 2013 14:42:37 -0000 >=20 >=20 >> - Sec 5.1 maps the XMPP unexpected-request error to SIP code 491, >> which is very tied to the dialog semantics IMHO. I tried to find a >> better matching code but I couldn't though. Maybe a 500 with a >> reasonable Retry-After header value? >=20 > It seems to me that we'd want it to be a 4xx series error, but I don't > see a good one in RFC 3261. Exactly my thought. >=20 >> - Sec 5.1 should me map the SIP outbound (RFC5626) error codes? Those >> are 430, and 439 which could be translated to bad-request. >=20 > Could you explain the scenarios where outbound-related error codes = might > be used? Feel free to say "just read RFC 5626". :-) >=20 A 430 may occur if the gateway sends a SIP INVITE to the target domain = and the edge proxy which handles the INVITE gets a flow error from the = authoritative proxy behind him. Forget about 439, that's for REGISTERs, = sorry. -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Wed Jul 31 07:47: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 C690811E819A for ; Wed, 31 Jul 2013 07:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=-0.448, 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 PvIgp3XUsyC1 for ; Wed, 31 Jul 2013 07:47:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D805F21F9CD9 for ; Wed, 31 Jul 2013 07:47:44 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 15AD740046; Wed, 31 Jul 2013 08:49:58 -0600 (MDT) Message-ID: <51F9238D.106@stpeter.im> Date: Wed, 31 Jul 2013 16:47:41 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> In-Reply-To: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@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] Review on -im 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, 31 Jul 2013 14:47:57 -0000 On 7/30/13 4:19 PM, Saúl Ibarra Corretgé wrote: > Hi, > > Here is my review on the -im document: > > - Section 3 suggests that the thread element in XMPP should be mapped > to the Call-ID header. I see why this was done, but it looks a bit > like abusing it. What are your specific concerns? Would something break? Is it insecure? Does it horribly violate the semantics defined in RFC 3261? I thought it was a pretty good match: The Call-ID header field acts as a unique identifier to group together a series of messages. But maybe I don't understand the "oral tradition" of how Call-ID has actually be used. > I would probably take it out or define it as a CPIM > header, in case CPIM is used. Thoughts? I don't see a header in RFC 3862 that we could map to. Our charter says we're not allowed to define new protocols. Someone could define a new CPIM header, but I don't think that would be widely adopted anytime soon. > - Section 5 only mentions text/plain and text/html, I think we should > add message/cpim in there. No objections here. > - Similarly to chat, I think we should define a mapping between XMPP > chatstates (XEP-0085) and the iscomosing indication (RFC 3994), but > in this case there would be no mapping for the 'gone' state. The stox-im spec is only for single messages, so I don't see how chat states apply. (This document might be the place to talk about message receipts, however.) Peter -- Peter Saint-Andre https://stpeter.im/ From oej@edvina.net Wed Jul 31 07:51: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 DD63221F9E2D for ; Wed, 31 Jul 2013 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMMNW2SP9QPO for ; Wed, 31 Jul 2013 07:51:38 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4415B21F9A29 for ; Wed, 31 Jul 2013 07:51:15 -0700 (PDT) Received: from [IPv6:2001:df8::16:f490:4537:d80:d090] (unknown [IPv6:2001:df8:0:16:f490:4537:d80:d090]) by smtp7.webway.se (Postfix) with ESMTPA id 5945B93C2A2; Wed, 31 Jul 2013 14:51:14 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_8C01BBE1-BB90-4A2F-AB32-0252D06746EF" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <835410ED-B7B9-4DD9-8E58-8DF6C7AE4BB2@ag-projects.com> Date: Wed, 31 Jul 2013 16:51:14 +0200 Message-Id: <2F1DACBC-4707-4FA5-ADE4-FFFD3709C870@edvina.net> References: <51F91E1D.7020606@stpeter.im> <835410ED-B7B9-4DD9-8E58-8DF6C7AE4BB2@ag-projects.com> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" , Peter Saint-Andre Subject: Re: [Stox] Review of -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: Wed, 31 Jul 2013 14:51:45 -0000 --Apple-Mail=_8C01BBE1-BB90-4A2F-AB32-0252D06746EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 31 jul 2013 kl. 16:42 skrev Sa=FAl Ibarra Corretg=E9 = : >>=20 >>=20 >>> - Sec 5.1 maps the XMPP unexpected-request error to SIP code 491, >>> which is very tied to the dialog semantics IMHO. I tried to find a >>> better matching code but I couldn't though. Maybe a 500 with a >>> reasonable Retry-After header value? >>=20 >> It seems to me that we'd want it to be a 4xx series error, but I = don't >> see a good one in RFC 3261. >=20 > Exactly my thought. "unexpected-request error" seems more like a server error - or does it = point to the actual request? /O >=20 >>=20 >>> - Sec 5.1 should me map the SIP outbound (RFC5626) error codes? = Those >>> are 430, and 439 which could be translated to bad-request. >>=20 >> Could you explain the scenarios where outbound-related error codes = might >> be used? Feel free to say "just read RFC 5626". :-) >>=20 >=20 > A 430 may occur if the gateway sends a SIP INVITE to the target domain = and the edge proxy which handles the INVITE gets a flow error from the = authoritative proxy behind him. Forget about 439, that's for REGISTERs, = sorry. >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_8C01BBE1-BB90-4A2F-AB32-0252D06746EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 saul@ag-projects.com>:


- Sec 5.1 maps the XMPP unexpected-request error to SIP = code 491,
which is very tied to the dialog semantics IMHO. I tried to = find a
better matching code but I couldn't though. Maybe a 500 with = a
reasonable Retry-After header value?

It seems = to me that we'd want it to be a 4xx series error, but I don't
see a = good one in RFC 3261.

Exactly my = thought.
"unexpected-request error" seems more like a = server error - or does it point to the actual = request?

/O


- Sec 5.1 should me map the SIP outbound (RFC5626) error = codes? Those
are 430, and 439 which could be translated to = bad-request.

Could you explain the scenarios where = outbound-related error codes might
be used? Feel free to say "just = read RFC 5626". :-)


A 430 may occur if the = gateway sends a SIP INVITE to the target domain and the edge proxy which = handles the INVITE gets a flow error from the authoritative proxy behind = him. Forget about 439, that's for REGISTERs, sorry.

--
Sa=FAl = Ibarra Corretg=E9
AG = Projects



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

---
* Olle E = Johansson - oej@edvina.net
* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_8C01BBE1-BB90-4A2F-AB32-0252D06746EF-- From stpeter@stpeter.im Wed Jul 31 07:59:12 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 5438221F9C7A for ; Wed, 31 Jul 2013 07:59:05 -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.285, 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 1iPCMw6WEPqq for ; Wed, 31 Jul 2013 07:58:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D673821F9A8C for ; Wed, 31 Jul 2013 07:53:19 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B77B740046; Wed, 31 Jul 2013 08:55:30 -0600 (MDT) Message-ID: <51F924D9.1040707@stpeter.im> Date: Wed, 31 Jul 2013 16:53:13 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Olle E. Johansson" References: <51F91E1D.7020606@stpeter.im> <835410ED-B7B9-4DD9-8E58-8DF6C7AE4BB2@ag-projects.com> <2F1DACBC-4707-4FA5-ADE4-FFFD3709C870@edvina.net> In-Reply-To: <2F1DACBC-4707-4FA5-ADE4-FFFD3709C870@edvina.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "stox@ietf.org" , =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [Stox] Review of -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: Wed, 31 Jul 2013 14:59:12 -0000 On 7/31/13 4:51 PM, Olle E. Johansson wrote: > > 31 jul 2013 kl. 16:42 skrev Saúl Ibarra Corretgé >: > >>> >>> >>>> - Sec 5.1 maps the XMPP unexpected-request error to SIP code 491, >>>> which is very tied to the dialog semantics IMHO. I tried to find a >>>> better matching code but I couldn't though. Maybe a 500 with a >>>> reasonable Retry-After header value? >>> >>> It seems to me that we'd want it to be a 4xx series error, but I don't >>> see a good one in RFC 3261. >> >> Exactly my thought. > "unexpected-request error" seems more like a server error - or does it > point to the actual request? Not necessarily a server thing. E.g., you send me but I never sent you (where "you" and "me" are clients). Peter -- Peter Saint-Andre https://stpeter.im/ From saul@ag-projects.com Wed Jul 31 07:59:24 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 2B22621F9D4C for ; Wed, 31 Jul 2013 07:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 l9u+M5m6XMEj for ; Wed, 31 Jul 2013 07:59:12 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 69EE621E80E0 for ; Wed, 31 Jul 2013 07:53:03 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 1A3C2B35E0; Wed, 31 Jul 2013 16:52:38 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 23200B017C; Wed, 31 Jul 2013 16:52:38 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51F92121.6010902@stpeter.im> Date: Wed, 31 Jul 2013 16:52:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> <51F92121.6010902@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" Subject: Re: [Stox] Review of -chat 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, 31 Jul 2013 14:59:24 -0000 >>=20 >> - What should a gateway do when it gets a message with XHTML-IM body? >> I guess send it with content-type text/html, but is there any >> translation required? >=20 > I know about the use of XHTML in XMPP, but I don't know much about the > use in SIP. Is there a profile of (X)HTML that most SIP entities = implement? >=20 SIP entities will implement text/html, can we use that? >> - Section 4 mentions what should happen if no formal sessions are >> used, but doesn't say anything of the opposite. Should we say that >> those are out of the scope of this specification? >=20 > Precursors to this document talked about formal chat sessions in XMPP > (XEP-0155), however no clients support that model so I remove all of > that text. The first paragraph of Section 4 reflects the earlier = specs. > I think we just need to remove a few words from Section 4... >=20 > OLD > When an MSRP client sends messages through a gateway to an XMPP > client that does not support formal sessinos, the order of events is > as follows. >=20 > NEW > When an MSRP client sends messages through a gateway to an XMPP > client, the order of events is as follows. >=20 Sounds good to me. >> - I think we should define a mapping between XMPP chatstates >> (XEP-0085) and the iscomosing indication (RFC 3994) particularly, the >> "gone" state in XMPP should trigger a BYE on the SIP side, and vice >> versa. >=20 > Could you describe a bit why you think that would be useful? (You > explained it to me in person, but I think it would be helpful to = discuss > it on the list so that it's in the records of the WG. And for the = record > I am pretty sure I agree with you.) >=20 For one, both SIP and XMPP clients usually implement typing indications = so translating the semantics between the two is useful to get that = information through. Now, as for the 'gone' state case, it's used by = XMPP clients when the conversation is closed, so the other party can = know that the window was closed on the other side and conversation has = ended. Ending a conversation in SIP would mean sending a BYE, and this = is particularly useful, because otherwise the SIP / MSRP session would = stay up forever since there is no ending condition. >> - Should we add text to map MSRP reports to XMPP receipts (XEP-0184)? >> They do map very well semantically. Now, XEP-0184 says that the ack >> may not be sent if "The recipient simply does not wish to return a >> receipt for the content message.", which pretty much renders it >> useless. Anyway, I think we do need some text explaining how MSRP >> success and failure ports should be dealt with. >=20 > I wonder if this belongs in the stox-chat spec or in an extension = document. >=20 > (And BTW XMPP message receipts can be used outside of chat sessions, = so > I think it applies more broadly than the stox-chat spec.) >=20 I didn't know they could be used for other things, but I do think that = their use in the context of a chat session should be translated since = the meaning they have is basically the same as the MSRP REPORT chunk. >> - In general: we don't have any example using CPIM, not sure if we >> should say anything about it. >=20 > What do you have in mind for CPIM examples? Do you mean examples other > than MSRP, or examples with CPIM payloads? >=20 Examples with CPIM payloads. But I see we have them in the group chat = document, so you can skip this point. -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Wed Jul 31 08:07: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 123F821F9E8B for ; Wed, 31 Jul 2013 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 dfplQQIyTNRG for ; Wed, 31 Jul 2013 08:07:19 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id F1AA621F9994 for ; Wed, 31 Jul 2013 08:07:18 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 45A3FB35E0; Wed, 31 Jul 2013 17:07:18 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 1E47EB017A; Wed, 31 Jul 2013 17:07:16 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51F9238D.106@stpeter.im> Date: Wed, 31 Jul 2013 17:07:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DFDCC4B-9568-4BA9-A3F5-C466E8549DCE@ag-projects.com> References: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> <51F9238D.106@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" Subject: Re: [Stox] Review on -im 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, 31 Jul 2013 15:07:25 -0000 On Jul 31, 2013, at 4:47 PM, Peter Saint-Andre = wrote: > On 7/30/13 4:19 PM, Sa=FAl Ibarra Corretg=E9 wrote: >> Hi, >>=20 >> Here is my review on the -im document: >>=20 >> - Section 3 suggests that the thread element in XMPP should be mapped >> to the Call-ID header. I see why this was done, but it looks a bit >> like abusing it.=20 >=20 > What are your specific concerns? Would something break? Is it = insecure? > Does it horribly violate the semantics defined in RFC 3261? I thought = it > was a pretty good match: >=20 > The Call-ID header field acts as a unique identifier to group > together a series of messages. >=20 > But maybe I don't understand the "oral tradition" of how Call-ID has > actually be used. >=20 It doesn't horribly violate it, but it's use has been to correlate = messages within a dialog, together with the tags. Since MESSAGE requests = could come retransmitted when using UDP, duplicated Call-ID detection is = a way to avoid it. >> I would probably take it out or define it as a CPIM >> header, in case CPIM is used. Thoughts? >=20 > I don't see a header in RFC 3862 that we could map to. Our charter = says > we're not allowed to define new protocols. Someone could define a new > CPIM header, but I don't think that would be widely adopted anytime = soon. >=20 I see. In that case I'd go for not really mapping it, but I won't fight = to death if you leave it in ;-) However, since this document is for = single messages ('normal' or 'headline' in XMPP), not sure if the thread = is all that useful.=20 >> - Section 5 only mentions text/plain and text/html, I think we should >> add message/cpim in there. >=20 > No objections here. >=20 >> - Similarly to chat, I think we should define a mapping between XMPP >> chatstates (XEP-0085) and the iscomosing indication (RFC 3994), but >> in this case there would be no mapping for the 'gone' state. >=20 > The stox-im spec is only for single messages, so I don't see how chat > states apply. >=20 Hum, I think you are right, that would apply if we created a -chat = equivalent document but mapping chat sessions to SIP MESSAGE it would be = useful, but not here, forget it. > (This document might be the place to talk about message receipts, = however.) >=20 Why? These are just one-off messages, aren't they? -- Sa=FAl Ibarra Corretg=E9 AG Projects From oej@edvina.net Wed Jul 31 08:09: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 7668021F9E8B for ; Wed, 31 Jul 2013 08:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2p2uGWN+jxl for ; Wed, 31 Jul 2013 08:09:08 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B1B8121F9E6C for ; Wed, 31 Jul 2013 08:09:07 -0700 (PDT) Received: from [IPv6:2001:df8::16:f490:4537:d80:d090] (unknown [IPv6:2001:df8:0:16:f490:4537:d80:d090]) by smtp7.webway.se (Postfix) with ESMTPA id D7F3B93C1AF; Wed, 31 Jul 2013 15:09:06 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 31 Jul 2013 17:09:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E68FDA2-999A-4FF8-AB28-F182F85282C7@edvina.net> References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> <51F92121.6010902@stpeter.im> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" , Peter Saint-Andre Subject: Re: [Stox] Review of -chat 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, 31 Jul 2013 15:09:08 -0000 31 jul 2013 kl. 16:52 skrev Sa=FAl Ibarra Corretg=E9 = : >>>=20 >>> - What should a gateway do when it gets a message with XHTML-IM = body? >>> I guess send it with content-type text/html, but is there any >>> translation required? >>=20 >> I know about the use of XHTML in XMPP, but I don't know much about = the >> use in SIP. Is there a profile of (X)HTML that most SIP entities = implement? >>=20 >=20 > SIP entities will implement text/html, can we use that? Or recommend multipart/alternative if it's a downgrade? Which document says that SIP Uas will support text/html? >=20 >>> - Section 4 mentions what should happen if no formal sessions are >>> used, but doesn't say anything of the opposite. Should we say that >>> those are out of the scope of this specification? >>=20 >> Precursors to this document talked about formal chat sessions in XMPP >> (XEP-0155), however no clients support that model so I remove all of >> that text. The first paragraph of Section 4 reflects the earlier = specs. >> I think we just need to remove a few words from Section 4... >>=20 >> OLD >> When an MSRP client sends messages through a gateway to an XMPP >> client that does not support formal sessinos, the order of events is >> as follows. >>=20 >> NEW >> When an MSRP client sends messages through a gateway to an XMPP >> client, the order of events is as follows. >>=20 >=20 > Sounds good to me. >=20 >>> - I think we should define a mapping between XMPP chatstates >>> (XEP-0085) and the iscomosing indication (RFC 3994) particularly, = the >>> "gone" state in XMPP should trigger a BYE on the SIP side, and vice >>> versa. >>=20 >> Could you describe a bit why you think that would be useful? (You >> explained it to me in person, but I think it would be helpful to = discuss >> it on the list so that it's in the records of the WG. And for the = record >> I am pretty sure I agree with you.) >>=20 >=20 > For one, both SIP and XMPP clients usually implement typing = indications so translating the semantics between the two is useful to = get that information through. Now, as for the 'gone' state case, it's = used by XMPP clients when the conversation is closed, so the other party = can know that the window was closed on the other side and conversation = has ended. Ending a conversation in SIP would mean sending a BYE, and = this is particularly useful, because otherwise the SIP / MSRP session = would stay up forever since there is no ending condition. Is the closing window notification more than just closing window? Is the = chat dead, really? /O= From stpeter@stpeter.im Wed Jul 31 08:13:30 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 DE1CD21F9B53 for ; Wed, 31 Jul 2013 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.861 X-Spam-Level: X-Spam-Status: No, score=-101.861 tagged_above=-999 required=5 tests=[AWL=-0.432, 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 b2O+zutGW-4l for ; Wed, 31 Jul 2013 08:13:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DBBD121F9B7F for ; Wed, 31 Jul 2013 08:13:25 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1A99A40046; Wed, 31 Jul 2013 09:15:39 -0600 (MDT) Message-ID: <51F92992.4070802@stpeter.im> Date: Wed, 31 Jul 2013 17:13:22 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> <51F9238D.106@stpeter.im> <4DFDCC4B-9568-4BA9-A3F5-C466E8549DCE@ag-projects.com> In-Reply-To: <4DFDCC4B-9568-4BA9-A3F5-C466E8549DCE@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] Review on -im 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, 31 Jul 2013 15:13:31 -0000 On 7/31/13 5:07 PM, Saúl Ibarra Corretgé wrote: > > On Jul 31, 2013, at 4:47 PM, Peter Saint-Andre > wrote: > >> On 7/30/13 4:19 PM, Saúl Ibarra Corretgé wrote: >>> Hi, >>> >>> Here is my review on the -im document: >>> >>> - Section 3 suggests that the thread element in XMPP should be >>> mapped to the Call-ID header. I see why this was done, but it >>> looks a bit like abusing it. >> >> What are your specific concerns? Would something break? Is it >> insecure? Does it horribly violate the semantics defined in RFC >> 3261? I thought it was a pretty good match: >> >> The Call-ID header field acts as a unique identifier to group >> together a series of messages. >> >> But maybe I don't understand the "oral tradition" of how Call-ID >> has actually be used. >> > > It doesn't horribly violate it, but it's use has been to correlate > messages within a dialog, together with the tags. Since MESSAGE > requests could come retransmitted when using UDP, duplicated Call-ID > detection is a way to avoid it. Ah, I see. >>> I would probably take it out or define it as a CPIM header, in >>> case CPIM is used. Thoughts? >> >> I don't see a header in RFC 3862 that we could map to. Our charter >> says we're not allowed to define new protocols. Someone could >> define a new CPIM header, but I don't think that would be widely >> adopted anytime soon. >> > > I see. In that case I'd go for not really mapping it, but I won't > fight to death if you leave it in ;-) However, since this document is > for single messages ('normal' or 'headline' in XMPP), not sure if the > thread is all that useful. I see your point. >>> - Section 5 only mentions text/plain and text/html, I think we >>> should add message/cpim in there. >> >> No objections here. >> >>> - Similarly to chat, I think we should define a mapping between >>> XMPP chatstates (XEP-0085) and the iscomosing indication (RFC >>> 3994), but in this case there would be no mapping for the 'gone' >>> state. >> >> The stox-im spec is only for single messages, so I don't see how >> chat states apply. >> > > Hum, I think you are right, that would apply if we created a -chat > equivalent document but mapping chat sessions to SIP MESSAGE it would > be useful, but not here, forget it. Agreed. >> (This document might be the place to talk about message receipts, >> however.) >> > > Why? These are just one-off messages, aren't they? Well, the sender might really really want to know if the message was delivered to the recipient. :-) My feeling about message receipts is that we leave them out for now and maybe define a mapping for them in another specification, but I am open to persuasion on the topic. Peter -- Peter Saint-Andre https://stpeter.im/ From saul@ag-projects.com Wed Jul 31 08:16:58 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38F821F9C78 for ; Wed, 31 Jul 2013 08:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 B8CvdckZWi17 for ; Wed, 31 Jul 2013 08:16:52 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2856B21F9C9B for ; Wed, 31 Jul 2013 08:16:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id C7C17B019B; Wed, 31 Jul 2013 17:16:50 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 0E06DB017A; Wed, 31 Jul 2013 17:16:49 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4E68FDA2-999A-4FF8-AB28-F182F85282C7@edvina.net> Date: Wed, 31 Jul 2013 17:16:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> <51F92121.6010902@stpeter.im> <4E68FDA2-999A-4FF8-AB28-F182F85282C7@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" , Peter Saint-Andre Subject: Re: [Stox] Review of -chat 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, 31 Jul 2013 15:16:58 -0000 >>=20 >> SIP entities will implement text/html, can we use that? > Or recommend multipart/alternative if it's a downgrade? I have never seen multipart used in MSRP and I'd rather not open that = door ;-) > Which document says that SIP Uas will support text/html? >=20 Well, nobody says UAs will support it, it's negotiated with = a=3Daccept-types in SDP, but an MSRP client is very likely to implement = it, directly or wrapped in CPIM. >> For one, both SIP and XMPP clients usually implement typing = indications so translating the semantics between the two is useful to = get that information through. Now, as for the 'gone' state case, it's = used by XMPP clients when the conversation is closed, so the other party = can know that the window was closed on the other side and conversation = has ended. Ending a conversation in SIP would mean sending a BYE, and = this is particularly useful, because otherwise the SIP / MSRP session = would stay up forever since there is no ending condition. > Is the closing window notification more than just closing window? Is = the chat dead, really? >=20 My understanding is that chat "sessions" in XMPP is a very loose thing, = so you could actually resume it later, but as a concept, if you close = the window and you signal that you are "gone" I wouldn't expect further = conversation from him. XMPP clients usually say "Olle has left the = conversation". -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Wed Jul 31 08:23: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 9FF9021F9E27 for ; Wed, 31 Jul 2013 08:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 iqIeBPkEes08 for ; Wed, 31 Jul 2013 08:23:20 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 282E621F9E3A for ; Wed, 31 Jul 2013 08:23:19 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id CD4D1B35DF; Wed, 31 Jul 2013 17:23:17 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 30D59B017A; Wed, 31 Jul 2013 17:23:17 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51F92992.4070802@stpeter.im> Date: Wed, 31 Jul 2013 17:23:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00DCCF5E-1D4B-4BFE-8986-A1B3B5682FF0@ag-projects.com> References: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> <51F9238D.106@stpeter.im> <4DFDCC4B-9568-4BA9-A3F5-C466E8549DCE@ag-projects.com> <51F92992.4070802@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" Subject: Re: [Stox] Review on -im 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, 31 Jul 2013 15:23:26 -0000 >>=20 >=20 > Well, the sender might really really want to know if the message was > delivered to the recipient. :-) >=20 Unfortunately there is no way to do that with a SIP MESSAGE. Unless we = invent a special payload for acknowledging reception of a given SIP = MESSAGE, but I think that is really out of the scope of what we are = doing in the IM document. > My feeling about message receipts is that we leave them out for now = and > maybe define a mapping for them in another specification, but I am = open > to persuasion on the topic. >=20 As I said above we have no way to use them in the -im document, but = there is a clear equivalence between the receipt and the MSRP REPORT = chunk which we use in -chat. If the SIP endpoint requests success and = failure reports, we'd need to fool it by always sending a report, = regardless of the acknowledgement of the message (in case receipts are = supported). I can live with that if we add some text clarifying she a = REPORT should be sent. -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Wed Jul 31 08:28: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 4774A11E8107 for ; Wed, 31 Jul 2013 08:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 R6HUlBjz-eZ1 for ; Wed, 31 Jul 2013 08:28:26 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 47A5321F9FF1 for ; Wed, 31 Jul 2013 08:28:25 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E5002B35DF; Wed, 31 Jul 2013 17:28:19 +0200 (CEST) Received: from dhcp-152d.meeting.ietf.org (dhcp-152d.meeting.ietf.org [130.129.21.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 4FB06B017A; Wed, 31 Jul 2013 17:28:19 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 31 Jul 2013 17:28:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5499487A-9CAC-40E6-89DA-0593300D1557@ag-projects.com> References: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> <51F9238D.106@stpeter.im> <4DFDCC4B-9568-4BA9-A3F5-C466E8549DCE@ag-projects.com> To: Olle E. Johansson X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" Subject: Re: [Stox] Review on -im 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, 31 Jul 2013 15:28:32 -0000 >>=20 >> It doesn't horribly violate it, but it's use has been to correlate = messages within a dialog, together with the tags. Since MESSAGE requests = could come retransmitted when using UDP, duplicated Call-ID detection is = a way to avoid it. > Which you should not do. You should use all of the SIP transaction = identifiers - cseq included. >=20 I know. Anyway, as I said, given that this is -im, not -chat, I don't = think we should translate it. >>=20 >> Why? These are just one-off messages, aren't they? > Page mode messages is proper terminology I believe ;-) >=20 Yeah, that! -- Sa=FAl Ibarra Corretg=E9 AG Projects From Markus.Isomaki@nokia.com Wed Jul 31 09:24: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 036A521E80BF for ; Wed, 31 Jul 2013 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[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 bCKLC7Ba0Uru for ; Wed, 31 Jul 2013 09:24:51 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49A21F9FDA for ; Wed, 31 Jul 2013 09:24:51 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6VGOe5I007024; Wed, 31 Jul 2013 19:24:40 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Jul 2013 19:24:39 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.18]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.03.0136.001; Wed, 31 Jul 2013 16:24:39 +0000 From: To: , Thread-Topic: [Stox] Review on -im Thread-Index: AQHOjTATlMVhbYVm3US/CkV1f6t9NJl+33CAgAAFeoCAAAGzAIAAAsiAgAAQi0A= Date: Wed, 31 Jul 2013 16:24:38 +0000 Message-ID: References: <7AE79F98-B222-4BBC-BC02-1606AF8F34A9@ag-projects.com> <51F9238D.106@stpeter.im> <4DFDCC4B-9568-4BA9-A3F5-C466E8549DCE@ag-projects.com> <51F92992.4070802@stpeter.im> <00DCCF5E-1D4B-4BFE-8986-A1B3B5682FF0@ag-projects.com> In-Reply-To: <00DCCF5E-1D4B-4BFE-8986-A1B3B5682FF0@ag-projects.com> 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+/nZJb9Kg7IkJvTIyt3dTSlgQ+2CPEULTladf6/u6D60UiBxnyA8OYbvYshdPwcVPUye7KI9i7VaFfoHbkxIqnGHoKXiMjeYDgA8OxR/RP3E2dQgdsrWtHfCUTDYTsA51ds9cr76yiO2l4BUhbWWaPsLhubQO15i9wkTjOgCsen4/8IpLYNoBniSqvZFU2KWHDQ78SmLmQbq2ljYXWR5anapRmUqHvBNE= x-originating-ip: [195.71.191.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jul 2013 16:24:39.0939 (UTC) FILETIME=[74B88530:01CE8E0A] X-Nokia-AV: Clean Cc: stox@ietf.org Subject: Re: [Stox] Review on -im 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, 31 Jul 2013 16:24:57 -0000 Hi Saul, Peter, Sa=FAl Ibarra Corretg=E9 wrote: > > > > Well, the sender might really really want to know if the message was > > delivered to the recipient. :-) > > >=20 > Unfortunately there is no way to do that with a SIP MESSAGE. Unless we > invent a special payload for acknowledging reception of a given SIP > MESSAGE, but I think that is really out of the scope of what we are doing= in > the IM document. >=20 Please take a look at RFC 5438 (http://datatracker.ietf.org/doc/rfc5438/) a= nd see if it applies to what would be required. Markus From michaellundberg.ietf@gmail.com Wed Jul 31 18:18:13 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 2BA8111E80F7 for ; Wed, 31 Jul 2013 18:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42ek4uS7yeJz for ; Wed, 31 Jul 2013 18:18:12 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4808511E80DC for ; Wed, 31 Jul 2013 18:18:04 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hr7so1278582wib.0 for ; Wed, 31 Jul 2013 18:17:59 -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=MJtsqXiSyILE8pWevWJ8u9cZT4IDk98f+0Agdk60Vhw=; b=snNFz0CYZSI1AHp02XANEdOZHnhy7wsytTDJ7lhf3T74NgJ7TLmGp4QZtChwX/5hpp K8fKhjkxen4fjZi6oLw0BkISinhMBuxCaaCtPFpN2NwAqT+CJRi2/RMv+z2eCkVD8Qws S2Lmn/AMInW4OeSeGXZRdUfT2FlbsVC5s2S5tR9EPE8rYurQIMCwFjGwNOjpZvO6LcUi Bwuf3KZbygr4fMNGM4EvtPKrG4lbWaNixb7FG9V+BHkxP5zvrsyBIF61FBxiDy3hOyKU rnetX2GTBxMH4J7vSzTDD9M9+3UR7qvJdE7vaAITSuLOAUGWVAVYGSohl5SNdTgP82g0 zEDA== MIME-Version: 1.0 X-Received: by 10.194.173.225 with SMTP id bn1mr52058841wjc.6.1375319877860; Wed, 31 Jul 2013 18:17:57 -0700 (PDT) Received: by 10.216.202.10 with HTTP; Wed, 31 Jul 2013 18:17:57 -0700 (PDT) In-Reply-To: <51F648BE.3040004@stpeter.im> References: <51EF4531.6090902@stpeter.im> <51F29BF9.3070506@stpeter.im> <51F648BE.3040004@stpeter.im> Date: Wed, 31 Jul 2013 21:17:57 -0400 Message-ID: From: Michael Lundberg To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: stox@ietf.org Subject: Re: [Stox] Comments on draft-ietf-stox-presence-00 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, 01 Aug 2013 01:18:13 -0000 Peter, The suggest text below makes sense to me. In my opinion, this helps more clearly defining the presence mapping from XMPP to SIP for values such as 'away'. I think there needs to be similar text for the second table (currently labeled Table 6), which states that the gateway SHOULD map the element in the PIDF XML to the element in the XMPP presence stanza. This would only be for SIP clients that support that particular namespace, but it at least provides a recommended mapping in the opposite direction for clients that do support that namespace. ~Michael On Mon, Jul 29, 2013 at 6:49 AM, Peter Saint-Andre wrote: > On 7/26/13 5:55 PM, Peter Saint-Andre wrote: >> On 7/26/13 4:50 PM, Michael Lundberg wrote: >> >>> One clarifying question: when you say "if the SIP implementation >>> supports the namespace", do you mean the XMPP-to-SIP gateway or the >>> SIP user agent? >>> >>>> Good question. It would be benificial if both supported the >>>> namespace, but only the gateway is probably required to. If the >>>> client supports the namespace, then the gateway would just need to map >>>> between the elements described in this document. >>> >>>> If the client doesn't support the namespace, the gateway would most >>>> likely need to do an additional translation into a namespace the >>>> client does understand. In this case, the values might not be the >>>> same between the two namespaces, and therefore things are 'lost' in >>>> translation. This is one of the big issues with presence mapping today >>>> as many implementations have thier own implementation specific >>>> namespace, which makes it hard to map between different >>>> implementations. Both the implementation specific and common >>>> namespaces could coexist, where the implementation specific namespace >>>> is used for internal communication and a common, standard namespace >>>> (e.g., 'jabber:client' ) is used when communicating between different >>>> implementations. >> >> Yes, I think that makes sense. I'm not sure exactly how to translate >> that into text (especially the part about proprietary / non-standard >> namespaces), but I'll work something up for consideration by the list. > > Here is some proposed text: > > OLD > 5. Some implementations support custom extensions to encapsulate > this information; however, there is no need to standardize a PIDF > extension for this purpose, since PIDF is already extensible and > thus the element can be included directly, qualified by > the 'jabber:client' namespace in the PIDF XML. The examples in > this document illustrate this usage, which is RECOMMENDED. The > most useful values are likely "away" and "dnd", although note > that the latter value merely means "busy" and does not imply that > a server or client ought to block incoming traffic while the user > is in that state. > > NEW > 5. Some implementations support custom extensions to encapsulate > detailed information about availability; however, there is no > need to standardize a PIDF extension for this purpose, since > PIDF is already extensible and thus the element > (qualified by the 'jabber:client' namespace) can be included > directly in the PIDF XML. The examples in this document > illustrate this usage, which is RECOMMENDED. The most useful > values are likely "away" and "dnd", although note that the > latter value merely means "busy" and does not imply that a > server or client ought to block incoming traffic while the user > is in that state. Naturally, a gateway can choose to translate > a custom extension into an established value of the > element [RFC6121], or translate a element into a custom > extension that the gateway knows is supported by the user agent > of the intended recipient. Unfortunately, this behavior does > not guarantee that information will not be lost; to help prevent > information loss, a gateway ought to include both the > element and the custom extension if the gateway cannot suitably > translate the custom value into a value. > > Mike, does that text address your concern? Do we need to say more (or > less) than that? > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > From stpeter@stpeter.im Wed Jul 31 23:38: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 854EC21F9D2A for ; Wed, 31 Jul 2013 23:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.071 X-Spam-Level: X-Spam-Status: No, score=-101.071 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_22=0.6, 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 bnwti0pkFYWA for ; Wed, 31 Jul 2013 23:38:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5304021F89A6 for ; Wed, 31 Jul 2013 23:38:45 -0700 (PDT) Received: from dhcp-6327.meeting.ietf.org (unknown [130.129.99.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 65EDFE831E; Thu, 1 Aug 2013 00:41:01 -0600 (MDT) Message-ID: <51F99063.30203@stpeter.im> Date: Thu, 01 Aug 2013 00:32:03 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <0CB65FBA-7262-4189-8852-5FC08A34D50D@ag-projects.com> In-Reply-To: <0CB65FBA-7262-4189-8852-5FC08A34D50D@ag-projects.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "stox@ietf.org" Subject: Re: [Stox] Review on -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, 01 Aug 2013 06:38:50 -0000 On 7/30/13 5:33 PM, Saúl Ibarra Corretgé wrote: > Hi, > > Here is my review of the -presence document: > > - Sec 3.3.2 suggests that if the subscription is maintained but we > have no presence state, a PIDF would be generated with a basic status > of closed, but what would be the tuple ID, if we don't know any > resource for this user anymore? We could also send an empty NOTIFY, > which would achieve the same goal. The empty NOTIFY sounds more consistent with the spirit of SIP presence. > - Sec 3.3.2 specifies how to handle the case when a gateway > translated a SIP subscription into an XMPP subscription and then the > SIP side decided to end it, but doesn't mention what to do in case > the XMPP side decides to end it. It should send a NOTIFY with > Subscription-State: terminated;reason=rejected. Agreed. > - Sec 4.1, "Instant Message URI of the form " - > shouldn't this be "Presence URI of the form…" ? Looks like a copy-and-paste error. > - Using ID-123kdklejd doesn't seem to work as a valid xs:ID, TID-1234 > does work though, so we could use TID- as the prefix for tuple > identifiers in examples and such. I will double-check that against the XML specification. > - Table 6 suggests that the Call-ID header should be matched to the > presence stanza id, but the called won't change throughout the whole > dialog, so we should use something else, which changes for each SIP > transaction, what about the Via branch? Table 7 uses CSeq, FWIW. You're right -- Call-ID is not right here. CSeq is better, and I think we changed it in Table 7 but not Table 6. > - Table 6 suggests that priority is translated as the PIDF priority > for a tuple, but that's an attribute of the contact element, which we > don't mention, but I guess we should. Good catch -- we don't seem to include the contact element in any of the examples. Will fix. > Also, the priority in PIDF is a > float between 0 and 1, is it the same for XMPP? Hmm. We had text about that in RFC 3922, and I suggest we copy that to this draft (adjusting as necessary)... An XMPP presence stanza MAY contain a child element whose value is an integer between -128 and +127. The value of this element MAY be mapped to the 'priority' attribute of the child of the PIDF element. If the value of the XMPP element is negative, an XMPP-CPIM gateway MUST NOT map the value. The range of allowable values for the PIDF 'priority' attribute is any decimal number from zero to one inclusive, with a maximum of three decimal places. If an XMPP-CPIM gateway maps these values, it SHOULD treat XMPP 0 as PIDF priority='0' and XMPP 127 as PIDF priority='1', mapping intermediate values appropriately so that they are unique (e.g., XMPP priority 1 to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and so on up through mapping XMPP priority 126 to PIDF priority 0.992; note that this is an example only, and that the exact mapping shall be determined by the XMPP-CPIM gateway). That's twice in one day I have looked at RFC 3922. ;-) > - Sec 4.3, the translated XMPP stanza contains the full JID of > Juliet, but where did we get the resource from? Shouldn't it go to > the bare JID? Another copy-and-paste error, I think. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 31 23:50: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 DED8421F9AAE for ; Wed, 31 Jul 2013 23:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 L-j3+eSDjj6l for ; Wed, 31 Jul 2013 23:50:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC0821F9D83 for ; Wed, 31 Jul 2013 23:50:00 -0700 (PDT) Received: from che-vpn-cluster-1-187.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C617BE831E; Thu, 1 Aug 2013 00:52:16 -0600 (MDT) Message-ID: <51FA0516.40607@stpeter.im> Date: Thu, 01 Aug 2013 08:49:58 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yana Stamcheva References: <51F01857.1050803@stpeter.im> <51F7AE48.1090507@stpeter.im> <7DF21815-06AE-40BF-8AF2-B9A9E8421E17@jitsi.org> <51F89504.9040808@stpeter.im> In-Reply-To: <51F89504.9040808@stpeter.im> 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] draft slides for core, presence, im, chat 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, 01 Aug 2013 06:50:10 -0000 OK, I have updated my slides: https://stpeter.im/files/ietf87-stox-core-presence.pdf Sorry it took me a bit longer than promised -- I wanted to incorporate some results of the list traffic yesterday. Note that I have not included all issues in the slides, only the issues that in my judgment merit a bit of face-to-face discussion. Peter On 7/31/13 6:39 AM, Peter Saint-Andre wrote: > This is just a warning that I'll be providing updated slides to address > some points that Saúl made in his reviews. I'll try to do that as early > today as possible. > > On 7/30/13 2:59 PM, Yana Stamcheva wrote: >> Hi Peter, >> >> Thanks! Your new slides are uploaded. >> >> Yana >> >> On Jul 30, 2013, at 2:15 PM, Peter Saint-Andre wrote: >> >>> After a hallway discussion with Robert Sparks, I have updated these >>> slides. I will post to the list about the issue he raised. >>> >>> On 7/24/13 8:09 PM, Peter Saint-Andre wrote: >>>> Draft slides for discussion of the -core, -presence, -im, and -chat >>>> specfications are here: >>>> >>>> https://stpeter.im/files/ietf87-stox-core-presence.pdf >>>> >>>> As you can see, there are very few open issues. If folks provide >>>> further feedback about these specs in the next few days, I'll update >>>> the slides accordingly. If not, mine will be a very short presentation >>>> and we'll have more time to discuss the -groupchat and -media I-Ds. :-) >>>> >>>> Peter >>>>