From geir.sandbakken@tandberg.com Wed Aug 5 06:55:08 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D30928C0E2 for ; Wed, 5 Aug 2009 06:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSdIoaT0Zwl0 for ; Wed, 5 Aug 2009 06:55:07 -0700 (PDT) Received: from mail195.messagelabs.com (mail195.messagelabs.com [85.158.138.147]) by core3.amsl.com (Postfix) with SMTP id 84C203A6A9C for ; Wed, 5 Aug 2009 06:54:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-12.tower-195.messagelabs.com!1249480469!27994557!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 29923 invoked from network); 5 Aug 2009 13:54:29 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-12.tower-195.messagelabs.com with SMTP; 5 Aug 2009 13:54:29 -0000 Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:54:29 +0200 Received: from [10.47.19.151] (GSandbakkenT61.rd.tandberg.com [10.47.19.151]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id n75DsS4o023714; Wed, 5 Aug 2009 15:54:29 +0200 Message-ID: <4A798F14.5010201@tandberg.com> Date: Wed, 05 Aug 2009 15:54:28 +0200 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ben Campbell References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> <3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> In-Reply-To: <3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 13:54:29.0326 (UTC) FILETIME=[408616E0:01CA15D4] Cc: Simple WG Subject: Re: [Simple] simple-chat status X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 13:55:08 -0000 It is unfortunate if my inability to move the draft forward kills a good idea. IMHO, the good thing about simple-chat is that it is nimble. If you have MSRP implemented, you can fairly easily add chat room support, bring it to SIPit and test it. We had two good WGLC reviews- and I believe all of the issues can be resolved and published before the next meeting. My vote goes to keeping the draft - and not break it into pieces. Thanks! Geir Arne Ben Campbell wrote: > (As chair) > > The sense of the room in Stockholm was that we no longer needed the > simple-chat as it currently exists, but that we did need to make sure > we preserved the information in it that describes how a focus works > with MSRP and message/cpim, whether as a scaled down version of > simple-chat or as an addition to the XCON documents. > > I'd like to make a consensus call on the list to confirm or deny that > approach. (I just saw Hisham's email--what do other's think?) > > Thanks! > > ben. > > On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote: > >> (as SIMPLE chair) >> >> Hi, >> >> We originally started work on draft-ietf-simple-chat back in 2007, >> with the idea that we could finish it quickly, and have something >> that works prior to completion of similar, but more general work in >> XCON. >> >> It's been two years now, so we clearly didn't finish it quickly, and >> it's been sitting without update or discussion since last spring. >> (Please don't take that as a complaint against the authors. I don't >> mean it that way--we're all busy here.) We are looking at how to get >> the draft moving again, but there's an important question we should >> address first: >> >> Is simple-chat still relevant? Should we take the effort to fix it, >> or should we shoot that milestone in the head? >> >> To recap, we WGLC'd simple-chat last April. There were non-trivial >> (but not necessarily earth-shattering) issues brought up in the >> feedback. That is, there's still at least a bit of work left to do on >> it. >> >> Perhaps Adam or Alan could comment on the status of the related work >> in XCON? >> >> Thanks! >> >> Ben. >> _______________________________________________ >> 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 geir.sandbakken@tandberg.com Thu Aug 6 08:35:10 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A5C28C123 for ; Thu, 6 Aug 2009 08:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2C+0TrgDtmb for ; Thu, 6 Aug 2009 08:35:10 -0700 (PDT) Received: from mail179.messagelabs.com (mail179.messagelabs.com [85.158.139.35]) by core3.amsl.com (Postfix) with SMTP id 461ED28C10F for ; Thu, 6 Aug 2009 08:34:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-2.tower-179.messagelabs.com!1249572860!17598513!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 31318 invoked from network); 6 Aug 2009 15:34:20 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-2.tower-179.messagelabs.com with SMTP; 6 Aug 2009 15:34:20 -0000 Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 17:34:19 +0200 Received: from [10.0.6.176] ([10.0.6.176]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id n76FYJ2h031138 for ; Thu, 6 Aug 2009 17:34:19 +0200 Message-ID: <4A7AF7FB.6080304@tandberg.com> Date: Thu, 06 Aug 2009 17:34:19 +0200 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Simple Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2009 15:34:19.0394 (UTC) FILETIME=[5D4BAE20:01CA16AB] Subject: [Simple] WGLC Summary for draft-ietf-simple-chat-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 15:35:10 -0000 Summary of the WGLC reviews. If I have missed anything - please let me know. Additions and changes going into -05: 1. Architectural diagrams or descriptions clarifying MSRP switch role towards MSRP relay, endpoints and focus 2. Clean up Section 6.2 on Private Messages 3. Various Nickname clarifications: terminology, privacy and security 4. Add normative reference to P-Asserted-Identity 5. Example of a Conference Event Package notification with a nickname element 6. Lots of requirement clean ups. Scary. 7. Clarification around conference "unaware" participants 8. MSRP switch needs to be made Message-Id stateful. Add text. 9. More reporting model update - and removal. 10. Remove mixed media references 11. Add text on side effect when removing chat rooms. 12. Add Multi-chunk example 13. Remove GRUU example 14. Add error response on private message 15. Various editorial fixes and simplifications 16. Add Mary and Ben to Acknowledgements Currently not planed for -05 1. Reuse of nicknames is not part of the specification as it is considered to be part of the policy of the chat room. Different chat rooms might have different policies regarding allocation of a nickname removed by another. Thanks, Geir Arne From mary.barnes@nortel.com Thu Aug 6 15:51:26 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230A63A6B1E for ; Thu, 6 Aug 2009 15:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1JsdzFDhiiK for ; Thu, 6 Aug 2009 15:51:25 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1094E3A69D9 for ; Thu, 6 Aug 2009 15:51:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n76MowU16498; Thu, 6 Aug 2009 22:50:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 17:53:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F59F699@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A798F14.5010201@tandberg.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] simple-chat status thread-index: AcoV1F8X079W3Q+0QvuX88vNJqqrNgBEvGJA References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net><3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> <4A798F14.5010201@tandberg.com> From: "Mary Barnes" To: "Geir Arne Sandbakken" , "Ben Campbell" Cc: Simple WG Subject: Re: [Simple] simple-chat status X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 22:51:26 -0000 Geir, I don't think it's only the issue of the document not having been updated. IMHO, the fact that one of the WGLC reviews was from the WG chair and the other from me, who only did the review because it seemed the WG was moving forward with this document, doesn't indicate significant WG interest. It's up to the chairs to decide if there remains enough WG interest to complete the document. And, I didn't understand at all that we were talking about breaking anything into pieces - the work in XCON is a superset.=20 Regards, Mary. =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Geir Arne Sandbakken Sent: Wednesday, August 05, 2009 8:54 AM To: Ben Campbell Cc: Simple WG Subject: Re: [Simple] simple-chat status It is unfortunate if my inability to move the draft forward kills a good idea. IMHO, the good thing about simple-chat is that it is nimble. If you have MSRP implemented, you can fairly easily add chat room support, bring it to SIPit and test it. We had two good WGLC reviews- and I believe all of the issues can be resolved and published before the next meeting. My vote goes to keeping the draft - and not break it into pieces. Thanks! Geir Arne Ben Campbell wrote: > (As chair) > > The sense of the room in Stockholm was that we no longer needed the=20 > simple-chat as it currently exists, but that we did need to make sure=20 > we preserved the information in it that describes how a focus works=20 > with MSRP and message/cpim, whether as a scaled down version of=20 > simple-chat or as an addition to the XCON documents. > > I'd like to make a consensus call on the list to confirm or deny that=20 > approach. (I just saw Hisham's email--what do other's think?) > > Thanks! > > ben. > > On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote: > >> (as SIMPLE chair) >> >> Hi, >> >> We originally started work on draft-ietf-simple-chat back in 2007,=20 >> with the idea that we could finish it quickly, and have something=20 >> that works prior to completion of similar, but more general work in=20 >> XCON. >> >> It's been two years now, so we clearly didn't finish it quickly, and=20 >> it's been sitting without update or discussion since last spring. >> (Please don't take that as a complaint against the authors. I don't=20 >> mean it that way--we're all busy here.) We are looking at how to get=20 >> the draft moving again, but there's an important question we should=20 >> address first: >> >> Is simple-chat still relevant? Should we take the effort to fix it,=20 >> or should we shoot that milestone in the head? >> >> To recap, we WGLC'd simple-chat last April. There were non-trivial=20 >> (but not necessarily earth-shattering) issues brought up in the=20 >> feedback. That is, there's still at least a bit of work left to do on >> it. >> >> Perhaps Adam or Alan could comment on the status of the related work=20 >> in XCON? >> >> Thanks! >> >> Ben. >> _______________________________________________ >> 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 geir.sandbakken@tandberg.com Fri Aug 7 02:14:39 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07E03A6A3C for ; Fri, 7 Aug 2009 02:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTE0EzeqiVIa for ; Fri, 7 Aug 2009 02:14:39 -0700 (PDT) Received: from mail195.messagelabs.com (mail195.messagelabs.com [85.158.138.147]) by core3.amsl.com (Postfix) with SMTP id 8194D3A67FF for ; Fri, 7 Aug 2009 02:13:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-12.tower-195.messagelabs.com!1249636437!28461856!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 12934 invoked from network); 7 Aug 2009 09:13:57 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-12.tower-195.messagelabs.com with SMTP; 7 Aug 2009 09:13:57 -0000 Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 11:13:56 +0200 Received: from [10.47.19.155] (GSandbakkenT61.rd.tandberg.com [10.47.19.155]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id n779DuYu006075; Fri, 7 Aug 2009 11:13:56 +0200 Message-ID: <4A7BF054.4070100@tandberg.com> Date: Fri, 07 Aug 2009 11:13:56 +0200 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Mary Barnes References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net><3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> <4A798F14.5010201@tandberg.com> <1ECE0EB50388174790F9694F77522CCF1F59F699@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F59F699@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2009 09:13:56.0895 (UTC) FILETIME=[647072F0:01CA173F] Cc: Simple WG Subject: Re: [Simple] simple-chat status X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 09:14:40 -0000 Mary, Sorry, I was a bit unclear. What I meant was breaking the draft into pieces. The chat room attribute and nickname mechanism to be pulled out of the draft, and moved into the XCON framework and the CCMP protocol. Keeping the MSRP switch in this or another draft - having a normative reference to a framework to achieve these semantics. IMHO, implementation interest is what should decide if it should be published. Regards, Geir Arne Mary Barnes wrote: > Geir, > > I don't think it's only the issue of the document not having been > updated. IMHO, the fact that one of the WGLC reviews was from the WG > chair and the other from me, who only did the review because it seemed > the WG was moving forward with this document, doesn't indicate > significant WG interest. It's up to the chairs to decide if there > remains enough WG interest to complete the document. And, I didn't > understand at all that we were talking about breaking anything into > pieces - the work in XCON is a superset. > > Regards, > Mary. > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Geir Arne Sandbakken > Sent: Wednesday, August 05, 2009 8:54 AM > To: Ben Campbell > Cc: Simple WG > Subject: Re: [Simple] simple-chat status > > It is unfortunate if my inability to move the draft forward kills a good > idea. IMHO, the good thing about simple-chat is that it is nimble. If > you have MSRP implemented, you can fairly easily add chat room support, > bring it to SIPit and test it. > > We had two good WGLC reviews- and I believe all of the issues can be > resolved and published before the next meeting. > > My vote goes to keeping the draft - and not break it into pieces. > > Thanks! > Geir Arne > > Ben Campbell wrote: > >> (As chair) >> >> The sense of the room in Stockholm was that we no longer needed the >> simple-chat as it currently exists, but that we did need to make sure >> we preserved the information in it that describes how a focus works >> with MSRP and message/cpim, whether as a scaled down version of >> simple-chat or as an addition to the XCON documents. >> >> I'd like to make a consensus call on the list to confirm or deny that >> approach. (I just saw Hisham's email--what do other's think?) >> >> Thanks! >> >> ben. >> >> On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote: >> >> >>> (as SIMPLE chair) >>> >>> Hi, >>> >>> We originally started work on draft-ietf-simple-chat back in 2007, >>> with the idea that we could finish it quickly, and have something >>> that works prior to completion of similar, but more general work in >>> XCON. >>> >>> It's been two years now, so we clearly didn't finish it quickly, and >>> it's been sitting without update or discussion since last spring. >>> (Please don't take that as a complaint against the authors. I don't >>> mean it that way--we're all busy here.) We are looking at how to get >>> the draft moving again, but there's an important question we should >>> address first: >>> >>> Is simple-chat still relevant? Should we take the effort to fix it, >>> or should we shoot that milestone in the head? >>> >>> To recap, we WGLC'd simple-chat last April. There were non-trivial >>> (but not necessarily earth-shattering) issues brought up in the >>> feedback. That is, there's still at least a bit of work left to do on >>> > > >>> it. >>> >>> Perhaps Adam or Alan could comment on the status of the related work >>> in XCON? >>> >>> Thanks! >>> >>> Ben. >>> _______________________________________________ >>> 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 ben@nostrum.com Fri Aug 7 13:35:33 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060693A672F for ; Fri, 7 Aug 2009 13:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10uFe6ZdTybq for ; Fri, 7 Aug 2009 13:35:32 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 139413A6AAF for ; Fri, 7 Aug 2009 13:35:31 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-28-173.dsl.rcsntx.swbell.net [68.94.28.173]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n77KYH8i018884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 15:34:18 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <0770C27A-65E3-42EA-86D8-F3C416E212D1@nostrum.com> From: Ben Campbell To: Mary Barnes In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F59F699@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 15:34:12 -0500 References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net><3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> <4A798F14.5010201@tandberg.com> <1ECE0EB50388174790F9694F77522CCF1F59F699@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 68.94.28.173 is authenticated by a trusted mechanism) Cc: Geir Arne Sandbakken , Simple WG Subject: Re: [Simple] simple-chat status X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 20:35:33 -0000 Since we originally had a consensus to pursue this milestone, we need a clear consensus to stop working on it if we are going to do so. So far, we have a few people in favor of stopping the work(Adam, Mary, myself, and a few others), but we've also seen some opinions in favor of keeping it (Hisham, Geir Arne, and maybe a little bit of Adrian). I'd like to see the following from those who have expressed an opinion, (and even if you haven't expressed one so far.): 1. Have you or do you plan to implement simple-chat? Or are you aware of other's work in this area? (Adrian pointed to one implementation so far.) 2. If you answered yes to 1., if the XCON framework and CCMP were complete_today_, would your answer to 1 change? 3. If _both_ simple-chat and XCON/CCMP were complete _today_, would your answer to 1 change? On Aug 6, 2009, at 5:53 PM, Mary Barnes wrote: > Geir, > > I don't think it's only the issue of the document not having been > updated. IMHO, the fact that one of the WGLC reviews was from the WG > chair and the other from me, who only did the review because it seemed > the WG was moving forward with this document, doesn't indicate > significant WG interest. It's up to the chairs to decide if there > remains enough WG interest to complete the document. And, I didn't > understand at all that we were talking about breaking anything into > pieces - the work in XCON is a superset. > > Regards, > Mary. > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Geir Arne Sandbakken > Sent: Wednesday, August 05, 2009 8:54 AM > To: Ben Campbell > Cc: Simple WG > Subject: Re: [Simple] simple-chat status > > It is unfortunate if my inability to move the draft forward kills a > good > idea. IMHO, the good thing about simple-chat is that it is nimble. If > you have MSRP implemented, you can fairly easily add chat room > support, > bring it to SIPit and test it. > > We had two good WGLC reviews- and I believe all of the issues can be > resolved and published before the next meeting. > > My vote goes to keeping the draft - and not break it into pieces. > > Thanks! > Geir Arne > > Ben Campbell wrote: >> (As chair) >> >> The sense of the room in Stockholm was that we no longer needed the >> simple-chat as it currently exists, but that we did need to make sure >> we preserved the information in it that describes how a focus works >> with MSRP and message/cpim, whether as a scaled down version of >> simple-chat or as an addition to the XCON documents. >> >> I'd like to make a consensus call on the list to confirm or deny that >> approach. (I just saw Hisham's email--what do other's think?) >> >> Thanks! >> >> ben. >> >> On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote: >> >>> (as SIMPLE chair) >>> >>> Hi, >>> >>> We originally started work on draft-ietf-simple-chat back in 2007, >>> with the idea that we could finish it quickly, and have something >>> that works prior to completion of similar, but more general work in >>> XCON. >>> >>> It's been two years now, so we clearly didn't finish it quickly, and >>> it's been sitting without update or discussion since last spring. >>> (Please don't take that as a complaint against the authors. I don't >>> mean it that way--we're all busy here.) We are looking at how to get >>> the draft moving again, but there's an important question we should >>> address first: >>> >>> Is simple-chat still relevant? Should we take the effort to fix it, >>> or should we shoot that milestone in the head? >>> >>> To recap, we WGLC'd simple-chat last April. There were non-trivial >>> (but not necessarily earth-shattering) issues brought up in the >>> feedback. That is, there's still at least a bit of work left to do >>> on > >>> it. >>> >>> Perhaps Adam or Alan could comment on the status of the related work >>> in XCON? >>> >>> Thanks! >>> >>> Ben. >>> _______________________________________________ >>> 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 From mary.barnes@nortel.com Fri Aug 7 14:15:37 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBBC3A67D3 for ; Fri, 7 Aug 2009 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LBRxTRNF+d8 for ; Fri, 7 Aug 2009 14:15:37 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id AF7053A6B80 for ; Fri, 7 Aug 2009 14:15:36 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n77LDB907823; Fri, 7 Aug 2009 21:13:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Aug 2009 16:17:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F5E4E6A@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A7BF054.4070100@tandberg.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] simple-chat status thread-index: AcoXP2bZ8Z4RLddSR72g+9JAvzyV5gAYnZ+A References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net><3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> <4A798F14.5010201@tandberg.com> <1ECE0EB50388174790F9694F77522CCF1F59F699@zrc2hxm0.corp.nortel.com> <4A7BF054.4070100@tandberg.com> From: "Mary Barnes" To: "Geir Arne Sandbakken" Cc: Simple WG Subject: Re: [Simple] simple-chat status X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 21:15:38 -0000 Hi Geir, I guess I'm still confused as I don't think you'll need the Nickname mechanism added to MSRP if you use the XCON Framework (you get that functionality for free, if you will). I also think the MSRP switch functionality is something that can be naturally provided by the XCON conference server/focus. This had been described in an earlier version of the XCON chat document (which has been around just a few months less than the SIMPLE document since 2005). Also, if you use XCON, you don't need the chat room attribute per se as the "media"/"signaling" type is part of the conference object. =20 I honestly don't see a problem if someone wants to implement this version of the simple-chat document since it could easily be evolved to the XCON framework. That all said, there is already an implementation of the XCON protocol (CCMP) and it should not be that difficult to combine an MSRP implementation with that rather than having a standalone MSRP chat implementation (which requires normative changes to MSRP as opposed to the XCON solution). =20 Regards, Mary.=20 -----Original Message----- From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.com]=20 Sent: Friday, August 07, 2009 4:14 AM To: Barnes, Mary (RICH2:AR00) Cc: Ben Campbell; Simple WG Subject: Re: [Simple] simple-chat status Mary, Sorry, I was a bit unclear. What I meant was breaking the draft into pieces. The chat room attribute and nickname mechanism to be pulled out of the draft, and moved into the XCON framework and the CCMP protocol.=20 Keeping the MSRP switch in this or another draft - having a normative reference to a framework to achieve these semantics. IMHO, implementation interest is what should decide if it should be published. Regards, Geir Arne Mary Barnes wrote: > Geir, > > I don't think it's only the issue of the document not having been=20 > updated. IMHO, the fact that one of the WGLC reviews was from the WG=20 > chair and the other from me, who only did the review because it seemed > the WG was moving forward with this document, doesn't indicate=20 > significant WG interest. It's up to the chairs to decide if there=20 > remains enough WG interest to complete the document. And, I didn't=20 > understand at all that we were talking about breaking anything into=20 > pieces - the work in XCON is a superset. > > Regards, > Mary. =20 > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 > Behalf Of Geir Arne Sandbakken > Sent: Wednesday, August 05, 2009 8:54 AM > To: Ben Campbell > Cc: Simple WG > Subject: Re: [Simple] simple-chat status > > It is unfortunate if my inability to move the draft forward kills a=20 > good idea. IMHO, the good thing about simple-chat is that it is=20 > nimble. If you have MSRP implemented, you can fairly easily add chat=20 > room support, bring it to SIPit and test it. > > We had two good WGLC reviews- and I believe all of the issues can be=20 > resolved and published before the next meeting. > > My vote goes to keeping the draft - and not break it into pieces. > > Thanks! > Geir Arne > > Ben Campbell wrote: > =20 >> (As chair) >> >> The sense of the room in Stockholm was that we no longer needed the=20 >> simple-chat as it currently exists, but that we did need to make sure >> we preserved the information in it that describes how a focus works=20 >> with MSRP and message/cpim, whether as a scaled down version of=20 >> simple-chat or as an addition to the XCON documents. >> >> I'd like to make a consensus call on the list to confirm or deny that >> approach. (I just saw Hisham's email--what do other's think?) >> >> Thanks! >> >> ben. >> >> On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote: >> >> =20 >>> (as SIMPLE chair) >>> >>> Hi, >>> >>> We originally started work on draft-ietf-simple-chat back in 2007,=20 >>> with the idea that we could finish it quickly, and have something=20 >>> that works prior to completion of similar, but more general work in=20 >>> XCON. >>> >>> It's been two years now, so we clearly didn't finish it quickly, and >>> it's been sitting without update or discussion since last spring. >>> (Please don't take that as a complaint against the authors. I don't=20 >>> mean it that way--we're all busy here.) We are looking at how to get >>> the draft moving again, but there's an important question we should=20 >>> address first: >>> >>> Is simple-chat still relevant? Should we take the effort to fix it,=20 >>> or should we shoot that milestone in the head? >>> >>> To recap, we WGLC'd simple-chat last April. There were non-trivial=20 >>> (but not necessarily earth-shattering) issues brought up in the=20 >>> feedback. That is, there's still at least a bit of work left to do=20 >>> on >>> =20 > > =20 >>> it. >>> >>> Perhaps Adam or Alan could comment on the status of the related work >>> in XCON? >>> >>> Thanks! >>> >>> Ben. >>> _______________________________________________ >>> 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 >> =20 > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > =20 From hisham.khartabil@gmail.com Sat Aug 8 09:01:36 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD8928C113 for ; Sat, 8 Aug 2009 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0k+a-ZMdjxT for ; Sat, 8 Aug 2009 09:01:35 -0700 (PDT) Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) by core3.amsl.com (Postfix) with ESMTP id 1F2123A6DE1 for ; Sat, 8 Aug 2009 09:01:35 -0700 (PDT) Received: by pzk8 with SMTP id 8so2272822pzk.31 for ; Sat, 08 Aug 2009 09:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MiijqTdBssP1gFZ3cGRoIuVq1npn83c/tYVS3WG8R2E=; b=OryABYgSxCrot9CLf5dwCUCOnNnKgy88FhbVznm8wV9s5P5bVmdR1Bis5DRgYpv2EZ dCGFpnq8kyf1hGY6GfGCBWtjKNxQmNoYx1e/TeDOV8M5DBd/KuX0meQaiqv2KNbGq3sF FUUMUjYe6A+EPlP2ZfOGqWurAoT8PeDUKtVtw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lz1j3kOLJOFq4MAQ8FokZdPhQ4Yhz8ZwRyhdLhALB+NNCnNrdvMxq+jaY18N0vUG/d Ep+HJIdCd2e/VhEoJ9xrStRa3lWYshkv4XyRstNrDy1SwQ6GiyMHz5sQvVF0nSfDsBc+ MS8RXu+Wbr489I0DjZks44MYmqtL+DTs/q1Vc= MIME-Version: 1.0 Received: by 10.114.210.4 with SMTP id i4mr3411611wag.196.1249747296820; Sat, 08 Aug 2009 09:01:36 -0700 (PDT) In-Reply-To: <0770C27A-65E3-42EA-86D8-F3C416E212D1@nostrum.com> References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net> <3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> <4A798F14.5010201@tandberg.com> <1ECE0EB50388174790F9694F77522CCF1F59F699@zrc2hxm0.corp.nortel.com> <0770C27A-65E3-42EA-86D8-F3C416E212D1@nostrum.com> Date: Sun, 9 Aug 2009 02:01:36 +1000 Message-ID: <66cd252f0908080901n5157a09bu6741b2811148ed4c@mail.gmail.com> From: Hisham Khartabil To: Ben Campbell Content-Type: multipart/alternative; boundary=00163646c140af9cff0470a377df Cc: Geir Arne Sandbakken , Mary Barnes , Simple WG Subject: Re: [Simple] simple-chat status X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 08 Aug 2009 16:01:36 -0000 --00163646c140af9cff0470a377df Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/8/8 Ben Campbell > > Since we originally had a consensus to pursue this milestone, we need a > clear consensus to stop working on it if we are going to do so. So far, we > have a few people in favor of stopping the work(Adam, Mary, myself, and a > few others), but we've also seen some opinions in favor of keeping it > (Hisham, Geir Arne, and maybe a little bit of Adrian). > > I'd like to see the following from those who have expressed an opinion, > (and even if you haven't expressed one so far.): > > 1. Have you or do you plan to implement simple-chat? Or are you aware of > other's work in this area? (Adrian pointed to one implementation so far.) Yes. Two of my customers (or ex-customers now) requested this to be implemented in the IMS system we are selling them. > > > 2. If you answered yes to 1., if the XCON framework and CCMP were > complete_today_, would your answer to 1 change? No. I don't need to go implement a whole XCON framework just to get this basic functionality into my solution, especially if that is the only functionality I'm interested in for now. I just need the basic simple chat service. > > 3. If _both_ simple-chat and XCON/CCMP were complete _today_, would your > answer to 1 change? No. Obviously there was interest in this draft a long time ago, and that's why it was added as a charter item. I think we also need to ask the question out of those who are of the opinion to stop the work on this: 4. Have you had a change of heart because you've always believed that simple-chat is a temp solutionand now its taken too long and CCMP is close to completion anyway? 5. Were you always not interested in simple-chat I would like to point out that simple-chat is delayed not because of any technical issues, but rather editors not having the cycles. I don't understand why we would abandon a draft that is complete (albiot one final revision updating minor issues). Regards, Hisham > > > > > > > > > > On Aug 6, 2009, at 5:53 PM, Mary Barnes wrote: > > Geir, >> >> I don't think it's only the issue of the document not having been >> updated. IMHO, the fact that one of the WGLC reviews was from the WG >> chair and the other from me, who only did the review because it seemed >> the WG was moving forward with this document, doesn't indicate >> significant WG interest. It's up to the chairs to decide if there >> remains enough WG interest to complete the document. And, I didn't >> understand at all that we were talking about breaking anything into >> pieces - the work in XCON is a superset. >> >> Regards, >> Mary. >> >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >> Of Geir Arne Sandbakken >> Sent: Wednesday, August 05, 2009 8:54 AM >> To: Ben Campbell >> Cc: Simple WG >> Subject: Re: [Simple] simple-chat status >> >> It is unfortunate if my inability to move the draft forward kills a good >> idea. IMHO, the good thing about simple-chat is that it is nimble. If >> you have MSRP implemented, you can fairly easily add chat room support, >> bring it to SIPit and test it. >> >> We had two good WGLC reviews- and I believe all of the issues can be >> resolved and published before the next meeting. >> >> My vote goes to keeping the draft - and not break it into pieces. >> >> Thanks! >> Geir Arne >> >> Ben Campbell wrote: >> >>> (As chair) >>> >>> The sense of the room in Stockholm was that we no longer needed the >>> simple-chat as it currently exists, but that we did need to make sure >>> we preserved the information in it that describes how a focus works >>> with MSRP and message/cpim, whether as a scaled down version of >>> simple-chat or as an addition to the XCON documents. >>> >>> I'd like to make a consensus call on the list to confirm or deny that >>> approach. (I just saw Hisham's email--what do other's think?) >>> >>> Thanks! >>> >>> ben. >>> >>> On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote: >>> >>> (as SIMPLE chair) >>>> >>>> Hi, >>>> >>>> We originally started work on draft-ietf-simple-chat back in 2007, >>>> with the idea that we could finish it quickly, and have something >>>> that works prior to completion of similar, but more general work in >>>> XCON. >>>> >>>> It's been two years now, so we clearly didn't finish it quickly, and >>>> it's been sitting without update or discussion since last spring. >>>> (Please don't take that as a complaint against the authors. I don't >>>> mean it that way--we're all busy here.) We are looking at how to get >>>> the draft moving again, but there's an important question we should >>>> address first: >>>> >>>> Is simple-chat still relevant? Should we take the effort to fix it, >>>> or should we shoot that milestone in the head? >>>> >>>> To recap, we WGLC'd simple-chat last April. There were non-trivial >>>> (but not necessarily earth-shattering) issues brought up in the >>>> feedback. That is, there's still at least a bit of work left to do on >>>> >>> >> it. >>>> >>>> Perhaps Adam or Alan could comment on the status of the related work >>>> in XCON? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --00163646c140af9cff0470a377df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/8/8 Ben Campbell = <ben@nostrum.com>
<as-chair>
Since we originally had a consensus to pursue this milestone, we need a cle= ar consensus to stop working on it if we are going to do so. So far, we hav= e a few people in favor of stopping the work(Adam, Mary, myself, and a few = others), but we've also seen some opinions in favor of keeping it (Hish= am, Geir Arne, and maybe a little bit of Adrian).

I'd like to see the following from those who have expressed an opinion,= (and even if you haven't expressed one so far.):

1. Have you or do you plan to implement simple-chat? Or are you aware of ot= her's work in this area? (Adrian pointed to one implementation so far.)=

Yes. Two of my customers (or ex-customers now) reques= ted this to be implemented in the IMS system we are selling them.
=A0


2. If you answered yes to 1., if the XCON framework and =A0CCMP were comple= te_today_, would your answer to 1 change?

No. I don= 9;t need to go implement a whole XCON framework just to get this basic functionality into my solution, especially if that is the only functionality I'm interested in for now. I just need the basic simple chat service.
=A0


3. If _both_ simple-chat and XCON/CCMP were complete _today_, would your an= swer to 1 change?

No.



Obviously there w= as interest in this draft a long time ago, and that's why it was added as a charter item. I think we also need to ask the question out of those who are of the opinion to stop the work on this:

4. Have you had a change of heart because you've always believed that simple-chat is a temp solutionand now its taken too long and CCMP is close to completion anyway?

5. Were you always not interested in = simple-chat

I would like to point out that simple-chat is delayed not because of any technical issues, but rather editors not having the cycles. I don't understand why we would abandon a draft that is complete (albiot one final revision updating minor issues).

Regards,
Hisham
=A0


</as-chair>






On Aug 6, 2009, at 5:53 PM, Mary Barnes wrote:

Geir,

I don't think it's only the issue of the document not having been updated. IMHO, the fact that one of the WGLC reviews was from the WG
chair and the other from me, who only did the review because it seemed
the WG was moving forward with this document, doesn't indicate
significant WG interest. =A0It's up to the chairs to decide if there remains enough WG interest to complete the document. And, I didn't
understand at all that we were talking about breaking anything into
pieces - the work in XCON is a superset.

Regards,
Mary.


-----Original Message-----
From: simple-b= ounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf
Of Geir Arne Sandbakken
Sent: Wednesday, August 05, 2009 8:54 AM
To: Ben Campbell
Cc: Simple WG
Subject: Re: [Simple] simple-chat status

It is unfortunate if my inability to move the draft forward kills a good idea. IMHO, the good thing about simple-chat is that it is nimble. If
you have MSRP implemented, you can fairly easily add chat room support,
bring it to SIPit and test it.

We had two good WGLC reviews- and I believe all of the issues can be
resolved and published before the next meeting.

My vote goes to keeping the draft - and not break it into pieces.

Thanks!
Geir Arne

Ben Campbell wrote:
(As chair)

The sense of the room in Stockholm was that we no longer needed the
simple-chat as it currently exists, but that we did need to make sure
we preserved the information in it that describes how a focus works
with MSRP and message/cpim, whether as a scaled down version of
simple-chat or as an addition to the XCON documents.

I'd like to make a consensus call on the list to confirm or deny that approach. (I just saw Hisham's email--what do other's think?)

Thanks!

ben.

On Jul 27, 2009, at 5:21 PM, Ben Campbell wrote:

(as SIMPLE chair)

Hi,

We originally started work on draft-ietf-simple-chat back in 2007,
with the idea that we could finish it quickly, and have something
that works prior to completion of similar, but more general work in
XCON.

It's been two years now, so we clearly didn't finish it quickly, an= d
it's been sitting without update or discussion since last spring.
(Please don't take that as a complaint against the authors. I don't=
mean it that way--we're all busy here.) We are looking at how to get the draft moving again, but there's an important question we should
address first:

Is simple-chat still relevant? Should we take the effort to fix it,
or should we shoot that milestone in the head?

To recap, we WGLC'd simple-chat last April. There were non-trivial
(but not necessarily earth-shattering) issues brought up in the
feedback. That is, there's still at least a bit of work left to do on

it.

Perhaps Adam or Alan could comment on the status of the related work
in XCON?

Thanks!

Ben.
_______________________________________________
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

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

--00163646c140af9cff0470a377df-- From deepanshu@huawei.com Sun Aug 9 20:24:31 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96E23A6911 for ; Sun, 9 Aug 2009 20:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.789 X-Spam-Level: **** X-Spam-Status: No, score=4.789 tagged_above=-999 required=5 tests=[AWL=2.683, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU9SZkikbETG for ; Sun, 9 Aug 2009 20:24:31 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B8A5E3A689C for ; Sun, 9 Aug 2009 20:24:30 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO50053S5C52Z@szxga03-in.huawei.com> for simple@ietf.org; Mon, 10 Aug 2009 11:21:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO500JW05C5RL@szxga03-in.huawei.com> for simple@ietf.org; Mon, 10 Aug 2009 11:21:41 +0800 (CST) Received: from d57531v ([10.168.86.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO5001K75C3G6@szxml04-in.huawei.com> for simple@ietf.org; Mon, 10 Aug 2009 11:21:39 +0800 (CST) Date: Mon, 10 Aug 2009 11:21:39 +0800 From: Deepanshu Gautam To: Simple WG Message-id: <012201ca1969$acf94c00$4056a80a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_dqpdGbSLVdA2abE0qDKZyQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 03:24:31 -0000 This is a multi-part message in MIME format. --Boundary_(ID_dqpdGbSLVdA2abE0qDKZyQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Dear All, I would like to propose a new IM-specific feature for SIMPLE, which i would call as "Quick Answer(QA)". Allow me to explain about it briefly. In instant messaging system, it is useful to have some readily available IM (text, audio or video) which can be sent in case of the receiver is too busy to type/speak/record for a reply. User can create and store IM (QA) using a particular client device and can use them when required. Creating and then storing on a single device may not be very useful because user can log-in a particular IM system using different client devices at different point of time. In that case QA created using one client device will not be available to another client device. I would like to propose a draft to solve this problem and perform the needed standardization, which will further make this IM-feature possible. Before moving forward I would like to get some initial comment from the group about this idea. You comments would be valuable. Regards Deepanshu Gautam --Boundary_(ID_dqpdGbSLVdA2abE0qDKZyQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Dear All,
 
I would like to propose a = new=20 IM-specific feature for SIMPLE, which i would call as "Quick = Answer(QA)". Allow=20 me to explain about it briefly.
 
In instant messaging = system, it is=20 useful to have some readily available IM (text, audio or video) which = can be=20 sent in case of the receiver is too busy to type/speak/record for a = reply. User=20 can create and store IM (QA) using a particular client device and can = use them=20 when required. Creating and then storing on a single device may not be = very=20 useful because user can log-in a particular IM system using different = client=20 devices at different point of time. In that case QA created using one = client=20 device will not be available to another client device.
 
I would like to propose a = draft to=20 solve this problem and perform the needed standardization, which will = further=20 make this IM-feature possible. Before moving forward I would like to get = some=20 initial comment from the group about this idea. You comments would be=20 valuable.
 
Regards
Deepanshu=20 Gautam
--Boundary_(ID_dqpdGbSLVdA2abE0qDKZyQ)-- From ben@nostrum.com Sun Aug 9 20:58:10 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B9F3A6C51 for ; Sun, 9 Aug 2009 20:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLTCPYna+CWW for ; Sun, 9 Aug 2009 20:58:09 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id B995B3A6C4F for ; Sun, 9 Aug 2009 20:58:09 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-28-173.dsl.rcsntx.swbell.net [68.94.28.173]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7A3uvTI034398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 9 Aug 2009 22:56:57 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <7019380A-075E-40BF-9185-5330DFF4C3BA@nostrum.com> From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 9 Aug 2009 22:56:52 -0500 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 68.94.28.173 is authenticated by a trusted mechanism) Subject: [Simple] Test Message Please Ignore X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 03:58:10 -0000 Ain't nobody here but us chickens From pkyzivat@cisco.com Mon Aug 10 15:44:25 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECD83A6CE8 for ; Mon, 10 Aug 2009 15:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX3KbolUVJtl for ; Mon, 10 Aug 2009 15:44:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B9F2B3A6BAE for ; Mon, 10 Aug 2009 15:44:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAENAgEqrR7O6/2dsb2JhbAC5IYZkgUePHwWBLYIjSIIi X-IronPort-AV: E=Sophos;i="4.43,356,1246838400"; d="scan'208";a="194241407" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 10 Aug 2009 22:44:22 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7AMiMti016458; Mon, 10 Aug 2009 15:44:22 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7AMiKGA028709; Mon, 10 Aug 2009 22:44:22 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 18:44:20 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 18:44:19 -0400 Message-ID: <4A80A2C4.4090408@cisco.com> Date: Mon, 10 Aug 2009 18:44:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Deepanshu Gautam References: <012201ca1969$acf94c00$4056a80a@china.huawei.com> In-Reply-To: <012201ca1969$acf94c00$4056a80a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2009 22:44:19.0794 (UTC) FILETIME=[192F4B20:01CA1A0C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1795; t=1249944262; x=1250808262; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20New=20IM-specific=20feature |Sender:=20; bh=cktjFYmUgiTRaKHTWQBOd/YgorVNNWdBTl1B88ydGnU=; b=wET+O1apjYRGge9YKTpzQgnkevqE4/U3VhyxlRvXHN6StrbeU7rIgZ4erl 2CmFqQnDhQ+R3R3+Hw+g+mDSlzFrqxNQ/yJH3qlg868l68GQoTa6+W55CKfE qUgrJqDuJ7; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Simple WG Subject: Re: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 22:44:25 -0000 Inline... Deepanshu Gautam wrote: > Dear All, > > I would like to propose a new IM-specific feature for SIMPLE, which i > would call as "Quick Answer(QA)". Allow me to explain about it briefly. > > In instant messaging system, it is useful to have some readily available > IM (text, audio or video) which can be sent in case of the receiver is > too busy to type/speak/record for a reply. User can create and store IM > (QA) using a particular client device and can use them when required. > Creating and then storing on a single device may not be very useful > because user can log-in a particular IM system using different client > devices at different point of time. In that case QA created using one > client device will not be available to another client device. > > I would like to propose a draft to solve this problem and perform the > needed standardization, which will further make this IM-feature > possible. Before moving forward I would like to get some initial comment > from the group about this idea. You comments would be valuable. Where do you imagine this new state would be stored? And who/what would use it? Are you proposing a "database" that is shared by the various UAs for an AOR, that they would each update and retrieve from? Would the sending of the answer still depend on a UA receiving the message? Or do you expect that the answer will be sent even if there is no UA registered? IMO this doesn't fit well with the simple model. Thanks, Paul > Regards > Deepanshu Gautam > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Mon Aug 10 20:29:41 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E0C3A6C26 for ; Mon, 10 Aug 2009 20:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJrDDny+q9hW for ; Mon, 10 Aug 2009 20:29:40 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 6EEB828C147 for ; Mon, 10 Aug 2009 20:29:07 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-28-173.dsl.rcsntx.swbell.net [68.94.28.173]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7B3QqLg041478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 22:26:52 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <99BA10DF-E192-4300-B3BE-D18F5CE8D0A6@nostrum.com> From: Ben Campbell To: Deepanshu Gautam , Simple WG In-Reply-To: <4A80A2C4.4090408@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 22:26:47 -0500 References: <012201ca1969$acf94c00$4056a80a@china.huawei.com> <4A80A2C4.4090408@cisco.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 68.94.28.173 is authenticated by a trusted mechanism) Cc: Paul Kyzivat Subject: Re: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 03:29:41 -0000 (as individual) I concur with Paul's opinion (and questions). To expand a bit, while I have seen some IM systems with this function, its utility seems weak in a _presence_ and IM system. That is, the sort of information one might put into a QA is better communicated as part of presence state. IMO, this sort of thing is exactly what the presence distribution mechanism was designed for. On Aug 10, 2009, at 5:44 PM, Paul Kyzivat wrote: > Inline... > > Deepanshu Gautam wrote: >> Dear All, >> >> I would like to propose a new IM-specific feature for SIMPLE, which i >> would call as "Quick Answer(QA)". Allow me to explain about it >> briefly. >> >> In instant messaging system, it is useful to have some readily >> available >> IM (text, audio or video) which can be sent in case of the receiver >> is >> too busy to type/speak/record for a reply. User can create and >> store IM >> (QA) using a particular client device and can use them when required. >> Creating and then storing on a single device may not be very useful >> because user can log-in a particular IM system using different client >> devices at different point of time. In that case QA created using one >> client device will not be available to another client device. >> >> I would like to propose a draft to solve this problem and perform the >> needed standardization, which will further make this IM-feature >> possible. Before moving forward I would like to get some initial >> comment >> from the group about this idea. You comments would be valuable. > > Where do you imagine this new state would be stored? > And who/what would use it? > > Are you proposing a "database" that is shared by the various UAs for > an > AOR, that they would each update and retrieve from? > > Would the sending of the answer still depend on a UA receiving the > message? Or do you expect that the answer will be sent even if there > is > no UA registered? > > IMO this doesn't fit well with the simple model. > > Thanks, > Paul > >> Regards >> Deepanshu Gautam >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 deepanshu@huawei.com Mon Aug 10 22:16:29 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95D83A69EC for ; Mon, 10 Aug 2009 22:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.298 X-Spam-Level: *** X-Spam-Status: No, score=3.298 tagged_above=-999 required=5 tests=[AWL=3.792, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQW9RuFxHH0o for ; Mon, 10 Aug 2009 22:16:29 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D823A3A6BE9 for ; Mon, 10 Aug 2009 22:16:28 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO700J0W57JBP@szxga04-in.huawei.com> for simple@ietf.org; Tue, 11 Aug 2009 13:14:08 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO700EV257J8Z@szxga04-in.huawei.com> for simple@ietf.org; Tue, 11 Aug 2009 13:14:07 +0800 (CST) Received: from d57531v ([10.168.86.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO700DWV57JO7@szxml04-in.huawei.com> for simple@ietf.org; Tue, 11 Aug 2009 13:14:07 +0800 (CST) Date: Tue, 11 Aug 2009 13:14:07 +0800 From: Deepanshu Gautam To: Paul Kyzivat Message-id: <011101ca1a42$8d6ff990$4056a80a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <012201ca1969$acf94c00$4056a80a@china.huawei.com> <4A80A2C4.4090408@cisco.com> Cc: Simple WG Subject: Re: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 05:16:29 -0000 inline with [DG] ----- Original Message ----- From: "Paul Kyzivat" To: "Deepanshu Gautam" Cc: "Simple WG" Sent: Tuesday, August 11, 2009 6:44 AM Subject: Re: [Simple] New IM-specific feature > Inline... > > Deepanshu Gautam wrote: >> Dear All, >> >> I would like to propose a new IM-specific feature for SIMPLE, which i >> would call as "Quick Answer(QA)". Allow me to explain about it briefly. >> >> In instant messaging system, it is useful to have some readily available >> IM (text, audio or video) which can be sent in case of the receiver is >> too busy to type/speak/record for a reply. User can create and store IM >> (QA) using a particular client device and can use them when required. >> Creating and then storing on a single device may not be very useful >> because user can log-in a particular IM system using different client >> devices at different point of time. In that case QA created using one >> client device will not be available to another client device. >> >> I would like to propose a draft to solve this problem and perform the >> needed standardization, which will further make this IM-feature >> possible. Before moving forward I would like to get some initial comment >> from the group about this idea. You comments would be valuable. > > Where do you imagine this new state would be stored? > And who/what would use it? [DG] I don't see this as a new state (if you are referring to IM user state like "ideal", "active" defined in 3994). Irrespective of state, the only concerns here is that "an IM is received and user would like to select from a list of messages (here QA) as reply to that IM". Problem to solve: how to create and make that list of messages avaliable on various UAs. I foresee these QA to be stored both on server and UA.[/DG] > > Are you proposing a "database" that is shared by the various UAs for an > AOR, that they would each update and retrieve from? [DG]No, Actually i'm proposing protocol(s) to make that kind of database avaliable[/DG] > Would the sending of the answer still depend on a UA receiving the > message? Or do you expect that the answer will be sent even if there is > no UA registered? [DG] According to me, till now, it depends on UA receiving the message. But, it may be other way round too, if we have feasible usecase/requirement.[/DG] > > IMO this doesn't fit well with the simple model. > > Thanks, > Paul > >> Regards >> Deepanshu Gautam >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple From root@core3.amsl.com Tue Aug 11 00:30:01 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3E9EF3A6A0F; Tue, 11 Aug 2009 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090811073001.3E9EF3A6A0F@core3.amsl.com> Date: Tue, 11 Aug 2009 00:30:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-msrp-acm-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 07:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Alternative Connection Model for the Message Session Relay Protocol (MSRP) Author(s) : C. Holmberg, S. Blau Filename : draft-ietf-simple-msrp-acm-01.txt Pages : 9 Date : 2009-08-11 This document defines an alternative connection model for MSRP UAs. The model differs from the standard MSRP model, as defined in RFC4975 and RFC4976 in the following ways: it uses COMEDIA for TCP connection establishment, and it allows the usage of SDP in a more conventional way for conveying endpoint address information. Because of this, the model also allows for the usage of generic mainstream mechanisms for NAT traversal, instead of using MSRP relays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-msrp-acm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-11001547.I-D@ietf.org> --NextPart-- From deepanshu@huawei.com Tue Aug 11 02:28:04 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1061F3A6CEA for ; Tue, 11 Aug 2009 02:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.645 X-Spam-Level: *** X-Spam-Status: No, score=3.645 tagged_above=-999 required=5 tests=[AWL=2.939, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_19=0.6, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyk-1FbQ+XX3 for ; Tue, 11 Aug 2009 02:28:03 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C098A3A684D for ; Tue, 11 Aug 2009 02:27:57 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO700DDXGY94N@szxga04-in.huawei.com> for simple@ietf.org; Tue, 11 Aug 2009 17:27:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO7005F7GY9WM@szxga04-in.huawei.com> for simple@ietf.org; Tue, 11 Aug 2009 17:27:45 +0800 (CST) Received: from d57531v ([10.168.86.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO700LTJGY9C0@szxml04-in.huawei.com> for simple@ietf.org; Tue, 11 Aug 2009 17:27:45 +0800 (CST) Date: Tue, 11 Aug 2009 17:27:45 +0800 From: Deepanshu Gautam To: Ben Campbell , Simple WG Message-id: <019e01ca1a65$fbf5a7c0$4056a80a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <012201ca1969$acf94c00$4056a80a@china.huawei.com> <4A80A2C4.4090408@cisco.com> <99BA10DF-E192-4300-B3BE-D18F5CE8D0A6@nostrum.com> Cc: Paul Kyzivat Subject: Re: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 09:28:04 -0000 I can foresee some disadvantage of using Presence for this as follows. 1. Adds more overhead as an explicit and periodic subscription is required (i.e Events and extension to presence). 2. Presence fits situation where IM sender (as watcher) gets information about IM recipient (as presentity), here the situation is reverse. 3. Will not allow user to choose from different option (QA) avaliable in real-time. 4. I may want to send some QA to those who are not my 'watchers' (because they don't care about my presence information) but v.important to me e.g HR delegate from a probable employer :-) 5. For page-mode delivery, subscribing to the right user agent and set of messages may not be easy. We can consider these QA somewhat analogous to multimedia message-templates in current messaging(SMS, MMS, ...) system which is usefull and widely used. User can themselves create them for future use. Regards Deepanshu ----- Original Message ----- From: "Ben Campbell" To: "Deepanshu Gautam" ; "Simple WG" Cc: "Paul Kyzivat" Sent: Tuesday, August 11, 2009 11:26 AM Subject: Re: [Simple] New IM-specific feature > (as individual) > > I concur with Paul's opinion (and questions). > > To expand a bit, while I have seen some IM systems with this function, > its utility seems weak in a _presence_ and IM system. That is, the sort > of information one might put into a QA is better communicated as part of > presence state. IMO, this sort of thing is exactly what the presence > distribution mechanism was designed for. > > > On Aug 10, 2009, at 5:44 PM, Paul Kyzivat wrote: > >> Inline... >> >> Deepanshu Gautam wrote: >>> Dear All, >>> >>> I would like to propose a new IM-specific feature for SIMPLE, which i >>> would call as "Quick Answer(QA)". Allow me to explain about it briefly. >>> >>> In instant messaging system, it is useful to have some readily >>> available >>> IM (text, audio or video) which can be sent in case of the receiver is >>> too busy to type/speak/record for a reply. User can create and store IM >>> (QA) using a particular client device and can use them when required. >>> Creating and then storing on a single device may not be very useful >>> because user can log-in a particular IM system using different client >>> devices at different point of time. In that case QA created using one >>> client device will not be available to another client device. >>> >>> I would like to propose a draft to solve this problem and perform the >>> needed standardization, which will further make this IM-feature >>> possible. Before moving forward I would like to get some initial >>> comment >>> from the group about this idea. You comments would be valuable. >> >> Where do you imagine this new state would be stored? >> And who/what would use it? >> >> Are you proposing a "database" that is shared by the various UAs for an >> AOR, that they would each update and retrieve from? >> >> Would the sending of the answer still depend on a UA receiving the >> message? Or do you expect that the answer will be sent even if there is >> no UA registered? >> >> IMO this doesn't fit well with the simple model. >> >> Thanks, >> Paul >> >>> Regards >>> Deepanshu Gautam >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 Markus.Isomaki@nokia.com Tue Aug 11 03:08:38 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220693A705E for ; Tue, 11 Aug 2009 03:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzU99STl+0wk for ; Tue, 11 Aug 2009 03:08:37 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 5465B3A7033 for ; Tue, 11 Aug 2009 03:08:37 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7BA71Co008348; Tue, 11 Aug 2009 05:08:16 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 13:08:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 13:08:13 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 11 Aug 2009 12:08:03 +0200 From: To: , Date: Tue, 11 Aug 2009 12:08:02 +0200 Thread-Topic: [Simple] simple-chat status Thread-Index: AcoXnqaVFYB++mrfQouoqQOfXxZVfACye/9w Message-ID: References: <75E88CE8-C457-4E69-BCC8-3867F14611A2@estacado.net><3FEAC3FB-741A-4002-AFA9-09F29FBA709D@nostrum.com> <4A798F14.5010201@tandberg.com> <1ECE0EB50388174790F9694F77522CCF1F59F699@zrc2hxm0.corp.nortel.com> <0770C27A-65E3-42EA-86D8-F3C416E212D1@nostrum.com> In-Reply-To: <0770C27A-65E3-42EA-86D8-F3C416E212D1@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Aug 2009 10:08:13.0878 (UTC) FILETIME=[A3679D60:01CA1A6B] X-Nokia-AV: Clean Cc: geir.sandbakken@tandberg.com, simple@ietf.org Subject: Re: [Simple] simple-chat status X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 10:08:38 -0000 Hi, I agree that there hasn't been a great interest for simple-chat lately. But= I'm not sure if there is any more interest for XCON-based chat either. See= more inline. =20 Ben Campbell wrote: > >1. Have you or do you plan to implement simple-chat? Or are=20 >you aware of other's work in this area? (Adrian pointed to one=20 >implementation so >far.) Actually, I'm not sure. To my understanding there are implementations of OM= A/GSMA version of simple-chat, and at least some customers are asking for t= his. (This is BTW roughly the same set of customers that would be intested = in MSRP-ACM, i.e. the ones that are planning to deploy the GSMA Rich Commun= ication Suite (RCS) service, where MSRP is used for 1-to-and and multiparty= IM and file transfer.) What is unclear to me is whether those implementati= ons would want to follow IETF's simple-chat should that ever complete. Most= likely the adaptation would be technically quite easy. > >2. If you answered yes to 1., if the XCON framework and CCMP=20 >were complete_today_, would your answer to 1 change? > >3. If _both_ simple-chat and XCON/CCMP were complete _today_,=20 >would your answer to 1 change? > I admit I should go and read the related XCON specs before saying anything.= But what I'm worried about them is whether they are merely a set of baseli= nes and frameworks or do they actually define all the details that are need= ed for interoperable implementations.=20 Is there anyone who has tried to implement MSRP chat with the XCON specs? I= t would be nice to get their feedback. Markus= From pkyzivat@cisco.com Tue Aug 11 05:57:43 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9583A70DC for ; Tue, 11 Aug 2009 05:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IO7GCpZ9T1f for ; Tue, 11 Aug 2009 05:57:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A3D0B3A70E5 for ; Tue, 11 Aug 2009 05:57:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPMHgUqrR7PD/2dsb2JhbAC5UYZkgUeQEwWBLoIjSIIi X-IronPort-AV: E=Sophos;i="4.43,360,1246838400"; d="scan'208";a="365001454" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2009 12:57:25 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7BCvPPS017614; Tue, 11 Aug 2009 05:57:25 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7BCvNhQ003138; Tue, 11 Aug 2009 12:57:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:57:24 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:57:23 -0400 Message-ID: <4A816AB3.3000305@cisco.com> Date: Tue, 11 Aug 2009 08:57:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Deepanshu Gautam References: <012201ca1969$acf94c00$4056a80a@china.huawei.com> <4A80A2C4.4090408@cisco.com> <011101ca1a42$8d6ff990$4056a80a@china.huawei.com> In-Reply-To: <011101ca1a42$8d6ff990$4056a80a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2009 12:57:23.0512 (UTC) FILETIME=[450EDB80:01CA1A83] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3991; t=1249995445; x=1250859445; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20New=20IM-specific=20feature |Sender:=20; bh=jT3xbdCuAP+gacqcftMP9MfsTOAC/v31+WjNbxN0EE8=; b=rXdH6j55yfxEpmdd4gVsmrN5M1/LEKNTr2Hbb2NXDN6wfZEXCQ8WFK4Jff KskLWoucjrp01DouCVSAfaE/LNswlgTClNrLBmxvlf8XWwJ6+CewQRYaJThV 4Wxao7YCUW; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Simple WG Subject: Re: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 12:57:43 -0000 Deepanshu Gautam wrote: > inline with [DG] > ----- Original Message ----- From: "Paul Kyzivat" > To: "Deepanshu Gautam" > Cc: "Simple WG" > Sent: Tuesday, August 11, 2009 6:44 AM > Subject: Re: [Simple] New IM-specific feature > > >> Inline... >> >> Deepanshu Gautam wrote: >>> Dear All, >>> >>> I would like to propose a new IM-specific feature for SIMPLE, which i >>> would call as "Quick Answer(QA)". Allow me to explain about it briefly. >>> >>> In instant messaging system, it is useful to have some readily available >>> IM (text, audio or video) which can be sent in case of the receiver is >>> too busy to type/speak/record for a reply. User can create and store IM >>> (QA) using a particular client device and can use them when required. >>> Creating and then storing on a single device may not be very useful >>> because user can log-in a particular IM system using different client >>> devices at different point of time. In that case QA created using one >>> client device will not be available to another client device. >>> >>> I would like to propose a draft to solve this problem and perform the >>> needed standardization, which will further make this IM-feature >>> possible. Before moving forward I would like to get some initial comment >>> from the group about this idea. You comments would be valuable. >> >> Where do you imagine this new state would be stored? >> And who/what would use it? > [DG] I don't see this as a new state (if you are referring to IM user state > like "ideal", "active" defined in 3994). Irrespective of state, the only > concerns here is that "an IM is received and user would like to select from > a list of messages (here QA) as reply to that IM". Problem to solve: how > to create and make that list of messages avaliable on various UAs. > I foresee these QA to be stored both on server and UA.[/DG] Which server? The registrar? IIUC you are then just proposing that the registrar provide storage for attributes that the various UAs registering to an AOR would share? That is a very slippery slope, since there are many pieces of state/configuration that UAs might like to store or share. >> Are you proposing a "database" that is shared by the various UAs for an >> AOR, that they would each update and retrieve from? > [DG]No, Actually i'm proposing protocol(s) to make that kind of database > avaliable[/DG] This is especially ugly when it calls for specific protocol additions to SIP to maintain each piece of such state that comes along. This sounds much more like provisioning information, to be maintained by a provisioning server and made available to the controlled devices. >> Would the sending of the answer still depend on a UA receiving the >> message? Or do you expect that the answer will be sent even if there is >> no UA registered? > [DG] According to me, till now, it depends on UA receiving the message. > But, > it may be other way round too, if we have feasible > usecase/requirement.[/DG] If you go that way, it becomes much more like a voicemail system. (In this case, a "IM-mail" system.) Namely it is a UA of last resort for responding to incoming requests if no other UA does. Its not really part of a registrar, though it *might* be collocated with one. This is not an unreasonable thing to do - its pretty common. But so far there have been no proposals to standardize anything about this as part of SIMPLE. (Nor have there been any to standardize voicemail systems.) Thanks, Paul >> IMO this doesn't fit well with the simple model. >> >> Thanks, >> Paul >> >>> Regards >>> Deepanshu Gautam >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple > > From deepanshu@huawei.com Wed Aug 12 00:58:31 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779283A6A47 for ; Wed, 12 Aug 2009 00:58:31 -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, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc2llhmUoSWe for ; Wed, 12 Aug 2009 00:58:30 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [58.251.152.67]) by core3.amsl.com (Postfix) with ESMTP id 09BD33A6AEB for ; Wed, 12 Aug 2009 00:58:30 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO900AF65FKWA@szxga04-in.huawei.com> for simple@ietf.org; Wed, 12 Aug 2009 15:14:08 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO9004MG5FKT1@szxga04-in.huawei.com> for simple@ietf.org; Wed, 12 Aug 2009 15:14:08 +0800 (CST) Received: from d57531v ([10.168.86.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO900M9P5FKEB@szxml06-in.huawei.com> for simple@ietf.org; Wed, 12 Aug 2009 15:14:08 +0800 (CST) Date: Wed, 12 Aug 2009 15:14:11 +0800 From: Deepanshu Gautam To: Paul Kyzivat Message-id: <011101ca1b1c$7e2ca610$4056a80a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <012201ca1969$acf94c00$4056a80a@china.huawei.com> <4A80A2C4.4090408@cisco.com> <011101ca1a42$8d6ff990$4056a80a@china.huawei.com> <4A816AB3.3000305@cisco.com> Cc: Simple WG Subject: Re: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 07:58:31 -0000 When i say "protocols" i only mean to define a new XML schema (to carry QA as instance of it) and a content-type (for labelling that QA), thats it. I don't see any thing ugly in that. It has been done for other two IM-specific feature already. I can agree with you on bit of a relation between QA and what you call "IM-mail" and would like to consider it further. However, i can think of a prominent difference i.e "IM-mail" will not allow user to choose from the avaliable options in real time (i.e when it has received an IM) About storage, i think that would not be on registrar. Can we consider storage of QA as implementation specific? We just provide a mechanism (XML schema/content-type) to deliver QA between two entities. How to store them will be implementation specific. Some IM application server (e.g OMA IM-XDMS) or provisioning server can do that. Will that make sense? Regards Deepanshu ----- Original Message ----- From: "Paul Kyzivat" To: "Deepanshu Gautam" Cc: "Simple WG" Sent: Tuesday, August 11, 2009 8:57 PM Subject: Re: [Simple] New IM-specific feature > > > Deepanshu Gautam wrote: >> inline with [DG] >> ----- Original Message ----- From: "Paul Kyzivat" >> To: "Deepanshu Gautam" >> Cc: "Simple WG" >> Sent: Tuesday, August 11, 2009 6:44 AM >> Subject: Re: [Simple] New IM-specific feature >> >> >>> Inline... >>> >>> Deepanshu Gautam wrote: >>>> Dear All, >>>> >>>> I would like to propose a new IM-specific feature for SIMPLE, which i >>>> would call as "Quick Answer(QA)". Allow me to explain about it briefly. >>>> >>>> In instant messaging system, it is useful to have some readily >>>> available >>>> IM (text, audio or video) which can be sent in case of the receiver is >>>> too busy to type/speak/record for a reply. User can create and store IM >>>> (QA) using a particular client device and can use them when required. >>>> Creating and then storing on a single device may not be very useful >>>> because user can log-in a particular IM system using different client >>>> devices at different point of time. In that case QA created using one >>>> client device will not be available to another client device. >>>> >>>> I would like to propose a draft to solve this problem and perform the >>>> needed standardization, which will further make this IM-feature >>>> possible. Before moving forward I would like to get some initial >>>> comment >>>> from the group about this idea. You comments would be valuable. >>> >>> Where do you imagine this new state would be stored? >>> And who/what would use it? >> [DG] I don't see this as a new state (if you are referring to IM user >> state >> like "ideal", "active" defined in 3994). Irrespective of state, the only >> concerns here is that "an IM is received and user would like to select >> from >> a list of messages (here QA) as reply to that IM". Problem to solve: how >> to create and make that list of messages avaliable on various UAs. >> I foresee these QA to be stored both on server and UA.[/DG] > > Which server? The registrar? > > IIUC you are then just proposing that the registrar provide storage for > attributes that the various UAs registering to an AOR would share? > > That is a very slippery slope, since there are many pieces of > state/configuration that UAs might like to store or share. > >>> Are you proposing a "database" that is shared by the various UAs for an >>> AOR, that they would each update and retrieve from? >> [DG]No, Actually i'm proposing protocol(s) to make that kind of database >> avaliable[/DG] > > This is especially ugly when it calls for specific protocol additions to > SIP to maintain each piece of such state that comes along. > > This sounds much more like provisioning information, to be maintained by > a provisioning server and made available to the controlled devices. > >>> Would the sending of the answer still depend on a UA receiving the >>> message? Or do you expect that the answer will be sent even if there is >>> no UA registered? >> [DG] According to me, till now, it depends on UA receiving the message. >> But, >> it may be other way round too, if we have feasible >> usecase/requirement.[/DG] > > If you go that way, it becomes much more like a voicemail system. > (In this case, a "IM-mail" system.) Namely it is a UA of last resort for > responding to incoming requests if no other UA does. Its not really part > of a registrar, though it *might* be collocated with one. > > This is not an unreasonable thing to do - its pretty common. But so far > there have been no proposals to standardize anything about this as part > of SIMPLE. (Nor have there been any to standardize voicemail systems.) > > Thanks, > Paul > >>> IMO this doesn't fit well with the simple model. >>> >>> Thanks, >>> Paul >>> >>>> Regards >>>> Deepanshu Gautam >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >> >> From pkyzivat@cisco.com Wed Aug 12 06:50:25 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E0B3A6B50 for ; Wed, 12 Aug 2009 06:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYHc5Uks6F-O for ; Wed, 12 Aug 2009 06:50:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 022AC3A6B5B for ; Wed, 12 Aug 2009 06:50:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK1lgkqrR7PE/2dsb2JhbAC5I4ZkgUeRDQWBLoIjSIIi X-IronPort-AV: E=Sophos;i="4.43,367,1246838400"; d="scan'208";a="226927463" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2009 13:49:21 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7CDnLXW024846; Wed, 12 Aug 2009 06:49:21 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7CDnLXr015957; Wed, 12 Aug 2009 13:49:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:49:21 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:49:20 -0400 Message-ID: <4A82C85F.8030007@cisco.com> Date: Wed, 12 Aug 2009 09:49:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Deepanshu Gautam References: <012201ca1969$acf94c00$4056a80a@china.huawei.com> <4A80A2C4.4090408@cisco.com> <011101ca1a42$8d6ff990$4056a80a@china.huawei.com> <4A816AB3.3000305@cisco.com> <011101ca1b1c$7e2ca610$4056a80a@china.huawei.com> In-Reply-To: <011101ca1b1c$7e2ca610$4056a80a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Aug 2009 13:49:20.0665 (UTC) FILETIME=[B1706890:01CA1B53] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6484; t=1250084961; x=1250948961; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20New=20IM-specific=20feature |Sender:=20; bh=eRVuZN9lgjMZFjxmxRhK7sphmahj1cPRx44dJjb7C8E=; b=V++cWlGXWjk6DRMSy1hj6V9xdVCUv6aJl0nOfv523OvDW+S4YQLDPImZoU SbWI1BfwhaaJnqNDOyW+7UaaSPb0WtvtFj/w66tk+G7GiedU8v0URNuyIPcH a1oLi4xXpf; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Simple WG Subject: Re: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 13:50:25 -0000 Deepanshu Gautam wrote: > When i say "protocols" i only mean to define a new XML schema (to carry > QA as instance of it) and a content-type (for labelling that QA), thats > it. I don't see any thing ugly in that. It has been done for other two > IM-specific feature already. I hadn't realized you wanted to carry this info in a body part. But then you would need to specify in which messages it is conveyed, and what the semantics are of including it in those messages. What did you have in mind? Were you thinking of using REGISTER and its response to convey this? Or were you going to send this in a MESSAGE? > I can agree with you on bit of a relation between QA and what you call > "IM-mail" and would like to consider it further. However, i can think of > a prominent difference i.e "IM-mail" will not allow user to choose from > the avaliable options in real time (i.e when it has received an IM) > > About storage, i think that would not be on registrar. Can we consider > storage of QA as implementation specific? We just provide a mechanism > (XML schema/content-type) to deliver QA between two entities. How to > store them will be implementation specific. Some IM application server > (e.g OMA IM-XDMS) or provisioning server can do that. Will that make sense? The problem is that you have to pass the data in some message, and have some reason to believe it will be received by something that will process it as you expect. That implies some level of standardization of the behavior. (The long history of trouble with INFO is testament to what happens if you don't address such issues.) If I am to send the info in REGISTER, then I am counting on some behavior by the registrar to do something with it. Its even more important if I expect the *response* to the REGISTER to give me such data! I still think this sounds like a provisioning problem. Thanks, Paul > Regards > Deepanshu > > ----- Original Message ----- From: "Paul Kyzivat" > To: "Deepanshu Gautam" > Cc: "Simple WG" > Sent: Tuesday, August 11, 2009 8:57 PM > Subject: Re: [Simple] New IM-specific feature > > >> >> >> Deepanshu Gautam wrote: >>> inline with [DG] >>> ----- Original Message ----- From: "Paul Kyzivat" >>> To: "Deepanshu Gautam" >>> Cc: "Simple WG" >>> Sent: Tuesday, August 11, 2009 6:44 AM >>> Subject: Re: [Simple] New IM-specific feature >>> >>> >>>> Inline... >>>> >>>> Deepanshu Gautam wrote: >>>>> Dear All, >>>>> >>>>> I would like to propose a new IM-specific feature for SIMPLE, which i >>>>> would call as "Quick Answer(QA)". Allow me to explain about it >>>>> briefly. >>>>> >>>>> In instant messaging system, it is useful to have some readily >>>>> available >>>>> IM (text, audio or video) which can be sent in case of the receiver is >>>>> too busy to type/speak/record for a reply. User can create and >>>>> store IM >>>>> (QA) using a particular client device and can use them when required. >>>>> Creating and then storing on a single device may not be very useful >>>>> because user can log-in a particular IM system using different client >>>>> devices at different point of time. In that case QA created using one >>>>> client device will not be available to another client device. >>>>> >>>>> I would like to propose a draft to solve this problem and perform the >>>>> needed standardization, which will further make this IM-feature >>>>> possible. Before moving forward I would like to get some initial >>>>> comment >>>>> from the group about this idea. You comments would be valuable. >>>> >>>> Where do you imagine this new state would be stored? >>>> And who/what would use it? >>> [DG] I don't see this as a new state (if you are referring to IM user >>> state >>> like "ideal", "active" defined in 3994). Irrespective of state, the only >>> concerns here is that "an IM is received and user would like to >>> select from >>> a list of messages (here QA) as reply to that IM". Problem to solve: how >>> to create and make that list of messages avaliable on various UAs. >>> I foresee these QA to be stored both on server and UA.[/DG] >> >> Which server? The registrar? >> >> IIUC you are then just proposing that the registrar provide storage for >> attributes that the various UAs registering to an AOR would share? >> >> That is a very slippery slope, since there are many pieces of >> state/configuration that UAs might like to store or share. >> >>>> Are you proposing a "database" that is shared by the various UAs for an >>>> AOR, that they would each update and retrieve from? >>> [DG]No, Actually i'm proposing protocol(s) to make that kind of database >>> avaliable[/DG] >> >> This is especially ugly when it calls for specific protocol additions to >> SIP to maintain each piece of such state that comes along. >> >> This sounds much more like provisioning information, to be maintained by >> a provisioning server and made available to the controlled devices. >> >>>> Would the sending of the answer still depend on a UA receiving the >>>> message? Or do you expect that the answer will be sent even if there is >>>> no UA registered? >>> [DG] According to me, till now, it depends on UA receiving the message. >>> But, >>> it may be other way round too, if we have feasible >>> usecase/requirement.[/DG] >> >> If you go that way, it becomes much more like a voicemail system. >> (In this case, a "IM-mail" system.) Namely it is a UA of last resort for >> responding to incoming requests if no other UA does. Its not really part >> of a registrar, though it *might* be collocated with one. >> >> This is not an unreasonable thing to do - its pretty common. But so far >> there have been no proposals to standardize anything about this as part >> of SIMPLE. (Nor have there been any to standardize voicemail systems.) >> >> Thanks, >> Paul >> >>>> IMO this doesn't fit well with the simple model. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards >>>>> Deepanshu Gautam >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>> >>> > > From deepanshu@huawei.com Thu Aug 13 22:52:46 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F853A6BD8 for ; Thu, 13 Aug 2009 22:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.739 X-Spam-Level: ** X-Spam-Status: No, score=2.739 tagged_above=-999 required=5 tests=[AWL=3.478, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcgjehjs0wij for ; Thu, 13 Aug 2009 22:52:45 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 28E2F3A6907 for ; Thu, 13 Aug 2009 22:52:44 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOC00BCFQHT0K@szxga01-in.huawei.com> for simple@ietf.org; Fri, 14 Aug 2009 13:41:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOC00263QHTJK@szxga01-in.huawei.com> for simple@ietf.org; Fri, 14 Aug 2009 13:41:53 +0800 (CST) Received: from d57531v ([10.168.86.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOC001ILQHSUC@szxml04-in.huawei.com> for simple@ietf.org; Fri, 14 Aug 2009 13:41:53 +0800 (CST) Date: Fri, 14 Aug 2009 13:41:52 +0800 From: Deepanshu Gautam To: Paul Kyzivat Message-id: <001a01ca1ca1$ed55dc60$4056a80a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <012201ca1969$acf94c00$4056a80a@china.huawei.com> <4A80A2C4.4090408@cisco.com> <011101ca1a42$8d6ff990$4056a80a@china.huawei.com> <4A816AB3.3000305@cisco.com> <011101ca1b1c$7e2ca610$4056a80a@china.huawei.com> <4A82C85F.8030007@cisco.com> Cc: Simple WG Subject: Re: [Simple] New IM-specific feature X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 05:52:46 -0000 ----- Original Message ----- From: "Paul Kyzivat" To: "Deepanshu Gautam" Cc: "Simple WG" Sent: Wednesday, August 12, 2009 9:49 PM Subject: Re: [Simple] New IM-specific feature > > > Deepanshu Gautam wrote: >> When i say "protocols" i only mean to define a new XML schema (to carry >> QA as instance of it) and a content-type (for labelling that QA), thats >> it. I don't see any thing ugly in that. It has been done for other two >> IM-specific feature already. > > I hadn't realized you wanted to carry this info in a body part. > > But then you would need to specify in which messages it is conveyed, and > what the semantics are of including it in those messages. What did you > have in mind? Were you thinking of using REGISTER and its response to > convey this? Or were you going to send this in a MESSAGE? [DG] The MESSAGE is what i have in my mind. > >> I can agree with you on bit of a relation between QA and what you call >> "IM-mail" and would like to consider it further. However, i can think of >> a prominent difference i.e "IM-mail" will not allow user to choose from >> the avaliable options in real time (i.e when it has received an IM) >> >> About storage, i think that would not be on registrar. Can we consider >> storage of QA as implementation specific? We just provide a mechanism >> (XML schema/content-type) to deliver QA between two entities. How to >> store them will be implementation specific. Some IM application server >> (e.g OMA IM-XDMS) or provisioning server can do that. Will that make >> sense? > > The problem is that you have to pass the data in some message, and have > some reason to believe it will be received by something that will > process it as you expect. That implies some level of standardization of > the behavior. > > (The long history of trouble with INFO is testament to what happens if > you don't address such issues.) > > If I am to send the info in REGISTER, then I am counting on some > behavior by the registrar to do something with it. Its even more > important if I expect the *response* to the REGISTER to give me such data! [DG] Let me go 1 step further in explanation I would divide the whole work to be done in two steps. 1. QA creation - Here the QAs are created by UA 2. QA Usage - Here a QA is selected by UA from the avaliable list of UAs. In step 1 UA will create QA and send to something (lets call it as QA Storer). This QA storer will be implementation specific. We *will* standardize the behaviour of this QA storer to *some extent* (leaving scope for addition). It may be further implemented by other standard organization like OMA. Step 2 will be straight forward: delivery of QA from QA Sender to QA Receiver using XML schema in MESSAGE body. Is this sounds feasible to you? Something which SIMPLE can do? > I still think this sounds like a provisioning problem. > > Thanks, > Paul > >> Regards >> Deepanshu >> >> ----- Original Message ----- From: "Paul Kyzivat" >> To: "Deepanshu Gautam" >> Cc: "Simple WG" >> Sent: Tuesday, August 11, 2009 8:57 PM >> Subject: Re: [Simple] New IM-specific feature >> >> >>> >>> >>> Deepanshu Gautam wrote: >>>> inline with [DG] >>>> ----- Original Message ----- From: "Paul Kyzivat" >>>> To: "Deepanshu Gautam" >>>> Cc: "Simple WG" >>>> Sent: Tuesday, August 11, 2009 6:44 AM >>>> Subject: Re: [Simple] New IM-specific feature >>>> >>>> >>>>> Inline... >>>>> >>>>> Deepanshu Gautam wrote: >>>>>> Dear All, >>>>>> >>>>>> I would like to propose a new IM-specific feature for SIMPLE, which i >>>>>> would call as "Quick Answer(QA)". Allow me to explain about it >>>>>> briefly. >>>>>> >>>>>> In instant messaging system, it is useful to have some readily >>>>>> available >>>>>> IM (text, audio or video) which can be sent in case of the receiver >>>>>> is >>>>>> too busy to type/speak/record for a reply. User can create and >>>>>> store IM >>>>>> (QA) using a particular client device and can use them when required. >>>>>> Creating and then storing on a single device may not be very useful >>>>>> because user can log-in a particular IM system using different client >>>>>> devices at different point of time. In that case QA created using one >>>>>> client device will not be available to another client device. >>>>>> >>>>>> I would like to propose a draft to solve this problem and perform the >>>>>> needed standardization, which will further make this IM-feature >>>>>> possible. Before moving forward I would like to get some initial >>>>>> comment >>>>>> from the group about this idea. You comments would be valuable. >>>>> >>>>> Where do you imagine this new state would be stored? >>>>> And who/what would use it? >>>> [DG] I don't see this as a new state (if you are referring to IM user >>>> state >>>> like "ideal", "active" defined in 3994). Irrespective of state, the >>>> only >>>> concerns here is that "an IM is received and user would like to >>>> select from >>>> a list of messages (here QA) as reply to that IM". Problem to solve: >>>> how >>>> to create and make that list of messages avaliable on various UAs. >>>> I foresee these QA to be stored both on server and UA.[/DG] >>> >>> Which server? The registrar? >>> >>> IIUC you are then just proposing that the registrar provide storage for >>> attributes that the various UAs registering to an AOR would share? >>> >>> That is a very slippery slope, since there are many pieces of >>> state/configuration that UAs might like to store or share. >>> >>>>> Are you proposing a "database" that is shared by the various UAs for >>>>> an >>>>> AOR, that they would each update and retrieve from? >>>> [DG]No, Actually i'm proposing protocol(s) to make that kind of >>>> database >>>> avaliable[/DG] >>> >>> This is especially ugly when it calls for specific protocol additions to >>> SIP to maintain each piece of such state that comes along. >>> >>> This sounds much more like provisioning information, to be maintained by >>> a provisioning server and made available to the controlled devices. >>> >>>>> Would the sending of the answer still depend on a UA receiving the >>>>> message? Or do you expect that the answer will be sent even if there >>>>> is >>>>> no UA registered? >>>> [DG] According to me, till now, it depends on UA receiving the message. >>>> But, >>>> it may be other way round too, if we have feasible >>>> usecase/requirement.[/DG] >>> >>> If you go that way, it becomes much more like a voicemail system. >>> (In this case, a "IM-mail" system.) Namely it is a UA of last resort for >>> responding to incoming requests if no other UA does. Its not really part >>> of a registrar, though it *might* be collocated with one. >>> >>> This is not an unreasonable thing to do - its pretty common. But so far >>> there have been no proposals to standardize anything about this as part >>> of SIMPLE. (Nor have there been any to standardize voicemail systems.) >>> >>> Thanks, >>> Paul >>> >>>>> IMO this doesn't fit well with the simple model. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Regards >>>>>> Deepanshu Gautam >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>>> >> >> From ben@nostrum.com Tue Aug 18 13:13:06 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406C23A68AC for ; Tue, 18 Aug 2009 13:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2PZMcr11ALA for ; Tue, 18 Aug 2009 13:13:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3572C3A63D3 for ; Tue, 18 Aug 2009 13:13:04 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-28-173.dsl.rcsntx.swbell.net [68.94.28.173]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7IKD6ex080387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Aug 2009 15:13:07 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <2DEAEEA0-F262-4522-8507-968F0D6EC385@nostrum.com> From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 15:13:03 -0500 X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 68.94.28.173 is authenticated by a trusted mechanism) Subject: [Simple] WGLC: draft-ietf-simple-intradomain-federation-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 18 Aug 2009 20:13:06 -0000 Folks - This is a Working Group Last Call for comments on http://tools.ietf.org/html/draft-ietf-simple-intradomain-federation-04 The editor believes this draft is ready to last call, and we did not have objections to doing so in the Stockholm meeting. Please have your comments to the editor and list by 2 September, 2009. Thanks, Ben. From ben@nostrum.com Tue Aug 18 13:20:48 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6DD3A6D2F for ; Tue, 18 Aug 2009 13:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecEspQQSftRZ for ; Tue, 18 Aug 2009 13:20:48 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 87C503A63D3 for ; Tue, 18 Aug 2009 13:20:47 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-28-173.dsl.rcsntx.swbell.net [68.94.28.173]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7IKKn8G080999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Aug 2009 15:20:49 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <7BB0A021-D629-4FA7-8CBB-3EF69DFA5A79@nostrum.com> From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 15:20:43 -0500 X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 68.94.28.173 is authenticated by a trusted mechanism) Subject: [Simple] Draft Minutes from SIMPLE at IETF75 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 18 Aug 2009 20:20:48 -0000 Please review. Send comments or corrections to the list and/or chairs ASAP. Thanks! Ben. ------ Minutes - SIMPLE IETF75 - Wednesday 29 July 2009 - Stockholm, Sweden Summary: Simple-Chat: We discussed whether this draft is still needed, given that it was intended to be a short-term solution until XCON was finished with similar work, and the XCON work is nearing completion. The sense of the room was that it was no longer needed, but consensus for this needs to be confirmed on the mailing list. Interested parties to meet after session to discuss logistics in the event the work group decides to shut down the effort. Intra-Domain Bridging: No issues raised--draft to be last-called shortly after meeting. MSRP-ACM: We closed a few COMEDIA related issues, but still have open issues related to the COMEDIA connection-reuse mechanism, connection routing, and legacy session matching. Discussion to continue on list. Interested parties to meet to try to find a path forward. Raw notes by Dean Willis: ------------------------ Notes in SIMPLE IETF 75 Reported by Dean Willis Chair Ben Campbell Jabber scribe St. Peter Note Well presented by chair Agenda accepted as proposed Status reviewed by chair. Topic: simple-chat Does OMA still need simple-chat? Gonzalo reports that they no longer need it, having given up years ago and done it themselves. Discussion suggested that we will be finishing the final solution about the same time as the temporary. MSRP and nicknames came up; offline discussion will be required to settle out what todo. Involved parties are to meet after this session and develop a plan. Noted that 10 other drafts reference this one; can they be changed to reference the XCON draft instead? Topic: Intra-Domain Bridging led by Avshalom Houri Slides presented Issue: Role of Publish clarified in this version. No issues noted with draft's revised text. Issue: Distributed Policy Management Draft recognizes and provides cautions on distributed policy management isses. Question: Are we ready for WGLC? No disagreement raised, chair will schedule a last-call after this IETF. Jean Francois Mule noted that there is some overlap between this document and DRINKS work, but that the discussion of provisioning in this document is too abstract to build something that works. Jon Peterson noted that previous plans were to refer the detailed provisioning work to SPEERMINT. Topic: Alternative Connection Model for MSRP Led by Christer Holmberg Slides presented Issue: COMEDIA 1st Send Proposed that active party sends SEND. Noted by Hadriel that doc must be clear that even with this decision, it might be possible that the active party receives a SEND, and it shouldn t freak out. This should be clarified in the document. Noted by Ben that we should recheck RFC discussion about active party. No parties spoke in opposition to this proposed solution. Issue: COMEDIA client-relay TCP connection. Proposed to retain current rules, establishment of client-relay connection not affected by COMEDIA. Ben asked if we could use guidance about active-passive useage. Christer will investigate. No one spoke against the proposes solution. Issue: Connection reuse andrelays 1/3 No objections to proposed solution Issue 2/3 No objections to proposed solution. Issue 3/3 No proposed solution. Three alternative presented. Adam argues against #1 (MSRP messaging element). Adam thinks third alternative might work. Discussion ensued. Noted that there may be more than one rely on the path. According to Jonathan Lennox, COMEDIA has this mechanism so that the passive node can report a loss-of-connection to the active node. Since SIP has retransmission, we may not need this COMEDIA behavior at all. Poll: Anybody planning on using COMEDIA for this? No one responded. Ben proposes putting some call flows around this in the draft and has an initial preference for Alt 3, but can see a possibility that we might discover a need for Alt 2. Alt 1 is right out. Issue: Connection/Routing C/M vs. a=path Two alternatives offered in draft: Alt 1 is in this draft, alt 2 is in MSRP. Hadriel may recall some previous discussion around a need to do further work even with alt 2. This may be aggrivated by v4-v6 migration and dual offers. Adam and Jonathan noted further complexities related t multi-hop scenarios. Much discussion ensued. Noted that MSRP relays never see the SDP, so that info has to be in MSRP somewhere. No conclusion noted. Issue: Legacy Session Matching Proposal offered in slides. This would impact RFC 4975 in at least one sport (Ben noted a second place). Noted that this change may be dependent on conclusion to previous open issue. Issue: SBC/ALG TLS Certificate Impact Two proposals offered. Hadriel objects to both; Alt 1 will never clear IESG. Alt 2 can be replaced with a note saying "this will fail if both ends are active". Discussion ensued. Cullen noted that IESG will expect that B2BUAs terminate the TLS, so Alt 1 is not as big a problem as Hadriel thinks. No conclusion noted. Chair asked interested parties to meet and resolve this week. From root@core3.amsl.com Thu Aug 27 02:45:01 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 397EA3A6D68; Thu, 27 Aug 2009 02:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090827094501.397EA3A6D68@core3.amsl.com> Date: Thu, 27 Aug 2009 02:45:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-interdomain-scaling-analysis-08.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 09:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Interdomain Scaling Analysis for SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-simple-interdomain-scaling-analysis-08.txt Pages : 62 Date : 2009-08-27 This document analyzes the traffic that is generated by presence subscriptions between domains and shows that the amount of traffic can be extremely large. This document also analyzes the effects of a large presence system on the memory footprint and the CPU load. Approved and in-work optimizations to the Session Initiation Protocol are analyzed, considering the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-interdomain-scaling-analysis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-27024146.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Thu Aug 27 14:13:58 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 78C5328C30C; Thu, 27 Aug 2009 14:13:58 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090827211358.78C5328C30C@core3.amsl.com> Date: Thu, 27 Aug 2009 14:13:58 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] Last Call: draft-ietf-simple-xcap-diff (An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources) to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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, 27 Aug 2009 21:13:58 -0000 The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources ' as a Proposed Standard This is a 2nd last call on this document. The first last call should have pointed explicitly to the normative reference to RFC 2648 (A URN Namespace for IETF Documents). This last call is focused solely on whether this downref is appropriate in this document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-13.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12965&rfc_flag=0