From miguel.a.garcia@ericsson.com Tue Oct 2 04:32:48 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F9721F8AD5 for ; Tue, 2 Oct 2012 04:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSqbLZGgqzVC for ; Tue, 2 Oct 2012 04:32:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C579A21F8A8E for ; Tue, 2 Oct 2012 04:32:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-d6-506ad0ddde44 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A0.51.11467.DD0DA605; Tue, 2 Oct 2012 13:32:45 +0200 (CEST) Received: from [164.48.161.175] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 13:32:45 +0200 Message-ID: <506AD0DC.6060201@ericsson.com> Date: Tue, 2 Oct 2012 13:32:44 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <505CCE60.40905@stpeter.im> <505D2E03.2050101@stpeter.im> In-Reply-To: <505D2E03.2050101@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3VvfuhawAg/svDSwWTvzHanFsTz+z A5PHkiU/mTzm7nnBHMAUxWWTkpqTWZZapG+XwJXx9loHa0EfX8XSy2vZGxj3cHcxcnJICJhI nHvVwQZhi0lcuLceyObiEBI4xShx8MdeFghnNaPE03nvWLsYOTh4BbQlDpxgBDFZBFQkpt5z AellEzCXaN24kR3EFhUIlji3cRvYTF4BQYmTM5+wgNgiAloSl671gdUwC6hLXLtyjgnEFhZQ ldjcsIoZZKSQgKvEnMkOICYnUPntvQkQ1bYSF+ZcZ4Gw5SW2v53DDGILCWhKTL65lHkCo+As JMtmIWmZhaRlASPzKkbh3MTMnPRyQ73Uoszk4uL8PL3i1E2MwCA9uOW37g7GU+dEDjFKc7Ao ifNyJe33FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCoqvg0KiBo0f6ZWzoWaJc8a89b5XfB 3O/X1+2NBzIvTWDPsjigx8Ltqd5yw3SvqP9vEQdN39C5kzIPXA/7KjPhhfdco6CAGV8mnpO9 oHJp84X5y1yNODbcu6Qh/UqqPqTfRv6sPGPW7sik99VeG8LNmG7eO6G2h1uK4+0FkxOf45x/ i/ioxEgrsRRnJBpqMRcVJwIA6l2fLSACAAA= Cc: "simple@ietf.org" Subject: Re: [Simple] nickname length X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 11:32:48 -0000 Hi Peter: It is true we don't have a limit in the nickname, for the same reason we don't have a limit in MSRP URIs, SIP URIs, Display-Names in SIP, etc. I don't mind setting the limit to 1023 bytes as you mentioned. /Miguel On 22/09/2012 5:18, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The more I think about this, the more I realize that nickname length > is best left up to protocol specifications for MSRP and XMPP, not the > nickname spec itself. Unless there are objections, I plan to remove > the relevant paragraph from draft-ietf-precis-nickname. > > On 9/21/12 2:30 PM, Peter Saint-Andre wrote: >> Are there any limits on the length of a nickname in >> draft-ietf-simple-chat? I don't see any, nor do I see any on >> quoted-string in RFC 4975. In draft-ietf-precis-nickname, I have a >> limit of 1023 bytes, which comes from RFC 6122 and is probably >> longer than most people will ever use. I received one comment that >> the nickname spec is the wrong place to be imposing such limits, >> and that makes sense (XMPP can impose one limit and MSRP can impose >> another limit, etc.). But I figured it would be good to check here >> before making a change to draft-ietf-precis-nickname on this >> point. >> >> Thanks! >> >> Peter >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBdLgMACgkQNL8k5A2w/vzpfQCdGeCGvS29+7CrMIKwzKeP4HVO > vBUAnAgvo5gFc0Ksq7tpPL3UvybRFQh/ > =ZMK/ > -----END PGP SIGNATURE----- > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From prasun.bheri@gmail.com Mon Oct 8 00:12:39 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFD721F876D for ; Mon, 8 Oct 2012 00:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3u1f4fwp0JS for ; Mon, 8 Oct 2012 00:12:39 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id F15C621F867B for ; Mon, 8 Oct 2012 00:12:38 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so9796869iec.31 for ; Mon, 08 Oct 2012 00:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=pMUJdoAnlpadDyJiYgY9Eqs9y2Nx9cxDCuDdeF23r0E=; b=frw6V4GuE5N6Z2dz3mNrgBo8k1ZFDc2VDYcpAF8BbwyXTAf/YYlKBwscwuNsg0oOfW ZhLxY6nQC+wvoD2WrVcNT7l1KlOY/VXNEqnqFRfeuz9FwXV1PLCz3V5tk+DRKQT7Pjcj ail4h3XLbi0k+YJoxSXwbH325PDJUOpzq6HBMTbTdnR4HHQVNMPdDUZcO9wuQSBKezRo QnpJGoFibGnFX1Nz+/P16bMJPAG/VxvBbt6czN+jvO5H2z0VeojkJzOiF8dNkC3GaYQm VKgUTOwdQP12sTnn8c/q/nVOxo6YKoB39sme1Hud5HnrklvTZEkRoD0cnJwgcaGnxg8o GDgg== Received: by 10.50.46.226 with SMTP id y2mr7162540igm.62.1349680358457; Mon, 08 Oct 2012 00:12:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.69.199 with HTTP; Mon, 8 Oct 2012 00:11:58 -0700 (PDT) From: Prasun Bheri Date: Mon, 8 Oct 2012 12:41:58 +0530 Message-ID: To: Simple@ietf.org Content-Type: multipart/alternative; boundary=14dae9340bcf537f5104cb86f299 Subject: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:12:39 -0000 --14dae9340bcf537f5104cb86f299 Content-Type: text/plain; charset=ISO-8859-1 Hello Group, I would like to use MSRP for various applications such as IM/File Transfer/Screen sharing etc. What is the right way to identify, which MSRP session belongs to which application? Looking at SDP in SIP INVITE all applications could have same accept-types. Thanks & Regards Prasun --14dae9340bcf537f5104cb86f299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Group,=A0
I would like to use MSRP for various applications such = as IM/File Transfer/Screen sharing etc.

What is th= e right way to identify, which MSRP session belongs to which application?

Looking at SDP in SIP INVITE all applications could hav= e same accept-types.

Thanks & Regards
Prasun
--14dae9340bcf537f5104cb86f299-- From ag@ag-projects.com Mon Oct 8 00:17:34 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9E21F8724 for ; Mon, 8 Oct 2012 00:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX1a3F1WEyTJ for ; Mon, 8 Oct 2012 00:17:33 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE5221F870B for ; Mon, 8 Oct 2012 00:17:33 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 2C163B0130; Mon, 8 Oct 2012 09:17:31 +0200 (CEST) Received: from imac3-2.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id D565EB0079; Mon, 8 Oct 2012 09:17:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: Date: Mon, 8 Oct 2012 09:17:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Prasun Bheri X-Mailer: Apple Mail (2.1283) Cc: Simple@ietf.org Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:17:34 -0000 Prasun, The SDP is different between those media types, namely the a lines of = the SDP. Some SIP trace examples for IM, FT and screen-sharing you can = find here: http://sylkserver.com/applications.phtml Adrian On Oct 8, 2012, at 9:11 AM, Prasun Bheri wrote: > Hello Group,=20 > I would like to use MSRP for various applications such as IM/File = Transfer/Screen sharing etc. >=20 > What is the right way to identify, which MSRP session belongs to which = application? >=20 > Looking at SDP in SIP INVITE all applications could have same = accept-types. >=20 > Thanks & Regards > Prasun > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From pkyzivat@alum.mit.edu Mon Oct 8 07:49:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8FE21F87FC for ; Mon, 8 Oct 2012 07:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNRZCUj46-0K for ; Mon, 8 Oct 2012 07:49:52 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id D52D421F87FA for ; Mon, 8 Oct 2012 07:49:51 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta02.westchester.pa.mail.comcast.net with comcast id 8bXp1k0070Fqzac51epvF4; Mon, 08 Oct 2012 14:49:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 8eki1k0073ZTu2S3UekinM; Mon, 08 Oct 2012 14:44:42 +0000 Message-ID: <5072E6E2.5090103@alum.mit.edu> Date: Mon, 08 Oct 2012 10:44:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 14:49:52 -0000 On 10/8/12 3:11 AM, Prasun Bheri wrote: > Hello Group, > I would like to use MSRP for various applications such as IM/File > Transfer/Screen sharing etc. > > What is the right way to identify, which MSRP session belongs to which > application? > > Looking at SDP in SIP INVITE all applications could have same accept-types. AFAIK there are no specific standards for this, but there are mechanisms you can use. E.g. you may use the a=label attribute in sdp to associate an m-line with a label that is significant to an application. Thanks, Paul From stpeter@stpeter.im Mon Oct 8 10:54:33 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED9B21F84D3 for ; Mon, 8 Oct 2012 10:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPVCfs9zoitq for ; Mon, 8 Oct 2012 10:54:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8C66321F86E1 for ; Mon, 8 Oct 2012 10:54:32 -0700 (PDT) Received: from [64.101.72.58] (unknown [64.101.72.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0806B4009B; Mon, 8 Oct 2012 11:56:39 -0600 (MDT) Message-ID: <5073136D.5090307@stpeter.im> Date: Mon, 08 Oct 2012 11:54:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <505CCE60.40905@stpeter.im> <505D2E03.2050101@stpeter.im> <506AD0DC.6060201@ericsson.com> In-Reply-To: <506AD0DC.6060201@ericsson.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: Re: [Simple] nickname length X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 17:54:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My conclusion is: let the XMPP folks set a limit of 1023 bytes in their use of the nickname spec, and let the MSRP folks do what they please. This really isn't a matter for the nickname spec itself, I think... Peter On 10/2/12 5:32 AM, Miguel A. Garcia wrote: > Hi Peter: > > It is true we don't have a limit in the nickname, for the same > reason we don't have a limit in MSRP URIs, SIP URIs, Display-Names > in SIP, etc. > > I don't mind setting the limit to 1023 bytes as you mentioned. > > /Miguel > > On 22/09/2012 5:18, Peter Saint-Andre wrote: The more I think about > this, the more I realize that nickname length is best left up to > protocol specifications for MSRP and XMPP, not the nickname spec > itself. Unless there are objections, I plan to remove the relevant > paragraph from draft-ietf-precis-nickname. > > On 9/21/12 2:30 PM, Peter Saint-Andre wrote: >>>> Are there any limits on the length of a nickname in >>>> draft-ietf-simple-chat? I don't see any, nor do I see any on >>>> quoted-string in RFC 4975. In draft-ietf-precis-nickname, I >>>> have a limit of 1023 bytes, which comes from RFC 6122 and is >>>> probably longer than most people will ever use. I received >>>> one comment that the nickname spec is the wrong place to be >>>> imposing such limits, and that makes sense (XMPP can impose >>>> one limit and MSRP can impose another limit, etc.). But I >>>> figured it would be good to check here before making a change >>>> to draft-ietf-precis-nickname on this point. >>>> >>>> Thanks! >>>> >>>> Peter >>>> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBzE20ACgkQNL8k5A2w/vybbQCePFLYiinpbJLQGehczQMBkyhS IssAnRv0uJYYQehKerSMxoDwp1Dx0p6C =RgJe -----END PGP SIGNATURE----- From miguel.a.garcia@ericsson.com Mon Oct 8 10:56:45 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F1F21F87A8 for ; Mon, 8 Oct 2012 10:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxNrXjfch-g5 for ; Mon, 8 Oct 2012 10:56:44 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 095AA21F86FC for ; Mon, 8 Oct 2012 10:56:43 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-2a-507313da83e5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C8.BA.11467.AD313705; Mon, 8 Oct 2012 19:56:43 +0200 (CEST) Received: from [159.107.48.152] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012 19:56:42 +0200 Message-ID: <507313D8.5080800@ericsson.com> Date: Mon, 8 Oct 2012 19:56:40 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <505CCE60.40905@stpeter.im> <505D2E03.2050101@stpeter.im> <506AD0DC.6060201@ericsson.com> <5073136D.5090307@stpeter.im> In-Reply-To: <5073136D.5090307@stpeter.im> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre5t4eIAg98POC0WTvzHanFsTz+z A5PHkiU/mTzm7nnBHMAUxWWTkpqTWZZapG+XwJXRM/8Nc8F2gYobz7eyNjBO5+1i5OSQEDCR uLbhMQuELSZx4d56ti5GLg4hgVOMEtOuXWaGcFYzStzumcUEUsUroC2xcN1rZhCbRUBFovH7 PbBuNgFzidaNG9lBbFGBYIlzG7exQdQLSpyc+QSsRkRAS+LStT6wGmYBdYlrV86BzRQWUJXY 3LAKalkzo8TC5g9gRZxADXO7/zJCNFhILH5zEKpZXmL72zlgRwgJaEpMvrmUeQKj4Cwk+2Yh aZmFpGUBI/MqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzAcD245bfuDsZT50QOMUpzsCiJ83Il 7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNjdMjU0rWmZjN3suO71Yb2SGh7t69sb5vDu 877/SMDSiM01reBB3uaVLndeHn4wXTQ6YU27SeCx39u+bTknsYt33Xq+utvCNgxbbuu2t39V PjrrRZNWGFNQesyvyell/6e6JDEKHfuQE7gmzOT3hXgOjzMvp2+7cnEJa9JmfR3xKXEpSzSz PZVYijMSDbWYi4oTAXAPdnQlAgAA Cc: "simple@ietf.org" Subject: Re: [Simple] nickname length X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 17:56:45 -0000 Ok for me. /Miguel On 08/10/2012 19:54, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My conclusion is: let the XMPP folks set a limit of 1023 bytes in > their use of the nickname spec, and let the MSRP folks do what they > please. This really isn't a matter for the nickname spec itself, I > think... > > Peter > > On 10/2/12 5:32 AM, Miguel A. Garcia wrote: >> Hi Peter: >> >> It is true we don't have a limit in the nickname, for the same >> reason we don't have a limit in MSRP URIs, SIP URIs, Display-Names >> in SIP, etc. >> >> I don't mind setting the limit to 1023 bytes as you mentioned. >> >> /Miguel >> >> On 22/09/2012 5:18, Peter Saint-Andre wrote: The more I think about >> this, the more I realize that nickname length is best left up to >> protocol specifications for MSRP and XMPP, not the nickname spec >> itself. Unless there are objections, I plan to remove the relevant >> paragraph from draft-ietf-precis-nickname. >> >> On 9/21/12 2:30 PM, Peter Saint-Andre wrote: >>>>> Are there any limits on the length of a nickname in >>>>> draft-ietf-simple-chat? I don't see any, nor do I see any on >>>>> quoted-string in RFC 4975. In draft-ietf-precis-nickname, I >>>>> have a limit of 1023 bytes, which comes from RFC 6122 and is >>>>> probably longer than most people will ever use. I received >>>>> one comment that the nickname spec is the wrong place to be >>>>> imposing such limits, and that makes sense (XMPP can impose >>>>> one limit and MSRP can impose another limit, etc.). But I >>>>> figured it would be good to check here before making a change >>>>> to draft-ietf-precis-nickname on this point. >>>>> >>>>> Thanks! >>>>> >>>>> Peter >>>>> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBzE20ACgkQNL8k5A2w/vybbQCePFLYiinpbJLQGehczQMBkyhS > IssAnRv0uJYYQehKerSMxoDwp1Dx0p6C > =RgJe > -----END PGP SIGNATURE----- > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ag@ag-projects.com Mon Oct 8 11:19:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430411F041C for ; Mon, 8 Oct 2012 11:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtdJtqPgzuIp for ; Mon, 8 Oct 2012 11:19:51 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8253B21F856F for ; Mon, 8 Oct 2012 11:19:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 50292B0132; Mon, 8 Oct 2012 20:19:50 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 8EA46B0067; Mon, 8 Oct 2012 20:19:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <5073136D.5090307@stpeter.im> Date: Mon, 8 Oct 2012 20:19:35 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <505CCE60.40905@stpeter.im> <505D2E03.2050101@stpeter.im> <506AD0DC.6060201@ericsson.com> <5073136D.5090307@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1283) Cc: "simple@ietf.org" Subject: Re: [Simple] nickname length X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:19:52 -0000 +1 On Oct 8, 2012, at 7:54 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My conclusion is: let the XMPP folks set a limit of 1023 bytes in > their use of the nickname spec, and let the MSRP folks do what they > please. This really isn't a matter for the nickname spec itself, I > think... > > Peter > > On 10/2/12 5:32 AM, Miguel A. Garcia wrote: >> Hi Peter: >> >> It is true we don't have a limit in the nickname, for the same >> reason we don't have a limit in MSRP URIs, SIP URIs, Display-Names >> in SIP, etc. >> >> I don't mind setting the limit to 1023 bytes as you mentioned. >> >> /Miguel >> >> On 22/09/2012 5:18, Peter Saint-Andre wrote: The more I think about >> this, the more I realize that nickname length is best left up to >> protocol specifications for MSRP and XMPP, not the nickname spec >> itself. Unless there are objections, I plan to remove the relevant >> paragraph from draft-ietf-precis-nickname. >> >> On 9/21/12 2:30 PM, Peter Saint-Andre wrote: >>>>> Are there any limits on the length of a nickname in >>>>> draft-ietf-simple-chat? I don't see any, nor do I see any on >>>>> quoted-string in RFC 4975. In draft-ietf-precis-nickname, I >>>>> have a limit of 1023 bytes, which comes from RFC 6122 and is >>>>> probably longer than most people will ever use. I received >>>>> one comment that the nickname spec is the wrong place to be >>>>> imposing such limits, and that makes sense (XMPP can impose >>>>> one limit and MSRP can impose another limit, etc.). But I >>>>> figured it would be good to check here before making a change >>>>> to draft-ietf-precis-nickname on this point. >>>>> >>>>> Thanks! >>>>> >>>>> Peter >>>>> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBzE20ACgkQNL8k5A2w/vybbQCePFLYiinpbJLQGehczQMBkyhS > IssAnRv0uJYYQehKerSMxoDwp1Dx0p6C > =RgJe > -----END PGP SIGNATURE----- > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From stpeter@stpeter.im Mon Oct 8 11:44:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBF721F8845 for ; Mon, 8 Oct 2012 11:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbLLT2I8M2bp for ; Mon, 8 Oct 2012 11:44:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CE52921F8844 for ; Mon, 8 Oct 2012 11:44:50 -0700 (PDT) Received: from [64.101.72.58] (unknown [64.101.72.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D18F94009B for ; Mon, 8 Oct 2012 12:46:58 -0600 (MDT) Message-ID: <50731F38.2040103@stpeter.im> Date: Mon, 08 Oct 2012 12:45:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "simple@ietf.org" References: <50731F22.9040406@stpeter.im> In-Reply-To: <50731F22.9040406@stpeter.im> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <50731F22.9040406@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: Re: [precis] I-D Action: draft-ietf-precis-nickname-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:44:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. - -------- Original Message -------- Subject: Re: [precis] I-D Action: draft-ietf-precis-nickname-03.txt Date: Mon, 08 Oct 2012 12:44:50 -0600 From: Peter Saint-Andre To: precis@ietf.org Just some small adjustments to incorporate feedback from reviewers in the SIMPLE WG. I will continue to ping people for reviews in this WG and in SIMPLE. On 10/8/12 12:42 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Preparation and > Comparison of Internationalized Strings Working Group of the IETF. > > Title : Preparation and Comparison of Nicknames > Author(s) : Peter Saint-Andre Filename : > draft-ietf-precis-nickname-03.txt Pages : 7 Date : > 2012-10-08 > > Abstract: This document describes how to prepare and compare > Unicode strings representing nicknames, primarily as used within > textual chatrooms. This profile is intended to be used by > messaging and text conferencing technologies such as the Extensible > Messaging and Presence Protocol (XMPP), the Message Session Relay > Protocol (MSRP), and Centralized Conferencing (XCON). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-nickname > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-nickname-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ precis mailing list > precis@ietf.org https://www.ietf.org/mailman/listinfo/precis > _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBzHzgACgkQNL8k5A2w/vyOsACgqT1hzuMl08KOCIm8iARBZMrh Js0AnilNOWs9UZFXY8qx9C96pEaLnnLW =BwdA -----END PGP SIGNATURE----- From ben@nostrum.com Mon Oct 8 11:56:02 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFE621F855E for ; Mon, 8 Oct 2012 11:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yulnsqJkoDff for ; Mon, 8 Oct 2012 11:56:02 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EDCB321F8543 for ; Mon, 8 Oct 2012 11:56:01 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q98It7Pf095496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Oct 2012 13:55:58 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <5073136D.5090307@stpeter.im> Date: Mon, 8 Oct 2012 13:55:57 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6D595D29-CB76-4261-BC0A-F1DC72732B5C@nostrum.com> References: <505CCE60.40905@stpeter.im> <505D2E03.2050101@stpeter.im> <506AD0DC.6060201@ericsson.com> <5073136D.5090307@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "simple@ietf.org" Subject: Re: [Simple] nickname length X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:56:02 -0000 On Oct 8, 2012, at 12:54 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My conclusion is: let the XMPP folks set a limit of 1023 bytes in > their use of the nickname spec, and let the MSRP folks do what they > please. This really isn't a matter for the nickname spec itself, I > think... > (as individual) I concur. From prasun.bheri@gmail.com Mon Oct 8 22:16:49 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9487121F86E0 for ; Mon, 8 Oct 2012 22:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRF8Gsq7USz0 for ; Mon, 8 Oct 2012 22:16:49 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E037B21F86DE for ; Mon, 8 Oct 2012 22:16:48 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so12478948iec.31 for ; Mon, 08 Oct 2012 22:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=btSyDpIFzIYGxms7rHPBFEGZxACfzs5wkVIjRVnNQYU=; b=oHct1qLToFUNjWf4B3n071v2qvhm3s5nzMMzI8GILRe6KvNcU0lBxh5D9UnMaCSSlY xfxyFGdUS3uiRpbHlCwKaQBTsSOyc64oFWnOSjPHGaTf2U0AncmgB1t3xRWgcLncpeXn 0057wflZIRTbxRq8RnsuodtoT64vA0fPDRtPEU+tte4ftTJNP2rigOQT7TD7ZXIi8IRS DZkK1qwItZOcBjPHGe3OFfShE9Yg8fd+emMjJRIoOO+ucz9bDHx3468sdsk+EBsCLvwf +kAjAuOc/DE8L86zQjwkREQ/mJr1tqq0gBFFngw4vBW73zw6Wj8SQJVj4+o0lFgqA3Hc LojQ== Received: by 10.50.173.41 with SMTP id bh9mr525892igc.52.1349759808486; Mon, 08 Oct 2012 22:16:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.69.199 with HTTP; Mon, 8 Oct 2012 22:16:08 -0700 (PDT) In-Reply-To: <5072E6E2.5090103@alum.mit.edu> References: <5072E6E2.5090103@alum.mit.edu> From: Prasun Bheri Date: Tue, 9 Oct 2012 10:46:08 +0530 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8f50352eeabdf504cb9971e9 Cc: simple@ietf.org Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 05:16:49 -0000 --e89a8f50352eeabdf504cb9971e9 Content-Type: text/plain; charset=ISO-8859-1 Thanks Paul and Adrian. Does it not create inter-op issues? What is the best approach to inter-opp with other msrp implementations. Thanks & Regards Prasun On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat wrote: > On 10/8/12 3:11 AM, Prasun Bheri wrote: > >> Hello Group, >> I would like to use MSRP for various applications such as IM/File >> Transfer/Screen sharing etc. >> >> What is the right way to identify, which MSRP session belongs to which >> application? >> >> Looking at SDP in SIP INVITE all applications could have same >> accept-types. >> > > AFAIK there are no specific standards for this, but there are mechanisms > you can use. > > E.g. you may use the a=label attribute in sdp to associate an m-line with > a label that is significant to an application. > > Thanks, > Paul > > > ______________________________**_________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/**listinfo/simple > --e89a8f50352eeabdf504cb9971e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Paul and Adrian.
Does it not create inter-op issues?
W= hat is the best approach to=A0inter-opp with other msrp implementations.=A0=

Thanks & Regards
Prasun=A0

<= div class=3D"gmail_quote"> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 10/8/12 3:11 AM, Prasun Bheri wr= ote:
Hello Group,
I would like to use MSRP for various applications such as IM/File
Transfer/Screen sharing etc.

What is the right way to identify, which MSRP session belongs to which
application?

Looking at SDP in SIP INVITE all applications could have same accept-types.=

AFAIK there are no specific standards for this, but there are mechanisms yo= u can use.

E.g. you may use the a=3Dlabel attribute in sdp to associate an m-line with= a label that is significant to an application.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


_______________________________________________
Simple mailing list
Simple@ietf.org = https://www.ietf.org/mailman/listinfo/simple

--e89a8f50352eeabdf504cb9971e9-- From ag@ag-projects.com Mon Oct 8 23:48:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658D821F8513 for ; Mon, 8 Oct 2012 23:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WylJ7rF-3Z7 for ; Mon, 8 Oct 2012 23:48:26 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 865F021F84F5 for ; Mon, 8 Oct 2012 23:48:26 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 59D27B0181; Tue, 9 Oct 2012 08:48:24 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 58FF9B007E; Tue, 9 Oct 2012 08:48:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4881653C-9B07-4BDB-8142-A2AD547526CD" From: Adrian Georgescu In-Reply-To: Date: Tue, 9 Oct 2012 08:48:24 +0200 Message-Id: <81CA73A9-CF57-40C2-838B-CE568E029715@ag-projects.com> References: <5072E6E2.5090103@alum.mit.edu> To: Prasun Bheri X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org, Paul Kyzivat Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 06:48:27 -0000 --Apple-Mail=_4881653C-9B07-4BDB-8142-A2AD547526CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Why do you think it creates interoperability issues? Adrian On Oct 9, 2012, at 7:16 AM, Prasun Bheri wrote: > Thanks Paul and Adrian. > Does it not create inter-op issues? > What is the best approach to inter-opp with other msrp = implementations.=20 >=20 > Thanks & Regards > Prasun=20 >=20 > On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat = wrote: > On 10/8/12 3:11 AM, Prasun Bheri wrote: > Hello Group, > I would like to use MSRP for various applications such as IM/File > Transfer/Screen sharing etc. >=20 > What is the right way to identify, which MSRP session belongs to which > application? >=20 > Looking at SDP in SIP INVITE all applications could have same = accept-types. >=20 > AFAIK there are no specific standards for this, but there are = mechanisms you can use. >=20 > E.g. you may use the a=3Dlabel attribute in sdp to associate an m-line = with a label that is significant to an application. >=20 > Thanks, > Paul >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_4881653C-9B07-4BDB-8142-A2AD547526CD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Why do you think it creates interoperability issues?

Adrian

On Oct 9, 2012, at 7:16 AM, Prasun Bheri wrote:

Thanks Paul and Adrian.
Does it not create inter-op issues?
What is the best approach to inter-opp with other msrp implementations. 

Thanks & Regards
Prasun 

On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 10/8/12 3:11 AM, Prasun Bheri wrote:
Hello Group,
I would like to use MSRP for various applications such as IM/File
Transfer/Screen sharing etc.

What is the right way to identify, which MSRP session belongs to which
application?

Looking at SDP in SIP INVITE all applications could have same accept-types.

AFAIK there are no specific standards for this, but there are mechanisms you can use.

E.g. you may use the a=label attribute in sdp to associate an m-line with a label that is significant to an application.

        Thanks,
        Paul


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

--Apple-Mail=_4881653C-9B07-4BDB-8142-A2AD547526CD-- From pkyzivat@alum.mit.edu Tue Oct 9 08:29:08 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B786011E8091 for ; Tue, 9 Oct 2012 08:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T3VPWZ9Y33X for ; Tue, 9 Oct 2012 08:29:08 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 13FE421F8748 for ; Tue, 9 Oct 2012 08:29:07 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8zN11k0071swQuc533VCkR; Tue, 09 Oct 2012 15:29:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 93SX1k00b3ZTu2S3b3SXps; Tue, 09 Oct 2012 15:26:31 +0000 Message-ID: <50744195.4000701@alum.mit.edu> Date: Tue, 09 Oct 2012 11:24:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Prasun Bheri References: <5072E6E2.5090103@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:29:08 -0000 On 10/9/12 1:16 AM, Prasun Bheri wrote: > Thanks Paul and Adrian. > Does it not create inter-op issues? > What is the best approach to inter-opp with other msrp implementations. Certainly it could. The issue arises when you try to multiplex multiple "applications" on a single AOR and, I gather, a single dialog. Standardizing such usage would seem to require a new higher level application framework on top of sip. One such framework that comes to mind is IMS. Thanks, Paul > Thanks & Regards > Prasun > > On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat > wrote: > > On 10/8/12 3:11 AM, Prasun Bheri wrote: > > Hello Group, > I would like to use MSRP for various applications such as IM/File > Transfer/Screen sharing etc. > > What is the right way to identify, which MSRP session belongs to > which > application? > > Looking at SDP in SIP INVITE all applications could have same > accept-types. > > > AFAIK there are no specific standards for this, but there are > mechanisms you can use. > > E.g. you may use the a=label attribute in sdp to associate an m-line > with a label that is significant to an application. > > Thanks, > Paul > > > _________________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/__listinfo/simple > > > From ag@ag-projects.com Wed Oct 10 13:53:56 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18511E808D for ; Wed, 10 Oct 2012 13:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J58-FhZuvVOY for ; Wed, 10 Oct 2012 13:53:56 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id EAE9C21F84B5 for ; Wed, 10 Oct 2012 13:53:55 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 59610B0130; Wed, 10 Oct 2012 22:53:53 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 69353B00E3; Wed, 10 Oct 2012 22:53:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <50744195.4000701@alum.mit.edu> Date: Wed, 10 Oct 2012 22:53:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5072E6E2.5090103@alum.mit.edu> <50744195.4000701@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 20:53:56 -0000 On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote: > On 10/9/12 1:16 AM, Prasun Bheri wrote: >> Thanks Paul and Adrian. >> Does it not create inter-op issues? >> What is the best approach to inter-opp with other msrp = implementations. >=20 > Certainly it could. >=20 Can you please provide a real life example about how this can happen? > The issue arises when you try to multiplex multiple "applications" on = a single AOR and, I gather, a single dialog. Standardizing such usage = would seem to require a new higher level application framework on top of = sip. One such framework that comes to mind is IMS. I am using such single dialog scenario with MSRP and I am not able to = find any issue with it. Can you please expand what issue you are = referring to. Adrian >=20 > Thanks, > Paul >=20 >> Thanks & Regards >> Prasun >>=20 >> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat > > wrote: >>=20 >> On 10/8/12 3:11 AM, Prasun Bheri wrote: >>=20 >> Hello Group, >> I would like to use MSRP for various applications such as = IM/File >> Transfer/Screen sharing etc. >>=20 >> What is the right way to identify, which MSRP session belongs = to >> which >> application? >>=20 >> Looking at SDP in SIP INVITE all applications could have same >> accept-types. >>=20 >>=20 >> AFAIK there are no specific standards for this, but there are >> mechanisms you can use. >>=20 >> E.g. you may use the a=3Dlabel attribute in sdp to associate an = m-line >> with a label that is significant to an application. >>=20 >> Thanks, >> Paul >>=20 >>=20 >> _________________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/__listinfo/simple >> >>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From pkyzivat@alum.mit.edu Wed Oct 10 14:27:17 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044A121F8617 for ; Wed, 10 Oct 2012 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHH1OFIJMnJ4 for ; Wed, 10 Oct 2012 14:27:16 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 333F221F8615 for ; Wed, 10 Oct 2012 14:27:16 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id 9PcN1k00D16LCl055ZTLjy; Wed, 10 Oct 2012 21:27:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 9ZMr1k0103ZTu2S3SZMrYL; Wed, 10 Oct 2012 21:21:52 +0000 Message-ID: <5075E705.40600@alum.mit.edu> Date: Wed, 10 Oct 2012 17:22:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <5072E6E2.5090103@alum.mit.edu> <50744195.4000701@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:27:17 -0000 On 10/10/12 4:53 PM, Adrian Georgescu wrote: > > On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote: > >> On 10/9/12 1:16 AM, Prasun Bheri wrote: >>> Thanks Paul and Adrian. >>> Does it not create inter-op issues? >>> What is the best approach to inter-opp with other msrp implementations. >> >> Certainly it could. >> > > Can you please provide a real life example about how this can happen? > > >> The issue arises when you try to multiplex multiple "applications" on a single AOR and, I gather, a single dialog. Standardizing such usage would seem to require a new higher level application framework on top of sip. One such framework that comes to mind is IMS. > > I am using such single dialog scenario with MSRP and I am not able to find any issue with it. Can you please expand what issue you are referring to. Presumably you are encoding some "application identifier" somewhere, to distinguish between file transfer, screen sharing, etc. (E.g. you could be using a=label for this.) This will work fine as long as you have control over the top level "meta application" at each end, and thus can assure that both ends agree on how to interpret which application is intended. But it will stop working as soon as you bring in some different application at one end that doesn't understand your application identifiers. So as long as you only want a proprietary solution there is no problem. When you want to open it up you can either convince everybody else to follow your defacto proprietary "standard", or you can come back here and create a real standard. Thanks, Paul > Adrian > >> >> Thanks, >> Paul >> >>> Thanks & Regards >>> Prasun >>> >>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat >> > wrote: >>> >>> On 10/8/12 3:11 AM, Prasun Bheri wrote: >>> >>> Hello Group, >>> I would like to use MSRP for various applications such as IM/File >>> Transfer/Screen sharing etc. >>> >>> What is the right way to identify, which MSRP session belongs to >>> which >>> application? >>> >>> Looking at SDP in SIP INVITE all applications could have same >>> accept-types. >>> >>> >>> AFAIK there are no specific standards for this, but there are >>> mechanisms you can use. >>> >>> E.g. you may use the a=label attribute in sdp to associate an m-line >>> with a label that is significant to an application. >>> >>> Thanks, >>> Paul >>> >>> >>> _________________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/__listinfo/simple >>> >>> >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > > From ag@ag-projects.com Wed Oct 10 14:54:31 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07811F042A for ; Wed, 10 Oct 2012 14:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wenWNkr9RmOd for ; Wed, 10 Oct 2012 14:54:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 975931F040A for ; Wed, 10 Oct 2012 14:54:30 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B2016B0156; Wed, 10 Oct 2012 23:54:29 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 6D312B007B; Wed, 10 Oct 2012 23:54:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <5075E705.40600@alum.mit.edu> Date: Wed, 10 Oct 2012 23:54:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68D47588-AE1E-4336-B248-19C60934CF00@ag-projects.com> References: <5072E6E2.5090103@alum.mit.edu> <50744195.4000701@alum.mit.edu> <5075E705.40600@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:54:31 -0000 Hi Paul, I can see what you mean now. My understanding is that when interpreting = the SDP one could do something like: 1. If one does not understand an m line, it will not use it and any a = lines related to it 2. If one does understand an m line, will look necessarily at all a = lines to figure out more details it understands and discard the ones it = does not=20 Are these assumptions good to have interoperability with other SDP = end-points? Adrian On Oct 10, 2012, at 11:22 PM, Paul Kyzivat wrote: > On 10/10/12 4:53 PM, Adrian Georgescu wrote: >>=20 >> On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote: >>=20 >>> On 10/9/12 1:16 AM, Prasun Bheri wrote: >>>> Thanks Paul and Adrian. >>>> Does it not create inter-op issues? >>>> What is the best approach to inter-opp with other msrp = implementations. >>>=20 >>> Certainly it could. >>>=20 >>=20 >> Can you please provide a real life example about how this can happen? >>=20 >>=20 >>> The issue arises when you try to multiplex multiple "applications" = on a single AOR and, I gather, a single dialog. Standardizing such usage = would seem to require a new higher level application framework on top of = sip. One such framework that comes to mind is IMS. >>=20 >> I am using such single dialog scenario with MSRP and I am not able to = find any issue with it. Can you please expand what issue you are = referring to. >=20 > Presumably you are encoding some "application identifier" somewhere, = to distinguish between file transfer, screen sharing, etc. (E.g. you = could be using a=3Dlabel for this.) > This will work fine as long as you have control over the top level = "meta application" at each end, and thus can assure that both ends agree = on how to interpret which application is intended. >=20 > But it will stop working as soon as you bring in some different = application at one end that doesn't understand your application = identifiers. >=20 > So as long as you only want a proprietary solution there is no = problem. When you want to open it up you can either convince everybody = else to follow your defacto proprietary "standard", or you can come back = here and create a real standard. >=20 > Thanks, > Paul >=20 >> Adrian >>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Thanks & Regards >>>> Prasun >>>>=20 >>>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat >>> > wrote: >>>>=20 >>>> On 10/8/12 3:11 AM, Prasun Bheri wrote: >>>>=20 >>>> Hello Group, >>>> I would like to use MSRP for various applications such as = IM/File >>>> Transfer/Screen sharing etc. >>>>=20 >>>> What is the right way to identify, which MSRP session = belongs to >>>> which >>>> application? >>>>=20 >>>> Looking at SDP in SIP INVITE all applications could have = same >>>> accept-types. >>>>=20 >>>>=20 >>>> AFAIK there are no specific standards for this, but there are >>>> mechanisms you can use. >>>>=20 >>>> E.g. you may use the a=3Dlabel attribute in sdp to associate an = m-line >>>> with a label that is significant to an application. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>=20 >>>> _________________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/__listinfo/simple >>>> >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From pkyzivat@alum.mit.edu Wed Oct 10 15:53:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFB821F847D for ; Wed, 10 Oct 2012 15:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.081 X-Spam-Level: X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np4GoaadFhWX for ; Wed, 10 Oct 2012 15:53:29 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 0A19A21F847A for ; Wed, 10 Oct 2012 15:53:28 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta14.westchester.pa.mail.comcast.net with comcast id 9Y4E1k0020cZkys5EatYey; Wed, 10 Oct 2012 22:53:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 9aoS1k0063ZTu2S3WaoSVi; Wed, 10 Oct 2012 22:48:26 +0000 Message-ID: <5075FB3B.9070305@alum.mit.edu> Date: Wed, 10 Oct 2012 18:48:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <5072E6E2.5090103@alum.mit.edu> <50744195.4000701@alum.mit.edu> <5075E705.40600@alum.mit.edu> <68D47588-AE1E-4336-B248-19C60934CF00@ag-projects.com> In-Reply-To: <68D47588-AE1E-4336-B248-19C60934CF00@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] How to identify application type of MSRP session. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 22:53:36 -0000 On 10/10/12 5:54 PM, Adrian Georgescu wrote: > Hi Paul, > > I can see what you mean now. My understanding is that when interpreting the SDP one could do something like: > > 1. If one does not understand an m line, it will not use it and any a lines related to it Yes, that is what you are expected to do. You would want to reject the m-line in the answer with a zero port. > 2. If one does understand an m line, will look necessarily at all a lines to figure out more details it understands and discard the ones it does not Yes, this is also the expectation. > Are these assumptions good to have interoperability with other SDP end-points? These are necessary but not sufficient for interoperability. If one side puts in a proprietary a-line that must be understood to properly process the stream, and the other side doesn't understand that line, ignores it, and then handles the stream in a different way, then you still have an interoperability problem. For instance, suppose you support both IM and screen sharing via MSRP. For one session you only intend to use screen sharing. You send off an offer with the MSRP m-lline and your indication that this is for screen sharing. The other side ignores that and assumes that this msrp session is for IM. It may then bring up a UI, and do all sorts of odd things. You can probably avoid many problems just by which media types you support on the msrp session. In fact, you might be able to solve most of the problems you are trying to deal with by having unique media types for each of your applications. If not, then be careful. If you aren't already aware of it, you should look at RFC 5547. Thanks, Paul > Adrian > > On Oct 10, 2012, at 11:22 PM, Paul Kyzivat wrote: > >> On 10/10/12 4:53 PM, Adrian Georgescu wrote: >>> >>> On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote: >>> >>>> On 10/9/12 1:16 AM, Prasun Bheri wrote: >>>>> Thanks Paul and Adrian. >>>>> Does it not create inter-op issues? >>>>> What is the best approach to inter-opp with other msrp implementations. >>>> >>>> Certainly it could. >>>> >>> >>> Can you please provide a real life example about how this can happen? >>> >>> >>>> The issue arises when you try to multiplex multiple "applications" on a single AOR and, I gather, a single dialog. Standardizing such usage would seem to require a new higher level application framework on top of sip. One such framework that comes to mind is IMS. >>> >>> I am using such single dialog scenario with MSRP and I am not able to find any issue with it. Can you please expand what issue you are referring to. >> >> Presumably you are encoding some "application identifier" somewhere, to distinguish between file transfer, screen sharing, etc. (E.g. you could be using a=label for this.) >> This will work fine as long as you have control over the top level "meta application" at each end, and thus can assure that both ends agree on how to interpret which application is intended. >> >> But it will stop working as soon as you bring in some different application at one end that doesn't understand your application identifiers. >> >> So as long as you only want a proprietary solution there is no problem. When you want to open it up you can either convince everybody else to follow your defacto proprietary "standard", or you can come back here and create a real standard. >> >> Thanks, >> Paul >> >>> Adrian >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Thanks & Regards >>>>> Prasun >>>>> >>>>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat >>>> > wrote: >>>>> >>>>> On 10/8/12 3:11 AM, Prasun Bheri wrote: >>>>> >>>>> Hello Group, >>>>> I would like to use MSRP for various applications such as IM/File >>>>> Transfer/Screen sharing etc. >>>>> >>>>> What is the right way to identify, which MSRP session belongs to >>>>> which >>>>> application? >>>>> >>>>> Looking at SDP in SIP INVITE all applications could have same >>>>> accept-types. >>>>> >>>>> >>>>> AFAIK there are no specific standards for this, but there are >>>>> mechanisms you can use. >>>>> >>>>> E.g. you may use the a=label attribute in sdp to associate an m-line >>>>> with a label that is significant to an application. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>> _________________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/__listinfo/simple >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>> >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > > From toyvenu@gmail.com Thu Oct 11 22:07:11 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08C321F84CD for ; Thu, 11 Oct 2012 22:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JDvunYHQLyn for ; Thu, 11 Oct 2012 22:07:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42A21F84D8 for ; Thu, 11 Oct 2012 22:07:10 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2004272lbo.31 for ; Thu, 11 Oct 2012 22:07:09 -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=VOAIUosuyNqJSXCYu8bWJFN+/ccwPZQrtabRvuLw/Og=; b=CmiTVW7BEObo8w9A8hqOHxF4K/0kzfKJiS7DDbKIlalARLxigyeGmWV4VUuElQxVxn Jy6tHhu2NvFTgC8vRq6NYoVbtPcn+5+Pm7Pe+NStgV9+0QYWAKYOs+eLYEH9J5V6OAL1 RxU7iCH20NMiHXPIlorr8cw5cxiqDnL9DMVgC+Zg9AS769IKGlUYv6AdogomTRq+hv7e jdzpOLLXljjR9sCroUIqzZnjoUXnLN/L9kGzSXX4uVqbNuj9lzIPfL4CrSdTr7Og2YEO 4i3wbbnEoR7Vlvxn+Dt8W8QPnxHAUapnt+2Dpk9/ov8CqZ5L/+GhqC7G9dJL+ZulaJQ3 dv0Q== MIME-Version: 1.0 Received: by 10.112.39.230 with SMTP id s6mr1159021lbk.90.1350018429553; Thu, 11 Oct 2012 22:07:09 -0700 (PDT) Received: by 10.112.37.37 with HTTP; Thu, 11 Oct 2012 22:07:09 -0700 (PDT) Date: Fri, 12 Oct 2012 10:37:09 +0530 Message-ID: From: venu Y To: simple@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe301cef0b3704cbd5a89f Subject: [Simple] How to identify the session X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 05:07:11 -0000 --e0cb4efe301cef0b3704cbd5a89f Content-Type: text/plain; charset=ISO-8859-1 Hi, For file transfer we can uniquely identify the session, based on 'a=file-selector' attribute. But for IM/MMS/Screen sharing... it's very unpredictable. Will it solve all the problem if instead of m=message, if we have m=im m=screen-share m=ftp etc., or Using 'SIP Tags' in the OFFER will solve most of the issues.. but will the order of the Tags and 'm=' line are in sync or not is the issue? On 10/10/12 5:54 PM, Adrian Georgescu wrote: > Hi Paul, > > I can see what you mean now. My understanding is that when interpreting the SDP one could do something like: > > 1. If one does not understand an m line, it will not use it and any a lines related to it Yes, that is what you are expected to do. You would want to reject the m-line in the answer with a zero port. > 2. If one does understand an m line, will look necessarily at all a lines to figure out more details it understands and discard the ones it does not Yes, this is also the expectation. > Are these assumptions good to have interoperability with other SDP end-points? These are necessary but not sufficient for interoperability. If one side puts in a proprietary a-line that must be understood to properly process the stream, and the other side doesn't understand that line, ignores it, and then handles the stream in a different way, then you still have an interoperability problem. For instance, suppose you support both IM and screen sharing via MSRP. For one session you only intend to use screen sharing. You send off an offer with the MSRP m-lline and your indication that this is for screen sharing. The other side ignores that and assumes that this msrp session is for IM. It may then bring up a UI, and do all sorts of odd things. You can probably avoid many problems just by which media types you support on the msrp session. In fact, you might be able to solve most of the problems you are trying to deal with by having unique media types for each of your applications. If not, then be careful. If you aren't already aware of it, you should look at RFC 5547. Thanks, Paul Thanks and Regards -Venu --e0cb4efe301cef0b3704cbd5a89f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

For file transfer we can = uniquely identify the session, based on 'a=3Dfile-selector' attribu= te.

But for IM/MMS/Screen sharing... it's very= unpredictable.

Will it solve all the problem if instead of m=3Dmessage, if = we have

m=3Dim
m=3Dscreen-share
m=3Dftp

etc.,

or
<= div>

Using 'SIP Tags' in the OFFER will solve most o= f the issues.. but will the order of the Tags and 'm=3D' line are i= n sync or not is the issue?

On 10/10/12 5:54 PM, Adrian Georgescu wrote:<= br style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px= ;background-color:rgb(255,255,255)"> > Hi Paul,
>
> I can see what you mean now. My= understanding is that when interpreting the SDP one could do something lik= e:
>
> 1. If one does not understand a= n m line, it will not use it and any a lines related to it

Yes, that is what you are expected to do.
You would want to reject the m-line = in the answer with a zero port.

> 2. If one does understand an m line, will look necessarily at all a l= ines to figure out more details it understands and discard the ones it does= not

Yes, this is also the expectation.

> Are these assumptions good to have interoperability with other SDP en= d-points?

These are necessary but not sufficient for interoperability.

If one side puts in a proprietary a-line that must be understood to=
properly process the stream, and the= other side doesn't understand that
line, ignores it, and then handles t= he stream in a different way, then
you still have an interoperability p= roblem.

For instance, suppose you support both IM and screen sharing via MSRP.
For one session you only intend to u= se screen sharing. You send off an
offer with the MSRP m-lline and your= indication that this is for screen
sharing. The other side ignores that= and assumes that this msrp session
is for IM. It may then bring up a UI= , and do all sorts of odd things.
You can probably avoid many problems just by which media types you<= br style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px= ;background-color:rgb(255,255,255)"> support on the msrp session. In fact= , you might be able to solve most of
the problems you are trying to deal = with by having unique media types
for each of your applications. If no= t, then be careful.

If you aren't already aware of it, you should look at RFC 5547.=

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Thanks and Regards
-Venu
--e0cb4efe301cef0b3704cbd5a89f-- From toyvenu@gmail.com Thu Oct 11 22:04:09 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A2521F84A6 for ; Thu, 11 Oct 2012 22:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh5f1U0c4WqX for ; Thu, 11 Oct 2012 22:04:07 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54FAD21F849A for ; Thu, 11 Oct 2012 22:04:06 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2002978lbo.31 for ; Thu, 11 Oct 2012 22:04:05 -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 :content-type; bh=I77DNdK3kMxSycE558ngCYOk1ZTbmeA5xnYPD52IbL4=; b=YjGeGpwaSBrzVNPtboVYv0UEWtmD1BzEyt3CYkCAHfRUX4+6h82MBRWgjsjUdDKI4Y mOM5CiVfObgDqPr2JOfH6FpZlrMT7cSYVAf785V1mYObn/o/FrU+Dyf/XoC/HNfDYFhM fjSw6p+bTYruaNYyJy6dHVRhMO4hUwgiASY+EaMKwh/bao+2aGsNPdWj7amGjJSuRS9B zF9otnCSq9i4X+2FTYry9QgvLPebyvVfISfCnKiGHv+ZOT8C9SKNGJYPUOPb8OY6oDlB Ro8CR1WUEcufFh8gcwDrnKIQI2PuNwtmoo8HXfZthqywHTkp7I4ijXNgUoEUlITTISKk 86ug== MIME-Version: 1.0 Received: by 10.112.99.71 with SMTP id eo7mr1112294lbb.83.1350018245054; Thu, 11 Oct 2012 22:04:05 -0700 (PDT) Received: by 10.112.37.37 with HTTP; Thu, 11 Oct 2012 22:04:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Oct 2012 10:34:04 +0530 Message-ID: From: venu Y To: simple@ietf.org Content-Type: multipart/alternative; boundary=f46d04016a23efd24504cbd59da6 X-Mailman-Approved-At: Fri, 12 Oct 2012 06:39:01 -0700 Subject: Re: [Simple] Simple Digest, Vol 102, Issue 4 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 05:04:09 -0000 --f46d04016a23efd24504cbd59da6 Content-Type: text/plain; charset=ISO-8859-1 Hi, For file transfer we can uniquely identify the session, based on 'a=file-selector' attribute. But for IM/MMS/Screen sharing... it's very unpredictable. Will it solve all the problem if instead of m=message, if we have m=im m=screen-share m=ftp etc., or Using 'SIP Tags' in the OFFER will solve most of the issues.. but will the order of the Tags and 'm=' line are in sync or not is the issue? Thanks and Regards -Venu On Fri, Oct 12, 2012 at 12:30 AM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/simple > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send Simple mailing list submissions to > simple@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/simple > or, via email, send a message with subject or body 'help' to > simple-request@ietf.org > > You can reach the person managing the list at > simple-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Simple digest..." > > > Today's Topics: > > 1. Re: How to identify application type of MSRP session. > (Adrian Georgescu) > 2. Re: How to identify application type of MSRP session. > (Paul Kyzivat) > 3. Re: How to identify application type of MSRP session. > (Adrian Georgescu) > 4. Re: How to identify application type of MSRP session. > (Paul Kyzivat) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 10 Oct 2012 22:53:53 +0200 > From: Adrian Georgescu > To: Paul Kyzivat > Cc: simple@ietf.org > Subject: Re: [Simple] How to identify application type of MSRP > session. > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote: > > > On 10/9/12 1:16 AM, Prasun Bheri wrote: > >> Thanks Paul and Adrian. > >> Does it not create inter-op issues? > >> What is the best approach to inter-opp with other msrp implementations. > > > > Certainly it could. > > > > Can you please provide a real life example about how this can happen? > > > > The issue arises when you try to multiplex multiple "applications" on a > single AOR and, I gather, a single dialog. Standardizing such usage would > seem to require a new higher level application framework on top of sip. One > such framework that comes to mind is IMS. > > I am using such single dialog scenario with MSRP and I am not able to find > any issue with it. Can you please expand what issue you are referring to. > > Adrian > > > > > Thanks, > > Paul > > > >> Thanks & Regards > >> Prasun > >> > >> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat >> > wrote: > >> > >> On 10/8/12 3:11 AM, Prasun Bheri wrote: > >> > >> Hello Group, > >> I would like to use MSRP for various applications such as IM/File > >> Transfer/Screen sharing etc. > >> > >> What is the right way to identify, which MSRP session belongs to > >> which > >> application? > >> > >> Looking at SDP in SIP INVITE all applications could have same > >> accept-types. > >> > >> > >> AFAIK there are no specific standards for this, but there are > >> mechanisms you can use. > >> > >> E.g. you may use the a=label attribute in sdp to associate an m-line > >> with a label that is significant to an application. > >> > >> Thanks, > >> Paul > >> > >> > >> _________________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/__listinfo/simple > >> > >> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 10 Oct 2012 17:22:13 -0400 > From: Paul Kyzivat > To: Adrian Georgescu > Cc: simple@ietf.org > Subject: Re: [Simple] How to identify application type of MSRP > session. > Message-ID: <5075E705.40600@alum.mit.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/10/12 4:53 PM, Adrian Georgescu wrote: > > > > On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote: > > > >> On 10/9/12 1:16 AM, Prasun Bheri wrote: > >>> Thanks Paul and Adrian. > >>> Does it not create inter-op issues? > >>> What is the best approach to inter-opp with other msrp implementations. > >> > >> Certainly it could. > >> > > > > Can you please provide a real life example about how this can happen? > > > > > >> The issue arises when you try to multiplex multiple "applications" on a > single AOR and, I gather, a single dialog. Standardizing such usage would > seem to require a new higher level application framework on top of sip. One > such framework that comes to mind is IMS. > > > > I am using such single dialog scenario with MSRP and I am not able to > find any issue with it. Can you please expand what issue you are referring > to. > > Presumably you are encoding some "application identifier" somewhere, to > distinguish between file transfer, screen sharing, etc. (E.g. you could > be using a=label for this.) > > This will work fine as long as you have control over the top level "meta > application" at each end, and thus can assure that both ends agree on > how to interpret which application is intended. > > But it will stop working as soon as you bring in some different > application at one end that doesn't understand your application > identifiers. > > So as long as you only want a proprietary solution there is no problem. > When you want to open it up you can either convince everybody else to > follow your defacto proprietary "standard", or you can come back here > and create a real standard. > > Thanks, > Paul > > > Adrian > > > >> > >> Thanks, > >> Paul > >> > >>> Thanks & Regards > >>> Prasun > >>> > >>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat >>> > wrote: > >>> > >>> On 10/8/12 3:11 AM, Prasun Bheri wrote: > >>> > >>> Hello Group, > >>> I would like to use MSRP for various applications such as > IM/File > >>> Transfer/Screen sharing etc. > >>> > >>> What is the right way to identify, which MSRP session belongs > to > >>> which > >>> application? > >>> > >>> Looking at SDP in SIP INVITE all applications could have same > >>> accept-types. > >>> > >>> > >>> AFAIK there are no specific standards for this, but there are > >>> mechanisms you can use. > >>> > >>> E.g. you may use the a=label attribute in sdp to associate an > m-line > >>> with a label that is significant to an application. > >>> > >>> Thanks, > >>> Paul > >>> > >>> > >>> _________________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www.ietf.org/mailman/__listinfo/simple > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/listinfo/simple > >> > > > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 10 Oct 2012 23:54:14 +0200 > From: Adrian Georgescu > To: Paul Kyzivat > Cc: simple@ietf.org > Subject: Re: [Simple] How to identify application type of MSRP > session. > Message-ID: <68D47588-AE1E-4336-B248-19C60934CF00@ag-projects.com> > Content-Type: text/plain; charset=us-ascii > > Hi Paul, > > I can see what you mean now. My understanding is that when interpreting > the SDP one could do something like: > > 1. If one does not understand an m line, it will not use it and any a > lines related to it > 2. If one does understand an m line, will look necessarily at all a lines > to figure out more details it understands and discard the ones it does not > > Are these assumptions good to have interoperability with other SDP > end-points? > > Adrian > > On Oct 10, 2012, at 11:22 PM, Paul Kyzivat wrote: > > > On 10/10/12 4:53 PM, Adrian Georgescu wrote: > >> > >> On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote: > >> > >>> On 10/9/12 1:16 AM, Prasun Bheri wrote: > >>>> Thanks Paul and Adrian. > >>>> Does it not create inter-op issues? > >>>> What is the best approach to inter-opp with other msrp > implementations. > >>> > >>> Certainly it could. > >>> > >> > >> Can you please provide a real life example about how this can happen? > >> > >> > >>> The issue arises when you try to multiplex multiple "applications" on > a single AOR and, I gather, a single dialog. Standardizing such usage would > seem to require a new higher level application framework on top of sip. One > such framework that comes to mind is IMS. > >> > >> I am using such single dialog scenario with MSRP and I am not able to > find any issue with it. Can you please expand what issue you are referring > to. > > > > Presumably you are encoding some "application identifier" somewhere, to > distinguish between file transfer, screen sharing, etc. (E.g. you could be > using a=label for this.) > > This will work fine as long as you have control over the top level "meta > application" at each end, and thus can assure that both ends agree on how > to interpret which application is intended. > > > > But it will stop working as soon as you bring in some different > application at one end that doesn't understand your application identifiers. > > > > So as long as you only want a proprietary solution there is no problem. > When you want to open it up you can either convince everybody else to > follow your defacto proprietary "standard", or you can come back here and > create a real standard. > > > > Thanks, > > Paul > > > >> Adrian > >> > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Thanks & Regards > >>>> Prasun > >>>> > >>>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat >>>> > wrote: > >>>> > >>>> On 10/8/12 3:11 AM, Prasun Bheri wrote: > >>>> > >>>> Hello Group, > >>>> I would like to use MSRP for various applications such as > IM/File > >>>> Transfer/Screen sharing etc. > >>>> > >>>> What is the right way to identify, which MSRP session belongs > to > >>>> which > >>>> application? > >>>> > >>>> Looking at SDP in SIP INVITE all applications could have same > >>>> accept-types. > >>>> > >>>> > >>>> AFAIK there are no specific standards for this, but there are > >>>> mechanisms you can use. > >>>> > >>>> E.g. you may use the a=label attribute in sdp to associate an > m-line > >>>> with a label that is significant to an application. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> > >>>> _________________________________________________ > >>>> Simple mailing list > >>>> Simple@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/simple > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www.ietf.org/mailman/listinfo/simple > >>> > >> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > > > > > ------------------------------ > > Message: 4 > Date: Wed, 10 Oct 2012 18:48:27 -0400 > From: Paul Kyzivat > To: Adrian Georgescu > Cc: simple@ietf.org > Subject: Re: [Simple] How to identify application type of MSRP > session. > Message-ID: <5075FB3B.9070305@alum.mit.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/10/12 5:54 PM, Adrian Georgescu wrote: > > Hi Paul, > > > > I can see what you mean now. My understanding is that when interpreting > the SDP one could do something like: > > > > 1. If one does not understand an m line, it will not use it and any a > lines related to it > > Yes, that is what you are expected to do. > You would want to reject the m-line in the answer with a zero port. > > > 2. If one does understand an m line, will look necessarily at all a > lines to figure out more details it understands and discard the ones it > does not > > Yes, this is also the expectation. > > > Are these assumptions good to have interoperability with other SDP > end-points? > > These are necessary but not sufficient for interoperability. > > If one side puts in a proprietary a-line that must be understood to > properly process the stream, and the other side doesn't understand that > line, ignores it, and then handles the stream in a different way, then > you still have an interoperability problem. > > For instance, suppose you support both IM and screen sharing via MSRP. > For one session you only intend to use screen sharing. You send off an > offer with the MSRP m-lline and your indication that this is for screen > sharing. The other side ignores that and assumes that this msrp session > is for IM. It may then bring up a UI, and do all sorts of odd things. > > You can probably avoid many problems just by which media types you > support on the msrp session. In fact, you might be able to solve most of > the problems you are trying to deal with by having unique media types > for each of your applications. If not, then be careful. > > If you aren't already aware of it, you should look at RFC 5547. > > Thanks, > Paul > > > Adrian > > > > On Oct 10, 2012, at 11:22 PM, Paul Kyzivat wrote: > > > >> On 10/10/12 4:53 PM, Adrian Georgescu wrote: > >>> > >>> On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote: > >>> > >>>> On 10/9/12 1:16 AM, Prasun Bheri wrote: > >>>>> Thanks Paul and Adrian. > >>>>> Does it not create inter-op issues? > >>>>> What is the best approach to inter-opp with other msrp > implementations. > >>>> > >>>> Certainly it could. > >>>> > >>> > >>> Can you please provide a real life example about how this can happen? > >>> > >>> > >>>> The issue arises when you try to multiplex multiple "applications" on > a single AOR and, I gather, a single dialog. Standardizing such usage would > seem to require a new higher level application framework on top of sip. One > such framework that comes to mind is IMS. > >>> > >>> I am using such single dialog scenario with MSRP and I am not able to > find any issue with it. Can you please expand what issue you are referring > to. > >> > >> Presumably you are encoding some "application identifier" somewhere, to > distinguish between file transfer, screen sharing, etc. (E.g. you could be > using a=label for this.) > >> This will work fine as long as you have control over the top level > "meta application" at each end, and thus can assure that both ends agree on > how to interpret which application is intended. > >> > >> But it will stop working as soon as you bring in some different > application at one end that doesn't understand your application identifiers. > >> > >> So as long as you only want a proprietary solution there is no problem. > When you want to open it up you can either convince everybody else to > follow your defacto proprietary "standard", or you can come back here and > create a real standard. > >> > >> Thanks, > >> Paul > >> > >>> Adrian > >>> > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Thanks & Regards > >>>>> Prasun > >>>>> > >>>>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat >>>>> > wrote: > >>>>> > >>>>> On 10/8/12 3:11 AM, Prasun Bheri wrote: > >>>>> > >>>>> Hello Group, > >>>>> I would like to use MSRP for various applications such as > IM/File > >>>>> Transfer/Screen sharing etc. > >>>>> > >>>>> What is the right way to identify, which MSRP session > belongs to > >>>>> which > >>>>> application? > >>>>> > >>>>> Looking at SDP in SIP INVITE all applications could have same > >>>>> accept-types. > >>>>> > >>>>> > >>>>> AFAIK there are no specific standards for this, but there are > >>>>> mechanisms you can use. > >>>>> > >>>>> E.g. you may use the a=label attribute in sdp to associate an > m-line > >>>>> with a label that is significant to an application. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> > >>>>> _________________________________________________ > >>>>> Simple mailing list > >>>>> Simple@ietf.org > >>>>> https://www.ietf.org/mailman/__listinfo/simple > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Simple mailing list > >>>> Simple@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/simple > >>>> > >>> > >>> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/listinfo/simple > >> > > > > > > > > ------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > > End of Simple Digest, Vol 102, Issue 4 > ************************************** > -- With Regards Venu 93484 89945 toyvenu@gmail.com --f46d04016a23efd24504cbd59da6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

For file transfer we can uniquely identify the sessi= on, based on 'a=3Dfile-selector' attribute.

But for IM/MMS/Screen sharing... it's very unpredictable.

Will it solve all the problem if instead of m=3Dmessage, if = we have

m=3Dim
m=3Dscreen-share
m=3Dftp

etc.,

or
<= div>

Using 'SIP Tags' in the OFFER will solve most o= f the issues.. but will the order of the Tags and 'm=3D' line are i= n sync or not is the issue?

Thanks and Regar= ds
-Venu

On Fri, Oct = 12, 2012 at 12:30 AM, <simple-request@ietf.org> wrote= :
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

= https://www.ietf.org/mailman/listinfo/simple

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send Simple mailing list submissions to
=A0 =A0 =A0 =A0 simple= @ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/simple
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0 simple-request@ietf.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0 = simple-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Simple digest..."


Today's Topics:

=A0 =A01. Re: How to identify application type of MSRP session.
=A0 =A0 =A0 (Adrian Georgescu)
=A0 =A02. Re: How to identify application type of MSRP session.
=A0 =A0 =A0 (Paul Kyzivat)
=A0 =A03. Re: How to identify application type of MSRP session.
=A0 =A0 =A0 (Adrian Georgescu)
=A0 =A04. Re: How to identify application type of MSRP session.
=A0 =A0 =A0 (Paul Kyzivat)


----------------------------------------------------------------------

Message: 1
Date: Wed, 10 Oct 2012 22:53:53 +0200
From: Adrian Georgescu <ag@ag-projects.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: simple@ietf.org
Subject: Re: [Simple] How to identify application type of MSRP
=A0 =A0 =A0 =A0 session.
Message-ID: <FC161E87-FFA0-45E1-9519-C83C3E304248@ag-proj= ects.com>
Content-Type: text/plain; charset=3Dus-ascii


On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote:

> On 10/9/12 1:16 AM, Prasun Bheri wrote:
>> Thanks Paul and Adrian.
>> Does it not create inter-op issues?
>> What is the best approach to inter-opp with other msrp implementat= ions.
>
> Certainly it could.
>

Can you please provide a real life example about how this can happen?


> The issue arises when you try to multiplex multiple "applications= " on a single AOR and, I gather, a single dialog. Standardizing such u= sage would seem to require a new higher level application framework on top = of sip. One such framework that comes to mind is IMS.

I am using such single dialog scenario with MSRP and I am not able to find = any issue with it. Can you please expand what issue you are referring to.
Adrian

>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Thanks & Regards
>> Prasun
>>
>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>> =A0 =A0On 10/8/12 3:11 AM, Prasun Bheri wrote:
>>
>> =A0 =A0 =A0 =A0Hello Group,
>> =A0 =A0 =A0 =A0I would like to use MSRP for various applications s= uch as IM/File
>> =A0 =A0 =A0 =A0Transfer/Screen sharing etc.
>>
>> =A0 =A0 =A0 =A0What is the right way to identify, which MSRP sessi= on belongs to
>> =A0 =A0 =A0 =A0which
>> =A0 =A0 =A0 =A0application?
>>
>> =A0 =A0 =A0 =A0Looking at SDP in SIP INVITE all applications could= have same
>> =A0 =A0 =A0 =A0accept-types.
>>
>>
>> =A0 =A0AFAIK there are no specific standards for this, but there a= re
>> =A0 =A0mechanisms you can use.
>>
>> =A0 =A0E.g. you may use the a=3Dlabel attribute in sdp to associat= e an m-line
>> =A0 =A0with a label that is significant to an application.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 =A0 =A0 Paul
>>
>>
>> =A0 =A0_________________________________________________
>> =A0 =A0Simple mailing list
>> =A0 =A0Simple= @ietf.org <mailto:Simple@ietf.org>
>> =A0 =A0https://www.ietf.org/mailman/__listinfo/simple
>> =A0 =A0<https://www.ietf.org/mailman/listinfo/simple> >>
>>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>



------------------------------

Message: 2
Date: Wed, 10 Oct 2012 17:22:13 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: Adrian Georgescu <ag@ag-projects.com>
Cc: simple@ietf.org
Subject: Re: [Simple] How to identify application type of MSRP
=A0 =A0 =A0 =A0 session.
Message-ID: <5075E705.40600@alum.mit.edu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

On 10/10/12 4:53 PM, Adrian Georgescu wrote:
>
> On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote:
>
>> On 10/9/12 1:16 AM, Prasun Bheri wrote:
>>> Thanks Paul and Adrian.
>>> Does it not create inter-op issues?
>>> What is the best approach to inter-opp with other msrp impleme= ntations.
>>
>> Certainly it could.
>>
>
> Can you please provide a real life example about how this can happen?<= br> >
>
>> The issue arises when you try to multiplex multiple "applicat= ions" on a single AOR and, I gather, a single dialog. Standardizing su= ch usage would seem to require a new higher level application framework on = top of sip. One such framework that comes to mind is IMS.
>
> I am using such single dialog scenario with MSRP and I am not able to = find any issue with it. Can you please expand what issue you are referring = to.

Presumably you are encoding some "application identifier" somewhe= re, to
distinguish between file transfer, screen sharing, etc. (E.g. you could
be using a=3Dlabel for this.)

This will work fine as long as you have control over the top level "me= ta
application" at each end, and thus can assure that both ends agree on<= br> how to interpret which application is intended.

But it will stop working as soon as you bring in some different
application at one end that doesn't understand your application identif= iers.

So as long as you only want a proprietary solution there is no problem.
When you want to open it up you can either convince everybody else to
follow your defacto proprietary "standard", or you can come back = here
and create a real standard.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

> Adrian
>
>>
>> =A0 =A0 =A0Thanks,
>> =A0 =A0 =A0Paul
>>
>>> Thanks & Regards
>>> Prasun
>>>
>>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>
>>> =A0 =A0 On 10/8/12 3:11 AM, Prasun Bheri wrote:
>>>
>>> =A0 =A0 =A0 =A0 Hello Group,
>>> =A0 =A0 =A0 =A0 I would like to use MSRP for various applicati= ons such as IM/File
>>> =A0 =A0 =A0 =A0 Transfer/Screen sharing etc.
>>>
>>> =A0 =A0 =A0 =A0 What is the right way to identify, which MSRP = session belongs to
>>> =A0 =A0 =A0 =A0 which
>>> =A0 =A0 =A0 =A0 application?
>>>
>>> =A0 =A0 =A0 =A0 Looking at SDP in SIP INVITE all applications = could have same
>>> =A0 =A0 =A0 =A0 accept-types.
>>>
>>>
>>> =A0 =A0 AFAIK there are no specific standards for this, but th= ere are
>>> =A0 =A0 mechanisms you can use.
>>>
>>> =A0 =A0 E.g. you may use the a=3Dlabel attribute in sdp to ass= ociate an m-line
>>> =A0 =A0 with a label that is significant to an application. >>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
>>>
>>>
>>> =A0 =A0 _________________________________________________
>>> =A0 =A0 Simple mailing list
>>> =A0 =A0 S= imple@ietf.org <mailto:Simple@ietf.org>
>>> =A0 =A0 https://www.ietf.org/mailman/__listinfo/simple >>> =A0 =A0 <https://www.ietf.org/mailman/listinfo/simple&g= t;
>>>
>>>
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/simple
>>
>
>



------------------------------

Message: 3
Date: Wed, 10 Oct 2012 23:54:14 +0200
From: Adrian Georgescu <ag@ag-projects.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: simple@ietf.org
Subject: Re: [Simple] How to identify application type of MSRP
=A0 =A0 =A0 =A0 session.
Message-ID: <68D47588-AE1E-4336-B248-19C60934CF00@ag-proj= ects.com>
Content-Type: text/plain; charset=3Dus-ascii

Hi Paul,

I can see what you mean now. My understanding is that when interpreting the= SDP one could do something like:

1. If one does not understand an m line, it will not use it and any a lines= related to it
2. If one does understand an m line, will look necessarily at all a lines t= o figure out more details it understands and discard the ones it does not
Are these assumptions good to have interoperability with other SDP end-poin= ts?

Adrian

On Oct 10, 2012, at 11:22 PM, Paul Kyzivat wrote:

> On 10/10/12 4:53 PM, Adrian Georgescu wrote:
>>
>> On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote:
>>
>>> On 10/9/12 1:16 AM, Prasun Bheri wrote:
>>>> Thanks Paul and Adrian.
>>>> Does it not create inter-op issues?
>>>> What is the best approach to inter-opp with other msrp imp= lementations.
>>>
>>> Certainly it could.
>>>
>>
>> Can you please provide a real life example about how this can happ= en?
>>
>>
>>> The issue arises when you try to multiplex multiple "appl= ications" on a single AOR and, I gather, a single dialog. Standardizin= g such usage would seem to require a new higher level application framework= on top of sip. One such framework that comes to mind is IMS.
>>
>> I am using such single dialog scenario with MSRP and I am not able= to find any issue with it. Can you please expand what issue you are referr= ing to.
>
> Presumably you are encoding some "application identifier" so= mewhere, to distinguish between file transfer, screen sharing, etc. (E.g. y= ou could be using a=3Dlabel for this.)
> This will work fine as long as you have control over the top level &qu= ot;meta application" at each end, and thus can assure that both ends a= gree on how to interpret which application is intended.
>
> But it will stop working as soon as you bring in some different applic= ation at one end that doesn't understand your application identifiers.<= br> >
> So as long as you only want a proprietary solution there is no problem= . When you want to open it up you can either convince everybody else to fol= low your defacto proprietary "standard", or you can come back her= e and create a real standard.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Adrian
>>
>>>
>>> =A0 =A0 Thanks,
>>> =A0 =A0 Paul
>>>
>>>> Thanks & Regards
>>>> Prasun
>>>>
>>>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>
>>>> =A0 =A0On 10/8/12 3:11 AM, Prasun Bheri wrote:
>>>>
>>>> =A0 =A0 =A0 =A0Hello Group,
>>>> =A0 =A0 =A0 =A0I would like to use MSRP for various applic= ations such as IM/File
>>>> =A0 =A0 =A0 =A0Transfer/Screen sharing etc.
>>>>
>>>> =A0 =A0 =A0 =A0What is the right way to identify, which MS= RP session belongs to
>>>> =A0 =A0 =A0 =A0which
>>>> =A0 =A0 =A0 =A0application?
>>>>
>>>> =A0 =A0 =A0 =A0Looking at SDP in SIP INVITE all applicatio= ns could have same
>>>> =A0 =A0 =A0 =A0accept-types.
>>>>
>>>>
>>>> =A0 =A0AFAIK there are no specific standards for this, but= there are
>>>> =A0 =A0mechanisms you can use.
>>>>
>>>> =A0 =A0E.g. you may use the a=3Dlabel attribute in sdp to = associate an m-line
>>>> =A0 =A0with a label that is significant to an application.=
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 Paul
>>>>
>>>>
>>>> =A0 =A0_________________________________________________ >>>> =A0 =A0Simple mailing list
>>>> =A0 =A0Simple@ietf.org <mailto:Simple@ietf.org>
>>>> =A0 =A0https://www.ietf.org/mailman/__listinfo/simple
>>>> =A0 =A0<https://www.ietf.org/mailman/listinfo/simple>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> Simple@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/simple
>>>
>>
>>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>



------------------------------

Message: 4
Date: Wed, 10 Oct 2012 18:48:27 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: Adrian Georgescu <ag@ag-projects.com>
Cc: simple@ietf.org
Subject: Re: [Simple] How to identify application type of MSRP
=A0 =A0 =A0 =A0 session.
Message-ID: <5075FB3B.9070305@alum.mit.edu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

On 10/10/12 5:54 PM, Adrian Georgescu wrote:
> Hi Paul,
>
> I can see what you mean now. My understanding is that when interpretin= g the SDP one could do something like:
>
> 1. If one does not understand an m line, it will not use it and any a = lines related to it

Yes, that is what you are expected to do.
You would want to reject the m-line in the answer with a zero port.

> 2. If one does understand an m line, will look necessarily at all a li= nes to figure out more details it understands and discard the ones it does = not

Yes, this is also the expectation.

> Are these assumptions good to have interoperability with other SDP end= -points?

These are necessary but not sufficient for interoperability.

If one side puts in a proprietary a-line that must be understood to
properly process the stream, and the other side doesn't understand that=
line, ignores it, and then handles the stream in a different way, then
you still have an interoperability problem.

For instance, suppose you support both IM and screen sharing via MSRP.
For one session you only intend to use screen sharing. You send off an
offer with the MSRP m-lline and your indication that this is for screen
sharing. The other side ignores that and assumes that this msrp session
is for IM. It may then bring up a UI, and do all sorts of odd things.

You can probably avoid many problems just by which media types you
support on the msrp session. In fact, you might be able to solve most of the problems you are trying to deal with by having unique media types
for each of your applications. If not, then be careful.

If you aren't already aware of it, you should look at RFC 5547.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

> Adrian
>
> On Oct 10, 2012, at 11:22 PM, Paul Kyzivat wrote:
>
>> On 10/10/12 4:53 PM, Adrian Georgescu wrote:
>>>
>>> On Oct 9, 2012, at 5:24 PM, Paul Kyzivat wrote:
>>>
>>>> On 10/9/12 1:16 AM, Prasun Bheri wrote:
>>>>> Thanks Paul and Adrian.
>>>>> Does it not create inter-op issues?
>>>>> What is the best approach to inter-opp with other msrp= implementations.
>>>>
>>>> Certainly it could.
>>>>
>>>
>>> Can you please provide a real life example about how this can = happen?
>>>
>>>
>>>> The issue arises when you try to multiplex multiple "= applications" on a single AOR and, I gather, a single dialog. Standard= izing such usage would seem to require a new higher level application frame= work on top of sip. One such framework that comes to mind is IMS.
>>>
>>> I am using such single dialog scenario with MSRP and I am not = able to find any issue with it. Can you please expand what issue you are re= ferring to.
>>
>> Presumably you are encoding some "application identifier"= ; somewhere, to distinguish between file transfer, screen sharing, etc. (E.= g. you could be using a=3Dlabel for this.)
>> This will work fine as long as you have control over the top level= "meta application" at each end, and thus can assure that both en= ds agree on how to interpret which application is intended.
>>
>> But it will stop working as soon as you bring in some different ap= plication at one end that doesn't understand your application identifie= rs.
>>
>> So as long as you only want a proprietary solution there is no pro= blem. When you want to open it up you can either convince everybody else to= follow your defacto proprietary "standard", or you can come back= here and create a real standard.
>>
>> =A0 =A0 =A0Thanks,
>> =A0 =A0 =A0Paul
>>
>>> Adrian
>>>
>>>>
>>>> =A0 =A0Thanks,
>>>> =A0 =A0Paul
>>>>
>>>>> Thanks & Regards
>>>>> Prasun
>>>>>
>>>>> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu=
>>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>>
>>>>> =A0 =A0 On 10/8/12 3:11 AM, Prasun Bheri wrote:
>>>>>
>>>>> =A0 =A0 =A0 =A0 Hello Group,
>>>>> =A0 =A0 =A0 =A0 I would like to use MSRP for various a= pplications such as IM/File
>>>>> =A0 =A0 =A0 =A0 Transfer/Screen sharing etc.
>>>>>
>>>>> =A0 =A0 =A0 =A0 What is the right way to identify, whi= ch MSRP session belongs to
>>>>> =A0 =A0 =A0 =A0 which
>>>>> =A0 =A0 =A0 =A0 application?
>>>>>
>>>>> =A0 =A0 =A0 =A0 Looking at SDP in SIP INVITE all appli= cations could have same
>>>>> =A0 =A0 =A0 =A0 accept-types.
>>>>>
>>>>>
>>>>> =A0 =A0 AFAIK there are no specific standards for this= , but there are
>>>>> =A0 =A0 mechanisms you can use.
>>>>>
>>>>> =A0 =A0 E.g. you may use the a=3Dlabel attribute in sd= p to associate an m-line
>>>>> =A0 =A0 with a label that is significant to an applica= tion.
>>>>>
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
>>>>>
>>>>>
>>>>> =A0 =A0 ______________________________________________= ___
>>>>> =A0 =A0 Simple mailing list
>>>>> =A0 =A0 Simple@ietf.org <mailto:Simple@ietf.org>
>>>>> =A0 =A0 https://www.ietf.org/mailman/__listinfo/simp= le
>>>>> =A0 =A0 <https://www.ietf.org/mailman/listinfo/simp= le>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Simple mailing list
>>>> Simpl= e@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/simple
>>
>
>



------------------------------

_______________________________________________
Simple mailing list
Simple@ietf.org = https://www.ietf.org/mailman/listinfo/simple


End of Simple Digest, Vol 102, Issue 4
**************************************



--
With Regards=
Venu
93484 89945

--f46d04016a23efd24504cbd59da6-- From pkyzivat@alum.mit.edu Fri Oct 12 19:13:48 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF5121F8682 for ; Fri, 12 Oct 2012 19:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.525 X-Spam-Level: X-Spam-Status: No, score=0.525 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y98Cd1IMN3iI for ; Fri, 12 Oct 2012 19:13:47 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2E121F8681 for ; Fri, 12 Oct 2012 19:13:43 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id AARM1k0091ZXKqc53SDnkB; Sat, 13 Oct 2012 02:13:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id AS9q1k00r3ZTu2S3hS9qYp; Sat, 13 Oct 2012 02:09:51 +0000 Message-ID: <5078CCDE.8060609@alum.mit.edu> Date: Fri, 12 Oct 2012 22:07:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] How to identify the session X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 02:13:48 -0000 On 10/12/12 1:07 AM, venu Y wrote: > Hi, > > For file transfer we can uniquely identify the session, based on > 'a=file-selector' attribute. > > But for IM/MMS/Screen sharing... it's very unpredictable. > > Will it solve all the problem if instead of m=message, if we have > > m=im > m=screen-share > m=ftp IMO the above are all terrible ideas. > etc., > > or > > Using 'SIP Tags' in the OFFER will solve most of the issues.. but will > the order of the Tags and 'm=' line are in sync or not is the issue? This seems to be abusing layering. Why is there a problem at all with IM vs. screen sharing? For one thing, why would you use MSRP for screen sharing when there are numerous other protocols for that purpose??? Or do you really mean just "URL sharing"? In any case, could you not simply distinguish your screen images (or whatever they are) by media type? If you want to discuss this in more depth, please take some time to explain more about the overall architecture in which you are encountering this problem. Thanks, Paul > On 10/10/12 5:54 PM, Adrian Georgescu wrote: >> Hi Paul, >> >> I can see what you mean now. My understanding is that when interpreting the SDP one could do something like: >> >> 1. If one does not understand an m line, it will not use it and any a lines related to it > > Yes, that is what you are expected to do. > You would want to reject the m-line in the answer with a zero port. > >> 2. If one does understand an m line, will look necessarily at all a lines to figure out more details it understands and discard the ones it does not > > Yes, this is also the expectation. > >> Are these assumptions good to have interoperability with other SDP end-points? > > These are necessary but not sufficient for interoperability. > > If one side puts in a proprietary a-line that must be understood to > properly process the stream, and the other side doesn't understand that > line, ignores it, and then handles the stream in a different way, then > you still have an interoperability problem. > > For instance, suppose you support both IM and screen sharing via MSRP. > For one session you only intend to use screen sharing. You send off an > offer with the MSRP m-lline and your indication that this is for screen > sharing. The other side ignores that and assumes that this msrp session > is for IM. It may then bring up a UI, and do all sorts of odd things. > > You can probably avoid many problems just by which media types you > support on the msrp session. In fact, you might be able to solve most of > the problems you are trying to deal with by having unique media types > for each of your applications. If not, then be careful. > > If you aren't already aware of it, you should look at RFC 5547. > > Thanks, > Paul > > Thanks and Regards > -Venu > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ag@ag-projects.com Sat Oct 13 00:36:05 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5A321F85A2 for ; Sat, 13 Oct 2012 00:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM93h-OBCuPf for ; Sat, 13 Oct 2012 00:36:04 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB7521F853B for ; Sat, 13 Oct 2012 00:36:04 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 25C5BB0156; Sat, 13 Oct 2012 09:36:02 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id B1C07B0079; Sat, 13 Oct 2012 09:36:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <5078CCDE.8060609@alum.mit.edu> Date: Sat, 13 Oct 2012 09:36:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F340E77-9D4A-42C5-B347-7B6A551617BC@ag-projects.com> References: <5078CCDE.8060609@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] How to identify the session X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 07:36:05 -0000 > Why is there a problem at all with IM vs. screen sharing? > For one thing, why would you use MSRP for screen sharing when there = are numerous other protocols for that purpose??? MSRP can be used as a reliable transport to carry VNC protocol over it. = It works fine for end-points behind NAT by using a standard MSRP relay.=20= Adrian From oej@edvina.net Sat Oct 13 05:31:22 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDB221F84F5 for ; Sat, 13 Oct 2012 05:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90VcNu84dji1 for ; Sat, 13 Oct 2012 05:31:21 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id AD81D21F84EB for ; Sat, 13 Oct 2012 05:31:20 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 0E70E754A8A7; Sat, 13 Oct 2012 12:31:19 +0000 (UTC) From: Olle E. Johansson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Oct 2012 14:31:18 +0200 Message-Id: <19F2A5D1-6F49-4C06-8D96-911E1FE01541@edvina.net> To: simple@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 12:31:22 -0000 Hello, The SIMPLE workgrup chartar says: "The IETF has committed to=20 producing an interoperable standard for these services compliant to=20 the requirements for IM outlined in RFC 2779 (including the security=20 and privacy requirements there) and in the Common Profile for Instant=20 Messaging (CPIM) specification, developed within the IMPP working=20 group." =46rom testing various SIP clients with SIMPLE support, I think the IETF = is far away from this goal - the "interoperable" part. I see a mixture of Proprietary, OMA and IETF documents being used in = different ways for address books, presence and messaging. It is really = hard to get a simple red/green indication to work across clients using = XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is = just not working, without loosing a lot of data or creating crashes. I've tested BRIA, Zoiper, Blink, Jitsi on a Kamailio server. The results = scare me. Due to lack of a reference profile (or the existence too many = non-compatible reference profiles) it seems like developers have tried = to pick parts from various sources to create a solution that works for = networks with their own clients. Most of them follow some sort of = standard, but the result does not create any acceptable level of = interoperability. I think a base requirement is=20 * To be able to use the same buddy list with different clients without = loosing data * To be able to add friends to the buddy list and see their presence = states=20 I tihnk it's time for the WG to focus on interoperability tests, = document these short-comings and find ways to solve them. Otherwise we = will end up with a standard that only works in single-vendor = installations, which is not what I call "an interoperable standard" as = is the goal in the very first paragraph of the charter. If possible = invite the OMA to work with us and merge their documents with the IETF = standards. SIPit 30 in February could be a good place for a meeting and practical = test, dicussion about what's missing and possibly ways forwards. Reports = from such an event could be brought back to the IETF and be the basis = for work to reach some level of interoperability. Right now any multi-vendor solution based on SIMPLE is just not possible = to sell, because it won't work. This means that customers that want open = standards to be a guarantee of some level of vendor-independence won't = get what they want. We seriously need to fix this and get some running, interoperable code. = Or just conclude with the statement "SIMPLE failed, use xmpp instead". /O= From ag@ag-projects.com Sat Oct 13 06:23:57 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE78B21F84EC for ; Sat, 13 Oct 2012 06:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8YrsfeeoOLA for ; Sat, 13 Oct 2012 06:23:56 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 593EB21F84CE for ; Sat, 13 Oct 2012 06:23:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 2B5C2B019A; Sat, 13 Oct 2012 15:23:49 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 757D2B007B; Sat, 13 Oct 2012 15:23:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <19F2A5D1-6F49-4C06-8D96-911E1FE01541@edvina.net> Date: Sat, 13 Oct 2012 15:23:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19F2A5D1-6F49-4C06-8D96-911E1FE01541@edvina.net> To: Olle E. Johansson X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 13:23:57 -0000 Hi Olle, As a developer I can only concur with your assessment about the address = book. In my case, it took four years of development and 15,000 lines of = Python code, which is a high level language to assemble what one would = call a SIP SIMPLE presence enabled address-book application where each = contact is Presence aware. And of course there is no chance to have = other SIP clients work with the same model. I had to navigate and = connect the dots between countless disparate IETF documents like=20 = http://sipsimpleclient.com/projects/sipsimpleclient/wiki/SipFeatures#Prese= nce This complexity is beyond the reach of regular programmers that do not = live deep inside the SIP world. Who has years to waste for such a task? = A comparison with what other functionality, like setting up an audio = call or a multiparty conference requires in terms of effort, may give a = better image of the complexity for doing Presence with SIMPLE. http://sipsimpleclient.com/attachments/4405/SDK-LinesOfCode.png Complexity aside, on the good side I have discovered that: 1. IM, File Transfers and Multiparty chat work very well with MSRP, it = is straight forward to implement and is well interoperable 2. Inter-domain signaling and media works well even to XMPP domains for = both Presence, IM and multi-party chat What could be considered 'broken' is the lack of a standard model for = storing a generic and extensible address-book with presence-rules so = that several different clients can work together under the same account = without generating conflicting XCAP documents. I would not call SIMPLE a failure just because things are complex, as = they really are. XMPP is not a walk in the park either when you try to = do with it more that it was designed for. Just look at the forest of = incompatible options between same the clients of Google namely Talk, = Hangouts and Gmail interfaces, you can recognize same issues as with = SIP. Add voice into the equation and you recognize the same complexity = as with SIP trying to do Presence. What Google did well is to abstract = the address book for all of their own clients so that the problem is = well hidden. What could be done to make SIMPLE better and achieve its original goal, = would be to standardize an XCAP address book application with presence = rules built-in that can be interpreted in a single way by all = developers. Adrian On Oct 13, 2012, at 2:31 PM, Olle E. Johansson wrote: > Hello, >=20 > The SIMPLE workgrup chartar says: >=20 > "The IETF has committed to=20 > producing an interoperable standard for these services compliant to=20 > the requirements for IM outlined in RFC 2779 (including the security=20= > and privacy requirements there) and in the Common Profile for Instant=20= > Messaging (CPIM) specification, developed within the IMPP working=20 > group." >=20 > =46rom testing various SIP clients with SIMPLE support, I think the = IETF is far away from this goal - the "interoperable" part. >=20 > I see a mixture of Proprietary, OMA and IETF documents being used in = different ways for address books, presence and messaging. It is really = hard to get a simple red/green indication to work across clients using = XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is = just not working, without loosing a lot of data or creating crashes. >=20 > I've tested BRIA, Zoiper, Blink, Jitsi on a Kamailio server. The = results scare me. Due to lack of a reference profile (or the existence = too many non-compatible reference profiles) it seems like developers = have tried to pick parts from various sources to create a solution that = works for networks with their own clients. Most of them follow some sort = of standard, but the result does not create any acceptable level of = interoperability. >=20 > I think a base requirement is=20 >=20 > * To be able to use the same buddy list with different clients without = loosing data > * To be able to add friends to the buddy list and see their presence = states=20 >=20 > I tihnk it's time for the WG to focus on interoperability tests, = document these short-comings and find ways to solve them. Otherwise we = will end up with a standard that only works in single-vendor = installations, which is not what I call "an interoperable standard" as = is the goal in the very first paragraph of the charter. If possible = invite the OMA to work with us and merge their documents with the IETF = standards. >=20 > SIPit 30 in February could be a good place for a meeting and practical = test, dicussion about what's missing and possibly ways forwards. Reports = from such an event could be brought back to the IETF and be the basis = for work to reach some level of interoperability. >=20 > Right now any multi-vendor solution based on SIMPLE is just not = possible to sell, because it won't work. This means that customers that = want open standards to be a guarantee of some level of = vendor-independence won't get what they want. >=20 > We seriously need to fix this and get some running, interoperable = code. Or just conclude with the statement "SIMPLE failed, use xmpp = instead". >=20 > /O > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From oej@edvina.net Sat Oct 13 08:56:01 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0118021F8596 for ; Sat, 13 Oct 2012 08:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUMKD7t1RIW3 for ; Sat, 13 Oct 2012 08:55:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5D86721F8574 for ; Sat, 13 Oct 2012 08:55:58 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id CACF4754A8A7; Sat, 13 Oct 2012 15:55:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Sat, 13 Oct 2012 17:55:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19F2A5D1-6F49-4C06-8D96-911E1FE01541@edvina.net> To: Adrian Georgescu X-Mailer: Apple Mail (2.1499) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:56:01 -0000 13 okt 2012 kl. 15:23 skrev Adrian Georgescu : > Hi Olle, >=20 > As a developer I can only concur with your assessment about the = address book. In my case, it took four years of development and 15,000 = lines of Python code, which is a high level language to assemble what = one would call a SIP SIMPLE presence enabled address-book application = where each contact is Presence aware. And of course there is no chance = to have other SIP clients work with the same model. I had to navigate = and connect the dots between countless disparate IETF documents like=20 >=20 > = http://sipsimpleclient.com/projects/sipsimpleclient/wiki/SipFeatures#Prese= nce >=20 > This complexity is beyond the reach of regular programmers that do not = live deep inside the SIP world. Who has years to waste for such a task? = A comparison with what other functionality, like setting up an audio = call or a multiparty conference requires in terms of effort, may give a = better image of the complexity for doing Presence with SIMPLE. >=20 > http://sipsimpleclient.com/attachments/4405/SDK-LinesOfCode.png >=20 > Complexity aside, on the good side I have discovered that: >=20 > 1. IM, File Transfers and Multiparty chat work very well with MSRP, it = is straight forward to implement and is well interoperable > 2. Inter-domain signaling and media works well even to XMPP domains = for both Presence, IM and multi-party chat >=20 > What could be considered 'broken' is the lack of a standard model for = storing a generic and extensible address-book with presence-rules so = that several different clients can work together under the same account = without generating conflicting XCAP documents. >=20 > I would not call SIMPLE a failure just because things are complex, as = they really are. XMPP is not a walk in the park either when you try to = do with it more that it was designed for. Just look at the forest of = incompatible options between same the clients of Google namely Talk, = Hangouts and Gmail interfaces, you can recognize same issues as with = SIP. Add voice into the equation and you recognize the same complexity = as with SIP trying to do Presence. What Google did well is to abstract = the address book for all of their own clients so that the problem is = well hidden. >=20 > What could be done to make SIMPLE better and achieve its original = goal, would be to standardize an XCAP address book application with = presence rules built-in that can be interpreted in a single way by all = developers. >=20 Adrian, Thanks for the feedback. You have done a good job with your = documentation both for the SIPsimpleClient and OpenXCAP, which help me = in my wanderings. Also good to hear that some things work well. I stumbled on the basics. Thanks for agreeing that we need to focus on interoperability, = especially in the buddy list/Address book section. /O > Adrian >=20 > On Oct 13, 2012, at 2:31 PM, Olle E. Johansson wrote: >=20 >> Hello, >>=20 >> The SIMPLE workgrup chartar says: >>=20 >> "The IETF has committed to=20 >> producing an interoperable standard for these services compliant to=20= >> the requirements for IM outlined in RFC 2779 (including the security=20= >> and privacy requirements there) and in the Common Profile for Instant=20= >> Messaging (CPIM) specification, developed within the IMPP working=20 >> group." >>=20 >> =46rom testing various SIP clients with SIMPLE support, I think the = IETF is far away from this goal - the "interoperable" part. >>=20 >> I see a mixture of Proprietary, OMA and IETF documents being used in = different ways for address books, presence and messaging. It is really = hard to get a simple red/green indication to work across clients using = XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is = just not working, without loosing a lot of data or creating crashes. >>=20 >> I've tested BRIA, Zoiper, Blink, Jitsi on a Kamailio server. The = results scare me. Due to lack of a reference profile (or the existence = too many non-compatible reference profiles) it seems like developers = have tried to pick parts from various sources to create a solution that = works for networks with their own clients. Most of them follow some sort = of standard, but the result does not create any acceptable level of = interoperability. >>=20 >> I think a base requirement is=20 >>=20 >> * To be able to use the same buddy list with different clients = without loosing data >> * To be able to add friends to the buddy list and see their presence = states=20 >>=20 >> I tihnk it's time for the WG to focus on interoperability tests, = document these short-comings and find ways to solve them. Otherwise we = will end up with a standard that only works in single-vendor = installations, which is not what I call "an interoperable standard" as = is the goal in the very first paragraph of the charter. If possible = invite the OMA to work with us and merge their documents with the IETF = standards. >>=20 >> SIPit 30 in February could be a good place for a meeting and = practical test, dicussion about what's missing and possibly ways = forwards. Reports from such an event could be brought back to the IETF = and be the basis for work to reach some level of interoperability. >>=20 >> Right now any multi-vendor solution based on SIMPLE is just not = possible to sell, because it won't work. This means that customers that = want open standards to be a guarantee of some level of = vendor-independence won't get what they want. >>=20 >> We seriously need to fix this and get some running, interoperable = code. Or just conclude with the statement "SIMPLE failed, use xmpp = instead". >>=20 >> /O >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 From hannes.tschofenig@gmx.net Sat Oct 13 10:29:26 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CB421F84F2 for ; Sat, 13 Oct 2012 10:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZUgfUf12+vm for ; Sat, 13 Oct 2012 10:29:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 41BE121F84F0 for ; Sat, 13 Oct 2012 10:29:24 -0700 (PDT) Received: (qmail invoked by alias); 13 Oct 2012 17:29:23 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.112]) [88.115.216.191] by mail.gmx.net (mp004) with SMTP; 13 Oct 2012 19:29:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/PAPsvrjvP7MtywquEnJLMCHEM4K0TZNuhjgL5Tp 0yNg1oVpRZFoka Date: Sat, 13 Oct 2012 20:29:16 +0300 Message-ID: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> From: Hannes Tschofenig To: Adrian Georgescu MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Y-GMX-Trusted: 0 Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 17:29:26 -0000 SSBoYXZlIGJlZW4gYXNrZWQgbWFueSB0aW1lcyBhYm91dCB0aGUgZGVwbG95bWVudCBzdGF0dXMg b2YgU0lNUExFIGluIHRoZSBjb250ZXh0IG9mIGVtZXJnZW5jeSBzZXJ2aWNlcy4gSSBjb3VsZG4n dCBwcm92aWRlIGEgZ29vZCBhbnN3ZXIuCgpIZXJlIGlzIHRoZSBpc3N1ZSB0aGF0IHRoZSBlbWVy Z2VuY3kgc2VydmljZXMgZm9sa3MgYXJlIGZhY2luZzogdGhlIGVtZXJnZW5jeSBzZXJ2aWNlcyBh dXRob3JpdGllcyBhcmUgY3VycmVudGx5IGluIHRoZSBwcm9ncmVzcyB0byBzd2l0Y2ggdG8gSVAt YmFzZWQgZW1lcmdlbmN5IHNlcnZpY2VzIG5ldHdvcmtzICh3aGljaCBpbmNsdWRlcyBJUC1iYXNl ZCBQU0FQcykuCgpPdXIgc3Rvcnkgc28gZmFyIChJRVRGLCBFRU5BLCBORU5BLCBldGMuKSB3YXMg dGhhdCB0aGV5IGhhdmUgdG8gaW1wbGVtZW50IGEgU0lQLW9ubHkgYmFzZWQgc29sdXRpb24gYW5k IGV2ZXJ5b25lIGVsc2Ugd2hvIHdhbnRzIHRvIHNlbmQgZW1lcmdlbmN5IGNhbGxzIHRvIHRoZW0g aGFzIHRvIHBlcmZvcm0gdGhlIHRyYW5zbGF0aW9uIGZyb20gd2hhdGV2ZXIgcHJvdG9jb2wgdGhl eSBhcmUgdXNpbmcuIApOb3RlIHRoYXQgZW1lcmdlbmN5IGNhbGxzIGhlcmUgcmVmZXJzIHRvIGEg bXVsdGktbWVkaWEgY29tbXVuaWNhdGlvbiAodm9pY2UsIHRleHQsIHJlYWwtdGltZSB0ZXh0LCB2 aWRlbywgZGF0YSkuCgpXaGlsZSB0aGUgc2l0dWF0aW9uIGlzIHByZXR0eSBnb29kIGZvciB2b2lj ZSBmb3IgdGV4dCBiYXNlZCBjb21tdW5pY2F0aW9uIGl0IGlzIGZhciBmcm9tIGNsZWFyIHdoYXQg dGhlIFNJTVBMRSBkZXBsb3ltZW50IHN0YXR1cyBpcy4gCgpUaGUgaW50ZXJ3b3JraW5nIGJldHdl ZW4gU0lQLWJhc2VkIHZvaWNlIGFuZCBYTVBQIHRleHQgbWVzc2FnaW5nIGlzIG5vdCBzdGFuZGFy ZGl6ZWQgZWl0aGVyLiBEb2VzIGFueW9uZSBoYXZlIGFueSBpbmZvcm1hdGlvbj8KClNvLCB3aGF0 IHN0b3J5IHNob3VsZCBJIHRlbGwgdGhlc2UgZW1lcmdlbmN5IHNlcnZpY2VzIGZvbGtzPwpIZWxw IGFwcHJlY2lhdGVkLiAKCkNpYW8KSGFubmVzCgpQUzogTHVja2lseSB0aGUgYWRkcmVzcyBib29r IGlzc3VlcyBpcyBub3QgYXBwbGljYWJsZSB0byBlbWVyZ2VuY3kgc2VydmljZXMuIAoKU2VudCBm cm9tIG15IEFTVVMgUGFkCgpBZHJpYW4gR2Vvcmdlc2N1IDxhZ0BhZy1wcm9qZWN0cy5jb20+IHdy b3RlOgoKPkhpIE9sbGUsCj4KPkFzIGEgZGV2ZWxvcGVyIEkgY2FuIG9ubHkgY29uY3VyIHdpdGgg eW91ciBhc3Nlc3NtZW50IGFib3V0IHRoZSBhZGRyZXNzIGJvb2suIEluIG15IGNhc2UsIGl0IHRv b2sgZm91ciB5ZWFycyBvZiBkZXZlbG9wbWVudCBhbmQgMTUsMDAwIGxpbmVzIG9mIFB5dGhvbiBj b2RlLCB3aGljaCBpcyBhIGhpZ2ggbGV2ZWwgbGFuZ3VhZ2UgdG8gYXNzZW1ibGUgd2hhdCBvbmUg d291bGQgY2FsbCBhIFNJUCBTSU1QTEUgcHJlc2VuY2UgZW5hYmxlZCBhZGRyZXNzLWJvb2sgYXBw bGljYXRpb24gd2hlcmUgZWFjaCBjb250YWN0IGlzIFByZXNlbmNlIGF3YXJlLiBBbmQgb2YgY291 cnNlIHRoZXJlIGlzIG5vIGNoYW5jZSB0byBoYXZlIG90aGVyIFNJUCBjbGllbnRzIHdvcmsgd2l0 aCB0aGUgc2FtZSBtb2RlbC4gSSBoYWQgdG8gbmF2aWdhdGUgYW5kIGNvbm5lY3QgdGhlIGRvdHMg YmV0d2VlbiBjb3VudGxlc3MgZGlzcGFyYXRlIElFVEYgZG9jdW1lbnRzIGxpa2UgCj4KPmh0dHA6 Ly9zaXBzaW1wbGVjbGllbnQuY29tL3Byb2plY3RzL3NpcHNpbXBsZWNsaWVudC93aWtpL1NpcEZl YXR1cmVzI1ByZXNlbmNlCj4KPlRoaXMgY29tcGxleGl0eSBpcyBiZXlvbmQgdGhlIHJlYWNoIG9m IHJlZ3VsYXIgcHJvZ3JhbW1lcnMgdGhhdCBkbyBub3QgbGl2ZSBkZWVwIGluc2lkZSB0aGUgU0lQ IHdvcmxkLiBXaG8gaGFzIHllYXJzIHRvIHdhc3RlIGZvciBzdWNoIGEgdGFzaz8gQSBjb21wYXJp c29uIHdpdGggd2hhdCBvdGhlciBmdW5jdGlvbmFsaXR5LCBsaWtlIHNldHRpbmcgdXAgYW4gYXVk aW8gY2FsbCBvciBhIG11bHRpcGFydHkgY29uZmVyZW5jZSByZXF1aXJlcyBpbiB0ZXJtcyBvZiBl ZmZvcnQsIG1heSBnaXZlIGEgYmV0dGVyIGltYWdlIG9mIHRoZSBjb21wbGV4aXR5IGZvciBkb2lu ZyBQcmVzZW5jZSB3aXRoIFNJTVBMRS4KPgo+aHR0cDovL3NpcHNpbXBsZWNsaWVudC5jb20vYXR0 YWNobWVudHMvNDQwNS9TREstTGluZXNPZkNvZGUucG5nCj4KPkNvbXBsZXhpdHkgYXNpZGUsIG9u IHRoZSBnb29kIHNpZGUgSSBoYXZlIGRpc2NvdmVyZWQgdGhhdDoKPgo+MS4gSU0sIEZpbGUgVHJh bnNmZXJzIGFuZCBNdWx0aXBhcnR5IGNoYXQgd29yayB2ZXJ5IHdlbGwgd2l0aCBNU1JQLCBpdCBp cyBzdHJhaWdodCBmb3J3YXJkIHRvIGltcGxlbWVudCBhbmQgaXMgd2VsbCBpbnRlcm9wZXJhYmxl Cj4yLiBJbnRlci1kb21haW4gc2lnbmFsaW5nIGFuZCBtZWRpYSB3b3JrcyB3ZWxsIGV2ZW4gdG8g WE1QUCBkb21haW5zIGZvciBib3RoIFByZXNlbmNlLCBJTSBhbmQgbXVsdGktcGFydHkgY2hhdAo+ Cj5XaGF0IGNvdWxkIGJlIGNvbnNpZGVyZWQgJ2Jyb2tlbicgaXMgdGhlIGxhY2sgb2YgYSBzdGFu ZGFyZCBtb2RlbCBmb3Igc3RvcmluZyBhIGdlbmVyaWMgYW5kIGV4dGVuc2libGUgYWRkcmVzcy1i b29rIHdpdGggcHJlc2VuY2UtcnVsZXMgc28gdGhhdCBzZXZlcmFsIGRpZmZlcmVudCBjbGllbnRz IGNhbiB3b3JrIHRvZ2V0aGVyIHVuZGVyIHRoZSBzYW1lIGFjY291bnQgd2l0aG91dCBnZW5lcmF0 aW5nIGNvbmZsaWN0aW5nIFhDQVAgZG9jdW1lbnRzLgo+Cj5JIHdvdWxkIG5vdCBjYWxsIFNJTVBM RSBhIGZhaWx1cmUganVzdCBiZWNhdXNlIHRoaW5ncyBhcmUgY29tcGxleCwgYXMgdGhleSByZWFs bHkgYXJlLiBYTVBQIGlzIG5vdCBhIHdhbGsgaW4gdGhlIHBhcmsgZWl0aGVyIHdoZW4geW91IHRy eSB0byBkbyB3aXRoIGl0IG1vcmUgdGhhdCBpdCB3YXMgZGVzaWduZWQgZm9yLiAgSnVzdCBsb29r IGF0IHRoZSBmb3Jlc3Qgb2YgaW5jb21wYXRpYmxlIG9wdGlvbnMgYmV0d2VlbiBzYW1lIHRoZSBj bGllbnRzIG9mIEdvb2dsZSBuYW1lbHkgVGFsaywgSGFuZ291dHMgYW5kIEdtYWlsIGludGVyZmFj ZXMsIHlvdSBjYW4gcmVjb2duaXplIHNhbWUgaXNzdWVzIGFzIHdpdGggU0lQLiBBZGQgdm9pY2Ug aW50byB0aGUgZXF1YXRpb24gYW5kIHlvdSByZWNvZ25pemUgdGhlIHNhbWUgY29tcGxleGl0eSBh cyB3aXRoIFNJUCB0cnlpbmcgdG8gZG8gUHJlc2VuY2UuIFdoYXQgR29vZ2xlIGRpZCB3ZWxsIGlz IHRvIGFic3RyYWN0IHRoZSBhZGRyZXNzIGJvb2sgZm9yIGFsbCBvZiB0aGVpciBvd24gY2xpZW50 cyBzbyB0aGF0IHRoZSBwcm9ibGVtIGlzIHdlbGwgaGlkZGVuLgo+Cj5XaGF0IGNvdWxkIGJlIGRv bmUgdG8gbWFrZSBTSU1QTEUgYmV0dGVyIGFuZCBhY2hpZXZlIGl0cyBvcmlnaW5hbCBnb2FsLCB3 b3VsZCBiZSB0byBzdGFuZGFyZGl6ZSBhbiBYQ0FQIGFkZHJlc3MgYm9vayBhcHBsaWNhdGlvbiB3 aXRoIHByZXNlbmNlIHJ1bGVzIGJ1aWx0LWluIHRoYXQgY2FuIGJlIGludGVycHJldGVkIGluIGEg c2luZ2xlIHdheSBieSBhbGwgZGV2ZWxvcGVycy4KPgo+QWRyaWFuCj4KPk9uIE9jdCAxMywgMjAx MiwgYXQgMjozMSBQTSwgT2xsZSBFLiBKb2hhbnNzb24gd3JvdGU6Cj4KPj4gSGVsbG8sCj4+IAo+ PiBUaGUgU0lNUExFIHdvcmtncnVwIGNoYXJ0YXIgc2F5czoKPj4gCj4+ICJUaGUgSUVURiBoYXMg Y29tbWl0dGVkIHRvIAo+PiBwcm9kdWNpbmcgYW4gaW50ZXJvcGVyYWJsZSBzdGFuZGFyZCBmb3Ig dGhlc2Ugc2VydmljZXMgY29tcGxpYW50IHRvIAo+PiB0aGUgcmVxdWlyZW1lbnRzIGZvciBJTSBv dXRsaW5lZCBpbiBSRkMgMjc3OSAoaW5jbHVkaW5nIHRoZSBzZWN1cml0eSAKPj4gYW5kIHByaXZh Y3kgcmVxdWlyZW1lbnRzIHRoZXJlKSBhbmQgaW4gdGhlIENvbW1vbiBQcm9maWxlIGZvciBJbnN0 YW50IAo+PiBNZXNzYWdpbmcgKENQSU0pIHNwZWNpZmljYXRpb24sIGRldmVsb3BlZCB3aXRoaW4g dGhlIElNUFAgd29ya2luZyAKPj4gZ3JvdXAuIgo+PiAKPj4gRnJvbSB0ZXN0aW5nIHZhcmlvdXMg U0lQIGNsaWVudHMgd2l0aCBTSU1QTEUgc3VwcG9ydCwgSSB0aGluayB0aGUgSUVURiBpcyBmYXIg YXdheSBmcm9tIHRoaXMgZ29hbCAtIHRoZSAiaW50ZXJvcGVyYWJsZSIgcGFydC4KPj4gCj4+IEkg c2VlIGEgbWl4dHVyZSBvZiBQcm9wcmlldGFyeSwgT01BIGFuZCBJRVRGIGRvY3VtZW50cyBiZWlu ZyB1c2VkIGluIGRpZmZlcmVudCB3YXlzIGZvciBhZGRyZXNzIGJvb2tzLCBwcmVzZW5jZSBhbmQg bWVzc2FnaW5nLiBJdCBpcyByZWFsbHkgaGFyZCB0byBnZXQgYSBzaW1wbGUgcmVkL2dyZWVuIGlu ZGljYXRpb24gIHRvIHdvcmsgYWNyb3NzIGNsaWVudHMgdXNpbmcgWENBUCBhbmQgUFVCTElTSC9T VUJTQ1JJQkUvTk9USUZZLiBTaGFyaW5nIGJ1ZGR5IGxpc3RzIGFjcm9zcyBjbGllbnRzIGlzIGp1 c3Qgbm90IHdvcmtpbmcsIHdpdGhvdXQgbG9vc2luZyBhIGxvdCBvZiBkYXRhIG9yIGNyZWF0aW5n IGNyYXNoZXMuCj4+IAo+PiBJJ3ZlIHRlc3RlZCBCUklBLCBab2lwZXIsIEJsaW5rLCBKaXRzaSBv biBhIEthbWFpbGlvIHNlcnZlci4gVGhlIHJlc3VsdHMgc2NhcmUgbWUuIER1ZSB0byBsYWNrIG9m IGEgcmVmZXJlbmNlIHByb2ZpbGUgKG9yIHRoZSBleGlzdGVuY2UgdG9vIG1hbnkgbm9uLWNvbXBh dGlibGUgcmVmZXJlbmNlIHByb2ZpbGVzKSAgaXQgc2VlbXMgbGlrZSBkZXZlbG9wZXJzIGhhdmUg dHJpZWQgdG8gcGljayBwYXJ0cyBmcm9tIHZhcmlvdXMgc291cmNlcyB0byBjcmVhdGUgYSBzb2x1 dGlvbiB0aGF0IHdvcmtzIGZvciBuZXR3b3JrcyB3aXRoIHRoZWlyIG93biBjbGllbnRzLiBNb3N0 IG9mIHRoZW0gZm9sbG93IHNvbWUgc29ydCBvZiBzdGFuZGFyZCwgYnV0IHRoZSByZXN1bHQgZG9l cyBub3QgY3JlYXRlIGFueSBhY2NlcHRhYmxlIGxldmVsIG9mIGludGVyb3BlcmFiaWxpdHkuCj4+ IAo+PiBJIHRoaW5rIGEgYmFzZSByZXF1aXJlbWVudCBpcyAKPj4gCj4+ICogVG8gYmUgYWJsZSB0 byB1c2UgdGhlIHNhbWUgYnVkZHkgbGlzdCB3aXRoIGRpZmZlcmVudCBjbGllbnRzIHdpdGhvdXQg bG9vc2luZyBkYXRhCj4+ICogVG8gYmUgYWJsZSB0byBhZGQgZnJpZW5kcyB0byB0aGUgYnVkZHkg bGlzdCBhbmQgc2VlIHRoZWlyIHByZXNlbmNlIHN0YXRlcyAKPj4gCj4+IEkgdGlobmsgaXQncyB0 aW1lIGZvciB0aGUgV0cgdG8gZm9jdXMgb24gaW50ZXJvcGVyYWJpbGl0eSB0ZXN0cywgZG9jdW1l bnQgdGhlc2Ugc2hvcnQtY29taW5ncyBhbmQgZmluZCB3YXlzIHRvIHNvbHZlIHRoZW0uIE90aGVy d2lzZSB3ZSB3aWxsIGVuZCB1cCB3aXRoIGEgc3RhbmRhcmQgdGhhdCBvbmx5IHdvcmtzIGluIHNp bmdsZS12ZW5kb3IgaW5zdGFsbGF0aW9ucywgd2hpY2ggaXMgbm90IHdoYXQgSSBjYWxsICJhbiBp bnRlcm9wZXJhYmxlIHN0YW5kYXJkIiBhcyBpcyB0aGUgZ29hbCBpbiB0aGUgdmVyeSBmaXJzdCBw YXJhZ3JhcGggb2YgdGhlIGNoYXJ0ZXIuIElmIHBvc3NpYmxlIGludml0ZSB0aGUgT01BIHRvIHdv cmsgd2l0aCB1cyBhbmQgbWVyZ2UgdGhlaXIgZG9jdW1lbnRzIHdpdGggdGhlIElFVEYgc3RhbmRh cmRzLgo+PiAKPj4gU0lQaXQgMzAgaW4gRmVicnVhcnkgY291bGQgYmUgYSBnb29kIHBsYWNlIGZv ciBhIG1lZXRpbmcgYW5kIHByYWN0aWNhbCB0ZXN0LCBkaWN1c3Npb24gYWJvdXQgd2hhdCdzIG1p c3NpbmcgYW5kIHBvc3NpYmx5IHdheXMgZm9yd2FyZHMuIFJlcG9ydHMgZnJvbSBzdWNoIGFuIGV2 ZW50IGNvdWxkIGJlIGJyb3VnaHQgYmFjayB0byB0aGUgSUVURiBhbmQgYmUgdGhlIGJhc2lzIGZv ciB3b3JrIHRvIHJlYWNoIHNvbWUgbGV2ZWwgb2YgaW50ZXJvcGVyYWJpbGl0eS4KPj4gCj4+IFJp Z2h0IG5vdyBhbnkgbXVsdGktdmVuZG9yIHNvbHV0aW9uIGJhc2VkIG9uIFNJTVBMRSBpcyBqdXN0 IG5vdCBwb3NzaWJsZSB0byBzZWxsLCBiZWNhdXNlIGl0IHdvbid0IHdvcmsuIFRoaXMgbWVhbnMg dGhhdCBjdXN0b21lcnMgdGhhdCB3YW50IG9wZW4gc3RhbmRhcmRzIHRvIGJlIGEgZ3VhcmFudGVl IG9mIHNvbWUgbGV2ZWwgb2YgdmVuZG9yLWluZGVwZW5kZW5jZSB3b24ndCBnZXQgd2hhdCB0aGV5 IHdhbnQuCj4+IAo+PiBXZSBzZXJpb3VzbHkgbmVlZCB0byBmaXggdGhpcyBhbmQgZ2V0IHNvbWUg cnVubmluZywgaW50ZXJvcGVyYWJsZSBjb2RlLiBPciBqdXN0IGNvbmNsdWRlIHdpdGggdGhlIHN0 YXRlbWVudCAiU0lNUExFIGZhaWxlZCwgdXNlIHhtcHAgaW5zdGVhZCIuCj4+IAo+PiAvTwo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBTaW1wbGUg bWFpbGluZyBsaXN0Cj4+IFNpbXBsZUBpZXRmLm9yZwo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpbXBsZQo+PiAKPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPlNpbXBsZSBtYWlsaW5nIGxpc3QKPlNpbXBsZUBpZXRmLm9y Zwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUK From oej@edvina.net Sat Oct 13 11:48:04 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DA521F84BF for ; Sat, 13 Oct 2012 11:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgU5tWmj0IbB for ; Sat, 13 Oct 2012 11:48:03 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D811821F847B for ; Sat, 13 Oct 2012 11:47:54 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id D8B3E754A8A7; Sat, 13 Oct 2012 18:47:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> Date: Sat, 13 Oct 2012 20:47:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:48:04 -0000 13 okt 2012 kl. 19:29 skrev Hannes Tschofenig = : > I have been asked many times about the deployment status of SIMPLE in = the context of emergency services. I couldn't provide a good answer. >=20 > Here is the issue that the emergency services folks are facing: the = emergency services authorities are currently in the progress to switch = to IP-based emergency services networks (which includes IP-based PSAPs). >=20 > Our story so far (IETF, EENA, NENA, etc.) was that they have to = implement a SIP-only based solution and everyone else who wants to send = emergency calls to them has to perform the translation from whatever = protocol they are using.=20 > Note that emergency calls here refers to a multi-media communication = (voice, text, real-time text, video, data). >=20 > While the situation is pretty good for voice for text based = communication it is far from clear what the SIMPLE deployment status is.=20= >=20 > The interworking between SIP-based voice and XMPP text messaging is = not standardized either. Does anyone have any information? It's going to be hard to translate. We had a workshop on that years ago. = The architecture is very different. There are efforts, recently in sylkserver, you can play with. I have some presentation on = slideshare as "oej" covering the differences as we saw them then. If you add xcap and server-side buddy lists it's even harder. >=20 > So, what story should I tell these emergency services folks? Good question. Basic SIP MESSAGE doesn't involve much of SIMPLE, but it = has it drawbacks. MSRP, as Adrian said, works well.=20 /O > Help appreciated.=20 >=20 > Ciao > Hannes >=20 > PS: Luckily the address book issues is not applicable to emergency = services.=20 >=20 > Sent from my ASUS Pad >=20 > Adrian Georgescu wrote: >=20 >> Hi Olle, >>=20 >> As a developer I can only concur with your assessment about the = address book. In my case, it took four years of development and 15,000 = lines of Python code, which is a high level language to assemble what = one would call a SIP SIMPLE presence enabled address-book application = where each contact is Presence aware. And of course there is no chance = to have other SIP clients work with the same model. I had to navigate = and connect the dots between countless disparate IETF documents like=20 >>=20 >> = http://sipsimpleclient.com/projects/sipsimpleclient/wiki/SipFeatures#Prese= nce >>=20 >> This complexity is beyond the reach of regular programmers that do = not live deep inside the SIP world. Who has years to waste for such a = task? A comparison with what other functionality, like setting up an = audio call or a multiparty conference requires in terms of effort, may = give a better image of the complexity for doing Presence with SIMPLE. >>=20 >> http://sipsimpleclient.com/attachments/4405/SDK-LinesOfCode.png >>=20 >> Complexity aside, on the good side I have discovered that: >>=20 >> 1. IM, File Transfers and Multiparty chat work very well with MSRP, = it is straight forward to implement and is well interoperable >> 2. Inter-domain signaling and media works well even to XMPP domains = for both Presence, IM and multi-party chat >>=20 >> What could be considered 'broken' is the lack of a standard model for = storing a generic and extensible address-book with presence-rules so = that several different clients can work together under the same account = without generating conflicting XCAP documents. >>=20 >> I would not call SIMPLE a failure just because things are complex, as = they really are. XMPP is not a walk in the park either when you try to = do with it more that it was designed for. Just look at the forest of = incompatible options between same the clients of Google namely Talk, = Hangouts and Gmail interfaces, you can recognize same issues as with = SIP. Add voice into the equation and you recognize the same complexity = as with SIP trying to do Presence. What Google did well is to abstract = the address book for all of their own clients so that the problem is = well hidden. >>=20 >> What could be done to make SIMPLE better and achieve its original = goal, would be to standardize an XCAP address book application with = presence rules built-in that can be interpreted in a single way by all = developers. >>=20 >> Adrian >>=20 >> On Oct 13, 2012, at 2:31 PM, Olle E. Johansson wrote: >>=20 >>> Hello, >>>=20 >>> The SIMPLE workgrup chartar says: >>>=20 >>> "The IETF has committed to=20 >>> producing an interoperable standard for these services compliant to=20= >>> the requirements for IM outlined in RFC 2779 (including the security=20= >>> and privacy requirements there) and in the Common Profile for = Instant=20 >>> Messaging (CPIM) specification, developed within the IMPP working=20 >>> group." >>>=20 >>> =46rom testing various SIP clients with SIMPLE support, I think the = IETF is far away from this goal - the "interoperable" part. >>>=20 >>> I see a mixture of Proprietary, OMA and IETF documents being used in = different ways for address books, presence and messaging. It is really = hard to get a simple red/green indication to work across clients using = XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is = just not working, without loosing a lot of data or creating crashes. >>>=20 >>> I've tested BRIA, Zoiper, Blink, Jitsi on a Kamailio server. The = results scare me. Due to lack of a reference profile (or the existence = too many non-compatible reference profiles) it seems like developers = have tried to pick parts from various sources to create a solution that = works for networks with their own clients. Most of them follow some sort = of standard, but the result does not create any acceptable level of = interoperability. >>>=20 >>> I think a base requirement is=20 >>>=20 >>> * To be able to use the same buddy list with different clients = without loosing data >>> * To be able to add friends to the buddy list and see their presence = states=20 >>>=20 >>> I tihnk it's time for the WG to focus on interoperability tests, = document these short-comings and find ways to solve them. Otherwise we = will end up with a standard that only works in single-vendor = installations, which is not what I call "an interoperable standard" as = is the goal in the very first paragraph of the charter. If possible = invite the OMA to work with us and merge their documents with the IETF = standards. >>>=20 >>> SIPit 30 in February could be a good place for a meeting and = practical test, dicussion about what's missing and possibly ways = forwards. Reports from such an event could be brought back to the IETF = and be the basis for work to reach some level of interoperability. >>>=20 >>> Right now any multi-vendor solution based on SIMPLE is just not = possible to sell, because it won't work. This means that customers that = want open standards to be a guarantee of some level of = vendor-independence won't get what they want. >>>=20 >>> We seriously need to fix this and get some running, interoperable = code. Or just conclude with the statement "SIMPLE failed, use xmpp = instead". >>>=20 >>> /O >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple From stpeter@stpeter.im Sat Oct 13 17:12:41 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCE821F847C for ; Sat, 13 Oct 2012 17:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps8bEHXXO13E for ; Sat, 13 Oct 2012 17:12:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2B721F8471 for ; Sat, 13 Oct 2012 17:12:40 -0700 (PDT) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 637524011B; Sat, 13 Oct 2012 18:15:05 -0600 (MDT) Message-ID: <507A0378.2090807@stpeter.im> Date: Sat, 13 Oct 2012 18:12:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> In-Reply-To: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 00:12:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/12 11:29 AM, Hannes Tschofenig wrote: > The interworking between SIP-based voice and XMPP text messaging > is not standardized either. Does anyone have any information? It's funny you should ask. Emil Ivov, Enrico Marocco, and I have been working on that a bit here: http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/ I am also planning to soon resurrect the entire series of documents I had underway several years ago, draft-saintandre-sip-xmpp-* (core, IM, presence, etc.). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB6A3gACgkQNL8k5A2w/vzh+wCg4lajuJTMDRwd0gBZNXaPk18S Ls4AoIaiLEL1q75NM09qISSDHUdUhSD4 =NDw2 -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Sat Oct 13 23:29:53 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA521F84B2 for ; Sat, 13 Oct 2012 23:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ19SPCW37BP for ; Sat, 13 Oct 2012 23:29:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1D5D521F84A2 for ; Sat, 13 Oct 2012 23:29:51 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2012 06:29:50 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp032) with SMTP; 14 Oct 2012 08:29:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19kLK981SNkRNLrsRLmQgR/3Mc2Dsl4xQwOXQD9mQ S9pFHIyEW+9Yxc Message-ID: <507A5BDA.7090207@gmx.net> Date: Sun, 14 Oct 2012 09:29:46 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> <507A0378.2090807@stpeter.im> In-Reply-To: <507A0378.2090807@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 06:29:53 -0000 Hi Peter, I am aware of this work and the effort that happened before it but for some reason I got the impression that there was very low energy behind it. My impression was that the telcommunication operator community don't seem to care about it there is still the believe that a pure SIP-based approach will lead to success (and XMPP is not on their radar at all) and the XMPP community does not seem care about SIP. Is this understanding wrong? Ciao Hannes On 10/14/2012 03:12 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/13/12 11:29 AM, Hannes Tschofenig wrote: > >> The interworking between SIP-based voice and XMPP text messaging >> is not standardized either. Does anyone have any information? > > It's funny you should ask. Emil Ivov, Enrico Marocco, and I have been > working on that a bit here: > > http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/ > > I am also planning to soon resurrect the entire series of documents I > had underway several years ago, draft-saintandre-sip-xmpp-* (core, IM, > presence, etc.). > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlB6A3gACgkQNL8k5A2w/vzh+wCg4lajuJTMDRwd0gBZNXaPk18S > Ls4AoIaiLEL1q75NM09qISSDHUdUhSD4 > =NDw2 > -----END PGP SIGNATURE----- > From oej@edvina.net Sun Oct 14 00:33:54 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B4F21F84CD for ; Sun, 14 Oct 2012 00:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26kmnKVrfcI6 for ; Sun, 14 Oct 2012 00:33:53 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B6A5621F84B5 for ; Sun, 14 Oct 2012 00:33:51 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C672A754A8A7; Sun, 14 Oct 2012 07:33:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <507A5BDA.7090207@gmx.net> Date: Sun, 14 Oct 2012 09:33:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E2FF868-B070-4180-8017-D504317D2999@edvina.net> References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> <507A0378.2090807@stpeter.im> <507A5BDA.7090207@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 07:33:54 -0000 14 okt 2012 kl. 08:29 skrev Hannes Tschofenig = : > Hi Peter, >=20 > I am aware of this work and the effort that happened before it but for = some reason I got the impression that there was very low energy behind = it. There are many clients around that support both XMPP and SIP and there = used to be very few clients supporting SIMPLE, so the requirements for = interoperability on protocol level has not been huge.=20 Today we have more clients supporting SIMPLE, so there may be a new = level of interest. >=20 > My impression was that the telcommunication operator community don't = seem to care about it there is still the believe that a pure SIP-based = approach will lead to success (and XMPP is not on their radar at all) = and the XMPP community does not seem care about SIP. Which may not be a bad thing. Being sarcastic, the interest in SIP from = the operator community has given SIP a lot of ISDN features that XMPP = luckily doesn't have... ;-) The architecture is fundamentally different. In XMPP, the server = forwards XMPP messages called stanzas, but doesn't keep or aggregate any = status. In SIMPLE, the server aggregates presence states and we can ask = the server about an entitys current status and change it. This lead to = some interoperability challenges, like the SIP subscribe query with = expires:0. A jabber server can't answer that. >=20 > Is this understanding wrong? The interesting thing with XMPP is that it powers a lot of applications = that you don't see as classical IM or presence, with buddy lists. The = XMPP developer meetings are full with cool developers presenting really = interesting projects powered by XMPP. So you might have applications in = the telecom world that build on XMPP, but very few people know about it.=20= XMPP did one thing right that SIP did not. There are two RFCs - one for = the core protocol and one for the first application - IM and presence. = SIP could have benefited from one RFC for the core protocol and a = separate for "telephony".=20 /O >=20 > Ciao > Hannes >=20 > On 10/14/2012 03:12 AM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 10/13/12 11:29 AM, Hannes Tschofenig wrote: >>=20 >>> The interworking between SIP-based voice and XMPP text messaging >>> is not standardized either. Does anyone have any information? >>=20 >> It's funny you should ask. Emil Ivov, Enrico Marocco, and I have been >> working on that a bit here: >>=20 >> http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/ >>=20 >> I am also planning to soon resurrect the entire series of documents I >> had underway several years ago, draft-saintandre-sip-xmpp-* (core, = IM, >> presence, etc.). >>=20 >> Peter >>=20 >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>=20 >> iEYEARECAAYFAlB6A3gACgkQNL8k5A2w/vzh+wCg4lajuJTMDRwd0gBZNXaPk18S >> Ls4AoIaiLEL1q75NM09qISSDHUdUhSD4 >> =3DNDw2 >> -----END PGP SIGNATURE----- >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From hannes.tschofenig@gmx.net Sun Oct 14 04:38:02 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2F21F8484 for ; Sun, 14 Oct 2012 04:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btKLi41mGrgQ for ; Sun, 14 Oct 2012 04:38:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8795721F847D for ; Sun, 14 Oct 2012 04:38:01 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2012 11:38:00 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp070) with SMTP; 14 Oct 2012 13:38:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/zPXBM18zzvR0RQAUxgLbsK7r3p+Bso6D2XyaDN0 QbYApXpN60L6q6 Message-ID: <507AA415.3010105@gmx.net> Date: Sun, 14 Oct 2012 14:37:57 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Olle E. Johansson" References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> <507A0378.2090807@stpeter.im> <507A5BDA.7090207@gmx.net> <6E2FF868-B070-4180-8017-D504317D2999@edvina.net> In-Reply-To: <6E2FF868-B070-4180-8017-D504317D2999@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 11:38:02 -0000 On 10/14/2012 10:33 AM, Olle E. Johansson wrote: > Today we have more clients supporting SIMPLE, so there may be a new level of interest. Could you give me a few examples? From oej@edvina.net Sun Oct 14 06:11:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CEA21F8469 for ; Sun, 14 Oct 2012 06:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgKxAxvqYf6A for ; Sun, 14 Oct 2012 06:11:36 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC421F8464 for ; Sun, 14 Oct 2012 06:11:35 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 1A8A9754A8A7; Sun, 14 Oct 2012 13:11:31 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <507AA415.3010105@gmx.net> Date: Sun, 14 Oct 2012 15:11:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AFE3F42-18AB-4C09-9357-4DA5984442DA@edvina.net> References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> <507A0378.2090807@stpeter.im> <507A5BDA.7090207@gmx.net> <6E2FF868-B070-4180-8017-D504317D2999@edvina.net> <507AA415.3010105@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 13:11:36 -0000 14 okt 2012 kl. 13:37 skrev Hannes Tschofenig = : > On 10/14/2012 10:33 AM, Olle E. Johansson wrote: >> Today we have more clients supporting SIMPLE, so there may be a new = level of interest. >=20 > Could you give me a few examples? I've tested Zoiper, Bria, Jitsi and Blink (for Mac). On the server side you have Kamailio (which I used), OpenSIPS as well as = a separate server for Xcap called OpenXCAP. /O= From pkyzivat@alum.mit.edu Sun Oct 14 11:08:03 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C1221F849D for ; Sun, 14 Oct 2012 11:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5Y9qSoXjWO5 for ; Sun, 14 Oct 2012 11:08:02 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 138B621F849C for ; Sun, 14 Oct 2012 11:08:01 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta10.westchester.pa.mail.comcast.net with comcast id B67i1k0021GhbT85A685Ls; Sun, 14 Oct 2012 18:08:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id B63W1k00S3ZTu2S3T63W0k; Sun, 14 Oct 2012 18:03:31 +0000 Message-ID: <507AFE52.4080705@alum.mit.edu> Date: Sun, 14 Oct 2012 14:02:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 18:08:03 -0000 On 10/13/12 2:47 PM, Olle E. Johansson wrote: > > 13 okt 2012 kl. 19:29 skrev Hannes Tschofenig : > >> I have been asked many times about the deployment status of SIMPLE in the context of emergency services. I couldn't provide a good answer. >> >> Here is the issue that the emergency services folks are facing: the emergency services authorities are currently in the progress to switch to IP-based emergency services networks (which includes IP-based PSAPs). >> >> Our story so far (IETF, EENA, NENA, etc.) was that they have to implement a SIP-only based solution and everyone else who wants to send emergency calls to them has to perform the translation from whatever protocol they are using. >> Note that emergency calls here refers to a multi-media communication (voice, text, real-time text, video, data). >> >> While the situation is pretty good for voice for text based communication it is far from clear what the SIMPLE deployment status is. >> >> The interworking between SIP-based voice and XMPP text messaging is not standardized either. Does anyone have any information? > It's going to be hard to translate. We had a workshop on that years ago. The architecture is very different. There are efforts, > recently in sylkserver, you can play with. I have some presentation on slideshare as "oej" covering the differences as we saw them then. > If you add xcap and server-side buddy lists it's even harder. ISTM that while there is difficulty in mapping presence between xmpp and sip, there is much less difficulty in mapping IM messages between xmpp and msrp. The latter is the part that is needed for emergency services. Thanks, Paul >> So, what story should I tell these emergency services folks? > Good question. Basic SIP MESSAGE doesn't involve much of SIMPLE, but it has it drawbacks. MSRP, as Adrian said, works well. > > /O > >> Help appreciated. >> >> Ciao >> Hannes >> >> PS: Luckily the address book issues is not applicable to emergency services. >> >> Sent from my ASUS Pad >> >> Adrian Georgescu wrote: >> >>> Hi Olle, >>> >>> As a developer I can only concur with your assessment about the address book. In my case, it took four years of development and 15,000 lines of Python code, which is a high level language to assemble what one would call a SIP SIMPLE presence enabled address-book application where each contact is Presence aware. And of course there is no chance to have other SIP clients work with the same model. I had to navigate and connect the dots between countless disparate IETF documents like >>> >>> http://sipsimpleclient.com/projects/sipsimpleclient/wiki/SipFeatures#Presence >>> >>> This complexity is beyond the reach of regular programmers that do not live deep inside the SIP world. Who has years to waste for such a task? A comparison with what other functionality, like setting up an audio call or a multiparty conference requires in terms of effort, may give a better image of the complexity for doing Presence with SIMPLE. >>> >>> http://sipsimpleclient.com/attachments/4405/SDK-LinesOfCode.png >>> >>> Complexity aside, on the good side I have discovered that: >>> >>> 1. IM, File Transfers and Multiparty chat work very well with MSRP, it is straight forward to implement and is well interoperable >>> 2. Inter-domain signaling and media works well even to XMPP domains for both Presence, IM and multi-party chat >>> >>> What could be considered 'broken' is the lack of a standard model for storing a generic and extensible address-book with presence-rules so that several different clients can work together under the same account without generating conflicting XCAP documents. >>> >>> I would not call SIMPLE a failure just because things are complex, as they really are. XMPP is not a walk in the park either when you try to do with it more that it was designed for. Just look at the forest of incompatible options between same the clients of Google namely Talk, Hangouts and Gmail interfaces, you can recognize same issues as with SIP. Add voice into the equation and you recognize the same complexity as with SIP trying to do Presence. What Google did well is to abstract the address book for all of their own clients so that the problem is well hidden. >>> >>> What could be done to make SIMPLE better and achieve its original goal, would be to standardize an XCAP address book application with presence rules built-in that can be interpreted in a single way by all developers. >>> >>> Adrian >>> >>> On Oct 13, 2012, at 2:31 PM, Olle E. Johansson wrote: >>> >>>> Hello, >>>> >>>> The SIMPLE workgrup chartar says: >>>> >>>> "The IETF has committed to >>>> producing an interoperable standard for these services compliant to >>>> the requirements for IM outlined in RFC 2779 (including the security >>>> and privacy requirements there) and in the Common Profile for Instant >>>> Messaging (CPIM) specification, developed within the IMPP working >>>> group." >>>> >>>> From testing various SIP clients with SIMPLE support, I think the IETF is far away from this goal - the "interoperable" part. >>>> >>>> I see a mixture of Proprietary, OMA and IETF documents being used in different ways for address books, presence and messaging. It is really hard to get a simple red/green indication to work across clients using XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is just not working, without loosing a lot of data or creating crashes. >>>> >>>> I've tested BRIA, Zoiper, Blink, Jitsi on a Kamailio server. The results scare me. Due to lack of a reference profile (or the existence too many non-compatible reference profiles) it seems like developers have tried to pick parts from various sources to create a solution that works for networks with their own clients. Most of them follow some sort of standard, but the result does not create any acceptable level of interoperability. >>>> >>>> I think a base requirement is >>>> >>>> * To be able to use the same buddy list with different clients without loosing data >>>> * To be able to add friends to the buddy list and see their presence states >>>> >>>> I tihnk it's time for the WG to focus on interoperability tests, document these short-comings and find ways to solve them. Otherwise we will end up with a standard that only works in single-vendor installations, which is not what I call "an interoperable standard" as is the goal in the very first paragraph of the charter. If possible invite the OMA to work with us and merge their documents with the IETF standards. >>>> >>>> SIPit 30 in February could be a good place for a meeting and practical test, dicussion about what's missing and possibly ways forwards. Reports from such an event could be brought back to the IETF and be the basis for work to reach some level of interoperability. >>>> >>>> Right now any multi-vendor solution based on SIMPLE is just not possible to sell, because it won't work. This means that customers that want open standards to be a guarantee of some level of vendor-independence won't get what they want. >>>> >>>> We seriously need to fix this and get some running, interoperable code. Or just conclude with the statement "SIMPLE failed, use xmpp instead". >>>> >>>> /O >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From b_mccolgan@hotmail.com Sun Oct 14 14:16:48 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4805E21F84F1 for ; Sun, 14 Oct 2012 14:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdXAQusLDlyu for ; Sun, 14 Oct 2012 14:16:47 -0700 (PDT) Received: from bay0-omc4-s4.bay0.hotmail.com (bay0-omc4-s4.bay0.hotmail.com [65.54.190.206]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0321F84EF for ; Sun, 14 Oct 2012 14:16:47 -0700 (PDT) Received: from BAY170-W11 ([65.54.190.201]) by bay0-omc4-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Oct 2012 14:16:46 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c942dbee-c379-429c-989f-78c06b1711b4_" X-Originating-IP: [76.75.135.13] From: Brian McColgan To: , Date: Sun, 14 Oct 2012 17:16:46 -0400 Importance: Normal In-Reply-To: <19F2A5D1-6F49-4C06-8D96-911E1FE01541@edvina.net> References: <19F2A5D1-6F49-4C06-8D96-911E1FE01541@edvina.net> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2012 21:16:46.0858 (UTC) FILETIME=[37C89EA0:01CDAA51] Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 21:16:48 -0000 --_c942dbee-c379-429c-989f-78c06b1711b4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is most folks get fixated on the protocols=2C and quickly lose = sight of the fact that the PIDF on which SIP/SIMPLE relies on is a data mod= el. That data model=2C while extremely flexible=2C leaves alot to be desir= ed in terms of consistent (and hence repeatable) results. Unfortunately=2C= there has not been sufficient work on defining the manner in which the dat= a model is navigated. This gets further complicated when RPIDis factored in= =2C and subsequently OMA Presence/SIMPLE is layered on top of these buildin= g blocks. OMA did a good thing when they developed the Presence Access Layer=2C howev= er lack of adoption of this 'add on service enabler' has hampered what woul= d be a truly helpful=2C simpler interface for presence aware services. Alo= t of the requirements/shortcomings you (Olle) have highlighted (below) are = addressed in the Presence Access Layer - including the ability to establish= a presence profile which reference repeatable indicators=2C for any presen= ce aware service. A presence (watcher) is then established based on this p= rofile - a presence context. BR/Brian. > From: oej@edvina.net > Date: Sat=2C 13 Oct 2012 14:31:18 +0200 > To: simple@ietf.org > Subject: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an= IETF failure? >=20 > Hello=2C >=20 > The SIMPLE workgrup chartar says: >=20 > "The IETF has committed to=20 > producing an interoperable standard for these services compliant to=20 > the requirements for IM outlined in RFC 2779 (including the security=20 > and privacy requirements there) and in the Common Profile for Instant=20 > Messaging (CPIM) specification=2C developed within the IMPP working=20 > group." >=20 > From testing various SIP clients with SIMPLE support=2C I think the IETF = is far away from this goal - the "interoperable" part. >=20 > I see a mixture of Proprietary=2C OMA and IETF documents being used in di= fferent ways for address books=2C presence and messaging. It is really hard= to get a simple red/green indication to work across clients using XCAP an= d PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is just not = working=2C without loosing a lot of data or creating crashes. >=20 > I've tested BRIA=2C Zoiper=2C Blink=2C Jitsi on a Kamailio server. The re= sults scare me. Due to lack of a reference profile (or the existence too ma= ny non-compatible reference profiles) it seems like developers have tried = to pick parts from various sources to create a solution that works for netw= orks with their own clients. Most of them follow some sort of standard=2C b= ut the result does not create any acceptable level of interoperability. >=20 > I think a base requirement is=20 >=20 > * To be able to use the same buddy list with different clients without lo= osing data > * To be able to add friends to the buddy list and see their presence stat= es=20 >=20 > I tihnk it's time for the WG to focus on interoperability tests=2C docume= nt these short-comings and find ways to solve them. Otherwise we will end u= p with a standard that only works in single-vendor installations=2C which i= s not what I call "an interoperable standard" as is the goal in the very fi= rst paragraph of the charter. If possible invite the OMA to work with us an= d merge their documents with the IETF standards. >=20 > SIPit 30 in February could be a good place for a meeting and practical te= st=2C dicussion about what's missing and possibly ways forwards. Reports fr= om such an event could be brought back to the IETF and be the basis for wor= k to reach some level of interoperability. >=20 > Right now any multi-vendor solution based on SIMPLE is just not possible = to sell=2C because it won't work. This means that customers that want open = standards to be a guarantee of some level of vendor-independence won't get = what they want. >=20 > We seriously need to fix this and get some running=2C interoperable code.= Or just conclude with the statement "SIMPLE failed=2C use xmpp instead". >=20 > /O > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple = --_c942dbee-c379-429c-989f-78c06b1711b4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The problem is most folks get fi= xated on the protocols=2C and quickly lose sight of the fact that the PIDF = on which SIP/SIMPLE relies on is a data model. =3B =3BThat data mod= el=2C while extremely flexible=2C leaves alot to be desired in terms of con= sistent (and hence repeatable) results. =3B =3BUnfortunately=2C the= re has not been sufficient work on defining the manner in which the data mo= del is navigated. This gets further complicated when RPIDis factored in=2C = and subsequently OMA Presence/SIMPLE is layered on top of these building bl= ocks.

OMA did a good thing when they developed the Presence Access L= ayer=2C however lack of adoption of this '=3Badd on service enabler'= =3B has hampered what would be a truly helpful=2C simpler interface for pre= sence aware services. =3B =3BAlot of the requirements/shortcomings = you (Olle) have highlighted (below) are addressed in the Presence Access La= yer - including the ability to establish a presence profile which reference= repeatable indicators=2C for any presence aware service. =3B =3BA = presence (watcher) is then established based on this profile - a presence c= ontext.

BR/Brian.

> From:=3B oej@=3Bedvina.net
> Dat= e:=3B Sat=2C 13 Oct 2012 14:=3B31:=3B18 +=3B0200
> To:=3B= simple@=3Bietf.org
> Subject:=3B [=3BSimple]=3B Controversi= al:=3B Have SIMPLE reached is goal?=3B Or is it an =3BIETF failure&= #63=3B
>
> Hello=2C
>
> The SIMPLE workgrup chartar says:= =3B
>
> "=3BThe IETF has committed to
> producing an interope= rable standard for these services compliant to
> the requirements for I= M outlined in RFC 2779 (=3Bincluding the security
> and privacy requ= irements there)=3B and in the Common Profile for Instant
> Messaging= (=3BCPIM)=3B specification=2C developed within the IMPP working
= > group."=3B
>
> From testing various SIP clients with SIMPLE sup= port=2C I think the IETF is far away from this goal - the "=3Binteropera= ble"=3B part.
>
> I see a mixture of Proprietary=2C OMA and IETF = documents being used in different ways for address books=2C presence and me= ssaging. It is really hard to get a simple red/green indication to work ac= ross clients using XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists a= cross clients is just not working=2C without loosing a lot of data or creat= ing crashes.
>
> I'=3Bve tested BRIA=2C Zoiper=2C Blink=2C Jitsi = on a Kamailio server. The results scare me. Due to lack of a reference prof= ile (=3Bor the existence too many non-compatible reference profiles)= =3B it seems like developers have tried to pick parts from various sources= to create a solution that works for networks with their own clients. Most = of them follow some sort of standard=2C but the result does not create any = acceptable level of interoperability.
>
> I think a base requirement= is
>
> *=3B To be able to use the same buddy list with differen= t clients without loosing data
> *=3B To be able to add friends to th= e buddy list and see their presence states
>
> I tihnk it'=3Bs t= ime for the WG to focus on interoperability tests=2C document these short-c= omings and find ways to solve them. Otherwise we will end up with a standar= d that only works in single-vendor installations=2C which is not what I cal= l "=3Ban interoperable standard"=3B as is the goal in the very first = paragraph of the charter. If possible invite the OMA to work with us and me= rge their documents with the IETF standards.
>
> SIPit 30 in Februar= y could be a good place for a meeting and practical test=2C dicussion about= what'=3Bs missing and possibly ways forwards. Reports from such an even= t could be brought back to the IETF and be the basis for work to reach some= level of interoperability.
>
> Right now any multi-vendor solution = based on SIMPLE is just not possible to sell=2C because it won'=3Bt work= . This means that customers that want open standards to be a guarantee of s= ome level of vendor-independence won'=3Bt get what they want.
>
>= We seriously need to fix this and get some running=2C interoperable code. = Or just conclude with the statement "=3BSIMPLE failed=2C use xmpp instea= d"=3B.
>
> /O
> ______________________________________________= _
> Simple mailing list
> Simple@=3Bietf.org
> https:=3B//ww= w.ietf.org/mailman/listinfo/simple
= --_c942dbee-c379-429c-989f-78c06b1711b4_-- From ag@ag-projects.com Sun Oct 14 14:42:08 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8721F84F6 for ; Sun, 14 Oct 2012 14:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A1pnCGS88yM for ; Sun, 14 Oct 2012 14:42:08 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94321F8487 for ; Sun, 14 Oct 2012 14:42:07 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 2511FB0156; Sun, 14 Oct 2012 23:42:06 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id C1733B00E3; Sun, 14 Oct 2012 23:42:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2B87A5A7-3664-4113-B8EF-9C9EDDB52221" From: Adrian Georgescu In-Reply-To: Date: Sun, 14 Oct 2012 23:42:02 +0200 Message-Id: <714E8653-7DB1-4095-A6AE-87ECF7B58EFC@ag-projects.com> References: <19F2A5D1-6F49-4C06-8D96-911E1FE01541@edvina.net> To: Brian McColgan X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 21:42:09 -0000 --Apple-Mail=_2B87A5A7-3664-4113-B8EF-9C9EDDB52221 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 PIDF is not the issue in my opinion. The issue that breaks interoperability is related to how to define a = buddy lists with presence rules that works across multiple devices from = multiple vendors. Adrian On Oct 14, 2012, at 11:16 PM, Brian McColgan wrote: > The problem is most folks get fixated on the protocols, and quickly = lose sight of the fact that the PIDF on which SIP/SIMPLE relies on is a = data model. That data model, while extremely flexible, leaves alot to = be desired in terms of consistent (and hence repeatable) results. = Unfortunately, there has not been sufficient work on defining the manner = in which the data model is navigated. This gets further complicated when = RPIDis factored in, and subsequently OMA Presence/SIMPLE is layered on = top of these building blocks. >=20 > OMA did a good thing when they developed the Presence Access Layer, = however lack of adoption of this 'add on service enabler' has hampered = what would be a truly helpful, simpler interface for presence aware = services. Alot of the requirements/shortcomings you (Olle) have = highlighted (below) are addressed in the Presence Access Layer - = including the ability to establish a presence profile which reference = repeatable indicators, for any presence aware service. A presence = (watcher) is then established based on this profile - a presence = context. >=20 > BR/Brian. >=20 > > From: oej@edvina.net > > Date: Sat, 13 Oct 2012 14:31:18 +0200 > > To: simple@ietf.org > > Subject: [Simple] Controversial: Have SIMPLE reached is goal? Or is = it an IETF failure? > >=20 > > Hello, > >=20 > > The SIMPLE workgrup chartar says: > >=20 > > "The IETF has committed to=20 > > producing an interoperable standard for these services compliant to=20= > > the requirements for IM outlined in RFC 2779 (including the security=20= > > and privacy requirements there) and in the Common Profile for = Instant=20 > > Messaging (CPIM) specification, developed within the IMPP working=20 > > group." > >=20 > > =46rom testing various SIP clients with SIMPLE support, I think the = IETF is far away from this goal - the "interoperable" part. > >=20 > > I see a mixture of Proprietary, OMA and IETF documents being used in = different ways for address books, presence and messaging. It is really = hard to get a simple red/green indication to work across clients using = XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is = just not working, without loosing a lot of data or creating crashes. > >=20 > > I've tested BRIA, Zoiper, Blink, Jitsi on a Kamailio server. The = results scare me. Due to lack of a reference profile (or the existence = too many non-compatible reference profiles) it seems like developers = have tried to pick parts from various sources to create a solution that = works for networks with their own clients. Most of them follow some sort = of standard, but the result does not create any acceptable level of = interoperability. > >=20 > > I think a base requirement is=20 > >=20 > > * To be able to use the same buddy list with different clients = without loosing data > > * To be able to add friends to the buddy list and see their presence = states=20 > >=20 > > I tihnk it's time for the WG to focus on interoperability tests, = document these short-comings and find ways to solve them. Otherwise we = will end up with a standard that only works in single-vendor = installations, which is not what I call "an interoperable standard" as = is the goal in the very first paragraph of the charter. If possible = invite the OMA to work with us and merge their documents with the IETF = standards. > >=20 > > SIPit 30 in February could be a good place for a meeting and = practical test, dicussion about what's missing and possibly ways = forwards. Reports from such an event could be brought back to the IETF = and be the basis for work to reach some level of interoperability. > >=20 > > Right now any multi-vendor solution based on SIMPLE is just not = possible to sell, because it won't work. This means that customers that = want open standards to be a guarantee of some level of = vendor-independence won't get what they want. > >=20 > > We seriously need to fix this and get some running, interoperable = code. Or just conclude with the statement "SIMPLE failed, use xmpp = instead". > >=20 > > /O > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_2B87A5A7-3664-4113-B8EF-9C9EDDB52221 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
PIDF is not the issue in my = opinion.

The issue that breaks interoperability = is related to how to define a buddy lists with presence rules that works = across multiple devices from multiple = vendors.

Adrian

On Oct 14, 2012, at 11:16 PM, Brian McColgan wrote:

The problem is most folks get fixated on the = protocols, and quickly lose sight of the fact that the PIDF on which = SIP/SIMPLE relies on is a data model.  That data model, while = extremely flexible, leaves alot to be desired in terms of consistent = (and hence repeatable) results.  Unfortunately, there has not = been sufficient work on defining the manner in which the data model is = navigated. This gets further complicated when RPIDis factored in, and = subsequently OMA Presence/SIMPLE is layered on top of these building = blocks.

OMA did a good thing when they developed the Presence = Access Layer, however lack of adoption of this 'add on service enabler' = has hampered what would be a truly helpful, simpler interface for = presence aware services.  Alot of the = requirements/shortcomings you (Olle) have highlighted (below) are = addressed in the Presence Access Layer - including the ability to = establish a presence profile which reference repeatable indicators, for = any presence aware service.  A presence (watcher) is then = established based on this profile - a presence = context.

BR/Brian.

> From: oej@edvina.net
> Date: Sat, 13 Oct 2012 = 14:31:18 +0200
> To: simple@ietf.org
> Subject: [Simple] = Controversial: Have SIMPLE reached is goal? Or is it an IETF = failure?
> 
> Hello,
> 
> The SIMPLE workgrup chartar = says:
> 
> "The IETF has committed = to 
> producing an interoperable = standard for these services compliant to 
> the requirements for IM = outlined in RFC 2779 (including the security 
> and privacy requirements = there) and in the Common Profile for Instant 
> Messaging (CPIM) = specification, developed within the IMPP working 
> group."
> 
> =46rom testing various SIP = clients with SIMPLE support, I think the IETF is far away from this goal = - the "interoperable" part.
> 
> I see a mixture of = Proprietary, OMA and IETF documents being used in different ways for = address books, presence and messaging. It is really hard to get a simple = red/green indication to work across clients using XCAP and = PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is just not = working, without loosing a lot of data or creating crashes.
> 
> I've tested BRIA, Zoiper, = Blink, Jitsi on a Kamailio server. The results scare me. Due to lack of = a reference profile (or the existence too many non-compatible reference = profiles) it seems like developers have tried to pick parts from various = sources to create a solution that works for networks with their own = clients. Most of them follow some sort of standard, but the result does = not create any acceptable level of interoperability.
> 
> I think a base requirement = is 
> 
> * To be able to use the = same buddy list with different clients without loosing data
> * To be able to add friends = to the buddy list and see their presence states 
> 
> I tihnk it's time for the = WG to focus on interoperability tests, document these short-comings and = find ways to solve them. Otherwise we will end up with a standard that = only works in single-vendor installations, which is not what I call "an = interoperable standard" as is the goal in the very first paragraph of = the charter. If possible invite the OMA to work with us and merge their = documents with the IETF standards.
> 
> SIPit 30 in February could = be a good place for a meeting and practical test, dicussion about what's = missing and possibly ways forwards. Reports from such an event could be = brought back to the IETF and be the basis for work to reach some level = of interoperability.
> 
> Right now any multi-vendor = solution based on SIMPLE is just not possible to sell, because it won't = work. This means that customers that want open standards to be a = guarantee of some level of vendor-independence won't get what they = want.
> 
> We seriously need to fix = this and get some running, interoperable code. Or just conclude with the = statement "SIMPLE failed, use xmpp instead".
> 
> /O
> _____________________________= __________________
> Simple mailing = list
> Simple@ietf.org
> https://www.ietf.org/mailman/= listinfo/simple
_______________________________________________Simple mailing list
Simple@ietf.org
https://www.ietf.org= /mailman/listinfo/simple

= --Apple-Mail=_2B87A5A7-3664-4113-B8EF-9C9EDDB52221-- From ibc@aliax.net Mon Oct 15 03:39:59 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3A221F85A2 for ; Mon, 15 Oct 2012 03:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZl3uc3+-FAP for ; Mon, 15 Oct 2012 03:39:58 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF84B21F86CF for ; Mon, 15 Oct 2012 03:39:57 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3708880lam.31 for ; Mon, 15 Oct 2012 03:39:56 -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=sMdoGdZ+kFAVYb9jxXP7CX3Eh8FZ1V8JWhdhEGkGpko=; b=TYEPVIyTL9pHc/6+JYDC/00jhSj0khCGzhXlfDlSeQcwg/36+M15hX6wJjGPnJXcfa 5pHvSWv6wv0ul/8QVYilAotIleOmba+Y6J1OdJy89fsPmxNQP0S5+BDAdaIcpK1tNzBX 2BQJzIVVOFFKE/dVzM6KT6oWs1lKYDBASTWewY4hfXU8rrJIYmZdSDdwq7hHPLvOmFfA WhaMIYGhvjFvPAOQUrHXwknrYGlaHb8eS/l0At+oSGplgFajrybM3LyBcKbi2zv9Np73 3abZ0+T2wxGaw4gkCAR0ka2twUAgHWXYJvJzlGLd1R+RUEIQ6DcNiX4/ie4Nke+AVCdL 7yew== Received: by 10.152.105.103 with SMTP id gl7mr9572898lab.10.1350297596677; Mon, 15 Oct 2012 03:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.26.37 with HTTP; Mon, 15 Oct 2012 03:39:36 -0700 (PDT) In-Reply-To: <8AFE3F42-18AB-4C09-9357-4DA5984442DA@edvina.net> References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> <507A0378.2090807@stpeter.im> <507A5BDA.7090207@gmx.net> <6E2FF868-B070-4180-8017-D504317D2999@edvina.net> <507AA415.3010105@gmx.net> <8AFE3F42-18AB-4C09-9357-4DA5984442DA@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 15 Oct 2012 12:39:36 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkXYh8+CpdwqumOdrMoc3peyFVj5EvTGAemM8lReFT2x5c/+HzZhxOGEbW2uSwjD8t0Awmn Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 10:39:59 -0000 2012/10/14 Olle E. Johansson : > I've tested Zoiper, Bria, Jitsi and Blink (for Mac). > > On the server side you have Kamailio (which I used), OpenSIPS as well as = a separate server for Xcap called OpenXCAP. We should assume that 99% of SIMPLE implementations in the "open internet" are buggy, but IMHO it makes sense taking into account the complexity of the so many RFC's required for implementing a not complete presence/permissions/buddylist platform. The only good implementation (AFAIK) is Blink and its related server stuff (after YEARS of work) and, finally, it can only interoperate *well* with other Blink instances. So we have really complex specs that use partial SIP subscription to partial XML documents distributed in HTTP/XCAP servers, with XML resource-list documents that can just store "display name" and "uri", and include *absolute* references (including HTTP schema, domain, path...) to other XML nodes within the *same* document (but they usually point to other XML documents in the same or *any* other HTTP/XCAP server). This is just annoying, nobody in the Internet world can deploy something like this and make it to properly work, but in the other side we have tons of XMPP clients and servers which interoperate very well when sharing buddy-list and permissions. What was the purpose of IETF in SIMPLE presence stuff? The specs are so ambiguous and complex that nobody knows what exactly to implement. We need a "Presence Profile" for the OPEN Internet ("implement exactly this and this and this in this exact way"), and not just for telcos private networks (OMA/RCS...). Let's be honest: the only environments in which SIMPLE presence stuff can "work" is within private networks or walled wardens, with their own clients and servers managing XML documents that will never be readable/writable by end users or open SIP clients. Then we have OMA that adds a layer on top of IETF SIMPLE specs (so we have stuf like "my-oma-PoC-users"...), and we also have RCS which is an extra layer on top of OMA specs... (=C2=BF?=C2=BF?=C2=BF?=C2=BF?). XMPP = presence is defined in a single RFC and implementors make it to work without problems (at least basic presence and buddylist/authorization rules management). Why is SIMPLE-presence so difficult? Some keys: - A "presence" NOTIFY can contain multiple tuples for the same AoR, but there is no way to correlate them between different instances of the same AoR (GRUU??). - A PIDF body can contain exotic information (state basic: "close", contact: "mailto:mysecretary@ietf.org"). It is just imposssible to render it in client side. - The pres-rules document (according to OMA specs) contains HTTP absolute links to the resource-list document, but the resource-list document also contains HTTP links to XML nodes within the same document. This is really annoying, what would happen if the service provider has to change its domain or upgrades from HTTP to HTTPS? all the XCAP documents would get invalidated! Why a document must point to other document and that document to others? why does a URI list contain a link to other lists with links to others? it's really HARD to inspect both the pres-rules and resource-list documents and decide how to draw my buddylist and who is blocked and who is not. That should be a single task. The buddylist should be a SINGLE "document" in which each contact has attributes (i.e. presence watching allowed or not, visible in the buddy list or not, groups, tags, vcard info, and so on). A single "document" hopefully managed via SIP (we have TCP so why to add HTTP to the SIP ecosystem?). I don't want to subscribe to a XCAP server, receive notifications with *partial* XML diffs and/or retrieve the XML document new fragment via HTTP/XCAP. Too many points of failure and inconsistency. IMHO the keywords that define all the SIMPLE presence stuff are "weak", "fragile" and "complex", so complex. The most basic operation (so easy in any other IM/presence protocol) becomes the hardest task in SIP (see the lines of code in Blink for the presence stuff and the years it took to make it to work). Why so hard? take a look to RCS specs, they provide NOTHING that XMPP does not provide since years, why to build a so complex spec and infrastructure that provides less than MSN 10 years ago but in a much more complex and expensive way? So, is this a failure of the IETF? No idea, what I really don't know is *what* the purpose of the IETF was when it designed all those specifications that don't explain how to build a single addressbook to be shared by different SIP devices. It seems like SIMPLE presence RFC's are just a skeleton in which telcos or vendors can add their custom extra layers for their private networks, and it seems that nobody cared about the open Internet when writting SIMPLE presence specs. What should I implement in a generic open source SIP client for interoperating with others and sharing a full-featured addressbook? There is no response for this question yet. NOTE: I spent more than a year implementing all the RFCs/OMA specs in my own XCAP/XDMS server and SIMPLE/XCAP clients. After having a working and strict implementation of a XCAP/XDMS server and a client capable of rendering the info from both the pres-rules and resource-lists all together, I decided to drop all my effort. Too many lines of code and wasted weeks for implementing nothing cool or new. IMHO life should be easier. Regards. --=20 I=C3=B1aki Baz Castillo From stpeter@stpeter.im Mon Oct 15 08:11:37 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8943D1F0429 for ; Mon, 15 Oct 2012 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj7d-r3KbY6F for ; Mon, 15 Oct 2012 08:11:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D0ED51F0425 for ; Mon, 15 Oct 2012 08:11:30 -0700 (PDT) Received: from [64.101.72.58] (unknown [64.101.72.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 99C644011B; Mon, 15 Oct 2012 09:14:00 -0600 (MDT) Message-ID: <507C1D6A.7060407@stpeter.im> Date: Mon, 15 Oct 2012 08:27:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> <507A0378.2090807@stpeter.im> <507A5BDA.7090207@gmx.net> In-Reply-To: <507A5BDA.7090207@gmx.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:11:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/14/12 12:29 AM, Hannes Tschofenig wrote: > Hi Peter, > > I am aware of this work and the effort that happened before it but > for some reason I got the impression that there was very low energy > behind it. Recently I have received a number of statements of interest in SIP-XMPP interworking. Partly this is because of dual-stack clients that use SIP for voice and video but XMPP for messaging and presence (thus the "CUSAX" I-D). > My impression was that the telcommunication operator community > don't seem to care about it there is still the believe that a pure > SIP-based approach will lead to success (and XMPP is not on their > radar at all) and the XMPP community does not seem care about SIP. > > Is this understanding wrong? In my experience, some operators and enterprise software vendors are indeed interested in SIMPLE<=>XMPP interworking for messaging and presence because, even if they support SIMPLE for messaging and presence, they want to provide gateways to XMPP so that they can offer connections to contacts on large XMPP services like Google Talk. Thus it is helpful for those folks to have specs showing how to translate between SIMPLE and XMPP for addresses, presence, single messages, one-to-one chat, and multi-user chat (the series of specs that I plan to resurrect here soon). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEUEARECAAYFAlB8HWoACgkQNL8k5A2w/vwlOQCgy9Ww59WJ56F1BfDH4BHi6/Jt C04AmNwlidK0IXgjGDw8HYritvy+974= =vkG/ -----END PGP SIGNATURE----- From ag@ag-projects.com Mon Oct 15 08:46:32 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F79221F87B7 for ; Mon, 15 Oct 2012 08:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF5D3PH8i1WZ for ; Mon, 15 Oct 2012 08:46:31 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2235721F87B4 for ; Mon, 15 Oct 2012 08:46:30 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B3A57B00F7; Mon, 15 Oct 2012 17:46:19 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 38E2BB0067; Mon, 15 Oct 2012 17:46:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6325033F-6EAC-463A-A0DD-0BCBC3903C67" From: Adrian Georgescu In-Reply-To: Date: Mon, 15 Oct 2012 17:46:14 +0200 Message-Id: <4F5338DD-FA97-4E83-A534-B820AE463020@ag-projects.com> References: , <839E4257-9B2F-4E3A-85B1-29FDD0240FD4@edvina.net> To: Brian McColgan X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:46:32 -0000 --Apple-Mail=_6325033F-6EAC-463A-A0DD-0BCBC3903C67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 15, 2012, at 2:57 PM, Brian McColgan wrote: > My analysis indicates RLMI doesn't scale, but you/AG allude to an = interop issue with buddy lists. Can you be more specific and outline = the issue? More specific. In SIP SIMPLE client Presence API we defined Group, = Contact and Policy classes each of them with add/delete/update methods = and eight notifications in total to manage the address book. Subscribing = to Presence for a contact and granting access to our own presence = information are booleans that can be set for each contact. To achieve = this simplicity, we had to write about 15K lines of code in a high level = programing language. We do not have an IETF definition of such address book API, that any = programmer would understand, what we have instead are a number of XML = payloads, several event packages and xcap applications. Glueing all of = them is up to the developers and they end up in different places as you = have heard already from several developers. Secondly, without being able = to control the behavior of the server side, there is little chance a = generic SIMPLE client would work with any SIMPLE server as the = assumption are different and the incapability of the server to support = same features used by the client will render the client useless. We = could only do this because we were able to develop at the same time both = the presence client and presence agent side (OpenSIPS and OpenXCAP).=20 XMPP has this approach where and both server and clients can implement = the same addressbook api without running into any interoperability = issues. Adrian > In IMS, they are using pre-defined (i.e. Well known) buddy lists - = e.g. "rcs" for the list of RCS-capable users. But I don't think this is = what you are referring to. >=20 > BR/Brian. >=20 > > Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or = is it an IETF failure? > > From: oej@edvina.net > > Date: Mon, 15 Oct 2012 08:50:32 +0200 > > CC: oej@edvina.net; ag@ag-projects.com > > To: b_mccolgan@hotmail.com > >=20 > >=20 > > 14 okt 2012 kl. 23:48 skrev "Brian McColgan " = : > >=20 > > > Good luck with that Adrian. As I said 'IETF' doesn't get it. > >=20 > > Which takes us back to my original issue - can we get IETF to fix = SIMPLE? > >=20 > > /O --Apple-Mail=_6325033F-6EAC-463A-A0DD-0BCBC3903C67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Oct 15, 2012, at 2:57 PM, Brian = McColgan wrote:

My analysis indicates RLMI doesn't scale, but you/AG = allude to an interop issue with buddy lists.  Can you be more = specific and outline the = issue?

More = specific. In SIP SIMPLE client Presence API we defined Group, Contact = and Policy classes each of them with add/delete/update methods and eight = notifications in total to manage the address book. Subscribing to = Presence for a contact and granting access to our own presence = information are booleans that can be set for each contact.  To = achieve this simplicity, we had to write about 15K lines of code in a = high level programing language.

We do not have = an IETF definition of such address book API, that any programmer would = understand, what we have instead are a number of XML payloads, several = event packages and xcap applications. Glueing all of them is  up to = the developers and they end up in different places as you have heard = already from several developers. Secondly, without being able to = control the behavior of the server side, there is little chance a = generic SIMPLE client would work with any SIMPLE server as the = assumption are different and the incapability of the server to support = same features used by the client will render the client useless. We = could only do this because we were able to develop at the same time both = the presence client and presence agent side (OpenSIPS and = OpenXCAP). 

XMPP has this approach where = and both server and clients can implement the same addressbook api = without running into any interoperability = issues.

Adrian


In = IMS, they are using pre-defined (i.e. Well known) buddy lists - e.g. = "rcs" for the list of RCS-capable users. But I don't think this is what = you are referring to.

BR/Brian.

> Subject: Re: [Simple] = Controversial: Have SIMPLE reached is goal? Or is it an IETF = failure?
> From: = oej@edvina.net
> Date: Mon, 15 Oct 2012 = 08:50:32 +0200
> CC: oej@edvina.net; ag@ag-projects.com
> To: b_mccolgan@hotmail.com
><= span class=3D"Apple-converted-space"> 
> 
> 14 okt 2012 kl. 23:48 skrev = "Brian McColgan " <b_mccolgan@hotmail.com>:
= > 
> > Good luck with that = Adrian. As I said 'IETF' doesn't get it.
> 
> Which takes us back to my = original issue - can we get IETF to fix SIMPLE?
> 
> /O

= --Apple-Mail=_6325033F-6EAC-463A-A0DD-0BCBC3903C67-- From oej@edvina.net Tue Oct 16 07:49:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CED921F881D for ; Tue, 16 Oct 2012 07:49:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqZm4QbWwav9 for ; Tue, 16 Oct 2012 07:49:36 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id CB3F821F8821 for ; Tue, 16 Oct 2012 07:49:35 -0700 (PDT) Received: from [192.168.101.25] (unknown [62.242.105.74]) by smtp7.webway.se (Postfix) with ESMTPA id F3736754A8AA; Tue, 16 Oct 2012 14:49:33 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <4F5338DD-FA97-4E83-A534-B820AE463020@ag-projects.com> Date: Tue, 16 Oct 2012 16:49:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5731FCA1-0F23-4261-8BBD-146B5E7A1065@edvina.net> References: , <839E4257-9B2F-4E3A-85B1-29FDD0240FD4@edvina.net> <4F5338DD-FA97-4E83-A534-B820AE463020@ag-projects.com> To: "simple@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 14:49:36 -0000 Any other thoughts in regards to SIMPLE? Is it a failure or not? Do we have a chance of fixing this within the IETF? Is anyone interested in fixing it so we actually reach the WG goal of = interoperability? /O= From stpeter@stpeter.im Tue Oct 16 08:10:02 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1113521F8682 for ; Tue, 16 Oct 2012 08:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.638 X-Spam-Level: X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-qx8o-Jnali for ; Tue, 16 Oct 2012 08:10:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E393521F8671 for ; Tue, 16 Oct 2012 08:10:00 -0700 (PDT) Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AE3634011B for ; Tue, 16 Oct 2012 09:12:34 -0600 (MDT) Message-ID: <507D78C6.1040103@stpeter.im> Date: Tue, 16 Oct 2012 09:09:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "simple@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Simple] updated SIP-XMPP gatewaying specs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 15:10:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Last night I refreshed the following specifications covering protocol mappings between SIP and XMPP for addresses and errors, presence, single messages, one-to-one chat sessions, and multi-user chat... https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-presence https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-im https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-chat https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat These specs have been around in one form or another for years. More recently, a number of people have asked me whether they can be finished off and published as RFCs. I think they can, although the specs farther down the list are a bit less mature and need to be aligned with work on MSRP and SIMPLE-based chat. I've received feedback offlist in the last few months about several of these (especially the groupchat spec), which I have not yet incorporated, but I will endeavor to do that soon. Thanks for listening, Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB9eMYACgkQNL8k5A2w/vwkbwCePKpOCnpzEEuqo51Vbii1UV/W SLMAn35Y/YFR9djqcQ+PCOO385B0EXjT =mdvB -----END PGP SIGNATURE----- From pkyzivat@alum.mit.edu Tue Oct 16 09:49:58 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9E21F8A48 for ; Tue, 16 Oct 2012 09:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSR8yPANWWbI for ; Tue, 16 Oct 2012 09:49:57 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4221F8A02 for ; Tue, 16 Oct 2012 09:49:57 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta04.westchester.pa.mail.comcast.net with comcast id Bnhi1k0060bG4ec54sq1gx; Tue, 16 Oct 2012 16:50:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id Bskl1k00W3ZTu2S3Psklzk; Tue, 16 Oct 2012 16:44:45 +0000 Message-ID: <507D8F08.4000601@alum.mit.edu> Date: Tue, 16 Oct 2012 12:44:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <507D78C6.1040103@stpeter.im> In-Reply-To: <507D78C6.1040103@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 16:49:58 -0000 AFAIK the SIMPLE WG currently exists as a placeholder. All chartered work was done long ago. There has continued to be a low level of q/a discussion on the list. But recently there has been more active interest in new work. If we want to do more work, we should charter it, either by rechartering SIMPLE, by doing the work in XMPP, starting a new wg, or *something*. Thanks, Paul From mary.ietf.barnes@gmail.com Tue Oct 16 10:34:56 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C21C21F8A6C for ; Tue, 16 Oct 2012 10:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyPy+chvWifY for ; Tue, 16 Oct 2012 10:34:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11E2221F8A63 for ; Tue, 16 Oct 2012 10:34:54 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so5025725lbo.31 for ; Tue, 16 Oct 2012 10:34:54 -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=dEUVwpyD3nEZGHZPYLEkMyfJhJzTDdN0WKX8EABZlfU=; b=yv638Nhew1UnVG5Giag73KPv/yQX2ncQ+ulHXalNabZRcD7elK9Hn2OAfJD8fBwFID w5AkJJ0/EVqyJcpbJnWNEz7Jaj9Fk4rjGy2TvvkMI9JHwjcETvGnke2I0MxYd4lyacQM HJbF0KD9Ji6uS6y7B9jBjZu8oLfM7eVtexHpnBulQIJvgU3yUJuqVON8ULmp6PmMhpeT y+YGXSJ26k3LhZ6vYtMqzPDjd0k960WWkLjHbe+0/ddtqTbmuL+00M4eSLSeG7gmNhW3 JgiEQT0a2dhzooKigh9pdF7LomEgRUmsZ/ujefh15w3fcZTb0irFcXeDJVn0JJ8zPo8Q UnYw== MIME-Version: 1.0 Received: by 10.152.105.135 with SMTP id gm7mr13558187lab.22.1350408893945; Tue, 16 Oct 2012 10:34:53 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 16 Oct 2012 10:34:53 -0700 (PDT) In-Reply-To: <507D8F08.4000601@alum.mit.edu> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> Date: Tue, 16 Oct 2012 12:34:53 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d040711c56cd84904cc30924c Cc: simple@ietf.org Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 17:34:56 -0000 --f46d040711c56cd84904cc30924c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 16, 2012 at 11:44 AM, Paul Kyzivat wrote: > AFAIK the SIMPLE WG currently exists as a placeholder. > All chartered work was done long ago. There has continued to be a low > level of q/a discussion on the list. > [MB] I don't know what you mean by placeholder. There is one WG document that fairly recently went to IESG review. It's not unusual to keep WGs open until all the WG drafts are complete - e.g., XCON only closed after the last RFCs were published. [/MB] > > But recently there has been more active interest in new work. > > If we want to do more work, we should charter it, either by rechartering > SIMPLE, by doing the work in XMPP, starting a new wg, or *something*. > [MB] Exactly. And, I think that's the intent of Peter Saint-Andre's posting on the updated SIP-XMPP docs. Note, that we discussed this topic 3 years ago in a DISPATCH adhoc session and there was not a lot of momentum (I personally think that's because it was scheduled on Friday afternoon). A separate list for the topic was created (but not announced on DISPATCH) and then the work went to XMPP WG to be discussed and the consensus was that there was not enough support for the work. However, that was scheduled opposite the exciting SPLICES WG so not all the interested parties were there. The best thing to do may be to discuss this work again in DISPATCH in an official WG session (per our process) and then decide where it fits. [/MB] > > Thanks, > Paul > ______________________________**_________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/**listinfo/simple > --f46d040711c56cd84904cc30924c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 16, 2012 at 11:44 AM, Paul K= yzivat <pkyzivat@alum.mit.edu> wrote:
AFAIK the SIMPLE WG currently exists as a placeholder.
All chartered work was done long ago. There has continued to be a low level= of q/a discussion on the list.
[MB] I don't know = what you mean by placeholder. =A0There is one WG document that fairly recen= tly went to IESG review. =A0It's not unusual to keep WGs open until all= the WG drafts are complete - e.g., XCON only closed after the last RFCs we= re published. [/MB]

But recently there has been more active interest in new work.

If we want to do more work, we should charter it, either by rechartering SI= MPLE, by doing the work in XMPP, starting a new wg, or *something*.
[MB] =A0Exactly. =A0And, I think that's the intent of Pet= er Saint-Andre's posting on the updated SIP-XMPP docs. Note, that we di= scussed this topic 3 years ago in a DISPATCH adhoc session and there was no= t a lot of momentum (I personally think that's because it was scheduled= on Friday afternoon). =A0A separate list for the topic was created (but no= t announced on DISPATCH) and then the work went to XMPP WG to be discussed = and the consensus was that there was not enough support for the work. =A0Ho= wever, that was scheduled opposite the exciting SPLICES WG so not all the i= nterested parties were there. =A0 The best thing to do may be to discuss th= is work again in DISPATCH in an official WG session (per our process) and t= hen decide where it fits. [/MB]

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul
_______________________________________________
Simple mailing list
Simple@ietf.org = https://www.ietf.org/mailman/listinfo/simple

--f46d040711c56cd84904cc30924c-- From ag@ag-projects.com Tue Oct 16 10:49:58 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC311E808A for ; Tue, 16 Oct 2012 10:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlhSGK0jWSNS for ; Tue, 16 Oct 2012 10:49:57 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id AE2D021F86D3 for ; Tue, 16 Oct 2012 10:49:57 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 30C18B0104; Tue, 16 Oct 2012 19:49:55 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 428BCB007B; Tue, 16 Oct 2012 19:49:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <507D78C6.1040103@stpeter.im> Date: Tue, 16 Oct 2012 19:49:40 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <507D78C6.1040103@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1283) Cc: "simple@ietf.org" Subject: Re: [Simple] updated SIP-XMPP gatewaying specs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 17:49:58 -0000 This is great work, Peter! Adrian On Oct 16, 2012, at 5:09 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Last night I refreshed the following specifications covering protocol > mappings between SIP and XMPP for addresses and errors, presence, > single messages, one-to-one chat sessions, and multi-user chat... > > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-presence > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-im > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-chat > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat > > These specs have been around in one form or another for years. More > recently, a number of people have asked me whether they can be > finished off and published as RFCs. I think they can, although the > specs farther down the list are a bit less mature and need to be > aligned with work on MSRP and SIMPLE-based chat. I've received > feedback offlist in the last few months about several of these > (especially the groupchat spec), which I have not yet incorporated, > but I will endeavor to do that soon. > > Thanks for listening, > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlB9eMYACgkQNL8k5A2w/vwkbwCePKpOCnpzEEuqo51Vbii1UV/W > SLMAn35Y/YFR9djqcQ+PCOO385B0EXjT > =mdvB > -----END PGP SIGNATURE----- > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From stpeter@stpeter.im Tue Oct 16 10:55:05 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E309321F89D6 for ; Tue, 16 Oct 2012 10:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.635 X-Spam-Level: X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ1Jf8baHIIj for ; Tue, 16 Oct 2012 10:55:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3B221F89D3 for ; Tue, 16 Oct 2012 10:55:04 -0700 (PDT) Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 95C3F4010C; Tue, 16 Oct 2012 11:57:38 -0600 (MDT) Message-ID: <507D9F74.8020902@stpeter.im> Date: Tue, 16 Oct 2012 11:55:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <507D78C6.1040103@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: Re: [Simple] updated SIP-XMPP gatewaying specs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 17:55:05 -0000 Thanks, Adrian. I still need to incorporate the feedback you sent me a few months ago. Will do soon. On 10/16/12 11:49 AM, Adrian Georgescu wrote: > This is great work, Peter! > > Adrian > > On Oct 16, 2012, at 5:09 PM, Peter Saint-Andre wrote: > > Last night I refreshed the following specifications covering protocol > mappings between SIP and XMPP for addresses and errors, presence, > single messages, one-to-one chat sessions, and multi-user chat... > > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-presence > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-im > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-chat > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat > > These specs have been around in one form or another for years. More > recently, a number of people have asked me whether they can be > finished off and published as RFCs. I think they can, although the > specs farther down the list are a bit less mature and need to be > aligned with work on MSRP and SIMPLE-based chat. I've received > feedback offlist in the last few months about several of these > (especially the groupchat spec), which I have not yet incorporated, > but I will endeavor to do that soon. > > Thanks for listening, > > Peter > From pkyzivat@alum.mit.edu Tue Oct 16 11:07:02 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C539721F8750 for ; Tue, 16 Oct 2012 11:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.363 X-Spam-Level: X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kVJJFc92+bm for ; Tue, 16 Oct 2012 11:07:01 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A67B721F8A7B for ; Tue, 16 Oct 2012 11:07:01 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id Btz91k00C1GhbT853u74nA; Tue, 16 Oct 2012 18:07:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id Bu2W1k00Q3ZTu2S3Tu2W71; Tue, 16 Oct 2012 18:02:30 +0000 Message-ID: <507DA115.3000308@alum.mit.edu> Date: Tue, 16 Oct 2012 14:01:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mary Barnes References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:07:02 -0000 Mary, Peter Saint-Andre's reactivated drafts are part of what I was talking about. There has been other discussion that may or may not be covered by those drafts. Your suggestion to discuss in DISPATCH and decide if and where we want to do that work makes sense, and is what DISPATCH is for. Presumably we can do that in Atlanta. Thanks, Paul On 10/16/12 1:34 PM, Mary Barnes wrote: > > > On Tue, Oct 16, 2012 at 11:44 AM, Paul Kyzivat > wrote: > > AFAIK the SIMPLE WG currently exists as a placeholder. > All chartered work was done long ago. There has continued to be a > low level of q/a discussion on the list. > > [MB] I don't know what you mean by placeholder. There is one WG > document that fairly recently went to IESG review. It's not unusual to > keep WGs open until all the WG drafts are complete - e.g., XCON only > closed after the last RFCs were published. [/MB] > > > But recently there has been more active interest in new work. > > If we want to do more work, we should charter it, either by > rechartering SIMPLE, by doing the work in XMPP, starting a new wg, > or *something*. > > [MB] Exactly. And, I think that's the intent of Peter Saint-Andre's > posting on the updated SIP-XMPP docs. Note, that we discussed this topic > 3 years ago in a DISPATCH adhoc session and there was not a lot of > momentum (I personally think that's because it was scheduled on Friday > afternoon). A separate list for the topic was created (but not > announced on DISPATCH) and then the work went to XMPP WG to be discussed > and the consensus was that there was not enough support for the work. > However, that was scheduled opposite the exciting SPLICES WG so not > all the interested parties were there. The best thing to do may be to > discuss this work again in DISPATCH in an official WG session (per our > process) and then decide where it fits. [/MB] > > > Thanks, > Paul > _________________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/__listinfo/simple > > > From ben@nostrum.com Tue Oct 16 11:12:56 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883B421F89CD for ; Tue, 16 Oct 2012 11:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIsLmNmLy794 for ; Tue, 16 Oct 2012 11:12:56 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD6F21F89CF for ; Tue, 16 Oct 2012 11:12:55 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9GICsY8051952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2012 13:12:54 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <507D8F08.4000601@alum.mit.edu> Date: Tue, 16 Oct 2012 13:12:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:12:56 -0000 (as chair) This is an interesting discussion, and please feel free to continue it = on the SIMPLE list, at least for now.=20 But if work comes of it, that will most likely need to go through = DISPATCH. Given the general lack of energy we've seen for SIMPLE lately, = I think it's unlikely that we would recharter it in it's current form. = Or at least, any recharter effort will be met with the same sort of = scrutiny a DISPATCH or BoF proposal. Thanks! Ben. On Oct 16, 2012, at 11:44 AM, Paul Kyzivat = wrote: > AFAIK the SIMPLE WG currently exists as a placeholder. > All chartered work was done long ago. There has continued to be a low = level of q/a discussion on the list. >=20 > But recently there has been more active interest in new work. >=20 > If we want to do more work, we should charter it, either by = rechartering SIMPLE, by doing the work in XMPP, starting a new wg, or = *something*. >=20 > Thanks, > Paul > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple ly= From ben@nostrum.com Tue Oct 16 11:15:41 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DD921F87E1 for ; Tue, 16 Oct 2012 11:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoVxW1Y8tASS for ; Tue, 16 Oct 2012 11:15:40 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 594C121F87D5 for ; Tue, 16 Oct 2012 11:15:40 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9GIFZXx052245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2012 13:15:35 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Tue, 16 Oct 2012 13:15:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> To: Mary Barnes X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org, Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:15:41 -0000 On Oct 16, 2012, at 12:34 PM, Mary Barnes = wrote: >=20 >=20 > On Tue, Oct 16, 2012 at 11:44 AM, Paul Kyzivat = wrote: > AFAIK the SIMPLE WG currently exists as a placeholder. > All chartered work was done long ago. There has continued to be a low = level of q/a discussion on the list. > [MB] I don't know what you mean by placeholder. There is one WG = document that fairly recently went to IESG review. It's not unusual to = keep WGs open until all the WG drafts are complete - e.g., XCON only = closed after the last RFCs were published. [/MB] >=20 > But recently there has been more active interest in new work. >=20 > If we want to do more work, we should charter it, either by = rechartering SIMPLE, by doing the work in XMPP, starting a new wg, or = *something*. > [MB] Exactly. And, I think that's the intent of Peter Saint-Andre's = posting on the updated SIP-XMPP docs. Note, that we discussed this topic = 3 years ago in a DISPATCH adhoc session and there was not a lot of = momentum (I personally think that's because it was scheduled on Friday = afternoon). A separate list for the topic was created (but not = announced on DISPATCH) and then the work went to XMPP WG to be discussed = and the consensus was that there was not enough support for the work. = However, that was scheduled opposite the exciting SPLICES WG so not all = the interested parties were there. The best thing to do may be to = discuss this work again in DISPATCH in an official WG session (per our = process) and then decide where it fits. [/MB] I concur, with the caveat that this shouldn't preclude _list_ discussion = prior to a DISPATCH f2f discussion. (I say that assuming such a f2f = discussion, if it happens, would likely be next March) >=20 > Thanks, > Paul > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Tue Oct 16 11:23:19 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA4321F87FC for ; Tue, 16 Oct 2012 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c260LWKkzRIX for ; Tue, 16 Oct 2012 11:23:19 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB82221F8813 for ; Tue, 16 Oct 2012 11:23:18 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9GINDjC052866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2012 13:23:14 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <507DA115.3000308@alum.mit.edu> Date: Tue, 16 Oct 2012 13:23:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Mary Barnes , Simple WG Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:23:19 -0000 On Oct 16, 2012, at 1:01 PM, Paul Kyzivat wrote: > Mary, >=20 > Peter Saint-Andre's reactivated drafts are part of what I was talking = about. There has been other discussion that may or may not be covered by = those drafts. >=20 > Your suggestion to discuss in DISPATCH and decide if and where we want = to do that work makes sense, and is what DISPATCH is for. Presumably we = can do that in Atlanta. I believe we're past the deadline for "official" DISPATCH agenda time = for Atlanta. Mary, since you've already commented, do you have thoughts = on that? >=20 > Thanks, > Paul >=20 >=20 > On 10/16/12 1:34 PM, Mary Barnes wrote: >>=20 >>=20 >> On Tue, Oct 16, 2012 at 11:44 AM, Paul Kyzivat > > wrote: >>=20 >> AFAIK the SIMPLE WG currently exists as a placeholder. >> All chartered work was done long ago. There has continued to be a >> low level of q/a discussion on the list. >>=20 >> [MB] I don't know what you mean by placeholder. There is one WG >> document that fairly recently went to IESG review. It's not unusual = to >> keep WGs open until all the WG drafts are complete - e.g., XCON only >> closed after the last RFCs were published. [/MB] >>=20 >>=20 >> But recently there has been more active interest in new work. >>=20 >> If we want to do more work, we should charter it, either by >> rechartering SIMPLE, by doing the work in XMPP, starting a new wg, >> or *something*. >>=20 >> [MB] Exactly. And, I think that's the intent of Peter Saint-Andre's >> posting on the updated SIP-XMPP docs. Note, that we discussed this = topic >> 3 years ago in a DISPATCH adhoc session and there was not a lot of >> momentum (I personally think that's because it was scheduled on = Friday >> afternoon). A separate list for the topic was created (but not >> announced on DISPATCH) and then the work went to XMPP WG to be = discussed >> and the consensus was that there was not enough support for the work. >> However, that was scheduled opposite the exciting SPLICES WG so not >> all the interested parties were there. The best thing to do may be = to >> discuss this work again in DISPATCH in an official WG session (per = our >> process) and then decide where it fits. [/MB] >>=20 >>=20 >> Thanks, >> Paul >> _________________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/__listinfo/simple >> >>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From mary.ietf.barnes@gmail.com Tue Oct 16 11:32:28 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F94921F885A for ; Tue, 16 Oct 2012 11:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vmw1CkcxSHTr for ; Tue, 16 Oct 2012 11:32:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA19321F8A07 for ; Tue, 16 Oct 2012 11:32:26 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so5068612lbo.31 for ; Tue, 16 Oct 2012 11:32:23 -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=YFjbqtlopsKn8uiSWU8CnK+K8WndROwgEbCTl7yQ/dM=; b=Y01cx98zzVQMLeZGv+tZrnNfXDJb6xg9b499Ke2dAlZtp/vc0leHxQLvGQ+rW7sDo0 RIHpgisAFm+Jl7N8JYyrAp8Vo8r3UURFjDNXkAPXpFhFFqnGErCzxpTOBJigQ7x/KPMF BMpxXbzUPqhJYaUOAwrNAU86FOaNUKP9h2fCRVlHIqaPth++Wq9b6+vl3lugaiLIwgQP owLK0lVDcgGQaMBOeiS5Nv7NGCnRBNUKJYGgUOv/O9OrvjZ+Pcuf0k1WgxX/047D0mvn dic9RnBrMVbgYknh/GmebhzEk1u8UKypDtx0qvww+ZUkL+EmKx5QM3sVVI/s2mehdUEm rhuw== MIME-Version: 1.0 Received: by 10.112.50.106 with SMTP id b10mr2576400lbo.122.1350412343654; Tue, 16 Oct 2012 11:32:23 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 16 Oct 2012 11:32:23 -0700 (PDT) In-Reply-To: <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> Date: Tue, 16 Oct 2012 13:32:23 -0500 Message-ID: From: Mary Barnes To: Ben Campbell Content-Type: multipart/alternative; boundary=f46d0401fe590b393f04cc316012 Cc: Paul Kyzivat , Simple WG Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:32:28 -0000 --f46d0401fe590b393f04cc316012 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 16, 2012 at 1:23 PM, Ben Campbell wrote: > > On Oct 16, 2012, at 1:01 PM, Paul Kyzivat wrote: > > > Mary, > > > > Peter Saint-Andre's reactivated drafts are part of what I was talking > about. There has been other discussion that may or may not be covered by > those drafts. > > > > Your suggestion to discuss in DISPATCH and decide if and where we want > to do that work makes sense, and is what DISPATCH is for. Presumably we can > do that in Atlanta. > > I believe we're past the deadline for "official" DISPATCH agenda time for > Atlanta. Mary, since you've already commented, do you have thoughts on that? > [MB] Yes - we are past the "official" DISPATCH dates. Although, we have a light agenda since only one topic was requested before the deadline. We may have some extra time and pending approval from the ADs, we could have an unofficial discussion after the "official" agenda to kick this off and pursue it formally in DISPATCH in March (with the discussion focusing on a proposed charter). I'll ping the ADs and see what they think. [/MB] > > > > > > Thanks, > > Paul > > > > > > On 10/16/12 1:34 PM, Mary Barnes wrote: > >> > >> > >> On Tue, Oct 16, 2012 at 11:44 AM, Paul Kyzivat >> > wrote: > >> > >> AFAIK the SIMPLE WG currently exists as a placeholder. > >> All chartered work was done long ago. There has continued to be a > >> low level of q/a discussion on the list. > >> > >> [MB] I don't know what you mean by placeholder. There is one WG > >> document that fairly recently went to IESG review. It's not unusual to > >> keep WGs open until all the WG drafts are complete - e.g., XCON only > >> closed after the last RFCs were published. [/MB] > >> > >> > >> But recently there has been more active interest in new work. > >> > >> If we want to do more work, we should charter it, either by > >> rechartering SIMPLE, by doing the work in XMPP, starting a new wg, > >> or *something*. > >> > >> [MB] Exactly. And, I think that's the intent of Peter Saint-Andre's > >> posting on the updated SIP-XMPP docs. Note, that we discussed this topic > >> 3 years ago in a DISPATCH adhoc session and there was not a lot of > >> momentum (I personally think that's because it was scheduled on Friday > >> afternoon). A separate list for the topic was created (but not > >> announced on DISPATCH) and then the work went to XMPP WG to be discussed > >> and the consensus was that there was not enough support for the work. > >> However, that was scheduled opposite the exciting SPLICES WG so not > >> all the interested parties were there. The best thing to do may be to > >> discuss this work again in DISPATCH in an official WG session (per our > >> process) and then decide where it fits. [/MB] > >> > >> > >> Thanks, > >> Paul > >> _________________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/__listinfo/simple > >> > >> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > --f46d0401fe590b393f04cc316012 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 16, 2012 at 1:23 PM, Ben Cam= pbell <ben@nostrum.com> wrote:

On Oct 16, 2012, at 1:01 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Mary,
>
> Peter Saint-Andre's reactivated drafts are part of what I was talk= ing about. There has been other discussion that may or may not be covered b= y those drafts.
>
> Your suggestion to discuss in DISPATCH and decide if and where we want= to do that work makes sense, and is what DISPATCH is for. Presumably we ca= n do that in Atlanta.

I believe we're past the deadline for "official" DISPAT= CH agenda time for Atlanta. Mary, since you've already commented, do yo= u have thoughts on that?
[MB] Yes - we are past the &q= uot;official" DISPATCH dates. =A0Although, we have a light agenda sinc= e only one topic was requested before the deadline. =A0We may have some ext= ra time and pending approval from the ADs, we could have an unofficial disc= ussion after the "official" agenda to kick this off and pursue it= formally in DISPATCH in March (with the discussion focusing on a proposed = charter). =A0I'll ping the ADs and see what they think. [/MB]=A0


>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>
> On 10/16/12 1:34 PM, Mary Barnes wrote:
>>
>>
>> On Tue, Oct 16, 2012 at 11:44 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.= mit.edu>> wrote:
>>
>> =A0 =A0AFAIK the SIMPLE WG currently exists as a placeholder.
>> =A0 =A0All chartered work was done long ago. There has continued t= o be a
>> =A0 =A0low level of q/a discussion on the list.
>>
>> [MB] I don't know what you mean by placeholder. =A0There is on= e WG
>> document that fairly recently went to IESG review. =A0It's not= unusual to
>> keep WGs open until all the WG drafts are complete - e.g., XCON on= ly
>> closed after the last RFCs were published. [/MB]
>>
>>
>> =A0 =A0But recently there has been more active interest in new wor= k.
>>
>> =A0 =A0If we want to do more work, we should charter it, either by=
>> =A0 =A0rechartering SIMPLE, by doing the work in XMPP, starting a = new wg,
>> =A0 =A0or *something*.
>>
>> [MB] =A0Exactly. =A0And, I think that's the intent of Peter Sa= int-Andre's
>> posting on the updated SIP-XMPP docs. Note, that we discussed this= topic
>> 3 years ago in a DISPATCH adhoc session and there was not a lot of=
>> momentum (I personally think that's because it was scheduled o= n Friday
>> afternoon). =A0A separate list for the topic was created (but not<= br> >> announced on DISPATCH) and then the work went to XMPP WG to be dis= cussed
>> and the consensus was that there was not enough support for the wo= rk.
>> =A0However, that was scheduled opposite the exciting SPLICES WG so= not
>> all the interested parties were there. =A0 The best thing to do ma= y be to
>> discuss this work again in DISPATCH in an official WG session (per= our
>> process) and then decide where it fits. [/MB]
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 =A0 =A0 Paul
>> =A0 =A0_________________________________________________
>> =A0 =A0Simple mailing list
>> =A0 =A0Simple@ietf.org <= mailto:Simple@ietf.org>
>> =A0 =A0https://www.ietf.org/mailman/__listinfo/simple
>> =A0 =A0<https://www.ietf.org/mailman/listinfo/simple> >>
>>
>
> __________________= _____________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple


--f46d0401fe590b393f04cc316012-- From ben@nostrum.com Tue Oct 16 12:01:39 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB4421F8A43 for ; Tue, 16 Oct 2012 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnMNoSrj0bwW for ; Tue, 16 Oct 2012 12:01:38 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0041F0C60 for ; Tue, 16 Oct 2012 12:01:28 -0700 (PDT) Received: from [10.167.217.34] (mobile-166-147-064-201.mycingular.net [166.147.64.201]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9GJ1IcL056413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2012 14:01:20 -0500 (CDT) (envelope-from ben@nostrum.com) References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-C2D8F55A-71E5-4DE0-BE3E-77F3CFB01A6C Content-Transfer-Encoding: 7bit Message-Id: <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> X-Mailer: iPad Mail (10A403) From: Ben Campbell Date: Tue, 16 Oct 2012 14:01:15 -0500 To: Mary Barnes Received-SPF: pass (nostrum.com: 166.147.64.201 is authenticated by a trusted mechanism) Cc: Paul Kyzivat , Simple WG Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:01:39 -0000 --Apple-Mail-C2D8F55A-71E5-4DE0-BE3E-77F3CFB01A6C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Oct 16, 2012, at 1:32 PM, Mary Barnes wrote:= >> > Your suggestion to discuss in DISPATCH and decide if and where we want t= o do that work makes sense, and is what DISPATCH is for. Presumably we can d= o that in Atlanta. >>=20 >> I believe we're past the deadline for "official" DISPATCH agenda time for= Atlanta. Mary, since you've already commented, do you have thoughts on that= ? > [MB] Yes - we are past the "official" DISPATCH dates. Although, we have a= light agenda since only one topic was requested before the deadline. We ma= y have some extra time and pending approval from the ADs, we could have an u= nofficial discussion after the "official" agenda to kick this off and pursue= it formally in DISPATCH in March (with the discussion focusing on a propose= d charter). I'll ping the ADs and see what they think. [/MB]=20 >>=20 I also assume any such discussion would be dependent on someone stepping up t= o lead it, right? It seems like there are really at least two things under d= iscussion on the list: SIMPLE/XMPP inter working, and whether work is needed= on SIMPLE itself in order to facilitate interoperable implementations. Thanks, Ben.= --Apple-Mail-C2D8F55A-71E5-4DE0-BE3E-77F3CFB01A6C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On Oct 16, 2012, at 1:32 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

> Your suggestion to discuss in DISPATCH and decide if and where we want to do that work makes sense, and is what DISPATCH is for. Presumably we can do that in Atlanta.

I believe we're past the deadline for "official" DISPATCH agenda time for Atlanta. Mary, since you've already commented, do you have thoughts on that?
[MB] Yes - we are past the "official" DISPATCH dates.  Although, we have a light agenda since only one topic was requested before the deadline.  We may have some extra time and pending approval from the ADs, we could have an unofficial discussion after the "official" agenda to kick this off and pursue it formally in DISPATCH in March (with the discussion focusing on a proposed charter).  I'll ping the ADs and see what they think. [/MB] 

I also assume any such discussion would be dependent on someone stepping up to lead it, right? It seems like there are really at least two things under discussion on the list: SIMPLE/XMPP inter working, and whether work is needed on SIMPLE itself in order to facilitate interoperable implementations.

Thanks,

Ben.
--Apple-Mail-C2D8F55A-71E5-4DE0-BE3E-77F3CFB01A6C-- From mary.ietf.barnes@gmail.com Tue Oct 16 14:12:13 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168921F0CA3 for ; Tue, 16 Oct 2012 14:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.38 X-Spam-Level: X-Spam-Status: No, score=-103.38 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaeGA-wQ4pde for ; Tue, 16 Oct 2012 14:12:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2E0C1F0CA2 for ; Tue, 16 Oct 2012 14:12:11 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so5180198lbo.31 for ; Tue, 16 Oct 2012 14:12:11 -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=TnVsCVKK581GqsS/BeRU8TA2oCih+C/320jhmQM3aYc=; b=lJN6DVd9bOAy9AfMsYcMPlRw6qzPFCtZP4MRlEYqN4yC+bw9Hb8lFBvOVnQRGPr9Pp xXQbhEKIMY8af4Lpc5FsoYuPqWsFd2K9mGOzYA4S7dvL1j75WOuQglu8jJyFJsi0X+iD 0VYkoOALMjWMJC/EtfDA+YQDWxZCGJUS9YzDGcxma/nyrs8tFqRCGeN9mNNnVIsThxUS +hRiIB3FSPfK57D3tFi2mG408eWc2smzN2nNC3SzDPrb0QGgD8ONVsp+xu2QDx3EW5qr 5/RZ52/f2rpdqQYjLXrIZKF9cMIGzihxNj4V//JbYtC35B7VabiUnRt2/G5RUkHzvkN8 ffxQ== MIME-Version: 1.0 Received: by 10.112.24.6 with SMTP id q6mr5420497lbf.24.1350421930929; Tue, 16 Oct 2012 14:12:10 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 16 Oct 2012 14:12:10 -0700 (PDT) In-Reply-To: <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> Date: Tue, 16 Oct 2012 16:12:10 -0500 Message-ID: From: Mary Barnes To: Ben Campbell Content-Type: multipart/alternative; boundary=e0cb4efe2a0a7d6da804cc339bee Cc: Paul Kyzivat , Simple WG Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 21:12:13 -0000 --e0cb4efe2a0a7d6da804cc339bee Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 16, 2012 at 2:01 PM, Ben Campbell wrote: > > > On Oct 16, 2012, at 1:32 PM, Mary Barnes > wrote: > > > Your suggestion to discuss in DISPATCH and decide if and where we want >> to do that work makes sense, and is what DISPATCH is for. Presumably we can >> do that in Atlanta. >> >> I believe we're past the deadline for "official" DISPATCH agenda time for >> Atlanta. Mary, since you've already commented, do you have thoughts on that? >> > [MB] Yes - we are past the "official" DISPATCH dates. Although, we have a > light agenda since only one topic was requested before the deadline. We > may have some extra time and pending approval from the ADs, we could have > an unofficial discussion after the "official" agenda to kick this off and > pursue it formally in DISPATCH in March (with the discussion focusing on a > proposed charter). I'll ping the ADs and see what they think. [/MB] > >> > I also assume any such discussion would be dependent on someone stepping > up to lead it, right? It seems like there are really at least two things > under discussion on the list: SIMPLE/XMPP inter working, and whether work > is needed on SIMPLE itself in order to facilitate interoperable > implementations. > [MB2] Yes, we would need people willing to lead the work as well as folks that are willing to contribute to and review documents. Yes, there are two separate things. My comments were on the former. I think the latter is a different beast and needs more consideration before thinking that we have something to do or whether we should do something. [/MB2] > > Thanks, > > Ben. > --e0cb4efe2a0a7d6da804cc339bee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 16, 2012 at 2:01 PM, Ben Cam= pbell <ben@nostrum.com> wrote:


On Oct 16, 2012, at 1:32 P= M, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

> Your suggestion to discuss in DISP= ATCH and decide if and where we want to do that work makes sense, and is wh= at DISPATCH is for. Presumably we can do that in Atlanta.

I believe we're past the deadline for "official" DISPAT= CH agenda time for Atlanta. Mary, since you've already commented, do yo= u have thoughts on that?
[MB] Yes - we are past the &q= uot;official" DISPATCH dates. =A0Although, we have a light agenda sinc= e only one topic was requested before the deadline. =A0We may have some ext= ra time and pending approval from the ADs, we could have an unofficial disc= ussion after the "official" agenda to kick this off and pursue it= formally in DISPATCH in March (with the discussion focusing on a proposed = charter). =A0I'll ping the ADs and see what they think. [/MB]=A0

I also assum= e any such discussion would be dependent on someone stepping up to lead it,= right? It seems like there are really at least two things under discussion= on the list: SIMPLE/XMPP inter working, and whether work is needed on SIMP= LE itself in order to facilitate interoperable implementations.
[MB2] Yes, we would need people willing to lead the= work as well as folks that are willing to contribute to and review documen= ts. =A0Yes, there are two separate things. =A0My comments were on the forme= r. =A0I think the latter is a different beast and needs more consideration = before thinking that we have something to do or whether we should do someth= ing. [/MB2]

Thanks= ,

Ben.

--e0cb4efe2a0a7d6da804cc339bee-- From raphael.bossek@estos.de Wed Oct 17 00:14:39 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3652121F8789 for ; Wed, 17 Oct 2012 00:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRpgVNu3O41R for ; Wed, 17 Oct 2012 00:14:36 -0700 (PDT) Received: from mail.estos.de (ns1.estos24.de [62.245.228.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7184D21F86BA for ; Wed, 17 Oct 2012 00:14:34 -0700 (PDT) Received: from hermelin.estos.de ([fe80::1]) by hermelin.estos.de ([fe80::1%1]) with mapi; Wed, 17 Oct 2012 09:14:32 +0200 From: Raphael Bossek To: Peter Saint-Andre , "simple@ietf.org" Date: Wed, 17 Oct 2012 09:14:30 +0200 Thread-Topic: [Simple] updated SIP-XMPP gatewaying specs Thread-Index: Ac2rsFTGBZ5jLL13QlSwDkPIxEbv+AAhqX4A Message-ID: <9B7CB52192C7EA4C931088F28A51177C0131381F5030@hermelin.estos.de> References: <507D78C6.1040103@stpeter.im> In-Reply-To: <507D78C6.1040103@stpeter.im> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE x-pp-processed: __PP2__3d782474-723b-4e9b-a051-a45da57f7129 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: David Welzmiller Subject: Re: [Simple] updated SIP-XMPP gatewaying specs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 07:14:39 -0000 Hallo Philipp, kennst du den Peter Saint-Andre? Sind "seine" Ideen obsolate? Gru=DF, i.A. Raphael Bossek Product Manager ESTOS GmbH Petersbrunner Str. 3a 82319 Starnberg, Germany Phone: +49815136856153 Fax: +49 (8151) 36856-853 Mobile: +49 (151) 59177535 Email: raphael.bossek@estos.de Web: http://www.estos.de // Jetzt anmelden zu den kostenfreien Online-Workshops ab September 2012. Webinare zu den Themen: Mobilit=E4t, DATEV pro, Federation, u. a. http://www.estos.de/partner/webinare.html --- ESTOS GmbH Registered office: Starnberg, Germany Commercial registry Munich, HRB 133 670 Managing Directors: Dipl.-Phys. Stephan Eckbauer, Dipl.-Ing. Stefan Hobrats= chk, Ing. Christoph L=F6sch, Florian Bock -----Urspr=FCngliche Nachricht----- Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im Auftrag vo= n Peter Saint-Andre Gesendet: Dienstag, 16. Oktober 2012 17:10 An: simple@ietf.org Betreff: [Simple] updated SIP-XMPP gatewaying specs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Last night I refreshed the following specifications covering protocol mappi= ngs between SIP and XMPP for addresses and errors, presence, single message= s, one-to-one chat sessions, and multi-user chat... https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-presence https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-im https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-chat https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat These specs have been around in one form or another for years. More recentl= y, a number of people have asked me whether they can be finished off and pu= blished as RFCs. I think they can, although the specs farther down the list= are a bit less mature and need to be aligned with work on MSRP and SIMPLE-= based chat. I've received feedback offlist in the last few months about sev= eral of these (especially the groupchat spec), which I have not yet incorpo= rated, but I will endeavor to do that soon. Thanks for listening, Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB9eMYACgkQNL8k5A2w/vwkbwCePKpOCnpzEEuqo51Vbii1UV/W SLMAn35Y/YFR9djqcQ+PCOO385B0EXjT =3DmdvB -----END PGP SIGNATURE----- _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From saul@ag-projects.com Wed Oct 17 01:08:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DE921F850B for ; Wed, 17 Oct 2012 01:08:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2De719zvjX7 for ; Wed, 17 Oct 2012 01:08:35 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3014B21F84FD for ; Wed, 17 Oct 2012 01:08:34 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AA43EB0130; Wed, 17 Oct 2012 10:08:33 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 581A7B007B; Wed, 17 Oct 2012 10:08:29 +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: <6E2FF868-B070-4180-8017-D504317D2999@edvina.net> Date: Wed, 17 Oct 2012 10:08:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6ECEF4BB-8C01-4FD7-AC87-7FF27EE1EE82@ag-projects.com> References: <61awl8u6wktn3a7d8k01c5jv.1350149270185@email.android.com> <507A0378.2090807@stpeter.im> <507A5BDA.7090207@gmx.net> <6E2FF868-B070-4180-8017-D504317D2999@edvina.net> To: Olle E. Johansson X-Mailer: Apple Mail (2.1085) Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 08:08:36 -0000 Hi Olle, (sorry if this has been answered down the thread, I'm catching up) On Oct 14, 2012, at 9:33 AM, Olle E. Johansson wrote: >=20 > 14 okt 2012 kl. 08:29 skrev Hannes Tschofenig = : >=20 >> Hi Peter, >>=20 >> I am aware of this work and the effort that happened before it but = for some reason I got the impression that there was very low energy = behind it. > There are many clients around that support both XMPP and SIP and there = used to be very few clients supporting SIMPLE, so the requirements for = interoperability on protocol level has not been huge.=20 >=20 > Today we have more clients supporting SIMPLE, so there may be a new = level of interest. >=20 >>=20 >> My impression was that the telcommunication operator community don't = seem to care about it there is still the believe that a pure SIP-based = approach will lead to success (and XMPP is not on their radar at all) = and the XMPP community does not seem care about SIP. > Which may not be a bad thing. Being sarcastic, the interest in SIP = from the operator community has given SIP a lot of ISDN features that = XMPP luckily doesn't have... ;-) >=20 > The architecture is fundamentally different. In XMPP, the server = forwards XMPP messages called stanzas, but doesn't keep or aggregate any = status. In SIMPLE, the server aggregates presence states and we can ask = the server about an entitys current status and change it. This lead to = some interoperability challenges, like the SIP subscribe query with = expires:0. A jabber server can't answer that. That particular example, SUBSCRIBE with expires 0, can be seen as a = 'presence probe', aka 'give me the last known state' and XMPP can do = this with a presence stanza of type 'probe'. >=20 >>=20 >> Is this understanding wrong? > The interesting thing with XMPP is that it powers a lot of = applications that you don't see as classical IM or presence, with buddy = lists. The XMPP developer meetings are full with cool developers = presenting really interesting projects powered by XMPP. So you might = have applications in the telecom world that build on XMPP, but very few = people know about it.=20 >=20 > XMPP did one thing right that SIP did not. There are two RFCs - one = for the core protocol and one for the first application - IM and = presence. SIP could have benefited from one RFC for the core protocol = and a separate for "telephony".=20 >=20 > /O >>=20 >> Ciao >> Hannes >>=20 >> On 10/14/2012 03:12 AM, Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>> On 10/13/12 11:29 AM, Hannes Tschofenig wrote: >>>=20 >>>> The interworking between SIP-based voice and XMPP text messaging >>>> is not standardized either. Does anyone have any information? >>>=20 >>> It's funny you should ask. Emil Ivov, Enrico Marocco, and I have = been >>> working on that a bit here: >>>=20 >>> http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/ >>>=20 >>> I am also planning to soon resurrect the entire series of documents = I >>> had underway several years ago, draft-saintandre-sip-xmpp-* (core, = IM, >>> presence, etc.). >>>=20 >>> Peter >>>=20 >>> - -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>>=20 >>>=20 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>>=20 >>> iEYEARECAAYFAlB6A3gACgkQNL8k5A2w/vzh+wCg4lajuJTMDRwd0gBZNXaPk18S >>> Ls4AoIaiLEL1q75NM09qISSDHUdUhSD4 >>> =3DNDw2 >>> -----END PGP SIGNATURE----- >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Wed Oct 17 01:26:05 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FEA21F877C for ; Wed, 17 Oct 2012 01:26:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-7rMS0YWcg2 for ; Wed, 17 Oct 2012 01:26:05 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE9321F857D for ; Wed, 17 Oct 2012 01:26:04 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4D05AB0104; Wed, 17 Oct 2012 10:26:02 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 7F481B0079; Wed, 17 Oct 2012 10:26:02 +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: <5731FCA1-0F23-4261-8BBD-146B5E7A1065@edvina.net> Date: Wed, 17 Oct 2012 10:26:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77BEF79D-9756-4296-9ADF-9815EA54EA97@ag-projects.com> References: , <839E4257-9B2F-4E3A-85B1-29FDD0240FD4@edvina.net> <4F5338DD-FA97-4E83-A534-B820AE463020@ag-projects.com> <5731FCA1-0F23-4261-8BBD-146B5E7A1065@edvina.net> To: Olle E. Johansson X-Mailer: Apple Mail (2.1085) Cc: "simple@ietf.org" Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 08:26:05 -0000 Hi, On Oct 16, 2012, at 4:49 PM, Olle E. Johansson wrote: > Any other thoughts in regards to SIMPLE? >=20 > Is it a failure or not? >=20 > Do we have a chance of fixing this within the IETF? >=20 > Is anyone interested in fixing it so we actually reach the WG goal of = interoperability? >=20 IMHO there are 2 key factors to solve this: a data model for presence, = and a data model for an addressbook. A data model for presence.=20 Currently PIDF allows us to express presence segmented into tuples and = then there is the person element. The tuple elements only have basic = status, whereas person can be extended with RPID activities such as = 'busy'. The fact that presence can be segmented into tuples yet there is = a global state which affects all makes interpreting documents really = complicated. Not to mention the fact that if several devices want to = modify the person element they'll need to agree on the ID for that = element or they'll just be overriding each other. I see 2 different possible presence models: one where the state belongs = to the physical person, and there is a single presence state across all = devices (like Skype, for example) and one where the presence belongs = exclusively to the device and recipients of multiple presence states = will examine them and take action (like XMPP). Since we now have means to do per-device things thanks to GRUU, I lean = towards the second approach. Of course this makes interoperability with = XMPP pretty straightforward. A data model for an addressbook. The current specs where defined with elements called 'resources', which = have a single URI, yet any addressbook allows us to specify multiple = numbers for the same person, so modeling an addressbook like application = is not straightforward. On top of that, if I want to do the simple operation of adding a buddy = with both ways presence, I need to modify 3 XCAP documents: pres-rules, = resource-lists and rls-services. There is no way to do this in an atomic = way, which lead to complex code. OMA specs do help here, by using external references both from = pres-rules and rls-services to resource-lists adding a buddy implies = modifying a single document, which is atomic. I'm probably forgetting a ton of details, but this 2 big things are the = first that come to mind. It would be great if there is interest in = trying to find a way around these and making a working model, count me = in for that :-) Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ag@ag-projects.com Wed Oct 17 06:14:31 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1055C21F873B for ; Wed, 17 Oct 2012 06:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V4ORhQL9bsc for ; Wed, 17 Oct 2012 06:14:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D5B5D21F872E for ; Wed, 17 Oct 2012 06:14:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E4AEBB014F; Wed, 17 Oct 2012 15:14:27 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 72FFDB0067; Wed, 17 Oct 2012 15:14:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: Date: Wed, 17 Oct 2012 15:14:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> References: To: Brian McColgan X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:14:31 -0000 Hi Brian, I keep this on the mailing list, hope you do not mind. On Oct 17, 2012, at 2:50 PM, Brian McColgan wrote: > Hi Adrian, >=20 > I looked at your site for the API, and had some comments. >=20 > My concern is that the API you developed is a series of wrappers = around a lot of complexity in SIP/SIMPLE, and xcap, etc. That explains = the 15kloc of code! =20 Indeed. In XMPP, this so called wrapper is defined well enough in the = core specification that can be interpreted in the same way by any client = or server implementor. SIMPLE lacks this.=20 > Not sure why folks are talking about an addr-book and SIP/SIMPLE (or = an rls for that matter) in the same breath. They are NOT the same = thing. If you want to understand why, look at OMA Converged Address = Book 1.1 for the reasons why that is the case. =46rom the perspective of both the UI developer and the end-user, they = are 100% the same thing. =46rom a standards perspective they are not, = and here is the cause of the problem. > If we go 'way back' to the days when Rosenberg was involved in = SIP/SIMPLE and xcap, the idea was to have an ability to manipulate a = (~20 member or smaller) buddy list. Most people now have networks = (contact-lists of 100 people or more). And the 'social meshing' expands = our potential connections well beyond this. One reason that the watcher = scale issue would be exacerbated sooner than later (as pointed out by = Houri, et al in his inter-domain scaling analysis on PRS). >=20 > Xcap and indeed (XDM) have gone way beyond that now. However, the = complexity remains. >=20 > What I don't see in the API is a model or approach - based on typical = consumption patterns.=20 >=20 > Presence Access Layer made several assumptions: > - a presence aware service knows what indicators they need to fulfill = functions (the rest is irrelevant) > - each watcher has (per SIMPLE) a view of presence; based on the view = the presentity 'permits' the user to see (via presence rules) > - that view X the presence aware service =3D presence context = (contextually oriented presence)=20 >=20 > That model simplifies the interface and strips out the details from a = client. =20 This model does not simplify but is the very cause of complexity, is the = root cause of ending up building clients that do not interoperate with = each other under the same account. > Interop is bandied about a lot, but what isn't clear is whether we are = talking 'on the wire interop' or 'coded interop' (I.e. I am coding to an = interface that is identical whether I am using an underlying X or Y). = Fill in the blanks on X and Y (X can be XMPP, Y the other flavor). =20 By interoperability, I mean that developer A can develop a SIMPLE = client that can be interchanged with a SIMPLE device developed by B. The = address book and presence rules should work with both clients same as = today I can use several XMPP clients from different vendors and all = work fine with the same contacts list. For example I have an Android = mobile device from one vendor and a MacOSX client from another vendor = and on XMPP this works. I cannot use them both for my account with = SIMPLE as they will both write different data according to their = interpretation of SIMPLE standards. The server implementor will also = have yet another way of interpreting the data. This triangle cannot be = reproduced with any combination of SIMPLE implementations but it can = with XMPP. > I don't view a presence conveyance as an addr-book. You need a = dedicated API - OMA was developing one on Converged Address Book 1.0. = You know the saying - to a carpenter everything is a 'hammer and nail = problem'! I studied OMA years ago and dropped it, as several assumptions made have = nothing to do with real world and how the Internet works, is a = interpretation that (could have) served closed silo-style Telco = infrastructures, and not end-points from public Internet. Not to = mention the complexity of OMA on top of an already complex foundation. > If that doesn't suit - then to me a RESTful approach may be the way to = go. What do you have in mind, can you give an example? >=20 > It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-work = solution. Not sure what that will achieve. >=20 > BR/Brian. > Sent from my BlackBerry device on the Rogers Wireless Network >=20 > -----Original Message----- > From: Adrian Georgescu > Date: Mon, 15 Oct 2012 15:46:14=20 > To: > Cc: ; > Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or = is it > an IETF failure? >=20 >=20 >=20 >=20 > On Oct 15, 2012, at 2:57 PM, Brian McColgan wrote: >=20 >=20 > My analysis indicates RLMI doesn't scale, but you/AG allude to an = interop issue with buddy lists. Can you be more specific and outline = the issue? >=20 >=20 >=20 > More specific. In SIP SIMPLE client Presence API we defined Group, = Contact and Policy classes each of them with add/delete/update methods = and eight notifications in total to manage the address book. Subscribing = to Presence for a contact and granting access to our own presence = information are booleans that can be set for each contact. To achieve = this simplicity, we had to write about 15K lines of code in a high level = programing language. >=20 >=20 > We do not have an IETF definition of such address book API, that any = programmer would understand, what we have instead are a number of XML = payloads, several event packages and xcap applications. Glueing all of = them is up to the developers and they end up in different places as you = have heard already from several developers. Secondly, without being able = to control the behavior of the server side, there is little chance a = generic SIMPLE client would work with any SIMPLE server as the = assumption are different and the incapability of the server to support = same features used by the client will render the client useless. We = could only do this because we were able to develop at the same time both = the presence client and presence agent side (OpenSIPS and OpenXCAP).=20 >=20 >=20 > XMPP has this approach where and both server and clients can implement = the same addressbook api without running into any interoperability = issues. >=20 >=20 > Adrian >=20 >=20 >=20 >=20 >=20 >=20 > In IMS, they are using pre-defined (i.e. Well known) buddy lists - = e.g. "rcs" for the list of RCS-capable users. But I don't think this is = what you are referring to. >=20 > BR/Brian. >=20 >> Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or = is it an IETF failure? >> From: oej@edvina.net =20 >> Date: Mon, 15 Oct 2012 08:50:32 +0200 >> CC: oej@edvina.net ; ag@ag-projects.com = =20 >> To: b_mccolgan@hotmail.com =20 >> =20 >> =20 >> 14 okt 2012 kl. 23:48 skrev "Brian McColgan " = >: >> =20 >> > Good luck with that Adrian. As I said 'IETF' doesn't get it. >> =20 >> Which takes us back to my original issue - can we get IETF to fix = SIMPLE? >> =20 >> /O >=20 From stpeter@stpeter.im Wed Oct 17 08:03:55 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A30721F8569 for ; Wed, 17 Oct 2012 08:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+RTgUx-DALb for ; Wed, 17 Oct 2012 08:03:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AE2E521F853D for ; Wed, 17 Oct 2012 08:03:54 -0700 (PDT) Received: from [64.101.72.58] (unknown [64.101.72.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BA3544010C; Wed, 17 Oct 2012 09:06:31 -0600 (MDT) Message-ID: <507EC13A.1060001@stpeter.im> Date: Wed, 17 Oct 2012 08:31:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> In-Reply-To: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:03:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/17/12 7:14 AM, Adrian Georgescu wrote: > Hi Brian, > > I keep this on the mailing list, hope you do not mind. > > On Oct 17, 2012, at 2:50 PM, Brian McColgan wrote: >> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE >> inter-work solution. Not sure what that will achieve. I don't know whether the IETF is plowing toward an interwork solution. All I know is that vendors and service providers who deploy SIMPLE-based systems often want to enable their users to communicate with users of XMPP-based systems (share presence, chat one-to-one, join chatrooms). If we define protocol mappings, such gateways will be easier to build and will work in more consistent ways. That seems like a good thing. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB+wToACgkQNL8k5A2w/vx1yACcDvKRP2BYGbejcKaASJOATguH hncAoOW4PFwPX1AMvd8NM+cjofprjuH9 =xkZl -----END PGP SIGNATURE----- From saul@ag-projects.com Wed Oct 17 08:26:08 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0309021F84F6 for ; Wed, 17 Oct 2012 08:26:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amjDTmSyF4En for ; Wed, 17 Oct 2012 08:26:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 74E4D21F8525 for ; Wed, 17 Oct 2012 08:26:07 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4F0ACB014D; Wed, 17 Oct 2012 17:26:05 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id B2B07B0079; Wed, 17 Oct 2012 17:26:05 +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: <507EC13A.1060001@stpeter.im> Date: Wed, 17 Oct 2012 17:26:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507EC13A.1060001@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Cc: "simple@ietf.org WG" Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:26:08 -0000 On Oct 17, 2012, at 4:31 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 10/17/12 7:14 AM, Adrian Georgescu wrote: >> Hi Brian, >>=20 >> I keep this on the mailing list, hope you do not mind. >>=20 >> On Oct 17, 2012, at 2:50 PM, Brian McColgan wrote: >=20 > >=20 >>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE=20 >>> inter-work solution. Not sure what that will achieve. >=20 > I don't know whether the IETF is plowing toward an interwork solution. > All I know is that vendors and service providers who deploy > SIMPLE-based systems often want to enable their users to communicate > with users of XMPP-based systems (share presence, chat one-to-one, > join chatrooms). If we define protocol mappings, such gateways will be > easier to build and will work in more consistent ways. That seems like > a good thing. >=20 Can't +1 this enough. -- Sa=FAl Ibarra Corretg=E9 AG Projects From mary.ietf.barnes@gmail.com Wed Oct 17 08:26:48 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3298221F8620 for ; Wed, 17 Oct 2012 08:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.385 X-Spam-Level: X-Spam-Status: No, score=-103.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsxQ95038XD8 for ; Wed, 17 Oct 2012 08:26:47 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F296021F85D5 for ; Wed, 17 Oct 2012 08:26:46 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so5775532lam.31 for ; Wed, 17 Oct 2012 08:26:45 -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=5vtydtKZue+wmk/usSm/+RaIsebRSiPts9wjzjmy+LA=; b=UT+rHAuOgK2m6HKsLesWc1vcBTNJI9ZS4FMcWIJ/8TzBJeY/hhu3gP7mvDANnq3p8S Iokrw+hM95Abyoy9Txtcd8d1wQFQp6oPC3UJIM8z3RhzuAN0KqQQQ7rObYp5nQUV/lUo I9aUu94/hZruoyy0JCnAPzi7GBU/0p7ojLvqjSl5VYnwOI/kBAaA7TBlB8bjQTO7+Ijf limyifBjpHhhD0HfM/zwsD60Uk+U+APM0P7/Rs4jpBW1413ZYb1N5U+Zr4Hn5z8EPKd9 TZvlb48yRbu8ZtjMWOaFHloNWWFL8LvRtord/7xmasrpQSp7+Abt4TV+Gv3+uSafvcj4 3wxg== MIME-Version: 1.0 Received: by 10.112.50.106 with SMTP id b10mr3644399lbo.122.1350487605616; Wed, 17 Oct 2012 08:26:45 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Wed, 17 Oct 2012 08:26:45 -0700 (PDT) In-Reply-To: <507EC13A.1060001@stpeter.im> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507EC13A.1060001@stpeter.im> Date: Wed, 17 Oct 2012 10:26:45 -0500 Message-ID: From: Mary Barnes To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=f46d0401fe5901a2b104cc42e617 Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:26:48 -0000 --f46d0401fe5901a2b104cc42e617 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 17, 2012 at 9:31 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/17/12 7:14 AM, Adrian Georgescu wrote: > > Hi Brian, > > > > I keep this on the mailing list, hope you do not mind. > > > > On Oct 17, 2012, at 2:50 PM, Brian McColgan wrote: > > > > >> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE > >> inter-work solution. Not sure what that will achieve. > > I don't know whether the IETF is plowing toward an interwork solution. > All I know is that vendors and service providers who deploy > SIMPLE-based systems often want to enable their users to communicate > with users of XMPP-based systems (share presence, chat one-to-one, > join chatrooms). If we define protocol mappings, such gateways will be > easier to build and will work in more consistent ways. That seems like > a good thing. > [MB] I totally agree! [/MB] > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlB+wToACgkQNL8k5A2w/vx1yACcDvKRP2BYGbejcKaASJOATguH > hncAoOW4PFwPX1AMvd8NM+cjofprjuH9 > =xkZl > -----END PGP SIGNATURE----- > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --f46d0401fe5901a2b104cc42e617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 17, 2012 at 9:31 AM, Peter S= aint-Andre <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/17/12 7:14 AM, Adrian Georgescu wrote:
> Hi Brian,
>
> I keep this on the mailing list, hope you do not mind.
>
> On Oct 17, 2012, at 2:50 PM, Brian McColgan wrote:

<snip/>

>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE
>> inter-work solution. =A0Not sure what that will achieve.

I don't know whether the IETF is plowing toward an interwork solu= tion.
All I know is that vendors and service providers who deploy
SIMPLE-based systems often want to enable their users to communicate
with users of XMPP-based systems (share presence, chat one-to-one,
join chatrooms). If we define protocol mappings, such gateways will be
easier to build and will work in more consistent ways. That seems like
a good thing.
[MB] I totally agree! [/MB]=A0

Peter

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlB+wToACgkQNL8k5A2w/vx1yACcDvKRP2BYGbejcKaASJOATguH
hncAoOW4PFwPX1AMvd8NM+cjofprjuH9
=3DxkZl
-----END PGP SIGNATURE-----
___________________________________= ____________
Simple mailing list
Simple@ietf.org
= https://www.ietf.org/mailman/listinfo/simple

--f46d0401fe5901a2b104cc42e617-- From ibc@aliax.net Wed Oct 17 08:42:49 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A618721F8595 for ; Wed, 17 Oct 2012 08:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+SobaldWomG for ; Wed, 17 Oct 2012 08:42:48 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB5A21F86CE for ; Wed, 17 Oct 2012 08:42:48 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so5788929lam.31 for ; Wed, 17 Oct 2012 08:42:42 -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=jgQdzfBlahzfb3qbGAb1HMS/gGVDYOIZaNxI0rv+n6Y=; b=oBqxVxKmSazj++x6PDa4LzFoMdLKmpsSXNoL7f0UconqJE8IY6ivTzV+u+ypJ/o46e Di00IJ3xT8FeLTY5jD12/lDdS+jbZdj2xWXTw56PXoCNV6IhGqm3/pMqmdlU6WgxGfwQ Ingdzb1R/Dzj3UYJ3cx4rgSS+nM6QvqUto9crGgpGgG3HqtNwKC+8i3QGbfZjchpnZT3 KCjaWIlXZdD3m5PgMECZYAEXkOQrVL0i3fFHdENo9pixypYiMcdp2aqJC1vWUWrb/LQd 4OI7+3GVZvNILYGa8bCdZ4ABjHFwuZE8yW1N4A3VS5P9mv/dU+C5Jf6jtH0PYSrCX6a/ cSKA== Received: by 10.112.29.129 with SMTP id k1mr6992302lbh.102.1350488562418; Wed, 17 Oct 2012 08:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Wed, 17 Oct 2012 08:42:22 -0700 (PDT) In-Reply-To: <507EC13A.1060001@stpeter.im> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507EC13A.1060001@stpeter.im> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 17 Oct 2012 17:42:22 +0200 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmylpnz2XEBchMzgsSF+L8zliR93Kr6tQVPQmf0QHsZCeeFjJL9Ok7afrlKOlFdP1Oq92kn Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:42:49 -0000 2012/10/17 Peter Saint-Andre : >>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE >>> inter-work solution. Not sure what that will achieve. > > I don't know whether the IETF is plowing toward an interwork solution. > All I know is that vendors and service providers who deploy > SIMPLE-based systems often want to enable their users to communicate > with users of XMPP-based systems (share presence, chat one-to-one, > join chatrooms). If we define protocol mappings, such gateways will be > easier to build and will work in more consistent ways. That seems like > a good thing. Hi Peter, I think this thread is not about SIMPLE/XMPP interoperability (which is good) but about SIMPLE/SIMPLE interoperability. With the current IETF SIMPLE specs is just impossible that two SIP vendors that build generic SIP devices will interoperate for sharing a simple addressbook by using a generic SIMPLE/XCAP server made by any other vendor. And this is just because the RFC's don't define the exact format of the XML files to use, so each vendor follows its own interpretation. Said that, there is also no way for storing info other than "dislplay-name" and "uri" per buddy so we DO NOT have a "addressbook" in SIMPLE/XCAP, at least not in the IETF documents (and I don't think that I should follow OMA/3GPP specs designed for telco networks if I code a generic and open source SIP client for the open Internet). So, before attempting to interoperate with XMPP I think SIP should be able to interoperate with itself in a generic IP network (out of walled gardens in which vendors have full control over servers and clients, and can design their required extra layers on top of the IETF specs to complete the puzzle). Regards. --=20 I=C3=B1aki Baz Castillo From ben@nostrum.com Wed Oct 17 08:48:37 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC83E21F852A for ; Wed, 17 Oct 2012 08:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHs04mlF24rO for ; Wed, 17 Oct 2012 08:48:37 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D7F3B21F851C for ; Wed, 17 Oct 2012 08:48:36 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9HFmLed086536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2012 10:48:21 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Wed, 17 Oct 2012 10:48:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507EC13A.1060001@stpeter.im> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:48:37 -0000 On Oct 17, 2012, at 10:42 AM, I=F1aki Baz Castillo = wrote: > Hi Peter, I think this thread is not about SIMPLE/XMPP > interoperability (which is good) but about SIMPLE/SIMPLE > interoperability. It looks to me that the thread has forked into both discussions. Perhaps = people could adjust their subject lines? Thanks! Ben.= From oej@edvina.net Wed Oct 17 11:22:42 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C4E21F86AA for ; Wed, 17 Oct 2012 11:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbUOhbwqnHtY for ; Wed, 17 Oct 2012 11:22:42 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 1B50421F86A7 for ; Wed, 17 Oct 2012 11:22:41 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 79EEE754A8A7; Wed, 17 Oct 2012 18:22:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> Date: Wed, 17 Oct 2012 20:22:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> To: Adrian Georgescu X-Mailer: Apple Mail (2.1499) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:22:42 -0000 17 okt 2012 kl. 15:14 skrev Adrian Georgescu : >> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-work = solution. Not sure what that will achieve. That's fine, but a separate project. If the only way we can get = interoperability between SIMPLE implentations is using XMPP between = them, that feels like a stupid solution to me. I do want to be able to = use SIMPLE to communicate with other SIMPLE implementations. I want to = be able to use one SIMPLE client from one vendor on my smartphone and = share the address book/buddy list and presence ruleset with my other = SIMPLE client on the desktop. That's what customers expect. And that's not where we are today with the = IETF specs, and if I parse right, maybe not with the inclusion of the = 3rd party OMA specs. /O= From mary.ietf.barnes@gmail.com Wed Oct 17 11:56:15 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2B121F8682 for ; Wed, 17 Oct 2012 11:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.387 X-Spam-Level: X-Spam-Status: No, score=-103.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccUnxqLE2CIi for ; Wed, 17 Oct 2012 11:56:14 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36E3D21F8595 for ; Wed, 17 Oct 2012 11:56:14 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so5998371lbo.31 for ; Wed, 17 Oct 2012 11:56:13 -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=c5mRH2jWr2zmAqKEzBM4kPEm9IP/cKG/fS3C5dNZXvY=; b=KPwFzGADeyyiYTqRRZ0NDQ1XQjkht36iK1W9UabwTUL/pwSXdue4wjUR+/OEoS9jAU OK5LBa7Qzf/CWDIssZTheW60Xlxmjw/nTn4QyaQNAYHFE0tMTPtuBC1mb4xBhenDOPbK 91Xqf14clDYL487U3HHFJV3b/eKlsnQ7XBtCNOBR0Br2uHKLerwL2fW00gqS1JRgLHDU wJaexNIb/CJHZAM7IywIwwAb11CIqwT1P+oYjdHF7FB+FguT0k1ltsVUMcE8iFm0Jbji GLGCN30DhRKJt5bwwDypDhfJhj5G3u8XRxUGjOL6J1gnG4phCeiY2UmlBEEK1dTHAQgV Y2HA== MIME-Version: 1.0 Received: by 10.112.38.65 with SMTP id e1mr7318486lbk.15.1350500172996; Wed, 17 Oct 2012 11:56:12 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Wed, 17 Oct 2012 11:56:12 -0700 (PDT) In-Reply-To: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> Date: Wed, 17 Oct 2012 13:56:12 -0500 Message-ID: From: Mary Barnes To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=e0cb4efe3118149f6704cc45d39c Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:56:15 -0000 --e0cb4efe3118149f6704cc45d39c Content-Type: text/plain; charset=ISO-8859-1 I agree it's silliness that SIMPLE implementations have interop issues right now. I think the SIP-XMPP is further along that SIMPLE-SIMPLE. I think that's because XMPP was done before SIMPLE - it's a matter of a market decisions -i.e, jabber was available way before SIMPLE. However, it now seems that there are some deployments (e.g., Hannes' emergency services scenario) that require SIMPLE-SIMPLE. I think we might be able to learn from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE to work for the lowest common denominator situations. I think the starting point for the latter is to identify the current set of interop issues and determine whether it's due to gaps in the specs or implementation decisions (as Olle suggested at the beginning of this thread). Mary. On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson wrote: > > 17 okt 2012 kl. 15:14 skrev Adrian Georgescu : > > >> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-work > solution. Not sure what that will achieve. > > That's fine, but a separate project. If the only way we can get > interoperability between SIMPLE implentations is using XMPP between them, > that feels like a stupid solution to me. I do want to be able to use SIMPLE > to communicate with other SIMPLE implementations. I want to be able to use > one SIMPLE client from one vendor on my smartphone and share the address > book/buddy list and presence ruleset with my other SIMPLE client on the > desktop. > > That's what customers expect. And that's not where we are today with the > IETF specs, and if I parse right, maybe not with the inclusion of the 3rd > party OMA specs. > > /O > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --e0cb4efe3118149f6704cc45d39c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree it's silliness that SIMPLE implementations have interop issues = right now. =A0I think the SIP-XMPP is further along that SIMPLE-SIMPLE. =A0= I think that's because XMPP was done before SIMPLE - it's a matter = of a market decisions -i.e, jabber was available way before SIMPLE. =A0Howe= ver, it now seems that there are some deployments (e.g., Hannes' emerge= ncy services scenario) that require SIMPLE-SIMPLE. I think we might be able= to learn from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE t= o work for the lowest common denominator situations. =A0I think the startin= g point for the latter is to identify the current set of interop issues and= determine whether it's due to gaps in the specs or implementation deci= sions (as Olle suggested at the beginning of this thread).

Mary.=A0

On Wed, Oct 17, 2012 at= 1:22 PM, Olle E. Johansson <oej@edvina.net> wrote:

17 okt 2012 kl. 15:14 skrev Adrian Georgescu <ag@ag-projects.com>:

>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-w= ork solution. =A0Not sure what that will achieve.

That's fine, but a separate project. If the only way we can get i= nteroperability between SIMPLE implentations is using XMPP between them, th= at feels like a stupid solution to me. I do want to be able to use SIMPLE t= o communicate with other SIMPLE implementations. I want to be able to use o= ne SIMPLE client from one vendor on my smartphone and share the address boo= k/buddy list and presence ruleset with my other SIMPLE client on the deskto= p.

That's what customers expect. And that's not where we are today wit= h the IETF specs, and if I parse right, maybe not with the inclusion of the= 3rd party OMA specs.

/O
_______________________________________________
Simple mailing list
Simple@ietf.org
= https://www.ietf.org/mailman/listinfo/simple

--e0cb4efe3118149f6704cc45d39c-- From ag@ag-projects.com Wed Oct 17 12:13:05 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC77C21F8639 for ; Wed, 17 Oct 2012 12:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AK4SUATEhMr for ; Wed, 17 Oct 2012 12:13:04 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8436D21F8659 for ; Wed, 17 Oct 2012 12:13:04 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AD98DB014D; Wed, 17 Oct 2012 21:13:02 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id A8B50B00F7; Wed, 17 Oct 2012 21:12:49 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Adrian Georgescu In-Reply-To: Date: Wed, 17 Oct 2012 21:12:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> To: Olle Johansson , "simple@ietf.org WG" X-Mailer: Apple Mail (2.1283) Subject: [Simple] SIP SIMPLE end-point addressbook application X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 19:13:05 -0000 Hi Olle, I changed the original subject, as we all like success stories rather = than failures. For Blink in particular, we developed a simple (pardon the over abused = word) to use AddressBook schema where one can store Contacts with = multiple URIs of different types and arbitrary attribute-value pairs = that the User Agent may need to store per contact plus a way to Group = them together. To subscribe for presence to a contact and provide a = policy one can set boolean values that any developer not familiar with = the SIP protocol mechanics should be able to use. Information that is = proprietary to end-points made by a vendor can be stored, atomically and = in a way that does not collide with the desires of other vendors. The schema is documented here: = http://sipsimpleclient.com/projects/sipsimpleclient/repository/entry/sipsi= mple/payloads/xml-schemas/addressbook.xsd An actual implementation in Python is available here; = http://sipsimpleclient.com/projects/sipsimpleclient/repository/changes/sip= simple/payloads/addressbook.py To eliminate the complexity and eliminate the non-atomicity of having to = use several XCAP documents like rls-services, resource-lists and = pres-rules for storing these information.=20 I propose to define, part of a further standardization effort of SIMPLE = or another IETF WG that is chartered for this purpose, the SIP SIMPLE = end-point addressbook application, an application that can be used both = by end-points and the Presence Agent for obtaining the policy for = subscribing to one's presence. This way, we can achieve two goals closely related to SIMPLE charter: 1. Any SIP end-point developer can develop its own SIMPLE implementation = perfectly inter-operable with any other SIMPLE end-point and compatible = at the same time with the server side, the presence agent. 2. As interest with XMPP is on the rise, we can now capture all gateway = features that will make the interoperability with XMPP 100% defined and = proven by open source implementations For those who do not adhere or care about such high-level API, they may = continue to use at their discretion the low-level building blocks = already in place as nothing will change on-the-wire between domains or = within the same domain as far as SIP signaling is concerned. Shall these goals be considered a desirable outcome for SIMPLE, in the = old tradition of good ideas backed not just be empty words but by open = source implementations, there might be a chance to turn SIMPLE into a = success story. Feedback is welcome. Adrian =20 On Oct 17, 2012, at 8:22 PM, Olle E. Johansson wrote: >=20 > 17 okt 2012 kl. 15:14 skrev Adrian Georgescu : >=20 >>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE = inter-work solution. Not sure what that will achieve. >=20 > That's fine, but a separate project. If the only way we can get = interoperability between SIMPLE implentations is using XMPP between = them, that feels like a stupid solution to me. I do want to be able to = use SIMPLE to communicate with other SIMPLE implementations. I want to = be able to use one SIMPLE client from one vendor on my smartphone and = share the address book/buddy list and presence ruleset with my other = SIMPLE client on the desktop. >=20 > That's what customers expect. And that's not where we are today with = the IETF specs, and if I parse right, maybe not with the inclusion of = the 3rd party OMA specs. >=20 > /O > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From oej@edvina.net Wed Oct 17 12:47:10 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D706021F86B6 for ; Wed, 17 Oct 2012 12:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PaONoNgj7Yb for ; Wed, 17 Oct 2012 12:47:09 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 831E121F85B8 for ; Wed, 17 Oct 2012 12:47:08 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5674C754A8A7; Wed, 17 Oct 2012 19:47:07 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_068A5982-09E1-4FD0-B8B0-FD9CB8188EFA" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 17 Oct 2012 21:47:06 +0200 Message-Id: <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> To: Mary Barnes X-Mailer: Apple Mail (2.1499) Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 19:47:10 -0000 --Apple-Mail=_068A5982-09E1-4FD0-B8B0-FD9CB8188EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 17 okt 2012 kl. 20:56 skrev Mary Barnes : > I agree it's silliness that SIMPLE implementations have interop issues = right now. I think the SIP-XMPP is further along that SIMPLE-SIMPLE. I = think that's because XMPP was done before SIMPLE - it's a matter of a = market decisions -i.e, jabber was available way before SIMPLE. However, = it now seems that there are some deployments (e.g., Hannes' emergency = services scenario) that require SIMPLE-SIMPLE. I think we might be able = to learn from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE = to work for the lowest common denominator situations. I think the = starting point for the latter is to identify the current set of interop = issues and determine whether it's due to gaps in the specs or = implementation decisions (as Olle suggested at the beginning of this = thread). >=20 Mary, Thanks for your response. While it feels strange to suggest a focus on = SIMPLE-to-SIMPLE interoperability, something that should have been there = before, I think that's exactly what we need.=20 All others following this list: Please add your thoughts, possibly details (like I=F1aki, Saul and = Adrian have done) in mail to this mailing list. With that information, = we can try to put together a document on "Issues in SIMPLE-SIMPLE = interoperability" that can be the platform for continued work to solve = issues. Pour it out to the mail archives! Maybe we should try to define "SIMPLE" here. What I meant in the start = of this discussion was a plaform using SIP "presence" event package, = using XCAP for buddy lists and presence rules. (I might have missed = something, so please add). I would add that we should limit the = definition to documents published by the IETF as RFCs in order to stay = in focus. If there are things clearly missing in the RFCs, point this = out clearly. If you've missed the previous detailed postings in this thread, they're = available in the mail archive for you to catch up. Let's go. /O > Mary.=20 >=20 > On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson = wrote: >=20 > 17 okt 2012 kl. 15:14 skrev Adrian Georgescu : >=20 > >> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE = inter-work solution. Not sure what that will achieve. >=20 > That's fine, but a separate project. If the only way we can get = interoperability between SIMPLE implentations is using XMPP between = them, that feels like a stupid solution to me. I do want to be able to = use SIMPLE to communicate with other SIMPLE implementations. I want to = be able to use one SIMPLE client from one vendor on my smartphone and = share the address book/buddy list and presence ruleset with my other = SIMPLE client on the desktop. >=20 > That's what customers expect. And that's not where we are today with = the IETF specs, and if I parse right, maybe not with the inclusion of = the 3rd party OMA specs. >=20 > /O > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 --Apple-Mail=_068A5982-09E1-4FD0-B8B0-FD9CB8188EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 mary.ietf.barnes@gmail.com&= gt;:

I agree it's silliness that SIMPLE implementations have = interop issues right now.  I think the SIP-XMPP is further along = that SIMPLE-SIMPLE.  I think that's because XMPP was done before = SIMPLE - it's a matter of a market decisions -i.e, jabber was available = way before SIMPLE.  However, it now seems that there are some = deployments (e.g., Hannes' emergency services scenario) that require = SIMPLE-SIMPLE. I think we might be able to learn from the SIP-XMPP - = i.e., at least try to get the SIMPLE-SIMPLE to work for the lowest = common denominator situations.  I think the starting point for the = latter is to identify the current set of interop issues and determine = whether it's due to gaps in the specs or implementation decisions (as = Olle suggested at the beginning of this thread).


Mary,
Thanks for = your response. While it feels strange to suggest a focus on = SIMPLE-to-SIMPLE interoperability, something that should have been there = before, I think that's exactly what we = need. 

All others following this = list:

Please add your thoughts, possibly = details (like I=F1aki, Saul and Adrian have done) in mail to this = mailing list. With that information, we can try to put together a = document on "Issues in SIMPLE-SIMPLE interoperability" that can be the = platform for continued work to solve issues. Pour it out to the mail = archives!

Maybe we should try to define = "SIMPLE" here. What I meant in the start of this discussion was a = plaform using SIP "presence" event package, using XCAP for buddy lists = and presence rules. (I might have missed something, so please add). =  I would add that we should limit the definition to documents = published by the IETF as RFCs in order to stay in focus. If there are = things clearly missing in the RFCs, point this out = clearly.

If you've missed the previous detailed = postings in this thread, they're available in the mail archive for you = to catch up.

Let's = go.

/O


Mary. 

On = Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson <oej@edvina.net> wrote:

17 okt 2012 kl. 15:14 skrev Adrian Georgescu <ag@ag-projects.com>:

>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE = inter-work solution.  Not sure what that will achieve.

That's fine, but a separate project. If the only way we can get = interoperability between SIMPLE implentations is using XMPP between = them, that feels like a stupid solution to me. I do want to be able to = use SIMPLE to communicate with other SIMPLE implementations. I want to = be able to use one SIMPLE client from one vendor on my smartphone and = share the address book/buddy list and presence ruleset with my other = SIMPLE client on the desktop.

That's what customers expect. And that's not where we are today with the = IETF specs, and if I parse right, maybe not with the inclusion of the = 3rd party OMA specs.

/O
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple


= --Apple-Mail=_068A5982-09E1-4FD0-B8B0-FD9CB8188EFA-- From ag@ag-projects.com Wed Oct 17 13:01:29 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79121F86CF for ; Wed, 17 Oct 2012 13:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lNVHcPycmZv for ; Wed, 17 Oct 2012 13:01:28 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A7AF921F86C5 for ; Wed, 17 Oct 2012 13:01:27 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id CB4A5B014F; Wed, 17 Oct 2012 22:01:26 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id C06AFB0079; Wed, 17 Oct 2012 22:01:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF485F1930@ucolhp9h.easf.csd.disa.mil> Date: Wed, 17 Oct 2012 22:01:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> <8486C8728176924BAF5BDB2F7D7EEDDF485F1930@ucolhp9h.easf.csd.disa.mil> To: "Roy, Radhika R CIV (US)" X-Mailer: Apple Mail (2.1283) Cc: Mary Barnes , "simple@ietf.org" Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:01:29 -0000 With. 2. On Oct 17, 2012, at 9:59 PM, Roy, Radhika R CIV (US) wrote: > Folks: >=20 > I do not know which scenarios for SIMPLE-XMPP interworking are taken = into > account: >=20 > 1. SIMPLE-XMPP without integration with audio and/or video? >=20 > 2. SIP/SIMPLE-XMPP with integration with audio and/or video? >=20 > Scenario 1 may be considered for an historical reason because XMPP = came > first. >=20 > Scenario 2 will not be useful from practical point of view because SIP = for > audio/video is firmly established in the market place and addition of > SIMPLE/Chat/IM does not cost anything. Interworking GW is unacceptable = from > scalability and security point of view. >=20 > BR/Radhika >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of > Olle E. Johansson > Sent: Wednesday, October 17, 2012 3:47 PM > To: Mary Barnes > Cc: Adrian Georgescu; simple@ietf.org > Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability >=20 >=20 > 17 okt 2012 kl. 20:56 skrev Mary Barnes : >=20 >=20 > I agree it's silliness that SIMPLE implementations have interop > issues right now. I think the SIP-XMPP is further along that = SIMPLE-SIMPLE. > I think that's because XMPP was done before SIMPLE - it's a matter of = a > market decisions -i.e, jabber was available way before SIMPLE. = However, it > now seems that there are some deployments (e.g., Hannes' emergency = services > scenario) that require SIMPLE-SIMPLE. I think we might be able to = learn from > the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE to work for = the > lowest common denominator situations. I think the starting point for = the > latter is to identify the current set of interop issues and determine > whether it's due to gaps in the specs or implementation decisions (as = Olle > suggested at the beginning of this thread). >=20 >=20 >=20 > Mary, > Thanks for your response. While it feels strange to suggest a focus on > SIMPLE-to-SIMPLE interoperability, something that should have been = there > before, I think that's exactly what we need.=20 >=20 > All others following this list: >=20 > Please add your thoughts, possibly details (like I=F1aki, Saul and = Adrian have > done) in mail to this mailing list. With that information, we can try = to put > together a document on "Issues in SIMPLE-SIMPLE interoperability" that = can > be the platform for continued work to solve issues. Pour it out to the = mail > archives! >=20 > Maybe we should try to define "SIMPLE" here. What I meant in the start = of > this discussion was a plaform using SIP "presence" event package, = using XCAP > for buddy lists and presence rules. (I might have missed something, so > please add). I would add that we should limit the definition to = documents > published by the IETF as RFCs in order to stay in focus. If there are = things > clearly missing in the RFCs, point this out clearly. >=20 > If you've missed the previous detailed postings in this thread, = they're > available in the mail archive for you to catch up. >=20 > Let's go. >=20 > /O >=20 >=20 >=20 > Mary.=20 > =09 > =09 > On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson = > wrote: > =09 >=20 >=20 > 17 okt 2012 kl. 15:14 skrev Adrian Georgescu > : > =09 >=20 > >> It seems however IETF is plowing toward an > XMPP/SIP-SIMPLE inter-work solution. Not sure what that will achieve. > =09 > =09 > That's fine, but a separate project. If the only way we = can > get interoperability between SIMPLE implentations is using XMPP = between > them, that feels like a stupid solution to me. I do want to be able to = use > SIMPLE to communicate with other SIMPLE implementations. I want to be = able > to use one SIMPLE client from one vendor on my smartphone and share = the > address book/buddy list and presence ruleset with my other SIMPLE = client on > the desktop. > =09 > That's what customers expect. And that's not where we = are > today with the IETF specs, and if I parse right, maybe not with the > inclusion of the 3rd party OMA specs. > =09 >=20 > /O > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > =20 > =09 >=20 >=20 >=20 From ag@ag-projects.com Wed Oct 17 13:08:08 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307EA21F86E2 for ; Wed, 17 Oct 2012 13:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUHkmEjIQ9bf for ; Wed, 17 Oct 2012 13:08:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC7C21F86E0 for ; Wed, 17 Oct 2012 13:08:07 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 006A5B014F; Wed, 17 Oct 2012 22:08:05 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 66584B0079; Wed, 17 Oct 2012 22:07:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: Date: Wed, 17 Oct 2012 22:07:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BE5778F-5A1F-4404-9C3D-539A3BB1ACA2@ag-projects.com> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> <8486C8728176924BAF5BDB2F7D7EEDDF485F1930@ucolhp9h.easf.csd.disa.mil> To: "Roy, Radhika R CIV (US)" X-Mailer: Apple Mail (2.1283) Cc: Mary Barnes , "simple@ietf.org" Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:08:08 -0000 To augment the reasoning for being practical. RTP media path uses ICE, which impose little to no burden on the = SIP/XMPP gateway itself, the TURN servers of each domain are carrying = the load burden in the worst case scenario when end-points cannot find a = more direct media path. Adrian On Oct 17, 2012, at 10:01 PM, Adrian Georgescu wrote: > With. >=20 > 2. >=20 >=20 > On Oct 17, 2012, at 9:59 PM, Roy, Radhika R CIV (US) wrote: >=20 >> Folks: >>=20 >> I do not know which scenarios for SIMPLE-XMPP interworking are taken = into >> account: >>=20 >> 1. SIMPLE-XMPP without integration with audio and/or video? >>=20 >> 2. SIP/SIMPLE-XMPP with integration with audio and/or video? >>=20 >> Scenario 1 may be considered for an historical reason because XMPP = came >> first. >>=20 >> Scenario 2 will not be useful from practical point of view because = SIP for >> audio/video is firmly established in the market place and addition of >> SIMPLE/Chat/IM does not cost anything. Interworking GW is = unacceptable from >> scalability and security point of view. >>=20 >> BR/Radhika >>=20 >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of >> Olle E. Johansson >> Sent: Wednesday, October 17, 2012 3:47 PM >> To: Mary Barnes >> Cc: Adrian Georgescu; simple@ietf.org >> Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability >>=20 >>=20 >> 17 okt 2012 kl. 20:56 skrev Mary Barnes : >>=20 >>=20 >> I agree it's silliness that SIMPLE implementations have interop >> issues right now. I think the SIP-XMPP is further along that = SIMPLE-SIMPLE. >> I think that's because XMPP was done before SIMPLE - it's a matter of = a >> market decisions -i.e, jabber was available way before SIMPLE. = However, it >> now seems that there are some deployments (e.g., Hannes' emergency = services >> scenario) that require SIMPLE-SIMPLE. I think we might be able to = learn from >> the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE to work = for the >> lowest common denominator situations. I think the starting point for = the >> latter is to identify the current set of interop issues and determine >> whether it's due to gaps in the specs or implementation decisions (as = Olle >> suggested at the beginning of this thread). >>=20 >>=20 >>=20 >> Mary, >> Thanks for your response. While it feels strange to suggest a focus = on >> SIMPLE-to-SIMPLE interoperability, something that should have been = there >> before, I think that's exactly what we need.=20 >>=20 >> All others following this list: >>=20 >> Please add your thoughts, possibly details (like I=F1aki, Saul and = Adrian have >> done) in mail to this mailing list. With that information, we can try = to put >> together a document on "Issues in SIMPLE-SIMPLE interoperability" = that can >> be the platform for continued work to solve issues. Pour it out to = the mail >> archives! >>=20 >> Maybe we should try to define "SIMPLE" here. What I meant in the = start of >> this discussion was a plaform using SIP "presence" event package, = using XCAP >> for buddy lists and presence rules. (I might have missed something, = so >> please add). I would add that we should limit the definition to = documents >> published by the IETF as RFCs in order to stay in focus. If there are = things >> clearly missing in the RFCs, point this out clearly. >>=20 >> If you've missed the previous detailed postings in this thread, = they're >> available in the mail archive for you to catch up. >>=20 >> Let's go. >>=20 >> /O >>=20 >>=20 >>=20 >> Mary.=20 >> =09 >> =09 >> On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson = >> wrote: >> =09 >>=20 >>=20 >> 17 okt 2012 kl. 15:14 skrev Adrian Georgescu >> : >> =09 >>=20 >> >> It seems however IETF is plowing toward an >> XMPP/SIP-SIMPLE inter-work solution. Not sure what that will = achieve. >> =09 >> =09 >> That's fine, but a separate project. If the only way we = can >> get interoperability between SIMPLE implentations is using XMPP = between >> them, that feels like a stupid solution to me. I do want to be able = to use >> SIMPLE to communicate with other SIMPLE implementations. I want to be = able >> to use one SIMPLE client from one vendor on my smartphone and share = the >> address book/buddy list and presence ruleset with my other SIMPLE = client on >> the desktop. >> =09 >> That's what customers expect. And that's not where we = are >> today with the IETF specs, and if I parse right, maybe not with the >> inclusion of the 3rd party OMA specs. >> =09 >>=20 >> /O >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> =20 >> =09 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From pkyzivat@alum.mit.edu Wed Oct 17 13:20:19 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9721F86B6 for ; Wed, 17 Oct 2012 13:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVCcewhflTKZ for ; Wed, 17 Oct 2012 13:20:18 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 5B06421F8698 for ; Wed, 17 Oct 2012 13:20:18 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id CBT91k0050ldTLk54LLNx7; Wed, 17 Oct 2012 20:20:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id CLF51k00z3ZTu2S3QLF55C; Wed, 17 Oct 2012 20:15:06 +0000 Message-ID: <507F11D4.6080104@alum.mit.edu> Date: Wed, 17 Oct 2012 16:15:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> In-Reply-To: <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:20:19 -0000 On 10/17/12 3:47 PM, Olle E. Johansson wrote: > All others following this list: > > Please add your thoughts, possibly details (like Iñaki, Saul and Adrian > have done) in mail to this mailing list. With that information, we can > try to put together a document on "Issues in SIMPLE-SIMPLE > interoperability" that can be the platform for continued work to solve > issues. Pour it out to the mail archives! ISTM that SIMPLE has two clearly separate parts: presence and IM. The interop issues for the two are very different. I think most of the issues are wrt presence. This applies to both simple-simple and simple-xmpp. The one point where there is commonality is around the URIs - sip: vs. xmpp:. For instance, for simple-xmpp interop for ecrit, I think only the IM part is critical, and that should be the easier part. Thanks, Paul From ag@ag-projects.com Wed Oct 17 13:29:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645B421F8661 for ; Wed, 17 Oct 2012 13:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TX1cY35qp2F for ; Wed, 17 Oct 2012 13:29:51 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4872221F861C for ; Wed, 17 Oct 2012 13:29:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8E641B014F; Wed, 17 Oct 2012 22:29:50 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 4D43FB0067; Wed, 17 Oct 2012 22:29:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <507F11D4.6080104@alum.mit.edu> Date: Wed, 17 Oct 2012 22:29:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23950D5E-A4D5-4DF7-A4CF-9D261B9FA5AF@ag-projects.com> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> <507F11D4.6080104@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:29:52 -0000 Hi Paul, You are analyzing things in terms of one to one dialogs. This is a bit wrong, and don't take this personally. Presence requires a multiple set of dialogs between each end-point and = the Presence Agent and between themselves on a logical level. You are right that the interop issue are very different but your = juxtaposed the actors. Presence is the most complicated part of it all, it involves at least = twelve of such dialogs when I do a napkin drawing. Which is at least one = order of magnitude more complicated then doing a MSRP file transfer or = an RTP video session. =20 Adrian On Oct 17, 2012, at 10:15 PM, Paul Kyzivat wrote: > On 10/17/12 3:47 PM, Olle E. Johansson wrote: >=20 >> All others following this list: >>=20 >> Please add your thoughts, possibly details (like I=F1aki, Saul and = Adrian >> have done) in mail to this mailing list. With that information, we = can >> try to put together a document on "Issues in SIMPLE-SIMPLE >> interoperability" that can be the platform for continued work to = solve >> issues. Pour it out to the mail archives! >=20 > ISTM that SIMPLE has two clearly separate parts: presence and IM. > The interop issues for the two are very different. I think most of the = issues are wrt presence. This applies to both simple-simple and = simple-xmpp. >=20 > The one point where there is commonality is around the URIs - sip: vs. = xmpp:. >=20 > For instance, for simple-xmpp interop for ecrit, I think only the IM = part is critical, and that should be the easier part. >=20 > Thanks, > Paul >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From radhika.r.roy.civ@mail.mil Wed Oct 17 12:57:25 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE1821F8671 for ; Wed, 17 Oct 2012 12:57:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf3+sYPSi8z8 for ; Wed, 17 Oct 2012 12:57:24 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA9921F861D for ; Wed, 17 Oct 2012 12:57:23 -0700 (PDT) Received: from UCOLHP2X.easf.csd.disa.mil (131.64.100.142) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 17 Oct 2012 19:59:10 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.175]) by UCOLHP2X.easf.csd.disa.mil ([131.64.100.142]) with mapi id 14.02.0309.003; Wed, 17 Oct 2012 19:59:10 +0000 From: "Roy, Radhika R CIV (US)" To: "Olle E. Johansson" , Mary Barnes Thread-Topic: [Simple] Focusing on SIMPLE-SIMPLE interoperability Thread-Index: AQHNrKCJE6M24VSb0EelylJ/0bgl3pe957zQ Date: Wed, 17 Oct 2012 19:59:09 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF485F1930@ucolhp9h.easf.csd.disa.mil> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> In-Reply-To: <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D0_01CDAC80.0BB67270" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 17 Oct 2012 13:34:16 -0700 Cc: Adrian Georgescu , "simple@ietf.org" Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 19:57:25 -0000 ------=_NextPart_000_00D0_01CDAC80.0BB67270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks: I do not know which scenarios for SIMPLE-XMPP interworking are taken = into account: 1. SIMPLE-XMPP without integration with audio and/or video? 2. SIP/SIMPLE-XMPP with integration with audio and/or video? Scenario 1 may be considered for an historical reason because XMPP came first. Scenario 2 will not be useful from practical point of view because SIP = for audio/video is firmly established in the market place and addition of SIMPLE/Chat/IM does not cost anything. Interworking GW is unacceptable = from scalability and security point of view. BR/Radhika -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Olle E. Johansson Sent: Wednesday, October 17, 2012 3:47 PM To: Mary Barnes Cc: Adrian Georgescu; simple@ietf.org Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability 17 okt 2012 kl. 20:56 skrev Mary Barnes : I agree it's silliness that SIMPLE implementations have interop issues right now. I think the SIP-XMPP is further along that = SIMPLE-SIMPLE. I think that's because XMPP was done before SIMPLE - it's a matter of a market decisions -i.e, jabber was available way before SIMPLE. However, = it now seems that there are some deployments (e.g., Hannes' emergency = services scenario) that require SIMPLE-SIMPLE. I think we might be able to learn = from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE to work for = the lowest common denominator situations. I think the starting point for = the latter is to identify the current set of interop issues and determine whether it's due to gaps in the specs or implementation decisions (as = Olle suggested at the beginning of this thread). Mary, Thanks for your response. While it feels strange to suggest a focus on SIMPLE-to-SIMPLE interoperability, something that should have been there before, I think that's exactly what we need.=20 All others following this list: Please add your thoughts, possibly details (like I=F1aki, Saul and = Adrian have done) in mail to this mailing list. With that information, we can try to = put together a document on "Issues in SIMPLE-SIMPLE interoperability" that = can be the platform for continued work to solve issues. Pour it out to the = mail archives! Maybe we should try to define "SIMPLE" here. What I meant in the start = of this discussion was a plaform using SIP "presence" event package, using = XCAP for buddy lists and presence rules. (I might have missed something, so please add). I would add that we should limit the definition to = documents published by the IETF as RFCs in order to stay in focus. If there are = things clearly missing in the RFCs, point this out clearly. If you've missed the previous detailed postings in this thread, they're available in the mail archive for you to catch up. Let's go. /O Mary.=20 =09 =09 On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson wrote: =09 17 okt 2012 kl. 15:14 skrev Adrian Georgescu : =09 >> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-work solution. Not sure what that will achieve. =09 =09 That's fine, but a separate project. If the only way we can get interoperability between SIMPLE implentations is using XMPP between them, that feels like a stupid solution to me. I do want to be able to = use SIMPLE to communicate with other SIMPLE implementations. I want to be = able to use one SIMPLE client from one vendor on my smartphone and share the address book/buddy list and presence ruleset with my other SIMPLE client = on the desktop. =09 That's what customers expect. And that's not where we are today with the IETF specs, and if I parse right, maybe not with the inclusion of the 3rd party OMA specs. =09 /O _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple =20 =09 ------=_NextPart_000_00D0_01CDAC80.0BB67270 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjEwMTcxOTU3MDFaMCMGCSqGSIb3DQEJBDEWBBQBik/3URUeqeymF+Z5mggy gTV9SjBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBADc5qD1Lc6+ct5fShF0KSTpc18F2uLPm9azoeIL1XThySwJRlawSs1c4Gzn66DvP/R5X UZrgMPDVU0uhDPGBq1zIVrqRZL9KG/ddP4jPFENfTLEm1ferm4f44pCwxB0PqZAfH+1KxfVkpfUn 5wVliTCWx46HJSeTSsW4/Qxtr+jdXBpP2E5RqJEw4dBxMsKkMhROC4Yv+D1/AgwoDpJXEgFsRo/y YsHbLnG0wtunlNrpuIM6Xai9nQKNHoDhiFBK4BRIfXPEE4kElY28zNFlYSmkB6PO0KOcIiy6s0ra CNzrFCkDy/HndROEL/mN+xPFJoXp+P8ZNmD15E/Xnjjd3KQAAAAAAAA= ------=_NextPart_000_00D0_01CDAC80.0BB67270-- From pkyzivat@alum.mit.edu Wed Oct 17 13:34:51 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0AB21F86FE for ; Wed, 17 Oct 2012 13:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpilzluON6-W for ; Wed, 17 Oct 2012 13:34:51 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 979AF21F8707 for ; Wed, 17 Oct 2012 13:34:50 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id CDd71k0070SCNGk51LavjZ; Wed, 17 Oct 2012 20:34:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id CLWJ1k00l3ZTu2S3VLWJuk; Wed, 17 Oct 2012 20:30:19 +0000 Message-ID: <507F153B.70603@alum.mit.edu> Date: Wed, 17 Oct 2012 16:29:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:34:51 -0000 On 10/17/12 2:56 PM, Mary Barnes wrote: > I agree it's silliness that SIMPLE implementations have interop issues > right now. I think the SIP-XMPP is further along that SIMPLE-SIMPLE. I > think that's because XMPP was done before SIMPLE - it's a matter of a > market decisions -i.e, jabber was available way before SIMPLE. However, > it now seems that there are some deployments (e.g., Hannes' emergency > services scenario) that require SIMPLE-SIMPLE. I think we might be able > to learn from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE > to work for the lowest common denominator situations. I think the > starting point for the latter is to identify the current set of interop > issues and determine whether it's due to gaps in the specs or > implementation decisions (as Olle suggested at the beginning of this > thread). I pretty much agree with Mary. I suspect the primary reason for simple-simple interop problems is lack of a sufficient number of implementations motivated to make interop work. (But I say that without data, so I'll be happy to be corrected on this.) It would surprise me if it had all magically interoperated without difficulty without anyone finding and reporting problems, and some work to sort them out. And I haven't heard of that, except for the most recent discussion. Perhaps this is because XMPP took a large part of the market, and the pieces it didn't get, that went with simple, are mostly walled gardens. (Maybe just a single walled garden.) Personally I never cared very much about the details of the simple presence and IM. What mattered to me was that there be a unified addressing and session setup mechanism that could mix and match IM with audio and video. If we could have used XMPP as a sip media stream I would have been happy. And if we could have used XMPP presence with sip AORs that would have been ok too. Thanks, Paul > Mary. > > On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson > wrote: > > > 17 okt 2012 kl. 15:14 skrev Adrian Georgescu >: > > >> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE > inter-work solution. Not sure what that will achieve. > > That's fine, but a separate project. If the only way we can get > interoperability between SIMPLE implentations is using XMPP between > them, that feels like a stupid solution to me. I do want to be able > to use SIMPLE to communicate with other SIMPLE implementations. I > want to be able to use one SIMPLE client from one vendor on my > smartphone and share the address book/buddy list and presence > ruleset with my other SIMPLE client on the desktop. > > That's what customers expect. And that's not where we are today with > the IETF specs, and if I parse right, maybe not with the inclusion > of the 3rd party OMA specs. > > /O > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ag@ag-projects.com Wed Oct 17 13:42:48 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F74921F86FE for ; Wed, 17 Oct 2012 13:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jwMcQlp93es for ; Wed, 17 Oct 2012 13:42:47 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 50ABE21F86FA for ; Wed, 17 Oct 2012 13:42:47 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 92D39B014F; Wed, 17 Oct 2012 22:42:46 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id A3A99B0067; Wed, 17 Oct 2012 22:42:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <507F153B.70603@alum.mit.edu> Date: Wed, 17 Oct 2012 22:42:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:42:48 -0000 On Oct 17, 2012, at 10:29 PM, Paul Kyzivat wrote: > On 10/17/12 2:56 PM, Mary Barnes wrote: >> I agree it's silliness that SIMPLE implementations have interop = issues >> right now. I think the SIP-XMPP is further along that SIMPLE-SIMPLE. = I >> think that's because XMPP was done before SIMPLE - it's a matter of a >> market decisions -i.e, jabber was available way before SIMPLE. = However, >> it now seems that there are some deployments (e.g., Hannes' emergency >> services scenario) that require SIMPLE-SIMPLE. I think we might be = able >> to learn from the SIP-XMPP - i.e., at least try to get the = SIMPLE-SIMPLE >> to work for the lowest common denominator situations. I think the >> starting point for the latter is to identify the current set of = interop >> issues and determine whether it's due to gaps in the specs or >> implementation decisions (as Olle suggested at the beginning of this >> thread). >=20 > I pretty much agree with Mary. > I suspect the primary reason for simple-simple interop problems is = lack of a sufficient number of implementations motivated to make interop = work. Your suspicion is the negation of everything hat was written and said on = this list in the last couple of days. People making open source implementation for these SIMPLE standards and = submitting feedback to this list lack motivation? How can you write such a careless thing? > (But I say that without data, so I'll be happy to be corrected on = this.) It would surprise me if it had all magically interoperated = without difficulty without anyone finding and reporting problems, and = some work to sort them out. And I haven't heard of that, except for the = most recent discussion. >=20 > Perhaps this is because XMPP took a large part of the market, and the = pieces it didn't get, that went with simple, are mostly walled gardens. = (Maybe just a single walled garden.) >=20 > Personally I never cared very much about the details of the simple = presence and IM. Well, if you do not care, why do you dare debate people who do care? =20 > What mattered to me was that there be a unified addressing and session = setup mechanism that could mix and match IM with audio and video. If we = could have used XMPP as a sip media stream I would have been happy. And = if we could have used XMPP presence with sip AORs that would have been = ok too. As you do not care, please stay out of this discussion and let people = who do care, discuss it.=20 Stop interfering with things you do not care about when others spend = their time writing software code for it. Adrian >=20 > Thanks, > Paul >=20 >> Mary. >>=20 >> On Wed, Oct 17, 2012 at 1:22 PM, Olle E. Johansson > > wrote: >>=20 >>=20 >> 17 okt 2012 kl. 15:14 skrev Adrian Georgescu > >: >>=20 >> >> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE >> inter-work solution. Not sure what that will achieve. >>=20 >> That's fine, but a separate project. If the only way we can get >> interoperability between SIMPLE implentations is using XMPP = between >> them, that feels like a stupid solution to me. I do want to be = able >> to use SIMPLE to communicate with other SIMPLE implementations. I >> want to be able to use one SIMPLE client from one vendor on my >> smartphone and share the address book/buddy list and presence >> ruleset with my other SIMPLE client on the desktop. >>=20 >> That's what customers expect. And that's not where we are today = with >> the IETF specs, and if I parse right, maybe not with the inclusion >> of the 3rd party OMA specs. >>=20 >> /O >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From pkyzivat@alum.mit.edu Wed Oct 17 13:53:01 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E992A21F8546 for ; Wed, 17 Oct 2012 13:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0YH6suD99+u for ; Wed, 17 Oct 2012 13:53:01 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 4A21E21F853B for ; Wed, 17 Oct 2012 13:53:01 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta15.westchester.pa.mail.comcast.net with comcast id CAtT1k00C0vyq2s5FLtXCy; Wed, 17 Oct 2012 20:53:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id CLoS1k00e3ZTu2S3RLoS5M; Wed, 17 Oct 2012 20:48:26 +0000 Message-ID: <507F1980.3060005@alum.mit.edu> Date: Wed, 17 Oct 2012 16:48:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> <507F11D4.6080104@alum.mit.edu> <23950D5E-A4D5-4DF7-A4CF-9D261B9FA5AF@ag-projects.com> In-Reply-To: <23950D5E-A4D5-4DF7-A4CF-9D261B9FA5AF@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: simple@ietf.org Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:53:02 -0000 On 10/17/12 4:29 PM, Adrian Georgescu wrote: > Hi Paul, > > You are analyzing things in terms of one to one dialogs. Yes for IM, no for presence. I fully realize that the topology that must be maintained for presence is different, and more complex. > This is a bit wrong, and don't take this personally. > > Presence requires a multiple set of dialogs between each end-point and the Presence Agent and between themselves on a logical level. > > You are right that the interop issue are very different but your juxtaposed the actors. > > Presence is the most complicated part of it all, it involves at least twelve of such dialogs when I do a napkin drawing. Which is at least one order of magnitude more complicated then doing a MSRP file transfer or an RTP video session. I don't know where you get the number 12. It seems obvious that the number will vary based on the buddy graph, the the partitioning of the principals among servers. No doubt it will turn out to be 12 in *some* case, but I don't see how that tells us anything. Nevertheless it can be complex. The whole scaling analysis thing demonstrated that. The potential to give different authorization to each of your buddies makes it very difficult to come up with a scalable design. Thanks, Paul > Adrian > > > On Oct 17, 2012, at 10:15 PM, Paul Kyzivat wrote: > >> On 10/17/12 3:47 PM, Olle E. Johansson wrote: >> >>> All others following this list: >>> >>> Please add your thoughts, possibly details (like Iñaki, Saul and Adrian >>> have done) in mail to this mailing list. With that information, we can >>> try to put together a document on "Issues in SIMPLE-SIMPLE >>> interoperability" that can be the platform for continued work to solve >>> issues. Pour it out to the mail archives! >> >> ISTM that SIMPLE has two clearly separate parts: presence and IM. >> The interop issues for the two are very different. I think most of the issues are wrt presence. This applies to both simple-simple and simple-xmpp. >> >> The one point where there is commonality is around the URIs - sip: vs. xmpp:. >> >> For instance, for simple-xmpp interop for ecrit, I think only the IM part is critical, and that should be the easier part. >> >> Thanks, >> Paul >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > > From ag@ag-projects.com Wed Oct 17 14:05:03 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2704A21F8619 for ; Wed, 17 Oct 2012 14:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY54P2NV1T4l for ; Wed, 17 Oct 2012 14:05:02 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1614921F8658 for ; Wed, 17 Oct 2012 14:05:02 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4FE94B014F; Wed, 17 Oct 2012 23:05:01 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 1E2C0B0067; Wed, 17 Oct 2012 23:05:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_AF141E0D-FD43-4E94-BE85-A9AB8E5A69A4" From: Adrian Georgescu In-Reply-To: <507F1980.3060005@alum.mit.edu> Date: Wed, 17 Oct 2012 23:04:59 +0200 Message-Id: <2BABF7BE-86F7-458A-B8CA-3201F50E273E@ag-projects.com> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> <507F11D4.6080104@alum.mit.edu> <23950D5E-A4D5-4DF7-A4CF-9D261B9FA5AF@ag-projects.com> <507F1980.3060005@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:05:03 -0000 --Apple-Mail=_AF141E0D-FD43-4E94-BE85-A9AB8E5A69A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 17, 2012, at 10:48 PM, Paul Kyzivat wrote: > On 10/17/12 4:29 PM, Adrian Georgescu wrote: >> Hi Paul, >>=20 >> You are analyzing things in terms of one to one dialogs. >=20 > Yes for IM, no for presence. I fully realize that the topology that = must be maintained for presence is different, and more complex. >=20 >> This is a bit wrong, and don't take this personally. >>=20 >> Presence requires a multiple set of dialogs between each end-point = and the Presence Agent and between themselves on a logical level. >>=20 >> You are right that the interop issue are very different but your = juxtaposed the actors. >>=20 >> Presence is the most complicated part of it all, it involves at least = twelve of such dialogs when I do a napkin drawing. Which is at least one = order of magnitude more complicated then doing a MSRP file transfer or = an RTP video session. >=20 > I don't know where you get the number 12. It seems obvious that the = number will vary based on the buddy graph, the the partitioning of the = principals among servers. No doubt it will turn out to be 12 in *some* = case, but I don't see how that tells us anything. >=20 > Nevertheless it can be complex. The whole scaling analysis thing = demonstrated that. The potential to give different authorization to each = of your buddies makes it very difficult to come up with a scalable = design. Again, can we forget about scalability for a second. Is a different = topic. The issue is the interoperability for presence flows between two clients = from two different vendors on the same account on the same server. The people concerned, myself included, want to find a solution for how = to make two SIP clients work under the same SIP account for presence.=20 Adrian >=20 > Thanks, > Paul >=20 >> Adrian >>=20 >>=20 >> On Oct 17, 2012, at 10:15 PM, Paul Kyzivat wrote: >>=20 >>> On 10/17/12 3:47 PM, Olle E. Johansson wrote: >>>=20 >>>> All others following this list: >>>>=20 >>>> Please add your thoughts, possibly details (like I=F1aki, Saul and = Adrian >>>> have done) in mail to this mailing list. With that information, we = can >>>> try to put together a document on "Issues in SIMPLE-SIMPLE >>>> interoperability" that can be the platform for continued work to = solve >>>> issues. Pour it out to the mail archives! >>>=20 >>> ISTM that SIMPLE has two clearly separate parts: presence and IM. >>> The interop issues for the two are very different. I think most of = the issues are wrt presence. This applies to both simple-simple and = simple-xmpp. >>>=20 >>> The one point where there is commonality is around the URIs - sip: = vs. xmpp:. >>>=20 >>> For instance, for simple-xmpp interop for ecrit, I think only the IM = part is critical, and that should be the easier part. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >>=20 >=20 --Apple-Mail=_AF141E0D-FD43-4E94-BE85-A9AB8E5A69A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 10/17/12 4:29 PM, Adrian Georgescu = wrote:
Hi Paul,

You are = analyzing things in terms of one to one dialogs.

Yes = for IM, no for presence. I fully realize that the topology that must be = maintained for presence is different, and more = complex.

This is a bit wrong, and don't = take this personally.

Presence = requires a multiple set of dialogs between each end-point and the = Presence Agent and between themselves on a logical = level.

You are right = that the interop issue are very different but your juxtaposed the = actors.

Presence is the = most complicated part of it all, it involves at least twelve of such = dialogs when I do a napkin drawing. Which is at least one order of = magnitude more complicated then doing a MSRP file transfer or an RTP = video session.

I don't know where you get the number = 12. It seems obvious that the number will vary based on the buddy graph, = the the partitioning of the principals among servers. No doubt it will = turn out to be 12 in *some* case, but I don't see how that tells us = anything.

Nevertheless it can be complex. The whole scaling = analysis thing demonstrated that. The potential to give different = authorization to each of your buddies makes it very difficult to come up = with a scalable design.

Again, = can we forget about scalability for a second.  Is a different = topic.

The issue is the interoperability = for presence flows between two clients from two different vendors on the = same account on the same server.

The = people concerned, myself included,  want to find a solution for how = to make two SIP clients work under the same SIP account for = presence. 

Adrian

=

Thanks,
= Paul

Adrian


On Oct 17, = 2012, at 10:15 PM, Paul Kyzivat wrote:

On 10/17/12 3:47 PM, Olle E. Johansson = wrote:

All = others following this = list:

Please = add your thoughts, possibly details (like I=F1aki, Saul and = Adrian
have = done) in mail to this mailing list. With that information, we = can
try to = put together a document on "Issues in = SIMPLE-SIMPLE
interoperability" that can be the platform for continued = work to solve
issues. = Pour it out to the mail = archives!

ISTM that SIMPLE has two clearly = separate parts: presence and = IM.
The interop issues for the two are very different. I think = most of the issues are wrt presence. This applies to both simple-simple = and simple-xmpp.

The one point where there is = commonality is around the URIs - sip: vs. = xmpp:.

For instance, for simple-xmpp = interop for ecrit, I think only the IM part is critical, and that should = be the easier part.

= Thanks,
= Paul

_______________________________________________
Simple mailing = list
Simple@ietf.org
https://www.ietf.org= /mailman/listinfo/simple





= --Apple-Mail=_AF141E0D-FD43-4E94-BE85-A9AB8E5A69A4-- From pkyzivat@alum.mit.edu Wed Oct 17 14:07:54 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A1321F8619 for ; Wed, 17 Oct 2012 14:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCDRqBe-PKLp for ; Wed, 17 Oct 2012 14:07:54 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 029F321F8600 for ; Wed, 17 Oct 2012 14:07:53 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta15.westchester.pa.mail.comcast.net with comcast id CEw91k0091wpRvQ5FM8Ql0; Wed, 17 Oct 2012 21:08:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id CMMy1k01F3ZTu2S3eMMyLQ; Wed, 17 Oct 2012 21:21:59 +0000 Message-ID: <507F1CFB.7060408@alum.mit.edu> Date: Wed, 17 Oct 2012 17:02:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> In-Reply-To: <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:07:54 -0000 On 10/17/12 4:42 PM, Adrian Georgescu wrote: > On Oct 17, 2012, at 10:29 PM, Paul Kyzivat wrote: > >> On 10/17/12 2:56 PM, Mary Barnes wrote: >>> I agree it's silliness that SIMPLE implementations have interop issues >>> right now. I think the SIP-XMPP is further along that SIMPLE-SIMPLE. I >>> think that's because XMPP was done before SIMPLE - it's a matter of a >>> market decisions -i.e, jabber was available way before SIMPLE. However, >>> it now seems that there are some deployments (e.g., Hannes' emergency >>> services scenario) that require SIMPLE-SIMPLE. I think we might be able >>> to learn from the SIP-XMPP - i.e., at least try to get the SIMPLE-SIMPLE >>> to work for the lowest common denominator situations. I think the >>> starting point for the latter is to identify the current set of interop >>> issues and determine whether it's due to gaps in the specs or >>> implementation decisions (as Olle suggested at the beginning of this >>> thread). >> >> I pretty much agree with Mary. >> I suspect the primary reason for simple-simple interop problems is lack of a sufficient number of implementations motivated to make interop work. > > Your suspicion is the negation of everything hat was written and said on this list in the last couple of days. > People making open source implementation for these SIMPLE standards and submitting feedback to this list lack motivation? > How can you write such a careless thing? This discussion comes after many years during which XMPP worked out its interop issues, and there was little discussion of interop issues with simple. It is good that now there seems to be a critical mass to address the issue. >> (But I say that without data, so I'll be happy to be corrected on this.) It would surprise me if it had all magically interoperated without difficulty without anyone finding and reporting problems, and some work to sort them out. And I haven't heard of that, except for the most recent discussion. >> >> Perhaps this is because XMPP took a large part of the market, and the pieces it didn't get, that went with simple, are mostly walled gardens. (Maybe just a single walled garden.) >> >> Personally I never cared very much about the details of the simple presence and IM. > > Well, if you do not care, why do you dare debate people who do care? IMO it would have been better if we had found a way to converge simple and xmpp long ago. But we didn't, and now we have both. And we get the issues that arise from that. I am not debating you about the problems. >> What mattered to me was that there be a unified addressing and session setup mechanism that could mix and match IM with audio and video. If we could have used XMPP as a sip media stream I would have been happy. And if we could have used XMPP presence with sip AORs that would have been ok too. > > As you do not care, please stay out of this discussion and let people who do care, discuss it. > > Stop interfering with things you do not care about when others spend their time writing software code for it. In what way have I "interfered"? I'm interested in seeing that the problems are identified and addressed. At the end of the day, I just want to be able to put anybody into my buddy list, regardless of what protocol they use, and be able to establish sessions with them that can use any combination of voice, video, and IM that seems useful at the time. Thanks, Paul From ag@ag-projects.com Wed Oct 17 14:22:37 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8A521F86D0 for ; Wed, 17 Oct 2012 14:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8hdNvwV6GIJ for ; Wed, 17 Oct 2012 14:22:37 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D39C721F8540 for ; Wed, 17 Oct 2012 14:22:36 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B70CAB014F; Wed, 17 Oct 2012 23:22:35 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 3BB6BB0079; Wed, 17 Oct 2012 23:22:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <2BABF7BE-86F7-458A-B8CA-3201F50E273E@ag-projects.com> Date: Wed, 17 Oct 2012 23:22:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C11283C-2937-4309-AA43-A5BD84294A63@ag-projects.com> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> <507F11D4.6080104@alum.mit.edu> <23950D5E-A4D5-4DF7-A4CF-9D261B9FA5AF@ag-projects.com> <507F1980.3060005@alum.mit.edu> <2BABF7BE-86F7-458A-B8CA-3201F50E273E@ag-projects.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:22:37 -0000 >> I don't know where you get the number 12. On my napkin I have: Each SIP client maintains at a minimum: 1. SIP Publication for each own state 2. SIP Subscription for presence.winfo event 3. SIP Subscription for presence event for rls 4. SIP Subscription for xcap-diff event 5. HTTP Connection for XCAP document rls-services 6. HTTP Connection for XCAP document resource-lists 7. HTTP Connection for XCAP document pres-rules 8. HTTP Connection for XCAP document pres-content icon document 9. HTTP Connection for retrieval of the icon published by the remote = contact Two clients then need in total at least eighteen dialogs to maintain = end-to-end presence signaling. I was wrong, there are not 12 but 18 dialogs. Adrian From ag@ag-projects.com Wed Oct 17 14:31:05 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB1921F86F5 for ; Wed, 17 Oct 2012 14:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLWD+J6mKA9y for ; Wed, 17 Oct 2012 14:31:04 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2721F86DC for ; Wed, 17 Oct 2012 14:31:04 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 050DDB014F; Wed, 17 Oct 2012 23:31:03 +0200 (CEST) Received: from imac3.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 79647B0079; Wed, 17 Oct 2012 23:31:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <507F1CFB.7060408@alum.mit.edu> Date: Wed, 17 Oct 2012 23:31:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:31:05 -0000 > At the end of the day, I just want to be able to put anybody into my = buddy list, regardless of what protocol they use, and be able to = establish sessions with them that can use any combination of voice, = video, and IM that seems useful at the time. Hi Paul! This sounds like a great goal. As you say, putting anyone in a buddy list that just works when one = tries to communicate would be a great achieving of this WG. This requires the concept of a buddy list., which is really the missing = part. I called it address-book, you called it buddy list and is really = the same thing.=20 Could we converge on this idea of having to define this buddy = list/address book part of SIMPLE? Adrian =20 From ibc@aliax.net Wed Oct 17 14:41:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C1121F8726 for ; Wed, 17 Oct 2012 14:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AFu3KNlsFGV for ; Wed, 17 Oct 2012 14:41:35 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2EB121F871E for ; Wed, 17 Oct 2012 14:41:34 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so6039048lam.31 for ; Wed, 17 Oct 2012 14:41:33 -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=bqS1FASjzeVHAeH/BXb0XhtTgnC6Pr0r+KIdUIu6uVo=; b=UFBYjBjZ1AjHZMdWZEuk/JrUnTvCGAkXVMvrS8DTOJx23Ax9fkvGhkN26HJymVr3If 9zKvmVIIBXRT5NufF/u4hNgJoveafqc5XdP6erxZMaFydwLzkfbutq+0vz6lw8kkcEwe 41YlSefgfUZsujHQLZpY1qnHok5KsgszMrgGmaZB49uJDkyYzmsWGuY6kuRKiV9hs7rd MOhsxS4ZXfh2sOzu/DCg0grDOlhfywl3IxauFjbmFvAV1lnIh3nUqHxpFsnJSyFtEEkJ lcFnftneKI/1yWT8poDb4UpEWtTtZtkWOOSq5JHOl3DnEP6dz5Ijl+23IeU/6v+GUd+v wx2A== Received: by 10.152.148.40 with SMTP id tp8mr16806688lab.30.1350510093749; Wed, 17 Oct 2012 14:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Wed, 17 Oct 2012 14:41:13 -0700 (PDT) In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF485F1930@ucolhp9h.easf.csd.disa.mil> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> <8486C8728176924BAF5BDB2F7D7EEDDF485F1930@ucolhp9h.easf.csd.disa.mil> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 17 Oct 2012 23:41:13 +0200 Message-ID: To: "Roy, Radhika R CIV (US)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnE7r/zhAslXl68vERFJF6vx1BCSD9Sfg7IKrfaO+/I7xM5hNLNl5inyNqht5lQ7AkoszBz Cc: Adrian Georgescu , Mary Barnes , "simple@ietf.org" Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:41:36 -0000 2012/10/17 Roy, Radhika R CIV (US) : > I do not know which scenarios for SIMPLE-XMPP interworking are taken into > account: Hi, the subject of this thread is "Focusing on SIMPLE-SIMPLE interoperability". It seems that things are to wrong in this area that is so easy for people to move the discussion to SIMPLE-XMPP interoperability. Please, let's focus on the real topic: SIMPLE-SIMPLE interoperability. My opinion (again): With the IETF specs SIMPLE-SIMPLE interoperability is not possible since there are missing specs, the existing ones are too complex and ambiguous and the ammount of lines of code to implement something that still is incomplete are too much (15K of lines of code in a high level language as Python). --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Wed Oct 17 15:18:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F0921F859F for ; Wed, 17 Oct 2012 15:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wX4BHSO78T2 for ; Wed, 17 Oct 2012 15:18:26 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 91D7F21F859A for ; Wed, 17 Oct 2012 15:18:26 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id CFxf1k01T1GhbT853NJWys; Wed, 17 Oct 2012 22:18:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id CNDx1k0053ZTu2S3TNDx95; Wed, 17 Oct 2012 22:13:57 +0000 Message-ID: <507F2D84.3070107@alum.mit.edu> Date: Wed, 17 Oct 2012 18:13:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <667EB6DA-1AEA-4909-804A-558275B34D23@edvina.net> <507F11D4.6080104@alum.mit.edu> <23950D5E-A4D5-4DF7-A4CF-9D261B9FA5AF@ag-projects.com> <507F1980.3060005@alum.mit.edu> <2BABF7BE-86F7-458A-B8CA-3201F50E273E@ag-projects.com> <6C11283C-2937-4309-AA43-A5BD84294A63@ag-projects.com> In-Reply-To: <6C11283C-2937-4309-AA43-A5BD84294A63@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Focusing on SIMPLE-SIMPLE interoperability X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 22:18:27 -0000 On 10/17/12 5:22 PM, Adrian Georgescu wrote: >>> I don't know where you get the number 12. > > On my napkin I have: > > Each SIP client maintains at a minimum: > > 1. SIP Publication for each own state > 2. SIP Subscription for presence.winfo event > 3. SIP Subscription for presence event for rls > 4. SIP Subscription for xcap-diff event > 5. HTTP Connection for XCAP document rls-services > 6. HTTP Connection for XCAP document resource-lists > 7. HTTP Connection for XCAP document pres-rules > 8. HTTP Connection for XCAP document pres-content icon document > 9. HTTP Connection for retrieval of the icon published by the remote contact > > Two clients then need in total at least eighteen dialogs to maintain end-to-end presence signaling. > > I was wrong, there are not 12 but 18 dialogs. OK. Now I understand what you meant. And yes, it is an impressive and depressing, list. Thanks, Paul From pkyzivat@alum.mit.edu Wed Oct 17 15:34:28 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D752321F86CA for ; Wed, 17 Oct 2012 15:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7Ptcd-weJgn for ; Wed, 17 Oct 2012 15:34:28 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 36CAB21F86B8 for ; Wed, 17 Oct 2012 15:34:28 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id CNQ81k0031ei1Bg57NaYoQ; Wed, 17 Oct 2012 22:34:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id CNVT1k00r3ZTu2S3kNVT6z; Wed, 17 Oct 2012 22:29:28 +0000 Message-ID: <507F3145.9050803@alum.mit.edu> Date: Wed, 17 Oct 2012 18:29:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 22:34:28 -0000 On 10/17/12 5:31 PM, Adrian Georgescu wrote: >> At the end of the day, I just want to be able to put anybody into my buddy list, regardless of what protocol they use, and be able to establish sessions with them that can use any combination of voice, video, and IM that seems useful at the time. > > Hi Paul! > > This sounds like a great goal. > > As you say, putting anyone in a buddy list that just works when one tries to communicate would be a great achieving of this WG. > > This requires the concept of a buddy list., which is really the missing part. I called it address-book, you called it buddy list and is really the same thing. > > Could we converge on this idea of having to define this buddy list/address book part of SIMPLE? ISTM that a buddy list can be considered as a subset of an address book. There are lots of things I keep in an address book that have nothing to do with my presence buddy list. Setting out to define a complete address book seems like a dangerous slippery slope. There are lots of other organizations that will have opinions on that and perhaps think it is within their scope rather than ours. (And they are probably right.) To have any success it will be necessary to figure out how to scope this down. Perhaps an abstract model that can be mapped onto a variety of things. Or else find a model already defined someplace else that we can just reference. Thanks, Paul From ibc@aliax.net Wed Oct 17 15:51:45 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195FD21F86B8 for ; Wed, 17 Oct 2012 15:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMaB+b3PeEcp for ; Wed, 17 Oct 2012 15:51:44 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0104F21F8645 for ; Wed, 17 Oct 2012 15:51:43 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6138627lbo.31 for ; Wed, 17 Oct 2012 15:51:42 -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=RgvB4GL0ajsvkbvlgVeCeWZVT/fIJc1fYVHOVBNH/9Q=; b=hTgRPUJafR+m4nix2809YVjW4rRU8OxTUnWotgqDFnE5zpBVRCAGRgjD/6BJKbOmIw wwOS/jPe8gqsHQFdSZ+10CKFySqDBXx31m9LkY2NWoGcZFCDphpcA4KaQmOVEQS6wemf blx7EU5J20uCSpymiMWYKKm30jYsZHr6mUQJG2gRCvHOh87xkgGnC8IwND12QDJMHz7s n1aqTrFjTJOudsGaEOMJB+Siuvcc2YWfYXHOzwShHsVwP/kc2c0Oopw4V+R0kwsWCCzq PCD+kICH/uzucO2zAokeA96jZ0uboPIhuEXoDpVQHmT7ncMy+2zBi42dN+pSyLgFKDT7 Iyyg== Received: by 10.152.146.67 with SMTP id ta3mr16745308lab.23.1350514302804; Wed, 17 Oct 2012 15:51:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Wed, 17 Oct 2012 15:51:22 -0700 (PDT) In-Reply-To: <507F3145.9050803@alum.mit.edu> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 00:51:22 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlHbQNkrXrpJt1qMSiYzGYfF5pSiesvk2uMHQWmRolx2eq/pSRMUWLsiRT+5mWYM2TORYFq Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 22:51:45 -0000 2012/10/18 Paul Kyzivat : > ISTM that a buddy list can be considered as a subset of an address book. > There are lots of things I keep in an address book that have nothing to d= o > with my presence buddy list. > > Setting out to define a complete address book seems like a dangerous > slippery slope. I agree with this. buddylist !=3D addressbook A buddylist is a list of entries with: - key: uri - value: attributes for the uri related to subscription/authorization. An addressbook is a list of entries with: - key: anything, i.e. full name or an ID. - value: like vCARD data or whatever. We should keep both separated. Take a look to MSN, Skype, Yahoo Messenger, XMPP, etc... You manage a buddylist, not an addressbook. Now take a look to your iPhone or Android: you manage an addressbook, and the addressbook inspects the buddylist of installed apps for merging/integrating different "contacts" into one. The problem of SIMPLE is that is the RFCs don't even specify a buddylist but a "resource-list" that IS NOT a buddylist because: - A resource-list document is structured in "groups" that contains URIs, so a URI could exist in more than a "group" and each group "could" have different meanings (or not), and a "group" can include a "link" to other groups that also include links to other groups, etc, etc. That's unmanageable for a client application that just wants to render buddies and their properties. In the other side, an addressbook is an extra layer over the buddylist. For example: - The buddylist contains buddies definitions. - A buddy includes an attribute "addressbook_id". - A buddy also includes other attributes related to SIP presence, authorization, etc (no display-name or home location here). - The addressbook has "id" as key and something like a vCARD as value. So you can have a single contact in your adressbook with id=3D5 and two or five associated buddies in the buddylist (all those buddies with addressbook_id=3D55). The client application should of course manage both "documents" (the buddylist and the addressbook) all together, but IMHO this is a terribly EASY task in comparison with managing the XCAP documents as defined by SIMPLE, right? Regards. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed Oct 17 15:53:05 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205C521F86FC for ; Wed, 17 Oct 2012 15:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoul7-BkqPQV for ; Wed, 17 Oct 2012 15:53:04 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5C61821F86B8 for ; Wed, 17 Oct 2012 15:53:04 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 831ADB014F; Thu, 18 Oct 2012 00:53:03 +0200 (CEST) Received: from [192.168.1.6] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id AD9A9B0067; Thu, 18 Oct 2012 00:53:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <507F3145.9050803@alum.mit.edu> Date: Thu, 18 Oct 2012 00:53:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 22:53:05 -0000 Hi Paul, In a client UI, one can aggregate contacts from different data sources. = The UI may make the look uniform (like showing them on same groups or = not) but the contacts and groups have different properties given by = their original maker. The goal is define one schema pertinent to SIMPLE where one can make a = list of URIs with their type and organize them in groups. Each contacts = can be subscribed to and a policy can be expressed for each contact. In = a SIP client I can render today a contacts list consisting of: SIMPLE Contacts MacOSX Addresbook Google Contacts Bonjour Contacts These groups are all disjunct with regards to their capabilities and = properties. In SIMPLE case I want to be able to be able to use = multimedia sessions and subscribe to presence information published by = those contacts, the other contacts are used for audio calls or chat = sessions and no presence. That works just fine with my implementation. = What I cannot do, is to use another SIMPLE client that implements the = same functionality for the SIMPLE Contacts part so that same list can be = see the same way from a mobile device for example.=20 This is the missing part of SIMPLE, in order to use the standards to = write a client in the same way by multiple vendors we need a common = definition for to to write and read same contacts list with their = properties. I cannot highlight this enough. People end up talking about = anything else like scalability XMPP etc, when the real problem is the = lack of interoperability of clients under the same account.=20 Adrian On Oct 18, 2012, at 12:29 AM, Paul Kyzivat wrote: > On 10/17/12 5:31 PM, Adrian Georgescu wrote: >>> At the end of the day, I just want to be able to put anybody into my = buddy list, regardless of what protocol they use, and be able to = establish sessions with them that can use any combination of voice, = video, and IM that seems useful at the time. >>=20 >> Hi Paul! >>=20 >> This sounds like a great goal. >>=20 >> As you say, putting anyone in a buddy list that just works when one = tries to communicate would be a great achieving of this WG. >>=20 >> This requires the concept of a buddy list., which is really the = missing part. I called it address-book, you called it buddy list and is = really the same thing. >>=20 >> Could we converge on this idea of having to define this buddy = list/address book part of SIMPLE? >=20 > ISTM that a buddy list can be considered as a subset of an address = book. There are lots of things I keep in an address book that have = nothing to do with my presence buddy list. >=20 > Setting out to define a complete address book seems like a dangerous = slippery slope. There are lots of other organizations that will have = opinions on that and perhaps think it is within their scope rather than = ours. (And they are probably right.) >=20 > To have any success it will be necessary to figure out how to scope = this down. Perhaps an abstract model that can be mapped onto a variety = of things. Or else find a model already defined someplace else that we = can just reference. >=20 > Thanks, > Paul >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ibc@aliax.net Thu Oct 18 04:15:43 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18ED521F8685 for ; Thu, 18 Oct 2012 04:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc3sm4k7HxxH for ; Thu, 18 Oct 2012 04:15:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42DBC21F8532 for ; Thu, 18 Oct 2012 04:15:42 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6528093lbo.31 for ; Thu, 18 Oct 2012 04:15:40 -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=OTdQC3M4Nz/zq3r9ybHbknpL6C3EqyRGg17IjZsXGCE=; b=Ah5BBHUFRyKRagA4PNTHnjzqpVRpfnZ9xqGyTu0J/fiFmDnD1h+FEJvrNSD34nHgJX qXuYrzRwI1f7ERAkMHfaQUh11qbyc2zR05rV/2lBEuj0SXrJi9RyLKBIr6g4103cXwhS Vu1IpbfL3NANzVaNqMkBhktoReHlVqBWdvd49KnEXrUL28jprHdVPKMQQzyR1lNFls/7 xnGSMt7ArEO0qRs5FV0UxRxzQ5ShLmMelGhOc0jVmqqmEVH739EN+5+LNze1w4BNKcdH 8VNE2pgRSSyKWXGvBCqVIUOSI5h3EaArG6EFP+4B2fwfJjNRkmDg4XUXiWEhMsfLz9Nt qjpA== Received: by 10.152.146.67 with SMTP id ta3mr18015740lab.23.1350558940798; Thu, 18 Oct 2012 04:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 04:15:20 -0700 (PDT) In-Reply-To: <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 13:15:20 +0200 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnTpLK0MLWz+hMWPila/LegTPvcD3FdHSHnzuC5aPtSlr1Z3Sg193qWuEvQfmIucvoXVQNI Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 11:15:43 -0000 2012/10/16 Ben Campbell : > It seems like there are really at least two things under discussion on th= e > list: SIMPLE/XMPP inter working, and whether work is needed on SIMPLE its= elf > in order to facilitate interoperable implementations. Hi Ben, some others as me propose a third vision: Trying to revive SIMPLE for open environments (i.e. Internet) is a no-go given the complexity of the existing specs. IMHO technical details about this realitity have been already given during the last mail threads, including the number of lines of high level programming code for building all the SIMPLE specs (more than 15000, and the result is something non interoperable with any other client or server implementation). A new effort 100% from scratch makes more sense for me (just my opinion). Regards. --=20 I=C3=B1aki Baz Castillo From avshalom@il.ibm.com Thu Oct 18 04:51:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1C221F8673 for ; Thu, 18 Oct 2012 04:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7jN+x1Uzy3d for ; Thu, 18 Oct 2012 04:51:26 -0700 (PDT) Received: from e06smtp18.uk.ibm.com (e06smtp18.uk.ibm.com [195.75.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 64FCE21F8672 for ; Thu, 18 Oct 2012 04:51:25 -0700 (PDT) Received: from /spool/local by e06smtp18.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 18 Oct 2012 12:51:23 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp18.uk.ibm.com (192.168.101.148) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 18 Oct 2012 12:51:21 +0100 Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9IBpEgb32768230 for ; Thu, 18 Oct 2012 11:51:14 GMT Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9IBDNUW005373 for ; Thu, 18 Oct 2012 07:13:24 -0400 Received: from d06ml319.portsmouth.uk.ibm.com (d06ml319.portsmouth.uk.ibm.com [9.149.76.146]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q9IBDNB5005359; Thu, 18 Oct 2012 07:13:23 -0400 In-Reply-To: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= MIME-Version: 1.0 X-KeepSent: 865B3C8C:A11A6405-C2257A9B:004082FC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Avshalom Houri Message-ID: Date: Thu, 18 Oct 2012 13:51:12 +0200 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 18/10/2012 13:51:12, Serialize complete at 18/10/2012 13:51:12 Content-Type: multipart/alternative; boundary="=_alternative 0040CCD7C2257A9B_=" x-cbid: 12101811-6892-0000-0000-00000347D65E Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 11:51:27 -0000 This is a multipart message in MIME format. --=_alternative 0040CCD7C2257A9B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable simple-bounces@ietf.org wrote on 10/18/2012 01:15:20 PM: > From: I=F1aki Baz Castillo > To: Ben Campbell ,=20 > Cc: Mary Barnes , Simple WG=20 > , Paul Kyzivat > Date: 10/18/2012 01:15 PM > Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or = what? > Sent by: simple-bounces@ietf.org >=20 > 2012/10/16 Ben Campbell : > > It seems like there are really at least two things under discussion on = the > > list: SIMPLE/XMPP inter working, and whether work is needed on SIMPLE=20 itself > > in order to facilitate interoperable implementations. >=20 > Hi Ben, some others as me propose a third vision: >=20 > Trying to revive SIMPLE for open environments (i.e. Internet) is a > no-go given the complexity of the existing specs. IMHO technical > details about this realitity have been already given during the last > mail threads, including the number of lines of high level programming > code for building all the SIMPLE specs (more than 15000, and the > result is something non interoperable with any other client or server > implementation). >=20 > A new effort 100% from scratch makes more sense for me (just my > opinion). Regards. >=20 > --=20 > I=F1aki Baz Castillo > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple A different effort may be considered which is what will make XMPP acceptable as an extension to SIP based systems. This means not modifying SIMPLE but using XMPP as the presence/IM protocol for SIP. Usage of SIP AOR was mentioned before as an example. thanks avshalom --=_alternative 0040CCD7C2257A9B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable


simple-bounces@ietf.org wrote on 10/18/2012 01:15:20 PM:

> From: I=F1aki Baz Castillo <ibc@aliax.net>
> To: Ben Campbell <ben@nostrum.com>,
> Cc: Mary Barnes <mary.ietf.barnes@gmail.com&= gt;, Simple WG
> <simple@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
> Date: 10/18/2012 01:15 PM
> Subject: Re: [Simple] Should SIMPLE be recharte= red, replaced, closed, or what?
> Sent by: simple-bounces@ietf.org
>
> 2012/10/16 Ben Campbell <ben@nostrum.com>:
> > It seems like there are really at least two things under discussi= on on the
> > list: SIMPLE/XMPP inter working, and whether work is needed on SIMPLE itself
> > in order to facilitate interoperable implementations.
>
> Hi Ben, some others as me propose a third vision:
>
> Trying to revive SIMPLE for open environments (i.e. Internet) is a
> no-go given the complexity of the existing specs. IMHO technical
> details about this realitity have been already given during the last > mail threads, including the number of lines of high level programming<= br> > code for building all the SIMPLE specs (more than 15000, and the
> result is something non interoperable with any other client or server<= br> > implementation).
>
> A new effort 100% from scratch makes more sense for me (just my
> opinion). Regards.
>
> --
> I=F1aki Baz Castillo
> <ibc@aliax.net>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
A different effort may be considered which is what will make
XMPP acceptable as an extension to SIP based systems= .

This means not modifying SIMPLE but using XMPP as the
presence/IM protocol for SIP.

Usage of SIP AOR was mentioned before as an example.=

thanks
avshalom
--=_alternative 0040CCD7C2257A9B_=-- From ibc@aliax.net Thu Oct 18 05:25:13 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF8B21F86E0 for ; Thu, 18 Oct 2012 05:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIHhIZozEKPV for ; Thu, 18 Oct 2012 05:25:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D05921F86DF for ; Thu, 18 Oct 2012 05:25:12 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6581287lbo.31 for ; Thu, 18 Oct 2012 05:25:11 -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=gr0nFYrWX1CwhfGf+TB2aaffZ/AEqy8c0UsCeIkH8iw=; b=I96DPlvpFXUDc8E2NYM6w0WPQn1bsKTB15tquTVz141DFe17lG3GAaskZ2qgu2KCkO J8RPDYAs9lWRtDq7aGyK3f5CvhSrA78iNHU2HtC3zU981fgQhH9+Dz1nmN/at/rDyZ6U Xgz60oto9ALxlwulkv0dzCAWEbleUzgr5pE0ew2vby5N8Cknf65HFT8lA7o2ASahVjB9 AbCQTQk63M6tPUsUeGvIImjyUWv+nLAlne5fdRF7pmAnbw1+dEB5mUPzAV/bc+Sfken7 bv1M69GW1oxjv01XwwEdrXVSDXhK3SFW8QpoNDgy4k5ntxT1n0x0BxtbrTRj41TOL2Pm PuAA== Received: by 10.112.101.72 with SMTP id fe8mr7998623lbb.107.1350563111624; Thu, 18 Oct 2012 05:25:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 05:24:51 -0700 (PDT) In-Reply-To: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 14:24:51 +0200 Message-ID: To: Avshalom Houri Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkZUsfELCF9dEy6nThTRLFrSaGpVa+M48jJ/kKL+FYwjaGPzp3tDDr5A1BWSa9WhGucwOlB Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:25:13 -0000 2012/10/18 Avshalom Houri : > A different effort may be considered which is what will make > XMPP acceptable as an extension to SIP based systems. > > This means not modifying SIMPLE but using XMPP as the > presence/IM protocol for SIP. > > Usage of SIP AOR was mentioned before as an example. XMPP is not the panacea. It uses two different mechanisms for presence: - Basic presence distribution. - Subscription/notification for advanced presence (avatar and so). Interoperability becomes hard for XMPP clients when implementing something else than basic presence exchange. I don't understand why XMPP should be the only way to go (for SIP). Regards. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Thu Oct 18 06:24:32 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF1421F8617 for ; Thu, 18 Oct 2012 06:24:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dr4sKdD1D8eV for ; Thu, 18 Oct 2012 06:24:29 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA1521F8599 for ; Thu, 18 Oct 2012 06:24:27 -0700 (PDT) Received: from [192.168.101.21] (unknown [62.242.105.74]) by smtp7.webway.se (Postfix) with ESMTPA id 73AEF754A8A7; Thu, 18 Oct 2012 13:24:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <467D388D.2080206@cisco.com> Date: Thu, 18 Oct 2012 15:24:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13419C92-8353-421A-8C03-7A2D585C3034@edvina.net> References: <467D388D.2080206@cisco.com> To: Simple WG X-Mailer: Apple Mail (2.1499) Subject: Re: [Simple] New draft on "SIMPLE made Simple" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:24:32 -0000 23 jun 2007 kl. 17:13 skrev Jonathan Rosenberg : > I've just posted: > = http://www.ietf.org/internet-drafts/draft-rosenberg-simple-simple-00.txt >=20 > This draft is basically the SIP hitchhikers guide, but for SIMPLE. It = was meant to fulfill our charter item: >=20 > Jun 2007 Submission of SIMPLE protocol annotated overview = draft to IESG for publication as Informational What's the current status of this document? /O= From avshalom@il.ibm.com Thu Oct 18 06:29:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327A321F8530 for ; Thu, 18 Oct 2012 06:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9idyxdDCPq1 for ; Thu, 18 Oct 2012 06:29:26 -0700 (PDT) Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by ietfa.amsl.com (Postfix) with ESMTP id 1484321F852E for ; Thu, 18 Oct 2012 06:29:24 -0700 (PDT) Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 18 Oct 2012 14:29:23 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 18 Oct 2012 14:29:20 +0100 Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps3074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9IDTCwo54460472 for ; Thu, 18 Oct 2012 13:29:12 GMT Received: from d06av11.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9IDTIbC002501 for ; Thu, 18 Oct 2012 07:29:19 -0600 Received: from d06ml319.portsmouth.uk.ibm.com (d06ml319.portsmouth.uk.ibm.com [9.149.76.146]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q9IDTIcP002489; Thu, 18 Oct 2012 07:29:18 -0600 In-Reply-To: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= MIME-Version: 1.0 X-KeepSent: 9FDF3AF8:80634FC9-C2257A9B:00495B06; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Avshalom Houri Message-ID: Date: Thu, 18 Oct 2012 15:29:10 +0200 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 18/10/2012 15:29:10, Serialize complete at 18/10/2012 15:29:10 Content-Type: multipart/alternative; boundary="=_alternative 004A1086C2257A9B_=" x-cbid: 12101813-2966-0000-0000-00000595BEBF Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:29:27 -0000 This is a multipart message in MIME format. --=_alternative 004A1086C2257A9B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I do not see the SIMPLE work being done again or fixed to the level that=20 it will interoperate. There is too much legacy and complexity including standardisation by other = organizations that will have to be considered. On the other hand, having a way to add presence and IM to SIP while using=20 an existing protocol that is proven to interoperate may be the way=20 forward. It may be that the MSRP work is solid enough so IM is covered but it does=20 not seem that it is the state for presence. Thanks --Avshalom From: I=F1aki Baz Castillo To: Avshalom Houri/Haifa/IBM@IBMIL,=20 Cc: Ben Campbell , Mary Barnes=20 , Paul Kyzivat , Simple = WG Date: 10/18/2012 02:25 PM Subject: Re: [Simple] Should SIMPLE be rechartered, replaced,=20 closed, or what? 2012/10/18 Avshalom Houri : > A different effort may be considered which is what will make > XMPP acceptable as an extension to SIP based systems. > > This means not modifying SIMPLE but using XMPP as the > presence/IM protocol for SIP. > > Usage of SIP AOR was mentioned before as an example. XMPP is not the panacea. It uses two different mechanisms for presence: - Basic presence distribution. - Subscription/notification for advanced presence (avatar and so). Interoperability becomes hard for XMPP clients when implementing something else than basic presence exchange. I don't understand why XMPP should be the only way to go (for SIP). Regards. --=20 I=F1aki Baz Castillo --=_alternative 004A1086C2257A9B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I do not see the SIMPLE work being done again or fixed to the level that it will interoperate.
There is too much legacy and complex= ity including standardisation by other organizations that will
have to be considered.

On the other hand, having a way to a= dd presence and IM to SIP while using an existing protocol that is proven to interoperate may be the way forward.
It may be that the MSRP work is solid enough so IM is covered but it does not seem that it is the state for prese= nce.

Thanks
--Avshalom



From:     =    I=F1aki Baz Castillo <ibc@aliax.net>
To:     &n= bsp;  Avshalom Houri/Haifa/IBM@IB= MIL,
Cc:     &n= bsp;  Ben Campbell <ben@nostru= m.com>, Mary Barnes <mary.ietf.barnes@gmail.com>, Paul Kyzivat <pkyzivat@a= lum.mit.edu>, Simple WG <simple@ietf.org>
Date:     =    10/18/2012 02:25 PM
Subject:   &nbs= p;    Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what?



2012/10/18 Avshalom Houri <AVSHALOM@il.ibm.com>= ;:
> A different effort may be considered which is what will make
> XMPP acceptable as an extension to SIP based systems.
>
> This means not modifying SIMPLE but using XMPP as the
> presence/IM protocol for SIP.
>
> Usage of SIP AOR was mentioned before as an example.

XMPP is not the panacea. It uses two different mechanisms for presence:

- Basic presence distribution.
- Subscription/notification for advanced presence (avatar and so).

Interoperability becomes hard for XMPP clients when implementing
something else than basic presence exchange. I don't understand why
XMPP should be the only way to go (for SIP).

Regards.


--
I=F1aki Baz Castillo
<ibc@aliax.net>
--=_alternative 004A1086C2257A9B_=-- From oej@edvina.net Thu Oct 18 06:33:47 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD7D21F8484 for ; Thu, 18 Oct 2012 06:33:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcj2Tcuz-V5V for ; Thu, 18 Oct 2012 06:33:47 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 221DA21F84D5 for ; Thu, 18 Oct 2012 06:33:42 -0700 (PDT) Received: from [192.168.101.21] (unknown [62.242.105.74]) by smtp7.webway.se (Postfix) with ESMTPA id 74706754A8AA; Thu, 18 Oct 2012 13:33:41 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 18 Oct 2012 15:33:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> To: =?iso-8859-1?Q?Castillo_Baz_I=F1aki?= , Simple WG X-Mailer: Apple Mail (2.1499) Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:33:47 -0000 18 okt 2012 kl. 00:51 skrev I=F1aki Baz Castillo : > We should keep both separated. Take a look to MSN, Skype, Yahoo > Messenger, XMPP, etc... You manage a buddylist, not an addressbook. Every single business customer I have talked with wants to integrate the = presence into the address book or LDAP directory lookups. That's an API issue, but it = means that we have to be able to have an API that queries for the presence of an object. Doesn't mean that we replace the address bok, we need points of = integration. Note also that XMPP supports VCARDs in their buddy lists for managing = extra attributes, like a photograph. /O= From oej@edvina.net Thu Oct 18 06:39:07 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED31521F878A for ; Thu, 18 Oct 2012 06:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppBeEcyIp8nU for ; Thu, 18 Oct 2012 06:39:06 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 225D821F87B2 for ; Thu, 18 Oct 2012 06:39:06 -0700 (PDT) Received: from [192.168.101.21] (unknown [62.242.105.74]) by smtp7.webway.se (Postfix) with ESMTPA id F0246754A8B3; Thu, 18 Oct 2012 13:39:04 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_72EDCDB2-0ECF-4F6C-B69C-8C0F2210D142" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 18 Oct 2012 15:39:04 +0200 Message-Id: <2EB96E8F-B371-4B45-AABC-2FC4CFD94C6D@edvina.net> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> To: Avshalom Houri X-Mailer: Apple Mail (2.1499) Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:39:07 -0000 --Apple-Mail=_72EDCDB2-0ECF-4F6C-B69C-8C0F2210D142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 >=20 >=20 > A different effort may be considered which is what will make=20 > XMPP acceptable as an extension to SIP based systems.=20 >=20 > This means not modifying SIMPLE but using XMPP as the=20 > presence/IM protocol for SIP.=20 >=20 > Usage of SIP AOR was mentioned before as an example.=20 That was the project that Mary referred to earlier, that never took off = and an implementation issue. The question here, in the SIMPLE wg, is not to select another protocol, = it is to judge whether * SIMPLE is broken, which we seams to reach a consensus on * SIMPLE can be fixed, which we are still discussion If we conclude that we have no interoperability, the SIMPLE wg hasn't = lived up to the goal of the charter. The SIMPLE-XMPP gatewaying and SIP-XMPP ("calls") gateway is a very = important discussion, but=20 kind of assumes that there are working SIMPLE implementations and some = basic level of interoperability so you can write a gateway to SIMPLE, not having to write a new gateway = for every SIMPLE-like implementation. For SIMPLE-XMPP to work, we need a SIMPLE world that = interoperates. /O= --Apple-Mail=_72EDCDB2-0ECF-4F6C-B69C-8C0F2210D142 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

A different effort may be considered which is = what will make
XMPP acceptable as an extension to SIP based = systems.

This means not modifying SIMPLE but using XMPP = as the
presence/IM protocol for SIP.

Usage of SIP AOR was mentioned before as an = example.

That was the project that Mary referred = to earlier, that never took off and an implementation = issue.

The question here, in the SIMPLE wg, is = not to select another protocol, it is to judge = whether

* SIMPLE is broken, which we seams to = reach a consensus on
* SIMPLE can be fixed, which we are still = discussion

If we conclude that we have no = interoperability, the SIMPLE wg hasn't lived up to the goal of the = charter.

The SIMPLE-XMPP gatewaying and = SIP-XMPP ("calls") gateway is a very important discussion, = but 
kind of assumes that there are working SIMPLE = implementations and some basic level of interoperability
so = you can write a gateway to SIMPLE, not having to write a new gateway for = every SIMPLE-like
implementation. For SIMPLE-XMPP to work, we = need a SIMPLE world that = interoperates.

/O
= --Apple-Mail=_72EDCDB2-0ECF-4F6C-B69C-8C0F2210D142-- From ben@nostrum.com Thu Oct 18 07:06:09 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7721F8820 for ; Thu, 18 Oct 2012 07:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYXghAr3hZz6 for ; Thu, 18 Oct 2012 07:06:08 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 93D2021F881D for ; Thu, 18 Oct 2012 07:06:08 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9IE61Td030224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 09:06:02 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <13419C92-8353-421A-8C03-7A2D585C3034@edvina.net> Date: Thu, 18 Oct 2012 09:06:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <467D388D.2080206@cisco.com> <13419C92-8353-421A-8C03-7A2D585C3034@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] New draft on "SIMPLE made Simple" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:06:09 -0000 On Oct 18, 2012, at 8:24 AM, "Olle E. Johansson" wrote: >=20 > 23 jun 2007 kl. 17:13 skrev Jonathan Rosenberg : >=20 >> I've just posted: >> = http://www.ietf.org/internet-drafts/draft-rosenberg-simple-simple-00.txt >>=20 >> This draft is basically the SIP hitchhikers guide, but for SIMPLE. It = was meant to fulfill our charter item: >>=20 >> Jun 2007 Submission of SIMPLE protocol annotated overview = draft to IESG for publication as Informational >=20 > What's the current status of this document? It's pretty much done, but on the back-burner pending the approval of = draft-ietf-simple-chat. Hopefully that approval is will happen RSN. We = will progress simple-simple shortly afterwards. From ben@nostrum.com Thu Oct 18 07:09:01 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04E721F843F for ; Thu, 18 Oct 2012 07:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMYoDmg2Iw6A for ; Thu, 18 Oct 2012 07:09:01 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D12321F843E for ; Thu, 18 Oct 2012 07:09:00 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9IE8pnb030500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 09:08:51 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Thu, 18 Oct 2012 09:08:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6D4583BE-919C-455E-B8FE-221F19C2BE61@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:09:01 -0000 On Oct 18, 2012, at 6:15 AM, I=F1aki Baz Castillo wrote: > 2012/10/16 Ben Campbell : >> It seems like there are really at least two things under discussion = on the >> list: SIMPLE/XMPP inter working, and whether work is needed on SIMPLE = itself >> in order to facilitate interoperable implementations. >=20 > Hi Ben, some others as me propose a third vision: >=20 > Trying to revive SIMPLE for open environments (i.e. Internet) is a > no-go given the complexity of the existing specs. IMHO technical > details about this realitity have been already given during the last > mail threads, including the number of lines of high level programming > code for building all the SIMPLE specs (more than 15000, and the > result is something non interoperable with any other client or server > implementation). How is that different from my second item (above)? >=20 > A new effort 100% from scratch makes more sense for me (just my > opinion). Regards. Can you clarify what you mean by "from scratch"? Do you suggest we = should start SIMPLE over from a blank slate? >=20 > --=20 > I=F1aki Baz Castillo > From ibc@aliax.net Thu Oct 18 07:11:25 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7C621F879D for ; Thu, 18 Oct 2012 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Qe3HjFEGOS for ; Thu, 18 Oct 2012 07:11:25 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA27C21F8484 for ; Thu, 18 Oct 2012 07:11:24 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6674413lbo.31 for ; Thu, 18 Oct 2012 07:11:23 -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=mRCq/x/quzgNFao5O1mOenvKEWBZx9JIeY1aMGz4SEg=; b=gOIoVqw4EizAymwJt1L5olB3LT7ewzC5edLJdTdFxPaSpI6Fm2HpKrjZ076zLJV0ia sjEYfiGRTfdr/OWbTiOOc8LgQ8nqoSoNKWd3YwLkfS3vB2j8YdN5eYgrmSAGaRYluvyd uzNLZqKTnWKNGj+oX4TTGD/mvk6I5b/oFvhjkZbjl81cbumPqBJ63ShOgUGNQLBVqhZR It3KbWCTJdWi9Ykj7Mk21A6lbOhw6GUJ1byARqOOlzIvtXhb/JkWyA2tx/QrlgAqQGVT M+ic22+6fF1KG2npVBfpDxByT1H+JWuBuM79TM5kD0BYNyI4MmV7PWkCBcYY7dD98o5V paBg== Received: by 10.112.29.9 with SMTP id f9mr3213768lbh.22.1350569483797; Thu, 18 Oct 2012 07:11:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 07:11:03 -0700 (PDT) In-Reply-To: <13419C92-8353-421A-8C03-7A2D585C3034@edvina.net> References: <467D388D.2080206@cisco.com> <13419C92-8353-421A-8C03-7A2D585C3034@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 16:11:03 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkSyqGYJjziuuyniRLfxocQDUz3QE0MfHGcMmRqQQFWJJeQ315ZqeGNQgkWQ8iXqeS1gmjQ Cc: Simple WG Subject: Re: [Simple] New draft on "SIMPLE made Simple" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:11:26 -0000 2012/10/18 Olle E. Johansson : > 23 jun 2007 kl. 17:13 skrev Jonathan Rosenberg : > >> I've just posted: >> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-simple-00.txt >> >> This draft is basically the SIP hitchhikers guide, but for SIMPLE. It wa= s meant to fulfill our charter item: >> >> Jun 2007 Submission of SIMPLE protocol annotated overview d= raft to IESG for publication as Informational > > What's the current status of this document? SIMPLE made Simple expired Ambiguous note here to crash the watcher UA Another global note for generating a core dump in the UA --=20 I=C3=B1aki Baz Castillo From ben@nostrum.com Thu Oct 18 07:14:33 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFE721F8819 for ; Thu, 18 Oct 2012 07:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzewFm8aY3v8 for ; Thu, 18 Oct 2012 07:14:33 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DC25B21F8816 for ; Thu, 18 Oct 2012 07:14:32 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9IEEPMb031117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 09:14:25 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <2EB96E8F-B371-4B45-AABC-2FC4CFD94C6D@edvina.net> Date: Thu, 18 Oct 2012 09:14:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3C4240C6-BFD1-480E-9CF6-AE9F2DA23E14@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <2EB96E8F-B371-4B45-AABC-2FC4CFD94C6D@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:14:33 -0000 On Oct 18, 2012, at 8:39 AM, "Olle E. Johansson" wrote: > If we conclude that we have no interoperability, the SIMPLE wg hasn't = lived up to the goal of the charter. Before you can draw that conclusion, you have to define what level of = interoperability is intended. For example: 1) Can one SIMPLE implementation exchange presence and IMs with another = implementation? 2) Can you mix and match components of one "deployment cluster" with = another? (For example, the ongoing discussion about being able to get = your address book from any client.) 1 was a clear goal of SIMPLE. I'm not sure you would have gotten = consensus on 2 as a requirement when that charter was written.= From radhika.r.roy.civ@mail.mil Thu Oct 18 07:02:48 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18221F8819 for ; Thu, 18 Oct 2012 07:02:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkvWX1QCxHct for ; Thu, 18 Oct 2012 07:02:47 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 657A121F8808 for ; Thu, 18 Oct 2012 07:02:47 -0700 (PDT) Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 18 Oct 2012 14:04:30 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.175]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.02.0309.003; Thu, 18 Oct 2012 14:04:30 +0000 From: "Roy, Radhika R CIV (US)" To: Avshalom Houri , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? Thread-Index: AQHNrSJU/8z3iyqKUEyLV/ZlBcgugpe+83gAgAAgqZA= Date: Thu, 18 Oct 2012 14:04:29 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF485F1C1E@ucolhp9h.easf.csd.disa.mil> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0011_01CDAD17.AA8F1810" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 18 Oct 2012 07:15:44 -0700 Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:02:48 -0000 ------=_NextPart_000_0011_01CDAD17.AA8F1810 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Avshalom: Yes, this may be another approach to use XMMP IM/Chat as another data application as a part of SIP call (as SIMPLE IM/Chat does). Then the question comes is this: Whether will XMPP have all the hooks = for SIP as SIMPLE does? If not, is it worthwhile to do so? One of the key weaknesses of XMPP is the integration of XMPP with audio and/or video. SIP is well established for integration of data = applications like IM/Chat (e.g. SIMPLE) as another applications with audio and/or = video, but XMPP is not. At the end of the day, it appears that XMPP and SIMPLE/SIP are two = competing protocols. So, it may be such that XMPP will be used as the stand-alone = data applications for IM/Chat while SIMPLE/SIP is the one that will be used = for integration with audio/video using SIP. So, there will be two niece markets evolving side-by-side. Of course, SIMPLE/SIP as a stand-alone IM/Chat application will also be competing = with XMPP, but XMPP has much more market share in this segment. BR/Radhika -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Avshalom Houri Sent: Thursday, October 18, 2012 7:51 AM To: I=F1aki Baz Castillo Cc: Mary Barnes; Simple WG; Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? A different effort may be considered which is what will make XMPP = acceptable as an extension to SIP based systems.=20 This means not modifying SIMPLE but using XMPP as the presence/IM = protocol for SIP.=20 Usage of SIP AOR was mentioned before as an example.=20 thanks avshalom=20 ------=_NextPart_000_0011_01CDAD17.AA8F1810 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjEwMTgxNDAyMjJaMCMGCSqGSIb3DQEJBDEWBBRyLbX9CycTfKY2qFPvFP/s zcxxeTBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAFpA0XUjgQOx9UwpN10UiNT6A3Sr+mAyNsfGlw2ZIDsSjKdAV6PWsEzO7N5KfFEX890D +tPM3v3YmWdR1cYiu+lINaq/qA0dlUQLyqQfgLjTF+eonDMFiXUjLVAy+tICFM8WKnT06kYB2heH i91jJ5mm6FSDd7gcfYg6ZWWopqPSz4LtrYMqp/cRWrGVDzPweledsmZncid5PjMltf1V3KvSCHGX YbEBdBGzNsDzsRNX3idhbOjkvWYuqxXne0HxEL/n3GOGyLh6v7GL8a9AE2s+e6eBrkQKRw4/cyNC hHvNB4qCJtHfIdLnkori992ICorEr1hVB6hbmOgskR1dSxEAAAAAAAA= ------=_NextPart_000_0011_01CDAD17.AA8F1810-- From ag@ag-projects.com Thu Oct 18 07:40:55 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD57C21F8779 for ; Thu, 18 Oct 2012 07:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWld48-FfrjE for ; Thu, 18 Oct 2012 07:40:55 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 457D521F8754 for ; Thu, 18 Oct 2012 07:40:54 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9CBB2B0130; Thu, 18 Oct 2012 16:40:53 +0200 (CEST) Received: from [192.168.1.6] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id BD350B007B; Thu, 18 Oct 2012 16:40:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <3C4240C6-BFD1-480E-9CF6-AE9F2DA23E14@nostrum.com> Date: Thu, 18 Oct 2012 16:40:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <2EB96E8F-B371-4B45-AABC-2FC4CFD94C6D@edvina.net> <3C4240C6-BFD1-480E-9CF6-AE9F2DA23E14@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1283) Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:40:55 -0000 On Oct 18, 2012, at 4:14 PM, Ben Campbell wrote: >=20 > On Oct 18, 2012, at 8:39 AM, "Olle E. Johansson" = wrote: >=20 >> If we conclude that we have no interoperability, the SIMPLE wg hasn't = lived up to the goal of the charter. >=20 > Before you can draw that conclusion, you have to define what level of = interoperability is intended. For example: >=20 > 1) Can one SIMPLE implementation exchange presence and IMs with = another implementation? This works. > 2) Can you mix and match components of one "deployment cluster" with = another? (For example, the ongoing discussion about being able to get = your address book from any client.) This does not. Adrian > 1 was a clear goal of SIMPLE. I'm not sure you would have gotten = consensus on 2 as a requirement when that charter was written. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From oej@edvina.net Thu Oct 18 07:46:45 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEE121F87A3 for ; Thu, 18 Oct 2012 07:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PioNYzCfBEw6 for ; Thu, 18 Oct 2012 07:46:45 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43921F86D5 for ; Thu, 18 Oct 2012 07:46:44 -0700 (PDT) Received: from [192.168.101.21] (unknown [62.242.105.74]) by smtp7.webway.se (Postfix) with ESMTPA id 56A88754A8A7; Thu, 18 Oct 2012 14:46:42 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <3C4240C6-BFD1-480E-9CF6-AE9F2DA23E14@nostrum.com> Date: Thu, 18 Oct 2012 16:46:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38FFFFD7-1983-4C41-ACE1-EFF3194BB01C@edvina.net> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <2EB96E8F-B371-4B45-AABC-2FC4CFD94C6D@edvina.net> <3C4240C6-BFD1-480E-9CF6-AE9F2DA23E14@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1499) Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:46:46 -0000 18 okt 2012 kl. 16:14 skrev Ben Campbell : >=20 > On Oct 18, 2012, at 8:39 AM, "Olle E. Johansson" = wrote: >=20 >> If we conclude that we have no interoperability, the SIMPLE wg hasn't = lived up to the goal of the charter. >=20 > Before you can draw that conclusion, you have to define what level of = interoperability is intended. For example: >=20 > 1) Can one SIMPLE implementation exchange presence and IMs with = another implementation? >=20 > 2) Can you mix and match components of one "deployment cluster" with = another? (For example, the ongoing discussion about being able to get = your address book from any client.) >=20 > 1 was a clear goal of SIMPLE. I'm not sure you would have gotten = consensus on 2 as a requirement when that charter was written. Thanks for the clarification, Ben. I was parsing the text of the charter = myself, as I wasn't involved in the background work back then...=20 For me, I can't even get proper presence notifications across the set of = implementations I have access to. That's why I want as many as possible = to come to SIPit so we can test and see where we are. After my initial = mail there seems to be consensus on issues with PIDF parsing for = presence and then on a bit more, but not too advanced level, a lack of = interoperability in regards to server-based buddy-lists.=20 "deployment cluster" was nicely put :-) Isolated island would be a = politically incorrect, but correct name... /O= From stpeter@stpeter.im Thu Oct 18 08:25:53 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F398221F877F for ; Thu, 18 Oct 2012 08:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B553lsHJ3t4I for ; Thu, 18 Oct 2012 08:25:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01C21F8653 for ; Thu, 18 Oct 2012 08:25:52 -0700 (PDT) Received: from [64.101.72.58] (unknown [64.101.72.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 234EC40062; Thu, 18 Oct 2012 09:28:32 -0600 (MDT) Message-ID: <50801F83.2020802@stpeter.im> Date: Thu, 18 Oct 2012 09:25:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Roy, Radhika R CIV (US)" References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF485F1C1E@ucolhp9h.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF485F1C1E@ucolhp9h.easf.csd.disa.mil> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:25:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/18/12 8:04 AM, Roy, Radhika R CIV (US) wrote: > Avshalom: > > Yes, this may be another approach to use XMMP IM/Chat as another > data application as a part of SIP call (as SIMPLE IM/Chat does). Robert Sparks proposed just such an approach back in 2002: http://tools.ietf.org/id/draft-sparks-simple-jabber-sessions-00.txt Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCAH4MACgkQNL8k5A2w/vxM5ACfQ395ISguVphg8RcOAc+0c2xc Ur0AniSLGKTsalHeI5p2XdluxSa+DQjO =fxJZ -----END PGP SIGNATURE----- From ibc@aliax.net Thu Oct 18 09:05:40 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AA121F886F for ; Thu, 18 Oct 2012 09:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBeSWdINV+Qi for ; Thu, 18 Oct 2012 09:05:39 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 695D121F8829 for ; Thu, 18 Oct 2012 09:05:22 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so6705119lam.31 for ; Thu, 18 Oct 2012 09:05:13 -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=XD5mWml9yCOr4DLf2YuXo4sc1WJ2x3R/tJuWn9B3Zf4=; b=L9VyoZTPcrhww/lzOJCocZsI4bTgImJXqikZMYPfKjIa5uD1t9nYRBkU3caZ6PN+Oe qOYIELi9EofKUTFuyjnz2HBz/hMzLP4xUYU1Az1/6QyxTGSHab1HxG+vVcfVxTBJDVN4 Ex5cLSlMKzMnM8p8BDzi+aVddovxqON1q8xPK7DWW+m1psmmCDgoRMSEnAG1bIWcAX+D PZkn0gKHUp6Cl5Yxbg84sfg9fyZ2plDVgehfj8EndcdxSeS0S6vd3YcnAlmMzlq0i/Er OV0LvdCcaoAYSCFriJrXwpQWD4iFE6RY8PFoUl73tBZSEZHXXxqkjA+9U3sICOAbVHuO 5PHQ== Received: by 10.112.101.72 with SMTP id fe8mr8229763lbb.107.1350576313222; Thu, 18 Oct 2012 09:05:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 09:04:53 -0700 (PDT) In-Reply-To: <6D4583BE-919C-455E-B8FE-221F19C2BE61@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <6D4583BE-919C-455E-B8FE-221F19C2BE61@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 18:04:53 +0200 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmW1ovg5e7gvD9Ly5IiGWCZFp79to36l8LW+SYKcEl5+HhJHmjYaBlmMSB162wLZlyeQeqX Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:05:40 -0000 2012/10/18 Ben Campbell : >> Hi Ben, some others as me propose a third vision: >> >> Trying to revive SIMPLE for open environments (i.e. Internet) is a >> no-go given the complexity of the existing specs. IMHO technical >> details about this realitity have been already given during the last >> mail threads, including the number of lines of high level programming >> code for building all the SIMPLE specs (more than 15000, and the >> result is something non interoperable with any other client or server >> implementation). > > How is that different from my second item (above)? Well, that depends on the ammount of existing specs that would be kept when designing a new SIP presence proposal. See below please. >> A new effort 100% from scratch makes more sense for me (just my >> opinion). Regards. > > Can you clarify what you mean by "from scratch"? Do you suggest we should= start SIMPLE over from a blank slate? Basically yes. I know SIMPLE specs very well and honestly I don't like them at all. Just for mentioning some points: - The Presence Data Model is too complex. In the world we have users and the user has devices. I don't understand what a "service" is. Theorically two devices managed by same AoR should not publish a different since must be unique, how to do that? And in case of various devices, how can the watcher match each to each device? it would make sense to use GRUU here (XMPP uses "resources"), but we have nothing about that. - If I subscribe using RLS I will get a very big first NOTIFY containing all the presence bodies of all my watched contacts, so SIP TCP is required. If so, why must I implement HTTP/XCAP for storing my "buddy list"? Which other IM/presence protocol implements both the protocol itself and HTTP for related stuff? This involves two servers, two TLS certificates, two authentication points, double lines of code... We can transfer a ISO image using MSRP but we need HTTP for storing a simple buddy list and permissions policy? - As Adrian pointed out, a SIMPLE client needs to mantain ~18 SIP/HTTP "dialogs" (subscriptions to XCAP-diff, winfo, presence...). Subscriptions means "dialogs" and dialogs are really a bad idea in the new Internet ecosystem: the mobile devices (those that dynamically change their IP or gets unreachable for a while). Mobiles apps want to use the PUSH mechanism, something unfeasible with SIMPLE subscriptions. IMHO a stateless mechanism based on PULL and PUSH would be the key. Nothing to reuse from SIMPLE here. - Managing a buddy list or presence authorizations should be simple and easy. Instead we have a generic protocol (XCAP) for performing partial modifications in remote XML documents, and when a modification takes place the presence server and all the watchers (same AoR) must re-evaluate all the XML documents along their relationship with all the other XML documents, otherwise it's near imposible to detect what such an incremental XML change involves, and this means high CPU usage in both servers and clients. - Blocking/allowing presence authorization for a buddy should be an atomic/boolean operation (like in XMPP). But in SIMPLE/XCAP we have two options: 1) Upload the new full XML documents with all the buddies (so let the server and others to full re-evaluate it again). 2) Two operations: delete a buddy from some "list", and then include it in some other "list" (partial DELETE/PUT), so double notification. - In XMPP blocking/allowing/subscribing/desubscribing to a buddy is an atomic operation: the user sends the full XML definition of the buddy to the server, with all the buddy attributes. The server notifies the buddy new properties to other resources of the same account. In SIMPLE anyone can do whatever XCAP allows (which is really too much). Does XMPP need so powerful control over the "XML files"? Sure not. - XCAP is like Xpath 1.0 but is not compatible with it since it adds a "cool" feature to save 10-20 bytes in a HTTP request (the "default document namespace") so developers cannot use the widely extended libxml library (which includes Xpath 1.0). Not good. - XML diff is too complex for expecting that anyone can properly use it. If I want to code a JavaScript web application for watching SIP presence, how will I implement XML diff in JavaScript? It's a no sense, and taking a look to other protocols (i.e. XMPP) they do NOT need it (and still they are really scalable in the whole Internet). So IMHO, after years of playing with SIMPLE, it's clear for me that there is no way for SIMPLE to become developer-friendly and thus, a new SIP presence proposal from scratch makes lot of sense IMHO. Best regards. --=20 I=C3=B1aki Baz Castillo From ben@nostrum.com Thu Oct 18 09:29:24 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F31E21F84F5 for ; Thu, 18 Oct 2012 09:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTPJxBRi8Dpn for ; Thu, 18 Oct 2012 09:29:23 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 82C8221F84FD for ; Thu, 18 Oct 2012 09:29:13 -0700 (PDT) Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9IGT59U045398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 11:29:05 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Thu, 18 Oct 2012 11:29:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <20DF42F3-7690-4228-9514-DED66523E6FF@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <6D4583BE-919C-455E-B8FE-221F19C2BE61@nostrum.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:29:24 -0000 On Oct 18, 2012, at 11:04 AM, I=F1aki Baz Castillo = wrote: >> Can you clarify what you mean by "from scratch"? Do you suggest we = should start SIMPLE over from a blank slate? >=20 > Basically yes. I know SIMPLE specs very well and honestly I don't like > them at all. Just for mentioning some points: >=20 > - The Presence Data Model is too complex. In the world we have users > and the user has devices. I don't understand what a "service" is. > Theorically two devices managed by same AoR should not publish a > different since must be unique, how to do that? And > in case of various devices, how can the watcher match each to > each device? it would make sense to use GRUU here (XMPP uses > "resources"), but we have nothing about that. The data model could be simplified, or perhaps we could do a BCP = clarifying things and recommending particular usages. >=20 > - If I subscribe using RLS I will get a very big first NOTIFY > containing all the presence bodies of all my watched contacts, so SIP > TCP is required. If so, why must I implement HTTP/XCAP for storing my > "buddy list"? Which other IM/presence protocol implements both the > protocol itself and HTTP for related stuff? This involves two servers, > two TLS certificates, two authentication points, double lines of > code... We can transfer a ISO image using MSRP but we need HTTP for > storing a simple buddy list and permissions policy? I'm not convinced by the "just implement one protocol" argument. I'm = hard pressed to imagine a useful client that only implements SIP, and = I'd be surprised if a mature client with high market penetration doesn't = eventually need to implement HTTP _somewhere_ for _something_.=20 >=20 > - As Adrian pointed out, a SIMPLE client needs to mantain ~18 SIP/HTTP > "dialogs" (subscriptions to XCAP-diff, winfo, presence...). > Subscriptions means "dialogs" and dialogs are really a bad idea in the > new Internet ecosystem: the mobile devices (those that dynamically > change their IP or gets unreachable for a while). Mobiles apps want to > use the PUSH mechanism, something unfeasible with SIMPLE > subscriptions. IMHO a stateless mechanism based on PULL and PUSH would > be the key. Nothing to reuse from SIMPLE here. Are these issues specific to SIMPLE, or an artifact of SIMPLE using SIP = in the first place? Are 18 dialogs that much worse than 1, if it forces = the client to nail up a TCP connection and/or outbound proxy binding? = (i.e. is this a protocol problem, or a network architecture problem?) What mechanism do you have in mind for "the PUSH mechanism"? >=20 > - Managing a buddy list or presence authorizations should be simple > and easy. Instead we have a generic protocol (XCAP) for performing > partial modifications in remote XML documents, and when a modification > takes place the presence server and all the watchers (same AoR) must > re-evaluate all the XML documents along their relationship with all > the other XML documents, otherwise it's near imposible to detect what > such an incremental XML change involves, and this means high CPU usage > in both servers and clients. >=20 > - Blocking/allowing presence authorization for a buddy should be an > atomic/boolean operation (like in XMPP). But in SIMPLE/XCAP we have > two options: >=20 > 1) Upload the new full XML documents with all the buddies (so let > the server and others to full re-evaluate it again). > 2) Two operations: delete a buddy from some "list", and then include > it in some other "list" (partial DELETE/PUT), so double notification. >=20 > - In XMPP blocking/allowing/subscribing/desubscribing to a buddy is an > atomic operation: the user sends the full XML definition of the buddy > to the server, with all the buddy attributes. The server notifies the > buddy new properties to other resources of the same account. In SIMPLE > anyone can do whatever XCAP allows (which is really too much). Does > XMPP need so powerful control over the "XML files"? Sure not. >=20 > - XCAP is like Xpath 1.0 but is not compatible with it since it adds a > "cool" feature to save 10-20 bytes in a HTTP request (the "default > document namespace") so developers cannot use the widely extended > libxml library (which includes Xpath 1.0). Not good. >=20 > - XML diff is too complex for expecting that anyone can properly use > it. If I want to code a JavaScript web application for watching SIP > presence, how will I implement XML diff in JavaScript? It's a no > sense, and taking a look to other protocols (i.e. XMPP) they do NOT > need it (and still they are really scalable in the whole Internet). >=20 'm open to the argument that XCAP is too complex. But that's only one = piece of the bigger puzzle. >=20 > So IMHO, after years of playing with SIMPLE, it's clear for me that > there is no way for SIMPLE to become developer-friendly and thus, a > new SIP presence proposal from scratch makes lot of sense IMHO. I'm extremely doubtful we could get traction with a completely new SIP = based PIM. I also strongly doubt the IESG would approve work on such a = thing. If SIMPLE is completely unfit for purpose, then we'd be better = focusing on using XMPP with SIP. From pkyzivat@alum.mit.edu Thu Oct 18 09:44:00 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B6821F84A6 for ; Thu, 18 Oct 2012 09:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqjlZLhUcjVi for ; Thu, 18 Oct 2012 09:43:59 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 9513321F84F3 for ; Thu, 18 Oct 2012 09:43:59 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id CggR1k0030Fqzac56gk3Uj; Thu, 18 Oct 2012 16:44:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id Cgjn1k00C3ZTu2S3UgjnZg; Thu, 18 Oct 2012 16:43:47 +0000 Message-ID: <508031CD.5000401@alum.mit.edu> Date: Thu, 18 Oct 2012 12:43:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Georgescu References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> In-Reply-To: <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:44:00 -0000 There is a lot in here, and you guys are closer to it than I am, so mostly I am going to try to stand back and watch you talk it out. I will observe that some things are, or can be, UI issues or API issues rather than protocol issues. For better or worse IETF doesn't do UI and API. So it's important to draw the lines carefully. Or establish a partnership with another SDO that does those things, like W3C, as is going on with RTCWEB/WEBRTC. Thanks, Paul On 10/17/12 6:53 PM, Adrian Georgescu wrote: > Hi Paul, > > In a client UI, one can aggregate contacts from different data sources. The UI may make the look uniform (like showing them on same groups or not) but the contacts and groups have different properties given by their original maker. > > The goal is define one schema pertinent to SIMPLE where one can make a list of URIs with their type and organize them in groups. Each contacts can be subscribed to and a policy can be expressed for each contact. In a SIP client I can render today a contacts list consisting of: > > SIMPLE Contacts > MacOSX Addresbook > Google Contacts > Bonjour Contacts > > These groups are all disjunct with regards to their capabilities and properties. In SIMPLE case I want to be able to be able to use multimedia sessions and subscribe to presence information published by those contacts, the other contacts are used for audio calls or chat sessions and no presence. That works just fine with my implementation. What I cannot do, is to use another SIMPLE client that implements the same functionality for the SIMPLE Contacts part so that same list can be see the same way from a mobile device for example. > > This is the missing part of SIMPLE, in order to use the standards to write a client in the same way by multiple vendors we need a common definition for to to write and read same contacts list with their properties. I cannot highlight this enough. People end up talking about anything else like scalability XMPP etc, when the real problem is the lack of interoperability of clients under the same account. > > Adrian > > > On Oct 18, 2012, at 12:29 AM, Paul Kyzivat wrote: > >> On 10/17/12 5:31 PM, Adrian Georgescu wrote: >>>> At the end of the day, I just want to be able to put anybody into my buddy list, regardless of what protocol they use, and be able to establish sessions with them that can use any combination of voice, video, and IM that seems useful at the time. >>> >>> Hi Paul! >>> >>> This sounds like a great goal. >>> >>> As you say, putting anyone in a buddy list that just works when one tries to communicate would be a great achieving of this WG. >>> >>> This requires the concept of a buddy list., which is really the missing part. I called it address-book, you called it buddy list and is really the same thing. >>> >>> Could we converge on this idea of having to define this buddy list/address book part of SIMPLE? >> >> ISTM that a buddy list can be considered as a subset of an address book. There are lots of things I keep in an address book that have nothing to do with my presence buddy list. >> >> Setting out to define a complete address book seems like a dangerous slippery slope. There are lots of other organizations that will have opinions on that and perhaps think it is within their scope rather than ours. (And they are probably right.) >> >> To have any success it will be necessary to figure out how to scope this down. Perhaps an abstract model that can be mapped onto a variety of things. Or else find a model already defined someplace else that we can just reference. >> >> Thanks, >> Paul >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > > From ibc@aliax.net Thu Oct 18 09:47:21 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F6321F853D for ; Thu, 18 Oct 2012 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GU2JYCFKmCg for ; Thu, 18 Oct 2012 09:47:20 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6962921F84F9 for ; Thu, 18 Oct 2012 09:47:19 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so6738183lam.31 for ; Thu, 18 Oct 2012 09:47:18 -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=QhZWh8efIIoR2eznZeT8EM7LtC/U0pIo0LIly+ldgJI=; b=YMvRMnbR48mP6jjVfpQ21mDUhOYo/w9KR5dGSrstGcALutJKV93qEi1kl83zn8s8v0 xNrQYp6dl+wVRMJV2DlcS9k9s2G3ECAG+LbK2/zoOmvjm8khlLSvz1rxljoulMXzY1b3 WqeG9IU1KagxvCnqhXi3Ex4t7iW0b5rGDY4ZH4fRf1EOX/rXlb+NfTKWScYwGfmpp65Y iOiZxlZ8TBvBqklPqE/7u7t/cNaH1i/GIp8EX2eNbUKml1Wi7DEQzTj279QWL6Rfi33E 30fgy4s84uHZmHV8sxAVlQ1vuQNbgHWphgC59qfu47uGtO+tkIlaQodVz4bjbGEvgHMw B1Yg== Received: by 10.152.135.41 with SMTP id pp9mr19222593lab.7.1350578837311; Thu, 18 Oct 2012 09:47:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 09:46:56 -0700 (PDT) In-Reply-To: <20DF42F3-7690-4228-9514-DED66523E6FF@nostrum.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <6D4583BE-919C-455E-B8FE-221F19C2BE61@nostrum.com> <20DF42F3-7690-4228-9514-DED66523E6FF@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 18:46:56 +0200 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnUy3rEBR5YNVVFkbCJJNbHJIPIczzwHTDgzwoAQBNtMIUR6vP6j68OzUszLa9YRb0NwGii Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:47:21 -0000 2012/10/18 Ben Campbell : > I'm not convinced by the "just implement one protocol" argument. I'm hard= pressed to imagine a useful client that only implements SIP, and I'd be su= rprised if a mature client with high market penetration doesn't eventually = need to implement HTTP _somewhere_ for _something_. Implementing also HTTP means, at least, two TCP connections (even more since HTTP uses a new TCP connection for every request/response unless pipeline is used, that AFAIK is not widely used in simple HTTP clients...). But I don't focus on that. I focus on the fact that a client must implement SIP and HTTP and use "same credentials" on both, and the service provider must run SIP and HTTP infraestructure, with probably different TLS certificates, and must make both SIP and HTTP servers to authenticate to the same backend, which is not always possible with existing software. >> - As Adrian pointed out, a SIMPLE client needs to mantain ~18 SIP/HTTP >> "dialogs" (subscriptions to XCAP-diff, winfo, presence...). >> Subscriptions means "dialogs" and dialogs are really a bad idea in the >> new Internet ecosystem: the mobile devices (those that dynamically >> change their IP or gets unreachable for a while). Mobiles apps want to >> use the PUSH mechanism, something unfeasible with SIMPLE >> subscriptions. IMHO a stateless mechanism based on PULL and PUSH would >> be the key. Nothing to reuse from SIMPLE here. > > Are these issues specific to SIMPLE, or an artifact of SIMPLE using SIP i= n the first place? I don't know what to reply here. SIMPLE is basically SIP :) My concern is that SIMPLE depends too much on SIP subscriptions, which are expensive, error prune and bad for mobile apps. > Are 18 dialogs that much worse than 1, if it forces the client to nail up= a TCP connection and/or outbound proxy binding? (i.e. is this a protocol p= roblem, or a network architecture problem?) It's not about resource usages for mantaining 18 dialogs, but about the complexity it involves in the application logic. > What mechanism do you have in mind for "the PUSH mechanism"? Exactly this: http://sip-space.net/flows/mutual-presence-authorization/ It's a proposal I started some time ago. It just uses SIP (no HTTP) and defines new methods: - STORE: used to manage content in the server (i.e. buddylist). - PULL: used by clients to ask a buddy for some information (i.e. presence status). - PUSH: used by presence agents to notify watchers that a buddy has changed something so the watcher may want to perform a PULL request again. Both PULL and PUSH are a stateless mechanism (no subscription/dialog here) and fit very well with the Push mechanism in mobile apps (the server notifies something to the app via a single TCP connection, with minimal information, and the app decides whether to wake-up, warn the user, or automaticall retrieve the desired information). >> - XCAP is like Xpath 1.0 but is not compatible with it since it adds a >> "cool" feature to save 10-20 bytes in a HTTP request (the "default >> document namespace") so developers cannot use the widely extended >> libxml library (which includes Xpath 1.0). Not good. >> >> - XML diff is too complex for expecting that anyone can properly use >> it. If I want to code a JavaScript web application for watching SIP >> presence, how will I implement XML diff in JavaScript? It's a no >> sense, and taking a look to other protocols (i.e. XMPP) they do NOT >> need it (and still they are really scalable in the whole Internet). >> > > I'm open to the argument that XCAP is too complex. But that's only one pi= ece of the bigger puzzle. Yes, I agree. >> So IMHO, after years of playing with SIMPLE, it's clear for me that >> there is no way for SIMPLE to become developer-friendly and thus, a >> new SIP presence proposal from scratch makes lot of sense IMHO. > > I'm extremely doubtful we could get traction with a completely new SIP ba= sed PIM. I also strongly doubt the IESG would approve work on such a thing.= If SIMPLE is completely unfit for purpose, then we'd be better focusing on= using XMPP with SIP. I understand what you say. But I would also like to insist that XMPP is not the panacea. It was initially designed 12 years ago (?), remember: Jabber. The mechanism for basic presence distribution is very simple and easy to implement, but for more complex features XMPP also implement subscription/notification, so both mechanism live togheter. Of course buddylist management is much more easier in XMPP, but still I think that in 2012 we can do something much better by learning from XMPP and SIMPLE. Regards. --=20 I=C3=B1aki Baz Castillo From b_mccolgan@hotmail.com Thu Oct 18 09:51:58 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13C221F8776 for ; Thu, 18 Oct 2012 09:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C43qA6GcZuCK for ; Thu, 18 Oct 2012 09:51:54 -0700 (PDT) Received: from bay0-omc2-s20.bay0.hotmail.com (bay0-omc2-s20.bay0.hotmail.com [65.54.190.95]) by ietfa.amsl.com (Postfix) with ESMTP id D433C21F8772 for ; Thu, 18 Oct 2012 09:51:52 -0700 (PDT) Received: from BAY170-W38 ([65.54.190.125]) by bay0-omc2-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Oct 2012 09:51:52 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_11a36743-ee10-4cbd-9062-f10a8fa56176_" X-Originating-IP: [208.65.73.39] From: Brian McColgan To: , , Date: Thu, 18 Oct 2012 12:51:52 -0400 Importance: Normal In-Reply-To: References: , <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com>, , MIME-Version: 1.0 X-OriginalArrivalTime: 18 Oct 2012 16:51:52.0367 (UTC) FILETIME=[DF94C3F0:01CDAD50] Subject: Re: [Simple] SIP SIMPLE end-point addressbook application X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:51:58 -0000 --_11a36743-ee10-4cbd-9062-f10a8fa56176_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments: - Tight binding of presence service/conveyance and an AB is poor design a= nd counters the KISS pattern (http://www.objectmentor.com/resources/article= s/srp.pdf) - A presence capable AB is fine=2C but presence conveyance should equal= ly serve other communication/services as well (translation: don't mix these= together) - a corollary to this is an AB does not need to be presence capable= (it can and would benefit from this - but it should be a MAY not a SHOULD = or MUST/SHALL) - If the AB can't be designed in such a way as to 'plug replace' pres-i= nfo publication/conveyance (regardless of protocol/transports) then the mod= el is wrong=20 - BTW - pres-rules has nothing to do with an AB it is a generic pol= icy mechanism for deciding who see's what (when a candidate observer comes = calling) =20 - Overlap of work already taken place in OMA=20 - given we are now in the all-IP era - I would strongly recommend (thos= e with an open mind) re-investigate at least in Converged Address Book 1.0 - a CAB API Enabler is also being developed (RESTful) from the work= in CAB 1.0 - enhancements have also been made in CAB 1.1 for social-networking=2C = including discovery of mutual contacts (a useful enhancement) - support in 1.1 also includes connecting to 3rd-party platforms (e.g. = import/export of non-CAB)=20 - CAB also has a single single data-model/schema and mappings from vCAR= D described Further comments: - Discussion between PaulK and Adrian (re: dialogues) isn't interoperabili= ty - that is orchestration (i.e. managing dialogues to complete one or more= aggregate functions) - if ALL exchanges (on the wire) follow conformant aspects of the respe= ctive RFC=2C then by extension they are interoperable (at the RFC level) - The combine of conformant call-flows (from the respective RFCs) to me= is more in the scope of a service Enabler (something OMA deals with) - not= a component RFC - Why does IETF want to reinvent work (Converged Address Book) alrea= dy carried out in OMA? =20 =20 Thoughts to ponder.=20 > From: ag@ag-projects.com > Date: Wed=2C 17 Oct 2012 21:12:49 +0200 > To: Oej@edvina.net=3B simple@ietf.org > Subject: [Simple] SIP SIMPLE end-point addressbook application >=20 > Hi Olle=2C >=20 > I changed the original subject=2C as we all like success stories rather t= han failures. >=20 > For Blink in particular=2C we developed a simple (pardon the over abused = word) to use AddressBook schema where one can store Contacts with multiple = URIs of different types and arbitrary attribute-value pairs that the User A= gent may need to store per contact plus a way to Group them together. To su= bscribe for presence to a contact and provide a policy one can set boolean = values that any developer not familiar with the SIP protocol mechanics shou= ld be able to use. Information that is proprietary to end-points made by a = vendor can be stored=2C atomically and in a way that does not collide with = the desires of other vendors. >=20 > The schema is documented here: >=20 > http://sipsimpleclient.com/projects/sipsimpleclient/repository/entry/sips= imple/payloads/xml-schemas/addressbook.xsd >=20 > An actual implementation in Python is available here=3B >=20 > http://sipsimpleclient.com/projects/sipsimpleclient/repository/changes/si= psimple/payloads/addressbook.py >=20 > To eliminate the complexity and eliminate the non-atomicity of having to = use several XCAP documents like rls-services=2C resource-lists and pres-rul= es for storing these information.=20 >=20 > I propose to define=2C part of a further standardization effort of SIMPLE= or another IETF WG that is chartered for this purpose=2C the SIP SIMPLE en= d-point addressbook application=2C an application that can be used both by = end-points and the Presence Agent for obtaining the policy for subscribing = to one's presence. >=20 > This way=2C we can achieve two goals closely related to SIMPLE charter: >=20 > 1. Any SIP end-point developer can develop its own SIMPLE implementation = perfectly inter-operable with any other SIMPLE end-point and compatible at = the same time with the server side=2C the presence agent. > 2. As interest with XMPP is on the rise=2C we can now capture all gateway= features that will make the interoperability with XMPP 100% defined and pr= oven by open source implementations >=20 > For those who do not adhere or care about such high-level API=2C they may= continue to use at their discretion the low-level building blocks already = in place as nothing will change on-the-wire between domains or within the s= ame domain as far as SIP signaling is concerned. >=20 > Shall these goals be considered a desirable outcome for SIMPLE=2C in the = old tradition of good ideas backed not just be empty words but by open sour= ce implementations=2C there might be a chance to turn SIMPLE into a success= story. >=20 > Feedback is welcome. >=20 > Adrian >=20 > On Oct 17=2C 2012=2C at 8:22 PM=2C Olle E. Johansson wrote: >=20 > >=20 > > 17 okt 2012 kl. 15:14 skrev Adrian Georgescu : > >=20 > >>> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-work= solution. Not sure what that will achieve. > >=20 > > That's fine=2C but a separate project. If the only way we can get inter= operability between SIMPLE implentations is using XMPP between them=2C that= feels like a stupid solution to me. I do want to be able to use SIMPLE to = communicate with other SIMPLE implementations. I want to be able to use one= SIMPLE client from one vendor on my smartphone and share the address book/= buddy list and presence ruleset with my other SIMPLE client on the desktop. > >=20 > > That's what customers expect. And that's not where we are today with th= e IETF specs=2C and if I parse right=2C maybe not with the inclusion of the= 3rd party OMA specs. > >=20 > > /O > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple = --_11a36743-ee10-4cbd-9062-f10a8fa56176_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Comments:

 =3B - Tight binding of presence servic= e/conveyance and an AB is =3Bpoor design and counters the KISS pattern = (http://www.objectmentor.com/resources/articles/srp.pdf)
 =3B = =3B =3B - A presence capable AB is fine=2C but presence conveyance shou= ld equally serve other communication/services as well (translation: don't m= ix these together)
 =3B =3B =3B =3B =3B =3B = =3B - a corollary to this is an AB does not need to be presence capable (it= can and would benefit from this - but it should be a MAY not a SHOULD or M= UST/SHALL)
 =3B =3B =3B - If the AB can't be designed in suc= h a way as to 'plug replace' pres-info publication/conveyance (regardless o= f protocol/transports) then the model is wrong
 =3B =3B =3B=  =3B =3B =3B =3B - BTW - =3Bpres-rules has nothing to d= o with an AB it is a generic policy mechanism for deciding who see's what (= when a candidate observer comes calling)
 =3B
 =3B- Overlap o= f work already taken place in OMA
 =3B =3B =3B - =3Bgiv= en we are now in the all-IP era - I would strongly recommend (those with an= open mind) re-investigate at least in Converged Address Book 1.0
 =3B =3B =3B =3B =3B =3B =3B - a= CAB API Enabler is also being =3Bdeveloped (RESTful) from the work in = CAB 1.0
 =3B =3B =3B - enhancements have also been made in C= AB 1.1 for social-networking=2C including discovery of mutual contacts (a u= seful enhancement)
 =3B =3B =3B - support in 1.1 also includ= es connecting to 3rd-party platforms (e.g. import/export of non-CAB) = =3B
 =3B =3B =3B - CAB also has a single single data= -model/schema and mappings from vCARD described
Further comments:
 =3B- Discussion between PaulK and Adrian (re: dialogues= ) isn't interoperability - that is orchestration (i.e. managing dialogues t= o complete one or more aggregate functions)
 =3B =3B =3B - if ALL exchanges (on the wire) fo= llow conformant aspects of the respective RFC=2C then by extension they are= interoperable (at the RFC level)
 =3B =3B =3B - The combine of conformant call-fl= ows (from the respective =3BRFCs) to me is more in the scope of =3B= a service Enabler (something OMA deals with) - not a component RFC
 =3B =3B =3B =3B =3B =3B - Why does = IETF want to reinvent work (Converged Address Book) already carried out in = OMA? =3B
 =3B
Thoughts to ponder. =3B

>=3B From: ag@ag-projects.com
>= =3B Date: Wed=2C 17 Oct 2012 21:12:49 +0200
>=3B To: Oej@edvina.net=3B= simple@ietf.org
>=3B Subject: [Simple] SIP SIMPLE end-point addressbo= ok application
>=3B
>=3B Hi Olle=2C
>=3B
>=3B I chang= ed the original subject=2C as we all like success stories rather than failu= res.
>=3B
>=3B For Blink in particular=2C we developed a simple = (pardon the over abused word) to use AddressBook schema where one can store= Contacts with multiple URIs of different types and arbitrary attribute-val= ue pairs that the User Agent may need to store per contact plus a way to Gr= oup them together. To subscribe for presence to a contact and provide a pol= icy one can set boolean values that any developer not familiar with the SIP= protocol mechanics should be able to use. Information that is proprietary = to end-points made by a vendor can be stored=2C atomically and in a way tha= t does not collide with the desires of other vendors.
>=3B
>=3B = The schema is documented here:
>=3B
>=3B http://sipsimpleclient.= com/projects/sipsimpleclient/repository/entry/sipsimple/payloads/xml-schema= s/addressbook.xsd
>=3B
>=3B An actual implementation in Python i= s available here=3B
>=3B
>=3B http://sipsimpleclient.com/project= s/sipsimpleclient/repository/changes/sipsimple/payloads/addressbook.py
&= gt=3B
>=3B To eliminate the complexity and eliminate the non-atomicit= y of having to use several XCAP documents like rls-services=2C resource-lis= ts and pres-rules for storing these information.
>=3B
>=3B I pr= opose to define=2C part of a further standardization effort of SIMPLE or an= other IETF WG that is chartered for this purpose=2C the SIP SIMPLE end-poin= t addressbook application=2C an application that can be used both by end-po= ints and the Presence Agent for obtaining the policy for subscribing to one= 's presence.
>=3B
>=3B This way=2C we can achieve two goals clos= ely related to SIMPLE charter:
>=3B
>=3B 1. Any SIP end-point de= veloper can develop its own SIMPLE implementation perfectly inter-operable = with any other SIMPLE end-point and compatible at the same time with the se= rver side=2C the presence agent.
>=3B 2. As interest with XMPP is on t= he rise=2C we can now capture all gateway features that will make the inter= operability with XMPP 100% defined and proven by open source implementation= s
>=3B
>=3B For those who do not adhere or care about such high-= level API=2C they may continue to use at their discretion the low-level bui= lding blocks already in place as nothing will change on-the-wire between do= mains or within the same domain as far as SIP signaling is concerned.
&g= t=3B
>=3B Shall these goals be considered a desirable outcome for SIM= PLE=2C in the old tradition of good ideas backed not just be empty words bu= t by open source implementations=2C there might be a chance to turn SIMPLE = into a success story.
>=3B
>=3B Feedback is welcome.
>=3B <= BR>>=3B Adrian
>=3B
>=3B On Oct 17=2C 2012=2C at 8:22 PM=2C Ol= le E. Johansson wrote:
>=3B
>=3B >=3B
>=3B >=3B 17 okt= 2012 kl. 15:14 skrev Adrian Georgescu <=3Bag@ag-projects.com>=3B:
&= gt=3B >=3B
>=3B >=3B>=3B>=3B It seems however IETF is plowing= toward an XMPP/SIP-SIMPLE inter-work solution. Not sure what that will ach= ieve.
>=3B >=3B
>=3B >=3B That's fine=2C but a separate proj= ect. If the only way we can get interoperability between SIMPLE implentatio= ns is using XMPP between them=2C that feels like a stupid solution to me. I= do want to be able to use SIMPLE to communicate with other SIMPLE implemen= tations. I want to be able to use one SIMPLE client from one vendor on my s= martphone and share the address book/buddy list and presence ruleset with m= y other SIMPLE client on the desktop.
>=3B >=3B
>=3B >=3B Th= at's what customers expect. And that's not where we are today with the IETF= specs=2C and if I parse right=2C maybe not with the inclusion of the 3rd p= arty OMA specs.
>=3B >=3B
>=3B >=3B /O
>=3B >=3B ____= ___________________________________________
>=3B >=3B Simple mailing= list
>=3B >=3B Simple@ietf.org
>=3B >=3B https://www.ietf.or= g/mailman/listinfo/simple
>=3B >=3B
>=3B
>=3B __________= _____________________________________
>=3B Simple mailing list
>= =3B Simple@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/simple<= BR>
= --_11a36743-ee10-4cbd-9062-f10a8fa56176_-- From oej@edvina.net Thu Oct 18 11:01:37 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3962621F84B0 for ; Thu, 18 Oct 2012 11:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLQUYQFQ6epq for ; Thu, 18 Oct 2012 11:01:36 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0395B21F84AD for ; Thu, 18 Oct 2012 11:01:35 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id D8020754A8AA; Thu, 18 Oct 2012 18:01:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <508031CD.5000401@alum.mit.edu> Date: Thu, 18 Oct 2012 20:01:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> <508031CD.5000401@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1499) Cc: Adrian Georgescu , simple@ietf.org Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:01:37 -0000 18 okt 2012 kl. 18:43 skrev Paul Kyzivat : > There is a lot in here, and you guys are closer to it than I am, so = mostly I am going to try to stand back and watch you talk it out. Feel free to participate. You have years of experience in this too :-) >=20 > I will observe that some things are, or can be, UI issues or API = issues rather than protocol issues. For better or worse IETF doesn't do = UI and API. So it's important to draw the lines carefully. Or establish = a partnership with another SDO that does those things, like W3C, as is = going on with RTCWEB/WEBRTC. Absolutely. But the requirement to be able to integrate with a UI may = affect the protocol solution.=20 XMPP has this problem. The XMPP server is not aware of the presence, it = just routes stanzas. Without caching stanzas or doing something else, it = is just not possible to create an API into the server and get the = presence of a particular JID. In SIP the server aggregates the presence = and is aware of it, so we can send SUBSCRIBE with expire:0 and query for = presence. Thus, we can integrate into an address book more easily from a = SIP presence server. /O >=20 > Thanks, > Paul >=20 > On 10/17/12 6:53 PM, Adrian Georgescu wrote: >> Hi Paul, >>=20 >> In a client UI, one can aggregate contacts from different data = sources. The UI may make the look uniform (like showing them on same = groups or not) but the contacts and groups have different properties = given by their original maker. >>=20 >> The goal is define one schema pertinent to SIMPLE where one can make = a list of URIs with their type and organize them in groups. Each = contacts can be subscribed to and a policy can be expressed for each = contact. In a SIP client I can render today a contacts list consisting = of: >>=20 >> SIMPLE Contacts >> MacOSX Addresbook >> Google Contacts >> Bonjour Contacts >>=20 >> These groups are all disjunct with regards to their capabilities and = properties. In SIMPLE case I want to be able to be able to use = multimedia sessions and subscribe to presence information published by = those contacts, the other contacts are used for audio calls or chat = sessions and no presence. That works just fine with my implementation. = What I cannot do, is to use another SIMPLE client that implements the = same functionality for the SIMPLE Contacts part so that same list can be = see the same way from a mobile device for example. >>=20 >> This is the missing part of SIMPLE, in order to use the standards to = write a client in the same way by multiple vendors we need a common = definition for to to write and read same contacts list with their = properties. I cannot highlight this enough. People end up talking about = anything else like scalability XMPP etc, when the real problem is the = lack of interoperability of clients under the same account. >>=20 >> Adrian >>=20 >>=20 >> On Oct 18, 2012, at 12:29 AM, Paul Kyzivat wrote: >>=20 >>> On 10/17/12 5:31 PM, Adrian Georgescu wrote: >>>>> At the end of the day, I just want to be able to put anybody into = my buddy list, regardless of what protocol they use, and be able to = establish sessions with them that can use any combination of voice, = video, and IM that seems useful at the time. >>>>=20 >>>> Hi Paul! >>>>=20 >>>> This sounds like a great goal. >>>>=20 >>>> As you say, putting anyone in a buddy list that just works when one = tries to communicate would be a great achieving of this WG. >>>>=20 >>>> This requires the concept of a buddy list., which is really the = missing part. I called it address-book, you called it buddy list and is = really the same thing. >>>>=20 >>>> Could we converge on this idea of having to define this buddy = list/address book part of SIMPLE? >>>=20 >>> ISTM that a buddy list can be considered as a subset of an address = book. There are lots of things I keep in an address book that have = nothing to do with my presence buddy list. >>>=20 >>> Setting out to define a complete address book seems like a dangerous = slippery slope. There are lots of other organizations that will have = opinions on that and perhaps think it is within their scope rather than = ours. (And they are probably right.) >>>=20 >>> To have any success it will be necessary to figure out how to scope = this down. Perhaps an abstract model that can be mapped onto a variety = of things. Or else find a model already defined someplace else that we = can just reference. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From oej@edvina.net Thu Oct 18 11:23:28 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A173521F8504 for ; Thu, 18 Oct 2012 11:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejh2I9Aja611 for ; Thu, 18 Oct 2012 11:23:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C804721F8509 for ; Thu, 18 Oct 2012 11:23:27 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id A8764754A8A7; Thu, 18 Oct 2012 18:23:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 18 Oct 2012 20:23:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <6D4583BE-919C-455E-B8FE-221F19C2BE61@nostrum.com> <20DF42F3-7690-4228-9514-DED66523E6FF@nostrum.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1499) Cc: Simple WG Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:23:28 -0000 As I haven't even tried to implement a full SIMPLE client I can't argue = with developers, just learn from what you write. The more the better.=20 I don't think we should throw away everything going down to the core SIP = protocol and trying to replace SUBSCRIBE/NOTIFY and PUBLISH. There are = ways to filter notifications and significant work.=20 So far, I've seen a few issues brought up: * PIDF status *may* bee too complex, especially in combination with XCAP = and the operations of XCAP (non-atomic, external references with full = urls etc) * Buddy lists are too complex and unmanageable * The IETF documents leave gaps in Buddy List management Apart from that, there are many mails about the total complexity with 18 = subscriptions, multiple XCAP formats intermingled with multiple sources = of application usages from both organizations and developers. Seems like = most of us that have mailed so far agree that this is too complex. To take a naive approach to this, can we * Dramatically reduce the number of subscriptions by implementing - one for synchronization of informaiton between one user's clients - = presence-ua-config - one for presence updates from my buddy list - presence-updates * Reduce the number of documents, possibly - one simple-buddy-list=20 - one auth-rules document * FInd a way to separate device states from user states and rules on how = to aggregate this - "This phone is busy" vs "OEJ's calendar says he is on a = wine-tasting in France, so he's obviously busy" The icon could be part of my own entry in my own buddy list, visible for = all buddies The notifications from presence-ua-config would include changes in buddy = lists, auth requests and much more. An aggregation - and simplification = - of a lot of the stuff that the years of work done in SIMPLE, XMPP and = OMA. If you shut your eyes for the pile of XML schemas and XCAP auids, = there is a lot of ideas and good functionality for applications hidden = in there. I see no point in throwing it away, just trying to create = something simple that is a concentrated, stream-lined and focused = application. And we should not forget that it has to be extensible in = some way too, so we don't end up with a new subscription, new XML = schema, new URN and new AUID for every extension. Then we're going to = end up quickly in the very same situation we are in now. Let's try to focus on attacking the solution from this end and see if we = can agree. I think we're done complaining over the existing solution for = a while. Note that I'm not saying that we have to use XML or XCAP. Let's = just talk "documents" and "subscriptions" and see where we end up. /O From pkyzivat@alum.mit.edu Thu Oct 18 11:36:43 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C7F21F84AB for ; Thu, 18 Oct 2012 11:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOy4sEdVD3HH for ; Thu, 18 Oct 2012 11:36:43 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id ED6A621F84A9 for ; Thu, 18 Oct 2012 11:36:42 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id Capw1k00D0cZkys53icngB; Thu, 18 Oct 2012 18:36:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Cicf1k00f3ZTu2S3Wicf8e; Thu, 18 Oct 2012 18:36:40 +0000 Message-ID: <50804C38.9040204@alum.mit.edu> Date: Thu, 18 Oct 2012 14:36:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> <508031CD.5000401@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:36:44 -0000 On 10/18/12 2:01 PM, Olle E. Johansson wrote: > > 18 okt 2012 kl. 18:43 skrev Paul Kyzivat : > >> There is a lot in here, and you guys are closer to it than I am, so mostly I am going to try to stand back and watch you talk it out. > Feel free to participate. You have years of experience in this too :-) I said I would "try" to stand back and watch. It is unlikely that I will actually remain silent. :-) >> I will observe that some things are, or can be, UI issues or API issues rather than protocol issues. For better or worse IETF doesn't do UI and API. So it's important to draw the lines carefully. Or establish a partnership with another SDO that does those things, like W3C, as is going on with RTCWEB/WEBRTC. > Absolutely. But the requirement to be able to integrate with a UI may affect the protocol solution. > > XMPP has this problem. The XMPP server is not aware of the presence, it just routes stanzas. Without caching stanzas or doing something else, it is just not possible to create an API into the server and get the presence of a particular JID. In SIP the server aggregates the presence and is aware of it, so we can send SUBSCRIBE with expire:0 and query for presence. Thus, we can integrate into an address book more easily from a SIP presence server. Part of the solution could be enhancements to XMPP. (I say that from the comfortable position of knowing nothing about XMPP.) Thanks, Paul > /O >> >> Thanks, >> Paul >> >> On 10/17/12 6:53 PM, Adrian Georgescu wrote: >>> Hi Paul, >>> >>> In a client UI, one can aggregate contacts from different data sources. The UI may make the look uniform (like showing them on same groups or not) but the contacts and groups have different properties given by their original maker. >>> >>> The goal is define one schema pertinent to SIMPLE where one can make a list of URIs with their type and organize them in groups. Each contacts can be subscribed to and a policy can be expressed for each contact. In a SIP client I can render today a contacts list consisting of: >>> >>> SIMPLE Contacts >>> MacOSX Addresbook >>> Google Contacts >>> Bonjour Contacts >>> >>> These groups are all disjunct with regards to their capabilities and properties. In SIMPLE case I want to be able to be able to use multimedia sessions and subscribe to presence information published by those contacts, the other contacts are used for audio calls or chat sessions and no presence. That works just fine with my implementation. What I cannot do, is to use another SIMPLE client that implements the same functionality for the SIMPLE Contacts part so that same list can be see the same way from a mobile device for example. >>> >>> This is the missing part of SIMPLE, in order to use the standards to write a client in the same way by multiple vendors we need a common definition for to to write and read same contacts list with their properties. I cannot highlight this enough. People end up talking about anything else like scalability XMPP etc, when the real problem is the lack of interoperability of clients under the same account. >>> >>> Adrian >>> >>> >>> On Oct 18, 2012, at 12:29 AM, Paul Kyzivat wrote: >>> >>>> On 10/17/12 5:31 PM, Adrian Georgescu wrote: >>>>>> At the end of the day, I just want to be able to put anybody into my buddy list, regardless of what protocol they use, and be able to establish sessions with them that can use any combination of voice, video, and IM that seems useful at the time. >>>>> >>>>> Hi Paul! >>>>> >>>>> This sounds like a great goal. >>>>> >>>>> As you say, putting anyone in a buddy list that just works when one tries to communicate would be a great achieving of this WG. >>>>> >>>>> This requires the concept of a buddy list., which is really the missing part. I called it address-book, you called it buddy list and is really the same thing. >>>>> >>>>> Could we converge on this idea of having to define this buddy list/address book part of SIMPLE? >>>> >>>> ISTM that a buddy list can be considered as a subset of an address book. There are lots of things I keep in an address book that have nothing to do with my presence buddy list. >>>> >>>> Setting out to define a complete address book seems like a dangerous slippery slope. There are lots of other organizations that will have opinions on that and perhaps think it is within their scope rather than ours. (And they are probably right.) >>>> >>>> To have any success it will be necessary to figure out how to scope this down. Perhaps an abstract model that can be mapped onto a variety of things. Or else find a model already defined someplace else that we can just reference. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>> >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From stpeter@stpeter.im Thu Oct 18 11:42:18 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED93A21F8519 for ; Thu, 18 Oct 2012 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEXOxoGHs--M for ; Thu, 18 Oct 2012 11:42:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1979B21F84F2 for ; Thu, 18 Oct 2012 11:42:17 -0700 (PDT) Received: from [64.101.72.58] (unknown [64.101.72.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5AA9D40062; Thu, 18 Oct 2012 12:44:58 -0600 (MDT) Message-ID: <50804D8A.4050206@stpeter.im> Date: Thu, 18 Oct 2012 12:42:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Olle E. Johansson" References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> <508031CD.5000401@alum.mit.edu> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Adrian Georgescu , simple@ietf.org, Paul Kyzivat Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:42:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/18/12 12:01 PM, Olle E. Johansson wrote: > > 18 okt 2012 kl. 18:43 skrev Paul Kyzivat : > >> I will observe that some things are, or can be, UI issues or API >> issues rather than protocol issues. For better or worse IETF >> doesn't do UI and API. So it's important to draw the lines >> carefully. Or establish a partnership with another SDO that does >> those things, like W3C, as is going on with RTCWEB/WEBRTC. > > Absolutely. But the requirement to be able to integrate with a UI > may affect the protocol solution. > > XMPP has this problem. The XMPP server is not aware of the > presence, it just routes stanzas. Without caching stanzas or doing > something else, it is just not possible to create an API into the > server and get the presence of a particular JID. Olle, that statement has no basis in reality. Every XMPP server implementation on the planet is aware of the presence state for each Jabber ID under its control. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCATYoACgkQNL8k5A2w/vzgngCgyUbd8x7gvtopn9dylgdKRpuk PLAAn398pHliBOEXqLhb2WkvjkIABLzf =Rtdu -----END PGP SIGNATURE----- From ibc@aliax.net Thu Oct 18 11:56:26 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E242921F8534 for ; Thu, 18 Oct 2012 11:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMYi9JfLVdbN for ; Thu, 18 Oct 2012 11:56:25 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24B4621F84C5 for ; Thu, 18 Oct 2012 11:56:24 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6897896lbo.31 for ; Thu, 18 Oct 2012 11:56:24 -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=5iiUFDzpSuRND1tB0bDtZjr5nIP2tRF/79WGNotx6tE=; b=bgJA0rQweoI6JCK3tN3mo9+69Z8WEBncHEPmCUkaO7Wn8nikFWxG1eyDk2HBS64a46 VtXTqr2+awtFZcmiHqWltwJl5qAOX4Ij/FqvaP1GB7P8ZhiZ81qghoWstfoPiiiEq0AZ pDoILyfNjREjtFny4MyJGQnWS55eJvlv853su/j37s8xl+91EtZdeN0unQgQr8Ujbp4w QJ+nrioz713G9cO9PojUmVEIcQYq43lrRmK1W8YrBCO3GCf5Xu9G/ipq163/PtTKd06b xKW22HNQ+Obxh+1QbrZXRCAdIhD28niCa+H61ZBvsVptYtOueZkp+/SLuZUiwebafJJI cqtw== Received: by 10.152.148.40 with SMTP id tp8mr19282872lab.30.1350586584082; Thu, 18 Oct 2012 11:56:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 11:56:03 -0700 (PDT) In-Reply-To: <50804D8A.4050206@stpeter.im> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> <508031CD.5000401@alum.mit.edu> <50804D8A.4050206@stpeter.im> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 20:56:03 +0200 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkLNu5OZEMThw080Hnm5Lct6yMPMiQ5R8B5gc88UYyx/zyza9bZ1+9vIh55nGgAmsUz0MIf Cc: Adrian Georgescu , simple@ietf.org, Paul Kyzivat Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:56:27 -0000 2012/10/18 Peter Saint-Andre : > Olle, that statement has no basis in reality. Every XMPP server > implementation on the planet is aware of the presence state for each > Jabber ID under its control. Right, in fact the XMPP server decides which user resource to route a XMPP message based on its priority, am I right? (well, unless Gtalk that uses its own "XMPP"...). --=20 I=C3=B1aki Baz Castillo From stpeter@stpeter.im Thu Oct 18 12:01:26 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C2221F850E for ; Thu, 18 Oct 2012 12:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qpRZ8z+INtt for ; Thu, 18 Oct 2012 12:01:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D60E021F84DC for ; Thu, 18 Oct 2012 12:01:24 -0700 (PDT) Received: from [64.101.72.58] (unknown [64.101.72.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7CDDE40062; Thu, 18 Oct 2012 13:04:05 -0600 (MDT) Message-ID: <50805206.2030808@stpeter.im> Date: Thu, 18 Oct 2012 13:01:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> <508031CD.5000401@alum.mit.edu> <50804D8A.4050206@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Adrian Georgescu , simple@ietf.org, Paul Kyzivat Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:01:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/18/12 12:56 PM, Iñaki Baz Castillo wrote: > 2012/10/18 Peter Saint-Andre : >> Olle, that statement has no basis in reality. Every XMPP server >> implementation on the planet is aware of the presence state for >> each Jabber ID under its control. > > Right, in fact the XMPP server decides which user resource to route > a XMPP message based on its priority, am I right? (well, unless > Gtalk that uses its own "XMPP"...). The Google Talk service sends messages to all XMPP resources; this is allowed by RFC 6120 and RFC 6121 but is not the traditional approach. The primary reason why an XMPP server needs to be aware of the presence state of the accounts registered at the service is so that it can respond to presence probes. RFC 6121 describes this in great detail. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCAUgYACgkQNL8k5A2w/vxEugCg2YRBuxu7eFUFre+w6ihyrhHQ i6IAn3BNaa7FulEFzhF3iXvbBzudM3bE =RSQu -----END PGP SIGNATURE----- From ibc@aliax.net Thu Oct 18 12:13:48 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EA021F8428 for ; Thu, 18 Oct 2012 12:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sstR5U-IGAOL for ; Thu, 18 Oct 2012 12:13:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8CB421F86ED for ; Thu, 18 Oct 2012 12:13:46 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6909315lbo.31 for ; Thu, 18 Oct 2012 12:13:45 -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=DaakUbN/pyKjiSRMk2SR2RMPrcD+Twvq34/1m8Zj9kc=; b=Tg3HgKUwWdzMdlzVcvSU4esRZ6vImxgXVyYFeJub3Pk4IGLHIcNITtqmvC1YeYo0lL TI/m+44+Ch+Z0Z7UaIIJbwEOZaDnmC+3KH75oZQnjnIm8IM9WeH8Q86B01ilu6yD7BtZ 1BqiuLS0Gvpj4kRNtSq5KqFvbkFvMTznfksCt5QCEMwplytSAXPLxG7Zj1CZHpVbZutB qWgVQ7Uh2uVLJ5Rt7WudBiqgxUQ5PYcwbXJYqVI3klUYdclRCtq6IsaBkMI0AGZR+koe 3TTWz/33rprx9coi4cO9SykPKWzCm2YTEmdc/l33eJSzl71kEah3eBSPlG1k676baD0N ZD4Q== Received: by 10.152.109.145 with SMTP id hs17mr19536042lab.5.1350587625623; Thu, 18 Oct 2012 12:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 12:13:25 -0700 (PDT) In-Reply-To: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <6D4583BE-919C-455E-B8FE-221F19C2BE61@nostrum.com> <20DF42F3-7690-4228-9514-DED66523E6FF@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 21:13:25 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlR+gcJKKdyVUtoVPxkIYLrD6lxfqFyMX3IZQjCZ+TNPgQJ6+IhBinndqFrOoC+PmZMXQBP Cc: Simple WG Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:13:48 -0000 2012/10/18 Olle E. Johansson : > Let's try to focus on attacking the solution from this end and see if we = can agree. I think we're done complaining over the existing solution for a = while. Note that I'm not saying that we have to use XML or XCAP. Let's just= talk "documents" and "subscriptions" and see where we end up. I don't agree that we should talk "documents". Why "documents"? In XMPP there are no "documents", but a buddylist, which yes, it's represented in XML format but the user cannot modify it in a custom way. For example, I don't remember now the exact syntax of the XMPP buddylist, but it's something like this (I DO not that is not like this): --------------------- 1 1 1 0 ------------------------------ Is that a XML document? humm, yes, but when the user wants to block presence for a buddy it cannot tell the server "set the allowed field to 0 where buddy id =3D=3D "alice@atlanta.com". Instead the user uploads the FULL definition of the buddy to the server, now with 0. So from this point of view this seems more a RPC protocol, something like an "API", rather than "custom modification of remote XML documents" as XCAP is designed for. Being constrained to specific actions makes implementations much easier. So I'm not in favour of talking about "documents". Instead I prefer calling them "buddylist" and them provide an "API" for performing actions over the buddylist (add, remove, block, allow, subscribe-to, unsubscribe-to...), something "idiomatic". I don't want that my SIP device becomes a Vi text editor. In this way, if me (a SIP device) tells the server "block this user" the server easily knows WHAT to do (block such a user and send him some spoofed "offline" presence status). In SIMPLE/XCAP instead, when the user *modifies* a XCAP document the server must recompute the whole document (by also retrieving the "linked" external documents) to understand what the desired operation of the user is. "API" is the winning keyword in today's Internet services, but SIMPLE provides no API at all, but just remote operation over XML documents, in any custom way. So forget documents, and let's design an *API*. Is there something more extensible than an API (request method and parameters)? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Oct 18 12:14:59 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405EF21F84E7 for ; Thu, 18 Oct 2012 12:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Buo7SpZs3O+x for ; Thu, 18 Oct 2012 12:14:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE321F84DF for ; Thu, 18 Oct 2012 12:14:58 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6910153lbo.31 for ; Thu, 18 Oct 2012 12: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=flAvfcDZHPHAUf3fkFkW7rHkjQt8LoUBa1ffoccpDtI=; b=HCsvWR206arcAXvXbLYXBUADOeBM2/5Q4BcdPnQKq55HU1FEna9AlsuqUOWMHTbFD+ V3AVrA12+3azkvC6XSouz2rHN39mYNlctoOfeKycNs1pX2XtCmN4y1bKfSKKoAZDcitk QOC7N531j64FIrUpCpa/rttupuJqDrEJ8muA+sW5YHe9YuSkBrfLRgDaOppXEHN+rKu1 4j1VVywaE+C8igMx5VgNY9BF3/sGnn1KV6+BY3PjaqqyNujr6NVFHiE3rtBF/T/moR3B Z8I6mGGBqryAMh04Hr0pjPq+i0CiLxYWLLmutEA1/nsFws03QtgymDcdGKn4EfSL+XNG cqbA== Received: by 10.112.29.9 with SMTP id f9mr3528046lbh.22.1350587697545; Thu, 18 Oct 2012 12:14:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 12:14:37 -0700 (PDT) In-Reply-To: <50805206.2030808@stpeter.im> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> <508031CD.5000401@alum.mit.edu> <50804D8A.4050206@stpeter.im> <50805206.2030808@stpeter.im> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 21:14:37 +0200 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl6ilCSfXjQXKyuytSUz+Jm3Mk640YNw/W+4qQ6gvkxBVV0v4PTWbQb0xrGEWAy/rV6yNma Cc: Adrian Georgescu , simple@ietf.org, Paul Kyzivat Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:14:59 -0000 2012/10/18 Peter Saint-Andre : > The Google Talk service sends messages to all XMPP resources; this is > allowed by RFC 6120 and RFC 6121 but is not the traditional approach. > > The primary reason why an XMPP server needs to be aware of the > presence state of the accounts registered at the service is so that it > can respond to presence probes. RFC 6121 describes this in great detail. Thanks a lot for the clarification. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Thu Oct 18 12:42:54 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689B721F8514 for ; Thu, 18 Oct 2012 12:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6HSUp5ppDQh for ; Thu, 18 Oct 2012 12:42:53 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD321F8513 for ; Thu, 18 Oct 2012 12:42:52 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 1EA92754A8A7; Thu, 18 Oct 2012 19:42:50 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_336A0202-12F8-4D04-B8A9-0E19052DBE47" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 18 Oct 2012 21:42:49 +0200 Message-Id: <062BC8A5-9CF3-42DC-BC19-72641E214175@edvina.net> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> To: Mary Barnes X-Mailer: Apple Mail (2.1499) Cc: Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:42:54 -0000 --Apple-Mail=_336A0202-12F8-4D04-B8A9-0E19052DBE47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 16 okt 2012 kl. 23:12 skrev Mary Barnes : >=20 >=20 > On Tue, Oct 16, 2012 at 2:01 PM, Ben Campbell wrote: >=20 >=20 > On Oct 16, 2012, at 1:32 PM, Mary Barnes = wrote: >=20 >> > Your suggestion to discuss in DISPATCH and decide if and where we = want to do that work makes sense, and is what DISPATCH is for. = Presumably we can do that in Atlanta. >>=20 >> I believe we're past the deadline for "official" DISPATCH agenda time = for Atlanta. Mary, since you've already commented, do you have thoughts = on that? >> [MB] Yes - we are past the "official" DISPATCH dates. Although, we = have a light agenda since only one topic was requested before the = deadline. We may have some extra time and pending approval from the = ADs, we could have an unofficial discussion after the "official" agenda = to kick this off and pursue it formally in DISPATCH in March (with the = discussion focusing on a proposed charter). I'll ping the ADs and see = what they think. [/MB]=20 >=20 > I also assume any such discussion would be dependent on someone = stepping up to lead it, right? It seems like there are really at least = two things under discussion on the list: SIMPLE/XMPP inter working, and = whether work is needed on SIMPLE itself in order to facilitate = interoperable implementations. > [MB2] Yes, we would need people willing to lead the work as well as = folks that are willing to contribute to and review documents. Yes, = there are two separate things. My comments were on the former. I think = the latter is a different beast and needs more consideration before = thinking that we have something to do or whether we should do something. = [/MB2] The SIMPLE-XMPP stuff are already in documents and there are = contributions. I'm sure Peter has control of the process for that. The SIMPLE-SIMPLE discussion is way too early to take anywhere in the = IETF process. Let us use the SIMPLE mailing list for brainstorming and = we'll see if we can agree on issues and possible solutions that can be = discussed and possibly taken down in document form. At that point, it = wlll hopefully be worth the energy and your backup to get a process = started, in this wg or somewhere else. IF there's time over for an unofficial discussion in Atlanta, it would = be very interesting to hear the feedback from the dispatch wg. I don't = think I can attend, so I guess I'll be participating over XMPP = ironically. THanks for your interest in this issue! /O --Apple-Mail=_336A0202-12F8-4D04-B8A9-0E19052DBE47 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1



On Tue, Oct 16, 2012 at 2:01 PM, Ben Campbell <ben@nostrum.com> wrote:


On Oct 16, 2012, at 1:32 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

> Your suggestion to discuss in DISPATCH and decide if and where we want to do that work makes sense, and is what DISPATCH is for. Presumably we can do that in Atlanta.

I believe we're past the deadline for "official" DISPATCH agenda time for Atlanta. Mary, since you've already commented, do you have thoughts on that?
[MB] Yes - we are past the "official" DISPATCH dates.  Although, we have a light agenda since only one topic was requested before the deadline.  We may have some extra time and pending approval from the ADs, we could have an unofficial discussion after the "official" agenda to kick this off and pursue it formally in DISPATCH in March (with the discussion focusing on a proposed charter).  I'll ping the ADs and see what they think. [/MB] 

I also assume any such discussion would be dependent on someone stepping up to lead it, right? It seems like there are really at least two things under discussion on the list: SIMPLE/XMPP inter working, and whether work is needed on SIMPLE itself in order to facilitate interoperable implementations.
[MB2] Yes, we would need people willing to lead the work as well as folks that are willing to contribute to and review documents.  Yes, there are two separate things.  My comments were on the former.  I think the latter is a different beast and needs more consideration before thinking that we have something to do or whether we should do something. [/MB2]

The SIMPLE-XMPP stuff are already in documents and there are contributions. I'm sure Peter has control of the process for that.

The SIMPLE-SIMPLE discussion is way too early to take anywhere in the IETF process. Let us use the SIMPLE mailing list for brainstorming and we'll see if we can agree on issues and possible solutions that can be discussed and possibly taken down in document form. At that point, it wlll hopefully be worth the energy and your backup to get a process started, in this wg or somewhere else.

IF there's time over for an unofficial discussion in Atlanta, it would be very interesting to hear the feedback from the dispatch wg. I don't think I can attend, so I guess I'll be participating over XMPP ironically.

THanks for your interest in this issue!

/O



--Apple-Mail=_336A0202-12F8-4D04-B8A9-0E19052DBE47-- From saul@ag-projects.com Fri Oct 19 01:03:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C452B21F843D for ; Fri, 19 Oct 2012 01:03:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83Rg7utGFE8L for ; Fri, 19 Oct 2012 01:03:36 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 43DFB21F843E for ; Fri, 19 Oct 2012 01:03:36 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DA69DB0181; Fri, 19 Oct 2012 10:03:34 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 42C2FB008B; Fri, 19 Oct 2012 10:03:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Fri, 19 Oct 2012 10:03:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> To: Avshalom Houri X-Mailer: Apple Mail (2.1085) Cc: Mary Barnes , Simple WG , Paul Kyzivat Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:03:36 -0000 >=20 >=20 > A different effort may be considered which is what will make=20 > XMPP acceptable as an extension to SIP based systems.=20 >=20 > This means not modifying SIMPLE but using XMPP as the=20 > presence/IM protocol for SIP.=20 >=20 What is wrong with IM? MSRP based IM works fine, I thought we were = focusing on presence here. > Usage of SIP AOR was mentioned before as an example.=20 >=20 Now we also have new tools, like GRUU, which maps one-to-one with a Full = JID, so exploring what XMPP did right sounds like a good idea. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Fri Oct 19 01:32:54 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B6921F85D5 for ; Fri, 19 Oct 2012 01:32: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=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyBtRk6LGgxS for ; Fri, 19 Oct 2012 01:32:53 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7C21F8596 for ; Fri, 19 Oct 2012 01:32:53 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 34E34B014F; Fri, 19 Oct 2012 10:32:51 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 0F297B0079; Fri, 19 Oct 2012 10:32:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Fri, 19 Oct 2012 10:32:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3D45341F-FD02-404A-ACBE-9984F8CB0DE1@ag-projects.com> References: <507D78C6.1040103@stpeter.im> <507D8F08.4000601@alum.mit.edu> <507DA115.3000308@alum.mit.edu> <76B14ADC-3666-44CF-837E-4EE1CBF18FFD@nostrum.com> <3422D8B2-7469-4AB0-B7F8-E32ABFF49B1F@nostrum.com> <6D4583BE-919C-455E-B8FE-221F19C2BE61@nostrum.com> <20DF42F3-7690-4228-9514-DED66523E6FF@nostrum.com> To: Olle E. Johansson X-Mailer: Apple Mail (2.1085) Cc: Simple WG Subject: Re: [Simple] Should SIMPLE be rechartered, replaced, closed, or what? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:32:54 -0000 On Oct 18, 2012, at 8:23 PM, Olle E. Johansson wrote: > As I haven't even tried to implement a full SIMPLE client I can't = argue with developers, just learn from what you write. The more the = better.=20 >=20 > I don't think we should throw away everything going down to the core = SIP protocol and trying to replace SUBSCRIBE/NOTIFY and PUBLISH. There = are ways to filter notifications and significant work.=20 >=20 I also lean towards not replacing those, but I may not be seeing the = trees because of the forest (I'm right now working on fixing a RLS = implementation). > So far, I've seen a few issues brought up: >=20 > * PIDF status *may* bee too complex, especially in combination with = XCAP and the operations of XCAP (non-atomic, external references with = full urls etc) Those are 2 different issues: 1- Ambiguous data in a PIDF: both per-person and per-device presence can = be expressed, which ends un in a weird mixture where only heuristics can = be used to try to draw a conclusion. 2- Use of different documents: this is what kills atomicity. > * Buddy lists are too complex and unmanageable They don't currently exist in SIMPLE. OMA added the oma_buddylist on top = of resource-lists, but IMHO the foundation is not right, we need = something new. > * The IETF documents leave gaps in Buddy List management >=20 > Apart from that, there are many mails about the total complexity with = 18 subscriptions, multiple XCAP formats intermingled with multiple = sources of application usages from both organizations and developers. = Seems like most of us that have mailed so far agree that this is too = complex. >=20 > To take a naive approach to this, can we >=20 > * Dramatically reduce the number of subscriptions by implementing > - one for synchronization of informaiton between one user's clients - = presence-ua-config > - one for presence updates from my buddy list - presence-updates >=20 > * Reduce the number of documents, possibly > - one simple-buddy-list=20 > - one auth-rules document >=20 Hum, yes and no :-) The actual buddylist could contain the policy for = each buddy. There would be the need for a different entity, which is not = a buddy, but holds policy information, for example when you would block = someone but don't want to see him in your buddylist. > * FInd a way to separate device states from user states and rules on = how to aggregate this > - "This phone is busy" vs "OEJ's calendar says he is on a = wine-tasting in France, so he's obviously busy" >=20 Yes, we need this. > The icon could be part of my own entry in my own buddy list, visible = for all buddies >=20 This doesn't scale very well. I'd rather use a different means of = storage for the icon and then have a mechanism to fetch it. Mobile = devices may not want to download all icons at all times, for example. = Also, documents can get really big if you start embedding icons, been = there :-) > The notifications from presence-ua-config would include changes in = buddy lists, auth requests and much more. An aggregation - and = simplification - of a lot of the stuff that the years of work done in = SIMPLE, XMPP and OMA. If you shut your eyes for the pile of XML schemas = and XCAP auids, there is a lot of ideas and good functionality for = applications hidden in there. I see no point in throwing it away, just = trying to create something simple that is a concentrated, stream-lined = and focused application. And we should not forget that it has to be = extensible in some way too, so we don't end up with a new subscription, = new XML schema, new URN and new AUID for every extension. Then we're = going to end up quickly in the very same situation we are in now. +1. This ua-config could be a base package and extensions could be = implemented as sub packages (like presence and presence.winfo). They = would surely need to provide a schema for the extension format, but = that's ok. I need to think about new AUIDs more, but we should at least = provide a working model based on 1 or 2 AUIDs. >=20 > Let's try to focus on attacking the solution from this end and see if = we can agree. I think we're done complaining over the existing solution = for a while. Note that I'm not saying that we have to use XML or XCAP. = Let's just talk "documents" and "subscriptions" and see where we end up. +1. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From joao.xii@gmail.com Fri Oct 19 05:23:30 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AEB21F8620 for ; Fri, 19 Oct 2012 05:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8eWknetBE4t for ; Fri, 19 Oct 2012 05:23:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A21121F8489 for ; Fri, 19 Oct 2012 05:23:29 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so457419vbb.31 for ; Fri, 19 Oct 2012 05:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=IC9ig8XyDXcEHhuGxng8AZciCL19o44hsRR9A4V1X+U=; b=aAzTDckZGroMocYYRnQBgMKkJx30LTSPt3b8eUM09Xu5mBB9bNiFWSAOPF9J/p4b2w Eu9vg1+9/TSQv0eFJqc2Eni0H7F2+V9Gr2mKPvciwqO+SlyXAlGrzNFP7fQr0SFZ+llo p7+lTts0B+LycgOGfrYvlVCpnBAmBitQ6nqYkFy8ztjOCcwUdqrs0rJILRwxsymopP8g 3cHNfbXDii333jLmxRxkQMiP4KxiVz3M8bzT+HQu/EwzJ6Q+EdogU05GaAtE/W18n9uR Q5wE2y9aXAafvunBGRvV7Z0Fi7LU3CgCtxMTn4yzOq/8PT4BNUTzqKD9KaHQlBbG+s2c 5ZMg== MIME-Version: 1.0 Received: by 10.220.150.14 with SMTP id w14mr1335201vcv.13.1350649408808; Fri, 19 Oct 2012 05:23:28 -0700 (PDT) Sender: joao.xii@gmail.com Received: by 10.58.89.230 with HTTP; Fri, 19 Oct 2012 05:23:28 -0700 (PDT) Date: Fri, 19 Oct 2012 13:23:28 +0100 X-Google-Sender-Auth: A5B8Pjcr2a07rO7owN8aQXaOb_4 Message-ID: From: Joao Antunes To: simple@ietf.org Content-Type: multipart/alternative; boundary=f46d043c81cc3a67c804cc6892f9 Cc: Tom Uijldert Subject: [Simple] - MSRP peer library O.S. now available announcement X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: joao.antunes@tagus.ist.utl.pt List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:41:12 -0000 --f46d043c81cc3a67c804cc6892f9 Content-Type: text/plain; charset=ISO-8859-1 Greetings Java developer,**** ** ** After a flying start within the brilliant Google Summer of Code, having it simmer for a while and finally polishing it up with some actual use-cases, the MSRP project team is proud to announce version 1.0 of its' magnificent library!**** ** ** This is an open source library, implementing the Message Session Relay Protocol (MSRP: RFC 4975), for you to deploy in any application.**** ** ** Functionalities include**** - establishing MSRP sessions**** - sending and receiving instant messages (chat) using MSRP**** - sending and receiving files using MSRP**** - message/cpim wrapping to interface with other chat systems**** - nicknames (draft-ietf-simple-chat)**** - message composition indication (RFC 3994)**** ** ** More information can be obtained at http://msrp.java.net**** For a quick introduction, read the tutorial: http://msrp.java.net/tutorial.html**** The entire project is hosted here: http://java.net/projects/msrp**** ** ** Build versions can be found in the central Maven repository, just include the dependency in your projects' pom.xml buildfile and you're good to go.*** * ** ** So be our guest, use it, abuse it and send us your patches, comments, issues, wishlists and what have you.**** ** ** Happy coding!**** The MSRP team.**** ** ** Special thanks go to:**** - The Jitsi project for initiating this**** - Google summer of code for making it possible**** - Nlnet for early development sponsoring**** - ContactMakers for sponsoring the polishing. --f46d043c81cc3a67c804cc6892f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Greetings Java develope= r,

=A0

Af= ter a flying start within the brilliant Google Summer of Code, having it si= mmer for a while and finally polishing it up with some actual use-cases, th= e MSRP project team is proud to announce version 1.0 of its' magnificen= t library!

=A0

This is an open source library, implementing the Message Session Relay Prot= ocol (MSRP: RFC 4975), for you to deploy in any application.<= /p>

=A0

Fu= nctionalities include

- establishing MSRP sessions

- sending and receiving instant messages (chat) usin= g MSRP

- sending and receiving= files using MSRP

- message/cpim wrapping to interface with other chat systems<= /p>

- nicknames (draft-i= etf-simple-chat)

- message composition i= ndication (RFC 3994)

=A0

Mo= re information can be obtained at=A0http://msrp.java.net=

For a quick introductio= n, read the tutorial:=A0http://msrp.java.net/tutorial.= html

The entire project is h= osted here:=A0http://java.net/projects/msrp

=A0

Build versions can be found in the central Maven repository, just include t= he dependency in your projects' pom.xml buildfile and you're good t= o go.

=A0

So= be our guest, use it, abuse it and send us your patches, comments, issues,= wishlists and what have you.

=A0

Happy coding!

=A0=A0 The MSRP team.

=A0

Sp= ecial thanks go to:

- The Jitsi project for initiating this

- Google summer of code for making it pos= sible

- Nlnet for early devel= opment sponsoring

- ContactMakers for sponsoring the polishing.

--f46d043c81cc3a67c804cc6892f9-- From ag@ag-projects.com Fri Oct 19 07:28:47 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6749121F84EE for ; Fri, 19 Oct 2012 07:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOv5r7wNO2QC for ; Fri, 19 Oct 2012 07:28:46 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3A60621F84D8 for ; Fri, 19 Oct 2012 07:28:46 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AEBEAB00F7; Fri, 19 Oct 2012 16:28:44 +0200 (CEST) Received: from [192.168.1.114] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id AA2FAB0067; Fri, 19 Oct 2012 16:28:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6EA45E1B-BDEC-4078-A941-54786CD31FD5" From: Adrian Georgescu In-Reply-To: Date: Fri, 19 Oct 2012 16:28:43 +0200 Message-Id: <213FA7AC-69EF-488E-BEDD-DCA71E1109C4@ag-projects.com> References: To: joao.antunes@tagus.ist.utl.pt X-Mailer: Apple Mail (2.1283) Cc: Tom Uijldert , simple@ietf.org Subject: Re: [Simple] - MSRP peer library O.S. now available announcement X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:28:47 -0000 --Apple-Mail=_6EA45E1B-BDEC-4078-A941-54786CD31FD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Joao, This is great stuff.=20 Congratulations to the developer team! Regards, Adrian On Oct 19, 2012, at 2:23 PM, Joao Antunes wrote: > Greetings Java developer, >=20 > =20 >=20 > After a flying start within the brilliant Google Summer of Code, = having it simmer for a while and finally polishing it up with some = actual use-cases, the MSRP project team is proud to announce version 1.0 = of its' magnificent library! >=20 > =20 >=20 > This is an open source library, implementing the Message Session Relay = Protocol (MSRP: RFC 4975), for you to deploy in any application. >=20 > =20 >=20 > Functionalities include >=20 > - establishing MSRP sessions >=20 > - sending and receiving instant messages (chat) using MSRP >=20 > - sending and receiving files using MSRP >=20 > - message/cpim wrapping to interface with other chat systems >=20 > - nicknames (draft-ietf-simple-chat) >=20 > - message composition indication (RFC 3994) >=20 > =20 >=20 > More information can be obtained at http://msrp.java.net >=20 > For a quick introduction, read the tutorial: = http://msrp.java.net/tutorial.html >=20 > The entire project is hosted here: http://java.net/projects/msrp >=20 > =20 >=20 > Build versions can be found in the central Maven repository, just = include the dependency in your projects' pom.xml buildfile and you're = good to go. >=20 > =20 >=20 > So be our guest, use it, abuse it and send us your patches, comments, = issues, wishlists and what have you. >=20 > =20 >=20 > Happy coding! >=20 > The MSRP team. >=20 > =20 >=20 > Special thanks go to: >=20 > - The Jitsi project for initiating this >=20 > - Google summer of code for making it possible >=20 > - Nlnet for early development sponsoring >=20 > - ContactMakers for sponsoring the polishing. >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_6EA45E1B-BDEC-4078-A941-54786CD31FD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Joao,

This is great = stuff. 

Congratulations to the developer = team!

Regards,
Adrian

On = Oct 19, 2012, at 2:23 PM, Joao Antunes wrote:

Greetings Java = developer,

 

After a flying start = within the brilliant Google Summer of Code, having it simmer for a while = and finally polishing it up with some actual use-cases, the MSRP project = team is proud to announce version 1.0 of its' magnificent = library!

 

=

This is an open source library, implementing the Message Session Relay = Protocol (MSRP: RFC 4975), for you to deploy in any = application.

 

Functionalities = include

- establishing MSRP sessions

- sending and = receiving instant messages (chat) using MSRP

- sending and = receiving files using MSRP

- message/cpim wrapping to interface with other chat = systems

- nicknames = (draft-ietf-simple-chat)

- message composition = indication (RFC 3994)

 

More information can = be obtained at http://msrp.java.net

<= p = style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727= 272033691406px;background-color:rgb(255,255,255)">For a quick = introduction, read the tutorial: http://msrp.java.net/tutorial.html

The entire project is = hosted here: http://java.net/projects/msrp=

 

=

Build versions can be found in the central Maven repository, just = include the dependency in your projects' pom.xml buildfile and you're = good to go.

 

So be our guest, use = it, abuse it and send us your patches, comments, issues, wishlists and = what have you.

 

=

Happy coding!

   The MSRP = team.

 

Special thanks go = to:

- The Jitsi project for initiating this

- Google summer of = code for making it possible

- Nlnet for early = development sponsoring

- ContactMakers for sponsoring the polishing.

_______________________________________________
Simple mailing = list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple

= --Apple-Mail=_6EA45E1B-BDEC-4078-A941-54786CD31FD5-- From stpeter@stpeter.im Fri Oct 19 20:16:07 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D0B21F88AE for ; Fri, 19 Oct 2012 20:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkwWS6MCH84E for ; Fri, 19 Oct 2012 20:16:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D10A721F8858 for ; Fri, 19 Oct 2012 20:16:06 -0700 (PDT) Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2C5C940062 for ; Fri, 19 Oct 2012 21:18:52 -0600 (MDT) Message-ID: <5082177D.1080305@stpeter.im> Date: Fri, 19 Oct 2012 21:16:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "simple@ietf.org" References: <20121020031406.30668.55437.idtracker@ietfa.amsl.com> In-Reply-To: <20121020031406.30668.55437.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.5 X-Forwarded-Message-Id: <20121020031406.30668.55437.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: [precis] I-D Action: draft-ietf-precis-nickname-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 03:16:07 -0000 FYI. I now consider this ready for WGLC in the PRECIS WG. Thanks to several SIMPLE WG participants for their reviews and comments. Peter -------- Original Message -------- Subject: [precis] I-D Action: draft-ietf-precis-nickname-04.txt Date: Fri, 19 Oct 2012 20:14:06 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: precis@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation and Comparison of Nicknames Author(s) : Peter Saint-Andre Filename : draft-ietf-precis-nickname-04.txt Pages : 7 Date : 2012-10-19 Abstract: This document describes how to prepare and compare Unicode strings representing nicknames, primarily for use within textual chatrooms. This profile is intended to be used by messaging and text conferencing technologies such as the Extensible Messaging and Presence Protocol (XMPP), the Message Session Relay Protocol (MSRP), and Centralized Conferencing (XCON). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-nickname There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-nickname-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis From oej@edvina.net Wed Oct 24 09:47:29 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E57221F89A8 for ; Wed, 24 Oct 2012 09:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g13eTKttvWP1 for ; Wed, 24 Oct 2012 09:47:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8943021F8944 for ; Wed, 24 Oct 2012 09:47:27 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 22C8A754A8AA; Wed, 24 Oct 2012 16:47:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <50804D8A.4050206@stpeter.im> Date: Wed, 24 Oct 2012 18:47:22 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6E6E5617-557A-4076-A445-8FF74C43DBCA@edvina.net> References: <08978277-AD2E-44A2-A13D-24444159E9BF@ag-projects.com> <507F153B.70603@alum.mit.edu> <44E96C7D-CBF8-492D-8DA5-E25D72E2DA93@ag-projects.com> <507F1CFB.7060408@alum.mit.edu> <507F3145.9050803@alum.mit.edu> <7DF2BF3D-3B69-4570-9AE9-3E573967D75B@ag-projects.com> <508031CD.5000401@alum.mit.edu> <50804D8A.4050206@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Cc: Simple WG Subject: Re: [Simple] XMPP servedr based presence (new subject) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 16:47:29 -0000 18 okt 2012 kl. 20:42 skrev Peter Saint-Andre : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/18/12 12:01 PM, Olle E. Johansson wrote: >> >> 18 okt 2012 kl. 18:43 skrev Paul Kyzivat : >> >>> I will observe that some things are, or can be, UI issues or API >>> issues rather than protocol issues. For better or worse IETF >>> doesn't do UI and API. So it's important to draw the lines >>> carefully. Or establish a partnership with another SDO that does >>> those things, like W3C, as is going on with RTCWEB/WEBRTC. >> >> Absolutely. But the requirement to be able to integrate with a UI >> may affect the protocol solution. >> >> XMPP has this problem. The XMPP server is not aware of the >> presence, it just routes stanzas. Without caching stanzas or doing >> something else, it is just not possible to create an API into the >> server and get the presence of a particular JID. > > Olle, that statement has no basis in reality. Every XMPP server > implementation on the planet is aware of the presence state for each > Jabber ID under its control. Thanks for the feedback. THat feature was not very stable when I implemented large scale XMPP a few years ago. Can I change the state in the server as well nowadays? /O From oej@edvina.net Wed Oct 24 10:00:45 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3420E21F85DA for ; Wed, 24 Oct 2012 10:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnePRqUYFNs5 for ; Wed, 24 Oct 2012 10:00:44 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0B49921F8498 for ; Wed, 24 Oct 2012 10:00:43 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 58D3E754A8B7; Wed, 24 Oct 2012 17:00:42 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2012 19:00:41 +0200 Message-Id: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> To: Simple WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:00:45 -0000 Simple friends ;-) I am surprised to see very few advocates for the current set of RFCs. It = seems like everyone on this list agrees that SIMPLE failed to deliver interoperability in the current = form, that the specifications leave too much to implementations and that there are undefined areas that = needs to be defined in an IETF document (which may currently be specified elsewhere). I see that the discussions diverge on a short-term and a long term plan. The short-term plan is to focus on the existing set of recommendations = in RFCs and try to find out which implementation guidelines and maybe extra set of documents that = are needed to get a=20 baseline interoperability in handling of a simple buddy list, presence = involving multiple devices and presence authorization. There seems to be an agreement that MSRP = based chat works. The long-term plan is to spend time on developing something that would = be much easier to implement, not require 18 (or more) subscriptions with states and be easier to = interoperate with XMPP. I personally would like to focus on the short term plan for now. I want = agreement on a=20 set of implementation guidelines so we can get the available softphones = (and hardphones that implement SIMPLE) to interoperate using standard open source = servers like OpenSIPS, OpenXCAP and Kamailio (and possibly others). If it's not possible, well, = then at least we tried to=20 fix it and we can divert attention on either XMPP or developing a = SIMPLE--. If there's time in the dispatch meeting for an open discussion, I hope I = can participate remotely. It would be great if we by combining our efforts can get both working = standards and interoperable running code, in true IETF spirit. Thanks to everyone for your involvement in this discussion. Let's keep = it alive and make progress together. /O ...and don't forget to book SIPit 30 in your calendars. = http://www.sipit.net There's a lot to test - TLS, DTLS/SRTP, MSRP, ICE, GRUU, SIMPLE, = Outbound, Identity=20 as well as the core SIP tests. SIPit is where we test if we have running = code :-) From saul@ag-projects.com Tue Oct 30 02:40:20 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E1A21F8495 for ; Tue, 30 Oct 2012 02:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.411 X-Spam-Level: * X-Spam-Status: No, score=1.411 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIvfrPZgZFFd for ; Tue, 30 Oct 2012 02:40:20 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id C62AE21F848D for ; Tue, 30 Oct 2012 02:40:19 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 3C9D8B35DD; Tue, 30 Oct 2012 10:40:17 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 6336FB007E; Tue, 30 Oct 2012 10:40:17 +0100 (CET) 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: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> Date: Tue, 30 Oct 2012 10:40:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> To: Olle E. Johansson X-Mailer: Apple Mail (2.1085) Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 09:40:20 -0000 Hi Olle, First, thanks for making some noise :-) On Oct 24, 2012, at 7:00 PM, Olle E. Johansson wrote: > Simple friends ;-) >=20 > I am surprised to see very few advocates for the current set of RFCs. = It seems like everyone on this list > agrees that SIMPLE failed to deliver interoperability in the current = form, that the specifications leave > too much to implementations and that there are undefined areas that = needs to be defined in an > IETF document (which may currently be specified elsewhere). >=20 > I see that the discussions diverge on a short-term and a long term = plan. >=20 > The short-term plan is to focus on the existing set of recommendations = in RFCs and try to find out > which implementation guidelines and maybe extra set of documents that = are needed to get a=20 > baseline interoperability in handling of a simple buddy list, presence = involving multiple devices > and presence authorization. There seems to be an agreement that MSRP = based chat works. >=20 > The long-term plan is to spend time on developing something that would = be much easier to implement, > not require 18 (or more) subscriptions with states and be easier to = interoperate with XMPP. >=20 > I personally would like to focus on the short term plan for now. I = want agreement on a=20 > set of implementation guidelines so we can get the available = softphones (and hardphones > that implement SIMPLE) to interoperate using standard open source = servers like OpenSIPS, > OpenXCAP and Kamailio (and possibly others). If it's not possible, = well, then at least we tried to=20 > fix it and we can divert attention on either XMPP or developing a = SIMPLE--. >=20 I agree. We (kind of) took this approach and managed to build something = that works, so it's doable. It would be great if we could put together = some recommendations / specifications for these items you highlighted: a = buddy list, multi-device presence and authorization. > If there's time in the dispatch meeting for an open discussion, I hope = I can participate remotely. >=20 Count me in! > It would be great if we by combining our efforts can get both working = standards and interoperable running code, > in true IETF spirit. >=20 > Thanks to everyone for your involvement in this discussion. Let's keep = it alive and make progress together. >=20 Cheers, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Tue Oct 30 04:06:45 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADEA21F8511 for ; Tue, 30 Oct 2012 04:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5KMYbPaBoUK for ; Tue, 30 Oct 2012 04:06:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4332421F850D for ; Tue, 30 Oct 2012 04:06:40 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so137091lbo.31 for ; Tue, 30 Oct 2012 04:06:39 -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=CgdJxL5eJ7kiS4Fq2RJpAq+KwVZGvYBBwDCSLlEaWUo=; b=MWlJ4yMO4NgaOF5yuanE0zCtalZUvaro0xZyXSs5ZhLjvLtllWazXJ6pxw0S1b8vlq Y3/Mdq+ujwp/IhdZ+uZD7yplu9m8pZ9LgkSrHBAWIdlM/sjJy4T0PJvyoQw+ISlhX/p1 Gy069Qy7SkxnkxPVOlriM92QnWmS3H6kFj33rjCJvIfvEomly2ZETxPG00iMsK2Opp9Z +0rJub+oXHxh/TbRd1G4k4UN2WLAQPjXqaqKuhWR4RirZxFlnJ5E91v7msumqnmHZEdJ 9kurBOsTYY56lzhnmCYqJ5pgdoqGv78VUOLbRrwDik78UEiwRAxNs0KvigFSas3JORIl bDhQ== Received: by 10.112.49.201 with SMTP id w9mr12985498lbn.100.1351595198973; Tue, 30 Oct 2012 04:06:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Tue, 30 Oct 2012 04:06:18 -0700 (PDT) In-Reply-To: References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Oct 2012 12:06:18 +0100 Message-ID: To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmoNk0zFqb2YkpdWc8x7VFJQitTkQAH/x/8yJBsbCuxOQfLNnR1Va7+80RYlGMNS5qjf9Eg Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:06:45 -0000 2012/10/30 Sa=C3=BAl Ibarra Corretg=C3=A9 : >> The short-term plan is to focus on the existing set of recommendations i= n RFCs and try to find out >> which implementation guidelines and maybe extra set of documents that ar= e needed to get a >> baseline interoperability in handling of a simple buddy list, presence i= nvolving multiple devices >> and presence authorization. There seems to be an agreement that MSRP bas= ed chat works. >> >> The long-term plan is to spend time on developing something that would b= e much easier to implement, >> not require 18 (or more) subscriptions with states and be easier to inte= roperate with XMPP. >> >> I personally would like to focus on the short term plan for now. I want = agreement on a >> set of implementation guidelines so we can get the available softphones = (and hardphones >> that implement SIMPLE) to interoperate using standard open source server= s like OpenSIPS, >> OpenXCAP and Kamailio (and possibly others). If it's not possible, well,= then at least we tried to >> fix it and we can divert attention on either XMPP or developing a SIMPLE= --. >> > > I agree. We (kind of) took this approach and managed to build something t= hat works, so it's doable. It would be great if we could put together some = recommendations / specifications for these items you highlighted: a buddy l= ist, multi-device presence and authorization. The "short-term" plan looks no so "short" for me (taking into account that AG, really experts in this area has required years of work to make all the SIMPLE/XCAP stuff to work). If the short-term plan requires that a developer team starting with SIMPLE must work over 2-3 years to implement all the specs, I would not name it "short-term" at all. In the other side, implementing XMPP is 100 times easier, more feasible and more robust than implementing current SIMPLE/XCAP specs plus the suggested "extra layer" for properly defining what exactly to implement and how to build basic features such as a working addressbook. And remember: XCAP is not XPath 1.0 compliant (since XCAP introduces the concept of "default document namespace" to save ~20 bytes in a HTTP request) which means that developers cannot use the well known libxml library. Who will ask them for coding their own libxml-xcap library? (not me). And one more thing: As I noted in previous mails, SIMPLE model fits very bad in the modern Internet environments (smartphones). SIMPLE requires mantaining dozens of SIP dialogs (subscriptions) and mantaining a dialog in a smartphone is a bad idea (it looses the connection, restarts it with a different IP, etc etc) and it's a battery overkill. So, honestly, if I new effort is desired I strongly doubt that the way to go is rescuing SIMPLE specs. The effort will be giant for newcomers and the result will be poor for environments different than private or fixed networks. Just my opinion. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Tue Oct 30 04:19:18 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E5321F853B for ; Tue, 30 Oct 2012 04:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-A5Fvse5b5b for ; Tue, 30 Oct 2012 04:19:17 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id EDD7D21F8536 for ; Tue, 30 Oct 2012 04:19:16 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 48BFDB35DA; Tue, 30 Oct 2012 12:19:14 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 24210B007E; Tue, 30 Oct 2012 12:19:14 +0100 (CET) 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: Tue, 30 Oct 2012 12:19:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1085) Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:19:18 -0000 On Oct 30, 2012, at 12:06 PM, I=F1aki Baz Castillo wrote: > 2012/10/30 Sa=FAl Ibarra Corretg=E9 : >>> The short-term plan is to focus on the existing set of = recommendations in RFCs and try to find out >>> which implementation guidelines and maybe extra set of documents = that are needed to get a >>> baseline interoperability in handling of a simple buddy list, = presence involving multiple devices >>> and presence authorization. There seems to be an agreement that MSRP = based chat works. >>>=20 >>> The long-term plan is to spend time on developing something that = would be much easier to implement, >>> not require 18 (or more) subscriptions with states and be easier to = interoperate with XMPP. >>>=20 >>> I personally would like to focus on the short term plan for now. I = want agreement on a >>> set of implementation guidelines so we can get the available = softphones (and hardphones >>> that implement SIMPLE) to interoperate using standard open source = servers like OpenSIPS, >>> OpenXCAP and Kamailio (and possibly others). If it's not possible, = well, then at least we tried to >>> fix it and we can divert attention on either XMPP or developing a = SIMPLE--. >>>=20 >>=20 >> I agree. We (kind of) took this approach and managed to build = something that works, so it's doable. It would be great if we could put = together some recommendations / specifications for these items you = highlighted: a buddy list, multi-device presence and authorization. >=20 >=20 > The "short-term" plan looks no so "short" for me (taking into account > that AG, really experts in this area has required years of work to > make all the SIMPLE/XCAP stuff to work). If the short-term plan > requires that a developer team starting with SIMPLE must work over 2-3 > years to implement all the specs, I would not name it "short-term" at > all. Well, in order to fix a problem you need to understand it first :-) = Seems like we (those posting in this thread) now do. Server side = capability was implemented years ago and somehow nobody had issues with = it, now that we could finally see how the client side feels like we = discovered that are actually worse that it seemed. >=20 > In the other side, implementing XMPP is 100 times easier, more > feasible and more robust than implementing current SIMPLE/XCAP specs > plus the suggested "extra layer" for properly defining what exactly to > implement and how to build basic features such as a working > addressbook. >=20 XMPP is not 100 times easier. Have a look at how basic presence is done = and how PEP relates to it. > And remember: XCAP is not XPath 1.0 compliant (since XCAP introduces > the concept of "default document namespace" to save ~20 bytes in a > HTTP request) which means that developers cannot use the well known > libxml library. Who will ask them for coding their own libxml-xcap > library? (not me). >=20 And who said that it can't be relaxed? RFCs update other RFCs all the = time. > And one more thing: As I noted in previous mails, SIMPLE model fits > very bad in the modern Internet environments (smartphones). SIMPLE > requires mantaining dozens of SIP dialogs (subscriptions) and > mantaining a dialog in a smartphone is a bad idea (it looses the > connection, restarts it with a different IP, etc etc) and it's a > battery overkill. >=20 Keeping a TCP socket is not costly at all. Mobile operating systems are = built to do it efficiently. If the connection breaks the client should = restart it. Same goes for the IP change. Yes, I know TCP is not = particularly nice for mobiles, that's probably why Google uses = pseudo-TCP and Facebook uses MQTT, but I think that's not the point = here. > So, honestly, if I new effort is desired I strongly doubt that the way > to go is rescuing SIMPLE specs. The effort will be giant for newcomers > and the result will be poor for environments different than private or > fixed networks. >=20 And doing something completely new would mean a installed base of 0 = devices. What if (years) later we also realize it was not such a good = idea? -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Tue Oct 30 04:50:07 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB85821F8552 for ; Tue, 30 Oct 2012 04:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRVKhRvKOxWg for ; Tue, 30 Oct 2012 04:50:06 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7389121F8542 for ; Tue, 30 Oct 2012 04:50:06 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so150622lam.31 for ; Tue, 30 Oct 2012 04:50:05 -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=w3zDhhBGYGNtt6zMXkVzJ1K5osLYaTn9ia91y/e4rNU=; b=JhEQUSUVqIyQVrJnv9Opf2b9OhTQHwTDVhNGD1XhG6NYfC0zk8mWTq1DG53zzamyd3 FxUU7YLvGv6nVRjKEM1fB0HKybvSTPI5QeMfPC+OFQwdp/fzDn3dHZZAsn72h5Q8+Xba dQ68LSXYaRCh53EXzv6Dx+Bnw969gsORXM0p4//iEFyUTGJldyV4w8rXr0f1XKqhrvtB J06twNSoPJvUenXkS0HyvWfmu7Kv0wQYopt2qQG0AorVX/LPkzwdPL3H45rlwFGBz94z KeztqRZhDGhPcJLZXeXsepOdt1c6fkl9UnoHfJW+g/8gHK03U3OXI+0ENfGTpTHvr3FY AtZw== Received: by 10.112.29.129 with SMTP id k1mr13303650lbh.102.1351597805377; Tue, 30 Oct 2012 04:50:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Tue, 30 Oct 2012 04:49:45 -0700 (PDT) In-Reply-To: References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Oct 2012 12:49:45 +0100 Message-ID: To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkFL2+UIX3gJALcOJq5eRBJwe1aWuDY28TYdvzJ1h1WuDJD1zzR+CtJy9T3MvhNdjqKutuE Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:50:07 -0000 2012/10/30 Sa=C3=BAl Ibarra Corretg=C3=A9 : >> The "short-term" plan looks no so "short" for me (taking into account >> that AG, really experts in this area has required years of work to >> make all the SIMPLE/XCAP stuff to work). If the short-term plan >> requires that a developer team starting with SIMPLE must work over 2-3 >> years to implement all the specs, I would not name it "short-term" at >> all. > > Well, in order to fix a problem you need to understand it first :-) The issue is when somebody understands the *problem* after years understanding/implementing the *specs*, and AFAIK this is something you and me know about, right? ;) > Seems like we (those posting in this thread) now do. I also understood the "problem" after more than 6 months reading SIMPLE and OMA specs and coding thousands lines of code. A spec should be implementable by an expertised developer in a few months, and with full knowledge and guarantee about the final result. Problems CAN NOT appear after building all the stuff by following all the specs. >> In the other side, implementing XMPP is 100 times easier, more >> feasible and more robust than implementing current SIMPLE/XCAP specs >> plus the suggested "extra layer" for properly defining what exactly to >> implement and how to build basic features such as a working >> addressbook. >> > > XMPP is not 100 times easier. Have a look at how basic presence is done a= nd how PEP relates to it. Basic presence, presence authorization and sharing a buddylist is just easy in XMPP. That's not in SIMPLE, is it? (I know that advanced presence features in XMPP based on subscriptions are hard and not well implemented). >> And remember: XCAP is not XPath 1.0 compliant (since XCAP introduces >> the concept of "default document namespace" to save ~20 bytes in a >> HTTP request) which means that developers cannot use the well known >> libxml library. Who will ask them for coding their own libxml-xcap >> library? (not me). >> > > And who said that it can't be relaxed? RFCs update other RFCs all the tim= e. Take a look to http://tools.ietf.org/html/draft-ietf-simple-simple-07. It contains ~27 references to RFC's about SIMPLE/XCAP (just for presence, I discard those related to MSRP and conferences). Now tell newcomers that they must implement those 27 RFC's plus some new RFC's that update them. >> So, honestly, if I new effort is desired I strongly doubt that the way >> to go is rescuing SIMPLE specs. The effort will be giant for newcomers >> and the result will be poor for environments different than private or >> fixed networks. >> > > And doing something completely new would mean a installed base of 0 devic= es. Could you please point me to TWO generic SIP/SIMPLE devices that can interoperate WELL when managing presence authorizations rules and buddylists? (two Blink instances is not a valid response). Please, I mean two devices out of walled gardens. > What if (years) later we also realize it was not such a good idea? I do think right now that rescuing SIMPLE (presence) for open environments is not a good idea. I don't expect I need years for that. Regards. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Tue Oct 30 04:54:39 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F82821F855F for ; Tue, 30 Oct 2012 04:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.06 X-Spam-Level: X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBvgmNZcEkOl for ; Tue, 30 Oct 2012 04:54:38 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B5BDF21F855E for ; Tue, 30 Oct 2012 04:54:37 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id EE5B9754A8AA; Tue, 30 Oct 2012 11:54:34 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 30 Oct 2012 12:54:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <41B9620C-3731-4E11-B0C6-FC77C1A17E86@edvina.net> References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1499) Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:54:39 -0000 30 okt 2012 kl. 12:06 skrev I=F1aki Baz Castillo : > 2012/10/30 Sa=FAl Ibarra Corretg=E9 : >>> The short-term plan is to focus on the existing set of = recommendations in RFCs and try to find out >>> which implementation guidelines and maybe extra set of documents = that are needed to get a >>> baseline interoperability in handling of a simple buddy list, = presence involving multiple devices >>> and presence authorization. There seems to be an agreement that MSRP = based chat works. >>>=20 >>> The long-term plan is to spend time on developing something that = would be much easier to implement, >>> not require 18 (or more) subscriptions with states and be easier to = interoperate with XMPP. >>>=20 >>> I personally would like to focus on the short term plan for now. I = want agreement on a >>> set of implementation guidelines so we can get the available = softphones (and hardphones >>> that implement SIMPLE) to interoperate using standard open source = servers like OpenSIPS, >>> OpenXCAP and Kamailio (and possibly others). If it's not possible, = well, then at least we tried to >>> fix it and we can divert attention on either XMPP or developing a = SIMPLE--. >>>=20 >>=20 >> I agree. We (kind of) took this approach and managed to build = something that works, so it's doable. It would be great if we could put = together some recommendations / specifications for these items you = highlighted: a buddy list, multi-device presence and authorization. >=20 >=20 > The "short-term" plan looks no so "short" for me (taking into account > that AG, really experts in this area has required years of work to > make all the SIMPLE/XCAP stuff to work). If the short-term plan > requires that a developer team starting with SIMPLE must work over 2-3 > years to implement all the specs, I would not name it "short-term" at > all. There must be a lot of people with experiences of developing and using = the SIMPLE framework on this list. Any opinions? We need you !! /O= From saul@ag-projects.com Tue Oct 30 05:01:45 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1614F21F8582 for ; Tue, 30 Oct 2012 05:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=1.085, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4yHrBI9zvDs for ; Tue, 30 Oct 2012 05:01:44 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB3B21F8518 for ; Tue, 30 Oct 2012 05:01:43 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id CB335B35DD; Tue, 30 Oct 2012 13:01:42 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D2340B007E; Tue, 30 Oct 2012 13:01:39 +0100 (CET) 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: Tue, 30 Oct 2012 13:01:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1085) Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:01:45 -0000 On Oct 30, 2012, at 12:49 PM, I=F1aki Baz Castillo wrote: > 2012/10/30 Sa=FAl Ibarra Corretg=E9 : >>> The "short-term" plan looks no so "short" for me (taking into = account >>> that AG, really experts in this area has required years of work to >>> make all the SIMPLE/XCAP stuff to work). If the short-term plan >>> requires that a developer team starting with SIMPLE must work over = 2-3 >>> years to implement all the specs, I would not name it "short-term" = at >>> all. >>=20 >> Well, in order to fix a problem you need to understand it first :-) >=20 > The issue is when somebody understands the *problem* after years > understanding/implementing the *specs*, and AFAIK this is something > you and me know about, right? ;) >=20 >=20 >> Seems like we (those posting in this thread) now do. >=20 > I also understood the "problem" after more than 6 months reading > SIMPLE and OMA specs and coding thousands lines of code. A spec should > be implementable by an expertised developer in a few months, and with > full knowledge and guarantee about the final result. Problems CAN NOT > appear after building all the stuff by following all the specs. >=20 That's a lot easier to say than to do. Unless we have a Delorean and = have a quick look at the future ;-) >=20 >=20 >>> In the other side, implementing XMPP is 100 times easier, more >>> feasible and more robust than implementing current SIMPLE/XCAP specs >>> plus the suggested "extra layer" for properly defining what exactly = to >>> implement and how to build basic features such as a working >>> addressbook. >>>=20 >>=20 >> XMPP is not 100 times easier. Have a look at how basic presence is = done and how PEP relates to it. >=20 > Basic presence, presence authorization and sharing a buddylist is just > easy in XMPP. That's not in SIMPLE, is it? > (I know that advanced presence features in XMPP based on subscriptions > are hard and not well implemented). >=20 So, as you also said XMPP isn't perfect either. We can learn from it, of = course. >=20 >=20 >>> And remember: XCAP is not XPath 1.0 compliant (since XCAP introduces >>> the concept of "default document namespace" to save ~20 bytes in a >>> HTTP request) which means that developers cannot use the well known >>> libxml library. Who will ask them for coding their own libxml-xcap >>> library? (not me). >>>=20 >>=20 >> And who said that it can't be relaxed? RFCs update other RFCs all the = time. >=20 > Take a look to http://tools.ietf.org/html/draft-ietf-simple-simple-07. > It contains ~27 references to RFC's about SIMPLE/XCAP (just for > presence, I discard those related to MSRP and conferences). >=20 > Now tell newcomers that they must implement those 27 RFC's plus some > new RFC's that update them. And your point is? A SIP client implements almost half of the Internet, = if you count HTTP, DNS and so on. 100 RFCs are fine if they are clear = RFCs. >=20 >=20 >=20 >>> So, honestly, if I new effort is desired I strongly doubt that the = way >>> to go is rescuing SIMPLE specs. The effort will be giant for = newcomers >>> and the result will be poor for environments different than private = or >>> fixed networks. >>>=20 >>=20 >> And doing something completely new would mean a installed base of 0 = devices. >=20 > Could you please point me to TWO generic SIP/SIMPLE devices that can > interoperate WELL when managing presence authorizations rules and > buddylists? (two Blink instances is not a valid response). Please, I > mean two devices out of walled gardens. >=20 Due to the broad specs this doesn't seem possible these days, not at = least for *every* possible twisted document. That, however, doesn't mean = there aren't working solutions with models similar to ours. IIRC = CounterPath uses (or used) a md5 hash as the entry ID in resource lists = and then put more stuff in a extension. >=20 >> What if (years) later we also realize it was not such a good idea? >=20 > I do think right now that rescuing SIMPLE (presence) for open > environments is not a good idea. I don't expect I need years for that. >=20 I didn't say rescue, I talked about using its foundation to evolve a = working "2.0" (if you will) thing. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Tue Oct 30 05:37:18 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801A221F8582 for ; Tue, 30 Oct 2012 05:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Clc3KX6CACjL for ; Tue, 30 Oct 2012 05:37:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9D21F8554 for ; Tue, 30 Oct 2012 05:37:11 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so207242lbo.31 for ; Tue, 30 Oct 2012 05:37:11 -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=IBc0rqJ19EflJkCWgPRpmmJ1zMpnB/TfDkjKG4t1kEY=; b=obt048FPjKCIpm2p2s454CN2lQ7Krbb2dtooe9Y8a+21xPCraXyFPxRp2CpVs8tYsA kNVyKQFg/I5kisowo1NECv/9AxeKnw3VjmM/sOjC1IU00b5qJ7EgFjC4+aY9eZm+vQnL dcDBIDoCd3Pg6wQJLR1TID3YgfvKCwS9iU9A5zTJiRAcnRBwNx5kEfTOEA3PWOa4csz8 CUwge6vpv2VmC/MpzIywfa7JEuBncm/+cgR63xGkZrqCHPlYeikExCQ9872X1Xi0oELC 7+dDMUadE+gcyKYVZ3Ft2b5+x4Yjwe8R3pLveLRVktAJedUN2X7QlqidSNzsQ3CtATMK X81g== Received: by 10.152.146.67 with SMTP id ta3mr30078909lab.23.1351600631011; Tue, 30 Oct 2012 05:37:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Tue, 30 Oct 2012 05:36:50 -0700 (PDT) In-Reply-To: References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Oct 2012 13:36:50 +0100 Message-ID: To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlSheIhI/XNYm0sV3kwVIDXXG6ocNYQyalrJTmdDUZWhaQ6bpf06vXV/XnoVse6Jwc8tRrA Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:37:18 -0000 2012/10/30 Sa=C3=BAl Ibarra Corretg=C3=A9 : >> Basic presence, presence authorization and sharing a buddylist is just >> easy in XMPP. That's not in SIMPLE, is it? >> (I know that advanced presence features in XMPP based on subscriptions >> are hard and not well implemented). > > So, as you also said XMPP isn't perfect either. We can learn from it, of = course. Yes, we can learn from XMPP (as opposite to copy/merge/include it within SIP as many others propose...). The questios is: can we learn from SIMPLE-presence? Well, IMHO we can learn that it is not a really suitable/complete solution. Right? We can "complete" it but, can we make it suitable? >> Take a look to http://tools.ietf.org/html/draft-ietf-simple-simple-07. >> It contains ~27 references to RFC's about SIMPLE/XCAP (just for >> presence, I discard those related to MSRP and conferences). >> >> Now tell newcomers that they must implement those 27 RFC's plus some >> new RFC's that update them. > > And your point is? A SIP client implements almost half of the Internet, i= f you count HTTP, DNS and so on. 100 RFCs are fine if they are clear RFCs. Do you want to implement a *working* solution that integrates buddylist management, presence authorization and basic presence status delivery?: - http://xmpp.org/rfcs/rfc6120.html - http://xmpp.org/rfcs/rfc6121.html And you are done, without patching libxml, without implementing XML-diff, and without arbitrary modifying remote XML documents in any custom way. >> Could you please point me to TWO generic SIP/SIMPLE devices that can >> interoperate WELL when managing presence authorizations rules and >> buddylists? (two Blink instances is not a valid response). Please, I >> mean two devices out of walled gardens. >> > > Due to the broad specs this doesn't seem possible these days, not at leas= t for *every* possible twisted document. That, however, doesn't mean there = aren't working solutions with models similar to ours. IIRC CounterPath uses= (or used) a md5 hash as the entry ID in resource lists and then put more s= tuff in a extension. So proprietary workarounds to make the stuff to work. >> I do think right now that rescuing SIMPLE (presence) for open >> environments is not a good idea. I don't expect I need years for that. > > I didn't say rescue, I talked about using its foundation to evolve a work= ing "2.0" (if you will) thing. And do you think there is REAL interest on it? who is interested? people that wrote SIMPLE does not seem to be interested. Real SIMPLE users (i.e. GSMA) seem already satisfied with existing specs which they are usd for building Joyn and RCS-e (I hope they use OMA/RCS specs full of XCAP and XDMS and so on...). Where is the REAL interest on using SIMPLE current specs for open Internet environments? If others are not interested I don't think they will be interested when they realize that they must implement 27 RFC's. Just my opinion. I could be wrong. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 30 06:30:08 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181A121F84B3 for ; Tue, 30 Oct 2012 06:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDuilzVsKNX9 for ; Tue, 30 Oct 2012 06:30:07 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49BE021F84A6 for ; Tue, 30 Oct 2012 06:30:07 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so250859lbo.31 for ; Tue, 30 Oct 2012 06:30:06 -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=jKz32OwjkdfRTpbnW1qoC+ZxFbu9sxoXaBqhiDFACNs=; b=aLk5hrCEJuq621MWYMy6fhWfb5JifRGtQR0qxJOWU0dJ9DWW+5PgNybKqxTiT4umjq mAeEnw44pDxbf5p8n4e9nSScIuCiyNIjkTM4ENtuUP+8J6MNotzKjKbh/yBkc6AHAuDj MsAfJ6cm5YAuHL8Bz/50ck+6wkGxbfaXkwC8fcVaZLdgRbSm8vr3FsncRvY66/nGvRTR inL1WvqpS5hCC78NVX22DPwzQ9x96LgcT3ovMc5ZuPkU2+z1+GnxTnGYTbOFSfwvAKrZ wDqF+pSL1QeV0kTU5PWFedylHd/9MBJbRFHa8ZKiLqrcYCF3waRPUA5VlOL591R7pS91 2ThA== Received: by 10.112.25.42 with SMTP id z10mr13088359lbf.103.1351603806218; Tue, 30 Oct 2012 06:30:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Tue, 30 Oct 2012 06:29:46 -0700 (PDT) In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF4864367B@ucolhp9h.easf.csd.disa.mil> References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> <8486C8728176924BAF5BDB2F7D7EEDDF4864367B@ucolhp9h.easf.csd.disa.mil> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Oct 2012 14:29:46 +0100 Message-ID: To: "Roy, Radhika R CIV (US)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkpFG/z8WVuGT3s3x15jA4aJT0qQQGMk1SF2tOrsQPEm6P+w1BdcLfBQlmDsOwKLfKBsbU6 Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:30:08 -0000 2012/10/30 Roy, Radhika R CIV (US) : > Folks: > > I do not whether when you talk about SIMPLE and XMPP, do you also talk ab= out > integration of SIMPLE (or XMPP) with audio and video? > > Or, are you saying the following only? > > 1. Only SIMPLE-SIMPLE Interworking. > > 2. Only SIMPLE-XMPP Interworking. > > Please clarify in the mailing list. The fact is that we are trying to talk about SIMPLE-SIMPLE and not about XMPP or SIMPLE-XMPP interoperability. Regards. --=20 I=C3=B1aki Baz Castillo From radhika.r.roy.civ@mail.mil Tue Oct 30 06:22:05 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFFF21F8542 for ; Tue, 30 Oct 2012 06:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8wEGaY28qDN for ; Tue, 30 Oct 2012 06:22:04 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8421F8525 for ; Tue, 30 Oct 2012 06:22:04 -0700 (PDT) Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 30 Oct 2012 13:21:54 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.31]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.02.0309.003; Tue, 30 Oct 2012 13:21:54 +0000 From: "Roy, Radhika R CIV (US)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , =?utf-8?B?U2HDumwgSWJhcnJhIENvcnJldGfDqQ==?= Thread-Topic: [Simple] Trying to summarize discussion on SIMPLE interop Thread-Index: AQHNtptjs7HGkTrX3EavHsDLJc/hU5fR1NIQ Date: Tue, 30 Oct 2012 13:21:54 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF4864367B@ucolhp9h.easf.csd.disa.mil> References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CDB67F.F9A14510" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 30 Oct 2012 07:27:45 -0700 Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:22:05 -0000 ------=_NextPart_000_0000_01CDB67F.F9A14510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Folks: I do not whether when you talk about SIMPLE and XMPP, do you also talk about integration of SIMPLE (or XMPP) with audio and video? Or, are you saying the following only? 1. Only SIMPLE-SIMPLE Interworking. 2. Only SIMPLE-XMPP Interworking. Please clarify in the mailing list. Best regards, Radhika ------=_NextPart_000_0000_01CDB67F.F9A14510 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjEwMzAxMzIxNDJaMCMGCSqGSIb3DQEJBDEWBBT4lefWu0UyIMc2o2ZJ+WEc JeUVdDBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAJ/Xo8q79bopAgLOgLMOlyGzwU0qnBHIiRJkXhBX2hEAIosp+bHwNSeGUeeyn8oPVDl+ 6FjcaQmsBQ2D1PeNsEaC2Hvy2zklxQlV/A7yGsRkg5rOqsgyCmEnbnDhkQdQSiGrEjzngVvyT2l5 2R7xujTC6pb3Iezi2IcPV5k+BVxpgPGPkcY4wBCeZhoHdFuik6XyzJZhh815BQxf2gpNXYRz1v5q NKQ02LqqDk4uWexg90Ffb0/IZn69e3Z+qSF9HGjxOvqRnQIT9V1sLsRPASzu1RtJ38BA8ynL/cvG F2355gx6LWEq/8DLhla+3lkQ1HQuKqkM1QK7pdDimYUFWjUAAAAAAAA= ------=_NextPart_000_0000_01CDB67F.F9A14510-- From radhika.r.roy.civ@mail.mil Tue Oct 30 06:37:15 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2EC21F84D8 for ; Tue, 30 Oct 2012 06:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-+A5fWli5OD for ; Tue, 30 Oct 2012 06:37:15 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 20B5D21F84D2 for ; Tue, 30 Oct 2012 06:37:15 -0700 (PDT) Received: from UCOLHP3E.easf.csd.disa.mil (131.64.100.144) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 30 Oct 2012 13:36:57 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.31]) by UCOLHP3E.easf.csd.disa.mil ([131.64.100.144]) with mapi id 14.02.0309.003; Tue, 30 Oct 2012 13:36:56 +0000 From: "Roy, Radhika R CIV (US)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [Simple] Trying to summarize discussion on SIMPLE interop Thread-Index: AQHNtptjs7HGkTrX3EavHsDLJc/hU5fR1NIQgAADOACAAACM4A== Date: Tue, 30 Oct 2012 13:36:56 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF486436A5@ucolhp9h.easf.csd.disa.mil> References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> <8486C8728176924BAF5BDB2F7D7EEDDF4864367B@ucolhp9h.easf.csd.disa.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0004_01CDB682.17F665C0" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 30 Oct 2012 07:27:50 -0700 Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:37:16 -0000 ------=_NextPart_000_0004_01CDB682.17F665C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I=C3=B1aki: Great! It helps a lot because we are using SIMPLE integrating with audio and = video, and SIP becomes the key signaling protocol for integration of = audio, video, and chat/IM/Presence. >From this view, it is urgent that we must need to solve all the problems = for SIMPLE-SIMPLE interworking as soon as we can. Of course, we must learn from XMPP-XMPP interworking as much as we can = and apply the same for SIMPLE-SIMPLE interworking as fast as we can. BR/Radhika -----Original Message----- From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]=20 Sent: Tuesday, October 30, 2012 9:30 AM To: Roy, Radhika R CIV (US) Cc: Sa=C3=BAl Ibarra Corretg=C3=A9; Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop 2012/10/30 Roy, Radhika R CIV (US) : > Folks: > > I do not whether when you talk about SIMPLE and XMPP, do you also talk = > about integration of SIMPLE (or XMPP) with audio and video? > > Or, are you saying the following only? > > 1. Only SIMPLE-SIMPLE Interworking. > > 2. Only SIMPLE-XMPP Interworking. > > Please clarify in the mailing list. The fact is that we are trying to talk about SIMPLE-SIMPLE and not about = XMPP or SIMPLE-XMPP interoperability. Regards. -- I=C3=B1aki Baz Castillo ------=_NextPart_000_0004_01CDB682.17F665C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjEwMzAxMzM2NTJaMCMGCSqGSIb3DQEJBDEWBBSG+oKvRxGqTPXUKtRMISHa FofItzBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAByQItk0JePgihgF4+nZJdNiCuKSbTHQkeuEZ2fyNnyyLLzPdj2zgORWMZlX5Uggix5W QXgeTTvnspBF1bmODXVDCyIhh+JLoDx6A1AZIWs0nuLs1DLMuEawR398CjzbmYdy1EY28jvD94Qp T1JUGRkUZWCS/O41Sf871LcKKUYzVcUh7wRt5FpvUYg5rWNCtjQFoQwnPQ6hBeUhm7l3jL8W5LfO g600Qg883o6ey0J14hBApSuxvvb98bSfrKvVX1KwwDOe2pUTAQEKgkviBhXBSG7eitSS+qyqWJJp jzY+MGGUu+A2SSHJqBf6QKz+RVy8gE2zSd1camAGKfhJxiEAAAAAAAA= ------=_NextPart_000_0004_01CDB682.17F665C0-- From ben@estacado.net Tue Oct 30 07:33:10 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758EB21F8444 for ; Tue, 30 Oct 2012 07:33:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKPgtbtBEJcC for ; Tue, 30 Oct 2012 07:33:10 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id E51DB21F8446 for ; Tue, 30 Oct 2012 07:33:09 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q9UEWwlo034186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2012 09:33:03 -0500 (CDT) (envelope-from ben@estacado.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Tue, 30 Oct 2012 09:32:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> <8486C8728176924BAF5BDB2F7D7EEDDF4864367B@ucolhp9h.easf.csd.disa.mil> To: "Roy, Radhika R CIV (US)" X-Mailer: Apple Mail (2.1499) Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:33:10 -0000 (as chair) In fact, there have been some parallel discussions about SIMPLE-XMPP = interworking.=20 Audio and video integration are certainly not off limits if people are = interested in discussing them. If they are, starting a separate thread = on the subject would help avoid some of the "what are we really talking = about" confusion. Thanks! Ben. On Oct 30, 2012, at 8:29 AM, I=F1aki Baz Castillo wrote: > 2012/10/30 Roy, Radhika R CIV (US) : >> Folks: >>=20 >> I do not whether when you talk about SIMPLE and XMPP, do you also = talk about >> integration of SIMPLE (or XMPP) with audio and video? >>=20 >> Or, are you saying the following only? >>=20 >> 1. Only SIMPLE-SIMPLE Interworking. >>=20 >> 2. Only SIMPLE-XMPP Interworking. >>=20 >> Please clarify in the mailing list. >=20 >=20 > The fact is that we are trying to talk about SIMPLE-SIMPLE and not > about XMPP or SIMPLE-XMPP interoperability. >=20 > Regards. >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From oej@edvina.net Tue Oct 30 08:08:31 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8F321F8529 for ; Tue, 30 Oct 2012 08:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TxEsgnKopqP for ; Tue, 30 Oct 2012 08:08:31 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id EC92721F8526 for ; Tue, 30 Oct 2012 08:08:30 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1001] (unknown [IPv6:2001:16d8:cc57:1000::42:1001]) by smtp7.webway.se (Postfix) with ESMTPA id BE5AE754A8A7; Tue, 30 Oct 2012 15:08:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF4864367B@ucolhp9h.easf.csd.disa.mil> Date: Tue, 30 Oct 2012 16:08:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47BAA819-B836-434C-AFC0-311AFB16E205@edvina.net> <8486C8728176924BAF5BDB2F7D7EEDDF4864367B@ucolhp9h.easf.csd.disa.mil> To: "Roy, Radhika R CIV (US)" X-Mailer: Apple Mail (2.1499) Cc: Simple WG Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:08:31 -0000 30 okt 2012 kl. 14:21 skrev "Roy, Radhika R CIV (US)" = : > Folks: >=20 > I do not whether when you talk about SIMPLE and XMPP, do you also talk = about=20 > integration of SIMPLE (or XMPP) with audio and video? >=20 > Or, are you saying the following only? >=20 > 1. Only SIMPLE-SIMPLE Interworking. >=20 > 2. Only SIMPLE-XMPP Interworking. >=20 > Please clarify in the mailing list. I am trying to focus on SIMPLE-SIMPLE interworking to narrow the scope. /O= From bernard_aboba@hotmail.com Wed Oct 31 15:08:31 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F6021F8721 for ; Wed, 31 Oct 2012 15:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBP7aQtzc-iR for ; Wed, 31 Oct 2012 15:08:30 -0700 (PDT) Received: from blu0-omc4-s37.blu0.hotmail.com (blu0-omc4-s37.blu0.hotmail.com [65.55.111.176]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3F21F871C for ; Wed, 31 Oct 2012 15:08:30 -0700 (PDT) Received: from BLU002-W106 ([65.55.111.135]) by blu0-omc4-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Oct 2012 15:08:29 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_cfa7ca78-8d9f-44ae-8496-a5bf272624d7_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: "simple@ietf.org" Date: Wed, 31 Oct 2012 15:08:29 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2012 22:08:29.0641 (UTC) FILETIME=[42357B90:01CDB7B4] Subject: Re: [Simple] SIMPLE and Emergency Services X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:08:31 -0000 --_cfa7ca78-8d9f-44ae-8496-a5bf272624d7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In response to Olle's question about whether SIMPLE is an abject and irrede= emable failure=2C I would note that SIMPLE is still under consideration fo= r use in emergency services=2C if only because XMPP isn't yet a viable alte= rnative. For example=2C both NENA i3 and ECRIT PhoneBCP mention SIMPLE=2C = but refer to XMPP support of emergency services as future work. In emergen= cy scenarios=2C presence and address books are typically not considered sin= ce the PSAP is neither a presentity nor a watcher. Instead=2C SIMPLE is u= sed as a way of conveying information between the caller and PSAP=2C includ= ing location=2C a message body and additional data. With SMS to 911 under a= ctive discussion with regulatory bodies=2C the question about whether we ca= n rely on SIMPLE for emergency use has become a "hot issue". As an exampl= e=2C there has been a suggestion that MESSAGE could be used to support con= veyance of SMS text messages to a "text gateway" that would then pass them= on to the PSAP (possibly in a different form=2C such as translating to TTY= /TDD). Not only might this help standardize the transport of SMS messages = to 911=2C but it would also support future uses of MESSAGE for next generat= ion emergency services.=20 While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE specs= =2C some folks have pointed to the lack of support for MESSAGE in SIP trunk= ing services as an indication that even basic uses of SIMPLE are unlikely t= o see much deployment=2C and that alternatives for disabled access to emerg= ency services (such as RFC 4103 realtime text) should be given priority.=20 IMHO=2C unless XMPP for emergency uses is specified by IETF in the near fu= ture=2C it is likely that SIMPLE will find its way into emergency services = architectures in some form. Since the IETF is still recommending SIMPLE in= documents such as ECRIT PhoneBCP=2C IMHO the IETF has a responsibility to = public safety to address interop issues that will arise in next generation = emergency services scenarios. AFAIK=2C SIMPLE interop issues haven't kille= d anyone yet. Hopefully this will remain true in the future. =20 Olle E. Johansson said: "Any other thoughts in regards to SIMPLE?=0A= =0A= Is it a failure or not?=0A= =0A= Do we have a chance of fixing this within the IETF?=0A= =0A= Is anyone interested in fixing it so we actually reach the WG goal of inter= operability?"=0A= =0A= = --_cfa7ca78-8d9f-44ae-8496-a5bf272624d7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In response to Olle's question about whether SIMPLE is an abject a= nd irredeemable failure=2C =3B I would note that SIMPLE is still under = consideration for use in emergency services=2C if only because XMPP isn't y= et a viable alternative. For example=2C both NENA i3 and ECRIT PhoneBCP mention SIMPLE=2C= but refer to XMPP support of emergency services as future work. In emerge= ncy scenarios=2C presence and address books are typically not considered si= nce the PSAP is neither a presentity nor a watcher. =3B Instead=2C SIM= PLE is used as a way of conveying information between the caller and PSAP= =2C including location=2C a message body and additional data.

<= div>With SMS to 911 under active discussion with regulatory bodies=2C th= e question about whether we can rely on SIMPLE for emergency use has become= a "hot issue". As an example=2C there has been a suggestion that MESSAGE= could be used to support conveyance of SMS text message= s to a "text gateway" that would then pass them on to the PSAP (possibly i= n a different form=2C such as translating to TTY/TDD).  =3BNot only mig= ht this help standardize the transport of SMS messages to 911=2C but it wou= ld also support future uses of MESSAGE for next generation emergency servic= es.

While documents like NE= NAi3 and ECRIT PhoneBCP still point to SIMPLE specs=2C some folks have poin= ted to the lack of support for MESSAGE in SIP trunking services as an indic= ation that even basic uses of SIMPLE are unlikely to see much deployment=2C= and that alternatives for disabled access to emergency services (such as R= FC 4103 realtime text) should be given priority. =3B
<= span style=3D"white-space: pre-wrap=3B font-family: Calibri=2C sans-serif= =3B">
IMHO=2C unless XMPP for emergency uses is s= pecified by IETF in the near future=2C it is likely that SIMPLE will find i= ts way into emergency services architectures in some form. Since the IETF = is still recommending SIMPLE in documents such as ECRIT PhoneBCP=2C IMHO th= e IETF has a responsibility to public safety to address interop issues that= will arise in next generation emergency services scenarios. AFAIK=2C SIMP= LE interop issues haven't killed anyone yet. Hopefully this will remain tr= ue in the future.
<= span style=3D"white-space: pre-wrap=3B">
Olle E. Johansson said: =3B
"Any other thoughts in =
regards to SIMPLE?=0A=
=0A=
Is it a failure or not?=0A=
=0A=
Do we have a chance of fixing this within the IETF?=0A=
=0A=
Is anyone interested in fixing it so we actually reach the WG goal of inter=
operability?"=0A=
=0A=
= --_cfa7ca78-8d9f-44ae-8496-a5bf272624d7_--