From simple-admin@ietf.org Thu Apr 1 00:41:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05654 for ; Thu, 1 Apr 2004 00:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8uwo-00028t-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 00:41:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8uvu-0001zz-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 00:40:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8uvU-0001un-04; Thu, 01 Apr 2004 00:39:40 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8ugf-000126-9X; Thu, 01 Apr 2004 00:24:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugb-0006Hc-00; Thu, 01 Apr 2004 00:24:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugC-000697-8P for simple@optimus.ietf.org; Thu, 01 Apr 2004 00:23:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04817 for ; Thu, 1 Apr 2004 00:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ug9-0000w9-00 for simple@ietf.org; Thu, 01 Apr 2004 00:23:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ufE-0000tu-00 for simple@ietf.org; Thu, 01 Apr 2004 00:22:52 -0500 Received: from website12.com ([203.194.209.81]) by ietf-mx with smtp (Exim 4.12) id 1B8uf0-0000rK-00 for simple@ietf.org; Thu, 01 Apr 2004 00:22:38 -0500 Received: (qmail 5947 invoked from network); 1 Apr 2004 05:22:45 -0000 Received: from unknown (HELO VIKAS) (61.247.240.87) by website12.com with SMTP; 1 Apr 2004 05:22:45 -0000 From: "Vikas Tandon" To: , Cc: , , Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <000f01c417a9$2bdc5b70$0100a8c0@VIKAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB702085CF2@esebe019.ntc.nokia.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 10:51:14 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Vijay, Thanks for summarizing this rather pending issue. Agree with Hisham on session mode delivery notification on every message. One of the reasons for session mode was to keep the notification traffic minimal. Also would be interesting to know "being responded to" status as i might send you "Hello Vijay " and at the same time you might be typing "Hey did you get my email" unaware of what I'm going to say, in effect i don't know if you are responding to "My Message" or writing your own. This surely is a debatable issue, would be good to have more thoughts on this. Regards, Vikas -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: mercredi 31 mars 2004 22:56 To: vkg@lucent.com Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com Subject: RE: [Simple] return receipt and delivery status notification for MSRP This is a good summary, although point 4 can be debatable: How useful is it to request receive notification in session mode? /Hisham > -----Original Message----- > From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: 04.March.2004 16:53 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki > (Nokia-M/Espoo) > Subject: Re: [Simple] return receipt and delivery status notification > for MSRP > > > > hisham.khartabil@nokia.com wrote: > > > It is optional. If it is annoying to you, then you don't > > request a delivery notification. It is not every time and it is > > not mandatory. > > So, just to be pedantic, please correct me if my summary below is > wrong: > > 1/ We are interested in DSNs at the _user_ level, not the > _protocol_ level (i.e. the transactional model at the > protocol level is sufficient for protocol state > machines to figure out if an IM was delivered to the > next hop successfully or not). > 2/ We should design protocol provisions such that a positive > acknowledgement DSN model is supported (let me know > the current state of the IM: queued, delivered, read, > being responded to, ...). > 3/ We should design protocol provisions such that a negative > acknowledgement DSN model is supported (send it and > forget it unless something drastic happens, then > let me know). > 4/ Both 2 and 3 should apply to page mode and session > mode IMs. > 5/ Both 2 and 3 should be configurable by the sending > user. > > Is this accurate? > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 00:41:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05698 for ; Thu, 1 Apr 2004 00:41:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8uwv-00029k-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 00:41:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8uw1-000218-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 00:40:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8uvW-0001un-00; Thu, 01 Apr 2004 00:39:42 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8ugZ-000114-4W; Thu, 01 Apr 2004 00:24:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugN-0006AS-HW; Thu, 01 Apr 2004 00:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8tcM-0002LT-NN for simple@optimus.ietf.org; Wed, 31 Mar 2004 23:15:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01343 for ; Wed, 31 Mar 2004 23:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8tcK-00050H-00 for simple@ietf.org; Wed, 31 Mar 2004 23:15:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8tbM-0004w1-00 for simple@ietf.org; Wed, 31 Mar 2004 23:14:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B8tav-0004td-00 for simple@ietf.org; Wed, 31 Mar 2004 23:14:21 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i314E3Nr000866; Wed, 31 Mar 2004 23:14:04 -0500 (EST) Message-ID: <406B96F4.3090808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, george.foti@ericsson.com, simple@ietf.org Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) References: <2038BCC78B1AD641891A0D1AE133DBB70179786E@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179786E@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 31 Mar 2004 23:13:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Niemi Aki (Nokia-M/Espoo) >>Sent: 17.March.2004 15:09 >>To: ext George Foti (QA/EMC) >>Cc: simple@ietf.org >>Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft >>(wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) >> >> >>Inline. >> >>ext George Foti (QA/EMC) wrote: >> >>>Comments inline Chris. Rgds/gf >>> >>> >>>>-----Original Message----- From: Chris Boulton >>>>[mailto:cboulton@ubiquity.com] Sent: Wednesday, March 17, 2004 3:44 >>>>AM To: George Foti (QA/EMC); Jonathan Rosenberg Cc: >>>>Markus.Isomaki@nokia.com; simple@ietf.org Subject: RE: [Simple] RE: >>>>Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on >>>>draft-isomaki-simple-xcap-publish-usage-00) >>>> >>>> >>>>Hi George, I'm getting a little confused by this thread. I don't >>>>see any benefit of restricting what 'Hard State' data can be set. >>>>The use of XCAP and the use of PUBLISH have clearly defined roles. >>>>If a presence server requires 'Hard state', it goes away and grabs >>>>the latest copy from the XCAP repository. I can see your point >>>>that rogue clients might use XCAP in a negative manner (e.g. for >>>>changing soft state), but this can be true of many implementations >>>>that bend rules. As long as it is strongly defined that XCAP is >>>>used for Hard state and PUBLISH is used for soft state, I see no >>>>real issue. >>> >>> >>>Yes, thats my concern. On the other hand there are *no >> >>rules* to bend >> >>>in this case. It is currently wide open to manipulate >> >>everything. The >> >>>language in the draft is very weak in that regard. Changing the >>>schema is one way to put in rules. But I am opened to the >> >>alternative >> >>>of strengthening the language in an updated version of the draft and >>>to clearly disallow the usage of XCAP for changing soft states. >> >>You make it sound like it was currently allowed. Well, it >>isn't, and in >>addition, it's not even possible. PUBLISH carries soft event >>state. The >>only way to manipulate that state is to use PUBLISH, and have >>possession >>of the corresponding publication etag. >> >>I'm not aware of any text that suggests that the soft event state >>manipulated with PUBLISH somehow also finds its way into the >>XCAP tree. > > > George's point is that there is no text forbidding it, so in theory, it could find its way. But the question is: Do we really need to explicitly forbit such thing from happening by placing a MUST NOT text? I think its sufficient to say that there is simply no way, with this application usage, to point to such presence documents, making it out of scope. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 1 00:41:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05758 for ; Thu, 1 Apr 2004 00:41:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8uws-00083H-UC for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 00:41:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i315f6sk030949 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 00:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8uws-000836-OS for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 00:41:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05672 for ; Thu, 1 Apr 2004 00:41:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8uwq-000296-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 00:41:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8uvv-000206-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 00:40:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8uvU-0001un-04; Thu, 01 Apr 2004 00:39:40 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8ugf-000126-9X; Thu, 01 Apr 2004 00:24:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugb-0006Hc-00; Thu, 01 Apr 2004 00:24:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugC-000697-8P for simple@optimus.ietf.org; Thu, 01 Apr 2004 00:23:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04817 for ; Thu, 1 Apr 2004 00:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ug9-0000w9-00 for simple@ietf.org; Thu, 01 Apr 2004 00:23:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ufE-0000tu-00 for simple@ietf.org; Thu, 01 Apr 2004 00:22:52 -0500 Received: from website12.com ([203.194.209.81]) by ietf-mx with smtp (Exim 4.12) id 1B8uf0-0000rK-00 for simple@ietf.org; Thu, 01 Apr 2004 00:22:38 -0500 Received: (qmail 5947 invoked from network); 1 Apr 2004 05:22:45 -0000 Received: from unknown (HELO VIKAS) (61.247.240.87) by website12.com with SMTP; 1 Apr 2004 05:22:45 -0000 From: "Vikas Tandon" To: , Cc: , , Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <000f01c417a9$2bdc5b70$0100a8c0@VIKAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB702085CF2@esebe019.ntc.nokia.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 10:51:14 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay, Thanks for summarizing this rather pending issue. Agree with Hisham on session mode delivery notification on every message. One of the reasons for session mode was to keep the notification traffic minimal. Also would be interesting to know "being responded to" status as i might send you "Hello Vijay " and at the same time you might be typing "Hey did you get my email" unaware of what I'm going to say, in effect i don't know if you are responding to "My Message" or writing your own. This surely is a debatable issue, would be good to have more thoughts on this. Regards, Vikas -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: mercredi 31 mars 2004 22:56 To: vkg@lucent.com Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com Subject: RE: [Simple] return receipt and delivery status notification for MSRP This is a good summary, although point 4 can be debatable: How useful is it to request receive notification in session mode? /Hisham > -----Original Message----- > From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: 04.March.2004 16:53 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki > (Nokia-M/Espoo) > Subject: Re: [Simple] return receipt and delivery status notification > for MSRP > > > > hisham.khartabil@nokia.com wrote: > > > It is optional. If it is annoying to you, then you don't > > request a delivery notification. It is not every time and it is > > not mandatory. > > So, just to be pedantic, please correct me if my summary below is > wrong: > > 1/ We are interested in DSNs at the _user_ level, not the > _protocol_ level (i.e. the transactional model at the > protocol level is sufficient for protocol state > machines to figure out if an IM was delivered to the > next hop successfully or not). > 2/ We should design protocol provisions such that a positive > acknowledgement DSN model is supported (let me know > the current state of the IM: queued, delivered, read, > being responded to, ...). > 3/ We should design protocol provisions such that a negative > acknowledgement DSN model is supported (send it and > forget it unless something drastic happens, then > let me know). > 4/ Both 2 and 3 should apply to page mode and session > mode IMs. > 5/ Both 2 and 3 should be configurable by the sending > user. > > Is this accurate? > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 1 00:41:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05775 for ; Thu, 1 Apr 2004 00:41:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8uwy-00084A-O3 for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 00:41:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i315fCV0031002 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 00:41:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8uwy-00083x-JU for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 00:41:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05716 for ; Thu, 1 Apr 2004 00:41:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8uww-00029p-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 00:41:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8uw2-00021G-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 00:40:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8uvW-0001un-00; Thu, 01 Apr 2004 00:39:42 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8ugZ-000114-4W; Thu, 01 Apr 2004 00:24:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugN-0006AS-HW; Thu, 01 Apr 2004 00:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8tcM-0002LT-NN for simple@optimus.ietf.org; Wed, 31 Mar 2004 23:15:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01343 for ; Wed, 31 Mar 2004 23:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8tcK-00050H-00 for simple@ietf.org; Wed, 31 Mar 2004 23:15:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8tbM-0004w1-00 for simple@ietf.org; Wed, 31 Mar 2004 23:14:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B8tav-0004td-00 for simple@ietf.org; Wed, 31 Mar 2004 23:14:21 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i314E3Nr000866; Wed, 31 Mar 2004 23:14:04 -0500 (EST) Message-ID: <406B96F4.3090808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, george.foti@ericsson.com, simple@ietf.org Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) References: <2038BCC78B1AD641891A0D1AE133DBB70179786E@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179786E@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 31 Mar 2004 23:13:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Niemi Aki (Nokia-M/Espoo) >>Sent: 17.March.2004 15:09 >>To: ext George Foti (QA/EMC) >>Cc: simple@ietf.org >>Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft >>(wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) >> >> >>Inline. >> >>ext George Foti (QA/EMC) wrote: >> >>>Comments inline Chris. Rgds/gf >>> >>> >>>>-----Original Message----- From: Chris Boulton >>>>[mailto:cboulton@ubiquity.com] Sent: Wednesday, March 17, 2004 3:44 >>>>AM To: George Foti (QA/EMC); Jonathan Rosenberg Cc: >>>>Markus.Isomaki@nokia.com; simple@ietf.org Subject: RE: [Simple] RE: >>>>Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on >>>>draft-isomaki-simple-xcap-publish-usage-00) >>>> >>>> >>>>Hi George, I'm getting a little confused by this thread. I don't >>>>see any benefit of restricting what 'Hard State' data can be set. >>>>The use of XCAP and the use of PUBLISH have clearly defined roles. >>>>If a presence server requires 'Hard state', it goes away and grabs >>>>the latest copy from the XCAP repository. I can see your point >>>>that rogue clients might use XCAP in a negative manner (e.g. for >>>>changing soft state), but this can be true of many implementations >>>>that bend rules. As long as it is strongly defined that XCAP is >>>>used for Hard state and PUBLISH is used for soft state, I see no >>>>real issue. >>> >>> >>>Yes, thats my concern. On the other hand there are *no >> >>rules* to bend >> >>>in this case. It is currently wide open to manipulate >> >>everything. The >> >>>language in the draft is very weak in that regard. Changing the >>>schema is one way to put in rules. But I am opened to the >> >>alternative >> >>>of strengthening the language in an updated version of the draft and >>>to clearly disallow the usage of XCAP for changing soft states. >> >>You make it sound like it was currently allowed. Well, it >>isn't, and in >>addition, it's not even possible. PUBLISH carries soft event >>state. The >>only way to manipulate that state is to use PUBLISH, and have >>possession >>of the corresponding publication etag. >> >>I'm not aware of any text that suggests that the soft event state >>manipulated with PUBLISH somehow also finds its way into the >>XCAP tree. > > > George's point is that there is no text forbidding it, so in theory, it could find its way. But the question is: Do we really need to explicitly forbit such thing from happening by placing a MUST NOT text? I think its sufficient to say that there is simply no way, with this application usage, to point to such presence documents, making it out of scope. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 02:39:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23414 for ; Thu, 1 Apr 2004 02:39:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8wnG-0003sw-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 02:39:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8wmL-0003md-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 02:38:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8wla-0003g9-00; Thu, 01 Apr 2004 02:37:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wl4-0000RA-6h; Thu, 01 Apr 2004 02:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wk5-0000E6-Ay for simple@optimus.ietf.org; Thu, 01 Apr 2004 02:36:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23207 for ; Thu, 1 Apr 2004 02:35:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8wk1-0003Zn-00 for simple@ietf.org; Thu, 01 Apr 2004 02:35:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8wj6-0003SW-00 for simple@ietf.org; Thu, 01 Apr 2004 02:35:01 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B8wiQ-0003Od-00; Thu, 01 Apr 2004 02:34:18 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i317YA324793; Thu, 1 Apr 2004 10:34:10 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 10:36:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i317abku031624; Thu, 1 Apr 2004 10:36:37 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 007el0Ry; Thu, 01 Apr 2004 10:36:37 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i317Y2F08163; Thu, 1 Apr 2004 10:34:02 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 10:32:56 +0300 Message-ID: <406BC5A8.4080003@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: SIMPLE mailing list , SIPPING mailing list CC: Gonzalo Camarillo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 07:32:56.0087 (UTC) FILETIME=[8CBF0A70:01C417BB] Content-Transfer-Encoding: 7bit Subject: [Simple] MESSAGE Exploders draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 10:32:56 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi: I have just submitted a draft that discusses a exploder of MESSAGEs. While it appears in the repository, you can download them from: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING (exploders), I am copying both mailing lists. Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 1 02:39:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23446 for ; Thu, 1 Apr 2004 02:39:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wnK-00012z-Qg for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 02:39:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i317dMLl004025 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 02:39:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wnK-00012o-IU for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 02:39:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23428 for ; Thu, 1 Apr 2004 02:39:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8wnG-0003t3-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 02:39:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8wmM-0003mk-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 02:38:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8wla-0003g9-00; Thu, 01 Apr 2004 02:37:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wl4-0000RA-6h; Thu, 01 Apr 2004 02:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wk5-0000E6-Ay for simple@optimus.ietf.org; Thu, 01 Apr 2004 02:36:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23207 for ; Thu, 1 Apr 2004 02:35:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8wk1-0003Zn-00 for simple@ietf.org; Thu, 01 Apr 2004 02:35:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8wj6-0003SW-00 for simple@ietf.org; Thu, 01 Apr 2004 02:35:01 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B8wiQ-0003Od-00; Thu, 01 Apr 2004 02:34:18 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i317YA324793; Thu, 1 Apr 2004 10:34:10 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 10:36:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i317abku031624; Thu, 1 Apr 2004 10:36:37 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 007el0Ry; Thu, 01 Apr 2004 10:36:37 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i317Y2F08163; Thu, 1 Apr 2004 10:34:02 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 10:32:56 +0300 Message-ID: <406BC5A8.4080003@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: SIMPLE mailing list , SIPPING mailing list CC: Gonzalo Camarillo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 07:32:56.0087 (UTC) FILETIME=[8CBF0A70:01C417BB] Content-Transfer-Encoding: 7bit Subject: [Simple] MESSAGE Exploders draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 10:32:56 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: I have just submitted a draft that discusses a exploder of MESSAGEs. While it appears in the repository, you can download them from: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING (exploders), I am copying both mailing lists. Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 04:28:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03092 for ; Thu, 1 Apr 2004 04:28:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yUZ-0004MD-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 04:28:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8yTb-0004HN-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 04:27:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8ySd-0004Cd-00; Thu, 01 Apr 2004 04:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ySW-0000Ve-Th; Thu, 01 Apr 2004 04:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ySV-0000VO-Dg for simple@optimus.ietf.org; Thu, 01 Apr 2004 04:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03052 for ; Thu, 1 Apr 2004 04:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ySS-0004Bu-00 for simple@ietf.org; Thu, 01 Apr 2004 04:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8yRW-00046S-00 for simple@ietf.org; Thu, 01 Apr 2004 04:24:59 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly09b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1B8yR0-00042g-00 for simple@ietf.org; Thu, 01 Apr 2004 04:24:26 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly09b.srv.mailcontrol.com (MailControl) with SMTP id i319Ngwo002559; Thu, 1 Apr 2004 10:23:42 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Thu, 1 Apr 2004 10:23:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B248@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQXi2UOVL+7l0diSEOwSwwg6zr+0gAPou5w From: "Chris Boulton" To: "Ben Campbell" , Cc: , , , , , X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 10:23:42 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I agree with Ben. If an entity requests delivery confirmation, it cannot rely on the absence of a failure DSN to convey that the message was delivered successfully. So I feel that there is scope for both failure/success DSN's and a requirement for appropriate text describing procedures for the scenario where a positive DSN is requested BUT none received. Out of interest - what are the current thoughts on exactly how a client will request a DSN conformation? Chris. =20 >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: 01 April 2004 02:46 >To: hisham.khartabil@nokia.com >Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; simple@ietf.org; >rohan@cisco.com; aki.niemi@nokia.com >Subject: Re: [Simple] return receipt and delivery status notification for >MSRP > >I don't think so. Imagine the following scenario: > >A---R1---R2---B > >A sends a critically important message to B, telling B to buy stock in >messaging companies. > >A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >fails to send to B. So he tries to send a negative DSN to A via R1. But >it turns out the failure killed all connectivity to and from R2, so he >cannot send it. > >The moral is, DSNs can fail just like any other kind of message. So if a >message absolutely positively must be delivered, you need to be able to >request positive DSN. Then A can at least notice it did not receive a >DSN, and act accordingly. > > >hisham.khartabil@nokia.com wrote: >> My question was: How useful is it to have both notification modes >(positive and negative) for session IMs? Isn't notification on failure >enough? >> >> /Hisham >> >> >>>-----Original Message----- >>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 01.April.2004 01:45 >>>To: Orit Levin >>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>(Nokia-M/Espoo) >>>Subject: Re: [Simple] return receipt and delivery status notification >>>for MSRP >>> >>> >>> >>>As Orit says, DSN will be very important for MSRP. >>> >>>The current thinking is that MSRP relays will be session >>>stateless, and >>>that transactions are entirely hop-by-hop. The relay >>>semantics would be >>>similar to those of the SIMS draft, with MSRP syntax. >>> >>>As Orit hinted, this means that a transaction response is merely an >>>indication that the transaction succeeded, not that the message has >>>reached its destination. So in non peer-to-peer sessions, DSN >>>is critical. >>> >>>We do expect it to be optional, as it is much less useful in the >>>peer-to-peer case, where is just constitutes redundant messaging. >>> >>>Orit Levin wrote: >>> >>>>Hisham, >>>>It is VERY useful because >>>> >>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you whether the >>>>message was actually delivered end-to-end. >>>>2. MSRP hop-by-hop application-timer-based mechanism >>> >>>doesn't prevent you >>> >>>>from getting negative acknowledge in a case when the message was >>>>actually delivered to the destination. In other words, it >>> >>>doesn't solve >>> >>>>a duplication problem. >>>> >>>>I would like to add the requirement that the "end-to-end" >>> >>>DSN receipt >>> >>>>needs to be requested per message (not negotiated for the >>> >>>whole session >>> >>>>for all messages). It will allow for writing different IM behaviors >>>>using the same mechanism. Such as: >>>> >>>>1. Loose IM session: all the user messages are sent without >>> >>>receipt, but >>> >>>>the application sends a heartbeat message with requesting a >>> >>>receipt for >>> >>>>each. >>>>2. Typical IM session: For all user messages a receipt is >>> >>>requested but >>> >>>>the indication messages (e.g. "The user is typing") are delivered >>>>without any receipt. >>>> >>>>Thanks, >>>>Orit. >>>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>> >>>On Behalf Of >>> >>>>hisham.khartabil@nokia.com >>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>To: vkg@lucent.com >>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >>>>aki.niemi@nokia.com >>>>Subject: RE: [Simple] return receipt and delivery status >>> >>>notification >>> >>>>for MSRP >>>> >>>>This is a good summary, although point 4 can be debatable: >>> >>>How useful is >>> >>>>it to request receive notification in session mode? >>>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>Sent: 04.March.2004 16:53 >>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>(Nokia-M/Espoo) >>>>>Subject: Re: [Simple] return receipt and delivery status >>> >>>notification >>> >>>>>for MSRP >>>>> >>>>> >>>>> >>>>>hisham.khartabil@nokia.com wrote: >>>>> >>>>> >>>>> >>>>>>It is optional. If it is annoying to you, then you don't request a >>>>>>delivery notification. It is not every time and it is not >>> >>>mandatory. >>> >>>>>So, just to be pedantic, please correct me if my summary below is >>>>>wrong: >>>>> >>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>> _protocol_ level (i.e. the transactional model at the >>>>> protocol level is sufficient for protocol state >>>>> machines to figure out if an IM was delivered to the >>>>> next hop successfully or not). >>>>> 2/ We should design protocol provisions such that a positive >>>>> acknowledgement DSN model is supported (let me know >>>>> the current state of the IM: queued, delivered, read, >>>>> being responded to, ...). >>>>> 3/ We should design protocol provisions such that a negative >>>>> acknowledgement DSN model is supported (send it and >>>>> forget it unless something drastic happens, then >>>>> let me know). >>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>> mode IMs. >>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>> user. >>>>> >>>>>Is this accurate? >>>>> >>>>>Thanks, >>>>> >>>>>- vijay >>>>>-- >>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>Wireless Networks Group/Internet Software and Services Lucent >>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>> >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 1 04:28:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03127 for ; Thu, 1 Apr 2004 04:28:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yUl-0000es-Ox for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 04:28:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i319SJIm002525 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 04:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yUf-0000eT-Tc for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 04:28:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03110 for ; Thu, 1 Apr 2004 04:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yUc-0004MY-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 04:28:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8yTc-0004HY-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 04:27:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8ySd-0004Cd-00; Thu, 01 Apr 2004 04:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ySW-0000Ve-Th; Thu, 01 Apr 2004 04:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ySV-0000VO-Dg for simple@optimus.ietf.org; Thu, 01 Apr 2004 04:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03052 for ; Thu, 1 Apr 2004 04:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ySS-0004Bu-00 for simple@ietf.org; Thu, 01 Apr 2004 04:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8yRW-00046S-00 for simple@ietf.org; Thu, 01 Apr 2004 04:24:59 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly09b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1B8yR0-00042g-00 for simple@ietf.org; Thu, 01 Apr 2004 04:24:26 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly09b.srv.mailcontrol.com (MailControl) with SMTP id i319Ngwo002559; Thu, 1 Apr 2004 10:23:42 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Thu, 1 Apr 2004 10:23:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B248@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQXi2UOVL+7l0diSEOwSwwg6zr+0gAPou5w From: "Chris Boulton" To: "Ben Campbell" , Cc: , , , , , X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 10:23:42 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Ben. If an entity requests delivery confirmation, it cannot rely on the absence of a failure DSN to convey that the message was delivered successfully. So I feel that there is scope for both failure/success DSN's and a requirement for appropriate text describing procedures for the scenario where a positive DSN is requested BUT none received. Out of interest - what are the current thoughts on exactly how a client will request a DSN conformation? Chris. =20 >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: 01 April 2004 02:46 >To: hisham.khartabil@nokia.com >Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; simple@ietf.org; >rohan@cisco.com; aki.niemi@nokia.com >Subject: Re: [Simple] return receipt and delivery status notification for >MSRP > >I don't think so. Imagine the following scenario: > >A---R1---R2---B > >A sends a critically important message to B, telling B to buy stock in >messaging companies. > >A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >fails to send to B. So he tries to send a negative DSN to A via R1. But >it turns out the failure killed all connectivity to and from R2, so he >cannot send it. > >The moral is, DSNs can fail just like any other kind of message. So if a >message absolutely positively must be delivered, you need to be able to >request positive DSN. Then A can at least notice it did not receive a >DSN, and act accordingly. > > >hisham.khartabil@nokia.com wrote: >> My question was: How useful is it to have both notification modes >(positive and negative) for session IMs? Isn't notification on failure >enough? >> >> /Hisham >> >> >>>-----Original Message----- >>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 01.April.2004 01:45 >>>To: Orit Levin >>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>(Nokia-M/Espoo) >>>Subject: Re: [Simple] return receipt and delivery status notification >>>for MSRP >>> >>> >>> >>>As Orit says, DSN will be very important for MSRP. >>> >>>The current thinking is that MSRP relays will be session >>>stateless, and >>>that transactions are entirely hop-by-hop. The relay >>>semantics would be >>>similar to those of the SIMS draft, with MSRP syntax. >>> >>>As Orit hinted, this means that a transaction response is merely an >>>indication that the transaction succeeded, not that the message has >>>reached its destination. So in non peer-to-peer sessions, DSN >>>is critical. >>> >>>We do expect it to be optional, as it is much less useful in the >>>peer-to-peer case, where is just constitutes redundant messaging. >>> >>>Orit Levin wrote: >>> >>>>Hisham, >>>>It is VERY useful because >>>> >>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you whether the >>>>message was actually delivered end-to-end. >>>>2. MSRP hop-by-hop application-timer-based mechanism >>> >>>doesn't prevent you >>> >>>>from getting negative acknowledge in a case when the message was >>>>actually delivered to the destination. In other words, it >>> >>>doesn't solve >>> >>>>a duplication problem. >>>> >>>>I would like to add the requirement that the "end-to-end" >>> >>>DSN receipt >>> >>>>needs to be requested per message (not negotiated for the >>> >>>whole session >>> >>>>for all messages). It will allow for writing different IM behaviors >>>>using the same mechanism. Such as: >>>> >>>>1. Loose IM session: all the user messages are sent without >>> >>>receipt, but >>> >>>>the application sends a heartbeat message with requesting a >>> >>>receipt for >>> >>>>each. >>>>2. Typical IM session: For all user messages a receipt is >>> >>>requested but >>> >>>>the indication messages (e.g. "The user is typing") are delivered >>>>without any receipt. >>>> >>>>Thanks, >>>>Orit. >>>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>> >>>On Behalf Of >>> >>>>hisham.khartabil@nokia.com >>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>To: vkg@lucent.com >>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >>>>aki.niemi@nokia.com >>>>Subject: RE: [Simple] return receipt and delivery status >>> >>>notification >>> >>>>for MSRP >>>> >>>>This is a good summary, although point 4 can be debatable: >>> >>>How useful is >>> >>>>it to request receive notification in session mode? >>>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>Sent: 04.March.2004 16:53 >>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>(Nokia-M/Espoo) >>>>>Subject: Re: [Simple] return receipt and delivery status >>> >>>notification >>> >>>>>for MSRP >>>>> >>>>> >>>>> >>>>>hisham.khartabil@nokia.com wrote: >>>>> >>>>> >>>>> >>>>>>It is optional. If it is annoying to you, then you don't request a >>>>>>delivery notification. It is not every time and it is not >>> >>>mandatory. >>> >>>>>So, just to be pedantic, please correct me if my summary below is >>>>>wrong: >>>>> >>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>> _protocol_ level (i.e. the transactional model at the >>>>> protocol level is sufficient for protocol state >>>>> machines to figure out if an IM was delivered to the >>>>> next hop successfully or not). >>>>> 2/ We should design protocol provisions such that a positive >>>>> acknowledgement DSN model is supported (let me know >>>>> the current state of the IM: queued, delivered, read, >>>>> being responded to, ...). >>>>> 3/ We should design protocol provisions such that a negative >>>>> acknowledgement DSN model is supported (send it and >>>>> forget it unless something drastic happens, then >>>>> let me know). >>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>> mode IMs. >>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>> user. >>>>> >>>>>Is this accurate? >>>>> >>>>>Thanks, >>>>> >>>>>- vijay >>>>>-- >>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>Wireless Networks Group/Internet Software and Services Lucent >>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>> >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 06:32:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06883 for ; Thu, 1 Apr 2004 06:32:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90QU-0006fE-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 06:32:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90PY-0006an-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 06:31:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B90Od-0006Ui-00; Thu, 01 Apr 2004 06:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90OX-0001HC-MM; Thu, 01 Apr 2004 06:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90Nb-0001Bt-LG for simple@optimus.ietf.org; Thu, 01 Apr 2004 06:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06756 for ; Thu, 1 Apr 2004 06:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90NX-0006Pe-00 for simple@ietf.org; Thu, 01 Apr 2004 06:28:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90Md-0006K7-00 for simple@ietf.org; Thu, 01 Apr 2004 06:28:03 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B90Li-0006Du-00; Thu, 01 Apr 2004 06:27:07 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i31BR6Q25968; Thu, 1 Apr 2004 13:27:06 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i31BR5T02030; Thu, 1 Apr 2004 13:27:05 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Apr 2004 13:26:18 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685F6D@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Markus.Isomaki@nokia.com'" , jdrosen@dynamicsoft.com, bcampbell@dynamicsoft.com Cc: hardie@qualcomm.com, hgs@cs.columbia.edu, simple@ietf.org, geopriv@ietf.org Subject: RE: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Commen ts on: First draft of text on semantic-based authorization policies [exce ptions] MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 13:26:42 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi markus, > Hi, > > I see that this is another case, where it would be beneficial > that the s would be ordered in similar way as other > permissions. I guess the "lowest" or default value would be > , as that gives least information out, so > there would not be even need to have that in any rules? well, section 4 of says that: "... This also implies that rule ordering is not important." i think that we should note this fact more clearly. we do not assume that rules appear in a certain order. rules can appear in any order without effecting the result of the rule evaluation. introducing an order into these rules would create a number of problems. i will just list a few: - you need to make sure that the person writing those rules is aware of the order to anticipate its result. - rule updates (e.g., via xcap need be aware of the order) - changing the order of the rule has an impact on the result of rule evaluation. i am not sure whether xcap would be able to handle this issue properly. - you suddenly have to deal with a different conflict resolution strategy. you know this from regular firewall rules. we tried to keep our conflict resolution strategy very simple (see section 10 - Procedure for Combining Permissions; in the same draft). ciao hannes > > Markus > > > -----Original Message----- > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: 31 March, 2004 14:48 > > To: 'Jonathan Rosenberg'; Ben Campbell > > Cc: Ted Hardie; Henning Schulzrinne; Isomaki Markus > > (Nokia-NRC/Helsinki); simple@ietf.org; 'geopriv@ietf.org' > > Subject: RE: supporitng blacklists, was: Re: [Simple] > > Comments on: First > > draft of text on semantic-based authorization policies [exceptions] > > > > > > -- cc to geopriv ml > > > > hi jonathan, > > > > you propose an action with is a deny. doesn't this conflict > > with the goals > > expressed in the common policy draft ( > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common- > > policy-00.txt) > > where Section 4 (Goals and Assumptions) specifies 'Permit > > only' actions are > > allowed. do you suggest that we modifying our > > goals/assumptions or do i miss > > something? > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, March 25, 2004 4:43 PM > > > To: Ben Campbell > > > Cc: Ted Hardie; Henning Schulzrinne; Markus.Isomaki@nokia.com; > > > simple@ietf.org > > > Subject: Re: supporitng blacklists, was: Re: [Simple] > > > Comments on: First > > > draft of text on semantic-based authorization policies > [exceptions] > > > > > > > > > You can still achieve the functionality you want, Ben, > > > without requiring > > > the new rule Henning had proposed: > > > > > > > > > > > > > > > example.com > > > joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Of course, you need to be careful that the user joe is not a > > > member of > > > any other rule which grants a permission greater than > > > "deny-subscription", but thats a fundamental property of > > the model in > > > general. > > > > > > -Jonathan R. > > > > > > Ben Campbell wrote: > > > > > > > Ted Hardie wrote: > > > > > > > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote: > > > >> > > > >>> "Everybody in the world, in any domain, gets to *ask* to > > > subscribe to > > > >>> my presence, but Alice, Bob and Carol have already been > > > told to take > > > >>> a hike and thus shouldn't even be able to ask." > > > >>> > > > >>> Is this the type of rule we want to be to support? > > > >> > > > >> > > > >> > > > >> It's seems to me to be a lot easier just to keep telling > > > them to take > > > >> a hike > > > >> whenever they ask; is there a reason to optimize for this > > > case that I'm > > > >> missing? > > > > > > > > > > > > The act of asking can become a kind of harrassment. Some > > > time ago, I had > > > > a yahoo messenger user that continuously asked permission > > > to watch my > > > > presence, but refused to identify themselves to me. This > > > continued after > > > > I asked them to desist. Fortunately, yahoo messenger > > > allowed me to block > > > > that ID, so I no longer get bothered by them. > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 1 06:32:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06932 for ; Thu, 1 Apr 2004 06:32:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90QZ-0001Wi-Mb for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 06:32:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31BW7d4005868 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 06:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90QZ-0001WZ-FF for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 06:32:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06901 for ; Thu, 1 Apr 2004 06:32:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90QV-0006fJ-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 06:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90PZ-0006av-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 06:31:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B90Od-0006Ui-00; Thu, 01 Apr 2004 06:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90OX-0001HC-MM; Thu, 01 Apr 2004 06:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90Nb-0001Bt-LG for simple@optimus.ietf.org; Thu, 01 Apr 2004 06:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06756 for ; Thu, 1 Apr 2004 06:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90NX-0006Pe-00 for simple@ietf.org; Thu, 01 Apr 2004 06:28:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90Md-0006K7-00 for simple@ietf.org; Thu, 01 Apr 2004 06:28:03 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B90Li-0006Du-00; Thu, 01 Apr 2004 06:27:07 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i31BR6Q25968; Thu, 1 Apr 2004 13:27:06 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i31BR5T02030; Thu, 1 Apr 2004 13:27:05 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Apr 2004 13:26:18 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685F6D@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Markus.Isomaki@nokia.com'" , jdrosen@dynamicsoft.com, bcampbell@dynamicsoft.com Cc: hardie@qualcomm.com, hgs@cs.columbia.edu, simple@ietf.org, geopriv@ietf.org Subject: RE: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Commen ts on: First draft of text on semantic-based authorization policies [exce ptions] MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 13:26:42 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi markus, > Hi, > > I see that this is another case, where it would be beneficial > that the s would be ordered in similar way as other > permissions. I guess the "lowest" or default value would be > , as that gives least information out, so > there would not be even need to have that in any rules? well, section 4 of says that: "... This also implies that rule ordering is not important." i think that we should note this fact more clearly. we do not assume that rules appear in a certain order. rules can appear in any order without effecting the result of the rule evaluation. introducing an order into these rules would create a number of problems. i will just list a few: - you need to make sure that the person writing those rules is aware of the order to anticipate its result. - rule updates (e.g., via xcap need be aware of the order) - changing the order of the rule has an impact on the result of rule evaluation. i am not sure whether xcap would be able to handle this issue properly. - you suddenly have to deal with a different conflict resolution strategy. you know this from regular firewall rules. we tried to keep our conflict resolution strategy very simple (see section 10 - Procedure for Combining Permissions; in the same draft). ciao hannes > > Markus > > > -----Original Message----- > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: 31 March, 2004 14:48 > > To: 'Jonathan Rosenberg'; Ben Campbell > > Cc: Ted Hardie; Henning Schulzrinne; Isomaki Markus > > (Nokia-NRC/Helsinki); simple@ietf.org; 'geopriv@ietf.org' > > Subject: RE: supporitng blacklists, was: Re: [Simple] > > Comments on: First > > draft of text on semantic-based authorization policies [exceptions] > > > > > > -- cc to geopriv ml > > > > hi jonathan, > > > > you propose an action with is a deny. doesn't this conflict > > with the goals > > expressed in the common policy draft ( > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common- > > policy-00.txt) > > where Section 4 (Goals and Assumptions) specifies 'Permit > > only' actions are > > allowed. do you suggest that we modifying our > > goals/assumptions or do i miss > > something? > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, March 25, 2004 4:43 PM > > > To: Ben Campbell > > > Cc: Ted Hardie; Henning Schulzrinne; Markus.Isomaki@nokia.com; > > > simple@ietf.org > > > Subject: Re: supporitng blacklists, was: Re: [Simple] > > > Comments on: First > > > draft of text on semantic-based authorization policies > [exceptions] > > > > > > > > > You can still achieve the functionality you want, Ben, > > > without requiring > > > the new rule Henning had proposed: > > > > > > > > > > > > > > > example.com > > > joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Of course, you need to be careful that the user joe is not a > > > member of > > > any other rule which grants a permission greater than > > > "deny-subscription", but thats a fundamental property of > > the model in > > > general. > > > > > > -Jonathan R. > > > > > > Ben Campbell wrote: > > > > > > > Ted Hardie wrote: > > > > > > > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote: > > > >> > > > >>> "Everybody in the world, in any domain, gets to *ask* to > > > subscribe to > > > >>> my presence, but Alice, Bob and Carol have already been > > > told to take > > > >>> a hike and thus shouldn't even be able to ask." > > > >>> > > > >>> Is this the type of rule we want to be to support? > > > >> > > > >> > > > >> > > > >> It's seems to me to be a lot easier just to keep telling > > > them to take > > > >> a hike > > > >> whenever they ask; is there a reason to optimize for this > > > case that I'm > > > >> missing? > > > > > > > > > > > > The act of asking can become a kind of harrassment. Some > > > time ago, I had > > > > a yahoo messenger user that continuously asked permission > > > to watch my > > > > presence, but refused to identify themselves to me. This > > > continued after > > > > I asked them to desist. Fortunately, yahoo messenger > > > allowed me to block > > > > that ID, so I no longer get bothered by them. > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 07:32:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08804 for ; Thu, 1 Apr 2004 07:32:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91Mb-00040d-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 07:32:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91Le-0003vM-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 07:31:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91Kn-0003pF-00; Thu, 01 Apr 2004 07:30:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Kc-0007Gn-Po; Thu, 01 Apr 2004 07:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Ji-0007ER-Jn for simple@optimus.ietf.org; Thu, 01 Apr 2004 07:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08711 for ; Thu, 1 Apr 2004 07:29:02 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91Ji-0003jI-00 for simple@ietf.org; Thu, 01 Apr 2004 07:29:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91Ik-0003fP-00 for simple@ietf.org; Thu, 01 Apr 2004 07:28:07 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B91I4-0003bm-00; Thu, 01 Apr 2004 07:27:24 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31CR2F26330; Thu, 1 Apr 2004 15:27:02 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 15:29:21 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i31CTLeo022522; Thu, 1 Apr 2004 15:29:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00uKPhbv; Thu, 01 Apr 2004 15:29:19 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31CQiF24110; Thu, 1 Apr 2004 15:26:44 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 15:25:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions] Message-ID: Thread-Topic: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions] Thread-Index: AcQX3KHFDIE0IPpDTTOVQOMzRzyrNQAAB4Tw To: , , Cc: , , , X-OriginalArrivalTime: 01 Apr 2004 12:25:25.0373 (UTC) FILETIME=[68EF92D0:01C417E4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 15:25:24 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hannes, I wasn't referring to the ordering of _rules_, but ordering of = _actions_, such as . For instance what happens if the same = watcher/recipient is given several (unorthogonal) actions - for instance = and by different rules. There is no = way of deciding what to do, unless the actions that are unorthogonal are = given integer values (per chapter 10 of the draft you refer to), i.e. = there is at least partial ordering of actions. (Orthogonal actions can = be combined with union still.) I think Jonathan's example would be OK, if we say that = is the default given to watchers not matched by any = rule, so the last rule: > > > > > > > > > > > > > > > > joe > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > would not be needed at all (unless there is something even stricter = which is applied by default to watchers who do not even get = - I doubt this would be the case). However, I think in another thread in SIMPLE Henning has suggested (as = far as I understood it)actually that could have lower = "number" than , and that has been debated. Markus=20 > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: 01 April, 2004 14:27 > To: Isomaki Markus (Nokia-NRC/Helsinki); jdrosen@dynamicsoft.com; > bcampbell@dynamicsoft.com > Cc: hardie@qualcomm.com; hgs@cs.columbia.edu; simple@ietf.org; > geopriv@ietf.org > Subject: RE: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] > Comments on: First draft of text on semantic-based authorization > policies [exceptions] >=20 >=20 > hi markus,=20 >=20 > > Hi, > >=20 > > I see that this is another case, where it would be beneficial=20 > > that the s would be ordered in similar way as other=20 > > permissions. I guess the "lowest" or default value would be=20 > > , as that gives least information out, so=20 > > there would not be even need to have that in any rules? >=20 > well, section 4 of =20 > says that: > "... This also implies that rule ordering is not important." >=20 > i think that we should note this fact more clearly.=20 >=20 > we do not assume that rules appear in a certain order. rules=20 > can appear in > any order without effecting the result of the rule evaluation. >=20 > introducing an order into these rules would create a number=20 > of problems. i > will just list a few:=20 > - you need to make sure that the person writing those rules=20 > is aware of the > order to anticipate its result.=20 > - rule updates (e.g., via xcap need be aware of the order) -=20 > changing the > order of the rule has an impact on the result of rule=20 > evaluation. i am not > sure whether xcap would be able to handle this issue properly.=20 > - you suddenly have to deal with a different conflict=20 > resolution strategy. > you know this from regular firewall rules. we tried to keep=20 > our conflict > resolution strategy very simple (see section 10 - Procedure=20 > for Combining > Permissions; in the same draft). >=20 > ciao > hannes >=20 > >=20 > > Markus=20 > >=20 > > > -----Original Message----- > > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > > Sent: 31 March, 2004 14:48 > > > To: 'Jonathan Rosenberg'; Ben Campbell > > > Cc: Ted Hardie; Henning Schulzrinne; Isomaki Markus > > > (Nokia-NRC/Helsinki); simple@ietf.org; 'geopriv@ietf.org' > > > Subject: RE: supporitng blacklists, was: Re: [Simple]=20 > > > Comments on: First > > > draft of text on semantic-based authorization policies=20 > [exceptions] > > >=20 > > >=20 > > > -- cc to geopriv ml > > >=20 > > > hi jonathan,=20 > > >=20 > > > you propose an action with is a deny. doesn't this conflict=20 > > > with the goals > > > expressed in the common policy draft ( > > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common- > > > policy-00.txt) > > > where Section 4 (Goals and Assumptions) specifies 'Permit=20 > > > only' actions are > > > allowed. do you suggest that we modifying our=20 > > > goals/assumptions or do i miss > > > something? > > >=20 > > > ciao > > > hannes > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Thursday, March 25, 2004 4:43 PM > > > > To: Ben Campbell > > > > Cc: Ted Hardie; Henning Schulzrinne; Markus.Isomaki@nokia.com; > > > > simple@ietf.org > > > > Subject: Re: supporitng blacklists, was: Re: [Simple]=20 > > > > Comments on: First > > > > draft of text on semantic-based authorization policies=20 > > [exceptions] > > > >=20 > > > >=20 > > > > You can still achieve the functionality you want, Ben,=20 > > > > without requiring=20 > > > > the new rule Henning had proposed: > > > >=20 > > > > > > > > > > > > > > > > example.com > > > > joe > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > joe > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > >=20 > > > >=20 > > > > Of course, you need to be careful that the user joe is not a=20 > > > > member of=20 > > > > any other rule which grants a permission greater than=20 > > > > "deny-subscription", but thats a fundamental property of=20 > > > the model in=20 > > > > general. > > > >=20 > > > > -Jonathan R. > > > >=20 > > > > Ben Campbell wrote: > > > >=20 > > > > > Ted Hardie wrote: > > > > >=20 > > > > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote: > > > > >> > > > > >>> "Everybody in the world, in any domain, gets to *ask* to=20 > > > > subscribe to=20 > > > > >>> my presence, but Alice, Bob and Carol have already been=20 > > > > told to take=20 > > > > >>> a hike and thus shouldn't even be able to ask." > > > > >>> > > > > >>> Is this the type of rule we want to be to support? > > > > >> > > > > >> > > > > >> > > > > >> It's seems to me to be a lot easier just to keep telling=20 > > > > them to take=20 > > > > >> a hike > > > > >> whenever they ask; is there a reason to optimize for this=20 > > > > case that I'm > > > > >> missing? > > > > >=20 > > > > >=20 > > > > > The act of asking can become a kind of harrassment. Some=20 > > > > time ago, I had=20 > > > > > a yahoo messenger user that continuously asked permission=20 > > > > to watch my=20 > > > > > presence, but refused to identify themselves to me. This=20 > > > > continued after=20 > > > > > I asked them to desist. Fortunately, yahoo messenger=20 > > > > allowed me to block=20 > > > > > that ID, so I no longer get bothered by them. > > > > >=20 > > > >=20 > > > > --=20 > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, NJ=20 > > > 07054-2711 > > > > dynamicsoft > > > > jdrosen@dynamicsoft.com FAX: =20 > (973) 952-5050 > > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 1 07:32:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08885 for ; Thu, 1 Apr 2004 07:32:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Md-0007Tb-A0 for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 07:32:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31CW7FC028740 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 07:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Mc-0007TR-SC for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:32:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08822 for ; Thu, 1 Apr 2004 07:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91Mc-00040i-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 07:32:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91Lg-0003vU-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 07:31:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91Kn-0003pF-00; Thu, 01 Apr 2004 07:30:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Kc-0007Gn-Po; Thu, 01 Apr 2004 07:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Ji-0007ER-Jn for simple@optimus.ietf.org; Thu, 01 Apr 2004 07:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08711 for ; Thu, 1 Apr 2004 07:29:02 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91Ji-0003jI-00 for simple@ietf.org; Thu, 01 Apr 2004 07:29:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91Ik-0003fP-00 for simple@ietf.org; Thu, 01 Apr 2004 07:28:07 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B91I4-0003bm-00; Thu, 01 Apr 2004 07:27:24 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31CR2F26330; Thu, 1 Apr 2004 15:27:02 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 15:29:21 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i31CTLeo022522; Thu, 1 Apr 2004 15:29:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00uKPhbv; Thu, 01 Apr 2004 15:29:19 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31CQiF24110; Thu, 1 Apr 2004 15:26:44 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 15:25:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions] Message-ID: Thread-Topic: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions] Thread-Index: AcQX3KHFDIE0IPpDTTOVQOMzRzyrNQAAB4Tw To: , , Cc: , , , X-OriginalArrivalTime: 01 Apr 2004 12:25:25.0373 (UTC) FILETIME=[68EF92D0:01C417E4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 15:25:24 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hannes, I wasn't referring to the ordering of _rules_, but ordering of = _actions_, such as . For instance what happens if the same = watcher/recipient is given several (unorthogonal) actions - for instance = and by different rules. There is no = way of deciding what to do, unless the actions that are unorthogonal are = given integer values (per chapter 10 of the draft you refer to), i.e. = there is at least partial ordering of actions. (Orthogonal actions can = be combined with union still.) I think Jonathan's example would be OK, if we say that = is the default given to watchers not matched by any = rule, so the last rule: > > > > > > > > > > > > > > > > joe > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > would not be needed at all (unless there is something even stricter = which is applied by default to watchers who do not even get = - I doubt this would be the case). However, I think in another thread in SIMPLE Henning has suggested (as = far as I understood it)actually that could have lower = "number" than , and that has been debated. Markus=20 > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: 01 April, 2004 14:27 > To: Isomaki Markus (Nokia-NRC/Helsinki); jdrosen@dynamicsoft.com; > bcampbell@dynamicsoft.com > Cc: hardie@qualcomm.com; hgs@cs.columbia.edu; simple@ietf.org; > geopriv@ietf.org > Subject: RE: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] > Comments on: First draft of text on semantic-based authorization > policies [exceptions] >=20 >=20 > hi markus,=20 >=20 > > Hi, > >=20 > > I see that this is another case, where it would be beneficial=20 > > that the s would be ordered in similar way as other=20 > > permissions. I guess the "lowest" or default value would be=20 > > , as that gives least information out, so=20 > > there would not be even need to have that in any rules? >=20 > well, section 4 of =20 > says that: > "... This also implies that rule ordering is not important." >=20 > i think that we should note this fact more clearly.=20 >=20 > we do not assume that rules appear in a certain order. rules=20 > can appear in > any order without effecting the result of the rule evaluation. >=20 > introducing an order into these rules would create a number=20 > of problems. i > will just list a few:=20 > - you need to make sure that the person writing those rules=20 > is aware of the > order to anticipate its result.=20 > - rule updates (e.g., via xcap need be aware of the order) -=20 > changing the > order of the rule has an impact on the result of rule=20 > evaluation. i am not > sure whether xcap would be able to handle this issue properly.=20 > - you suddenly have to deal with a different conflict=20 > resolution strategy. > you know this from regular firewall rules. we tried to keep=20 > our conflict > resolution strategy very simple (see section 10 - Procedure=20 > for Combining > Permissions; in the same draft). >=20 > ciao > hannes >=20 > >=20 > > Markus=20 > >=20 > > > -----Original Message----- > > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > > Sent: 31 March, 2004 14:48 > > > To: 'Jonathan Rosenberg'; Ben Campbell > > > Cc: Ted Hardie; Henning Schulzrinne; Isomaki Markus > > > (Nokia-NRC/Helsinki); simple@ietf.org; 'geopriv@ietf.org' > > > Subject: RE: supporitng blacklists, was: Re: [Simple]=20 > > > Comments on: First > > > draft of text on semantic-based authorization policies=20 > [exceptions] > > >=20 > > >=20 > > > -- cc to geopriv ml > > >=20 > > > hi jonathan,=20 > > >=20 > > > you propose an action with is a deny. doesn't this conflict=20 > > > with the goals > > > expressed in the common policy draft ( > > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common- > > > policy-00.txt) > > > where Section 4 (Goals and Assumptions) specifies 'Permit=20 > > > only' actions are > > > allowed. do you suggest that we modifying our=20 > > > goals/assumptions or do i miss > > > something? > > >=20 > > > ciao > > > hannes > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Thursday, March 25, 2004 4:43 PM > > > > To: Ben Campbell > > > > Cc: Ted Hardie; Henning Schulzrinne; Markus.Isomaki@nokia.com; > > > > simple@ietf.org > > > > Subject: Re: supporitng blacklists, was: Re: [Simple]=20 > > > > Comments on: First > > > > draft of text on semantic-based authorization policies=20 > > [exceptions] > > > >=20 > > > >=20 > > > > You can still achieve the functionality you want, Ben,=20 > > > > without requiring=20 > > > > the new rule Henning had proposed: > > > >=20 > > > > > > > > > > > > > > > > example.com > > > > joe > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > joe > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > >=20 > > > >=20 > > > > Of course, you need to be careful that the user joe is not a=20 > > > > member of=20 > > > > any other rule which grants a permission greater than=20 > > > > "deny-subscription", but thats a fundamental property of=20 > > > the model in=20 > > > > general. > > > >=20 > > > > -Jonathan R. > > > >=20 > > > > Ben Campbell wrote: > > > >=20 > > > > > Ted Hardie wrote: > > > > >=20 > > > > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote: > > > > >> > > > > >>> "Everybody in the world, in any domain, gets to *ask* to=20 > > > > subscribe to=20 > > > > >>> my presence, but Alice, Bob and Carol have already been=20 > > > > told to take=20 > > > > >>> a hike and thus shouldn't even be able to ask." > > > > >>> > > > > >>> Is this the type of rule we want to be to support? > > > > >> > > > > >> > > > > >> > > > > >> It's seems to me to be a lot easier just to keep telling=20 > > > > them to take=20 > > > > >> a hike > > > > >> whenever they ask; is there a reason to optimize for this=20 > > > > case that I'm > > > > >> missing? > > > > >=20 > > > > >=20 > > > > > The act of asking can become a kind of harrassment. Some=20 > > > > time ago, I had=20 > > > > > a yahoo messenger user that continuously asked permission=20 > > > > to watch my=20 > > > > > presence, but refused to identify themselves to me. This=20 > > > > continued after=20 > > > > > I asked them to desist. Fortunately, yahoo messenger=20 > > > > allowed me to block=20 > > > > > that ID, so I no longer get bothered by them. > > > > >=20 > > > >=20 > > > > --=20 > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, NJ=20 > > > 07054-2711 > > > > dynamicsoft > > > > jdrosen@dynamicsoft.com FAX: =20 > (973) 952-5050 > > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 15:13:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28899 for ; Thu, 1 Apr 2004 15:13:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98Yx-000550-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 15:13:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98Y2-00050b-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 15:12:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B98Xm-0004w5-00; Thu, 01 Apr 2004 15:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98XW-0003o1-Ma; Thu, 01 Apr 2004 15:11:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jLJ-0003zm-Nc for simple@optimus.ietf.org; Wed, 31 Mar 2004 12:17:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02285 for ; Wed, 31 Mar 2004 12:17:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8jLI-0004nN-00 for simple@ietf.org; Wed, 31 Mar 2004 12:17:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8jKD-0004kq-00 for simple@ietf.org; Wed, 31 Mar 2004 12:16:26 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8jJJ-0004gF-00; Wed, 31 Mar 2004 12:15:29 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 31 Mar 2004 09:21:15 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2VHEkKj009095; Wed, 31 Mar 2004 09:14:46 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA29513; Wed, 31 Mar 2004 09:14:43 -0800 (PST) Message-Id: <4.3.2.7.2.20040331111010.03d98d68@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tschofenig Hannes , "'Jonathan Rosenberg'" , Ben Campbell From: "James M. Polk" Cc: Ted Hardie , Henning Schulzrinne , Markus.Isomaki@nokia.com, simple@ietf.org, "'geopriv@ietf.org'" In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685F50@mchp905a.mch.sbs. de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Simple] Re: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First d raft of text on semantic-based authorization policies [exceptions] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 31 Mar 2004 11:14:55 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Jonathan I'm curious about this as well - as it appears that you have a non-permissions statement in the XML with I could be wrong, but want confirmation I'm wrong here. At 01:48 PM 3/31/2004 +0200, Tschofenig Hannes wrote: >-- cc to geopriv ml > >hi jonathan, > >you propose an action with is a deny. doesn't this conflict with the goals >expressed in the common policy draft ( >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.txt) >where Section 4 (Goals and Assumptions) specifies 'Permit only' actions are >allowed. do you suggest that we modifying our goals/assumptions or do i miss >something? > >ciao >hannes > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, March 25, 2004 4:43 PM > > To: Ben Campbell > > Cc: Ted Hardie; Henning Schulzrinne; Markus.Isomaki@nokia.com; > > simple@ietf.org > > Subject: Re: supporitng blacklists, was: Re: [Simple] > > Comments on: First > > draft of text on semantic-based authorization policies [exceptions] > > > > > > You can still achieve the functionality you want, Ben, > > without requiring > > the new rule Henning had proposed: > > > > > > > > > > example.com > > joe > > > > > > > > > > > > > > > > > > > > > > > > joe > > > > > > > > > > > > > > > > > > > > Of course, you need to be careful that the user joe is not a > > member of > > any other rule which grants a permission greater than > > "deny-subscription", but thats a fundamental property of the model in > > general. > > > > -Jonathan R. > > > > Ben Campbell wrote: > > > > > Ted Hardie wrote: > > > > > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote: > > >> > > >>> "Everybody in the world, in any domain, gets to *ask* to > > subscribe to > > >>> my presence, but Alice, Bob and Carol have already been > > told to take > > >>> a hike and thus shouldn't even be able to ask." > > >>> > > >>> Is this the type of rule we want to be to support? > > >> > > >> > > >> > > >> It's seems to me to be a lot easier just to keep telling > > them to take > > >> a hike > > >> whenever they ask; is there a reason to optimize for this > > case that I'm > > >> missing? > > > > > > > > > The act of asking can become a kind of harrassment. Some > > time ago, I had > > > a yahoo messenger user that continuously asked permission > > to watch my > > > presence, but refused to identify themselves to me. This > > continued after > > > I asked them to desist. Fortunately, yahoo messenger > > allowed me to block > > > that ID, so I no longer get bothered by them. > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 1 15:13:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28958 for ; Thu, 1 Apr 2004 15:13:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98Z0-0004rR-NJ for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 15:13:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31KDMqE018685 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 15:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98Z0-0004qG-1P for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 15:13:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28917 for ; Thu, 1 Apr 2004 15:13:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98Yy-000556-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 15:13:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98Y3-00050k-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 15:12:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B98Xm-0004w5-00; Thu, 01 Apr 2004 15:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98XW-0003o1-Ma; Thu, 01 Apr 2004 15:11:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jLJ-0003zm-Nc for simple@optimus.ietf.org; Wed, 31 Mar 2004 12:17:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02285 for ; Wed, 31 Mar 2004 12:17:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8jLI-0004nN-00 for simple@ietf.org; Wed, 31 Mar 2004 12:17:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8jKD-0004kq-00 for simple@ietf.org; Wed, 31 Mar 2004 12:16:26 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8jJJ-0004gF-00; Wed, 31 Mar 2004 12:15:29 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 31 Mar 2004 09:21:15 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2VHEkKj009095; Wed, 31 Mar 2004 09:14:46 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA29513; Wed, 31 Mar 2004 09:14:43 -0800 (PST) Message-Id: <4.3.2.7.2.20040331111010.03d98d68@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tschofenig Hannes , "'Jonathan Rosenberg'" , Ben Campbell From: "James M. Polk" Cc: Ted Hardie , Henning Schulzrinne , Markus.Isomaki@nokia.com, simple@ietf.org, "'geopriv@ietf.org'" In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685F50@mchp905a.mch.sbs. de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Simple] Re: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First d raft of text on semantic-based authorization policies [exceptions] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 31 Mar 2004 11:14:55 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Jonathan I'm curious about this as well - as it appears that you have a non-permissions statement in the XML with I could be wrong, but want confirmation I'm wrong here. At 01:48 PM 3/31/2004 +0200, Tschofenig Hannes wrote: >-- cc to geopriv ml > >hi jonathan, > >you propose an action with is a deny. doesn't this conflict with the goals >expressed in the common policy draft ( >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.txt) >where Section 4 (Goals and Assumptions) specifies 'Permit only' actions are >allowed. do you suggest that we modifying our goals/assumptions or do i miss >something? > >ciao >hannes > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, March 25, 2004 4:43 PM > > To: Ben Campbell > > Cc: Ted Hardie; Henning Schulzrinne; Markus.Isomaki@nokia.com; > > simple@ietf.org > > Subject: Re: supporitng blacklists, was: Re: [Simple] > > Comments on: First > > draft of text on semantic-based authorization policies [exceptions] > > > > > > You can still achieve the functionality you want, Ben, > > without requiring > > the new rule Henning had proposed: > > > > > > > > > > example.com > > joe > > > > > > > > > > > > > > > > > > > > > > > > joe > > > > > > > > > > > > > > > > > > > > Of course, you need to be careful that the user joe is not a > > member of > > any other rule which grants a permission greater than > > "deny-subscription", but thats a fundamental property of the model in > > general. > > > > -Jonathan R. > > > > Ben Campbell wrote: > > > > > Ted Hardie wrote: > > > > > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote: > > >> > > >>> "Everybody in the world, in any domain, gets to *ask* to > > subscribe to > > >>> my presence, but Alice, Bob and Carol have already been > > told to take > > >>> a hike and thus shouldn't even be able to ask." > > >>> > > >>> Is this the type of rule we want to be to support? > > >> > > >> > > >> > > >> It's seems to me to be a lot easier just to keep telling > > them to take > > >> a hike > > >> whenever they ask; is there a reason to optimize for this > > case that I'm > > >> missing? > > > > > > > > > The act of asking can become a kind of harrassment. Some > > time ago, I had > > > a yahoo messenger user that continuously asked permission > > to watch my > > > presence, but refused to identify themselves to me. This > > continued after > > > I asked them to desist. Fortunately, yahoo messenger > > allowed me to block > > > that ID, so I no longer get bothered by them. > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 17:52:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05881 for ; Thu, 1 Apr 2004 17:52:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9B2v-0005v9-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 17:52:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9B21-0005qH-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 17:51:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9B1Z-0005lB-00; Thu, 01 Apr 2004 17:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B994Q-0005jJ-Fm; Thu, 01 Apr 2004 15:45:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95hF-0001Y8-Nl for simple@optimus.ietf.org; Thu, 01 Apr 2004 12:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16628 for ; Thu, 1 Apr 2004 10:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9453-0005uP-00 for simple@ietf.org; Thu, 01 Apr 2004 10:26:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B944A-0005oI-00 for simple@ietf.org; Thu, 01 Apr 2004 10:25:15 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B943k-0005kB-00 for simple@ietf.org; Thu, 01 Apr 2004 10:24:53 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31FOaF00559; Thu, 1 Apr 2004 18:24:36 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 18:24:24 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i31FOOaK008559; Thu, 1 Apr 2004 18:24:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00BHZA5V; Thu, 01 Apr 2004 18:24:22 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31FOHs13077; Thu, 1 Apr 2004 18:24:17 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 18:24:00 +0300 Message-ID: <406C3411.8080606@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell CC: SIMPLE mailing list Subject: Re: [Simple] MSRP update References: <406B538C.3010408@dynamicsoft.com> In-Reply-To: <406B538C.3010408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 15:24:00.0359 (UTC) FILETIME=[5B90AF70:01C417FD] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 18:24:01 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben: Thanks for posting "working versions". I have a few comments: 1) By reading sections 6.4 and 6.5, it is not clear to me, in case the a=path contains several URLs, which one represents the endpoint and which one the relays. In 6.4 you wrote: "If the path attribute received from the peer contains more than one URL, then the remote URL is the first one". So I would expect a=path:remote_host, relay_2, relay_1 However, in 6.5, you wrote: "When an endpoint receives more than one URL in a path header, only the first entry is relevant for purposes of resolving the address and port, and establishing the network connection". According to 6.4, the first entry points to the remote host, not the relay, but I would expect the endpoint to establish a connection to the relay. I see a mismatch between 6.5 and 6.5. Perhaps you can clarify this in the draft. 2) Connection management (section 7.2). It is written that an endpoint should re-use an existing connection when the peer URL matches the host part. Isn't this in contradiction with the text in section 5.1 that says, when a large file is to be sent, the endpoint should create a new MSRP session to avoid blocking? I would expect that "creating a new session" comprises creating a new TCP connection as well, not re-using an existing one. We have similar procedures in 7.5.1, second bullet point for the answer. 3) I noticed the Content-Type is now an MSRP header, but the content is a quoted string. Is there any reason to have a quoted string there? I noticed that SIP and HTTP does not encode this header field value in quotes. 4) If you remember and old e-mail I sent you some time ago, the MSRP URL misses the "@" sign after the "userinfo". Also, there is a mixture of quotes (" and '). IMHO the correct definition should be: msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource] Regards, Miguel Ben Campbell wrote: > The chairs have requested that we put MSRP on a "release early and > often" track. That is, rather than waiting until I have all the planned > updates completed, I will put out a revision for each significant update. > > Therefore I will be submitting a revised MSRP base spec draft either > this evening (Wednesday) or Thursday, followed by a series of revisions > over the next few weeks. > > This revision will include changes to MSRP URL handling and connection > handling needed to allow relays to be used. As we discussed in Korea, it > will not describe relays themselves; this will be handled in a separate > draft. But there were a number of base specification changes needed to > make it possible to integrate relays. > > We are working from a number of assumptions about how relays will work, > even though the MSRP relay draft is pending: > > --Relays are session-stateless > > --Relay chains are source routed, with the route negotiated in the SDP. > > -- Transactions are hop-by-hop, and downstream transactions do not > depend on upstream transactions. > > Specific changes in this revision: > > -- The answerer always opens the TCP connection to the offerer. The > comedia like direction negotiation is removed. > > -- Shared connections are allowed. > > -- MSRP URLs identify a destination within a session, rather than the > entire session itself. MSRP requests will now have a To field describing > the destination, and a From field describing the source. The sdp > negotiation allows each endpoint to contribute its URL. > > -- To enable routing across relays, an SDP request can carry a list of > URLs. We expect this to be used with relays to describe a route across > relays. The base spec will not say how one would determine a list of > more than one URL, but it does require an endpoint to be able to receive > such a list and process it reasonably. Basically, if you receive a list, > you put the entire list in To headers on SEND requests. This will work > even if the receiver wants to contribute their own relays to the path, > but that belongs in the relay spec, not the base. > > There are still a number of outstanding items we discussed in Korea,that > will be required to allow relay integration, but are not covered by this > revision: > > -- DSN handling and negotiation. Since relays will be able to originate > DSNs, even endpoints that don't understand relays will need to be able > to receive them. > > -- Chunking > > -- Using message bounderies instead of length fields for message > framing, so you can abort a request without destroying framing for the > connection. > > -- Orit requested that we allow a mode where there are no transaction > responses. She has agreed to document the motivation for this. I will > hold any changes based on this request until after the work group has a > chance to discuss that document. > > -- a few outstanding, non-controversial items, such as allowing all > standard MIME headers. > > Watch this channel for revisions covering these items in the very near > future. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailman-admin@ietf.org Thu Apr 1 18:29:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09121 for ; Thu, 1 Apr 2004 18:29:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bcq-0001zx-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 18:29:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Bbx-0001u7-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 18:28:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9BbA-0001nn-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 18:27:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99QB-00054N-27 for simple-archive@ietf.org; Thu, 01 Apr 2004 16:08:19 -0500 Date: Thu, 01 Apr 2004 11:19:20 -0500 Message-ID: <20040401161920.11029.42439.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From simple-admin@ietf.org Thu Apr 1 19:22:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13399 for ; Thu, 1 Apr 2004 19:22:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CS3-0001CW-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 19:22:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9CR6-000153-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 19:21:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9CQ8-0000vI-00; Thu, 01 Apr 2004 19:20:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9A9r-0007SM-F1; Thu, 01 Apr 2004 16:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95Vt-0001E1-Qn for simple@optimus.ietf.org; Thu, 01 Apr 2004 11:57:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17950 for ; Thu, 1 Apr 2004 11:06:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94hr-000212-00 for simple@ietf.org; Thu, 01 Apr 2004 11:06:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94h4-0001uP-00 for simple@ietf.org; Thu, 01 Apr 2004 11:05:27 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B94gU-0001ob-00 for simple@ietf.org; Thu, 01 Apr 2004 11:04:50 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i31G4mIw035950; Thu, 1 Apr 2004 10:04:49 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <406C3DA0.2010000@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list Subject: Re: [Simple] MSRP update References: <406B538C.3010408@dynamicsoft.com> <406C3411.8080606@nokia.com> In-Reply-To: <406C3411.8080606@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 10:04:48 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > Ben: > > Thanks for posting "working versions". I have a few comments: > > 1) By reading sections 6.4 and 6.5, it is not clear to me, in case the > a=path contains several URLs, which one represents the endpoint and > which one the relays. > > In 6.4 you wrote: "If the path attribute received from the peer contains > more than one URL, then the remote URL is the first one". > > So I would expect a=path:remote_host, relay_2, relay_1 The idea is, the remote host is the one an endpoint actually connects to and visits. So if you had relays, the remote URL actually points to a relay. So you would really be looking at: a=path:relay_1, relay_2, remote_host. > > However, in 6.5, you wrote: "When an endpoint receives more than one URL > in a path header, only the first entry is relevant for purposes of > resolving the address and port, and establishing the network connection". A non-relay aware endpoint really only ever has to care about the first entry. It includes the entire path in the To headers so that any relays can do the right thing. > > According to 6.4, the first entry points to the remote host, not the > relay, but I would expect the endpoint to establish a connection to the > relay. > > I see a mismatch between 6.5 and 6.5. Perhaps you can clarify this in > the draft. > Do you mean between 6.4 and 6.5? Or do I have a section number conflict? I can see how the current wording is confusing. I struggled with the terminology here, and am very open to suggestion. Particularly if we decide an endpoint needs to distinguish between the first-hop URL and the remote-host URL for any reason. > > > 2) Connection management (section 7.2). It is written that an endpoint > should re-use an existing connection when the peer URL matches the host > part. Isn't this in contradiction with the text in section 5.1 that > says, when a large file is to be sent, the endpoint should create a new > MSRP session to avoid blocking? I would expect that "creating a new > session" comprises creating a new TCP connection as well, not re-using > an existing one. > > We have similar procedures in 7.5.1, second bullet point for the answer. > Yes, that needs to be rationalized. I believe I put in an open issue asking if we need to discuss situations where an endpoint would intentionally choose not to share a connection between session. (Unless I forgot. It happens). There have been suggestions that we would remove the suggestion to create a new session once we have chunking described in the draft. Does anyone have thoughts on this point? > > 3) I noticed the Content-Type is now an MSRP header, but the content is > a quoted string. Is there any reason to have a quoted string there? I > noticed that SIP and HTTP does not encode this header field value in > quotes. > > I honestly don't remember why we chose quoted-string. It is possible there was no good reason. I will check into this. (If anyone remembers, please speak up now.) > > 4) If you remember and old e-mail I sent you some time ago, the MSRP URL > misses the "@" sign after the "userinfo". Also, there is a mixture of > quotes (" and '). IMHO the correct definition should be: > > msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource] > > Darn. I thought I had fixed than in the _previous_ version. I will fix in the next. > > Regards, > > Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 20:58:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21781 for ; Thu, 1 Apr 2004 20:58:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Dx2-0007Zk-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 20:58:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Dvj-0007FX-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 20:57:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9DuK-0006w7-00; Thu, 01 Apr 2004 20:55:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ACX-0007ns-Lh; Thu, 01 Apr 2004 16:58:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95LN-00011G-Ld for simple@optimus.ietf.org; Thu, 01 Apr 2004 11:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17309 for ; Thu, 1 Apr 2004 10:53:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94VJ-0000Pt-00 for simple@ietf.org; Thu, 01 Apr 2004 10:53:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94UK-0000KC-00 for simple@ietf.org; Thu, 01 Apr 2004 10:52:17 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B94U4-0000Fg-00 for simple@ietf.org; Thu, 01 Apr 2004 10:52:01 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i31FovIw034618; Thu, 1 Apr 2004 09:50:58 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <406C3A61.5080907@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: hisham.khartabil@nokia.com, oritl@microsoft.com, vkg@lucent.com, vikas@arciis.com, simple@ietf.org, rohan@cisco.com, aki.niemi@nokia.com Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <45730E094814E44488F789C1CDED27AE0219B248@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B248@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 09:50:57 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Chris Boulton wrote: > I agree with Ben. If an entity requests delivery confirmation, it > cannot rely on the absence of a failure DSN to convey that the message > was delivered successfully. So I feel that there is scope for both > failure/success DSN's and a requirement for appropriate text describing > procedures for the scenario where a positive DSN is requested BUT none > received. > > Out of interest - what are the current thoughts on exactly how a client > will request a DSN conformation? I don't think we have consensus on that yet for MSRP. I originally leaned towards doing it in the content-type negotiation in the SDP exchange. but it has been pointed out to me that certain messages (isComposing, and DSNs themselves, for example) might require different treatment than user content messages. Rather than specifying treatment for different classes of messages, it may make more sense to add an optional flag the messages themselves, or possibly create a new method for carrying such "status" messages. > > > Chris. > > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 01 April 2004 02:46 >>To: hisham.khartabil@nokia.com >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > > simple@ietf.org; > >>rohan@cisco.com; aki.niemi@nokia.com >>Subject: Re: [Simple] return receipt and delivery status notification > > for > >>MSRP >> >>I don't think so. Imagine the following scenario: >> >>A---R1---R2---B >> >>A sends a critically important message to B, telling B to buy stock in >>messaging companies. >> >>A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >>fails to send to B. So he tries to send a negative DSN to A via R1. But >>it turns out the failure killed all connectivity to and from R2, so he >>cannot send it. >> >>The moral is, DSNs can fail just like any other kind of message. So if > > a > >>message absolutely positively must be delivered, you need to be able to >>request positive DSN. Then A can at least notice it did not receive a >>DSN, and act accordingly. >> >> >>hisham.khartabil@nokia.com wrote: >> >>>My question was: How useful is it to have both notification modes >> >>(positive and negative) for session IMs? Isn't notification on failure >>enough? >> >>>/Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>Sent: 01.April.2004 01:45 >>>>To: Orit Levin >>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>(Nokia-M/Espoo) >>>>Subject: Re: [Simple] return receipt and delivery status notification >>>>for MSRP >>>> >>>> >>>> >>>>As Orit says, DSN will be very important for MSRP. >>>> >>>>The current thinking is that MSRP relays will be session >>>>stateless, and >>>>that transactions are entirely hop-by-hop. The relay >>>>semantics would be >>>>similar to those of the SIMS draft, with MSRP syntax. >>>> >>>>As Orit hinted, this means that a transaction response is merely an >>>>indication that the transaction succeeded, not that the message has >>>>reached its destination. So in non peer-to-peer sessions, DSN >>>>is critical. >>>> >>>>We do expect it to be optional, as it is much less useful in the >>>>peer-to-peer case, where is just constitutes redundant messaging. >>>> >>>>Orit Levin wrote: >>>> >>>> >>>>>Hisham, >>>>>It is VERY useful because >>>>> >>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you whether the >>>>>message was actually delivered end-to-end. >>>>>2. MSRP hop-by-hop application-timer-based mechanism >>>> >>>>doesn't prevent you >>>> >>>>>from getting negative acknowledge in a case when the message was >>>> >>>>>actually delivered to the destination. In other words, it >>>> >>>>doesn't solve >>>> >>>> >>>>>a duplication problem. >>>>> >>>>>I would like to add the requirement that the "end-to-end" >>>> >>>>DSN receipt >>>> >>>> >>>>>needs to be requested per message (not negotiated for the >>>> >>>>whole session >>>> >>>> >>>>>for all messages). It will allow for writing different IM behaviors >>>>>using the same mechanism. Such as: >>>>> >>>>>1. Loose IM session: all the user messages are sent without >>>> >>>>receipt, but >>>> >>>> >>>>>the application sends a heartbeat message with requesting a >>>> >>>>receipt for >>>> >>>> >>>>>each. >>>>>2. Typical IM session: For all user messages a receipt is >>>> >>>>requested but >>>> >>>> >>>>>the indication messages (e.g. "The user is typing") are delivered >>>>>without any receipt. >>>>> >>>>>Thanks, >>>>>Orit. >>>>> >>>>>-----Original Message----- >>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>>> >>>>On Behalf Of >>>> >>>> >>>>>hisham.khartabil@nokia.com >>>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>>To: vkg@lucent.com >>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >>>>>aki.niemi@nokia.com >>>>>Subject: RE: [Simple] return receipt and delivery status >>>> >>>>notification >>>> >>>> >>>>>for MSRP >>>>> >>>>>This is a good summary, although point 4 can be debatable: >>>> >>>>How useful is >>>> >>>> >>>>>it to request receive notification in session mode? >>>>> >>>>>/Hisham >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>>Sent: 04.March.2004 16:53 >>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>>(Nokia-M/Espoo) >>>>>>Subject: Re: [Simple] return receipt and delivery status >>>> >>>>notification >>>> >>>> >>>>>>for MSRP >>>>>> >>>>>> >>>>>> >>>>>>hisham.khartabil@nokia.com wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>It is optional. If it is annoying to you, then you don't request a >>>>>>>delivery notification. It is not every time and it is not >>>> >>>>mandatory. >>>> >>>> >>>>>>So, just to be pedantic, please correct me if my summary below is >>>>>>wrong: >>>>>> >>>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>>> _protocol_ level (i.e. the transactional model at the >>>>>> protocol level is sufficient for protocol state >>>>>> machines to figure out if an IM was delivered to the >>>>>> next hop successfully or not). >>>>>> 2/ We should design protocol provisions such that a positive >>>>>> acknowledgement DSN model is supported (let me know >>>>>> the current state of the IM: queued, delivered, read, >>>>>> being responded to, ...). >>>>>> 3/ We should design protocol provisions such that a negative >>>>>> acknowledgement DSN model is supported (send it and >>>>>> forget it unless something drastic happens, then >>>>>> let me know). >>>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>>> mode IMs. >>>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>>> user. >>>>>> >>>>>>Is this accurate? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>- vijay >>>>>>-- >>>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>>Wireless Networks Group/Internet Software and Services Lucent >>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 1 20:58:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21828 for ; Thu, 1 Apr 2004 20:58:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Dx8-0007b3-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 20:58:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Dvs-0007Gr-00 for simple-archive@ietf.org; Thu, 01 Apr 2004 20:57:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9DuW-0006zJ-00; Thu, 01 Apr 2004 20:55:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ACZ-0007oC-7M; Thu, 01 Apr 2004 16:58:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97Go-0008Gw-KJ for simple@optimus.ietf.org; Thu, 01 Apr 2004 13:50:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25558 for ; Thu, 1 Apr 2004 13:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B97Gc-0004bA-00 for simple@ietf.org; Thu, 01 Apr 2004 13:50:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B97Fj-0004Wf-00 for simple@ietf.org; Thu, 01 Apr 2004 13:49:23 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1B97FI-0004RS-00 for simple@ietf.org; Thu, 01 Apr 2004 13:48:56 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 10:48:31 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 1 Apr 2004 10:48:13 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Apr 2004 10:48:20 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 10:48:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-3db4dc33-6718-4dad-8e86-fe0f847e4de9" Message-ID: Thread-Topic: GRUU, device and un-REGISTER with * Thread-Index: AcQYGelPoq86ZOCHS5mvK6rBhiTqJw== From: "Orit Levin" To: , "Jonathan Rosenberg" X-OriginalArrivalTime: 01 Apr 2004 18:48:06.0706 (UTC) FILETIME=[DEF4F120:01C41819] Subject: [Simple] GRUU, device and un-REGISTER with * Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 10:48:24 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, MIME_BOUND_NEXTPART autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPartTM-000-3db4dc33-6718-4dad-8e86-fe0f847e4de9 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41819.E82A998C" ------_=_NextPart_001_01C41819.E82A998C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, Now when we have GRUU, device identifier and the expanded registration procedure, what would be the meaning of un-REGISTER with *? It makes a lot of sense to un-REGISTER a specific device with all its contacts at once. Some would say that it is more useful (and reasonable from authentication/security point of view) than un-REGISTERing all the devices of the same user at once. =20 I personally think that we need both semantics and the syntax for each needs to be defined/agreed upon. =20 Thanks, Orit. ------_=_NextPart_001_01C41819.E82A998C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Guys,
Now = when we have=20 GRUU, device identifier and the expanded registration procedure, = what would=20 be the meaning of un-REGISTER with *?
It = makes a lot of=20 sense to un-REGISTER a specific device with all its contacts at once. = Some would=20 say that it is more useful (and reasonable from authentication/security = point of=20 view) than un-REGISTERing all the devices of the same user at=20 once.
 
I = personally think=20 that we need both semantics and the syntax for each needs to = be=20 defined/agreed upon.
 
Thanks,
Orit.
------_=_NextPart_001_01C41819.E82A998C-- ------=_NextPartTM-000-3db4dc33-6718-4dad-8e86-fe0f847e4de9-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 1 23:59:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09036 for ; Thu, 1 Apr 2004 23:59:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Dyz-0000kR-Ee for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 21:00:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3220XxC002871 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 21:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BYv-0006Ir-If for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:25:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08773 for ; Thu, 1 Apr 2004 18:25:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BYs-0001Xr-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 18:25:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BY2-0001Sc-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 18:24:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9BXA-0001Mm-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 18:23:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99L9-0003Ao-3W for simple-web-archive@ietf.org; Thu, 01 Apr 2004 16:03:07 -0500 Date: Thu, 01 Apr 2004 11:18:24 -0500 Message-ID: <20040401161824.11029.49014.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-web-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org fuasex https://www1.ietf.org/mailman/options/simple/simple-web-archive%40ietf.org From exim@www1.ietf.org Fri Apr 2 00:13:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10090 for ; Fri, 2 Apr 2004 00:13:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E5o-0004dh-9t for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 21:07:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3227aaa017829 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 21:07:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9B2y-0003JS-VT for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 17:52:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05901 for ; Thu, 1 Apr 2004 17:52:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9B2w-0005vE-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 17:52:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9B22-0005qO-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 17:51:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9B1Z-0005lB-00; Thu, 01 Apr 2004 17:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B994Q-0005jJ-Fm; Thu, 01 Apr 2004 15:45:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95hF-0001Y8-Nl for simple@optimus.ietf.org; Thu, 01 Apr 2004 12:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16628 for ; Thu, 1 Apr 2004 10:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9453-0005uP-00 for simple@ietf.org; Thu, 01 Apr 2004 10:26:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B944A-0005oI-00 for simple@ietf.org; Thu, 01 Apr 2004 10:25:15 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B943k-0005kB-00 for simple@ietf.org; Thu, 01 Apr 2004 10:24:53 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31FOaF00559; Thu, 1 Apr 2004 18:24:36 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 18:24:24 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i31FOOaK008559; Thu, 1 Apr 2004 18:24:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00BHZA5V; Thu, 01 Apr 2004 18:24:22 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31FOHs13077; Thu, 1 Apr 2004 18:24:17 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 18:24:00 +0300 Message-ID: <406C3411.8080606@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell CC: SIMPLE mailing list Subject: Re: [Simple] MSRP update References: <406B538C.3010408@dynamicsoft.com> In-Reply-To: <406B538C.3010408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 15:24:00.0359 (UTC) FILETIME=[5B90AF70:01C417FD] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 18:24:01 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben: Thanks for posting "working versions". I have a few comments: 1) By reading sections 6.4 and 6.5, it is not clear to me, in case the a=path contains several URLs, which one represents the endpoint and which one the relays. In 6.4 you wrote: "If the path attribute received from the peer contains more than one URL, then the remote URL is the first one". So I would expect a=path:remote_host, relay_2, relay_1 However, in 6.5, you wrote: "When an endpoint receives more than one URL in a path header, only the first entry is relevant for purposes of resolving the address and port, and establishing the network connection". According to 6.4, the first entry points to the remote host, not the relay, but I would expect the endpoint to establish a connection to the relay. I see a mismatch between 6.5 and 6.5. Perhaps you can clarify this in the draft. 2) Connection management (section 7.2). It is written that an endpoint should re-use an existing connection when the peer URL matches the host part. Isn't this in contradiction with the text in section 5.1 that says, when a large file is to be sent, the endpoint should create a new MSRP session to avoid blocking? I would expect that "creating a new session" comprises creating a new TCP connection as well, not re-using an existing one. We have similar procedures in 7.5.1, second bullet point for the answer. 3) I noticed the Content-Type is now an MSRP header, but the content is a quoted string. Is there any reason to have a quoted string there? I noticed that SIP and HTTP does not encode this header field value in quotes. 4) If you remember and old e-mail I sent you some time ago, the MSRP URL misses the "@" sign after the "userinfo". Also, there is a mixture of quotes (" and '). IMHO the correct definition should be: msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource] Regards, Miguel Ben Campbell wrote: > The chairs have requested that we put MSRP on a "release early and > often" track. That is, rather than waiting until I have all the planned > updates completed, I will put out a revision for each significant update. > > Therefore I will be submitting a revised MSRP base spec draft either > this evening (Wednesday) or Thursday, followed by a series of revisions > over the next few weeks. > > This revision will include changes to MSRP URL handling and connection > handling needed to allow relays to be used. As we discussed in Korea, it > will not describe relays themselves; this will be handled in a separate > draft. But there were a number of base specification changes needed to > make it possible to integrate relays. > > We are working from a number of assumptions about how relays will work, > even though the MSRP relay draft is pending: > > --Relays are session-stateless > > --Relay chains are source routed, with the route negotiated in the SDP. > > -- Transactions are hop-by-hop, and downstream transactions do not > depend on upstream transactions. > > Specific changes in this revision: > > -- The answerer always opens the TCP connection to the offerer. The > comedia like direction negotiation is removed. > > -- Shared connections are allowed. > > -- MSRP URLs identify a destination within a session, rather than the > entire session itself. MSRP requests will now have a To field describing > the destination, and a From field describing the source. The sdp > negotiation allows each endpoint to contribute its URL. > > -- To enable routing across relays, an SDP request can carry a list of > URLs. We expect this to be used with relays to describe a route across > relays. The base spec will not say how one would determine a list of > more than one URL, but it does require an endpoint to be able to receive > such a list and process it reasonably. Basically, if you receive a list, > you put the entire list in To headers on SEND requests. This will work > even if the receiver wants to contribute their own relays to the path, > but that belongs in the relay spec, not the base. > > There are still a number of outstanding items we discussed in Korea,that > will be required to allow relay integration, but are not covered by this > revision: > > -- DSN handling and negotiation. Since relays will be able to originate > DSNs, even endpoints that don't understand relays will need to be able > to receive them. > > -- Chunking > > -- Using message bounderies instead of length fields for message > framing, so you can abort a request without destroying framing for the > connection. > > -- Orit requested that we allow a mode where there are no transaction > responses. She has agreed to document the motivation for this. I will > hold any changes based on this request until after the work group has a > chance to discuss that document. > > -- a few outstanding, non-controversial items, such as allowing all > standard MIME headers. > > Watch this channel for revisions covering these items in the very near > future. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 03:16:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28205 for ; Fri, 2 Apr 2004 03:16:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9EBH-0007R5-LH for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 21:13:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322DFtS028578 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 21:13:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9CS5-00088h-Tc for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 19:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13417 for ; Thu, 1 Apr 2004 19:22:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CS4-0001Cb-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 19:22:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9CR7-00015B-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 19:21:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9CQ8-0000vI-00; Thu, 01 Apr 2004 19:20:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9A9r-0007SM-F1; Thu, 01 Apr 2004 16:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95Vt-0001E1-Qn for simple@optimus.ietf.org; Thu, 01 Apr 2004 11:57:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17950 for ; Thu, 1 Apr 2004 11:06:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94hr-000212-00 for simple@ietf.org; Thu, 01 Apr 2004 11:06:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94h4-0001uP-00 for simple@ietf.org; Thu, 01 Apr 2004 11:05:27 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B94gU-0001ob-00 for simple@ietf.org; Thu, 01 Apr 2004 11:04:50 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i31G4mIw035950; Thu, 1 Apr 2004 10:04:49 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <406C3DA0.2010000@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list Subject: Re: [Simple] MSRP update References: <406B538C.3010408@dynamicsoft.com> <406C3411.8080606@nokia.com> In-Reply-To: <406C3411.8080606@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 10:04:48 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > Ben: > > Thanks for posting "working versions". I have a few comments: > > 1) By reading sections 6.4 and 6.5, it is not clear to me, in case the > a=path contains several URLs, which one represents the endpoint and > which one the relays. > > In 6.4 you wrote: "If the path attribute received from the peer contains > more than one URL, then the remote URL is the first one". > > So I would expect a=path:remote_host, relay_2, relay_1 The idea is, the remote host is the one an endpoint actually connects to and visits. So if you had relays, the remote URL actually points to a relay. So you would really be looking at: a=path:relay_1, relay_2, remote_host. > > However, in 6.5, you wrote: "When an endpoint receives more than one URL > in a path header, only the first entry is relevant for purposes of > resolving the address and port, and establishing the network connection". A non-relay aware endpoint really only ever has to care about the first entry. It includes the entire path in the To headers so that any relays can do the right thing. > > According to 6.4, the first entry points to the remote host, not the > relay, but I would expect the endpoint to establish a connection to the > relay. > > I see a mismatch between 6.5 and 6.5. Perhaps you can clarify this in > the draft. > Do you mean between 6.4 and 6.5? Or do I have a section number conflict? I can see how the current wording is confusing. I struggled with the terminology here, and am very open to suggestion. Particularly if we decide an endpoint needs to distinguish between the first-hop URL and the remote-host URL for any reason. > > > 2) Connection management (section 7.2). It is written that an endpoint > should re-use an existing connection when the peer URL matches the host > part. Isn't this in contradiction with the text in section 5.1 that > says, when a large file is to be sent, the endpoint should create a new > MSRP session to avoid blocking? I would expect that "creating a new > session" comprises creating a new TCP connection as well, not re-using > an existing one. > > We have similar procedures in 7.5.1, second bullet point for the answer. > Yes, that needs to be rationalized. I believe I put in an open issue asking if we need to discuss situations where an endpoint would intentionally choose not to share a connection between session. (Unless I forgot. It happens). There have been suggestions that we would remove the suggestion to create a new session once we have chunking described in the draft. Does anyone have thoughts on this point? > > 3) I noticed the Content-Type is now an MSRP header, but the content is > a quoted string. Is there any reason to have a quoted string there? I > noticed that SIP and HTTP does not encode this header field value in > quotes. > > I honestly don't remember why we chose quoted-string. It is possible there was no good reason. I will check into this. (If anyone remembers, please speak up now.) > > 4) If you remember and old e-mail I sent you some time ago, the MSRP URL > misses the "@" sign after the "userinfo". Also, there is a mixture of > quotes (" and '). IMHO the correct definition should be: > > msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource] > > Darn. I thought I had fixed than in the _previous_ version. I will fix in the next. > > Regards, > > Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 04:18:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00498 for ; Fri, 2 Apr 2004 04:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GZt-0002bl-Uv for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 23:46:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i324knn4010023 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 23:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Dx6-0007lF-2m for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 20:58:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21802 for ; Thu, 1 Apr 2004 20:58:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Dx3-0007a1-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 20:58:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Dvk-0007Fh-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 20:57:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9DuK-0006w7-00; Thu, 01 Apr 2004 20:55:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ACX-0007ns-Lh; Thu, 01 Apr 2004 16:58:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95LN-00011G-Ld for simple@optimus.ietf.org; Thu, 01 Apr 2004 11:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17309 for ; Thu, 1 Apr 2004 10:53:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94VJ-0000Pt-00 for simple@ietf.org; Thu, 01 Apr 2004 10:53:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94UK-0000KC-00 for simple@ietf.org; Thu, 01 Apr 2004 10:52:17 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B94U4-0000Fg-00 for simple@ietf.org; Thu, 01 Apr 2004 10:52:01 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i31FovIw034618; Thu, 1 Apr 2004 09:50:58 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <406C3A61.5080907@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: hisham.khartabil@nokia.com, oritl@microsoft.com, vkg@lucent.com, vikas@arciis.com, simple@ietf.org, rohan@cisco.com, aki.niemi@nokia.com Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <45730E094814E44488F789C1CDED27AE0219B248@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B248@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 09:50:57 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris Boulton wrote: > I agree with Ben. If an entity requests delivery confirmation, it > cannot rely on the absence of a failure DSN to convey that the message > was delivered successfully. So I feel that there is scope for both > failure/success DSN's and a requirement for appropriate text describing > procedures for the scenario where a positive DSN is requested BUT none > received. > > Out of interest - what are the current thoughts on exactly how a client > will request a DSN conformation? I don't think we have consensus on that yet for MSRP. I originally leaned towards doing it in the content-type negotiation in the SDP exchange. but it has been pointed out to me that certain messages (isComposing, and DSNs themselves, for example) might require different treatment than user content messages. Rather than specifying treatment for different classes of messages, it may make more sense to add an optional flag the messages themselves, or possibly create a new method for carrying such "status" messages. > > > Chris. > > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 01 April 2004 02:46 >>To: hisham.khartabil@nokia.com >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > > simple@ietf.org; > >>rohan@cisco.com; aki.niemi@nokia.com >>Subject: Re: [Simple] return receipt and delivery status notification > > for > >>MSRP >> >>I don't think so. Imagine the following scenario: >> >>A---R1---R2---B >> >>A sends a critically important message to B, telling B to buy stock in >>messaging companies. >> >>A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >>fails to send to B. So he tries to send a negative DSN to A via R1. But >>it turns out the failure killed all connectivity to and from R2, so he >>cannot send it. >> >>The moral is, DSNs can fail just like any other kind of message. So if > > a > >>message absolutely positively must be delivered, you need to be able to >>request positive DSN. Then A can at least notice it did not receive a >>DSN, and act accordingly. >> >> >>hisham.khartabil@nokia.com wrote: >> >>>My question was: How useful is it to have both notification modes >> >>(positive and negative) for session IMs? Isn't notification on failure >>enough? >> >>>/Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>Sent: 01.April.2004 01:45 >>>>To: Orit Levin >>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>(Nokia-M/Espoo) >>>>Subject: Re: [Simple] return receipt and delivery status notification >>>>for MSRP >>>> >>>> >>>> >>>>As Orit says, DSN will be very important for MSRP. >>>> >>>>The current thinking is that MSRP relays will be session >>>>stateless, and >>>>that transactions are entirely hop-by-hop. The relay >>>>semantics would be >>>>similar to those of the SIMS draft, with MSRP syntax. >>>> >>>>As Orit hinted, this means that a transaction response is merely an >>>>indication that the transaction succeeded, not that the message has >>>>reached its destination. So in non peer-to-peer sessions, DSN >>>>is critical. >>>> >>>>We do expect it to be optional, as it is much less useful in the >>>>peer-to-peer case, where is just constitutes redundant messaging. >>>> >>>>Orit Levin wrote: >>>> >>>> >>>>>Hisham, >>>>>It is VERY useful because >>>>> >>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you whether the >>>>>message was actually delivered end-to-end. >>>>>2. MSRP hop-by-hop application-timer-based mechanism >>>> >>>>doesn't prevent you >>>> >>>>>from getting negative acknowledge in a case when the message was >>>> >>>>>actually delivered to the destination. In other words, it >>>> >>>>doesn't solve >>>> >>>> >>>>>a duplication problem. >>>>> >>>>>I would like to add the requirement that the "end-to-end" >>>> >>>>DSN receipt >>>> >>>> >>>>>needs to be requested per message (not negotiated for the >>>> >>>>whole session >>>> >>>> >>>>>for all messages). It will allow for writing different IM behaviors >>>>>using the same mechanism. Such as: >>>>> >>>>>1. Loose IM session: all the user messages are sent without >>>> >>>>receipt, but >>>> >>>> >>>>>the application sends a heartbeat message with requesting a >>>> >>>>receipt for >>>> >>>> >>>>>each. >>>>>2. Typical IM session: For all user messages a receipt is >>>> >>>>requested but >>>> >>>> >>>>>the indication messages (e.g. "The user is typing") are delivered >>>>>without any receipt. >>>>> >>>>>Thanks, >>>>>Orit. >>>>> >>>>>-----Original Message----- >>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>>> >>>>On Behalf Of >>>> >>>> >>>>>hisham.khartabil@nokia.com >>>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>>To: vkg@lucent.com >>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >>>>>aki.niemi@nokia.com >>>>>Subject: RE: [Simple] return receipt and delivery status >>>> >>>>notification >>>> >>>> >>>>>for MSRP >>>>> >>>>>This is a good summary, although point 4 can be debatable: >>>> >>>>How useful is >>>> >>>> >>>>>it to request receive notification in session mode? >>>>> >>>>>/Hisham >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>>Sent: 04.March.2004 16:53 >>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>>(Nokia-M/Espoo) >>>>>>Subject: Re: [Simple] return receipt and delivery status >>>> >>>>notification >>>> >>>> >>>>>>for MSRP >>>>>> >>>>>> >>>>>> >>>>>>hisham.khartabil@nokia.com wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>It is optional. If it is annoying to you, then you don't request a >>>>>>>delivery notification. It is not every time and it is not >>>> >>>>mandatory. >>>> >>>> >>>>>>So, just to be pedantic, please correct me if my summary below is >>>>>>wrong: >>>>>> >>>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>>> _protocol_ level (i.e. the transactional model at the >>>>>> protocol level is sufficient for protocol state >>>>>> machines to figure out if an IM was delivered to the >>>>>> next hop successfully or not). >>>>>> 2/ We should design protocol provisions such that a positive >>>>>> acknowledgement DSN model is supported (let me know >>>>>> the current state of the IM: queued, delivered, read, >>>>>> being responded to, ...). >>>>>> 3/ We should design protocol provisions such that a negative >>>>>> acknowledgement DSN model is supported (send it and >>>>>> forget it unless something drastic happens, then >>>>>> let me know). >>>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>>> mode IMs. >>>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>>> user. >>>>>> >>>>>>Is this accurate? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>- vijay >>>>>>-- >>>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>>Wireless Networks Group/Internet Software and Services Lucent >>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 04:18:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00587 for ; Fri, 2 Apr 2004 04:18:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GZu-0002c7-6a for simple-archive@odin.ietf.org; Thu, 01 Apr 2004 23:46:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i324ko5d010040 for simple-archive@odin.ietf.org; Thu, 1 Apr 2004 23:46:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9DxB-0007nk-G3 for simple-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 20:58:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21830 for ; Thu, 1 Apr 2004 20:58:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Dx8-0007b7-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 20:58:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Dvt-0007Gz-00 for simple-web-archive@ietf.org; Thu, 01 Apr 2004 20:57:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9DuW-0006zJ-00; Thu, 01 Apr 2004 20:55:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ACZ-0007oC-7M; Thu, 01 Apr 2004 16:58:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97Go-0008Gw-KJ for simple@optimus.ietf.org; Thu, 01 Apr 2004 13:50:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25558 for ; Thu, 1 Apr 2004 13:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B97Gc-0004bA-00 for simple@ietf.org; Thu, 01 Apr 2004 13:50:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B97Fj-0004Wf-00 for simple@ietf.org; Thu, 01 Apr 2004 13:49:23 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1B97FI-0004RS-00 for simple@ietf.org; Thu, 01 Apr 2004 13:48:56 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 10:48:31 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 1 Apr 2004 10:48:13 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Apr 2004 10:48:20 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 10:48:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-3db4dc33-6718-4dad-8e86-fe0f847e4de9" Message-ID: Thread-Topic: GRUU, device and un-REGISTER with * Thread-Index: AcQYGelPoq86ZOCHS5mvK6rBhiTqJw== From: "Orit Levin" To: , "Jonathan Rosenberg" X-OriginalArrivalTime: 01 Apr 2004 18:48:06.0706 (UTC) FILETIME=[DEF4F120:01C41819] Subject: [Simple] GRUU, device and un-REGISTER with * Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 10:48:24 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, MIME_BOUND_NEXTPART autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPartTM-000-3db4dc33-6718-4dad-8e86-fe0f847e4de9 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41819.E82A998C" ------_=_NextPart_001_01C41819.E82A998C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, Now when we have GRUU, device identifier and the expanded registration procedure, what would be the meaning of un-REGISTER with *? It makes a lot of sense to un-REGISTER a specific device with all its contacts at once. Some would say that it is more useful (and reasonable from authentication/security point of view) than un-REGISTERing all the devices of the same user at once. =20 I personally think that we need both semantics and the syntax for each needs to be defined/agreed upon. =20 Thanks, Orit. ------_=_NextPart_001_01C41819.E82A998C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Guys,
Now = when we have=20 GRUU, device identifier and the expanded registration procedure, = what would=20 be the meaning of un-REGISTER with *?
It = makes a lot of=20 sense to un-REGISTER a specific device with all its contacts at once. = Some would=20 say that it is more useful (and reasonable from authentication/security = point of=20 view) than un-REGISTERing all the devices of the same user at=20 once.
 
I = personally think=20 that we need both semantics and the syntax for each needs to = be=20 defined/agreed upon.
 
Thanks,
Orit.
------_=_NextPart_001_01C41819.E82A998C-- ------=_NextPartTM-000-3db4dc33-6718-4dad-8e86-fe0f847e4de9-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 10:00:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11501 for ; Fri, 2 Apr 2004 10:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Q9Z-0002qi-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 10:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Q8o-0002f9-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 09:59:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Q7n-0002Rd-00; Fri, 02 Apr 2004 09:58:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9N4g-00025j-1D; Fri, 02 Apr 2004 06:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9I5h-0006Fa-KQ for simple@optimus.ietf.org; Fri, 02 Apr 2004 01:23:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11916 for ; Fri, 2 Apr 2004 01:23:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9I5e-0003nS-00 for simple@ietf.org; Fri, 02 Apr 2004 01:23:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9I4j-0003hb-00 for simple@ietf.org; Fri, 02 Apr 2004 01:22:46 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B9I3q-0003bX-00 for simple@ietf.org; Fri, 02 Apr 2004 01:21:50 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i326Lih20987; Fri, 2 Apr 2004 09:21:44 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 09:21:30 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i326LU78031033; Fri, 2 Apr 2004 09:21:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00G74rYR; Fri, 02 Apr 2004 09:21:29 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i326LOF21855; Fri, 2 Apr 2004 09:21:24 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 09:20:58 +0300 Message-ID: <406D064C.70502@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell CC: SIMPLE mailing list Subject: Re: [Simple] MSRP update References: <406B538C.3010408@dynamicsoft.com> <406C3411.8080606@nokia.com> <406C3DA0.2010000@dynamicsoft.com> In-Reply-To: <406C3DA0.2010000@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2004 06:20:58.0634 (UTC) FILETIME=[A9C1BEA0:01C4187A] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 09:21:00 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Ben: With respect my first point, I think I understand what is not clear: the term "remote host" or "remote URL". I expected that to be peer host, not the "next hop". I agree that an MSRP endpoint does not need to distinguish between the next hop and the peer end, but the protocol specification should clarify when we are speaking about the next hop and when about the remote endpoint. If you can make such distinction, it would be great. And yes, I meant 6.4 and 6.5 ;-) Miguel Ben Campbell wrote: > > Miguel Garcia wrote: > >> Ben: >> >> Thanks for posting "working versions". I have a few comments: >> >> 1) By reading sections 6.4 and 6.5, it is not clear to me, in case the >> a=path contains several URLs, which one represents the endpoint and >> which one the relays. >> >> In 6.4 you wrote: "If the path attribute received from the peer >> contains more than one URL, then the remote URL is the first one". >> >> So I would expect a=path:remote_host, relay_2, relay_1 > > > The idea is, the remote host is the one an endpoint actually connects to > and visits. So if you had relays, the remote URL actually points to a > relay. So you would really be looking at: > > a=path:relay_1, relay_2, remote_host. > >> >> However, in 6.5, you wrote: "When an endpoint receives more than one >> URL in a path header, only the first entry is relevant for purposes of >> resolving the address and port, and establishing the network connection". > > > A non-relay aware endpoint really only ever has to care about the first > entry. It includes the entire path in the To headers so that any relays > can do the right thing. > >> >> According to 6.4, the first entry points to the remote host, not the >> relay, but I would expect the endpoint to establish a connection to >> the relay. >> >> I see a mismatch between 6.5 and 6.5. Perhaps you can clarify this in >> the draft. >> > > Do you mean between 6.4 and 6.5? Or do I have a section number conflict? > > I can see how the current wording is confusing. I struggled with the > terminology here, and am very open to suggestion. Particularly if we > decide an endpoint needs to distinguish between the first-hop URL and > the remote-host URL for any reason. > >> >> >> 2) Connection management (section 7.2). It is written that an endpoint >> should re-use an existing connection when the peer URL matches the >> host part. Isn't this in contradiction with the text in section 5.1 >> that says, when a large file is to be sent, the endpoint should create >> a new MSRP session to avoid blocking? I would expect that "creating a >> new session" comprises creating a new TCP connection as well, not >> re-using an existing one. >> >> We have similar procedures in 7.5.1, second bullet point for the answer. >> > > Yes, that needs to be rationalized. I believe I put in an open issue > asking if we need to discuss situations where an endpoint would > intentionally choose not to share a connection between session. (Unless > I forgot. It happens). > > There have been suggestions that we would remove the suggestion to > create a new session once we have chunking described in the draft. Does > anyone have thoughts on this point? > >> >> 3) I noticed the Content-Type is now an MSRP header, but the content >> is a quoted string. Is there any reason to have a quoted string there? >> I noticed that SIP and HTTP does not encode this header field value in >> quotes. >> >> > > I honestly don't remember why we chose quoted-string. It is possible > there was no good reason. I will check into this. (If anyone remembers, > please speak up now.) > >> >> 4) If you remember and old e-mail I sent you some time ago, the MSRP >> URL misses the "@" sign after the "userinfo". Also, there is a mixture >> of quotes (" and '). IMHO the correct definition should be: >> >> msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource] >> >> > > Darn. I thought I had fixed than in the _previous_ version. I will fix > in the next. > >> >> Regards, >> >> Miguel >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 15:34:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27498 for ; Fri, 2 Apr 2004 15:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SH5-0007KM-Eb for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 12:16:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32HGBIR028167 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 12:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Q9c-0005DK-B4 for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 10:00:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11511 for ; Fri, 2 Apr 2004 10:00:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Q9a-0002qn-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 10:00:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Q8p-0002fG-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 09:59:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Q7n-0002Rd-00; Fri, 02 Apr 2004 09:58:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9N4g-00025j-1D; Fri, 02 Apr 2004 06:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9I5h-0006Fa-KQ for simple@optimus.ietf.org; Fri, 02 Apr 2004 01:23:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11916 for ; Fri, 2 Apr 2004 01:23:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9I5e-0003nS-00 for simple@ietf.org; Fri, 02 Apr 2004 01:23:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9I4j-0003hb-00 for simple@ietf.org; Fri, 02 Apr 2004 01:22:46 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B9I3q-0003bX-00 for simple@ietf.org; Fri, 02 Apr 2004 01:21:50 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i326Lih20987; Fri, 2 Apr 2004 09:21:44 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 09:21:30 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i326LU78031033; Fri, 2 Apr 2004 09:21:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00G74rYR; Fri, 02 Apr 2004 09:21:29 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i326LOF21855; Fri, 2 Apr 2004 09:21:24 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 09:20:58 +0300 Message-ID: <406D064C.70502@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell CC: SIMPLE mailing list Subject: Re: [Simple] MSRP update References: <406B538C.3010408@dynamicsoft.com> <406C3411.8080606@nokia.com> <406C3DA0.2010000@dynamicsoft.com> In-Reply-To: <406C3DA0.2010000@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2004 06:20:58.0634 (UTC) FILETIME=[A9C1BEA0:01C4187A] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 09:21:00 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ben: With respect my first point, I think I understand what is not clear: the term "remote host" or "remote URL". I expected that to be peer host, not the "next hop". I agree that an MSRP endpoint does not need to distinguish between the next hop and the peer end, but the protocol specification should clarify when we are speaking about the next hop and when about the remote endpoint. If you can make such distinction, it would be great. And yes, I meant 6.4 and 6.5 ;-) Miguel Ben Campbell wrote: > > Miguel Garcia wrote: > >> Ben: >> >> Thanks for posting "working versions". I have a few comments: >> >> 1) By reading sections 6.4 and 6.5, it is not clear to me, in case the >> a=path contains several URLs, which one represents the endpoint and >> which one the relays. >> >> In 6.4 you wrote: "If the path attribute received from the peer >> contains more than one URL, then the remote URL is the first one". >> >> So I would expect a=path:remote_host, relay_2, relay_1 > > > The idea is, the remote host is the one an endpoint actually connects to > and visits. So if you had relays, the remote URL actually points to a > relay. So you would really be looking at: > > a=path:relay_1, relay_2, remote_host. > >> >> However, in 6.5, you wrote: "When an endpoint receives more than one >> URL in a path header, only the first entry is relevant for purposes of >> resolving the address and port, and establishing the network connection". > > > A non-relay aware endpoint really only ever has to care about the first > entry. It includes the entire path in the To headers so that any relays > can do the right thing. > >> >> According to 6.4, the first entry points to the remote host, not the >> relay, but I would expect the endpoint to establish a connection to >> the relay. >> >> I see a mismatch between 6.5 and 6.5. Perhaps you can clarify this in >> the draft. >> > > Do you mean between 6.4 and 6.5? Or do I have a section number conflict? > > I can see how the current wording is confusing. I struggled with the > terminology here, and am very open to suggestion. Particularly if we > decide an endpoint needs to distinguish between the first-hop URL and > the remote-host URL for any reason. > >> >> >> 2) Connection management (section 7.2). It is written that an endpoint >> should re-use an existing connection when the peer URL matches the >> host part. Isn't this in contradiction with the text in section 5.1 >> that says, when a large file is to be sent, the endpoint should create >> a new MSRP session to avoid blocking? I would expect that "creating a >> new session" comprises creating a new TCP connection as well, not >> re-using an existing one. >> >> We have similar procedures in 7.5.1, second bullet point for the answer. >> > > Yes, that needs to be rationalized. I believe I put in an open issue > asking if we need to discuss situations where an endpoint would > intentionally choose not to share a connection between session. (Unless > I forgot. It happens). > > There have been suggestions that we would remove the suggestion to > create a new session once we have chunking described in the draft. Does > anyone have thoughts on this point? > >> >> 3) I noticed the Content-Type is now an MSRP header, but the content >> is a quoted string. Is there any reason to have a quoted string there? >> I noticed that SIP and HTTP does not encode this header field value in >> quotes. >> >> > > I honestly don't remember why we chose quoted-string. It is possible > there was no good reason. I will check into this. (If anyone remembers, > please speak up now.) > >> >> 4) If you remember and old e-mail I sent you some time ago, the MSRP >> URL misses the "@" sign after the "userinfo". Also, there is a mixture >> of quotes (" and '). IMHO the correct definition should be: >> >> msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource] >> >> > > Darn. I thought I had fixed than in the _previous_ version. I will fix > in the next. > >> >> Regards, >> >> Miguel >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 16:58:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04730 for ; Fri, 2 Apr 2004 16:58:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgG-0002oI-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 16:58:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WcV-0001wo-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 16:54:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaK-0001S5-01; Fri, 02 Apr 2004 16:52:20 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WVT-0007tl-Vm; Fri, 02 Apr 2004 16:47:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WVC-0003w5-R9; Fri, 02 Apr 2004 16:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9V3I-00034J-QC for simple@optimus.ietf.org; Fri, 02 Apr 2004 15:14:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26510 for ; Fri, 2 Apr 2004 15:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9V3H-0007m9-00 for simple@ietf.org; Fri, 02 Apr 2004 15:14:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9V2J-0007f4-00 for simple@ietf.org; Fri, 02 Apr 2004 15:13:08 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9V26-0007YR-00 for simple@ietf.org; Fri, 02 Apr 2004 15:12:54 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32KCOh05988 for ; Fri, 2 Apr 2004 14:12:24 -0600 Message-ID: <406DC8A1.8020509@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] DSN/MDN and MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 14:10:09 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit We've had a pretty long thread on DSN and MDN for instant messages. this brings me to an MSRP requirements question. How much specification of either of these belongs in the MSRP base spec? A while back, we were leaning towards leaving them as an extension. Adding SIMS style relays changes my opinion on this somewhat. MSRP transactions would be hop-by-hop. A transaction response merely tells you the message was successfully submitted to the next hop. If that hop is a relay, then we have a failure mode similar to that of email. That is, the relay may discover that it cannot forward the request for some reason _after_ it sent an OK response to the previous hop. This tells me that DSN, at least, is very important for MSRP relays to work. We could defer that work to the relay specification. However, we are trying to make it so that an MSRP endpoint that does not implement the relay specification can still interoperate with another that wishes to use relays. So it seems to me that the base MSRP spec should at least include the ability to _receive_ failure DSN reports, if not generate them. I am less sure about MDN. I see the value in allowing them, but I am not sure they need to be discussed in the base specification. Thoughts? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 16:58:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04830 for ; Fri, 2 Apr 2004 16:58:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgW-0002rE-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 16:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wcn-00020r-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 16:54:54 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaN-0001S5-01; Fri, 02 Apr 2004 16:52:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WTp-0007oS-Tb; Fri, 02 Apr 2004 16:45:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTL-0002eW-Vs; Fri, 02 Apr 2004 16:45:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Umy-0001Ru-BU for simple@optimus.ietf.org; Fri, 02 Apr 2004 14:57:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25171 for ; Fri, 2 Apr 2004 14:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Umv-0005kW-00 for simple@ietf.org; Fri, 02 Apr 2004 14:57:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Ulz-0005dP-00 for simple@ietf.org; Fri, 02 Apr 2004 14:56:16 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9UlK-0005Sm-00 for simple@ietf.org; Fri, 02 Apr 2004 14:55:34 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32Jsmh05692; Fri, 2 Apr 2004 13:54:48 -0600 Message-ID: <406DC4F8.7040603@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: Chris Boulton , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <4A3384433CE2AB46A63468CB207E209DB1A435@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A435@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 13:54:32 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eric Burger wrote: > nononononononono. > > We are confusing two, different concepts here. A DSN lets the sender know that a relay attempt failed. IMHO, a positive DSN has not practical value (other than generating information that "might be useful", but of no use). ["Useful" information is how long it takes a message to traverse the relays. What user cares?] > I had not confused the concepts. I was arguing that it was useful to get a report saying that an IM was successfully delivered to the endpoint. That seems to me to fit the definition of DSN more than MDN. But I might be able to be convived otherwise (see below.) > A MDN lets the sender know that the recipient received the message. > > If you are a *user*, and you want to *know* if someone received a message, you are going to request a MDN. If I understand correctly, you are arguing that the useful information is not whether it was delivered to the endpoint, but whether the user actually saw it. (Or consumer consumed it, to be more generic.) Is that the point? If so, I do not have strong feelings one way or another. I am willing to accept that, for critical delivery, the thing I care about is that the message was consumed, rather than merely delivered. But I continue to hold the opinion, that you need some form of positive acknowledgement for sufficiently important messages, whether it be positive DSN or MDN. Negative DSN by themselves are insufficent, because they can also fail. Positive acknowledgement gives us a fail-safe mode. > > > Let's look at two cases from the example again: > > A --> R1 --> R2 --> B > > First case: > A sends to R1 > R1 tries to send to R2, but nobody is home. > R1 sends Failure DSN to A > A knows message was not delivered. Why? Because A receives the DSN. > > > Second case: > A sends to R1 > R1 sends to R2 (successfully - no DSN) > R2 disappears (no DSN) > A *knows* B did not get the message. > How does A know this? Because A requested a MDN, and it never got it. To be pedantic, you do not know it was _not_ delivered. You just have reason to believe it might not have been delivered. Close, but not the same. B may have ignored the MDN request, or the MDN itself may have failed in transit. > > One might say that A cannot tell the difference between a delivery failure and the user ignoring the message. One might say that one would be correct in that assertion, and that is by design. > [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 16:58:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04899 for ; Fri, 2 Apr 2004 16:58:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WgJ-0001a1-II for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LwV9X006074 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WgJ-0001Zt-EY for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04748 for ; Fri, 2 Apr 2004 16:58:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgH-0002oN-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WcW-0001x0-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 16:54:37 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaK-0001S5-01; Fri, 02 Apr 2004 16:52:20 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WVT-0007tl-Vm; Fri, 02 Apr 2004 16:47:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WVC-0003w5-R9; Fri, 02 Apr 2004 16:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9V3I-00034J-QC for simple@optimus.ietf.org; Fri, 02 Apr 2004 15:14:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26510 for ; Fri, 2 Apr 2004 15:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9V3H-0007m9-00 for simple@ietf.org; Fri, 02 Apr 2004 15:14:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9V2J-0007f4-00 for simple@ietf.org; Fri, 02 Apr 2004 15:13:08 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9V26-0007YR-00 for simple@ietf.org; Fri, 02 Apr 2004 15:12:54 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32KCOh05988 for ; Fri, 2 Apr 2004 14:12:24 -0600 Message-ID: <406DC8A1.8020509@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] DSN/MDN and MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 14:10:09 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We've had a pretty long thread on DSN and MDN for instant messages. this brings me to an MSRP requirements question. How much specification of either of these belongs in the MSRP base spec? A while back, we were leaning towards leaving them as an extension. Adding SIMS style relays changes my opinion on this somewhat. MSRP transactions would be hop-by-hop. A transaction response merely tells you the message was successfully submitted to the next hop. If that hop is a relay, then we have a failure mode similar to that of email. That is, the relay may discover that it cannot forward the request for some reason _after_ it sent an OK response to the previous hop. This tells me that DSN, at least, is very important for MSRP relays to work. We could defer that work to the relay specification. However, we are trying to make it so that an MSRP endpoint that does not implement the relay specification can still interoperate with another that wishes to use relays. So it seems to me that the base MSRP spec should at least include the ability to _receive_ failure DSN reports, if not generate them. I am less sure about MDN. I see the value in allowing them, but I am not sure they need to be discussed in the base specification. Thoughts? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 16:59:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05055 for ; Fri, 2 Apr 2004 16:59:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wga-0001eq-7y for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Lwmem006366 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wga-0001eW-1z for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04851 for ; Fri, 2 Apr 2004 16:58:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgX-0002rT-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wco-000217-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 16:54:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaN-0001S5-01; Fri, 02 Apr 2004 16:52:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WTp-0007oS-Tb; Fri, 02 Apr 2004 16:45:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTL-0002eW-Vs; Fri, 02 Apr 2004 16:45:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Umy-0001Ru-BU for simple@optimus.ietf.org; Fri, 02 Apr 2004 14:57:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25171 for ; Fri, 2 Apr 2004 14:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Umv-0005kW-00 for simple@ietf.org; Fri, 02 Apr 2004 14:57:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Ulz-0005dP-00 for simple@ietf.org; Fri, 02 Apr 2004 14:56:16 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9UlK-0005Sm-00 for simple@ietf.org; Fri, 02 Apr 2004 14:55:34 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32Jsmh05692; Fri, 2 Apr 2004 13:54:48 -0600 Message-ID: <406DC4F8.7040603@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: Chris Boulton , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <4A3384433CE2AB46A63468CB207E209DB1A435@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A435@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 13:54:32 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Burger wrote: > nononononononono. > > We are confusing two, different concepts here. A DSN lets the sender know that a relay attempt failed. IMHO, a positive DSN has not practical value (other than generating information that "might be useful", but of no use). ["Useful" information is how long it takes a message to traverse the relays. What user cares?] > I had not confused the concepts. I was arguing that it was useful to get a report saying that an IM was successfully delivered to the endpoint. That seems to me to fit the definition of DSN more than MDN. But I might be able to be convived otherwise (see below.) > A MDN lets the sender know that the recipient received the message. > > If you are a *user*, and you want to *know* if someone received a message, you are going to request a MDN. If I understand correctly, you are arguing that the useful information is not whether it was delivered to the endpoint, but whether the user actually saw it. (Or consumer consumed it, to be more generic.) Is that the point? If so, I do not have strong feelings one way or another. I am willing to accept that, for critical delivery, the thing I care about is that the message was consumed, rather than merely delivered. But I continue to hold the opinion, that you need some form of positive acknowledgement for sufficiently important messages, whether it be positive DSN or MDN. Negative DSN by themselves are insufficent, because they can also fail. Positive acknowledgement gives us a fail-safe mode. > > > Let's look at two cases from the example again: > > A --> R1 --> R2 --> B > > First case: > A sends to R1 > R1 tries to send to R2, but nobody is home. > R1 sends Failure DSN to A > A knows message was not delivered. Why? Because A receives the DSN. > > > Second case: > A sends to R1 > R1 sends to R2 (successfully - no DSN) > R2 disappears (no DSN) > A *knows* B did not get the message. > How does A know this? Because A requested a MDN, and it never got it. To be pedantic, you do not know it was _not_ delivered. You just have reason to believe it might not have been delivered. Close, but not the same. B may have ignored the MDN request, or the MDN itself may have failed in transit. > > One might say that A cannot tell the difference between a delivery failure and the user ignoring the message. One might say that one would be correct in that assertion, and that is by design. > [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 17:23:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08254 for ; Fri, 2 Apr 2004 17:23:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X4S-0000Hn-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:23:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wyo-0006zn-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:17:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WxG-0006bI-00; Fri, 02 Apr 2004 17:16:02 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wss-0000bQ-7K; Fri, 02 Apr 2004 17:11:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WsQ-0006jL-CK; Fri, 02 Apr 2004 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ws7-0006Y1-CC for simple@optimus.ietf.org; Fri, 02 Apr 2004 17:10:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06941 for ; Fri, 2 Apr 2004 17:10:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ws5-0005Tl-00 for simple@ietf.org; Fri, 02 Apr 2004 17:10:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WqB-00050B-00 for simple@ietf.org; Fri, 02 Apr 2004 17:08:43 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WpC-0004dV-00; Fri, 02 Apr 2004 17:07:42 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32M75h07991; Fri, 2 Apr 2004 16:07:05 -0600 Message-ID: <406DE407.7000701@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Miguel Garcia , SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406BC5A8.4080003@nokia.com> <406DE1C8.3040309@dynamicsoft.com> In-Reply-To: <406DE1C8.3040309@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 16:07:03 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit (Comments to self inline) Ben Campbell wrote: [...] > Saying the exploder MUST NOT include the URI list in the outbound > messages seems a little severe. I can imagine applications where I want > the recipients to know the list. This could be useful for "reply to all" > sort of functions. But if we do allow this, we would need to give the > sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. > "bcc" thing.) This sort of functionality seems to be required by REQ-GROUP-2 and REQ-GROUP-4 from the advanced IM reqs draft. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 17:23:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08314 for ; Fri, 2 Apr 2004 17:23:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X4Z-0000IY-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:23:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wyv-00071d-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:17:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WxI-0006bI-00; Fri, 02 Apr 2004 17:16:04 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WsT-0000a2-4P; Fri, 02 Apr 2004 17:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W58-0006iz-7j; Fri, 02 Apr 2004 16:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Snr-0002B1-9y for simple@optimus.ietf.org; Fri, 02 Apr 2004 12:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20844 for ; Fri, 2 Apr 2004 12:49:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Snp-0004ST-00 for simple@ietf.org; Fri, 02 Apr 2004 12:50:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Smx-0004M3-00 for simple@ietf.org; Fri, 02 Apr 2004 12:49:09 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1B9Sm8-00047a-00 for simple@ietf.org; Fri, 02 Apr 2004 12:48:16 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30402; Fri, 02 Apr 2004 12:45:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A435@zoe.office.snowshore.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQXi2UOVL+7l0diSEOwSwwg6zr+0gAPou5wADcEguA= From: "Eric Burger" To: "Chris Boulton" , "Ben Campbell" , Cc: Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 Apr 2004 12:47:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable nononononononono. We are confusing two, different concepts here. A DSN lets the sender = know that a relay attempt failed. IMHO, a positive DSN has not = practical value (other than generating information that "might be = useful", but of no use). ["Useful" information is how long it takes a = message to traverse the relays. What user cares?] A MDN lets the sender know that the recipient received the message. If you are a *user*, and you want to *know* if someone received a = message, you are going to request a MDN. Let's look at two cases from the example again: A --> R1 --> R2 --> B First case: A sends to R1 R1 tries to send to R2, but nobody is home. R1 sends Failure DSN to A A knows message was not delivered. Why? Because A receives the DSN. Second case: A sends to R1 R1 sends to R2 (successfully - no DSN) R2 disappears (no DSN) A *knows* B did not get the message. How does A know this? Because A requested a MDN, and it never got it. One might say that A cannot tell the difference between a delivery = failure and the user ignoring the message. One might say that one would = be correct in that assertion, and that is by design. > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.com] > Sent: Thursday, April 01, 2004 4:24 AM > To: Ben Campbell; hisham.khartabil@nokia.com > Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 > I agree with Ben. If an entity requests delivery confirmation, it > cannot rely on the absence of a failure DSN to convey that the message > was delivered successfully. So I feel that there is scope for both > failure/success DSN's and a requirement for appropriate text=20 > describing > procedures for the scenario where a positive DSN is requested BUT none > received. >=20 > Out of interest - what are the current thoughts on exactly=20 > how a client > will request a DSN conformation? >=20 >=20 > Chris. > =20 >=20 > >-----Original Message----- > >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >Sent: 01 April 2004 02:46 > >To: hisham.khartabil@nokia.com > >Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > simple@ietf.org; > >rohan@cisco.com; aki.niemi@nokia.com > >Subject: Re: [Simple] return receipt and delivery status notification > for > >MSRP > > > >I don't think so. Imagine the following scenario: > > > >A---R1---R2---B > > > >A sends a critically important message to B, telling B to=20 > buy stock in > >messaging companies. > > > >A sends to R1 successfully, and R1 sends to R2 successfully. But R2 > >fails to send to B. So he tries to send a negative DSN to A=20 > via R1. But > >it turns out the failure killed all connectivity to and from=20 > R2, so he > >cannot send it. > > > >The moral is, DSNs can fail just like any other kind of=20 > message. So if > a > >message absolutely positively must be delivered, you need to=20 > be able to > >request positive DSN. Then A can at least notice it did not receive a > >DSN, and act accordingly. > > > > > >hisham.khartabil@nokia.com wrote: > >> My question was: How useful is it to have both notification modes > >(positive and negative) for session IMs? Isn't notification=20 > on failure > >enough? > >> > >> /Hisham > >> > >> > >>>-----Original Message----- > >>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>Sent: 01.April.2004 01:45 > >>>To: Orit Levin > >>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; > >>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki > >>>(Nokia-M/Espoo) > >>>Subject: Re: [Simple] return receipt and delivery status=20 > notification > >>>for MSRP > >>> > >>> > >>> > >>>As Orit says, DSN will be very important for MSRP. > >>> > >>>The current thinking is that MSRP relays will be session > >>>stateless, and > >>>that transactions are entirely hop-by-hop. The relay > >>>semantics would be > >>>similar to those of the SIMS draft, with MSRP syntax. > >>> > >>>As Orit hinted, this means that a transaction response is merely an > >>>indication that the transaction succeeded, not that the message has > >>>reached its destination. So in non peer-to-peer sessions, DSN > >>>is critical. > >>> > >>>We do expect it to be optional, as it is much less useful in the > >>>peer-to-peer case, where is just constitutes redundant messaging. > >>> > >>>Orit Levin wrote: > >>> > >>>>Hisham, > >>>>It is VERY useful because > >>>> > >>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you=20 > whether the > >>>>message was actually delivered end-to-end. > >>>>2. MSRP hop-by-hop application-timer-based mechanism > >>> > >>>doesn't prevent you > >>> > >>>>from getting negative acknowledge in a case when the message was > >>>>actually delivered to the destination. In other words, it > >>> > >>>doesn't solve > >>> > >>>>a duplication problem. > >>>> > >>>>I would like to add the requirement that the "end-to-end" > >>> > >>>DSN receipt > >>> > >>>>needs to be requested per message (not negotiated for the > >>> > >>>whole session > >>> > >>>>for all messages). It will allow for writing different IM=20 > behaviors > >>>>using the same mechanism. Such as: > >>>> > >>>>1. Loose IM session: all the user messages are sent without > >>> > >>>receipt, but > >>> > >>>>the application sends a heartbeat message with requesting a > >>> > >>>receipt for > >>> > >>>>each. > >>>>2. Typical IM session: For all user messages a receipt is > >>> > >>>requested but > >>> > >>>>the indication messages (e.g. "The user is typing") are delivered > >>>>without any receipt. > >>>> > >>>>Thanks, > >>>>Orit. > >>>> > >>>>-----Original Message----- > >>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] > >>> > >>>On Behalf Of > >>> > >>>>hisham.khartabil@nokia.com > >>>>Sent: Wednesday, March 31, 2004 9:26 AM > >>>>To: vkg@lucent.com > >>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; > >>>>aki.niemi@nokia.com > >>>>Subject: RE: [Simple] return receipt and delivery status > >>> > >>>notification > >>> > >>>>for MSRP > >>>> > >>>>This is a good summary, although point 4 can be debatable: > >>> > >>>How useful is > >>> > >>>>it to request receive notification in session mode? > >>>> > >>>>/Hisham > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] > >>>>>Sent: 04.March.2004 16:53 > >>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > >>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki > >>>>>(Nokia-M/Espoo) > >>>>>Subject: Re: [Simple] return receipt and delivery status > >>> > >>>notification > >>> > >>>>>for MSRP > >>>>> > >>>>> > >>>>> > >>>>>hisham.khartabil@nokia.com wrote: > >>>>> > >>>>> > >>>>> > >>>>>>It is optional. If it is annoying to you, then you=20 > don't request a > >>>>>>delivery notification. It is not every time and it is not > >>> > >>>mandatory. > >>> > >>>>>So, just to be pedantic, please correct me if my summary below is > >>>>>wrong: > >>>>> > >>>>> 1/ We are interested in DSNs at the _user_ level, not the > >>>>> _protocol_ level (i.e. the transactional model at the > >>>>> protocol level is sufficient for protocol state > >>>>> machines to figure out if an IM was delivered to the > >>>>> next hop successfully or not). > >>>>> 2/ We should design protocol provisions such that a positive > >>>>> acknowledgement DSN model is supported (let me know > >>>>> the current state of the IM: queued, delivered, read, > >>>>> being responded to, ...). > >>>>> 3/ We should design protocol provisions such that a negative > >>>>> acknowledgement DSN model is supported (send it and > >>>>> forget it unless something drastic happens, then > >>>>> let me know). > >>>>> 4/ Both 2 and 3 should apply to page mode and session > >>>>> mode IMs. > >>>>> 5/ Both 2 and 3 should be configurable by the sending > >>>>> user. > >>>>> > >>>>>Is this accurate? > >>>>> > >>>>>Thanks, > >>>>> > >>>>>- vijay > >>>>>-- > >>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > >>>>>Wireless Networks Group/Internet Software and Services Lucent > >>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > >>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 > >>>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > This message has been scanned for viruses by MailControl -=20 www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 17:23:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08451 for ; Fri, 2 Apr 2004 17:23:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4V-0001PY-HP for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 17:23:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MNV1B005425 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 17:23:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4V-0001PQ-6T for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:23:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08272 for ; Fri, 2 Apr 2004 17:23:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X4S-0000Hs-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:23:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wyp-000700-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:17:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WxG-0006bI-00; Fri, 02 Apr 2004 17:16:02 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wss-0000bQ-7K; Fri, 02 Apr 2004 17:11:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WsQ-0006jL-CK; Fri, 02 Apr 2004 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ws7-0006Y1-CC for simple@optimus.ietf.org; Fri, 02 Apr 2004 17:10:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06941 for ; Fri, 2 Apr 2004 17:10:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ws5-0005Tl-00 for simple@ietf.org; Fri, 02 Apr 2004 17:10:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WqB-00050B-00 for simple@ietf.org; Fri, 02 Apr 2004 17:08:43 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WpC-0004dV-00; Fri, 02 Apr 2004 17:07:42 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32M75h07991; Fri, 2 Apr 2004 16:07:05 -0600 Message-ID: <406DE407.7000701@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Miguel Garcia , SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406BC5A8.4080003@nokia.com> <406DE1C8.3040309@dynamicsoft.com> In-Reply-To: <406DE1C8.3040309@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 16:07:03 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Comments to self inline) Ben Campbell wrote: [...] > Saying the exploder MUST NOT include the URI list in the outbound > messages seems a little severe. I can imagine applications where I want > the recipients to know the list. This could be useful for "reply to all" > sort of functions. But if we do allow this, we would need to give the > sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. > "bcc" thing.) This sort of functionality seems to be required by REQ-GROUP-2 and REQ-GROUP-4 from the advanced IM reqs draft. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 17:24:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08511 for ; Fri, 2 Apr 2004 17:24:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4d-0001R2-Cr for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 17:23:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MNdKX005512 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 17:23:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4c-0001Qp-Vz for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:23:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08329 for ; Fri, 2 Apr 2004 17:23:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X4a-0000Ig-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:23:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wyx-00071v-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:17:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WxI-0006bI-00; Fri, 02 Apr 2004 17:16:04 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WsT-0000a2-4P; Fri, 02 Apr 2004 17:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W58-0006iz-7j; Fri, 02 Apr 2004 16:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Snr-0002B1-9y for simple@optimus.ietf.org; Fri, 02 Apr 2004 12:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20844 for ; Fri, 2 Apr 2004 12:49:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Snp-0004ST-00 for simple@ietf.org; Fri, 02 Apr 2004 12:50:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Smx-0004M3-00 for simple@ietf.org; Fri, 02 Apr 2004 12:49:09 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1B9Sm8-00047a-00 for simple@ietf.org; Fri, 02 Apr 2004 12:48:16 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30402; Fri, 02 Apr 2004 12:45:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A435@zoe.office.snowshore.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQXi2UOVL+7l0diSEOwSwwg6zr+0gAPou5wADcEguA= From: "Eric Burger" To: "Chris Boulton" , "Ben Campbell" , Cc: Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 Apr 2004 12:47:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable nononononononono. We are confusing two, different concepts here. A DSN lets the sender = know that a relay attempt failed. IMHO, a positive DSN has not = practical value (other than generating information that "might be = useful", but of no use). ["Useful" information is how long it takes a = message to traverse the relays. What user cares?] A MDN lets the sender know that the recipient received the message. If you are a *user*, and you want to *know* if someone received a = message, you are going to request a MDN. Let's look at two cases from the example again: A --> R1 --> R2 --> B First case: A sends to R1 R1 tries to send to R2, but nobody is home. R1 sends Failure DSN to A A knows message was not delivered. Why? Because A receives the DSN. Second case: A sends to R1 R1 sends to R2 (successfully - no DSN) R2 disappears (no DSN) A *knows* B did not get the message. How does A know this? Because A requested a MDN, and it never got it. One might say that A cannot tell the difference between a delivery = failure and the user ignoring the message. One might say that one would = be correct in that assertion, and that is by design. > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.com] > Sent: Thursday, April 01, 2004 4:24 AM > To: Ben Campbell; hisham.khartabil@nokia.com > Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 > I agree with Ben. If an entity requests delivery confirmation, it > cannot rely on the absence of a failure DSN to convey that the message > was delivered successfully. So I feel that there is scope for both > failure/success DSN's and a requirement for appropriate text=20 > describing > procedures for the scenario where a positive DSN is requested BUT none > received. >=20 > Out of interest - what are the current thoughts on exactly=20 > how a client > will request a DSN conformation? >=20 >=20 > Chris. > =20 >=20 > >-----Original Message----- > >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >Sent: 01 April 2004 02:46 > >To: hisham.khartabil@nokia.com > >Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > simple@ietf.org; > >rohan@cisco.com; aki.niemi@nokia.com > >Subject: Re: [Simple] return receipt and delivery status notification > for > >MSRP > > > >I don't think so. Imagine the following scenario: > > > >A---R1---R2---B > > > >A sends a critically important message to B, telling B to=20 > buy stock in > >messaging companies. > > > >A sends to R1 successfully, and R1 sends to R2 successfully. But R2 > >fails to send to B. So he tries to send a negative DSN to A=20 > via R1. But > >it turns out the failure killed all connectivity to and from=20 > R2, so he > >cannot send it. > > > >The moral is, DSNs can fail just like any other kind of=20 > message. So if > a > >message absolutely positively must be delivered, you need to=20 > be able to > >request positive DSN. Then A can at least notice it did not receive a > >DSN, and act accordingly. > > > > > >hisham.khartabil@nokia.com wrote: > >> My question was: How useful is it to have both notification modes > >(positive and negative) for session IMs? Isn't notification=20 > on failure > >enough? > >> > >> /Hisham > >> > >> > >>>-----Original Message----- > >>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>Sent: 01.April.2004 01:45 > >>>To: Orit Levin > >>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; > >>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki > >>>(Nokia-M/Espoo) > >>>Subject: Re: [Simple] return receipt and delivery status=20 > notification > >>>for MSRP > >>> > >>> > >>> > >>>As Orit says, DSN will be very important for MSRP. > >>> > >>>The current thinking is that MSRP relays will be session > >>>stateless, and > >>>that transactions are entirely hop-by-hop. The relay > >>>semantics would be > >>>similar to those of the SIMS draft, with MSRP syntax. > >>> > >>>As Orit hinted, this means that a transaction response is merely an > >>>indication that the transaction succeeded, not that the message has > >>>reached its destination. So in non peer-to-peer sessions, DSN > >>>is critical. > >>> > >>>We do expect it to be optional, as it is much less useful in the > >>>peer-to-peer case, where is just constitutes redundant messaging. > >>> > >>>Orit Levin wrote: > >>> > >>>>Hisham, > >>>>It is VERY useful because > >>>> > >>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you=20 > whether the > >>>>message was actually delivered end-to-end. > >>>>2. MSRP hop-by-hop application-timer-based mechanism > >>> > >>>doesn't prevent you > >>> > >>>>from getting negative acknowledge in a case when the message was > >>>>actually delivered to the destination. In other words, it > >>> > >>>doesn't solve > >>> > >>>>a duplication problem. > >>>> > >>>>I would like to add the requirement that the "end-to-end" > >>> > >>>DSN receipt > >>> > >>>>needs to be requested per message (not negotiated for the > >>> > >>>whole session > >>> > >>>>for all messages). It will allow for writing different IM=20 > behaviors > >>>>using the same mechanism. Such as: > >>>> > >>>>1. Loose IM session: all the user messages are sent without > >>> > >>>receipt, but > >>> > >>>>the application sends a heartbeat message with requesting a > >>> > >>>receipt for > >>> > >>>>each. > >>>>2. Typical IM session: For all user messages a receipt is > >>> > >>>requested but > >>> > >>>>the indication messages (e.g. "The user is typing") are delivered > >>>>without any receipt. > >>>> > >>>>Thanks, > >>>>Orit. > >>>> > >>>>-----Original Message----- > >>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] > >>> > >>>On Behalf Of > >>> > >>>>hisham.khartabil@nokia.com > >>>>Sent: Wednesday, March 31, 2004 9:26 AM > >>>>To: vkg@lucent.com > >>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; > >>>>aki.niemi@nokia.com > >>>>Subject: RE: [Simple] return receipt and delivery status > >>> > >>>notification > >>> > >>>>for MSRP > >>>> > >>>>This is a good summary, although point 4 can be debatable: > >>> > >>>How useful is > >>> > >>>>it to request receive notification in session mode? > >>>> > >>>>/Hisham > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] > >>>>>Sent: 04.March.2004 16:53 > >>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > >>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki > >>>>>(Nokia-M/Espoo) > >>>>>Subject: Re: [Simple] return receipt and delivery status > >>> > >>>notification > >>> > >>>>>for MSRP > >>>>> > >>>>> > >>>>> > >>>>>hisham.khartabil@nokia.com wrote: > >>>>> > >>>>> > >>>>> > >>>>>>It is optional. If it is annoying to you, then you=20 > don't request a > >>>>>>delivery notification. It is not every time and it is not > >>> > >>>mandatory. > >>> > >>>>>So, just to be pedantic, please correct me if my summary below is > >>>>>wrong: > >>>>> > >>>>> 1/ We are interested in DSNs at the _user_ level, not the > >>>>> _protocol_ level (i.e. the transactional model at the > >>>>> protocol level is sufficient for protocol state > >>>>> machines to figure out if an IM was delivered to the > >>>>> next hop successfully or not). > >>>>> 2/ We should design protocol provisions such that a positive > >>>>> acknowledgement DSN model is supported (let me know > >>>>> the current state of the IM: queued, delivered, read, > >>>>> being responded to, ...). > >>>>> 3/ We should design protocol provisions such that a negative > >>>>> acknowledgement DSN model is supported (send it and > >>>>> forget it unless something drastic happens, then > >>>>> let me know). > >>>>> 4/ Both 2 and 3 should apply to page mode and session > >>>>> mode IMs. > >>>>> 5/ Both 2 and 3 should be configurable by the sending > >>>>> user. > >>>>> > >>>>>Is this accurate? > >>>>> > >>>>>Thanks, > >>>>> > >>>>>- vijay > >>>>>-- > >>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > >>>>>Wireless Networks Group/Internet Software and Services Lucent > >>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > >>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 > >>>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > This message has been scanned for viruses by MailControl -=20 www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 17:25:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09025 for ; Fri, 2 Apr 2004 17:25:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X67-0000h7-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:25:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9X1f-0007aS-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:20:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wy9-0006bI-01; Fri, 02 Apr 2004 17:16:57 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wor-0000Ki-Jk; Fri, 02 Apr 2004 17:07:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WoY-0004Rk-Qp; Fri, 02 Apr 2004 17:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Vj2-0000Ht-Au for simple@optimus.ietf.org; Fri, 02 Apr 2004 15:57:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28333 for ; Fri, 2 Apr 2004 15:57:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Vj0-0005nf-00 for simple@ietf.org; Fri, 02 Apr 2004 15:57:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Vi6-0005eZ-00 for simple@ietf.org; Fri, 02 Apr 2004 15:56:19 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9VhS-0005Ue-00 for simple@ietf.org; Fri, 02 Apr 2004 15:55:38 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32Ksuh06588; Fri, 2 Apr 2004 14:54:56 -0600 Message-ID: <406DD31E.5030707@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, george.foti@ericsson.com, simple@ietf.org Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) References: <2038BCC78B1AD641891A0D1AE133DBB70179786E@esebe019.ntc.nokia.com> <406B96F4.3090808@dynamicsoft.com> In-Reply-To: <406B96F4.3090808@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 14:54:54 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] >>> >>> I'm not aware of any text that suggests that the soft event state >>> manipulated with PUBLISH somehow also finds its way into the XCAP tree. >> >> >> >> George's point is that there is no text forbidding it, so in theory, >> it could find its way. But the question is: Do we really need to >> explicitly forbit such thing from happening by placing a MUST NOT text? > > > I think its sufficient to say that there is simply no way, with this > application usage, to point to such presence documents, making it out of > scope. I am a little confused by the statement "there is no way". I can imagine someone co-locating their XCAP service and a PA, and reflecting the current presence state into the XCAP tree. Any meta-data like expirations and entity tags could just be left out from the XCAP view. The point is, doing this is a bad idea. Perhaps we should say something to that effect. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 17:25:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09155 for ; Fri, 2 Apr 2004 17:25:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X6L-0000kD-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:25:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9X26-0007f2-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:21:03 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WyE-0006bI-02; Fri, 02 Apr 2004 17:17:02 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wnq-0000Il-DT; Fri, 02 Apr 2004 17:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wnc-0003s0-Im; Fri, 02 Apr 2004 17:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wn5-0003W7-C6 for simple@optimus.ietf.org; Fri, 02 Apr 2004 17:05:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06010 for ; Fri, 2 Apr 2004 17:05:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Wn3-0004Am-00 for simple@ietf.org; Fri, 02 Apr 2004 17:05:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WjT-0003Uy-00 for simple@ietf.org; Fri, 02 Apr 2004 17:01:48 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wfz-0002Zt-00; Fri, 02 Apr 2004 16:58:11 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32LvVh07784; Fri, 2 Apr 2004 15:57:31 -0600 Message-ID: <406DE1C8.3040309@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406BC5A8.4080003@nokia.com> In-Reply-To: <406BC5A8.4080003@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 15:57:28 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I like this approach overall. A couple of comments and questions. Apologies if these have already been discussed. Is it legal for the list parameter to point to something other than a body part? That is, can I have external lists? Saying the exploder MUST NOT include the URI list in the outbound messages seems a little severe. I can imagine applications where I want the recipients to know the list. This could be useful for "reply to all" sort of functions. But if we do allow this, we would need to give the sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. "bcc" thing.) Instead of saying that message exploders must always send message requests, we might consider saying the outbound request method must match the outbound method. This would allow for exploders that know how to explode more than one method. When condidering DoS issues, it might be worth suggesting behavior if the exploder finds duplicate URIs on the list. For example, I could put the same URI in a bunch of times, and have a nice DoS amplifier. Miguel Garcia wrote: > Hi: > > I have just submitted a draft that discusses a exploder of MESSAGEs. > > While it appears in the repository, you can download them from: > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html > > > Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING > (exploders), I am copying both mailing lists. > > Regards, > > Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 17:25:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09245 for ; Fri, 2 Apr 2004 17:25:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X6B-00026B-7E for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 17:25:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MPFRl008063 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 17:25:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X6B-00025y-2A for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:25:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09046 for ; Fri, 2 Apr 2004 17:25:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X68-0000hQ-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:25:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9X1h-0007aj-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:20:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wy9-0006bI-01; Fri, 02 Apr 2004 17:16:57 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wor-0000Ki-Jk; Fri, 02 Apr 2004 17:07:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WoY-0004Rk-Qp; Fri, 02 Apr 2004 17:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Vj2-0000Ht-Au for simple@optimus.ietf.org; Fri, 02 Apr 2004 15:57:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28333 for ; Fri, 2 Apr 2004 15:57:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Vj0-0005nf-00 for simple@ietf.org; Fri, 02 Apr 2004 15:57:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Vi6-0005eZ-00 for simple@ietf.org; Fri, 02 Apr 2004 15:56:19 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9VhS-0005Ue-00 for simple@ietf.org; Fri, 02 Apr 2004 15:55:38 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32Ksuh06588; Fri, 2 Apr 2004 14:54:56 -0600 Message-ID: <406DD31E.5030707@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, george.foti@ericsson.com, simple@ietf.org Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) References: <2038BCC78B1AD641891A0D1AE133DBB70179786E@esebe019.ntc.nokia.com> <406B96F4.3090808@dynamicsoft.com> In-Reply-To: <406B96F4.3090808@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 14:54:54 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] >>> >>> I'm not aware of any text that suggests that the soft event state >>> manipulated with PUBLISH somehow also finds its way into the XCAP tree. >> >> >> >> George's point is that there is no text forbidding it, so in theory, >> it could find its way. But the question is: Do we really need to >> explicitly forbit such thing from happening by placing a MUST NOT text? > > > I think its sufficient to say that there is simply no way, with this > application usage, to point to such presence documents, making it out of > scope. I am a little confused by the statement "there is no way". I can imagine someone co-locating their XCAP service and a PA, and reflecting the current presence state into the XCAP tree. Any meta-data like expirations and entity tags could just be left out from the XCAP view. The point is, doing this is a bad idea. Perhaps we should say something to that effect. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 17:25:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09335 for ; Fri, 2 Apr 2004 17:25:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X6O-00028T-SA for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 17:25:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MPS98008208 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 17:25:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X6O-00028I-Lv for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09175 for ; Fri, 2 Apr 2004 17:25:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X6M-0000kO-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:25:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9X28-0007fN-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:21:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WyE-0006bI-02; Fri, 02 Apr 2004 17:17:02 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wnq-0000Il-DT; Fri, 02 Apr 2004 17:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wnc-0003s0-Im; Fri, 02 Apr 2004 17:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wn5-0003W7-C6 for simple@optimus.ietf.org; Fri, 02 Apr 2004 17:05:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06010 for ; Fri, 2 Apr 2004 17:05:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Wn3-0004Am-00 for simple@ietf.org; Fri, 02 Apr 2004 17:05:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WjT-0003Uy-00 for simple@ietf.org; Fri, 02 Apr 2004 17:01:48 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wfz-0002Zt-00; Fri, 02 Apr 2004 16:58:11 -0500 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i32LvVh07784; Fri, 2 Apr 2004 15:57:31 -0600 Message-ID: <406DE1C8.3040309@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406BC5A8.4080003@nokia.com> In-Reply-To: <406BC5A8.4080003@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 15:57:28 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I like this approach overall. A couple of comments and questions. Apologies if these have already been discussed. Is it legal for the list parameter to point to something other than a body part? That is, can I have external lists? Saying the exploder MUST NOT include the URI list in the outbound messages seems a little severe. I can imagine applications where I want the recipients to know the list. This could be useful for "reply to all" sort of functions. But if we do allow this, we would need to give the sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. "bcc" thing.) Instead of saying that message exploders must always send message requests, we might consider saying the outbound request method must match the outbound method. This would allow for exploders that know how to explode more than one method. When condidering DoS issues, it might be worth suggesting behavior if the exploder finds duplicate URIs on the list. For example, I could put the same URI in a bunch of times, and have a nice DoS amplifier. Miguel Garcia wrote: > Hi: > > I have just submitted a draft that discusses a exploder of MESSAGEs. > > While it appears in the repository, you can download them from: > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html > > > Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING > (exploders), I am copying both mailing lists. > > Regards, > > Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 17:42:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10450 for ; Fri, 2 Apr 2004 17:42:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9XMe-0003XK-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:42:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9XLj-0003QO-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 17:41:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9XLS-0003J4-00; Fri, 02 Apr 2004 17:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XLR-0001Pz-K0; Fri, 02 Apr 2004 17:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XKm-00014j-5o for simple@optimus.ietf.org; Fri, 02 Apr 2004 17:40:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10333 for ; Fri, 2 Apr 2004 17:40:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9XKj-0003Ht-00 for simple@ietf.org; Fri, 02 Apr 2004 17:40:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9XJs-0003A4-00 for simple@ietf.org; Fri, 02 Apr 2004 17:39:25 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B9XIu-0002ta-00 for simple@ietf.org; Fri, 02 Apr 2004 17:38:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 14:45:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i32MbqKj008226; Fri, 2 Apr 2004 14:37:52 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI28663; Fri, 2 Apr 2004 17:37:51 -0500 (EST) Message-ID: <406DEB3E.7090808@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: Chris Boulton , Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <4A3384433CE2AB46A63468CB207E209DB1A435@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 17:37:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eric, I can't speak for the others, but I have been lumping the notion of MDN into DSN - perphaps distinguished by options or something. Maybe it is useful to distinguish the two types, maybe not. Paul Eric Burger wrote: > nononononononono. > > We are confusing two, different concepts here. A DSN lets the sender know that a relay attempt failed. IMHO, a positive DSN has not practical value (other than generating information that "might be useful", but of no use). ["Useful" information is how long it takes a message to traverse the relays. What user cares?] > > A MDN lets the sender know that the recipient received the message. > > If you are a *user*, and you want to *know* if someone received a message, you are going to request a MDN. > > > Let's look at two cases from the example again: > > A --> R1 --> R2 --> B > > First case: > A sends to R1 > R1 tries to send to R2, but nobody is home. > R1 sends Failure DSN to A > A knows message was not delivered. Why? Because A receives the DSN. > > > Second case: > A sends to R1 > R1 sends to R2 (successfully - no DSN) > R2 disappears (no DSN) > A *knows* B did not get the message. > How does A know this? Because A requested a MDN, and it never got it. > > One might say that A cannot tell the difference between a delivery failure and the user ignoring the message. One might say that one would be correct in that assertion, and that is by design. > > > > >>-----Original Message----- >>From: Chris Boulton [mailto:cboulton@ubiquity.com] >>Sent: Thursday, April 01, 2004 4:24 AM >>To: Ben Campbell; hisham.khartabil@nokia.com >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >>simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com >>Subject: RE: [Simple] return receipt and delivery status notification >>for MSRP >> >> >>I agree with Ben. If an entity requests delivery confirmation, it >>cannot rely on the absence of a failure DSN to convey that the message >>was delivered successfully. So I feel that there is scope for both >>failure/success DSN's and a requirement for appropriate text >>describing >>procedures for the scenario where a positive DSN is requested BUT none >>received. >> >>Out of interest - what are the current thoughts on exactly >>how a client >>will request a DSN conformation? >> >> >>Chris. >> >> >> >>>-----Original Message----- >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 01 April 2004 02:46 >>>To: hisham.khartabil@nokia.com >>>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> >>simple@ietf.org; >> >>>rohan@cisco.com; aki.niemi@nokia.com >>>Subject: Re: [Simple] return receipt and delivery status notification >> >>for >> >>>MSRP >>> >>>I don't think so. Imagine the following scenario: >>> >>>A---R1---R2---B >>> >>>A sends a critically important message to B, telling B to >> >>buy stock in >> >>>messaging companies. >>> >>>A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >>>fails to send to B. So he tries to send a negative DSN to A >> >>via R1. But >> >>>it turns out the failure killed all connectivity to and from >> >>R2, so he >> >>>cannot send it. >>> >>>The moral is, DSNs can fail just like any other kind of >> >>message. So if >>a >> >>>message absolutely positively must be delivered, you need to >> >>be able to >> >>>request positive DSN. Then A can at least notice it did not receive a >>>DSN, and act accordingly. >>> >>> >>>hisham.khartabil@nokia.com wrote: >>> >>>>My question was: How useful is it to have both notification modes >>> >>>(positive and negative) for session IMs? Isn't notification >> >>on failure >> >>>enough? >>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>Sent: 01.April.2004 01:45 >>>>>To: Orit Levin >>>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >>>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>(Nokia-M/Espoo) >>>>>Subject: Re: [Simple] return receipt and delivery status >>>> >>notification >> >>>>>for MSRP >>>>> >>>>> >>>>> >>>>>As Orit says, DSN will be very important for MSRP. >>>>> >>>>>The current thinking is that MSRP relays will be session >>>>>stateless, and >>>>>that transactions are entirely hop-by-hop. The relay >>>>>semantics would be >>>>>similar to those of the SIMS draft, with MSRP syntax. >>>>> >>>>>As Orit hinted, this means that a transaction response is merely an >>>>>indication that the transaction succeeded, not that the message has >>>>>reached its destination. So in non peer-to-peer sessions, DSN >>>>>is critical. >>>>> >>>>>We do expect it to be optional, as it is much less useful in the >>>>>peer-to-peer case, where is just constitutes redundant messaging. >>>>> >>>>>Orit Levin wrote: >>>>> >>>>> >>>>>>Hisham, >>>>>>It is VERY useful because >>>>>> >>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you >>>>> >>whether the >> >>>>>>message was actually delivered end-to-end. >>>>>>2. MSRP hop-by-hop application-timer-based mechanism >>>>> >>>>>doesn't prevent you >>>>> >>>>>>from getting negative acknowledge in a case when the message was >>>>> >>>>>>actually delivered to the destination. In other words, it >>>>> >>>>>doesn't solve >>>>> >>>>> >>>>>>a duplication problem. >>>>>> >>>>>>I would like to add the requirement that the "end-to-end" >>>>> >>>>>DSN receipt >>>>> >>>>> >>>>>>needs to be requested per message (not negotiated for the >>>>> >>>>>whole session >>>>> >>>>> >>>>>>for all messages). It will allow for writing different IM >>>>> >>behaviors >> >>>>>>using the same mechanism. Such as: >>>>>> >>>>>>1. Loose IM session: all the user messages are sent without >>>>> >>>>>receipt, but >>>>> >>>>> >>>>>>the application sends a heartbeat message with requesting a >>>>> >>>>>receipt for >>>>> >>>>> >>>>>>each. >>>>>>2. Typical IM session: For all user messages a receipt is >>>>> >>>>>requested but >>>>> >>>>> >>>>>>the indication messages (e.g. "The user is typing") are delivered >>>>>>without any receipt. >>>>>> >>>>>>Thanks, >>>>>>Orit. >>>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>>>> >>>>>On Behalf Of >>>>> >>>>> >>>>>>hisham.khartabil@nokia.com >>>>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>>>To: vkg@lucent.com >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >>>>>>aki.niemi@nokia.com >>>>>>Subject: RE: [Simple] return receipt and delivery status >>>>> >>>>>notification >>>>> >>>>> >>>>>>for MSRP >>>>>> >>>>>>This is a good summary, although point 4 can be debatable: >>>>> >>>>>How useful is >>>>> >>>>> >>>>>>it to request receive notification in session mode? >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>>>Sent: 04.March.2004 16:53 >>>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>>>(Nokia-M/Espoo) >>>>>>>Subject: Re: [Simple] return receipt and delivery status >>>>>> >>>>>notification >>>>> >>>>> >>>>>>>for MSRP >>>>>>> >>>>>>> >>>>>>> >>>>>>>hisham.khartabil@nokia.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>It is optional. If it is annoying to you, then you >>>>>>> >>don't request a >> >>>>>>>>delivery notification. It is not every time and it is not >>>>>>> >>>>>mandatory. >>>>> >>>>> >>>>>>>So, just to be pedantic, please correct me if my summary below is >>>>>>>wrong: >>>>>>> >>>>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>>>> _protocol_ level (i.e. the transactional model at the >>>>>>> protocol level is sufficient for protocol state >>>>>>> machines to figure out if an IM was delivered to the >>>>>>> next hop successfully or not). >>>>>>> 2/ We should design protocol provisions such that a positive >>>>>>> acknowledgement DSN model is supported (let me know >>>>>>> the current state of the IM: queued, delivered, read, >>>>>>> being responded to, ...). >>>>>>> 3/ We should design protocol provisions such that a negative >>>>>>> acknowledgement DSN model is supported (send it and >>>>>>> forget it unless something drastic happens, then >>>>>>> let me know). >>>>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>>>> mode IMs. >>>>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>>>> user. >>>>>>> >>>>>>>Is this accurate? >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>- vijay >>>>>>>-- >>>>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>>>Wireless Networks Group/Internet Software and Services Lucent >>>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >> >>This message has been scanned for viruses by MailControl - > > www.mailcontrol.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 17:44:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10511 for ; Fri, 2 Apr 2004 17:44:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XMx-0001XL-Nl for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 17:43:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MgPht005880 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 17:42:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XMn-0001WP-GB for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:42:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10468 for ; Fri, 2 Apr 2004 17:42:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9XMg-0003XX-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:42:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9XLl-0003QX-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 17:41:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9XLS-0003J4-00; Fri, 02 Apr 2004 17:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XLR-0001Pz-K0; Fri, 02 Apr 2004 17:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XKm-00014j-5o for simple@optimus.ietf.org; Fri, 02 Apr 2004 17:40:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10333 for ; Fri, 2 Apr 2004 17:40:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9XKj-0003Ht-00 for simple@ietf.org; Fri, 02 Apr 2004 17:40:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9XJs-0003A4-00 for simple@ietf.org; Fri, 02 Apr 2004 17:39:25 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B9XIu-0002ta-00 for simple@ietf.org; Fri, 02 Apr 2004 17:38:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 14:45:58 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i32MbqKj008226; Fri, 2 Apr 2004 14:37:52 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI28663; Fri, 2 Apr 2004 17:37:51 -0500 (EST) Message-ID: <406DEB3E.7090808@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: Chris Boulton , Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <4A3384433CE2AB46A63468CB207E209DB1A435@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 17:37:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, I can't speak for the others, but I have been lumping the notion of MDN into DSN - perphaps distinguished by options or something. Maybe it is useful to distinguish the two types, maybe not. Paul Eric Burger wrote: > nononononononono. > > We are confusing two, different concepts here. A DSN lets the sender know that a relay attempt failed. IMHO, a positive DSN has not practical value (other than generating information that "might be useful", but of no use). ["Useful" information is how long it takes a message to traverse the relays. What user cares?] > > A MDN lets the sender know that the recipient received the message. > > If you are a *user*, and you want to *know* if someone received a message, you are going to request a MDN. > > > Let's look at two cases from the example again: > > A --> R1 --> R2 --> B > > First case: > A sends to R1 > R1 tries to send to R2, but nobody is home. > R1 sends Failure DSN to A > A knows message was not delivered. Why? Because A receives the DSN. > > > Second case: > A sends to R1 > R1 sends to R2 (successfully - no DSN) > R2 disappears (no DSN) > A *knows* B did not get the message. > How does A know this? Because A requested a MDN, and it never got it. > > One might say that A cannot tell the difference between a delivery failure and the user ignoring the message. One might say that one would be correct in that assertion, and that is by design. > > > > >>-----Original Message----- >>From: Chris Boulton [mailto:cboulton@ubiquity.com] >>Sent: Thursday, April 01, 2004 4:24 AM >>To: Ben Campbell; hisham.khartabil@nokia.com >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >>simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com >>Subject: RE: [Simple] return receipt and delivery status notification >>for MSRP >> >> >>I agree with Ben. If an entity requests delivery confirmation, it >>cannot rely on the absence of a failure DSN to convey that the message >>was delivered successfully. So I feel that there is scope for both >>failure/success DSN's and a requirement for appropriate text >>describing >>procedures for the scenario where a positive DSN is requested BUT none >>received. >> >>Out of interest - what are the current thoughts on exactly >>how a client >>will request a DSN conformation? >> >> >>Chris. >> >> >> >>>-----Original Message----- >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 01 April 2004 02:46 >>>To: hisham.khartabil@nokia.com >>>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> >>simple@ietf.org; >> >>>rohan@cisco.com; aki.niemi@nokia.com >>>Subject: Re: [Simple] return receipt and delivery status notification >> >>for >> >>>MSRP >>> >>>I don't think so. Imagine the following scenario: >>> >>>A---R1---R2---B >>> >>>A sends a critically important message to B, telling B to >> >>buy stock in >> >>>messaging companies. >>> >>>A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >>>fails to send to B. So he tries to send a negative DSN to A >> >>via R1. But >> >>>it turns out the failure killed all connectivity to and from >> >>R2, so he >> >>>cannot send it. >>> >>>The moral is, DSNs can fail just like any other kind of >> >>message. So if >>a >> >>>message absolutely positively must be delivered, you need to >> >>be able to >> >>>request positive DSN. Then A can at least notice it did not receive a >>>DSN, and act accordingly. >>> >>> >>>hisham.khartabil@nokia.com wrote: >>> >>>>My question was: How useful is it to have both notification modes >>> >>>(positive and negative) for session IMs? Isn't notification >> >>on failure >> >>>enough? >>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>Sent: 01.April.2004 01:45 >>>>>To: Orit Levin >>>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >>>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>(Nokia-M/Espoo) >>>>>Subject: Re: [Simple] return receipt and delivery status >>>> >>notification >> >>>>>for MSRP >>>>> >>>>> >>>>> >>>>>As Orit says, DSN will be very important for MSRP. >>>>> >>>>>The current thinking is that MSRP relays will be session >>>>>stateless, and >>>>>that transactions are entirely hop-by-hop. The relay >>>>>semantics would be >>>>>similar to those of the SIMS draft, with MSRP syntax. >>>>> >>>>>As Orit hinted, this means that a transaction response is merely an >>>>>indication that the transaction succeeded, not that the message has >>>>>reached its destination. So in non peer-to-peer sessions, DSN >>>>>is critical. >>>>> >>>>>We do expect it to be optional, as it is much less useful in the >>>>>peer-to-peer case, where is just constitutes redundant messaging. >>>>> >>>>>Orit Levin wrote: >>>>> >>>>> >>>>>>Hisham, >>>>>>It is VERY useful because >>>>>> >>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you >>>>> >>whether the >> >>>>>>message was actually delivered end-to-end. >>>>>>2. MSRP hop-by-hop application-timer-based mechanism >>>>> >>>>>doesn't prevent you >>>>> >>>>>>from getting negative acknowledge in a case when the message was >>>>> >>>>>>actually delivered to the destination. In other words, it >>>>> >>>>>doesn't solve >>>>> >>>>> >>>>>>a duplication problem. >>>>>> >>>>>>I would like to add the requirement that the "end-to-end" >>>>> >>>>>DSN receipt >>>>> >>>>> >>>>>>needs to be requested per message (not negotiated for the >>>>> >>>>>whole session >>>>> >>>>> >>>>>>for all messages). It will allow for writing different IM >>>>> >>behaviors >> >>>>>>using the same mechanism. Such as: >>>>>> >>>>>>1. Loose IM session: all the user messages are sent without >>>>> >>>>>receipt, but >>>>> >>>>> >>>>>>the application sends a heartbeat message with requesting a >>>>> >>>>>receipt for >>>>> >>>>> >>>>>>each. >>>>>>2. Typical IM session: For all user messages a receipt is >>>>> >>>>>requested but >>>>> >>>>> >>>>>>the indication messages (e.g. "The user is typing") are delivered >>>>>>without any receipt. >>>>>> >>>>>>Thanks, >>>>>>Orit. >>>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>>>> >>>>>On Behalf Of >>>>> >>>>> >>>>>>hisham.khartabil@nokia.com >>>>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>>>To: vkg@lucent.com >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >>>>>>aki.niemi@nokia.com >>>>>>Subject: RE: [Simple] return receipt and delivery status >>>>> >>>>>notification >>>>> >>>>> >>>>>>for MSRP >>>>>> >>>>>>This is a good summary, although point 4 can be debatable: >>>>> >>>>>How useful is >>>>> >>>>> >>>>>>it to request receive notification in session mode? >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>>>Sent: 04.March.2004 16:53 >>>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>>>(Nokia-M/Espoo) >>>>>>>Subject: Re: [Simple] return receipt and delivery status >>>>>> >>>>>notification >>>>> >>>>> >>>>>>>for MSRP >>>>>>> >>>>>>> >>>>>>> >>>>>>>hisham.khartabil@nokia.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>It is optional. If it is annoying to you, then you >>>>>>> >>don't request a >> >>>>>>>>delivery notification. It is not every time and it is not >>>>>>> >>>>>mandatory. >>>>> >>>>> >>>>>>>So, just to be pedantic, please correct me if my summary below is >>>>>>>wrong: >>>>>>> >>>>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>>>> _protocol_ level (i.e. the transactional model at the >>>>>>> protocol level is sufficient for protocol state >>>>>>> machines to figure out if an IM was delivered to the >>>>>>> next hop successfully or not). >>>>>>> 2/ We should design protocol provisions such that a positive >>>>>>> acknowledgement DSN model is supported (let me know >>>>>>> the current state of the IM: queued, delivered, read, >>>>>>> being responded to, ...). >>>>>>> 3/ We should design protocol provisions such that a negative >>>>>>> acknowledgement DSN model is supported (send it and >>>>>>> forget it unless something drastic happens, then >>>>>>> let me know). >>>>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>>>> mode IMs. >>>>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>>>> user. >>>>>>> >>>>>>>Is this accurate? >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>- vijay >>>>>>>-- >>>>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>>>Wireless Networks Group/Internet Software and Services Lucent >>>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >> >>This message has been scanned for viruses by MailControl - > > www.mailcontrol.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 2 18:14:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12146 for ; Fri, 2 Apr 2004 18:14:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xra-0007VP-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 18:14:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Xqg-0007NH-00 for simple-archive@ietf.org; Fri, 02 Apr 2004 18:13:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xpn-0007G8-00; Fri, 02 Apr 2004 18:12:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xml-0007n4-Uj; Fri, 02 Apr 2004 18:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xlq-0007S3-HB for simple@optimus.ietf.org; Fri, 02 Apr 2004 18:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11602 for ; Fri, 2 Apr 2004 18:08:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xlm-0006i6-00 for simple@ietf.org; Fri, 02 Apr 2004 18:08:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Xks-0006bT-00 for simple@ietf.org; Fri, 02 Apr 2004 18:07:19 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B9XkV-0006UP-00; Fri, 02 Apr 2004 18:06:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 15:14:28 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i32N6MKj006377; Fri, 2 Apr 2004 15:06:22 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI30980; Fri, 2 Apr 2004 18:06:21 -0500 (EST) Message-ID: <406DF1EC.4050400@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406BC5A8.4080003@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sipping] MESSAGE Exploders draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 18:06:20 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Miguel, In general the approach in the draft seems reasonable to me. I see one area of ambiguity, having to do with how multipart bodies are handled. The draft says to remove the list and include everything else. But even your example doesn't do that - it also removes the multipart/mixed wrapper. Of course in this particular example that makes perfect sense, but it goes beyond what the draft says to do. There are more complex cases: - for security there could be signed body parts. - The signature could be on the multipart containing the message and list. It would have to be removed. - The signature could be on just the message. Presumably it should remain. - There could be other body parts referenced by cid: urls in other headers in the message. I think there needs to be a more prescriptive way of defining what gets passed on in the exploded messages. This is really just a manifestation of a more general problem of how to decide how different body parts should be processed. It potentially exists in a normal, unexploded, MESSAGE. I think at least part of the answer lies with Content-Disposition. I think there should be clarity about the content-disposition should be for the body part(s) that MESSAGE interprets as message content. Probably "render" (which is default for sip) would be an appropriate content-disposition for message content. Also, I think there should be some clarity about what the content-disposition should be for various kinds of multipart containers when used in the various ways they may be used in sip. I'm not quite sure what the answer is here. The list itself is of course referenced from a cid: url. It is the url and its placement that determines how the corresponding body part should be processed. For these, the content-disposition should be some value that doesn't imply some other sort of processing. I think it can't be any of "session", "render", "alert", or "icon". Maybe it could be "attachment". Paul Miguel Garcia wrote: > Hi: > > I have just submitted a draft that discusses a exploder of MESSAGEs. > > While it appears in the repository, you can download them from: > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html > > > Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING > (exploders), I am copying both mailing lists. > > Regards, > > Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 2 18:15:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12366 for ; Fri, 2 Apr 2004 18:15:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xrt-0001O4-A6 for simple-archive@odin.ietf.org; Fri, 02 Apr 2004 18:15:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32NENqi005089 for simple-archive@odin.ietf.org; Fri, 2 Apr 2004 18:14:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xri-0001I1-V5 for simple-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 18:14:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12165 for ; Fri, 2 Apr 2004 18:14:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xrb-0007VU-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 18:14:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Xqg-0007NO-00 for simple-web-archive@ietf.org; Fri, 02 Apr 2004 18:13:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xpn-0007G8-00; Fri, 02 Apr 2004 18:12:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xml-0007n4-Uj; Fri, 02 Apr 2004 18:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xlq-0007S3-HB for simple@optimus.ietf.org; Fri, 02 Apr 2004 18:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11602 for ; Fri, 2 Apr 2004 18:08:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xlm-0006i6-00 for simple@ietf.org; Fri, 02 Apr 2004 18:08:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Xks-0006bT-00 for simple@ietf.org; Fri, 02 Apr 2004 18:07:19 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B9XkV-0006UP-00; Fri, 02 Apr 2004 18:06:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 15:14:28 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i32N6MKj006377; Fri, 2 Apr 2004 15:06:22 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI30980; Fri, 2 Apr 2004 18:06:21 -0500 (EST) Message-ID: <406DF1EC.4050400@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406BC5A8.4080003@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sipping] MESSAGE Exploders draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Apr 2004 18:06:20 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel, In general the approach in the draft seems reasonable to me. I see one area of ambiguity, having to do with how multipart bodies are handled. The draft says to remove the list and include everything else. But even your example doesn't do that - it also removes the multipart/mixed wrapper. Of course in this particular example that makes perfect sense, but it goes beyond what the draft says to do. There are more complex cases: - for security there could be signed body parts. - The signature could be on the multipart containing the message and list. It would have to be removed. - The signature could be on just the message. Presumably it should remain. - There could be other body parts referenced by cid: urls in other headers in the message. I think there needs to be a more prescriptive way of defining what gets passed on in the exploded messages. This is really just a manifestation of a more general problem of how to decide how different body parts should be processed. It potentially exists in a normal, unexploded, MESSAGE. I think at least part of the answer lies with Content-Disposition. I think there should be clarity about the content-disposition should be for the body part(s) that MESSAGE interprets as message content. Probably "render" (which is default for sip) would be an appropriate content-disposition for message content. Also, I think there should be some clarity about what the content-disposition should be for various kinds of multipart containers when used in the various ways they may be used in sip. I'm not quite sure what the answer is here. The list itself is of course referenced from a cid: url. It is the url and its placement that determines how the corresponding body part should be processed. For these, the content-disposition should be some value that doesn't imply some other sort of processing. I think it can't be any of "session", "render", "alert", or "icon". Maybe it could be "attachment". Paul Miguel Garcia wrote: > Hi: > > I have just submitted a draft that discusses a exploder of MESSAGEs. > > While it appears in the repository, you can download them from: > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt > > http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html > > > Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING > (exploders), I am copying both mailing lists. > > Regards, > > Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Apr 3 23:30:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17517 for ; Sat, 3 Apr 2004 23:30:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zH3-0006az-00 for simple-archive@ietf.org; Sat, 03 Apr 2004 23:30:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9zG6-0006V0-00 for simple-archive@ietf.org; Sat, 03 Apr 2004 23:29:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9zFv-0006P1-00; Sat, 03 Apr 2004 23:29:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zFl-0003ze-C2; Sat, 03 Apr 2004 23:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zF6-0003w0-9S for simple@optimus.ietf.org; Sat, 03 Apr 2004 23:28:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17475 for ; Sat, 3 Apr 2004 23:28:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zF4-0006Nn-00 for simple@ietf.org; Sat, 03 Apr 2004 23:28:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9zE8-0006IM-00 for simple@ietf.org; Sat, 03 Apr 2004 23:27:21 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1B9zDh-0006Ci-00; Sat, 03 Apr 2004 23:26:53 -0500 Received: from bear.cs.columbia.edu (IDENT:0e+4iOyoYYcqa1v1mKFR9ayQMDBCnWuS@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i344Qj0h019529 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 3 Apr 2004 23:26:45 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i344PlPs023600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 3 Apr 2004 23:25:48 -0500 Message-ID: <406F8E45.1070101@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 2004.4.2.96241 X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 2004.4.2.96241 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __NEW_DOMAIN_EXTENSIONS_2 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 03 Apr 2004 23:25:41 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > I wasn't referring to the ordering of _rules_, but ordering of > _actions_, such as . For instance what happens if the > same watcher/recipient is given several (unorthogonal) actions - for > instance and by different rules. > There is no way of deciding what to do, unless the actions that are > unorthogonal are given integer values (per chapter 10 of the draft > you refer to), i.e. there is at least partial ordering of actions. > (Orthogonal actions can be combined with union still.) I had suggested exactly such an ordering of actions earlier. I agree that action ordering is necessary to make things work. I hope we all agree that rule ordering is evil. > > I think Jonathan's example would be OK, if we say that > is the default given to watchers not matched by > any rule, so the last rule: The 'NULL' action is the default and does not need to be expressed explicitly. In this case, deny is a sensible default (see below). > However, I think in another thread in SIMPLE Henning has suggested > (as far as I understood it)actually that could have > lower "number" than , and that has been debated. My earlier post assumed that you only had domain-specific blacklists. If we allow global, rule-specific blacklists, you could do this with (1) everybody except blacklist: confirmation required (2) whitelist: accept subscription and making 'deny' the default behavior for those not matching any rule (which includes those on the blacklist). In that case, you wouldn't really need 'deny' as an action since it would never appear in a rule, as far as I can tell. You obviously have to be careful to include the blacklist on any other rule that might match a blacklist resident, in particular domain-wide matches, but that's a generic problem. Example: (3) columbia.edu: accept subscription during business hours would need to be qualified with any blacklisted columbia.edu addresses. I don't think you can have a stalker blacklist if you make confirmation-required the default behavior, except by the contorted ordering that I proposed earlier, where deny has the *highest* ranking and trumps anything else. The problem with that ordering is that it is not privacy safe under unreliable composition [PSURC]. (My more precise definition of unreliable composition: some complete rules may be at another location and may not be reliably available when making a decision.) My model above is PSURC since if rule (1) is not available, everybody except the whitelist will be denied without getting to knock. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Apr 3 23:30:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17559 for ; Sat, 3 Apr 2004 23:30:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zH6-0004BJ-Ux for simple-archive@odin.ietf.org; Sat, 03 Apr 2004 23:30:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i344UOH7016074 for simple-archive@odin.ietf.org; Sat, 3 Apr 2004 23:30:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zH6-0004BB-QJ for simple-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 23:30:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17537 for ; Sat, 3 Apr 2004 23:30:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zH4-0006b4-00 for simple-web-archive@ietf.org; Sat, 03 Apr 2004 23:30:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9zG7-0006V7-00 for simple-web-archive@ietf.org; Sat, 03 Apr 2004 23:29:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9zFv-0006P1-00; Sat, 03 Apr 2004 23:29:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zFl-0003ze-C2; Sat, 03 Apr 2004 23:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9zF6-0003w0-9S for simple@optimus.ietf.org; Sat, 03 Apr 2004 23:28:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17475 for ; Sat, 3 Apr 2004 23:28:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9zF4-0006Nn-00 for simple@ietf.org; Sat, 03 Apr 2004 23:28:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9zE8-0006IM-00 for simple@ietf.org; Sat, 03 Apr 2004 23:27:21 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1B9zDh-0006Ci-00; Sat, 03 Apr 2004 23:26:53 -0500 Received: from bear.cs.columbia.edu (IDENT:0e+4iOyoYYcqa1v1mKFR9ayQMDBCnWuS@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i344Qj0h019529 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 3 Apr 2004 23:26:45 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i344PlPs023600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 3 Apr 2004 23:25:48 -0500 Message-ID: <406F8E45.1070101@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 2004.4.2.96241 X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 2004.4.2.96241 X-PerlMx-Spam: Gauge=XII, Probability=12%, Report='X_NJABL_DUL 1, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __NEW_DOMAIN_EXTENSIONS_2 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RCVD_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 03 Apr 2004 23:25:41 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I wasn't referring to the ordering of _rules_, but ordering of > _actions_, such as . For instance what happens if the > same watcher/recipient is given several (unorthogonal) actions - for > instance and by different rules. > There is no way of deciding what to do, unless the actions that are > unorthogonal are given integer values (per chapter 10 of the draft > you refer to), i.e. there is at least partial ordering of actions. > (Orthogonal actions can be combined with union still.) I had suggested exactly such an ordering of actions earlier. I agree that action ordering is necessary to make things work. I hope we all agree that rule ordering is evil. > > I think Jonathan's example would be OK, if we say that > is the default given to watchers not matched by > any rule, so the last rule: The 'NULL' action is the default and does not need to be expressed explicitly. In this case, deny is a sensible default (see below). > However, I think in another thread in SIMPLE Henning has suggested > (as far as I understood it)actually that could have > lower "number" than , and that has been debated. My earlier post assumed that you only had domain-specific blacklists. If we allow global, rule-specific blacklists, you could do this with (1) everybody except blacklist: confirmation required (2) whitelist: accept subscription and making 'deny' the default behavior for those not matching any rule (which includes those on the blacklist). In that case, you wouldn't really need 'deny' as an action since it would never appear in a rule, as far as I can tell. You obviously have to be careful to include the blacklist on any other rule that might match a blacklist resident, in particular domain-wide matches, but that's a generic problem. Example: (3) columbia.edu: accept subscription during business hours would need to be qualified with any blacklisted columbia.edu addresses. I don't think you can have a stalker blacklist if you make confirmation-required the default behavior, except by the contorted ordering that I proposed earlier, where deny has the *highest* ranking and trumps anything else. The problem with that ordering is that it is not privacy safe under unreliable composition [PSURC]. (My more precise definition of unreliable composition: some complete rules may be at another location and may not be reliably available when making a decision.) My model above is PSURC since if rule (1) is not available, everybody except the whitelist will be denied without getting to knock. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 00:44:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26205 for ; Mon, 5 Apr 2004 00:44:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BALxv-0004cA-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 00:44:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BALwy-0004VV-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 00:43:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BALw3-0004Pp-00; Mon, 05 Apr 2004 00:42:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALvu-0008Uo-0P; Mon, 05 Apr 2004 00:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALv6-0008Li-21 for simple@optimus.ietf.org; Mon, 05 Apr 2004 00:41:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26163 for ; Mon, 5 Apr 2004 00:41:08 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BALv3-0004Jq-00 for simple@ietf.org; Mon, 05 Apr 2004 00:41:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BALu4-0004FA-00 for simple@ietf.org; Mon, 05 Apr 2004 00:40:09 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BALtg-00049y-00 for simple@ietf.org; Mon, 05 Apr 2004 00:39:44 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i354d524008631 for ; Mon, 5 Apr 2004 10:09:08 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 05 Apr 2004 10:09:05 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 10:09:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <72001BBBF6CB124BA1C40E415914E213030185@blr-ec-msg04.wipro.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQZBQx25vwCvvgWQDSzN8vaMQ+2OABvndhQ To: , Cc: , , , X-OriginalArrivalTime: 05 Apr 2004 04:39:05.0235 (UTC) FILETIME=[ED205630:01C41AC7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 10:09:05 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Eric, In general: MDN are like: READ Receipt with additional parameters like :on Successful delivery the recipient's refusal to provide MDNs Or deletion (without display) of the message or display of the message contents DSN are :delivery receipts that notify that the message has arrived in the recipient's inbox on the server. So both give the response success or failure of the message. ---- I think we should give response for both (SUCCESS and FAILURE) in MSRP. Please correct my understanding. Thanking you, Regards, Sreeram -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Paul Kyzivat Sent: Saturday, April 03, 2004 4:08 AM To: Eric Burger Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP Eric, I can't speak for the others, but I have been lumping the notion of MDN=20 into DSN - perphaps distinguished by options or something. Maybe it is=20 useful to distinguish the two types, maybe not. Paul Eric Burger wrote: > nononononononono. >=20 > We are confusing two, different concepts here. A DSN lets the sender=20 > know that a relay attempt failed. IMHO, a positive DSN has not=20 > practical value (other than generating information that "might be=20 > useful", but of no use). ["Useful" information is how long it takes a > message to traverse the relays. What user cares?] >=20 > A MDN lets the sender know that the recipient received the message. >=20 > If you are a *user*, and you want to *know* if someone received a=20 > message, you are going to request a MDN. >=20 >=20 > Let's look at two cases from the example again: >=20 > A --> R1 --> R2 --> B >=20 > First case: > A sends to R1 > R1 tries to send to R2, but nobody is home. > R1 sends Failure DSN to A > A knows message was not delivered. Why? Because A receives the DSN. >=20 >=20 > Second case: > A sends to R1 > R1 sends to R2 (successfully - no DSN) > R2 disappears (no DSN) > A *knows* B did not get the message. > How does A know this? Because A requested a MDN, and it never got it. >=20 > One might say that A cannot tell the difference between a delivery=20 > failure and the user ignoring the message. One might say that one=20 > would be correct in that assertion, and that is by design. >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Chris Boulton [mailto:cboulton@ubiquity.com] >>Sent: Thursday, April 01, 2004 4:24 AM >>To: Ben Campbell; hisham.khartabil@nokia.com >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com;=20 >>simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com >>Subject: RE: [Simple] return receipt and delivery status notification=20 >>for MSRP >> >> >>I agree with Ben. If an entity requests delivery confirmation, it=20 >>cannot rely on the absence of a failure DSN to convey that the message >>was delivered successfully. So I feel that there is scope for both=20 >>failure/success DSN's and a requirement for appropriate text=20 >>describing procedures for the scenario where a positive DSN is=20 >>requested BUT none received. >> >>Out of interest - what are the current thoughts on exactly >>how a client >>will request a DSN conformation? >> >> >>Chris. >>=20 >> >> >>>-----Original Message----- >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 01 April 2004 02:46 >>>To: hisham.khartabil@nokia.com >>>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> >>simple@ietf.org; >> >>>rohan@cisco.com; aki.niemi@nokia.com >>>Subject: Re: [Simple] return receipt and delivery status notification >> >>for >> >>>MSRP >>> >>>I don't think so. Imagine the following scenario: >>> >>>A---R1---R2---B >>> >>>A sends a critically important message to B, telling B to >> >>buy stock in >> >>>messaging companies. >>> >>>A sends to R1 successfully, and R1 sends to R2 successfully. But R2=20 >>>fails to send to B. So he tries to send a negative DSN to A >> >>via R1. But >> >>>it turns out the failure killed all connectivity to and from >> >>R2, so he >> >>>cannot send it. >>> >>>The moral is, DSNs can fail just like any other kind of >> >>message. So if >>a >> >>>message absolutely positively must be delivered, you need to >> >>be able to >> >>>request positive DSN. Then A can at least notice it did not receive a >>>DSN, and act accordingly. >>> >>> >>>hisham.khartabil@nokia.com wrote: >>> >>>>My question was: How useful is it to have both notification modes >>> >>>(positive and negative) for session IMs? Isn't notification >> >>on failure >> >>>enough? >>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>Sent: 01.April.2004 01:45 >>>>>To: Orit Levin >>>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com;=20 >>>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>(Nokia-M/Espoo) >>>>>Subject: Re: [Simple] return receipt and delivery status >>>> >>notification >> >>>>>for MSRP >>>>> >>>>> >>>>> >>>>>As Orit says, DSN will be very important for MSRP. >>>>> >>>>>The current thinking is that MSRP relays will be session stateless, >>>>>and that transactions are entirely hop-by-hop. The relay >>>>>semantics would be >>>>>similar to those of the SIMS draft, with MSRP syntax. >>>>> >>>>>As Orit hinted, this means that a transaction response is merely an >>>>>indication that the transaction succeeded, not that the message has >>>>>reached its destination. So in non peer-to-peer sessions, DSN is=20 >>>>>critical. >>>>> >>>>>We do expect it to be optional, as it is much less useful in the=20 >>>>>peer-to-peer case, where is just constitutes redundant messaging. >>>>> >>>>>Orit Levin wrote: >>>>> >>>>> >>>>>>Hisham, >>>>>>It is VERY useful because >>>>>> >>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you >>>>> >>whether the >> >>>>>>message was actually delivered end-to-end. >>>>>>2. MSRP hop-by-hop application-timer-based mechanism >>>>> >>>>>doesn't prevent you >>>>> >>>>>>from getting negative acknowledge in a case when the message was >>>>> >>>>>>actually delivered to the destination. In other words, it >>>>> >>>>>doesn't solve >>>>> >>>>> >>>>>>a duplication problem. >>>>>> >>>>>>I would like to add the requirement that the "end-to-end" >>>>> >>>>>DSN receipt >>>>> >>>>> >>>>>>needs to be requested per message (not negotiated for the >>>>> >>>>>whole session >>>>> >>>>> >>>>>>for all messages). It will allow for writing different IM >>>>> >>behaviors >> >>>>>>using the same mechanism. Such as: >>>>>> >>>>>>1. Loose IM session: all the user messages are sent without >>>>> >>>>>receipt, but >>>>> >>>>> >>>>>>the application sends a heartbeat message with requesting a >>>>> >>>>>receipt for >>>>> >>>>> >>>>>>each. >>>>>>2. Typical IM session: For all user messages a receipt is >>>>> >>>>>requested but >>>>> >>>>> >>>>>>the indication messages (e.g. "The user is typing") are delivered=20 >>>>>>without any receipt. >>>>>> >>>>>>Thanks, >>>>>>Orit. >>>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>>>> >>>>>On Behalf Of >>>>> >>>>> >>>>>>hisham.khartabil@nokia.com >>>>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>>>To: vkg@lucent.com >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com;=20 >>>>>>aki.niemi@nokia.com >>>>>>Subject: RE: [Simple] return receipt and delivery status >>>>> >>>>>notification >>>>> >>>>> >>>>>>for MSRP >>>>>> >>>>>>This is a good summary, although point 4 can be debatable: >>>>> >>>>>How useful is >>>>> >>>>> >>>>>>it to request receive notification in session mode? >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>>>Sent: 04.March.2004 16:53 >>>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>>>(Nokia-M/Espoo) >>>>>>>Subject: Re: [Simple] return receipt and delivery status >>>>>> >>>>>notification >>>>> >>>>> >>>>>>>for MSRP >>>>>>> >>>>>>> >>>>>>> >>>>>>>hisham.khartabil@nokia.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>It is optional. If it is annoying to you, then you >>>>>>> >>don't request a >> >>>>>>>>delivery notification. It is not every time and it is not >>>>>>> >>>>>mandatory. >>>>> >>>>> >>>>>>>So, just to be pedantic, please correct me if my summary below is >>>>>>>wrong: >>>>>>> >>>>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>>>> _protocol_ level (i.e. the transactional model at the >>>>>>> protocol level is sufficient for protocol state >>>>>>> machines to figure out if an IM was delivered to the >>>>>>> next hop successfully or not). >>>>>>> 2/ We should design protocol provisions such that a positive >>>>>>> acknowledgement DSN model is supported (let me know >>>>>>> the current state of the IM: queued, delivered, read, >>>>>>> being responded to, ...). >>>>>>> 3/ We should design protocol provisions such that a negative >>>>>>> acknowledgement DSN model is supported (send it and >>>>>>> forget it unless something drastic happens, then >>>>>>> let me know). >>>>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>>>> mode IMs. >>>>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>>>> user. >>>>>>> >>>>>>>Is this accurate? >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>- vijay >>>>>>>-- >>>>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>>>Wireless Networks Group/Internet Software and Services Lucent=20 >>>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >> >>This message has been scanned for viruses by MailControl -=20 >=20 > www.mailcontrol.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 00:44:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26261 for ; Mon, 5 Apr 2004 00:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALxy-0000Hk-Ux for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 00:44:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i354iANB001097 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 00:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALxy-0000Hc-Oc for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 00:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26225 for ; Mon, 5 Apr 2004 00:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BALxw-0004cF-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 00:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BALwz-0004Vc-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 00:43:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BALw3-0004Pp-00; Mon, 05 Apr 2004 00:42:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALvu-0008Uo-0P; Mon, 05 Apr 2004 00:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALv6-0008Li-21 for simple@optimus.ietf.org; Mon, 05 Apr 2004 00:41:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26163 for ; Mon, 5 Apr 2004 00:41:08 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BALv3-0004Jq-00 for simple@ietf.org; Mon, 05 Apr 2004 00:41:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BALu4-0004FA-00 for simple@ietf.org; Mon, 05 Apr 2004 00:40:09 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BALtg-00049y-00 for simple@ietf.org; Mon, 05 Apr 2004 00:39:44 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i354d524008631 for ; Mon, 5 Apr 2004 10:09:08 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 05 Apr 2004 10:09:05 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 10:09:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <72001BBBF6CB124BA1C40E415914E213030185@blr-ec-msg04.wipro.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQZBQx25vwCvvgWQDSzN8vaMQ+2OABvndhQ To: , Cc: , , , X-OriginalArrivalTime: 05 Apr 2004 04:39:05.0235 (UTC) FILETIME=[ED205630:01C41AC7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 10:09:05 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Eric, In general: MDN are like: READ Receipt with additional parameters like :on Successful delivery the recipient's refusal to provide MDNs Or deletion (without display) of the message or display of the message contents DSN are :delivery receipts that notify that the message has arrived in the recipient's inbox on the server. So both give the response success or failure of the message. ---- I think we should give response for both (SUCCESS and FAILURE) in MSRP. Please correct my understanding. Thanking you, Regards, Sreeram -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Paul Kyzivat Sent: Saturday, April 03, 2004 4:08 AM To: Eric Burger Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP Eric, I can't speak for the others, but I have been lumping the notion of MDN=20 into DSN - perphaps distinguished by options or something. Maybe it is=20 useful to distinguish the two types, maybe not. Paul Eric Burger wrote: > nononononononono. >=20 > We are confusing two, different concepts here. A DSN lets the sender=20 > know that a relay attempt failed. IMHO, a positive DSN has not=20 > practical value (other than generating information that "might be=20 > useful", but of no use). ["Useful" information is how long it takes a > message to traverse the relays. What user cares?] >=20 > A MDN lets the sender know that the recipient received the message. >=20 > If you are a *user*, and you want to *know* if someone received a=20 > message, you are going to request a MDN. >=20 >=20 > Let's look at two cases from the example again: >=20 > A --> R1 --> R2 --> B >=20 > First case: > A sends to R1 > R1 tries to send to R2, but nobody is home. > R1 sends Failure DSN to A > A knows message was not delivered. Why? Because A receives the DSN. >=20 >=20 > Second case: > A sends to R1 > R1 sends to R2 (successfully - no DSN) > R2 disappears (no DSN) > A *knows* B did not get the message. > How does A know this? Because A requested a MDN, and it never got it. >=20 > One might say that A cannot tell the difference between a delivery=20 > failure and the user ignoring the message. One might say that one=20 > would be correct in that assertion, and that is by design. >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Chris Boulton [mailto:cboulton@ubiquity.com] >>Sent: Thursday, April 01, 2004 4:24 AM >>To: Ben Campbell; hisham.khartabil@nokia.com >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com;=20 >>simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com >>Subject: RE: [Simple] return receipt and delivery status notification=20 >>for MSRP >> >> >>I agree with Ben. If an entity requests delivery confirmation, it=20 >>cannot rely on the absence of a failure DSN to convey that the message >>was delivered successfully. So I feel that there is scope for both=20 >>failure/success DSN's and a requirement for appropriate text=20 >>describing procedures for the scenario where a positive DSN is=20 >>requested BUT none received. >> >>Out of interest - what are the current thoughts on exactly >>how a client >>will request a DSN conformation? >> >> >>Chris. >>=20 >> >> >>>-----Original Message----- >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 01 April 2004 02:46 >>>To: hisham.khartabil@nokia.com >>>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> >>simple@ietf.org; >> >>>rohan@cisco.com; aki.niemi@nokia.com >>>Subject: Re: [Simple] return receipt and delivery status notification >> >>for >> >>>MSRP >>> >>>I don't think so. Imagine the following scenario: >>> >>>A---R1---R2---B >>> >>>A sends a critically important message to B, telling B to >> >>buy stock in >> >>>messaging companies. >>> >>>A sends to R1 successfully, and R1 sends to R2 successfully. But R2=20 >>>fails to send to B. So he tries to send a negative DSN to A >> >>via R1. But >> >>>it turns out the failure killed all connectivity to and from >> >>R2, so he >> >>>cannot send it. >>> >>>The moral is, DSNs can fail just like any other kind of >> >>message. So if >>a >> >>>message absolutely positively must be delivered, you need to >> >>be able to >> >>>request positive DSN. Then A can at least notice it did not receive a >>>DSN, and act accordingly. >>> >>> >>>hisham.khartabil@nokia.com wrote: >>> >>>>My question was: How useful is it to have both notification modes >>> >>>(positive and negative) for session IMs? Isn't notification >> >>on failure >> >>>enough? >>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>Sent: 01.April.2004 01:45 >>>>>To: Orit Levin >>>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com;=20 >>>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>(Nokia-M/Espoo) >>>>>Subject: Re: [Simple] return receipt and delivery status >>>> >>notification >> >>>>>for MSRP >>>>> >>>>> >>>>> >>>>>As Orit says, DSN will be very important for MSRP. >>>>> >>>>>The current thinking is that MSRP relays will be session stateless, >>>>>and that transactions are entirely hop-by-hop. The relay >>>>>semantics would be >>>>>similar to those of the SIMS draft, with MSRP syntax. >>>>> >>>>>As Orit hinted, this means that a transaction response is merely an >>>>>indication that the transaction succeeded, not that the message has >>>>>reached its destination. So in non peer-to-peer sessions, DSN is=20 >>>>>critical. >>>>> >>>>>We do expect it to be optional, as it is much less useful in the=20 >>>>>peer-to-peer case, where is just constitutes redundant messaging. >>>>> >>>>>Orit Levin wrote: >>>>> >>>>> >>>>>>Hisham, >>>>>>It is VERY useful because >>>>>> >>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you >>>>> >>whether the >> >>>>>>message was actually delivered end-to-end. >>>>>>2. MSRP hop-by-hop application-timer-based mechanism >>>>> >>>>>doesn't prevent you >>>>> >>>>>>from getting negative acknowledge in a case when the message was >>>>> >>>>>>actually delivered to the destination. In other words, it >>>>> >>>>>doesn't solve >>>>> >>>>> >>>>>>a duplication problem. >>>>>> >>>>>>I would like to add the requirement that the "end-to-end" >>>>> >>>>>DSN receipt >>>>> >>>>> >>>>>>needs to be requested per message (not negotiated for the >>>>> >>>>>whole session >>>>> >>>>> >>>>>>for all messages). It will allow for writing different IM >>>>> >>behaviors >> >>>>>>using the same mechanism. Such as: >>>>>> >>>>>>1. Loose IM session: all the user messages are sent without >>>>> >>>>>receipt, but >>>>> >>>>> >>>>>>the application sends a heartbeat message with requesting a >>>>> >>>>>receipt for >>>>> >>>>> >>>>>>each. >>>>>>2. Typical IM session: For all user messages a receipt is >>>>> >>>>>requested but >>>>> >>>>> >>>>>>the indication messages (e.g. "The user is typing") are delivered=20 >>>>>>without any receipt. >>>>>> >>>>>>Thanks, >>>>>>Orit. >>>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>>>> >>>>>On Behalf Of >>>>> >>>>> >>>>>>hisham.khartabil@nokia.com >>>>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>>>To: vkg@lucent.com >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com;=20 >>>>>>aki.niemi@nokia.com >>>>>>Subject: RE: [Simple] return receipt and delivery status >>>>> >>>>>notification >>>>> >>>>> >>>>>>for MSRP >>>>>> >>>>>>This is a good summary, although point 4 can be debatable: >>>>> >>>>>How useful is >>>>> >>>>> >>>>>>it to request receive notification in session mode? >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>>>Sent: 04.March.2004 16:53 >>>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>>>(Nokia-M/Espoo) >>>>>>>Subject: Re: [Simple] return receipt and delivery status >>>>>> >>>>>notification >>>>> >>>>> >>>>>>>for MSRP >>>>>>> >>>>>>> >>>>>>> >>>>>>>hisham.khartabil@nokia.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>It is optional. If it is annoying to you, then you >>>>>>> >>don't request a >> >>>>>>>>delivery notification. It is not every time and it is not >>>>>>> >>>>>mandatory. >>>>> >>>>> >>>>>>>So, just to be pedantic, please correct me if my summary below is >>>>>>>wrong: >>>>>>> >>>>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>>>> _protocol_ level (i.e. the transactional model at the >>>>>>> protocol level is sufficient for protocol state >>>>>>> machines to figure out if an IM was delivered to the >>>>>>> next hop successfully or not). >>>>>>> 2/ We should design protocol provisions such that a positive >>>>>>> acknowledgement DSN model is supported (let me know >>>>>>> the current state of the IM: queued, delivered, read, >>>>>>> being responded to, ...). >>>>>>> 3/ We should design protocol provisions such that a negative >>>>>>> acknowledgement DSN model is supported (send it and >>>>>>> forget it unless something drastic happens, then >>>>>>> let me know). >>>>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>>>> mode IMs. >>>>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>>>> user. >>>>>>> >>>>>>>Is this accurate? >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>- vijay >>>>>>>-- >>>>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>>>Wireless Networks Group/Internet Software and Services Lucent=20 >>>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >> >>This message has been scanned for viruses by MailControl -=20 >=20 > www.mailcontrol.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 01:21:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27186 for ; Mon, 5 Apr 2004 01:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAMXh-0000Xz-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 01:21:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAMWk-0000Sr-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 01:20:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAMVn-0000Nm-00; Mon, 05 Apr 2004 01:19:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAMVh-0004HP-ML; Mon, 05 Apr 2004 01:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAMUv-0004E6-Fj for simple@optimus.ietf.org; Mon, 05 Apr 2004 01:18:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27146 for ; Mon, 5 Apr 2004 01:18:11 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAMUs-0000IE-00 for simple@ietf.org; Mon, 05 Apr 2004 01:18:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAMTx-0000Cp-00 for simple@ietf.org; Mon, 05 Apr 2004 01:17:15 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BAMTD-00000i-00 for simple@ietf.org; Mon, 05 Apr 2004 01:16:28 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i355Ft24009706 for ; Mon, 5 Apr 2004 10:45:55 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 05 Apr 2004 10:45:55 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 10:45:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <72001BBBF6CB124BA1C40E415914E213030186@blr-ec-msg04.wipro.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQZBQx25vwCvvgWQDSzN8vaMQ+2OABvndhQAAJDi4A= To: , , Cc: , , , X-OriginalArrivalTime: 05 Apr 2004 05:15:54.0446 (UTC) FILETIME=[11EB2EE0:01C41ACD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 10:45:54 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Added to that, I understand that MSRP is hop-to-hop so the DSN are not in this case upto the end receipt!! So,my comments: 1.we should give response for both success and failure responses (DSN) 2.we should define MDN and DSN if needed as per MSRP=20 -Sreeram -----Original Message----- From: Sreeram Kanumuri (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS)=20 Sent: Monday, April 05, 2004 10:09 AM To: 'Paul Kyzivat'; Eric Burger Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; simple@ietf.org Subject: RE: [Simple] return receipt and delivery status notification for MSRP Eric, In general: MDN are like: READ Receipt with additional parameters like :on Successful delivery the recipient's refusal to provide MDNs Or deletion (without display) of the message or display of the message contents DSN are :delivery receipts that notify that the message has arrived in the recipient's inbox on the server. So both give the response success or failure of the message. ---- I think we should give response for both (SUCCESS and FAILURE) in MSRP. Please correct my understanding. Thanking you, Regards, Sreeram -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Paul Kyzivat Sent: Saturday, April 03, 2004 4:08 AM To: Eric Burger Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP Eric, I can't speak for the others, but I have been lumping the notion of MDN=20 into DSN - perphaps distinguished by options or something. Maybe it is=20 useful to distinguish the two types, maybe not. Paul Eric Burger wrote: > nononononononono. >=20 > We are confusing two, different concepts here. A DSN lets the sender > know that a relay attempt failed. IMHO, a positive DSN has not=20 > practical value (other than generating information that "might be=20 > useful", but of no use). ["Useful" information is how long it takes a > message to traverse the relays. What user cares?] >=20 > A MDN lets the sender know that the recipient received the message. >=20 > If you are a *user*, and you want to *know* if someone received a > message, you are going to request a MDN. >=20 >=20 > Let's look at two cases from the example again: >=20 > A --> R1 --> R2 --> B >=20 > First case: > A sends to R1 > R1 tries to send to R2, but nobody is home. > R1 sends Failure DSN to A > A knows message was not delivered. Why? Because A receives the DSN. >=20 >=20 > Second case: > A sends to R1 > R1 sends to R2 (successfully - no DSN) > R2 disappears (no DSN) > A *knows* B did not get the message. > How does A know this? Because A requested a MDN, and it never got it. >=20 > One might say that A cannot tell the difference between a delivery > failure and the user ignoring the message. One might say that one=20 > would be correct in that assertion, and that is by design. >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Chris Boulton [mailto:cboulton@ubiquity.com] >>Sent: Thursday, April 01, 2004 4:24 AM >>To: Ben Campbell; hisham.khartabil@nokia.com >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >>simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com >>Subject: RE: [Simple] return receipt and delivery status notification=20 >>for MSRP >> >> >>I agree with Ben. If an entity requests delivery confirmation, it >>cannot rely on the absence of a failure DSN to convey that the message >>was delivered successfully. So I feel that there is scope for both=20 >>failure/success DSN's and a requirement for appropriate text=20 >>describing procedures for the scenario where a positive DSN is=20 >>requested BUT none received. >> >>Out of interest - what are the current thoughts on exactly how a=20 >>client will request a DSN conformation? >> >> >>Chris. >>=20 >> >> >>>-----Original Message----- >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 01 April 2004 02:46 >>>To: hisham.khartabil@nokia.com >>>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> >>simple@ietf.org; >> >>>rohan@cisco.com; aki.niemi@nokia.com >>>Subject: Re: [Simple] return receipt and delivery status notification >> >>for >> >>>MSRP >>> >>>I don't think so. Imagine the following scenario: >>> >>>A---R1---R2---B >>> >>>A sends a critically important message to B, telling B to >> >>buy stock in >> >>>messaging companies. >>> >>>A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >>>fails to send to B. So he tries to send a negative DSN to A >> >>via R1. But >> >>>it turns out the failure killed all connectivity to and from >> >>R2, so he >> >>>cannot send it. >>> >>>The moral is, DSNs can fail just like any other kind of >> >>message. So if >>a >> >>>message absolutely positively must be delivered, you need to >> >>be able to >> >>>request positive DSN. Then A can at least notice it did not receive a >>>DSN, and act accordingly. >>> >>> >>>hisham.khartabil@nokia.com wrote: >>> >>>>My question was: How useful is it to have both notification modes >>> >>>(positive and negative) for session IMs? Isn't notification >> >>on failure >> >>>enough? >>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>Sent: 01.April.2004 01:45 >>>>>To: Orit Levin >>>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >>>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>(Nokia-M/Espoo) >>>>>Subject: Re: [Simple] return receipt and delivery status >>>> >>notification >> >>>>>for MSRP >>>>> >>>>> >>>>> >>>>>As Orit says, DSN will be very important for MSRP. >>>>> >>>>>The current thinking is that MSRP relays will be session stateless, >>>>>and that transactions are entirely hop-by-hop. The relay >>>>>semantics would be >>>>>similar to those of the SIMS draft, with MSRP syntax. >>>>> >>>>>As Orit hinted, this means that a transaction response is merely an >>>>>indication that the transaction succeeded, not that the message has >>>>>reached its destination. So in non peer-to-peer sessions, DSN is=20 >>>>>critical. >>>>> >>>>>We do expect it to be optional, as it is much less useful in the >>>>>peer-to-peer case, where is just constitutes redundant messaging. >>>>> >>>>>Orit Levin wrote: >>>>> >>>>> >>>>>>Hisham, >>>>>>It is VERY useful because >>>>>> >>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you >>>>> >>whether the >> >>>>>>message was actually delivered end-to-end. >>>>>>2. MSRP hop-by-hop application-timer-based mechanism >>>>> >>>>>doesn't prevent you >>>>> >>>>>>from getting negative acknowledge in a case when the message was >>>>> >>>>>>actually delivered to the destination. In other words, it >>>>> >>>>>doesn't solve >>>>> >>>>> >>>>>>a duplication problem. >>>>>> >>>>>>I would like to add the requirement that the "end-to-end" >>>>> >>>>>DSN receipt >>>>> >>>>> >>>>>>needs to be requested per message (not negotiated for the >>>>> >>>>>whole session >>>>> >>>>> >>>>>>for all messages). It will allow for writing different IM >>>>> >>behaviors >> >>>>>>using the same mechanism. Such as: >>>>>> >>>>>>1. Loose IM session: all the user messages are sent without >>>>> >>>>>receipt, but >>>>> >>>>> >>>>>>the application sends a heartbeat message with requesting a >>>>> >>>>>receipt for >>>>> >>>>> >>>>>>each. >>>>>>2. Typical IM session: For all user messages a receipt is >>>>> >>>>>requested but >>>>> >>>>> >>>>>>the indication messages (e.g. "The user is typing") are delivered >>>>>>without any receipt. >>>>>> >>>>>>Thanks, >>>>>>Orit. >>>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>>>> >>>>>On Behalf Of >>>>> >>>>> >>>>>>hisham.khartabil@nokia.com >>>>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>>>To: vkg@lucent.com >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >>>>>>aki.niemi@nokia.com >>>>>>Subject: RE: [Simple] return receipt and delivery status >>>>> >>>>>notification >>>>> >>>>> >>>>>>for MSRP >>>>>> >>>>>>This is a good summary, although point 4 can be debatable: >>>>> >>>>>How useful is >>>>> >>>>> >>>>>>it to request receive notification in session mode? >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>>>Sent: 04.March.2004 16:53 >>>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>>>(Nokia-M/Espoo) >>>>>>>Subject: Re: [Simple] return receipt and delivery status >>>>>> >>>>>notification >>>>> >>>>> >>>>>>>for MSRP >>>>>>> >>>>>>> >>>>>>> >>>>>>>hisham.khartabil@nokia.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>It is optional. If it is annoying to you, then you >>>>>>> >>don't request a >> >>>>>>>>delivery notification. It is not every time and it is not >>>>>>> >>>>>mandatory. >>>>> >>>>> >>>>>>>So, just to be pedantic, please correct me if my summary below is >>>>>>>wrong: >>>>>>> >>>>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>>>> _protocol_ level (i.e. the transactional model at the >>>>>>> protocol level is sufficient for protocol state >>>>>>> machines to figure out if an IM was delivered to the >>>>>>> next hop successfully or not). >>>>>>> 2/ We should design protocol provisions such that a positive >>>>>>> acknowledgement DSN model is supported (let me know >>>>>>> the current state of the IM: queued, delivered, read, >>>>>>> being responded to, ...). >>>>>>> 3/ We should design protocol provisions such that a negative >>>>>>> acknowledgement DSN model is supported (send it and >>>>>>> forget it unless something drastic happens, then >>>>>>> let me know). >>>>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>>>> mode IMs. >>>>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>>>> user. >>>>>>> >>>>>>>Is this accurate? >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>- vijay >>>>>>>-- >>>>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>>>Wireless Networks Group/Internet Software and Services Lucent >>>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >> >> >>This message has been scanned for viruses by MailControl -=20 >=20 > www.mailcontrol.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 01:21:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27211 for ; Mon, 5 Apr 2004 01:21:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAMXl-0004Zn-C7 for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 01:21:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i355L9c6017592 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 01:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAMXl-0004Zf-3x for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 01:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27204 for ; Mon, 5 Apr 2004 01:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAMXi-0000Y4-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 01:21:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAMWl-0000Sy-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 01:20:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAMVn-0000Nm-00; Mon, 05 Apr 2004 01:19:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAMVh-0004HP-ML; Mon, 05 Apr 2004 01:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAMUv-0004E6-Fj for simple@optimus.ietf.org; Mon, 05 Apr 2004 01:18:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27146 for ; Mon, 5 Apr 2004 01:18:11 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAMUs-0000IE-00 for simple@ietf.org; Mon, 05 Apr 2004 01:18:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAMTx-0000Cp-00 for simple@ietf.org; Mon, 05 Apr 2004 01:17:15 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BAMTD-00000i-00 for simple@ietf.org; Mon, 05 Apr 2004 01:16:28 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i355Ft24009706 for ; Mon, 5 Apr 2004 10:45:55 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 05 Apr 2004 10:45:55 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 10:45:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <72001BBBF6CB124BA1C40E415914E213030186@blr-ec-msg04.wipro.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQZBQx25vwCvvgWQDSzN8vaMQ+2OABvndhQAAJDi4A= To: , , Cc: , , , X-OriginalArrivalTime: 05 Apr 2004 05:15:54.0446 (UTC) FILETIME=[11EB2EE0:01C41ACD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 10:45:54 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Added to that, I understand that MSRP is hop-to-hop so the DSN are not in this case upto the end receipt!! So,my comments: 1.we should give response for both success and failure responses (DSN) 2.we should define MDN and DSN if needed as per MSRP=20 -Sreeram -----Original Message----- From: Sreeram Kanumuri (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS)=20 Sent: Monday, April 05, 2004 10:09 AM To: 'Paul Kyzivat'; Eric Burger Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; simple@ietf.org Subject: RE: [Simple] return receipt and delivery status notification for MSRP Eric, In general: MDN are like: READ Receipt with additional parameters like :on Successful delivery the recipient's refusal to provide MDNs Or deletion (without display) of the message or display of the message contents DSN are :delivery receipts that notify that the message has arrived in the recipient's inbox on the server. So both give the response success or failure of the message. ---- I think we should give response for both (SUCCESS and FAILURE) in MSRP. Please correct my understanding. Thanking you, Regards, Sreeram -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Paul Kyzivat Sent: Saturday, April 03, 2004 4:08 AM To: Eric Burger Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP Eric, I can't speak for the others, but I have been lumping the notion of MDN=20 into DSN - perphaps distinguished by options or something. Maybe it is=20 useful to distinguish the two types, maybe not. Paul Eric Burger wrote: > nononononononono. >=20 > We are confusing two, different concepts here. A DSN lets the sender > know that a relay attempt failed. IMHO, a positive DSN has not=20 > practical value (other than generating information that "might be=20 > useful", but of no use). ["Useful" information is how long it takes a > message to traverse the relays. What user cares?] >=20 > A MDN lets the sender know that the recipient received the message. >=20 > If you are a *user*, and you want to *know* if someone received a > message, you are going to request a MDN. >=20 >=20 > Let's look at two cases from the example again: >=20 > A --> R1 --> R2 --> B >=20 > First case: > A sends to R1 > R1 tries to send to R2, but nobody is home. > R1 sends Failure DSN to A > A knows message was not delivered. Why? Because A receives the DSN. >=20 >=20 > Second case: > A sends to R1 > R1 sends to R2 (successfully - no DSN) > R2 disappears (no DSN) > A *knows* B did not get the message. > How does A know this? Because A requested a MDN, and it never got it. >=20 > One might say that A cannot tell the difference between a delivery > failure and the user ignoring the message. One might say that one=20 > would be correct in that assertion, and that is by design. >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Chris Boulton [mailto:cboulton@ubiquity.com] >>Sent: Thursday, April 01, 2004 4:24 AM >>To: Ben Campbell; hisham.khartabil@nokia.com >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >>simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com >>Subject: RE: [Simple] return receipt and delivery status notification=20 >>for MSRP >> >> >>I agree with Ben. If an entity requests delivery confirmation, it >>cannot rely on the absence of a failure DSN to convey that the message >>was delivered successfully. So I feel that there is scope for both=20 >>failure/success DSN's and a requirement for appropriate text=20 >>describing procedures for the scenario where a positive DSN is=20 >>requested BUT none received. >> >>Out of interest - what are the current thoughts on exactly how a=20 >>client will request a DSN conformation? >> >> >>Chris. >>=20 >> >> >>>-----Original Message----- >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 01 April 2004 02:46 >>>To: hisham.khartabil@nokia.com >>>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> >>simple@ietf.org; >> >>>rohan@cisco.com; aki.niemi@nokia.com >>>Subject: Re: [Simple] return receipt and delivery status notification >> >>for >> >>>MSRP >>> >>>I don't think so. Imagine the following scenario: >>> >>>A---R1---R2---B >>> >>>A sends a critically important message to B, telling B to >> >>buy stock in >> >>>messaging companies. >>> >>>A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >>>fails to send to B. So he tries to send a negative DSN to A >> >>via R1. But >> >>>it turns out the failure killed all connectivity to and from >> >>R2, so he >> >>>cannot send it. >>> >>>The moral is, DSNs can fail just like any other kind of >> >>message. So if >>a >> >>>message absolutely positively must be delivered, you need to >> >>be able to >> >>>request positive DSN. Then A can at least notice it did not receive a >>>DSN, and act accordingly. >>> >>> >>>hisham.khartabil@nokia.com wrote: >>> >>>>My question was: How useful is it to have both notification modes >>> >>>(positive and negative) for session IMs? Isn't notification >> >>on failure >> >>>enough? >>> >>>>/Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>Sent: 01.April.2004 01:45 >>>>>To: Orit Levin >>>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >>>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>(Nokia-M/Espoo) >>>>>Subject: Re: [Simple] return receipt and delivery status >>>> >>notification >> >>>>>for MSRP >>>>> >>>>> >>>>> >>>>>As Orit says, DSN will be very important for MSRP. >>>>> >>>>>The current thinking is that MSRP relays will be session stateless, >>>>>and that transactions are entirely hop-by-hop. The relay >>>>>semantics would be >>>>>similar to those of the SIMS draft, with MSRP syntax. >>>>> >>>>>As Orit hinted, this means that a transaction response is merely an >>>>>indication that the transaction succeeded, not that the message has >>>>>reached its destination. So in non peer-to-peer sessions, DSN is=20 >>>>>critical. >>>>> >>>>>We do expect it to be optional, as it is much less useful in the >>>>>peer-to-peer case, where is just constitutes redundant messaging. >>>>> >>>>>Orit Levin wrote: >>>>> >>>>> >>>>>>Hisham, >>>>>>It is VERY useful because >>>>>> >>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you >>>>> >>whether the >> >>>>>>message was actually delivered end-to-end. >>>>>>2. MSRP hop-by-hop application-timer-based mechanism >>>>> >>>>>doesn't prevent you >>>>> >>>>>>from getting negative acknowledge in a case when the message was >>>>> >>>>>>actually delivered to the destination. In other words, it >>>>> >>>>>doesn't solve >>>>> >>>>> >>>>>>a duplication problem. >>>>>> >>>>>>I would like to add the requirement that the "end-to-end" >>>>> >>>>>DSN receipt >>>>> >>>>> >>>>>>needs to be requested per message (not negotiated for the >>>>> >>>>>whole session >>>>> >>>>> >>>>>>for all messages). It will allow for writing different IM >>>>> >>behaviors >> >>>>>>using the same mechanism. Such as: >>>>>> >>>>>>1. Loose IM session: all the user messages are sent without >>>>> >>>>>receipt, but >>>>> >>>>> >>>>>>the application sends a heartbeat message with requesting a >>>>> >>>>>receipt for >>>>> >>>>> >>>>>>each. >>>>>>2. Typical IM session: For all user messages a receipt is >>>>> >>>>>requested but >>>>> >>>>> >>>>>>the indication messages (e.g. "The user is typing") are delivered >>>>>>without any receipt. >>>>>> >>>>>>Thanks, >>>>>>Orit. >>>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >>>>> >>>>>On Behalf Of >>>>> >>>>> >>>>>>hisham.khartabil@nokia.com >>>>>>Sent: Wednesday, March 31, 2004 9:26 AM >>>>>>To: vkg@lucent.com >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >>>>>>aki.niemi@nokia.com >>>>>>Subject: RE: [Simple] return receipt and delivery status >>>>> >>>>>notification >>>>> >>>>> >>>>>>for MSRP >>>>>> >>>>>>This is a good summary, although point 4 can be debatable: >>>>> >>>>>How useful is >>>>> >>>>> >>>>>>it to request receive notification in session mode? >>>>>> >>>>>>/Hisham >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >>>>>>>Sent: 04.March.2004 16:53 >>>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >>>>>>>(Nokia-M/Espoo) >>>>>>>Subject: Re: [Simple] return receipt and delivery status >>>>>> >>>>>notification >>>>> >>>>> >>>>>>>for MSRP >>>>>>> >>>>>>> >>>>>>> >>>>>>>hisham.khartabil@nokia.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>It is optional. If it is annoying to you, then you >>>>>>> >>don't request a >> >>>>>>>>delivery notification. It is not every time and it is not >>>>>>> >>>>>mandatory. >>>>> >>>>> >>>>>>>So, just to be pedantic, please correct me if my summary below is >>>>>>>wrong: >>>>>>> >>>>>>> 1/ We are interested in DSNs at the _user_ level, not the >>>>>>> _protocol_ level (i.e. the transactional model at the >>>>>>> protocol level is sufficient for protocol state >>>>>>> machines to figure out if an IM was delivered to the >>>>>>> next hop successfully or not). >>>>>>> 2/ We should design protocol provisions such that a positive >>>>>>> acknowledgement DSN model is supported (let me know >>>>>>> the current state of the IM: queued, delivered, read, >>>>>>> being responded to, ...). >>>>>>> 3/ We should design protocol provisions such that a negative >>>>>>> acknowledgement DSN model is supported (send it and >>>>>>> forget it unless something drastic happens, then >>>>>>> let me know). >>>>>>> 4/ Both 2 and 3 should apply to page mode and session >>>>>>> mode IMs. >>>>>>> 5/ Both 2 and 3 should be configurable by the sending >>>>>>> user. >>>>>>> >>>>>>>Is this accurate? >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>- vijay >>>>>>>-- >>>>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>>>>>Wireless Networks Group/Internet Software and Services Lucent >>>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >>>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >>>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >> >> >>This message has been scanned for viruses by MailControl -=20 >=20 > www.mailcontrol.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 04:36:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17472 for ; Mon, 5 Apr 2004 04:36:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPal-00078p-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 04:36:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPZs-000708-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 04:35:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAPYc-0006nH-04; Mon, 05 Apr 2004 04:34:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPI4-0000cO-E8; Mon, 05 Apr 2004 04:17:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAOL9-0008BN-5D for simple@optimus.ietf.org; Mon, 05 Apr 2004 03:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14910 for ; Mon, 5 Apr 2004 03:16:13 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAOL6-00065k-00 for simple@ietf.org; Mon, 05 Apr 2004 03:16:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAOKF-000604-00 for simple@ietf.org; Mon, 05 Apr 2004 03:15:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BAOJI-0005tp-00 for simple@ietf.org; Mon, 05 Apr 2004 03:14:20 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i357E3813975; Mon, 5 Apr 2004 10:14:03 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 10:13:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i357Dukk022680; Mon, 5 Apr 2004 10:13:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00fikg6O; Mon, 05 Apr 2004 10:13:55 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i357DVs18543; Mon, 5 Apr 2004 10:13:31 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 10:10:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP update Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797880@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP update Thread-Index: AcQYU+GP7yodhrkFSV60H2RzedoyHQCiLzJA To: , Cc: X-OriginalArrivalTime: 05 Apr 2004 07:10:33.0753 (UTC) FILETIME=[164E2090:01C41ADD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 10:10:33 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 01.April.2004 19:05 > To: Garcia Miguel.An (Nokia-NRC/Helsinki) > Cc: SIMPLE mailing list > Subject: Re: [Simple] MSRP update >=20 > >=20 > > 2) Connection management (section 7.2). It is written that=20 > an endpoint=20 > > should re-use an existing connection when the peer URL=20 > matches the host=20 > > part. Isn't this in contradiction with the text in section 5.1 that=20 > > says, when a large file is to be sent, the endpoint should=20 > create a new=20 > > MSRP session to avoid blocking? I would expect that "creating a new=20 > > session" comprises creating a new TCP connection as well,=20 > not re-using=20 > > an existing one. > >=20 > > We have similar procedures in 7.5.1, second bullet point=20 > for the answer. > >=20 >=20 > Yes, that needs to be rationalized. I believe I put in an open issue=20 > asking if we need to discuss situations where an endpoint would=20 > intentionally choose not to share a connection between=20 > session. (Unless=20 > I forgot. It happens). >=20 > There have been suggestions that we would remove the suggestion to=20 > create a new session once we have chunking described in the=20 > draft. Does=20 > anyone have thoughts on this point? >=20 Yes, I suggested removing such text :) I think when chunking is = introduced, the problem of blocking is reduced and therefore we don't = need text suggesting the creation of a new session. /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 04:36:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17524 for ; Mon, 5 Apr 2004 04:36:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPao-00044X-QJ for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 04:36:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i358aUAR015654 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 04:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPao-00044P-JW for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 04:36:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17490 for ; Mon, 5 Apr 2004 04:36:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPal-00078x-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 04:36:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPZt-00070F-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 04:35:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAPYc-0006nH-04; Mon, 05 Apr 2004 04:34:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPI4-0000cO-E8; Mon, 05 Apr 2004 04:17:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAOL9-0008BN-5D for simple@optimus.ietf.org; Mon, 05 Apr 2004 03:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14910 for ; Mon, 5 Apr 2004 03:16:13 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAOL6-00065k-00 for simple@ietf.org; Mon, 05 Apr 2004 03:16:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAOKF-000604-00 for simple@ietf.org; Mon, 05 Apr 2004 03:15:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BAOJI-0005tp-00 for simple@ietf.org; Mon, 05 Apr 2004 03:14:20 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i357E3813975; Mon, 5 Apr 2004 10:14:03 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 10:13:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i357Dukk022680; Mon, 5 Apr 2004 10:13:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00fikg6O; Mon, 05 Apr 2004 10:13:55 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i357DVs18543; Mon, 5 Apr 2004 10:13:31 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 10:10:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP update Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797880@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP update Thread-Index: AcQYU+GP7yodhrkFSV60H2RzedoyHQCiLzJA To: , Cc: X-OriginalArrivalTime: 05 Apr 2004 07:10:33.0753 (UTC) FILETIME=[164E2090:01C41ADD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 10:10:33 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 01.April.2004 19:05 > To: Garcia Miguel.An (Nokia-NRC/Helsinki) > Cc: SIMPLE mailing list > Subject: Re: [Simple] MSRP update >=20 > >=20 > > 2) Connection management (section 7.2). It is written that=20 > an endpoint=20 > > should re-use an existing connection when the peer URL=20 > matches the host=20 > > part. Isn't this in contradiction with the text in section 5.1 that=20 > > says, when a large file is to be sent, the endpoint should=20 > create a new=20 > > MSRP session to avoid blocking? I would expect that "creating a new=20 > > session" comprises creating a new TCP connection as well,=20 > not re-using=20 > > an existing one. > >=20 > > We have similar procedures in 7.5.1, second bullet point=20 > for the answer. > >=20 >=20 > Yes, that needs to be rationalized. I believe I put in an open issue=20 > asking if we need to discuss situations where an endpoint would=20 > intentionally choose not to share a connection between=20 > session. (Unless=20 > I forgot. It happens). >=20 > There have been suggestions that we would remove the suggestion to=20 > create a new session once we have chunking described in the=20 > draft. Does=20 > anyone have thoughts on this point? >=20 Yes, I suggested removing such text :) I think when chunking is = introduced, the problem of blocking is reduced and therefore we don't = need text suggesting the creation of a new session. /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 07:28:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23815 for ; Mon, 5 Apr 2004 07:28:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASHB-0004OA-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 07:28:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASGM-0004IR-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 07:27:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BASFx-0004C5-00; Mon, 05 Apr 2004 07:27:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASFp-0000zp-Cz; Mon, 05 Apr 2004 07:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASFR-0000zS-0F for simple@optimus.ietf.org; Mon, 05 Apr 2004 07:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23775 for ; Mon, 5 Apr 2004 07:26:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASFQ-0004Bp-00 for simple@ietf.org; Mon, 05 Apr 2004 07:26:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASET-00044c-00 for simple@ietf.org; Mon, 05 Apr 2004 07:25:39 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly05b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BASE3-0003xm-00 for simple@ietf.org; Mon, 05 Apr 2004 07:25:11 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05b.srv.mailcontrol.com (MailControl) with SMTP id i35BOW3d010398; Mon, 5 Apr 2004 12:24:32 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Mon, 5 Apr 2004 12:24:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B24E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQXi2UOVL+7l0diSEOwSwwg6zr+0gAPou5wADcEguAAlmevYA== From: "Chris Boulton" To: "Eric Burger" , "Ben Campbell" , Cc: X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 12:24:31 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Eric Burger [mailto:eburger@snowshore.com] >Sent: 02 April 2004 18:48 >To: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com >Cc: simple@ietf.org >Subject: RE: [Simple] return receipt and delivery status notification for >MSRP > >nononononononono. > >We are confusing two, different concepts here. A DSN lets the sender know >that a relay attempt failed. IMHO, a positive DSN has not practical value >(other than generating information that "might be useful", but of no use). >["Useful" information is how long it takes a message to traverse the >relays. What user cares?] [Chris Boulton] You care if you are sending an important message using a hop-by-hop protocol ;-) Receiving a positive DSN from the final destination of the request ensures delivery - Not receiving a negative DNS does not provide me with guarantee of delivery. Chris. > >A MDN lets the sender know that the recipient received the message. > >If you are a *user*, and you want to *know* if someone received a message, >you are going to request a MDN. > > >Let's look at two cases from the example again: > >A --> R1 --> R2 --> B > >First case: >A sends to R1 >R1 tries to send to R2, but nobody is home. >R1 sends Failure DSN to A >A knows message was not delivered. Why? Because A receives the DSN. > > >Second case: >A sends to R1 >R1 sends to R2 (successfully - no DSN) >R2 disappears (no DSN) >A *knows* B did not get the message. >How does A know this? Because A requested a MDN, and it never got it. > >One might say that A cannot tell the difference between a delivery failure >and the user ignoring the message. One might say that one would be correct >in that assertion, and that is by design. > > > >> -----Original Message----- >> From: Chris Boulton [mailto:cboulton@ubiquity.com] >> Sent: Thursday, April 01, 2004 4:24 AM >> To: Ben Campbell; hisham.khartabil@nokia.com >> Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com >> Subject: RE: [Simple] return receipt and delivery status notification >> for MSRP >> >> >> I agree with Ben. If an entity requests delivery confirmation, it >> cannot rely on the absence of a failure DSN to convey that the message >> was delivered successfully. So I feel that there is scope for both >> failure/success DSN's and a requirement for appropriate text >> describing >> procedures for the scenario where a positive DSN is requested BUT none >> received. >> >> Out of interest - what are the current thoughts on exactly >> how a client >> will request a DSN conformation? >> >> >> Chris. >> >> >> >-----Original Message----- >> >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> >Sent: 01 April 2004 02:46 >> >To: hisham.khartabil@nokia.com >> >Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> simple@ietf.org; >> >rohan@cisco.com; aki.niemi@nokia.com >> >Subject: Re: [Simple] return receipt and delivery status notification >> for >> >MSRP >> > >> >I don't think so. Imagine the following scenario: >> > >> >A---R1---R2---B >> > >> >A sends a critically important message to B, telling B to >> buy stock in >> >messaging companies. >> > >> >A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >> >fails to send to B. So he tries to send a negative DSN to A >> via R1. But >> >it turns out the failure killed all connectivity to and from >> R2, so he >> >cannot send it. >> > >> >The moral is, DSNs can fail just like any other kind of >> message. So if >> a >> >message absolutely positively must be delivered, you need to >> be able to >> >request positive DSN. Then A can at least notice it did not receive a >> >DSN, and act accordingly. >> > >> > >> >hisham.khartabil@nokia.com wrote: >> >> My question was: How useful is it to have both notification modes >> >(positive and negative) for session IMs? Isn't notification >> on failure >> >enough? >> >> >> >> /Hisham >> >> >> >> >> >>>-----Original Message----- >> >>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> >>>Sent: 01.April.2004 01:45 >> >>>To: Orit Levin >> >>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >> >>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >> >>>(Nokia-M/Espoo) >> >>>Subject: Re: [Simple] return receipt and delivery status >> notification >> >>>for MSRP >> >>> >> >>> >> >>> >> >>>As Orit says, DSN will be very important for MSRP. >> >>> >> >>>The current thinking is that MSRP relays will be session >> >>>stateless, and >> >>>that transactions are entirely hop-by-hop. The relay >> >>>semantics would be >> >>>similar to those of the SIMS draft, with MSRP syntax. >> >>> >> >>>As Orit hinted, this means that a transaction response is merely an >> >>>indication that the transaction succeeded, not that the message has >> >>>reached its destination. So in non peer-to-peer sessions, DSN >> >>>is critical. >> >>> >> >>>We do expect it to be optional, as it is much less useful in the >> >>>peer-to-peer case, where is just constitutes redundant messaging. >> >>> >> >>>Orit Levin wrote: >> >>> >> >>>>Hisham, >> >>>>It is VERY useful because >> >>>> >> >>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you >> whether the >> >>>>message was actually delivered end-to-end. >> >>>>2. MSRP hop-by-hop application-timer-based mechanism >> >>> >> >>>doesn't prevent you >> >>> >> >>>>from getting negative acknowledge in a case when the message was >> >>>>actually delivered to the destination. In other words, it >> >>> >> >>>doesn't solve >> >>> >> >>>>a duplication problem. >> >>>> >> >>>>I would like to add the requirement that the "end-to-end" >> >>> >> >>>DSN receipt >> >>> >> >>>>needs to be requested per message (not negotiated for the >> >>> >> >>>whole session >> >>> >> >>>>for all messages). It will allow for writing different IM >> behaviors >> >>>>using the same mechanism. Such as: >> >>>> >> >>>>1. Loose IM session: all the user messages are sent without >> >>> >> >>>receipt, but >> >>> >> >>>>the application sends a heartbeat message with requesting a >> >>> >> >>>receipt for >> >>> >> >>>>each. >> >>>>2. Typical IM session: For all user messages a receipt is >> >>> >> >>>requested but >> >>> >> >>>>the indication messages (e.g. "The user is typing") are delivered >> >>>>without any receipt. >> >>>> >> >>>>Thanks, >> >>>>Orit. >> >>>> >> >>>>-----Original Message----- >> >>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >> >>> >> >>>On Behalf Of >> >>> >> >>>>hisham.khartabil@nokia.com >> >>>>Sent: Wednesday, March 31, 2004 9:26 AM >> >>>>To: vkg@lucent.com >> >>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >> >>>>aki.niemi@nokia.com >> >>>>Subject: RE: [Simple] return receipt and delivery status >> >>> >> >>>notification >> >>> >> >>>>for MSRP >> >>>> >> >>>>This is a good summary, although point 4 can be debatable: >> >>> >> >>>How useful is >> >>> >> >>>>it to request receive notification in session mode? >> >>>> >> >>>>/Hisham >> >>>> >> >>>> >> >>>> >> >>>>>-----Original Message----- >> >>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >> >>>>>Sent: 04.March.2004 16:53 >> >>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >> >>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >> >>>>>(Nokia-M/Espoo) >> >>>>>Subject: Re: [Simple] return receipt and delivery status >> >>> >> >>>notification >> >>> >> >>>>>for MSRP >> >>>>> >> >>>>> >> >>>>> >> >>>>>hisham.khartabil@nokia.com wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>>>It is optional. If it is annoying to you, then you >> don't request a >> >>>>>>delivery notification. It is not every time and it is not >> >>> >> >>>mandatory. >> >>> >> >>>>>So, just to be pedantic, please correct me if my summary below is >> >>>>>wrong: >> >>>>> >> >>>>> 1/ We are interested in DSNs at the _user_ level, not the >> >>>>> _protocol_ level (i.e. the transactional model at the >> >>>>> protocol level is sufficient for protocol state >> >>>>> machines to figure out if an IM was delivered to the >> >>>>> next hop successfully or not). >> >>>>> 2/ We should design protocol provisions such that a positive >> >>>>> acknowledgement DSN model is supported (let me know >> >>>>> the current state of the IM: queued, delivered, read, >> >>>>> being responded to, ...). >> >>>>> 3/ We should design protocol provisions such that a negative >> >>>>> acknowledgement DSN model is supported (send it and >> >>>>> forget it unless something drastic happens, then >> >>>>> let me know). >> >>>>> 4/ Both 2 and 3 should apply to page mode and session >> >>>>> mode IMs. >> >>>>> 5/ Both 2 and 3 should be configurable by the sending >> >>>>> user. >> >>>>> >> >>>>>Is this accurate? >> >>>>> >> >>>>>Thanks, >> >>>>> >> >>>>>- vijay >> >>>>>-- >> >>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >> >>>>>Wireless Networks Group/Internet Software and Services Lucent >> >>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >> >>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >> >>>>> >> >>>> >> >>>> >> >>>>_______________________________________________ >> >>>>Simple mailing list >> >>>>Simple@ietf.org >> >>>>https://www1.ietf.org/mailman/listinfo/simple >> >>>> >> >>>>_______________________________________________ >> >>>>Simple mailing list >> >>>>Simple@ietf.org >> >>>>https://www1.ietf.org/mailman/listinfo/simple >> >>> >> >>> >> > >> > >> >_______________________________________________ >> >Simple mailing list >> >Simple@ietf.org >> >https://www1.ietf.org/mailman/listinfo/simple >> >> >> This message has been scanned for viruses by MailControl - >www.mailcontrol.com > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 07:28:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23839 for ; Mon, 5 Apr 2004 07:28:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASHG-0001Fo-14 for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 07:28:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35BSU7o004821 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 07:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASHF-0001Fg-R1 for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 07:28:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23833 for ; Mon, 5 Apr 2004 07:28:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASHF-0004OZ-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 07:28:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASGN-0004Ia-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 07:27:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BASFx-0004C5-00; Mon, 05 Apr 2004 07:27:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASFp-0000zp-Cz; Mon, 05 Apr 2004 07:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASFR-0000zS-0F for simple@optimus.ietf.org; Mon, 05 Apr 2004 07:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23775 for ; Mon, 5 Apr 2004 07:26:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASFQ-0004Bp-00 for simple@ietf.org; Mon, 05 Apr 2004 07:26:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASET-00044c-00 for simple@ietf.org; Mon, 05 Apr 2004 07:25:39 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly05b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BASE3-0003xm-00 for simple@ietf.org; Mon, 05 Apr 2004 07:25:11 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05b.srv.mailcontrol.com (MailControl) with SMTP id i35BOW3d010398; Mon, 5 Apr 2004 12:24:32 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Mon, 5 Apr 2004 12:24:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <45730E094814E44488F789C1CDED27AE0219B24E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQXi2UOVL+7l0diSEOwSwwg6zr+0gAPou5wADcEguAAlmevYA== From: "Chris Boulton" To: "Eric Burger" , "Ben Campbell" , Cc: X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 12:24:31 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Eric Burger [mailto:eburger@snowshore.com] >Sent: 02 April 2004 18:48 >To: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com >Cc: simple@ietf.org >Subject: RE: [Simple] return receipt and delivery status notification for >MSRP > >nononononononono. > >We are confusing two, different concepts here. A DSN lets the sender know >that a relay attempt failed. IMHO, a positive DSN has not practical value >(other than generating information that "might be useful", but of no use). >["Useful" information is how long it takes a message to traverse the >relays. What user cares?] [Chris Boulton] You care if you are sending an important message using a hop-by-hop protocol ;-) Receiving a positive DSN from the final destination of the request ensures delivery - Not receiving a negative DNS does not provide me with guarantee of delivery. Chris. > >A MDN lets the sender know that the recipient received the message. > >If you are a *user*, and you want to *know* if someone received a message, >you are going to request a MDN. > > >Let's look at two cases from the example again: > >A --> R1 --> R2 --> B > >First case: >A sends to R1 >R1 tries to send to R2, but nobody is home. >R1 sends Failure DSN to A >A knows message was not delivered. Why? Because A receives the DSN. > > >Second case: >A sends to R1 >R1 sends to R2 (successfully - no DSN) >R2 disappears (no DSN) >A *knows* B did not get the message. >How does A know this? Because A requested a MDN, and it never got it. > >One might say that A cannot tell the difference between a delivery failure >and the user ignoring the message. One might say that one would be correct >in that assertion, and that is by design. > > > >> -----Original Message----- >> From: Chris Boulton [mailto:cboulton@ubiquity.com] >> Sent: Thursday, April 01, 2004 4:24 AM >> To: Ben Campbell; hisham.khartabil@nokia.com >> Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com >> Subject: RE: [Simple] return receipt and delivery status notification >> for MSRP >> >> >> I agree with Ben. If an entity requests delivery confirmation, it >> cannot rely on the absence of a failure DSN to convey that the message >> was delivered successfully. So I feel that there is scope for both >> failure/success DSN's and a requirement for appropriate text >> describing >> procedures for the scenario where a positive DSN is requested BUT none >> received. >> >> Out of interest - what are the current thoughts on exactly >> how a client >> will request a DSN conformation? >> >> >> Chris. >> >> >> >-----Original Message----- >> >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> >Sent: 01 April 2004 02:46 >> >To: hisham.khartabil@nokia.com >> >Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; >> simple@ietf.org; >> >rohan@cisco.com; aki.niemi@nokia.com >> >Subject: Re: [Simple] return receipt and delivery status notification >> for >> >MSRP >> > >> >I don't think so. Imagine the following scenario: >> > >> >A---R1---R2---B >> > >> >A sends a critically important message to B, telling B to >> buy stock in >> >messaging companies. >> > >> >A sends to R1 successfully, and R1 sends to R2 successfully. But R2 >> >fails to send to B. So he tries to send a negative DSN to A >> via R1. But >> >it turns out the failure killed all connectivity to and from >> R2, so he >> >cannot send it. >> > >> >The moral is, DSNs can fail just like any other kind of >> message. So if >> a >> >message absolutely positively must be delivered, you need to >> be able to >> >request positive DSN. Then A can at least notice it did not receive a >> >DSN, and act accordingly. >> > >> > >> >hisham.khartabil@nokia.com wrote: >> >> My question was: How useful is it to have both notification modes >> >(positive and negative) for session IMs? Isn't notification >> on failure >> >enough? >> >> >> >> /Hisham >> >> >> >> >> >>>-----Original Message----- >> >>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> >>>Sent: 01.April.2004 01:45 >> >>>To: Orit Levin >> >>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; >> >>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >> >>>(Nokia-M/Espoo) >> >>>Subject: Re: [Simple] return receipt and delivery status >> notification >> >>>for MSRP >> >>> >> >>> >> >>> >> >>>As Orit says, DSN will be very important for MSRP. >> >>> >> >>>The current thinking is that MSRP relays will be session >> >>>stateless, and >> >>>that transactions are entirely hop-by-hop. The relay >> >>>semantics would be >> >>>similar to those of the SIMS draft, with MSRP syntax. >> >>> >> >>>As Orit hinted, this means that a transaction response is merely an >> >>>indication that the transaction succeeded, not that the message has >> >>>reached its destination. So in non peer-to-peer sessions, DSN >> >>>is critical. >> >>> >> >>>We do expect it to be optional, as it is much less useful in the >> >>>peer-to-peer case, where is just constitutes redundant messaging. >> >>> >> >>>Orit Levin wrote: >> >>> >> >>>>Hisham, >> >>>>It is VERY useful because >> >>>> >> >>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you >> whether the >> >>>>message was actually delivered end-to-end. >> >>>>2. MSRP hop-by-hop application-timer-based mechanism >> >>> >> >>>doesn't prevent you >> >>> >> >>>>from getting negative acknowledge in a case when the message was >> >>>>actually delivered to the destination. In other words, it >> >>> >> >>>doesn't solve >> >>> >> >>>>a duplication problem. >> >>>> >> >>>>I would like to add the requirement that the "end-to-end" >> >>> >> >>>DSN receipt >> >>> >> >>>>needs to be requested per message (not negotiated for the >> >>> >> >>>whole session >> >>> >> >>>>for all messages). It will allow for writing different IM >> behaviors >> >>>>using the same mechanism. Such as: >> >>>> >> >>>>1. Loose IM session: all the user messages are sent without >> >>> >> >>>receipt, but >> >>> >> >>>>the application sends a heartbeat message with requesting a >> >>> >> >>>receipt for >> >>> >> >>>>each. >> >>>>2. Typical IM session: For all user messages a receipt is >> >>> >> >>>requested but >> >>> >> >>>>the indication messages (e.g. "The user is typing") are delivered >> >>>>without any receipt. >> >>>> >> >>>>Thanks, >> >>>>Orit. >> >>>> >> >>>>-----Original Message----- >> >>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >> >>> >> >>>On Behalf Of >> >>> >> >>>>hisham.khartabil@nokia.com >> >>>>Sent: Wednesday, March 31, 2004 9:26 AM >> >>>>To: vkg@lucent.com >> >>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; >> >>>>aki.niemi@nokia.com >> >>>>Subject: RE: [Simple] return receipt and delivery status >> >>> >> >>>notification >> >>> >> >>>>for MSRP >> >>>> >> >>>>This is a good summary, although point 4 can be debatable: >> >>> >> >>>How useful is >> >>> >> >>>>it to request receive notification in session mode? >> >>>> >> >>>>/Hisham >> >>>> >> >>>> >> >>>> >> >>>>>-----Original Message----- >> >>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] >> >>>>>Sent: 04.March.2004 16:53 >> >>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >> >>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki >> >>>>>(Nokia-M/Espoo) >> >>>>>Subject: Re: [Simple] return receipt and delivery status >> >>> >> >>>notification >> >>> >> >>>>>for MSRP >> >>>>> >> >>>>> >> >>>>> >> >>>>>hisham.khartabil@nokia.com wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>>>It is optional. If it is annoying to you, then you >> don't request a >> >>>>>>delivery notification. It is not every time and it is not >> >>> >> >>>mandatory. >> >>> >> >>>>>So, just to be pedantic, please correct me if my summary below is >> >>>>>wrong: >> >>>>> >> >>>>> 1/ We are interested in DSNs at the _user_ level, not the >> >>>>> _protocol_ level (i.e. the transactional model at the >> >>>>> protocol level is sufficient for protocol state >> >>>>> machines to figure out if an IM was delivered to the >> >>>>> next hop successfully or not). >> >>>>> 2/ We should design protocol provisions such that a positive >> >>>>> acknowledgement DSN model is supported (let me know >> >>>>> the current state of the IM: queued, delivered, read, >> >>>>> being responded to, ...). >> >>>>> 3/ We should design protocol provisions such that a negative >> >>>>> acknowledgement DSN model is supported (send it and >> >>>>> forget it unless something drastic happens, then >> >>>>> let me know). >> >>>>> 4/ Both 2 and 3 should apply to page mode and session >> >>>>> mode IMs. >> >>>>> 5/ Both 2 and 3 should be configurable by the sending >> >>>>> user. >> >>>>> >> >>>>>Is this accurate? >> >>>>> >> >>>>>Thanks, >> >>>>> >> >>>>>- vijay >> >>>>>-- >> >>>>>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >> >>>>>Wireless Networks Group/Internet Software and Services Lucent >> >>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >> >>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 >> >>>>> >> >>>> >> >>>> >> >>>>_______________________________________________ >> >>>>Simple mailing list >> >>>>Simple@ietf.org >> >>>>https://www1.ietf.org/mailman/listinfo/simple >> >>>> >> >>>>_______________________________________________ >> >>>>Simple mailing list >> >>>>Simple@ietf.org >> >>>>https://www1.ietf.org/mailman/listinfo/simple >> >>> >> >>> >> > >> > >> >_______________________________________________ >> >Simple mailing list >> >Simple@ietf.org >> >https://www1.ietf.org/mailman/listinfo/simple >> >> >> This message has been scanned for viruses by MailControl - >www.mailcontrol.com > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 07:36:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24197 for ; Mon, 5 Apr 2004 07:36:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASOx-0005Nj-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 07:36:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASO5-0005HJ-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 07:35:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BASNg-0005At-00; Mon, 05 Apr 2004 07:35:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASNZ-0002aj-B5; Mon, 05 Apr 2004 07:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASN6-0002a2-BX for simple@optimus.ietf.org; Mon, 05 Apr 2004 07:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24084 for ; Mon, 5 Apr 2004 07:34:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASN5-0005AC-00 for simple@ietf.org; Mon, 05 Apr 2004 07:34:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASMJ-00053u-00 for simple@ietf.org; Mon, 05 Apr 2004 07:33:43 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BASLm-0004ui-00 for simple@ietf.org; Mon, 05 Apr 2004 07:33:10 -0400 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i35BWdfX004504 for ; Mon, 5 Apr 2004 06:32:39 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 06:29:59 -0500 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <2DNB94PK>; Mon, 5 Apr 2004 06:32:14 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C96E7@lmc37.lmc.ericsson.se> From: "George Foti (QA/EMC)" To: "'Ben Campbell'" , Jonathan Rosenberg Cc: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Apr 2004 11:29:59.0390 (UTC) FILETIME=[5425D7E0:01C41B01] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 06:31:05 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Ben Campbell > Sent: Friday, April 02, 2004 3:55 PM > To: Jonathan Rosenberg > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; George Foti > (QA/EMC); simple@ietf.org > Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft > (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) > > > Jonathan Rosenberg wrote: > [...] > > >>> > >>> I'm not aware of any text that suggests that the soft event state > >>> manipulated with PUBLISH somehow also finds its way into > the XCAP tree. > >> > >> > >> > >> George's point is that there is no text forbidding it, so > in theory, > >> it could find its way. But the question is: Do we really need to > >> explicitly forbit such thing from happening by placing a > MUST NOT text? > > > > > > I think its sufficient to say that there is simply no way, > with this > > application usage, to point to such presence documents, > making it out of > > scope. > > I am a little confused by the statement "there is no way". I > can imagine > someone co-locating their XCAP service and a PA, and reflecting the > current presence state into the XCAP tree. Any meta-data like > expirations and entity tags could just be left out from the XCAP view. > > The point is, doing this is a bad idea. Perhaps we should say > something > to that effect. > Indeed this is a very real scenario. Given that the interface between the XCAP server & the PS is proprietary, the XCAP server is a privilaged publisher, and does not require any refresh for a published state. So the presence composer will have to have local policies and rules to handle status information for same devices/applications coming from multiple sources inorder to have a predictiable behavior. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 07:36:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24225 for ; Mon, 5 Apr 2004 07:36:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASP0-0002vi-3V for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 07:36:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35BaUtW011258 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 07:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASOz-0002vV-UI for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 07:36:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24215 for ; Mon, 5 Apr 2004 07:36:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASOz-0005Nx-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 07:36:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASO6-0005HQ-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 07:35:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BASNg-0005At-00; Mon, 05 Apr 2004 07:35:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASNZ-0002aj-B5; Mon, 05 Apr 2004 07:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASN6-0002a2-BX for simple@optimus.ietf.org; Mon, 05 Apr 2004 07:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24084 for ; Mon, 5 Apr 2004 07:34:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASN5-0005AC-00 for simple@ietf.org; Mon, 05 Apr 2004 07:34:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASMJ-00053u-00 for simple@ietf.org; Mon, 05 Apr 2004 07:33:43 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BASLm-0004ui-00 for simple@ietf.org; Mon, 05 Apr 2004 07:33:10 -0400 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i35BWdfX004504 for ; Mon, 5 Apr 2004 06:32:39 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 06:29:59 -0500 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <2DNB94PK>; Mon, 5 Apr 2004 06:32:14 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C96E7@lmc37.lmc.ericsson.se> From: "George Foti (QA/EMC)" To: "'Ben Campbell'" , Jonathan Rosenberg Cc: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Apr 2004 11:29:59.0390 (UTC) FILETIME=[5425D7E0:01C41B01] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 06:31:05 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Ben Campbell > Sent: Friday, April 02, 2004 3:55 PM > To: Jonathan Rosenberg > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; George Foti > (QA/EMC); simple@ietf.org > Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft > (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) > > > Jonathan Rosenberg wrote: > [...] > > >>> > >>> I'm not aware of any text that suggests that the soft event state > >>> manipulated with PUBLISH somehow also finds its way into > the XCAP tree. > >> > >> > >> > >> George's point is that there is no text forbidding it, so > in theory, > >> it could find its way. But the question is: Do we really need to > >> explicitly forbit such thing from happening by placing a > MUST NOT text? > > > > > > I think its sufficient to say that there is simply no way, > with this > > application usage, to point to such presence documents, > making it out of > > scope. > > I am a little confused by the statement "there is no way". I > can imagine > someone co-locating their XCAP service and a PA, and reflecting the > current presence state into the XCAP tree. Any meta-data like > expirations and entity tags could just be left out from the XCAP view. > > The point is, doing this is a bad idea. Perhaps we should say > something > to that effect. > Indeed this is a very real scenario. Given that the interface between the XCAP server & the PS is proprietary, the XCAP server is a privilaged publisher, and does not require any refresh for a published state. So the presence composer will have to have local policies and rules to handle status information for same devices/applications coming from multiple sources inorder to have a predictiable behavior. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 09:42:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00478 for ; Mon, 5 Apr 2004 09:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUNK-0006hp-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 09:42:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUMS-0006Xl-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 09:42:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAULk-0006NZ-00; Mon, 05 Apr 2004 09:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAULW-0001LP-5m; Mon, 05 Apr 2004 09:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUKx-0001Hd-Gr for simple@optimus.ietf.org; Mon, 05 Apr 2004 09:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00314 for ; Mon, 5 Apr 2004 09:40:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUKv-0006JH-00 for simple@ietf.org; Mon, 05 Apr 2004 09:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUJB-00066J-00 for simple@ietf.org; Mon, 05 Apr 2004 09:38:38 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1BAUIh-0005zZ-00 for simple@ietf.org; Mon, 05 Apr 2004 09:38:07 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15830; Mon, 05 Apr 2004 09:35:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A44A@zoe.office.snowshore.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQY/A409EGn6U64SH2fUVLazghR1wCFfgiw From: "Eric Burger" To: "Ben Campbell" Cc: "Chris Boulton" , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 09:37:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ben gets it in one... As the sender of the message, there is no difference between any of the = following scenarios: 1. The message is delivered, but the user does not read it. 2. The message is delivered, but the user ignores it. 3. The message is delivered, the user reads it, but the user blocks = receipt generation. 4. The message is not delivered. All of those scenarios, including #3, fall into the "Recipient did not = get the message". The security implications of #3 are more then enough to suggest that = generating a Positive DSN on message receipt at a UAS is a bad idea. On a separate thought, is the plan to have SIMPLE replace SMTP for = messaging? I thought SIMPLE was for real-time communications, while = ESMTP, with its myriad of non-real-time certification facilities, would = be the place for things like "Registered Delivery With Return Receipt = Delivery With Signatures from Every Person That Handled the Message". > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, April 02, 2004 2:55 PM > To: Eric Burger > Cc: Chris Boulton; hisham.khartabil@nokia.com; simple@ietf.org > Subject: Re: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 >=20 >=20 >=20 >=20 > Eric Burger wrote: > > nononononononono. > >=20 > > We are confusing two, different concepts here. A DSN lets=20 > the sender know that a relay attempt failed. IMHO, a=20 > positive DSN has not practical value (other than generating=20 > information that "might be useful", but of no use). =20 > ["Useful" information is how long it takes a message to=20 > traverse the relays. What user cares?] > >=20 >=20 > I had not confused the concepts. I was arguing that it was=20 > useful to get=20 > a report saying that an IM was successfully delivered to the=20 > endpoint.=20 > That seems to me to fit the definition of DSN more than MDN.=20 > But I might=20 > be able to be convived otherwise (see below.) >=20 > > A MDN lets the sender know that the recipient received the message. > >=20 > > If you are a *user*, and you want to *know* if someone=20 > received a message, you are going to request a MDN. >=20 > If I understand correctly, you are arguing that the useful=20 > information=20 > is not whether it was delivered to the endpoint, but whether the user=20 > actually saw it. (Or consumer consumed it, to be more=20 > generic.) Is that=20 > the point? >=20 > If so, I do not have strong feelings one way or another. I am=20 > willing to=20 > accept that, for critical delivery, the thing I care about is=20 > that the=20 > message was consumed, rather than merely delivered. >=20 > But I continue to hold the opinion, that you need some form=20 > of positive=20 > acknowledgement for sufficiently important messages, whether it be=20 > positive DSN or MDN. Negative DSN by themselves are=20 > insufficent, because=20 > they can also fail. Positive acknowledgement gives us a=20 > fail-safe mode. >=20 >=20 > >=20 > >=20 > > Let's look at two cases from the example again: > >=20 > > A --> R1 --> R2 --> B > >=20 > > First case: > > A sends to R1 > > R1 tries to send to R2, but nobody is home. > > R1 sends Failure DSN to A > > A knows message was not delivered. Why? Because A=20 > receives the DSN. > >=20 > >=20 > > Second case: > > A sends to R1 > > R1 sends to R2 (successfully - no DSN) > > R2 disappears (no DSN) > > A *knows* B did not get the message. > > How does A know this? Because A requested a MDN, and it=20 > never got it. >=20 > To be pedantic, you do not know it was _not_ delivered. You just have=20 > reason to believe it might not have been delivered. Close,=20 > but not the=20 > same. B may have ignored the MDN request, or the MDN itself may have=20 > failed in transit. >=20 > >=20 > > One might say that A cannot tell the difference between a=20 > delivery failure and the user ignoring the message. One=20 > might say that one would be correct in that assertion, and=20 > that is by design. > >=20 >=20 > [...] >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 09:42:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00498 for ; Mon, 5 Apr 2004 09:42:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUNM-0006i0-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 09:42:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUMU-0006Y0-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 09:42:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAULk-0006Na-00; Mon, 05 Apr 2004 09:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAULV-0001LB-Mn; Mon, 05 Apr 2004 09:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUKw-0001GF-SM for simple@optimus.ietf.org; Mon, 05 Apr 2004 09:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00311 for ; Mon, 5 Apr 2004 09:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUKv-0006Ir-00 for simple@ietf.org; Mon, 05 Apr 2004 09:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUJ9-00066B-00 for simple@ietf.org; Mon, 05 Apr 2004 09:38:37 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1BAUIg-0005zZ-00 for simple@ietf.org; Mon, 05 Apr 2004 09:38:07 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15830; Mon, 05 Apr 2004 09:35:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A449@zoe.office.snowshore.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQZBQx25vwCvvgWQDSzN8vaMQ+2OABvndhQAAJDi4AAEU950A== From: "Eric Burger" To: , Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 09:37:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable DSN's get issued by MSRP proxies, just like DSN's get generated by MTA's = in SMTP. MDN's get issued by MSRP endpoints (a.k.a. SIP UA's), just like MDN's = get generated by MUA's in SMTP. > -----Original Message----- > From: sreeram.kanumuri@wipro.com [mailto:sreeram.kanumuri@wipro.com] > Sent: Monday, April 05, 2004 1:16 AM > To: sreeram.kanumuri@wipro.com; pkyzivat@cisco.com; Eric Burger > Cc: cboulton@ubiquity.com; bcampbell@dynamicsoft.com; > hisham.khartabil@nokia.com; simple@ietf.org > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 >=20 > Added to that, > I understand that MSRP is hop-to-hop so the DSN are not in this case > upto the end receipt!! >=20 > So,my comments: > 1.we should give response for both success and failure responses (DSN) > 2.we should define MDN and DSN if needed as per MSRP >=20 >=20 > -Sreeram >=20 > -----Original Message----- > From: Sreeram Kanumuri (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) >=20 > Sent: Monday, April 05, 2004 10:09 AM > To: 'Paul Kyzivat'; Eric Burger > Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; > simple@ietf.org > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 > Eric, >=20 > In general: >=20 > MDN are like: READ Receipt with additional parameters like :on > Successful delivery the recipient's refusal to provide MDNs=20 > Or deletion > (without display) of the message or display of the message contents >=20 > DSN are :delivery receipts that notify that the message has=20 > arrived in > the recipient's inbox on the server. >=20 > So both give the response success or failure of the message. > ---- >=20 > I think we should give response for both (SUCCESS and=20 > FAILURE) in MSRP. >=20 > Please correct my understanding. >=20 >=20 >=20 > Thanking you, >=20 > Regards, > Sreeram >=20 >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of > Paul Kyzivat > Sent: Saturday, April 03, 2004 4:08 AM > To: Eric Burger > Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; > simple@ietf.org > Subject: Re: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 > Eric, >=20 > I can't speak for the others, but I have been lumping the=20 > notion of MDN >=20 > into DSN - perphaps distinguished by options or something. Maybe it is >=20 > useful to distinguish the two types, maybe not. >=20 > Paul >=20 > Eric Burger wrote: > > nononononononono. > > >=20 > > We are confusing two, different concepts here. A DSN lets=20 > the sender > > know that a relay attempt failed. IMHO, a positive DSN has not >=20 > > practical value (other than generating information that "might be >=20 > > useful", but of no use). ["Useful" information is how long=20 > it takes a >=20 > > message to traverse the relays. What user cares?] > > >=20 > > A MDN lets the sender know that the recipient received the message. > > >=20 > > If you are a *user*, and you want to *know* if someone received a > > message, you are going to request a MDN. > > >=20 > > >=20 > > Let's look at two cases from the example again: > > >=20 > > A --> R1 --> R2 --> B > > >=20 > > First case: > > A sends to R1 > > R1 tries to send to R2, but nobody is home. > > R1 sends Failure DSN to A > > A knows message was not delivered. Why? Because A=20 > receives the DSN. > > >=20 > > >=20 > > Second case: > > A sends to R1 > > R1 sends to R2 (successfully - no DSN) > > R2 disappears (no DSN) > > A *knows* B did not get the message. > > How does A know this? Because A requested a MDN, and it=20 > never got it. > > >=20 > > One might say that A cannot tell the difference between a delivery > > failure and the user ignoring the message. One might say that one >=20 > > would be correct in that assertion, and that is by design. > > >=20 > > >=20 > > >=20 > > >=20 > >>-----Original Message----- > >>From: Chris Boulton [mailto:cboulton@ubiquity.com] > >>Sent: Thursday, April 01, 2004 4:24 AM > >>To: Ben Campbell; hisham.khartabil@nokia.com > >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > >>simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com > >>Subject: RE: [Simple] return receipt and delivery status=20 > notification >=20 > >>for MSRP > >> > >> > >>I agree with Ben. If an entity requests delivery confirmation, it > >>cannot rely on the absence of a failure DSN to convey that=20 > the message >=20 > >>was delivered successfully. So I feel that there is scope for both >=20 > >>failure/success DSN's and a requirement for appropriate text >=20 > >>describing procedures for the scenario where a positive DSN is >=20 > >>requested BUT none received. > >> > >>Out of interest - what are the current thoughts on exactly how a >=20 > >>client will request a DSN conformation? > >> > >> > >>Chris. > >> >=20 > >> > >> > >>>-----Original Message----- > >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>Sent: 01 April 2004 02:46 > >>>To: hisham.khartabil@nokia.com > >>>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > >> > >>simple@ietf.org; > >> > >>>rohan@cisco.com; aki.niemi@nokia.com > >>>Subject: Re: [Simple] return receipt and delivery status=20 > notification > >> > >>for > >> > >>>MSRP > >>> > >>>I don't think so. Imagine the following scenario: > >>> > >>>A---R1---R2---B > >>> > >>>A sends a critically important message to B, telling B to > >> > >>buy stock in > >> > >>>messaging companies. > >>> > >>>A sends to R1 successfully, and R1 sends to R2 successfully. But R2 > >>>fails to send to B. So he tries to send a negative DSN to A > >> > >>via R1. But > >> > >>>it turns out the failure killed all connectivity to and from > >> > >>R2, so he > >> > >>>cannot send it. > >>> > >>>The moral is, DSNs can fail just like any other kind of > >> > >>message. So if > >>a > >> > >>>message absolutely positively must be delivered, you need to > >> > >>be able to > >> > >>>request positive DSN. Then A can at least notice it did=20 > not receive a > >>>DSN, and act accordingly. > >>> > >>> > >>>hisham.khartabil@nokia.com wrote: > >>> > >>>>My question was: How useful is it to have both notification modes > >>> > >>>(positive and negative) for session IMs? Isn't notification > >> > >>on failure > >> > >>>enough? > >>> > >>>>/Hisham > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>>>Sent: 01.April.2004 01:45 > >>>>>To: Orit Levin > >>>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; > >>>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki > >>>>>(Nokia-M/Espoo) > >>>>>Subject: Re: [Simple] return receipt and delivery status > >>>> > >>notification > >> > >>>>>for MSRP > >>>>> > >>>>> > >>>>> > >>>>>As Orit says, DSN will be very important for MSRP. > >>>>> > >>>>>The current thinking is that MSRP relays will be session=20 > stateless, > >>>>>and that transactions are entirely hop-by-hop. The relay > >>>>>semantics would be > >>>>>similar to those of the SIMS draft, with MSRP syntax. > >>>>> > >>>>>As Orit hinted, this means that a transaction response=20 > is merely an > >>>>>indication that the transaction succeeded, not that the=20 > message has >=20 > >>>>>reached its destination. So in non peer-to-peer sessions, DSN is >=20 > >>>>>critical. > >>>>> > >>>>>We do expect it to be optional, as it is much less useful in the > >>>>>peer-to-peer case, where is just constitutes redundant messaging. > >>>>> > >>>>>Orit Levin wrote: > >>>>> > >>>>> > >>>>>>Hisham, > >>>>>>It is VERY useful because > >>>>>> > >>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you > >>>>> > >>whether the > >> > >>>>>>message was actually delivered end-to-end. > >>>>>>2. MSRP hop-by-hop application-timer-based mechanism > >>>>> > >>>>>doesn't prevent you > >>>>> > >>>>>>from getting negative acknowledge in a case when the message was > >>>>> > >>>>>>actually delivered to the destination. In other words, it > >>>>> > >>>>>doesn't solve > >>>>> > >>>>> > >>>>>>a duplication problem. > >>>>>> > >>>>>>I would like to add the requirement that the "end-to-end" > >>>>> > >>>>>DSN receipt > >>>>> > >>>>> > >>>>>>needs to be requested per message (not negotiated for the > >>>>> > >>>>>whole session > >>>>> > >>>>> > >>>>>>for all messages). It will allow for writing different IM > >>>>> > >>behaviors > >> > >>>>>>using the same mechanism. Such as: > >>>>>> > >>>>>>1. Loose IM session: all the user messages are sent without > >>>>> > >>>>>receipt, but > >>>>> > >>>>> > >>>>>>the application sends a heartbeat message with requesting a > >>>>> > >>>>>receipt for > >>>>> > >>>>> > >>>>>>each. > >>>>>>2. Typical IM session: For all user messages a receipt is > >>>>> > >>>>>requested but > >>>>> > >>>>> > >>>>>>the indication messages (e.g. "The user is typing") are=20 > delivered > >>>>>>without any receipt. > >>>>>> > >>>>>>Thanks, > >>>>>>Orit. > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] > >>>>> > >>>>>On Behalf Of > >>>>> > >>>>> > >>>>>>hisham.khartabil@nokia.com > >>>>>>Sent: Wednesday, March 31, 2004 9:26 AM > >>>>>>To: vkg@lucent.com > >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; > >>>>>>aki.niemi@nokia.com > >>>>>>Subject: RE: [Simple] return receipt and delivery status > >>>>> > >>>>>notification > >>>>> > >>>>> > >>>>>>for MSRP > >>>>>> > >>>>>>This is a good summary, although point 4 can be debatable: > >>>>> > >>>>>How useful is > >>>>> > >>>>> > >>>>>>it to request receive notification in session mode? > >>>>>> > >>>>>>/Hisham > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] > >>>>>>>Sent: 04.March.2004 16:53 > >>>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > >>>>>>>Cc: vikas@arciis.com; simple@ietf.org;=20 > rohan@cisco.com; Niemi Aki > >>>>>>>(Nokia-M/Espoo) > >>>>>>>Subject: Re: [Simple] return receipt and delivery status > >>>>>> > >>>>>notification > >>>>> > >>>>> > >>>>>>>for MSRP > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>hisham.khartabil@nokia.com wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>It is optional. If it is annoying to you, then you > >>>>>>> > >>don't request a > >> > >>>>>>>>delivery notification. It is not every time and it is not > >>>>>>> > >>>>>mandatory. > >>>>> > >>>>> > >>>>>>>So, just to be pedantic, please correct me if my=20 > summary below is > >>>>>>>wrong: > >>>>>>> > >>>>>>> 1/ We are interested in DSNs at the _user_ level, not the > >>>>>>> _protocol_ level (i.e. the transactional model at the > >>>>>>> protocol level is sufficient for protocol state > >>>>>>> machines to figure out if an IM was delivered to the > >>>>>>> next hop successfully or not). > >>>>>>> 2/ We should design protocol provisions such that a positive > >>>>>>> acknowledgement DSN model is supported (let me know > >>>>>>> the current state of the IM: queued, delivered, read, > >>>>>>> being responded to, ...). > >>>>>>> 3/ We should design protocol provisions such that a negative > >>>>>>> acknowledgement DSN model is supported (send it and > >>>>>>> forget it unless something drastic happens, then > >>>>>>> let me know). > >>>>>>> 4/ Both 2 and 3 should apply to page mode and session > >>>>>>> mode IMs. > >>>>>>> 5/ Both 2 and 3 should be configurable by the sending > >>>>>>> user. > >>>>>>> > >>>>>>>Is this accurate? > >>>>>>> > >>>>>>>Thanks, > >>>>>>> > >>>>>>>- vijay > >>>>>>>-- > >>>>>>>Vijay K. Gurbani =20 > vkg@{lucent.com,research.bell-labs.com,acm.org} > >>>>>>>Wireless Networks Group/Internet Software and Services Lucent > >>>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > >>>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 > >>>>>>> > >>>>>> > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Simple mailing list > >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Simple mailing list > >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>>> > >>> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >> > >> > >>This message has been scanned for viruses by MailControl - >=20 > > >=20 > > www.mailcontrol.com > > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > Confidentiality Notice >=20 >=20 > The information contained in this electronic message and any=20 > attachments to this message are intended > for the exclusive use of the addressee(s) and may contain=20 > confidential or privileged information. If > you are not the intended recipient, please notify the sender=20 > at Wipro or Mailadmin@wipro.com immediately > and destroy all copies of this message and any attachments. >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 09:43:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00645 for ; Mon, 5 Apr 2004 09:43:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUNN-0001zt-IZ for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 09:42:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35DgvGY007675 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 09:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUNN-0001zi-CU for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 09:42:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00491 for ; Mon, 5 Apr 2004 09:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUNL-0006hu-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 09:42:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUMT-0006Xs-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 09:42:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAULk-0006NZ-00; Mon, 05 Apr 2004 09:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAULW-0001LP-5m; Mon, 05 Apr 2004 09:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUKx-0001Hd-Gr for simple@optimus.ietf.org; Mon, 05 Apr 2004 09:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00314 for ; Mon, 5 Apr 2004 09:40:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUKv-0006JH-00 for simple@ietf.org; Mon, 05 Apr 2004 09:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUJB-00066J-00 for simple@ietf.org; Mon, 05 Apr 2004 09:38:38 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1BAUIh-0005zZ-00 for simple@ietf.org; Mon, 05 Apr 2004 09:38:07 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15830; Mon, 05 Apr 2004 09:35:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A44A@zoe.office.snowshore.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQY/A409EGn6U64SH2fUVLazghR1wCFfgiw From: "Eric Burger" To: "Ben Campbell" Cc: "Chris Boulton" , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 09:37:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ben gets it in one... As the sender of the message, there is no difference between any of the = following scenarios: 1. The message is delivered, but the user does not read it. 2. The message is delivered, but the user ignores it. 3. The message is delivered, the user reads it, but the user blocks = receipt generation. 4. The message is not delivered. All of those scenarios, including #3, fall into the "Recipient did not = get the message". The security implications of #3 are more then enough to suggest that = generating a Positive DSN on message receipt at a UAS is a bad idea. On a separate thought, is the plan to have SIMPLE replace SMTP for = messaging? I thought SIMPLE was for real-time communications, while = ESMTP, with its myriad of non-real-time certification facilities, would = be the place for things like "Registered Delivery With Return Receipt = Delivery With Signatures from Every Person That Handled the Message". > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, April 02, 2004 2:55 PM > To: Eric Burger > Cc: Chris Boulton; hisham.khartabil@nokia.com; simple@ietf.org > Subject: Re: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 >=20 >=20 >=20 >=20 > Eric Burger wrote: > > nononononononono. > >=20 > > We are confusing two, different concepts here. A DSN lets=20 > the sender know that a relay attempt failed. IMHO, a=20 > positive DSN has not practical value (other than generating=20 > information that "might be useful", but of no use). =20 > ["Useful" information is how long it takes a message to=20 > traverse the relays. What user cares?] > >=20 >=20 > I had not confused the concepts. I was arguing that it was=20 > useful to get=20 > a report saying that an IM was successfully delivered to the=20 > endpoint.=20 > That seems to me to fit the definition of DSN more than MDN.=20 > But I might=20 > be able to be convived otherwise (see below.) >=20 > > A MDN lets the sender know that the recipient received the message. > >=20 > > If you are a *user*, and you want to *know* if someone=20 > received a message, you are going to request a MDN. >=20 > If I understand correctly, you are arguing that the useful=20 > information=20 > is not whether it was delivered to the endpoint, but whether the user=20 > actually saw it. (Or consumer consumed it, to be more=20 > generic.) Is that=20 > the point? >=20 > If so, I do not have strong feelings one way or another. I am=20 > willing to=20 > accept that, for critical delivery, the thing I care about is=20 > that the=20 > message was consumed, rather than merely delivered. >=20 > But I continue to hold the opinion, that you need some form=20 > of positive=20 > acknowledgement for sufficiently important messages, whether it be=20 > positive DSN or MDN. Negative DSN by themselves are=20 > insufficent, because=20 > they can also fail. Positive acknowledgement gives us a=20 > fail-safe mode. >=20 >=20 > >=20 > >=20 > > Let's look at two cases from the example again: > >=20 > > A --> R1 --> R2 --> B > >=20 > > First case: > > A sends to R1 > > R1 tries to send to R2, but nobody is home. > > R1 sends Failure DSN to A > > A knows message was not delivered. Why? Because A=20 > receives the DSN. > >=20 > >=20 > > Second case: > > A sends to R1 > > R1 sends to R2 (successfully - no DSN) > > R2 disappears (no DSN) > > A *knows* B did not get the message. > > How does A know this? Because A requested a MDN, and it=20 > never got it. >=20 > To be pedantic, you do not know it was _not_ delivered. You just have=20 > reason to believe it might not have been delivered. Close,=20 > but not the=20 > same. B may have ignored the MDN request, or the MDN itself may have=20 > failed in transit. >=20 > >=20 > > One might say that A cannot tell the difference between a=20 > delivery failure and the user ignoring the message. One=20 > might say that one would be correct in that assertion, and=20 > that is by design. > >=20 >=20 > [...] >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 09:43:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00668 for ; Mon, 5 Apr 2004 09:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUNP-00020B-AO for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 09:42:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35DgxRP007691 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 09:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUNP-0001zy-16 for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 09:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00508 for ; Mon, 5 Apr 2004 09:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUNN-0006i5-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 09:42:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUMW-0006Y7-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 09:42:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAULk-0006Na-00; Mon, 05 Apr 2004 09:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAULV-0001LB-Mn; Mon, 05 Apr 2004 09:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUKw-0001GF-SM for simple@optimus.ietf.org; Mon, 05 Apr 2004 09:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00311 for ; Mon, 5 Apr 2004 09:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUKv-0006Ir-00 for simple@ietf.org; Mon, 05 Apr 2004 09:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUJ9-00066B-00 for simple@ietf.org; Mon, 05 Apr 2004 09:38:37 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1BAUIg-0005zZ-00 for simple@ietf.org; Mon, 05 Apr 2004 09:38:07 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15830; Mon, 05 Apr 2004 09:35:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A449@zoe.office.snowshore.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQZBQx25vwCvvgWQDSzN8vaMQ+2OABvndhQAAJDi4AAEU950A== From: "Eric Burger" To: , Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 09:37:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable DSN's get issued by MSRP proxies, just like DSN's get generated by MTA's = in SMTP. MDN's get issued by MSRP endpoints (a.k.a. SIP UA's), just like MDN's = get generated by MUA's in SMTP. > -----Original Message----- > From: sreeram.kanumuri@wipro.com [mailto:sreeram.kanumuri@wipro.com] > Sent: Monday, April 05, 2004 1:16 AM > To: sreeram.kanumuri@wipro.com; pkyzivat@cisco.com; Eric Burger > Cc: cboulton@ubiquity.com; bcampbell@dynamicsoft.com; > hisham.khartabil@nokia.com; simple@ietf.org > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 >=20 > Added to that, > I understand that MSRP is hop-to-hop so the DSN are not in this case > upto the end receipt!! >=20 > So,my comments: > 1.we should give response for both success and failure responses (DSN) > 2.we should define MDN and DSN if needed as per MSRP >=20 >=20 > -Sreeram >=20 > -----Original Message----- > From: Sreeram Kanumuri (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) >=20 > Sent: Monday, April 05, 2004 10:09 AM > To: 'Paul Kyzivat'; Eric Burger > Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; > simple@ietf.org > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 > Eric, >=20 > In general: >=20 > MDN are like: READ Receipt with additional parameters like :on > Successful delivery the recipient's refusal to provide MDNs=20 > Or deletion > (without display) of the message or display of the message contents >=20 > DSN are :delivery receipts that notify that the message has=20 > arrived in > the recipient's inbox on the server. >=20 > So both give the response success or failure of the message. > ---- >=20 > I think we should give response for both (SUCCESS and=20 > FAILURE) in MSRP. >=20 > Please correct my understanding. >=20 >=20 >=20 > Thanking you, >=20 > Regards, > Sreeram >=20 >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of > Paul Kyzivat > Sent: Saturday, April 03, 2004 4:08 AM > To: Eric Burger > Cc: Chris Boulton; Ben Campbell; hisham.khartabil@nokia.com; > simple@ietf.org > Subject: Re: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 > Eric, >=20 > I can't speak for the others, but I have been lumping the=20 > notion of MDN >=20 > into DSN - perphaps distinguished by options or something. Maybe it is >=20 > useful to distinguish the two types, maybe not. >=20 > Paul >=20 > Eric Burger wrote: > > nononononononono. > > >=20 > > We are confusing two, different concepts here. A DSN lets=20 > the sender > > know that a relay attempt failed. IMHO, a positive DSN has not >=20 > > practical value (other than generating information that "might be >=20 > > useful", but of no use). ["Useful" information is how long=20 > it takes a >=20 > > message to traverse the relays. What user cares?] > > >=20 > > A MDN lets the sender know that the recipient received the message. > > >=20 > > If you are a *user*, and you want to *know* if someone received a > > message, you are going to request a MDN. > > >=20 > > >=20 > > Let's look at two cases from the example again: > > >=20 > > A --> R1 --> R2 --> B > > >=20 > > First case: > > A sends to R1 > > R1 tries to send to R2, but nobody is home. > > R1 sends Failure DSN to A > > A knows message was not delivered. Why? Because A=20 > receives the DSN. > > >=20 > > >=20 > > Second case: > > A sends to R1 > > R1 sends to R2 (successfully - no DSN) > > R2 disappears (no DSN) > > A *knows* B did not get the message. > > How does A know this? Because A requested a MDN, and it=20 > never got it. > > >=20 > > One might say that A cannot tell the difference between a delivery > > failure and the user ignoring the message. One might say that one >=20 > > would be correct in that assertion, and that is by design. > > >=20 > > >=20 > > >=20 > > >=20 > >>-----Original Message----- > >>From: Chris Boulton [mailto:cboulton@ubiquity.com] > >>Sent: Thursday, April 01, 2004 4:24 AM > >>To: Ben Campbell; hisham.khartabil@nokia.com > >>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > >>simple@ietf.org; rohan@cisco.com; aki.niemi@nokia.com > >>Subject: RE: [Simple] return receipt and delivery status=20 > notification >=20 > >>for MSRP > >> > >> > >>I agree with Ben. If an entity requests delivery confirmation, it > >>cannot rely on the absence of a failure DSN to convey that=20 > the message >=20 > >>was delivered successfully. So I feel that there is scope for both >=20 > >>failure/success DSN's and a requirement for appropriate text >=20 > >>describing procedures for the scenario where a positive DSN is >=20 > >>requested BUT none received. > >> > >>Out of interest - what are the current thoughts on exactly how a >=20 > >>client will request a DSN conformation? > >> > >> > >>Chris. > >> >=20 > >> > >> > >>>-----Original Message----- > >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>Sent: 01 April 2004 02:46 > >>>To: hisham.khartabil@nokia.com > >>>Cc: oritl@microsoft.com; vkg@lucent.com; vikas@arciis.com; > >> > >>simple@ietf.org; > >> > >>>rohan@cisco.com; aki.niemi@nokia.com > >>>Subject: Re: [Simple] return receipt and delivery status=20 > notification > >> > >>for > >> > >>>MSRP > >>> > >>>I don't think so. Imagine the following scenario: > >>> > >>>A---R1---R2---B > >>> > >>>A sends a critically important message to B, telling B to > >> > >>buy stock in > >> > >>>messaging companies. > >>> > >>>A sends to R1 successfully, and R1 sends to R2 successfully. But R2 > >>>fails to send to B. So he tries to send a negative DSN to A > >> > >>via R1. But > >> > >>>it turns out the failure killed all connectivity to and from > >> > >>R2, so he > >> > >>>cannot send it. > >>> > >>>The moral is, DSNs can fail just like any other kind of > >> > >>message. So if > >>a > >> > >>>message absolutely positively must be delivered, you need to > >> > >>be able to > >> > >>>request positive DSN. Then A can at least notice it did=20 > not receive a > >>>DSN, and act accordingly. > >>> > >>> > >>>hisham.khartabil@nokia.com wrote: > >>> > >>>>My question was: How useful is it to have both notification modes > >>> > >>>(positive and negative) for session IMs? Isn't notification > >> > >>on failure > >> > >>>enough? > >>> > >>>>/Hisham > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>>>Sent: 01.April.2004 01:45 > >>>>>To: Orit Levin > >>>>>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); vkg@lucent.com; > >>>>>vikas@arciis.com; simple@ietf.org; rohan@cisco.com; Niemi Aki > >>>>>(Nokia-M/Espoo) > >>>>>Subject: Re: [Simple] return receipt and delivery status > >>>> > >>notification > >> > >>>>>for MSRP > >>>>> > >>>>> > >>>>> > >>>>>As Orit says, DSN will be very important for MSRP. > >>>>> > >>>>>The current thinking is that MSRP relays will be session=20 > stateless, > >>>>>and that transactions are entirely hop-by-hop. The relay > >>>>>semantics would be > >>>>>similar to those of the SIMS draft, with MSRP syntax. > >>>>> > >>>>>As Orit hinted, this means that a transaction response=20 > is merely an > >>>>>indication that the transaction succeeded, not that the=20 > message has >=20 > >>>>>reached its destination. So in non peer-to-peer sessions, DSN is >=20 > >>>>>critical. > >>>>> > >>>>>We do expect it to be optional, as it is much less useful in the > >>>>>peer-to-peer case, where is just constitutes redundant messaging. > >>>>> > >>>>>Orit Levin wrote: > >>>>> > >>>>> > >>>>>>Hisham, > >>>>>>It is VERY useful because > >>>>>> > >>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you > >>>>> > >>whether the > >> > >>>>>>message was actually delivered end-to-end. > >>>>>>2. MSRP hop-by-hop application-timer-based mechanism > >>>>> > >>>>>doesn't prevent you > >>>>> > >>>>>>from getting negative acknowledge in a case when the message was > >>>>> > >>>>>>actually delivered to the destination. In other words, it > >>>>> > >>>>>doesn't solve > >>>>> > >>>>> > >>>>>>a duplication problem. > >>>>>> > >>>>>>I would like to add the requirement that the "end-to-end" > >>>>> > >>>>>DSN receipt > >>>>> > >>>>> > >>>>>>needs to be requested per message (not negotiated for the > >>>>> > >>>>>whole session > >>>>> > >>>>> > >>>>>>for all messages). It will allow for writing different IM > >>>>> > >>behaviors > >> > >>>>>>using the same mechanism. Such as: > >>>>>> > >>>>>>1. Loose IM session: all the user messages are sent without > >>>>> > >>>>>receipt, but > >>>>> > >>>>> > >>>>>>the application sends a heartbeat message with requesting a > >>>>> > >>>>>receipt for > >>>>> > >>>>> > >>>>>>each. > >>>>>>2. Typical IM session: For all user messages a receipt is > >>>>> > >>>>>requested but > >>>>> > >>>>> > >>>>>>the indication messages (e.g. "The user is typing") are=20 > delivered > >>>>>>without any receipt. > >>>>>> > >>>>>>Thanks, > >>>>>>Orit. > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] > >>>>> > >>>>>On Behalf Of > >>>>> > >>>>> > >>>>>>hisham.khartabil@nokia.com > >>>>>>Sent: Wednesday, March 31, 2004 9:26 AM > >>>>>>To: vkg@lucent.com > >>>>>>Cc: vikas@arciis.com; simple@ietf.org; rohan@cisco.com; > >>>>>>aki.niemi@nokia.com > >>>>>>Subject: RE: [Simple] return receipt and delivery status > >>>>> > >>>>>notification > >>>>> > >>>>> > >>>>>>for MSRP > >>>>>> > >>>>>>This is a good summary, although point 4 can be debatable: > >>>>> > >>>>>How useful is > >>>>> > >>>>> > >>>>>>it to request receive notification in session mode? > >>>>>> > >>>>>>/Hisham > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] > >>>>>>>Sent: 04.March.2004 16:53 > >>>>>>>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > >>>>>>>Cc: vikas@arciis.com; simple@ietf.org;=20 > rohan@cisco.com; Niemi Aki > >>>>>>>(Nokia-M/Espoo) > >>>>>>>Subject: Re: [Simple] return receipt and delivery status > >>>>>> > >>>>>notification > >>>>> > >>>>> > >>>>>>>for MSRP > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>hisham.khartabil@nokia.com wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>It is optional. If it is annoying to you, then you > >>>>>>> > >>don't request a > >> > >>>>>>>>delivery notification. It is not every time and it is not > >>>>>>> > >>>>>mandatory. > >>>>> > >>>>> > >>>>>>>So, just to be pedantic, please correct me if my=20 > summary below is > >>>>>>>wrong: > >>>>>>> > >>>>>>> 1/ We are interested in DSNs at the _user_ level, not the > >>>>>>> _protocol_ level (i.e. the transactional model at the > >>>>>>> protocol level is sufficient for protocol state > >>>>>>> machines to figure out if an IM was delivered to the > >>>>>>> next hop successfully or not). > >>>>>>> 2/ We should design protocol provisions such that a positive > >>>>>>> acknowledgement DSN model is supported (let me know > >>>>>>> the current state of the IM: queued, delivered, read, > >>>>>>> being responded to, ...). > >>>>>>> 3/ We should design protocol provisions such that a negative > >>>>>>> acknowledgement DSN model is supported (send it and > >>>>>>> forget it unless something drastic happens, then > >>>>>>> let me know). > >>>>>>> 4/ Both 2 and 3 should apply to page mode and session > >>>>>>> mode IMs. > >>>>>>> 5/ Both 2 and 3 should be configurable by the sending > >>>>>>> user. > >>>>>>> > >>>>>>>Is this accurate? > >>>>>>> > >>>>>>>Thanks, > >>>>>>> > >>>>>>>- vijay > >>>>>>>-- > >>>>>>>Vijay K. Gurbani =20 > vkg@{lucent.com,research.bell-labs.com,acm.org} > >>>>>>>Wireless Networks Group/Internet Software and Services Lucent > >>>>>>>Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > >>>>>>>Naperville, Illinois 60566 Voice: +1 630 224 0216 > >>>>>>> > >>>>>> > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Simple mailing list > >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Simple mailing list > >>>>>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>>> > >>> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >> > >> > >>This message has been scanned for viruses by MailControl - >=20 > > >=20 > > www.mailcontrol.com > > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > Confidentiality Notice >=20 >=20 > The information contained in this electronic message and any=20 > attachments to this message are intended > for the exclusive use of the addressee(s) and may contain=20 > confidential or privileged information. If > you are not the intended recipient, please notify the sender=20 > at Wipro or Mailadmin@wipro.com immediately > and destroy all copies of this message and any attachments. >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 09:53:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01155 for ; Mon, 5 Apr 2004 09:53:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUXl-0000FZ-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 09:53:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUWq-00008K-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 09:52:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAUWK-00000S-00; Mon, 05 Apr 2004 09:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUW9-0003Qa-Qm; Mon, 05 Apr 2004 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUVu-0003PQ-5M for simple@optimus.ietf.org; Mon, 05 Apr 2004 09:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01076 for ; Mon, 5 Apr 2004 09:51:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUVr-0007nN-00 for simple@ietf.org; Mon, 05 Apr 2004 09:51:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUUv-0007fn-00 for simple@ietf.org; Mon, 05 Apr 2004 09:50:46 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BAUUH-0007Vw-00; Mon, 05 Apr 2004 09:50:05 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i35DnLNr005077; Mon, 5 Apr 2004 09:49:21 -0400 (EDT) Message-ID: <407163C0.40700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: Tschofenig Hannes , Ben Campbell , Ted Hardie , Henning Schulzrinne , Markus.Isomaki@nokia.com, simple@ietf.org, "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First d raft of text on semantic-based authorization policies [exceptions] References: <4.3.2.7.2.20040331111010.03d98d68@localhost> In-Reply-To: <4.3.2.7.2.20040331111010.03d98d68@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Apr 2004 09:48:48 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sorry for confusing folks. I was being loose with the XML in my example. The proposal I had made on the list was to do this: > So, it seems like there are only a few combinations that make sense. Perhaps it would be a better idea to combine all three into a single operation - and have the following values: > > block : deny the subscription > confirm : subscription is pending > polite-block: accept it, but provide no presence > allow: accept it and provide presence THus, the element does have a value which is a "deny". However, I dont see anything wrong with that. This value represents the default action, and the action with lowest integral value. Its the same as would happen as if there were no element, which is to NOT reveal any privacy information. If another rule had a of confirm, the combination rules would result in a value of "confirm", which is exactly what you want. HTH, Jonathan R. James M. Polk wrote: > Jonathan > > I'm curious about this as well - as it appears that you have a > non-permissions > statement in the XML with > > > > > > I could be wrong, but want confirmation I'm wrong here. > > > At 01:48 PM 3/31/2004 +0200, Tschofenig Hannes wrote: > >> -- cc to geopriv ml >> >> hi jonathan, >> >> you propose an action with is a deny. doesn't this conflict with the >> goals >> expressed in the common policy draft ( >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.txt) >> >> where Section 4 (Goals and Assumptions) specifies 'Permit only' >> actions are >> allowed. do you suggest that we modifying our goals/assumptions or do >> i miss >> something? >> >> ciao >> hannes >> >> >> > -----Original Message----- >> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> > Sent: Thursday, March 25, 2004 4:43 PM >> > To: Ben Campbell >> > Cc: Ted Hardie; Henning Schulzrinne; Markus.Isomaki@nokia.com; >> > simple@ietf.org >> > Subject: Re: supporitng blacklists, was: Re: [Simple] >> > Comments on: First >> > draft of text on semantic-based authorization policies [exceptions] >> > >> > >> > You can still achieve the functionality you want, Ben, >> > without requiring >> > the new rule Henning had proposed: >> > >> > >> > >> > >> > example.com >> > joe >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > joe >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Of course, you need to be careful that the user joe is not a >> > member of >> > any other rule which grants a permission greater than >> > "deny-subscription", but thats a fundamental property of the model in >> > general. >> > >> > -Jonathan R. >> > >> > Ben Campbell wrote: >> > >> > > Ted Hardie wrote: >> > > >> > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote: >> > >> >> > >>> "Everybody in the world, in any domain, gets to *ask* to >> > subscribe to >> > >>> my presence, but Alice, Bob and Carol have already been >> > told to take >> > >>> a hike and thus shouldn't even be able to ask." >> > >>> >> > >>> Is this the type of rule we want to be to support? >> > >> >> > >> >> > >> >> > >> It's seems to me to be a lot easier just to keep telling >> > them to take >> > >> a hike >> > >> whenever they ask; is there a reason to optimize for this >> > case that I'm >> > >> missing? >> > > >> > > >> > > The act of asking can become a kind of harrassment. Some >> > time ago, I had >> > > a yahoo messenger user that continuously asked permission >> > to watch my >> > > presence, but refused to identify themselves to me. This >> > continued after >> > > I asked them to desist. Fortunately, yahoo messenger >> > allowed me to block >> > > that ID, so I no longer get bothered by them. >> > > >> > >> > -- >> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> > Chief Technology Officer Parsippany, NJ 07054-2711 >> > dynamicsoft >> > jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> > http://www.jdrosen.net PHONE: (973) 952-5000 >> > http://www.dynamicsoft.com >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www1.ietf.org/mailman/listinfo/simple >> > >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 09:54:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01209 for ; Mon, 5 Apr 2004 09:54:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUXo-0003iX-EZ for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 09:53:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35DriIR014290 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 09:53:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUXo-0003iP-8f for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 09:53:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01164 for ; Mon, 5 Apr 2004 09:53:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUXm-0000Fg-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 09:53:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUWr-00008R-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 09:52:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAUWK-00000S-00; Mon, 05 Apr 2004 09:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUW9-0003Qa-Qm; Mon, 05 Apr 2004 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUVu-0003PQ-5M for simple@optimus.ietf.org; Mon, 05 Apr 2004 09:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01076 for ; Mon, 5 Apr 2004 09:51:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUVr-0007nN-00 for simple@ietf.org; Mon, 05 Apr 2004 09:51:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUUv-0007fn-00 for simple@ietf.org; Mon, 05 Apr 2004 09:50:46 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BAUUH-0007Vw-00; Mon, 05 Apr 2004 09:50:05 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i35DnLNr005077; Mon, 5 Apr 2004 09:49:21 -0400 (EDT) Message-ID: <407163C0.40700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" CC: Tschofenig Hannes , Ben Campbell , Ted Hardie , Henning Schulzrinne , Markus.Isomaki@nokia.com, simple@ietf.org, "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First d raft of text on semantic-based authorization policies [exceptions] References: <4.3.2.7.2.20040331111010.03d98d68@localhost> In-Reply-To: <4.3.2.7.2.20040331111010.03d98d68@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Apr 2004 09:48:48 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for confusing folks. I was being loose with the XML in my example. The proposal I had made on the list was to do this: > So, it seems like there are only a few combinations that make sense. Perhaps it would be a better idea to combine all three into a single operation - and have the following values: > > block : deny the subscription > confirm : subscription is pending > polite-block: accept it, but provide no presence > allow: accept it and provide presence THus, the element does have a value which is a "deny". However, I dont see anything wrong with that. This value represents the default action, and the action with lowest integral value. Its the same as would happen as if there were no element, which is to NOT reveal any privacy information. If another rule had a of confirm, the combination rules would result in a value of "confirm", which is exactly what you want. HTH, Jonathan R. James M. Polk wrote: > Jonathan > > I'm curious about this as well - as it appears that you have a > non-permissions > statement in the XML with > > > > > > I could be wrong, but want confirmation I'm wrong here. > > > At 01:48 PM 3/31/2004 +0200, Tschofenig Hannes wrote: > >> -- cc to geopriv ml >> >> hi jonathan, >> >> you propose an action with is a deny. doesn't this conflict with the >> goals >> expressed in the common policy draft ( >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.txt) >> >> where Section 4 (Goals and Assumptions) specifies 'Permit only' >> actions are >> allowed. do you suggest that we modifying our goals/assumptions or do >> i miss >> something? >> >> ciao >> hannes >> >> >> > -----Original Message----- >> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> > Sent: Thursday, March 25, 2004 4:43 PM >> > To: Ben Campbell >> > Cc: Ted Hardie; Henning Schulzrinne; Markus.Isomaki@nokia.com; >> > simple@ietf.org >> > Subject: Re: supporitng blacklists, was: Re: [Simple] >> > Comments on: First >> > draft of text on semantic-based authorization policies [exceptions] >> > >> > >> > You can still achieve the functionality you want, Ben, >> > without requiring >> > the new rule Henning had proposed: >> > >> > >> > >> > >> > example.com >> > joe >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > joe >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Of course, you need to be careful that the user joe is not a >> > member of >> > any other rule which grants a permission greater than >> > "deny-subscription", but thats a fundamental property of the model in >> > general. >> > >> > -Jonathan R. >> > >> > Ben Campbell wrote: >> > >> > > Ted Hardie wrote: >> > > >> > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote: >> > >> >> > >>> "Everybody in the world, in any domain, gets to *ask* to >> > subscribe to >> > >>> my presence, but Alice, Bob and Carol have already been >> > told to take >> > >>> a hike and thus shouldn't even be able to ask." >> > >>> >> > >>> Is this the type of rule we want to be to support? >> > >> >> > >> >> > >> >> > >> It's seems to me to be a lot easier just to keep telling >> > them to take >> > >> a hike >> > >> whenever they ask; is there a reason to optimize for this >> > case that I'm >> > >> missing? >> > > >> > > >> > > The act of asking can become a kind of harrassment. Some >> > time ago, I had >> > > a yahoo messenger user that continuously asked permission >> > to watch my >> > > presence, but refused to identify themselves to me. This >> > continued after >> > > I asked them to desist. Fortunately, yahoo messenger >> > allowed me to block >> > > that ID, so I no longer get bothered by them. >> > > >> > >> > -- >> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> > Chief Technology Officer Parsippany, NJ 07054-2711 >> > dynamicsoft >> > jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> > http://www.jdrosen.net PHONE: (973) 952-5000 >> > http://www.dynamicsoft.com >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www1.ietf.org/mailman/listinfo/simple >> > >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 5 12:05:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10103 for ; Mon, 5 Apr 2004 12:05:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWbc-00042H-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 12:05:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWOw-00026q-00 for simple-archive@ietf.org; Mon, 05 Apr 2004 11:52:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAWDs-00004T-00; Mon, 05 Apr 2004 11:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAW2h-0006ds-C4; Mon, 05 Apr 2004 11:29:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAVZZ-00086v-3p for simple@optimus.ietf.org; Mon, 05 Apr 2004 10:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05774 for ; Mon, 5 Apr 2004 10:59:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAVZP-0001Wn-00 for simple@ietf.org; Mon, 05 Apr 2004 10:59:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAVYQ-0001Nd-00 for simple@ietf.org; Mon, 05 Apr 2004 10:58:27 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BAVXZ-00019R-00 for simple@ietf.org; Mon, 05 Apr 2004 10:57:33 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i35EvCIw060490; Mon, 5 Apr 2004 09:57:21 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407173BE.4040307@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: Chris Boulton , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <4A3384433CE2AB46A63468CB207E209DB1A44A@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A44A@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Apr 2004 09:57:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eric Burger wrote: > Ben gets it in one... > > As the sender of the message, there is no difference between any of the following scenarios: > > 1. The message is delivered, but the user does not read it. > 2. The message is delivered, but the user ignores it. > 3. The message is delivered, the user reads it, but the user blocks receipt generation. > 4. The message is not delivered. > > All of those scenarios, including #3, fall into the "Recipient did not get the message". > > The security implications of #3 are more then enough to suggest that generating a Positive DSN on message receipt at a UAS is a bad idea. > > On a separate thought, is the plan to have SIMPLE replace SMTP for messaging? I thought SIMPLE was for real-time communications, while ESMTP, with its myriad of non-real-time certification facilities, would be the place for things like "Registered Delivery With Return Receipt Delivery With Signatures from Every Person That Handled the Message". > I certainly hope we are not planning to replace mail. But does this absolve us from needing positive acknowledgement of delivery? I am not sure on this point. > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, April 02, 2004 2:55 PM >>To: Eric Burger >>Cc: Chris Boulton; hisham.khartabil@nokia.com; simple@ietf.org >>Subject: Re: [Simple] return receipt and delivery status notification >>for MSRP >> >> >> >> >> >> >>Eric Burger wrote: >> >>>nononononononono. >>> >>>We are confusing two, different concepts here. A DSN lets >> >>the sender know that a relay attempt failed. IMHO, a >>positive DSN has not practical value (other than generating >>information that "might be useful", but of no use). >>["Useful" information is how long it takes a message to >>traverse the relays. What user cares?] >> >>I had not confused the concepts. I was arguing that it was >>useful to get >>a report saying that an IM was successfully delivered to the >>endpoint. >>That seems to me to fit the definition of DSN more than MDN. >>But I might >>be able to be convived otherwise (see below.) >> >> >>>A MDN lets the sender know that the recipient received the message. >>> >>>If you are a *user*, and you want to *know* if someone >> >>received a message, you are going to request a MDN. >> >>If I understand correctly, you are arguing that the useful >>information >>is not whether it was delivered to the endpoint, but whether the user >>actually saw it. (Or consumer consumed it, to be more >>generic.) Is that >>the point? >> >>If so, I do not have strong feelings one way or another. I am >>willing to >>accept that, for critical delivery, the thing I care about is >>that the >>message was consumed, rather than merely delivered. >> >>But I continue to hold the opinion, that you need some form >>of positive >>acknowledgement for sufficiently important messages, whether it be >>positive DSN or MDN. Negative DSN by themselves are >>insufficent, because >>they can also fail. Positive acknowledgement gives us a >>fail-safe mode. >> >> >> >>> >>>Let's look at two cases from the example again: >>> >>>A --> R1 --> R2 --> B >>> >>>First case: >>>A sends to R1 >>>R1 tries to send to R2, but nobody is home. >>>R1 sends Failure DSN to A >>>A knows message was not delivered. Why? Because A >> >>receives the DSN. >> >>> >>>Second case: >>>A sends to R1 >>>R1 sends to R2 (successfully - no DSN) >>>R2 disappears (no DSN) >>>A *knows* B did not get the message. >>>How does A know this? Because A requested a MDN, and it >> >>never got it. >> >>To be pedantic, you do not know it was _not_ delivered. You just have >>reason to believe it might not have been delivered. Close, >>but not the >>same. B may have ignored the MDN request, or the MDN itself may have >>failed in transit. >> >> >>>One might say that A cannot tell the difference between a >> >>delivery failure and the user ignoring the message. One >>might say that one would be correct in that assertion, and >>that is by design. >> >>[...] >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 5 12:07:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10692 for ; Mon, 5 Apr 2004 12:07:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWc0-0002pr-Np for simple-archive@odin.ietf.org; Mon, 05 Apr 2004 12:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35G5xiW010811 for simple-archive@odin.ietf.org; Mon, 5 Apr 2004 12:05:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWbn-0002mt-Cs for simple-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 12:05:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10124 for ; Mon, 5 Apr 2004 12:05:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWbd-00042P-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 12:05:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWOy-00026x-00 for simple-web-archive@ietf.org; Mon, 05 Apr 2004 11:52:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAWDs-00004T-00; Mon, 05 Apr 2004 11:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAW2h-0006ds-C4; Mon, 05 Apr 2004 11:29:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAVZZ-00086v-3p for simple@optimus.ietf.org; Mon, 05 Apr 2004 10:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05774 for ; Mon, 5 Apr 2004 10:59:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAVZP-0001Wn-00 for simple@ietf.org; Mon, 05 Apr 2004 10:59:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAVYQ-0001Nd-00 for simple@ietf.org; Mon, 05 Apr 2004 10:58:27 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BAVXZ-00019R-00 for simple@ietf.org; Mon, 05 Apr 2004 10:57:33 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i35EvCIw060490; Mon, 5 Apr 2004 09:57:21 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407173BE.4040307@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: Chris Boulton , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <4A3384433CE2AB46A63468CB207E209DB1A44A@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A44A@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Apr 2004 09:57:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Burger wrote: > Ben gets it in one... > > As the sender of the message, there is no difference between any of the following scenarios: > > 1. The message is delivered, but the user does not read it. > 2. The message is delivered, but the user ignores it. > 3. The message is delivered, the user reads it, but the user blocks receipt generation. > 4. The message is not delivered. > > All of those scenarios, including #3, fall into the "Recipient did not get the message". > > The security implications of #3 are more then enough to suggest that generating a Positive DSN on message receipt at a UAS is a bad idea. > > On a separate thought, is the plan to have SIMPLE replace SMTP for messaging? I thought SIMPLE was for real-time communications, while ESMTP, with its myriad of non-real-time certification facilities, would be the place for things like "Registered Delivery With Return Receipt Delivery With Signatures from Every Person That Handled the Message". > I certainly hope we are not planning to replace mail. But does this absolve us from needing positive acknowledgement of delivery? I am not sure on this point. > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, April 02, 2004 2:55 PM >>To: Eric Burger >>Cc: Chris Boulton; hisham.khartabil@nokia.com; simple@ietf.org >>Subject: Re: [Simple] return receipt and delivery status notification >>for MSRP >> >> >> >> >> >> >>Eric Burger wrote: >> >>>nononononononono. >>> >>>We are confusing two, different concepts here. A DSN lets >> >>the sender know that a relay attempt failed. IMHO, a >>positive DSN has not practical value (other than generating >>information that "might be useful", but of no use). >>["Useful" information is how long it takes a message to >>traverse the relays. What user cares?] >> >>I had not confused the concepts. I was arguing that it was >>useful to get >>a report saying that an IM was successfully delivered to the >>endpoint. >>That seems to me to fit the definition of DSN more than MDN. >>But I might >>be able to be convived otherwise (see below.) >> >> >>>A MDN lets the sender know that the recipient received the message. >>> >>>If you are a *user*, and you want to *know* if someone >> >>received a message, you are going to request a MDN. >> >>If I understand correctly, you are arguing that the useful >>information >>is not whether it was delivered to the endpoint, but whether the user >>actually saw it. (Or consumer consumed it, to be more >>generic.) Is that >>the point? >> >>If so, I do not have strong feelings one way or another. I am >>willing to >>accept that, for critical delivery, the thing I care about is >>that the >>message was consumed, rather than merely delivered. >> >>But I continue to hold the opinion, that you need some form >>of positive >>acknowledgement for sufficiently important messages, whether it be >>positive DSN or MDN. Negative DSN by themselves are >>insufficent, because >>they can also fail. Positive acknowledgement gives us a >>fail-safe mode. >> >> >> >>> >>>Let's look at two cases from the example again: >>> >>>A --> R1 --> R2 --> B >>> >>>First case: >>>A sends to R1 >>>R1 tries to send to R2, but nobody is home. >>>R1 sends Failure DSN to A >>>A knows message was not delivered. Why? Because A >> >>receives the DSN. >> >>> >>>Second case: >>>A sends to R1 >>>R1 sends to R2 (successfully - no DSN) >>>R2 disappears (no DSN) >>>A *knows* B did not get the message. >>>How does A know this? Because A requested a MDN, and it >> >>never got it. >> >>To be pedantic, you do not know it was _not_ delivered. You just have >>reason to believe it might not have been delivered. Close, >>but not the >>same. B may have ignored the MDN request, or the MDN itself may have >>failed in transit. >> >> >>>One might say that A cannot tell the difference between a >> >>delivery failure and the user ignoring the message. One >>might say that one would be correct in that assertion, and >>that is by design. >> >>[...] >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 6 02:28:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11260 for ; Tue, 6 Apr 2004 02:28:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAk4C-0006wF-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 02:28:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAjyV-0005vl-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 02:22:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAjkp-0003OS-00; Tue, 06 Apr 2004 02:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjki-0005KI-2M; Tue, 06 Apr 2004 02:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjkM-000531-Ae for simple@optimus.ietf.org; Tue, 06 Apr 2004 02:07:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01325 for ; Tue, 6 Apr 2004 02:07:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAjkI-0003KN-00 for simple@ietf.org; Tue, 06 Apr 2004 02:07:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAjBp-0000Ko-00 for simple@ietf.org; Tue, 06 Apr 2004 01:32:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BAj3E-0006No-00 for simple@ietf.org; Tue, 06 Apr 2004 01:23:09 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i365Mpus006824; Tue, 6 Apr 2004 01:22:52 -0400 (EDT) Message-ID: <40723E8A.7080505@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "George Foti (QA/EMC)" CC: "'Ben Campbell'" , hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) References: <2DBF697D5B36014ABA46E66A96107DA02C96E7@lmc37.lmc.ericsson.se> In-Reply-To: <2DBF697D5B36014ABA46E66A96107DA02C96E7@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Apr 2004 01:22:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. George Foti (QA/EMC) wrote: > >> -----Original Message----- From: simple-admin@ietf.org >> [mailto:simple-admin@ietf.org]On Behalf Of Ben Campbell Sent: >> Friday, April 02, 2004 3:55 PM To: Jonathan Rosenberg Cc: >> hisham.khartabil@nokia.com; aki.niemi@nokia.com; George Foti >> (QA/EMC); simple@ietf.org Subject: Re: [Simple] RE: Comments on >> PIDF-Manipulation Usage-00draft (wa s RE: Comment s on >> draft-isomaki-simple-xcap-publish-usage-00) >> >> >> Jonathan Rosenberg wrote: [...] >> >> >>>>> I'm not aware of any text that suggests that the soft event >>>>> state manipulated with PUBLISH somehow also finds its way >>>>> into >> >> the XCAP tree. >> >>>> >>>> >>>> George's point is that there is no text forbidding it, so >> >> in theory, >> >>>> it could find its way. But the question is: Do we really need >>>> to explicitly forbit such thing from happening by placing a >> >> MUST NOT text? >> >>> >>> I think its sufficient to say that there is simply no way, >> >> with this >> >>> application usage, to point to such presence documents, >> >> making it out of >> >>> scope. >> >> I am a little confused by the statement "there is no way". I can >> imagine someone co-locating their XCAP service and a PA, and >> reflecting the current presence state into the XCAP tree. Any >> meta-data like expirations and entity tags could just be left out >> from the XCAP view. My point was, there is no STANDARD way to do this, since reflecting the published documents into the xcap tree reqiures a well-known set of HTTP URIs for identifying those documents. There is no such standard, and therefore there could be no interop for this. >> >> The point is, doing this is a bad idea. Perhaps we should say >> something to that effect. >> > > > Indeed this is a very real scenario. Given that the interface between > the XCAP server & the PS is proprietary, the XCAP server is a > privilaged publisher, and does not require any refresh for a > published state. > > So the presence composer will have to have local policies and rules > to handle status information for same devices/applications coming > from multiple sources inorder to have a predictiable behavior. I dont think this fact has anything to do with pidf-manipulation. Composition in general will require policies that tell the compositor how to handle multiple sources, potentially more than one for the same device. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 6 02:28:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11370 for ; Tue, 6 Apr 2004 02:28:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAk4H-0003kU-Da for simple-archive@odin.ietf.org; Tue, 06 Apr 2004 02:28:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i366SH7q014408 for simple-archive@odin.ietf.org; Tue, 6 Apr 2004 02:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAk4H-0003kC-4H for simple-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 02:28:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11279 for ; Tue, 6 Apr 2004 02:28:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAk4D-0006wK-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 02:28:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAjyX-0005w8-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 02:22:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAjkp-0003OS-00; Tue, 06 Apr 2004 02:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjki-0005KI-2M; Tue, 06 Apr 2004 02:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjkM-000531-Ae for simple@optimus.ietf.org; Tue, 06 Apr 2004 02:07:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01325 for ; Tue, 6 Apr 2004 02:07:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAjkI-0003KN-00 for simple@ietf.org; Tue, 06 Apr 2004 02:07:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAjBp-0000Ko-00 for simple@ietf.org; Tue, 06 Apr 2004 01:32:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BAj3E-0006No-00 for simple@ietf.org; Tue, 06 Apr 2004 01:23:09 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i365Mpus006824; Tue, 6 Apr 2004 01:22:52 -0400 (EDT) Message-ID: <40723E8A.7080505@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "George Foti (QA/EMC)" CC: "'Ben Campbell'" , hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] RE: Comments on PIDF-Manipulation Usage-00draft (wa s RE: Comment s on draft-isomaki-simple-xcap-publish-usage-00) References: <2DBF697D5B36014ABA46E66A96107DA02C96E7@lmc37.lmc.ericsson.se> In-Reply-To: <2DBF697D5B36014ABA46E66A96107DA02C96E7@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Apr 2004 01:22:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. George Foti (QA/EMC) wrote: > >> -----Original Message----- From: simple-admin@ietf.org >> [mailto:simple-admin@ietf.org]On Behalf Of Ben Campbell Sent: >> Friday, April 02, 2004 3:55 PM To: Jonathan Rosenberg Cc: >> hisham.khartabil@nokia.com; aki.niemi@nokia.com; George Foti >> (QA/EMC); simple@ietf.org Subject: Re: [Simple] RE: Comments on >> PIDF-Manipulation Usage-00draft (wa s RE: Comment s on >> draft-isomaki-simple-xcap-publish-usage-00) >> >> >> Jonathan Rosenberg wrote: [...] >> >> >>>>> I'm not aware of any text that suggests that the soft event >>>>> state manipulated with PUBLISH somehow also finds its way >>>>> into >> >> the XCAP tree. >> >>>> >>>> >>>> George's point is that there is no text forbidding it, so >> >> in theory, >> >>>> it could find its way. But the question is: Do we really need >>>> to explicitly forbit such thing from happening by placing a >> >> MUST NOT text? >> >>> >>> I think its sufficient to say that there is simply no way, >> >> with this >> >>> application usage, to point to such presence documents, >> >> making it out of >> >>> scope. >> >> I am a little confused by the statement "there is no way". I can >> imagine someone co-locating their XCAP service and a PA, and >> reflecting the current presence state into the XCAP tree. Any >> meta-data like expirations and entity tags could just be left out >> from the XCAP view. My point was, there is no STANDARD way to do this, since reflecting the published documents into the xcap tree reqiures a well-known set of HTTP URIs for identifying those documents. There is no such standard, and therefore there could be no interop for this. >> >> The point is, doing this is a bad idea. Perhaps we should say >> something to that effect. >> > > > Indeed this is a very real scenario. Given that the interface between > the XCAP server & the PS is proprietary, the XCAP server is a > privilaged publisher, and does not require any refresh for a > published state. > > So the presence composer will have to have local policies and rules > to handle status information for same devices/applications coming > from multiple sources inorder to have a predictiable behavior. I dont think this fact has anything to do with pidf-manipulation. Composition in general will require policies that tell the compositor how to handle multiple sources, potentially more than one for the same device. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 6 04:20:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20335 for ; Tue, 6 Apr 2004 04:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAlot-0004Ni-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 04:20:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAlaA-0001d5-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 04:05:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAl19-0006aE-00; Tue, 06 Apr 2004 03:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAl13-0002Mw-GF; Tue, 06 Apr 2004 03:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAl09-00022X-20 for simple@optimus.ietf.org; Tue, 06 Apr 2004 03:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16364 for ; Tue, 6 Apr 2004 03:28:02 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAl06-0006NS-00 for simple@ietf.org; Tue, 06 Apr 2004 03:28:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAktw-0005Kn-00 for simple@ietf.org; Tue, 06 Apr 2004 03:21:41 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BAkfO-0002ZA-00 for simple@ietf.org; Tue, 06 Apr 2004 03:06:38 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3676VE04166; Tue, 6 Apr 2004 10:06:31 +0300 (EET DST) X-Scanned: Tue, 6 Apr 2004 10:06:23 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3676NtR031437; Tue, 6 Apr 2004 10:06:23 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00ISAAt4; Tue, 06 Apr 2004 10:06:22 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3676HF25020; Tue, 6 Apr 2004 10:06:17 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Apr 2004 10:02:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797895@esebe019.ntc.nokia.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQY/A409EGn6U64SH2fUVLazghR1wCFfgiwACSjpaA= To: , Cc: , X-OriginalArrivalTime: 06 Apr 2004 07:02:27.0867 (UTC) FILETIME=[1F1B8EB0:01C41BA5] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 10:02:27 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Sent: 05.April.2004 16:38 > To: Ben Campbell > Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > simple@ietf.org > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 >=20 > Ben gets it in one... >=20 > As the sender of the message, there is no difference between=20 > any of the following scenarios: >=20 > 1. The message is delivered, but the user does not read it. > 2. The message is delivered, but the user ignores it. > 3. The message is delivered, the user reads it, but the user=20 > blocks receipt generation. > 4. The message is not delivered. >=20 > All of those scenarios, including #3, fall into the=20 > "Recipient did not get the message". "Message is delivered" is not the same as "message is not delivered". In = cases 1-3, the sender knows that it was a receiver action that stopped = the MDN since he will get a DSN saying that message is delivered. /Hisham >=20 > The security implications of #3 are more then enough to=20 > suggest that generating a Positive DSN on message receipt at=20 > a UAS is a bad idea. >=20 > On a separate thought, is the plan to have SIMPLE replace=20 > SMTP for messaging? I thought SIMPLE was for real-time=20 > communications, while ESMTP, with its myriad of non-real-time=20 > certification facilities, would be the place for things like=20 > "Registered Delivery With Return Receipt Delivery With=20 > Signatures from Every Person That Handled the Message". >=20 >=20 > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Friday, April 02, 2004 2:55 PM > > To: Eric Burger > > Cc: Chris Boulton; hisham.khartabil@nokia.com; simple@ietf.org > > Subject: Re: [Simple] return receipt and delivery status=20 > notification > > for MSRP > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Eric Burger wrote: > > > nononononononono. > > >=20 > > > We are confusing two, different concepts here. A DSN lets=20 > > the sender know that a relay attempt failed. IMHO, a=20 > > positive DSN has not practical value (other than generating=20 > > information that "might be useful", but of no use). =20 > > ["Useful" information is how long it takes a message to=20 > > traverse the relays. What user cares?] > > >=20 > >=20 > > I had not confused the concepts. I was arguing that it was=20 > > useful to get=20 > > a report saying that an IM was successfully delivered to the=20 > > endpoint.=20 > > That seems to me to fit the definition of DSN more than MDN.=20 > > But I might=20 > > be able to be convived otherwise (see below.) > >=20 > > > A MDN lets the sender know that the recipient received=20 > the message. > > >=20 > > > If you are a *user*, and you want to *know* if someone=20 > > received a message, you are going to request a MDN. > >=20 > > If I understand correctly, you are arguing that the useful=20 > > information=20 > > is not whether it was delivered to the endpoint, but=20 > whether the user=20 > > actually saw it. (Or consumer consumed it, to be more=20 > > generic.) Is that=20 > > the point? > >=20 > > If so, I do not have strong feelings one way or another. I am=20 > > willing to=20 > > accept that, for critical delivery, the thing I care about is=20 > > that the=20 > > message was consumed, rather than merely delivered. > >=20 > > But I continue to hold the opinion, that you need some form=20 > > of positive=20 > > acknowledgement for sufficiently important messages, whether it be=20 > > positive DSN or MDN. Negative DSN by themselves are=20 > > insufficent, because=20 > > they can also fail. Positive acknowledgement gives us a=20 > > fail-safe mode. > >=20 > >=20 > > >=20 > > >=20 > > > Let's look at two cases from the example again: > > >=20 > > > A --> R1 --> R2 --> B > > >=20 > > > First case: > > > A sends to R1 > > > R1 tries to send to R2, but nobody is home. > > > R1 sends Failure DSN to A > > > A knows message was not delivered. Why? Because A=20 > > receives the DSN. > > >=20 > > >=20 > > > Second case: > > > A sends to R1 > > > R1 sends to R2 (successfully - no DSN) > > > R2 disappears (no DSN) > > > A *knows* B did not get the message. > > > How does A know this? Because A requested a MDN, and it=20 > > never got it. > >=20 > > To be pedantic, you do not know it was _not_ delivered. You=20 > just have=20 > > reason to believe it might not have been delivered. Close,=20 > > but not the=20 > > same. B may have ignored the MDN request, or the MDN itself=20 > may have=20 > > failed in transit. > >=20 > > >=20 > > > One might say that A cannot tell the difference between a=20 > > delivery failure and the user ignoring the message. One=20 > > might say that one would be correct in that assertion, and=20 > > that is by design. > > >=20 > >=20 > > [...] > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 6 04:21:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20427 for ; Tue, 6 Apr 2004 04:21:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAlox-00070l-Q2 for simple-archive@odin.ietf.org; Tue, 06 Apr 2004 04:20:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i368KZki026952 for simple-archive@odin.ietf.org; Tue, 6 Apr 2004 04:20:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAlox-00070b-Hz for simple-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 04:20:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20353 for ; Tue, 6 Apr 2004 04:20:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAlou-0004Nw-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 04:20:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAlaB-0001dC-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 04:05:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAl19-0006aE-00; Tue, 06 Apr 2004 03:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAl13-0002Mw-GF; Tue, 06 Apr 2004 03:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAl09-00022X-20 for simple@optimus.ietf.org; Tue, 06 Apr 2004 03:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16364 for ; Tue, 6 Apr 2004 03:28:02 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAl06-0006NS-00 for simple@ietf.org; Tue, 06 Apr 2004 03:28:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAktw-0005Kn-00 for simple@ietf.org; Tue, 06 Apr 2004 03:21:41 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BAkfO-0002ZA-00 for simple@ietf.org; Tue, 06 Apr 2004 03:06:38 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3676VE04166; Tue, 6 Apr 2004 10:06:31 +0300 (EET DST) X-Scanned: Tue, 6 Apr 2004 10:06:23 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3676NtR031437; Tue, 6 Apr 2004 10:06:23 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00ISAAt4; Tue, 06 Apr 2004 10:06:22 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3676HF25020; Tue, 6 Apr 2004 10:06:17 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Apr 2004 10:02:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797895@esebe019.ntc.nokia.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQY/A409EGn6U64SH2fUVLazghR1wCFfgiwACSjpaA= To: , Cc: , X-OriginalArrivalTime: 06 Apr 2004 07:02:27.0867 (UTC) FILETIME=[1F1B8EB0:01C41BA5] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 10:02:27 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Sent: 05.April.2004 16:38 > To: Ben Campbell > Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > simple@ietf.org > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 >=20 > Ben gets it in one... >=20 > As the sender of the message, there is no difference between=20 > any of the following scenarios: >=20 > 1. The message is delivered, but the user does not read it. > 2. The message is delivered, but the user ignores it. > 3. The message is delivered, the user reads it, but the user=20 > blocks receipt generation. > 4. The message is not delivered. >=20 > All of those scenarios, including #3, fall into the=20 > "Recipient did not get the message". "Message is delivered" is not the same as "message is not delivered". In = cases 1-3, the sender knows that it was a receiver action that stopped = the MDN since he will get a DSN saying that message is delivered. /Hisham >=20 > The security implications of #3 are more then enough to=20 > suggest that generating a Positive DSN on message receipt at=20 > a UAS is a bad idea. >=20 > On a separate thought, is the plan to have SIMPLE replace=20 > SMTP for messaging? I thought SIMPLE was for real-time=20 > communications, while ESMTP, with its myriad of non-real-time=20 > certification facilities, would be the place for things like=20 > "Registered Delivery With Return Receipt Delivery With=20 > Signatures from Every Person That Handled the Message". >=20 >=20 > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Friday, April 02, 2004 2:55 PM > > To: Eric Burger > > Cc: Chris Boulton; hisham.khartabil@nokia.com; simple@ietf.org > > Subject: Re: [Simple] return receipt and delivery status=20 > notification > > for MSRP > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Eric Burger wrote: > > > nononononononono. > > >=20 > > > We are confusing two, different concepts here. A DSN lets=20 > > the sender know that a relay attempt failed. IMHO, a=20 > > positive DSN has not practical value (other than generating=20 > > information that "might be useful", but of no use). =20 > > ["Useful" information is how long it takes a message to=20 > > traverse the relays. What user cares?] > > >=20 > >=20 > > I had not confused the concepts. I was arguing that it was=20 > > useful to get=20 > > a report saying that an IM was successfully delivered to the=20 > > endpoint.=20 > > That seems to me to fit the definition of DSN more than MDN.=20 > > But I might=20 > > be able to be convived otherwise (see below.) > >=20 > > > A MDN lets the sender know that the recipient received=20 > the message. > > >=20 > > > If you are a *user*, and you want to *know* if someone=20 > > received a message, you are going to request a MDN. > >=20 > > If I understand correctly, you are arguing that the useful=20 > > information=20 > > is not whether it was delivered to the endpoint, but=20 > whether the user=20 > > actually saw it. (Or consumer consumed it, to be more=20 > > generic.) Is that=20 > > the point? > >=20 > > If so, I do not have strong feelings one way or another. I am=20 > > willing to=20 > > accept that, for critical delivery, the thing I care about is=20 > > that the=20 > > message was consumed, rather than merely delivered. > >=20 > > But I continue to hold the opinion, that you need some form=20 > > of positive=20 > > acknowledgement for sufficiently important messages, whether it be=20 > > positive DSN or MDN. Negative DSN by themselves are=20 > > insufficent, because=20 > > they can also fail. Positive acknowledgement gives us a=20 > > fail-safe mode. > >=20 > >=20 > > >=20 > > >=20 > > > Let's look at two cases from the example again: > > >=20 > > > A --> R1 --> R2 --> B > > >=20 > > > First case: > > > A sends to R1 > > > R1 tries to send to R2, but nobody is home. > > > R1 sends Failure DSN to A > > > A knows message was not delivered. Why? Because A=20 > > receives the DSN. > > >=20 > > >=20 > > > Second case: > > > A sends to R1 > > > R1 sends to R2 (successfully - no DSN) > > > R2 disappears (no DSN) > > > A *knows* B did not get the message. > > > How does A know this? Because A requested a MDN, and it=20 > > never got it. > >=20 > > To be pedantic, you do not know it was _not_ delivered. You=20 > just have=20 > > reason to believe it might not have been delivered. Close,=20 > > but not the=20 > > same. B may have ignored the MDN request, or the MDN itself=20 > may have=20 > > failed in transit. > >=20 > > >=20 > > > One might say that A cannot tell the difference between a=20 > > delivery failure and the user ignoring the message. One=20 > > might say that one would be correct in that assertion, and=20 > > that is by design. > > >=20 > >=20 > > [...] > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 6 13:49:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11189 for ; Tue, 6 Apr 2004 13:49:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuhb-0007ba-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 13:49:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAucD-0006gd-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 13:44:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAuT5-0005M8-00; Tue, 06 Apr 2004 13:34:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuPE-0000Bi-VS; Tue, 06 Apr 2004 13:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuAU-00065U-RQ for simple@optimus.ietf.org; Tue, 06 Apr 2004 13:15:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07538; Tue, 6 Apr 2004 13:15:20 -0400 (EDT) Message-Id: <200404061715.NAA07538@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-iscomposing-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Apr 2004 13:15:20 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : is-composing Indication for Instant Messaging Using the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne Filename : draft-ietf-simple-iscomposing-00.txt Pages : 10 Date : 2004-4-5 In instant messaging systems, it is useful to know that the other party is composing a message, e.g., typing. This document defines a new content type and XML namespace that conveys information about a message being composed. The message could be of any type, including text, voice or video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-iscomposing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-iscomposing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-6105439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-iscomposing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-iscomposing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-6105439.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 6 13:50:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11549 for ; Tue, 6 Apr 2004 13:50:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuhu-000555-Qu for simple-archive@odin.ietf.org; Tue, 06 Apr 2004 13:50:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36HniNN019405 for simple-archive@odin.ietf.org; Tue, 6 Apr 2004 13:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuhk-00052L-Cm for simple-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 13:49:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11187 for ; Tue, 6 Apr 2004 13:49:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuhb-0007bd-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 13:49:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAucE-0006gv-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 13:44:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAuT5-0005M8-00; Tue, 06 Apr 2004 13:34:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuPE-0000Bi-VS; Tue, 06 Apr 2004 13:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuAU-00065U-RQ for simple@optimus.ietf.org; Tue, 06 Apr 2004 13:15:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07538; Tue, 6 Apr 2004 13:15:20 -0400 (EDT) Message-Id: <200404061715.NAA07538@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-iscomposing-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Apr 2004 13:15:20 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : is-composing Indication for Instant Messaging Using the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne Filename : draft-ietf-simple-iscomposing-00.txt Pages : 10 Date : 2004-4-5 In instant messaging systems, it is useful to know that the other party is composing a message, e.g., typing. This document defines a new content type and XML namespace that conveys information about a message being composed. The message could be of any type, including text, voice or video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-iscomposing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-iscomposing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-6105439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-iscomposing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-iscomposing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-6105439.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 6 16:15:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25200 for ; Tue, 6 Apr 2004 16:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwz2-0004OO-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 16:15:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwSc-0006GZ-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 15:42:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAvYN-0000Na-00; Tue, 06 Apr 2004 14:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvYH-0004RO-A8; Tue, 06 Apr 2004 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvY6-0004R8-Fv for simple@optimus.ietf.org; Tue, 06 Apr 2004 14:43:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15771 for ; Tue, 6 Apr 2004 14:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAvY3-0000Lz-00 for simple@ietf.org; Tue, 06 Apr 2004 14:43:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAvNQ-0006b3-00 for simple@ietf.org; Tue, 06 Apr 2004 14:32:49 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1BAvKs-00064Y-00 for simple@ietf.org; Tue, 06 Apr 2004 14:30:10 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15847; Tue, 06 Apr 2004 14:27:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A460@zoe.office.snowshore.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQY/A409EGn6U64SH2fUVLazghR1wCFfgiwACSjpaAAF5TdsA== From: "Eric Burger" To: , Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 14:29:39 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable And if the receiver is sensible, she will set her UAS options to never = offer positive DSN, making it useless. I could see putting it in the protocol if one was looking to deploy such = a system where there were legal implications of a message being = delivered (financial services?). However, wouldn't e-mail be better for = that? > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, April 06, 2004 3:02 AM > To: Eric Burger; bcampbell@dynamicsoft.com > Cc: cboulton@ubiquity.com; simple@ietf.org > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > Sent: 05.April.2004 16:38 > > To: Ben Campbell > > Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > > simple@ietf.org > > Subject: RE: [Simple] return receipt and delivery status=20 > notification > > for MSRP > >=20 > >=20 > >=20 > > Ben gets it in one... > >=20 > > As the sender of the message, there is no difference between=20 > > any of the following scenarios: > >=20 > > 1. The message is delivered, but the user does not read it. > > 2. The message is delivered, but the user ignores it. > > 3. The message is delivered, the user reads it, but the user=20 > > blocks receipt generation. > > 4. The message is not delivered. > >=20 > > All of those scenarios, including #3, fall into the=20 > > "Recipient did not get the message". >=20 > "Message is delivered" is not the same as "message is not=20 > delivered". In cases 1-3, the sender knows that it was a=20 > receiver action that stopped the MDN since he will get a DSN=20 > saying that message is delivered. >=20 > /Hisham >=20 > >=20 > > The security implications of #3 are more then enough to=20 > > suggest that generating a Positive DSN on message receipt at=20 > > a UAS is a bad idea. > >=20 > > On a separate thought, is the plan to have SIMPLE replace=20 > > SMTP for messaging? I thought SIMPLE was for real-time=20 > > communications, while ESMTP, with its myriad of non-real-time=20 > > certification facilities, would be the place for things like=20 > > "Registered Delivery With Return Receipt Delivery With=20 > > Signatures from Every Person That Handled the Message". [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 6 16:16:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25345 for ; Tue, 6 Apr 2004 16:16:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwz5-00031Q-WB for simple-archive@odin.ietf.org; Tue, 06 Apr 2004 16:15:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36KFlgO011617 for simple-archive@odin.ietf.org; Tue, 6 Apr 2004 16:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwz5-00031I-P0 for simple-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:15:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25218 for ; Tue, 6 Apr 2004 16:15:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwz4-0004Om-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 16:15:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwSe-0006Gz-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 15:42:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAvYN-0000Na-00; Tue, 06 Apr 2004 14:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvYH-0004RO-A8; Tue, 06 Apr 2004 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvY6-0004R8-Fv for simple@optimus.ietf.org; Tue, 06 Apr 2004 14:43:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15771 for ; Tue, 6 Apr 2004 14:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAvY3-0000Lz-00 for simple@ietf.org; Tue, 06 Apr 2004 14:43:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAvNQ-0006b3-00 for simple@ietf.org; Tue, 06 Apr 2004 14:32:49 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1BAvKs-00064Y-00 for simple@ietf.org; Tue, 06 Apr 2004 14:30:10 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15847; Tue, 06 Apr 2004 14:27:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] return receipt and delivery status notification for MSRP Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A460@zoe.office.snowshore.com> Thread-Topic: [Simple] return receipt and delivery status notification for MSRP Thread-Index: AcQY/A409EGn6U64SH2fUVLazghR1wCFfgiwACSjpaAAF5TdsA== From: "Eric Burger" To: , Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 14:29:39 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable And if the receiver is sensible, she will set her UAS options to never = offer positive DSN, making it useless. I could see putting it in the protocol if one was looking to deploy such = a system where there were legal implications of a message being = delivered (financial services?). However, wouldn't e-mail be better for = that? > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, April 06, 2004 3:02 AM > To: Eric Burger; bcampbell@dynamicsoft.com > Cc: cboulton@ubiquity.com; simple@ietf.org > Subject: RE: [Simple] return receipt and delivery status notification > for MSRP >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > Sent: 05.April.2004 16:38 > > To: Ben Campbell > > Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > > simple@ietf.org > > Subject: RE: [Simple] return receipt and delivery status=20 > notification > > for MSRP > >=20 > >=20 > >=20 > > Ben gets it in one... > >=20 > > As the sender of the message, there is no difference between=20 > > any of the following scenarios: > >=20 > > 1. The message is delivered, but the user does not read it. > > 2. The message is delivered, but the user ignores it. > > 3. The message is delivered, the user reads it, but the user=20 > > blocks receipt generation. > > 4. The message is not delivered. > >=20 > > All of those scenarios, including #3, fall into the=20 > > "Recipient did not get the message". >=20 > "Message is delivered" is not the same as "message is not=20 > delivered". In cases 1-3, the sender knows that it was a=20 > receiver action that stopped the MDN since he will get a DSN=20 > saying that message is delivered. >=20 > /Hisham >=20 > >=20 > > The security implications of #3 are more then enough to=20 > > suggest that generating a Positive DSN on message receipt at=20 > > a UAS is a bad idea. > >=20 > > On a separate thought, is the plan to have SIMPLE replace=20 > > SMTP for messaging? I thought SIMPLE was for real-time=20 > > communications, while ESMTP, with its myriad of non-real-time=20 > > certification facilities, would be the place for things like=20 > > "Registered Delivery With Return Receipt Delivery With=20 > > Signatures from Every Person That Handled the Message". [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 6 18:05:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04254 for ; Tue, 6 Apr 2004 18:05:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAyhC-0002Bh-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 18:05:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAy49-0003In-00 for simple-archive@ietf.org; Tue, 06 Apr 2004 17:25:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAwzd-0004WG-00; Tue, 06 Apr 2004 16:16:21 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAwzd-0002iP-EW; Tue, 06 Apr 2004 16:16:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwzJ-00033U-UC; Tue, 06 Apr 2004 16:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwyR-0002ZC-DQ for simple@optimus.ietf.org; Tue, 06 Apr 2004 16:15:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25056 for ; Tue, 6 Apr 2004 16:15:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwyP-0004Fs-00 for simple@ietf.org; Tue, 06 Apr 2004 16:15:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwRD-00060n-00 for simple@ietf.org; Tue, 06 Apr 2004 15:40:48 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BAvUy-00005W-00 for simple@ietf.org; Tue, 06 Apr 2004 14:40:36 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i36IeQIx090422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2004 13:40:27 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4072F997.5040701@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: hisham.khartabil@nokia.com, cboulton@ubiquity.com, simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <4A3384433CE2AB46A63468CB207E209DB1A460@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A460@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Apr 2004 13:40:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eric Burger wrote: > And if the receiver is sensible, she will set her UAS options to never offer positive DSN, making it useless. > > I could see putting it in the protocol if one was looking to deploy such a system where there were legal implications of a message being delivered (financial services?). However, wouldn't e-mail be better for that? The financial services market is really interested in IM, as some aspects of the industry tend to be highly time sensitive. (And, no, I am not arguing that IM is necessarily any faster than mail...) > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: Tuesday, April 06, 2004 3:02 AM >>To: Eric Burger; bcampbell@dynamicsoft.com >>Cc: cboulton@ubiquity.com; simple@ietf.org >>Subject: RE: [Simple] return receipt and delivery status notification >>for MSRP >> >> >> >> >> >>>-----Original Message----- >>>From: ext Eric Burger [mailto:eburger@snowshore.com] >>>Sent: 05.April.2004 16:38 >>>To: Ben Campbell >>>Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>>simple@ietf.org >>>Subject: RE: [Simple] return receipt and delivery status >> >>notification >> >>>for MSRP >>> >>> >>> >>>Ben gets it in one... >>> >>>As the sender of the message, there is no difference between >>>any of the following scenarios: >>> >>>1. The message is delivered, but the user does not read it. >>>2. The message is delivered, but the user ignores it. >>>3. The message is delivered, the user reads it, but the user >>>blocks receipt generation. >>>4. The message is not delivered. >>> >>>All of those scenarios, including #3, fall into the >>>"Recipient did not get the message". >> >>"Message is delivered" is not the same as "message is not >>delivered". In cases 1-3, the sender knows that it was a >>receiver action that stopped the MDN since he will get a DSN >>saying that message is delivered. >> >>/Hisham >> >> >>>The security implications of #3 are more then enough to >>>suggest that generating a Positive DSN on message receipt at >>>a UAS is a bad idea. >>> >>>On a separate thought, is the plan to have SIMPLE replace >>>SMTP for messaging? I thought SIMPLE was for real-time >>>communications, while ESMTP, with its myriad of non-real-time >>>certification facilities, would be the place for things like >>>"Registered Delivery With Return Receipt Delivery With >>>Signatures from Every Person That Handled the Message". > > [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 6 18:05:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04410 for ; Tue, 6 Apr 2004 18:05:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyhG-0003mz-6t for simple-archive@odin.ietf.org; Tue, 06 Apr 2004 18:05:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36M5UZk014566 for simple-archive@odin.ietf.org; Tue, 6 Apr 2004 18:05:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyhF-0003mr-Ov for simple-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 18:05:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04274 for ; Tue, 6 Apr 2004 18:05:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAyhD-0002Bz-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 18:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAy4B-0003Iw-00 for simple-web-archive@ietf.org; Tue, 06 Apr 2004 17:25:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAwzd-0004WG-00; Tue, 06 Apr 2004 16:16:21 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAwzd-0002iP-EW; Tue, 06 Apr 2004 16:16:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwzJ-00033U-UC; Tue, 06 Apr 2004 16:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwyR-0002ZC-DQ for simple@optimus.ietf.org; Tue, 06 Apr 2004 16:15:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25056 for ; Tue, 6 Apr 2004 16:15:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwyP-0004Fs-00 for simple@ietf.org; Tue, 06 Apr 2004 16:15:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwRD-00060n-00 for simple@ietf.org; Tue, 06 Apr 2004 15:40:48 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BAvUy-00005W-00 for simple@ietf.org; Tue, 06 Apr 2004 14:40:36 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i36IeQIx090422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2004 13:40:27 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4072F997.5040701@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: hisham.khartabil@nokia.com, cboulton@ubiquity.com, simple@ietf.org Subject: Re: [Simple] return receipt and delivery status notification for MSRP References: <4A3384433CE2AB46A63468CB207E209DB1A460@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A460@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Apr 2004 13:40:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Burger wrote: > And if the receiver is sensible, she will set her UAS options to never offer positive DSN, making it useless. > > I could see putting it in the protocol if one was looking to deploy such a system where there were legal implications of a message being delivered (financial services?). However, wouldn't e-mail be better for that? The financial services market is really interested in IM, as some aspects of the industry tend to be highly time sensitive. (And, no, I am not arguing that IM is necessarily any faster than mail...) > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: Tuesday, April 06, 2004 3:02 AM >>To: Eric Burger; bcampbell@dynamicsoft.com >>Cc: cboulton@ubiquity.com; simple@ietf.org >>Subject: RE: [Simple] return receipt and delivery status notification >>for MSRP >> >> >> >> >> >>>-----Original Message----- >>>From: ext Eric Burger [mailto:eburger@snowshore.com] >>>Sent: 05.April.2004 16:38 >>>To: Ben Campbell >>>Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>>simple@ietf.org >>>Subject: RE: [Simple] return receipt and delivery status >> >>notification >> >>>for MSRP >>> >>> >>> >>>Ben gets it in one... >>> >>>As the sender of the message, there is no difference between >>>any of the following scenarios: >>> >>>1. The message is delivered, but the user does not read it. >>>2. The message is delivered, but the user ignores it. >>>3. The message is delivered, the user reads it, but the user >>>blocks receipt generation. >>>4. The message is not delivered. >>> >>>All of those scenarios, including #3, fall into the >>>"Recipient did not get the message". >> >>"Message is delivered" is not the same as "message is not >>delivered". In cases 1-3, the sender knows that it was a >>receiver action that stopped the MDN since he will get a DSN >>saying that message is delivered. >> >>/Hisham >> >> >>>The security implications of #3 are more then enough to >>>suggest that generating a Positive DSN on message receipt at >>>a UAS is a bad idea. >>> >>>On a separate thought, is the plan to have SIMPLE replace >>>SMTP for messaging? I thought SIMPLE was for real-time >>>communications, while ESMTP, with its myriad of non-real-time >>>certification facilities, would be the place for things like >>>"Registered Delivery With Return Receipt Delivery With >>>Signatures from Every Person That Handled the Message". > > [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 7 16:51:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02530 for ; Wed, 7 Apr 2004 16:51:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBK18-00011t-00 for simple-archive@ietf.org; Wed, 07 Apr 2004 16:51:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBHvi-0003jG-00 for simple-archive@ietf.org; Wed, 07 Apr 2004 14:37:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBGzo-0002hx-00; Wed, 07 Apr 2004 13:37:52 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBGzp-0003rm-Ty; Wed, 07 Apr 2004 13:37:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBFsB-0001Wj-4n; Wed, 07 Apr 2004 12:25:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBF6q-0003fR-4I for simple@optimus.ietf.org; Wed, 07 Apr 2004 11:37:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03936; Wed, 7 Apr 2004 11:36:23 -0400 (EDT) Message-Id: <200404071536.LAA03936@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-04.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Apr 2004 11:36:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Instant Message Sessions in SIMPLE Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-04.txt Pages : 38 Date : 2004-4-6 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model carried by a signaling protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110906.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 7 16:51:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02685 for ; Wed, 7 Apr 2004 16:51:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK1B-0002vQ-St for simple-archive@odin.ietf.org; Wed, 07 Apr 2004 16:51:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37KpTBl011245 for simple-archive@odin.ietf.org; Wed, 7 Apr 2004 16:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK1B-0002vI-Mc for simple-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 16:51:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02550 for ; Wed, 7 Apr 2004 16:51:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBK19-00012E-00 for simple-web-archive@ietf.org; Wed, 07 Apr 2004 16:51:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBHvk-0003jY-00 for simple-web-archive@ietf.org; Wed, 07 Apr 2004 14:37:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBGzo-0002hx-00; Wed, 07 Apr 2004 13:37:52 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBGzp-0003rm-Ty; Wed, 07 Apr 2004 13:37:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBFsB-0001Wj-4n; Wed, 07 Apr 2004 12:25:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBF6q-0003fR-4I for simple@optimus.ietf.org; Wed, 07 Apr 2004 11:37:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03936; Wed, 7 Apr 2004 11:36:23 -0400 (EDT) Message-Id: <200404071536.LAA03936@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-04.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Apr 2004 11:36:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Instant Message Sessions in SIMPLE Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-04.txt Pages : 38 Date : 2004-4-6 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model carried by a signaling protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110906.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 8 03:05:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14576 for ; Thu, 8 Apr 2004 03:05:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBTbp-00049B-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 03:05:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRk8-0004ZW-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 01:06:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBPeK-0006Y5-03; Wed, 07 Apr 2004 22:52:16 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBPOn-00083E-GX; Wed, 07 Apr 2004 22:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPOc-0006yp-T5; Wed, 07 Apr 2004 22:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPNx-0006wQ-8k for simple@optimus.ietf.org; Wed, 07 Apr 2004 22:35:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09931 for ; Wed, 7 Apr 2004 22:35:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBPNt-0005EU-00 for simple@ietf.org; Wed, 07 Apr 2004 22:35:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBO3S-0001Lu-00 for simple@ietf.org; Wed, 07 Apr 2004 21:10:08 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BBM9n-0003Fi-00 for simple@ietf.org; Wed, 07 Apr 2004 19:08:31 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 7 Apr 2004 16:07:59 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Wed, 7 Apr 2004 16:07:59 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 16:07:59 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 16:08:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-cc4eeec3-dd04-4b34-afb3-92743aed4da4" Message-ID: Thread-Topic: FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Thread-Index: AcQc9SrFlCjJ7dVbRXqr3kMaUxJIUQ== From: "Orit Levin" To: X-OriginalArrivalTime: 07 Apr 2004 23:08:02.0921 (UTC) FILETIME=[2D80FD90:01C41CF5] Subject: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Apr 2004 16:07:58 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MIME_BOUND_NEXTPART autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPartTM-000-cc4eeec3-dd04-4b34-afb3-92743aed4da4 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41CF5.382DA8D6" ------_=_NextPart_001_01C41CF5.382DA8D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! This is the analysis that I promised to prepare during the last SIMPLE meeting. =20 The proposed application TCP keep-alive mechanism may not be the only way to resolve the problem, but my strong feeling is that the scalability problem MUST be resolved in a reasonable way by not requiring ACCEPT for each MSRP message and on each UA and each relay. =20 Thanks, Orit. =20 ------------------------------------------------------------------------ ---------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Review of MSRP Delivery Mechanisms Author(s) : O. Levin Filename : draft-levin-simple-msrp-review-00.txt Pages : 16 Date : 2004-4-6 =20 This paper shows that the currently defined per-message hop-by-hop mechanism doesn't scale for large deployments and is not feasible for scalable IM conferencing. Instead, the paper proposes to replace this mechanism with an MSRP layer "per TCP connection keep-alive mechanism". This paper also reinforces the need for the end-to-end mechanism to be defined in the core MSRP specification and to become the abstraction for all MSRP applications regardless the underlying topology in use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-simple-msrp-review-00.tx t ------_=_NextPart_001_01C41CF5.382DA8D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi!
This = is the analysis=20 that I promised to prepare during the last SIMPLE = meeting.
 
The = proposed=20 application TCP keep-alive mechanism may not be the only way to resolve = the=20 problem, but my strong feeling is that the scalability problem MUST = be=20 resolved in a reasonable way by not requiring ACCEPT for each = MSRP=20 message and on each UA and each relay.
 
Thanks,
Orit.
 
----------------------------------------------------------------= ------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.


Title : Review of MSRP Delivery = Mechanisms
Author(s)=20 : O. Levin
Filename : draft-levin-simple-msrp-review-00.txt
Pages = :=20 16
Date : 2004-4-6
 
This paper shows that the currently = defined=20 per-message hop-by-hop
   mechanism doesn’t scale for = large=20 deployments and is not feasible for
   scalable IM = conferencing.=20 Instead, the paper proposes to replace this
   mechanism = with an=20 MSRP layer "per TCP connection keep-alive
   mechanism". = This paper=20 also reinforces the need for the end-to-end
   mechanism to = be=20 defined in the core MSRP specification and to become
   the = abstraction for all MSRP applications regardless the = underlying
  =20 topology in use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levin-simple-msrp-rev= iew-00.txt

------_=_NextPart_001_01C41CF5.382DA8D6-- ------=_NextPartTM-000-cc4eeec3-dd04-4b34-afb3-92743aed4da4-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 8 03:06:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14708 for ; Thu, 8 Apr 2004 03:06:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBTbz-00052T-W3 for simple-archive@odin.ietf.org; Thu, 08 Apr 2004 03:06:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38767r2019321 for simple-archive@odin.ietf.org; Thu, 8 Apr 2004 03:06:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBTbz-00050o-1c for simple-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 03:06:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14606 for ; Thu, 8 Apr 2004 03:06:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBTbv-00049w-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 03:06:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRkB-0004Zy-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 01:06:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBPeK-0006Y5-03; Wed, 07 Apr 2004 22:52:16 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBPOn-00083E-GX; Wed, 07 Apr 2004 22:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPOc-0006yp-T5; Wed, 07 Apr 2004 22:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPNx-0006wQ-8k for simple@optimus.ietf.org; Wed, 07 Apr 2004 22:35:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09931 for ; Wed, 7 Apr 2004 22:35:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBPNt-0005EU-00 for simple@ietf.org; Wed, 07 Apr 2004 22:35:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBO3S-0001Lu-00 for simple@ietf.org; Wed, 07 Apr 2004 21:10:08 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BBM9n-0003Fi-00 for simple@ietf.org; Wed, 07 Apr 2004 19:08:31 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 7 Apr 2004 16:07:59 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Wed, 7 Apr 2004 16:07:59 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Apr 2004 16:07:59 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 16:08:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-cc4eeec3-dd04-4b34-afb3-92743aed4da4" Message-ID: Thread-Topic: FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Thread-Index: AcQc9SrFlCjJ7dVbRXqr3kMaUxJIUQ== From: "Orit Levin" To: X-OriginalArrivalTime: 07 Apr 2004 23:08:02.0921 (UTC) FILETIME=[2D80FD90:01C41CF5] Subject: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Apr 2004 16:07:58 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MIME_BOUND_NEXTPART autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPartTM-000-cc4eeec3-dd04-4b34-afb3-92743aed4da4 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41CF5.382DA8D6" ------_=_NextPart_001_01C41CF5.382DA8D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! This is the analysis that I promised to prepare during the last SIMPLE meeting. =20 The proposed application TCP keep-alive mechanism may not be the only way to resolve the problem, but my strong feeling is that the scalability problem MUST be resolved in a reasonable way by not requiring ACCEPT for each MSRP message and on each UA and each relay. =20 Thanks, Orit. =20 ------------------------------------------------------------------------ ---------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Review of MSRP Delivery Mechanisms Author(s) : O. Levin Filename : draft-levin-simple-msrp-review-00.txt Pages : 16 Date : 2004-4-6 =20 This paper shows that the currently defined per-message hop-by-hop mechanism doesn't scale for large deployments and is not feasible for scalable IM conferencing. Instead, the paper proposes to replace this mechanism with an MSRP layer "per TCP connection keep-alive mechanism". This paper also reinforces the need for the end-to-end mechanism to be defined in the core MSRP specification and to become the abstraction for all MSRP applications regardless the underlying topology in use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-simple-msrp-review-00.tx t ------_=_NextPart_001_01C41CF5.382DA8D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi!
This = is the analysis=20 that I promised to prepare during the last SIMPLE = meeting.
 
The = proposed=20 application TCP keep-alive mechanism may not be the only way to resolve = the=20 problem, but my strong feeling is that the scalability problem MUST = be=20 resolved in a reasonable way by not requiring ACCEPT for each = MSRP=20 message and on each UA and each relay.
 
Thanks,
Orit.
 
----------------------------------------------------------------= ------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.


Title : Review of MSRP Delivery = Mechanisms
Author(s)=20 : O. Levin
Filename : draft-levin-simple-msrp-review-00.txt
Pages = :=20 16
Date : 2004-4-6
 
This paper shows that the currently = defined=20 per-message hop-by-hop
   mechanism doesn’t scale for = large=20 deployments and is not feasible for
   scalable IM = conferencing.=20 Instead, the paper proposes to replace this
   mechanism = with an=20 MSRP layer "per TCP connection keep-alive
   mechanism". = This paper=20 also reinforces the need for the end-to-end
   mechanism to = be=20 defined in the core MSRP specification and to become
   the = abstraction for all MSRP applications regardless the = underlying
  =20 topology in use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levin-simple-msrp-rev= iew-00.txt

------_=_NextPart_001_01C41CF5.382DA8D6-- ------=_NextPartTM-000-cc4eeec3-dd04-4b34-afb3-92743aed4da4-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 8 21:04:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18125 for ; Thu, 8 Apr 2004 21:04:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkRp-0007hz-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 21:04:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkCq-0005FX-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 20:49:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjpk-0002YY-00; Thu, 08 Apr 2004 20:25:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjpd-0002kK-99; Thu, 08 Apr 2004 20:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiuk-0005Tx-B0 for simple@optimus.ietf.org; Thu, 08 Apr 2004 19:26:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08147 for ; Thu, 8 Apr 2004 19:26:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiui-0004W7-00 for simple@ietf.org; Thu, 08 Apr 2004 19:26:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhnZ-0003sN-00 for simple@ietf.org; Thu, 08 Apr 2004 18:15:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfpU-00039v-00 for simple@ietf.org; Thu, 08 Apr 2004 16:08:52 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBfWr-00064a-Kj for simple@ietf.org; Thu, 08 Apr 2004 15:49:37 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i38JnPIx025575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2004 14:49:26 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4075ACB9.9080408@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Simple WG Subject: Re: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by magus.nostrum.com id i38JnPIx025575 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Apr 2004 14:49:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, thanks for sending this. I do have some comments and questions. This=20 email is strictly in response to your draft. I will send general=20 comments about MSRP with and without transaction responses in a separate=20 email. The big ones first: You make a number of assertions of normative behavior for relays.=20 Considering that we do not have an MSRP relay draft yet, these=20 assertions are a bit overstated. The recent discussions, both on and off=20 the list, involved making some assumtions about how relays work, based=20 on the SIMS draft. The reason for these assumptions was to determine=20 what changes needed to be made to the MSRP base spec to minimally enable=20 relay integration. Second, you use a SIP transaction model to prove the impact of=20 transaction responses. I need to think that through better, but my first=20 inclination is to say that it is not a good comparison to MSRP. This is=20 because the SIP transaction model is much more complex and timing=20 sensitive than anything currently proposed for MSRP. Further, the MSRP=20 syntax is (hopefully) lighter weight, and easier to parse. Therefore, I=20 think that, if you had done this test using an MSRP device, and kept the=20 other factors the same, the difference in performance between running=20 with and without responses would be smaller than that for a SIP device. Further, if I understand your data correctly, with the SIP device you=20 see a difference in performance of around %20. Is this correct? If so, I=20 do not find that to be highly convincing by itself. If we were talking=20 about order-of-magnitude differences, I would be more convinced. Of=20 course, if we end up accepting your other assertions that the=20 transaction response brings no value, then a %20 change might be worthwhi= le. And now, some specific comments: > The hop-by-hop mechanism (sometimes referred to as the "ACCEPT" > mechanism) is modeled after the SIP transaction model.=20 We used the term "ACCEPT" in off line discussions as an abstraction to=20 talk about transaction responses. I think in this draft, it would be=20 less confusing to use the terminology from the MSRP draft. Perhaps=20 "transaction response" would be more clear. > (Negative responses are also defined but they are applicable only for > deployments with no relays in the network.) There has not been any agreement to that effect that I am aware of. We=20 had a side conversation that we might want to get rid of negative=20 transaction responses for relays, but no wg consensus. I personally do=20 not like the idea of having a different set of allowed transaction=20 responses depending on whether relays are present. > The negative "end-to-end" mechanism is mandatory for relays for error > reporting when connectivity problem is detected. In this context the > mechanism is interchangeably referred to as "DSR" or "DSN". Relays > MUST NOT use the end-to end mechanism for reporting positive > acknowledgements. DSN would not necessarily be end-to-end, since, as you mention, relays=20 might generate them. Also, I accidentally introduced the acronym DSR due=20 to some email typos. I think we can drop it. > When an MSRP entity A (a user agent or a relay) sends/forwards a > message, it creates the message transaction state and starts a timer > (~30 sec).=20 Adam suggested that we don't really need a mandatory timer here. He=20 proposed that we say that a device MAY create a timer, and the value=20 would be local policy. If a device(endpoint or relay) does _not_ create=20 a timer, it would merely keep a record of the transaction until it got a=20 transaction response, at which time it could completely forget about it.=20 If a TCP error is encounted, it would then need to either send DSN(s)=20 for any outstanding transactions (if a relay), or inform the user (if=20 and endpoint.) I believe that removing the mandatory timer will make it=20 possible for a relay to greatly reduce the transaction overhead. The=20 only advantage in keeping such a timer is it could allow a device to=20 detect a problem faster than TCP will by itself. This would come at the=20 expense of more false failure notifications. > If there is an > immediate problem in the local handling of this message by B, the > MSRP entity (B) MUST generate an error report and send it all the wa= y > back to the originator (i.e. the original source) of the message > using the end-to-end mechanism described below. I don't think we have consensus on that point. This goes back to the=20 point about negative transaction responses. If the failure is immediate,=20 B could have just sent a negative transaction response. The DSN is=20 needed for failures that require too much time to detect to block the=20 sending of the transaction response. > In both cases, the > error reports must include a list the messages per originator that > haven=92t been acknowledged by the next hop. We still need to do work to determine whether a DSN can include a list=20 of failed messages, or we have a separate DSN per message. > o In addition, if as a result of the SDP negotiation, a user agent > agreed to provide an application layer positive and/or negative > report/receipt per message, the user agent MUST create the report > and send it back to the message originator in the same manner as > described above (i.e. inside the existing MSRP connection) I am confused by this paragraph. The section so far talked about how you=20 send DSN. This paragraph seems to say "And if you agreed to do so, you=20 also have to send DSN. How is this not redundant?" > The following known issues still need to be addressed by the MSRP > specification: >=20 > o Relationship between the MSRP end-to-end procedures and the > "application above the user agent" end-to-end procedures Our current expectation is the primary use of DSN would be to present=20 the information to the user, who then does whatever he or she chooses. I=20 expect it to be machine parseable, but do not expect to define any=20 normative behavior from the application beyond telling the user. > o The exact end-to-end operation modes and their negotiation using > the offer-answer SDP mechanism That work is currently in progress. (In fact, Chris Boulon just proposed=20 some text to me on DSN in general--Yeah Chris!!) In the past, though, you have suggested per-message negotiation, rather=20 than SDP based, i.e. per-session, negotiation. Are you saying you would=20 now prefer per-session? > o The exact format of the reports (both negative and positive) In progress. > o A mechanism needs to be defined so that all outstanding end-to-en= d > reports (i.e. belonging to sessions ended earlier by user agents) > are silently discarded by the system The next MSRP draft will call out an open issue on whether DSN can be=20 delivered after a session ends. > o A mechanism needs to be defined so that NO end-to-end status > reports will be generated about delivery of earlier end-to-end > status reports In progress. > o It is unclear why the status report messages need to be > acknowledged hop-by-hop (as per current design) because they MUST > not be included in the status reports (as stated above) It is a matter of balancing the complexity of having two different=20 transaction models with the cost of having a transaction model that=20 works well for the primary usage (sending IMs) but is less optimal for a=20 secondary usage (sending DSN, or other status reports.) Scalability analysis: > The most trivial consequence of the defined "hop-by-hop" mechanism i= s > the need to keep per message a state object (including a timer) and > to clear it upon receiving an acknowledgement for the message. >=20 As I mentioned above, we have a proposal to remove the requirement to=20 keep a timer. This should have a significant affect on the overall impact. > In order to fully realize the impact of this design on an IM system, > we need to translate it to numbers. For example, as of today, a > typical public IM service would have 150MM subscribed users with a > peak of 10MM simultaneous users. >=20 > Consequently, in order to compare the cost of such IM solution to > "less statefull" IM architectures, every additional bit of memory an= d > CPU processing power required for keeping the state per "message > transaction" need to be multiplied at least (since message > transactions can be overlapped) by 10MM. I'm confused. Are you saying that, if I have 10 million (I assume you=20 mean MM to represent a million.) concurrently logged in users, I have 10=20 million MSRP transactions in play at any moment? I would assume not all=20 active users are in a session at any moment, and not all that _are_ in a=20 session have an open transaction at any moment. Am I misunderastanding=20 your point? > It is interesting to mention that even modern TCP implementations > have moved away from acknowledging every TCP segment and today > acknowledge every second segment only=85 >=20 While I don't find TCP's ack rate to be particularly relevent to the=20 discussion, I believe that most implementations send _"at least that=20 often", which is very different than "no more often than". >=20 > One of the concerns with the suggested hop-by-hop mechanism is that > although the mechanism is very simple, it suffers from some of the > known TCP problems but, unlike TCP, doesn=92t address them. > Unfortunately, the current working assumption that the > "congestion-safe" TCP will automatically make the MSRP > congestion-safe is inaccurate. I think the point of congestion-safety, is the presence of MSRP on the=20 network should not interfere with the use of _other_ applications. It is=20 not the same as saying an MSRP relay cannot itself get congested. > Because each message will be acknowledged (by Response) by B > automatically, A needs to control the rate of the messages it sends > to B in order to be able to process the incoming responses. In order > to do so, A buffers messages before it sends them to B. In the same > time B sends its data messages (i.e. new Requests) asynchronously on > the same connection from B to A. As a result, the connection gets > throttled by new Requests while the old Requests (from A to B) > haven't been acknowledged yet. Provided A and B do not use common > throttling mechanism and/or have different processing power this > situation requires careful tuning (e.g. configuration or negotiation= ) > by each side. It seems to me that using chunking to cut down on message size, and the=20 removal of the transaction timer will help this issue quite a lot. Functional Overview: > Detection of TCP connection failure earlier than reported by TCP > itself: >=20 > o This can be useful if TCP connection shows a property of > unreasonably long (e.g. up to 9 minutes) TCP retry procedures. Th= e > reason for this pattern would be either improperly tuned TCP > configuration or/and transport layer intermediates (potentially > deployed for security or monitoring) that actively intervene the > TCP connection and, as a result, change its properties The 9 minute figure you have heard Adam and I throw out is _not_ the TCP=20 retransmission timer value . Rather, it is roughly the total time that=20 a TCP stack using default configurations is likely to continue=20 retransmission/backoff cycles before it gives up and tells the=20 application it has a problem. This is _not_ due to misconfiguration;=20 rather, it is the behavior using the _default_ configuration. Not all=20 implementations let you change this at all. I think Windows does, but at=20 a whole interface scope. > o Unfortunately, using the MSRP timer with shorter than TCP timeout > will increase the probability of message duplications as describe= d > in the next section See previous comments on the transaction timer. > o It=92s possible that an MSRP timer of the relay has expired or a > local TCP connection failure has been detected by the relay when > there are still locally unprocessed positive acknowledgments from > the next hop in the TCP pipe. These acknowledgements can be to th= e > messages that had been already forwarded by the next hop and > eventually got delivered to the destination Yes, I acknowledge this as true. (It is true of just about any protocol=20 I have ever seen.) > o Note that as shorter the local MSRP timer is, as more frequently > the scenario above can occur > o Note also that the scenario above can theoretically happen to any > or all of the relays for the same message. This will result in a > flood of error reports towards the message originator even in the > case of successful message delivery to its final destination Theoretically, yes. But in practice, rarely, as having multiple hops=20 along the way _each_ decide that a transaction had failed when it in=20 fact had succeeded is very unlikely. MSRP Abstraction: > As shown above, the defined hop-by-hop mechanism is incapable of > addressing most of the basic IM applications requirements when more > than a single hop is involved. >=20 You showed _one_ potential requirement it does not address by itself.=20 That is hardly "most". > As a result of the two statements above, this paper argues that the > end-to-end mechanism MUST be specified in the basic MSRP > specification: >=20 I believe we have already agreed that the base spec will describe=20 endpoint processing of DSN, to the degree that a non-relay aware=20 endpoint needs to understand to interwork with an endpoint that uses rela= ys. >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Review of MSRP Delivery Mechanisms > Author(s) : O. Levin > Filename : draft-levin-simple-msrp-review-00.txt > Pages : 16 > Date : 2004-4-6 > =20 > This paper shows that the currently defined per-message hop-by-hop > mechanism doesn=92t scale for large deployments and is not feasible = for > scalable IM conferencing. Instead, the paper proposes to replace thi= s > mechanism with an MSRP layer "per TCP connection keep-alive > mechanism". This paper also reinforces the need for the end-to-end > mechanism to be defined in the core MSRP specification and to become > the abstraction for all MSRP applications regardless the underlying > topology in use. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-levin-simple-msrp-review-00.t= xt >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 8 21:05:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18317 for ; Thu, 8 Apr 2004 21:05:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkS5-0001NI-Fk for simple-archive@odin.ietf.org; Thu, 08 Apr 2004 21:05:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39151Iw005279 for simple-archive@odin.ietf.org; Thu, 8 Apr 2004 21:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkS4-0001Mx-VN for simple-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:05:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18189 for ; Thu, 8 Apr 2004 21:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkS1-0007jR-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 21:04:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkD0-0005Hx-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 20:49:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjpk-0002YY-00; Thu, 08 Apr 2004 20:25:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjpd-0002kK-99; Thu, 08 Apr 2004 20:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiuk-0005Tx-B0 for simple@optimus.ietf.org; Thu, 08 Apr 2004 19:26:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08147 for ; Thu, 8 Apr 2004 19:26:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiui-0004W7-00 for simple@ietf.org; Thu, 08 Apr 2004 19:26:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhnZ-0003sN-00 for simple@ietf.org; Thu, 08 Apr 2004 18:15:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfpU-00039v-00 for simple@ietf.org; Thu, 08 Apr 2004 16:08:52 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBfWr-00064a-Kj for simple@ietf.org; Thu, 08 Apr 2004 15:49:37 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i38JnPIx025575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2004 14:49:26 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4075ACB9.9080408@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Simple WG Subject: Re: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by magus.nostrum.com id i38JnPIx025575 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Apr 2004 14:49:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, thanks for sending this. I do have some comments and questions. This=20 email is strictly in response to your draft. I will send general=20 comments about MSRP with and without transaction responses in a separate=20 email. The big ones first: You make a number of assertions of normative behavior for relays.=20 Considering that we do not have an MSRP relay draft yet, these=20 assertions are a bit overstated. The recent discussions, both on and off=20 the list, involved making some assumtions about how relays work, based=20 on the SIMS draft. The reason for these assumptions was to determine=20 what changes needed to be made to the MSRP base spec to minimally enable=20 relay integration. Second, you use a SIP transaction model to prove the impact of=20 transaction responses. I need to think that through better, but my first=20 inclination is to say that it is not a good comparison to MSRP. This is=20 because the SIP transaction model is much more complex and timing=20 sensitive than anything currently proposed for MSRP. Further, the MSRP=20 syntax is (hopefully) lighter weight, and easier to parse. Therefore, I=20 think that, if you had done this test using an MSRP device, and kept the=20 other factors the same, the difference in performance between running=20 with and without responses would be smaller than that for a SIP device. Further, if I understand your data correctly, with the SIP device you=20 see a difference in performance of around %20. Is this correct? If so, I=20 do not find that to be highly convincing by itself. If we were talking=20 about order-of-magnitude differences, I would be more convinced. Of=20 course, if we end up accepting your other assertions that the=20 transaction response brings no value, then a %20 change might be worthwhi= le. And now, some specific comments: > The hop-by-hop mechanism (sometimes referred to as the "ACCEPT" > mechanism) is modeled after the SIP transaction model.=20 We used the term "ACCEPT" in off line discussions as an abstraction to=20 talk about transaction responses. I think in this draft, it would be=20 less confusing to use the terminology from the MSRP draft. Perhaps=20 "transaction response" would be more clear. > (Negative responses are also defined but they are applicable only for > deployments with no relays in the network.) There has not been any agreement to that effect that I am aware of. We=20 had a side conversation that we might want to get rid of negative=20 transaction responses for relays, but no wg consensus. I personally do=20 not like the idea of having a different set of allowed transaction=20 responses depending on whether relays are present. > The negative "end-to-end" mechanism is mandatory for relays for error > reporting when connectivity problem is detected. In this context the > mechanism is interchangeably referred to as "DSR" or "DSN". Relays > MUST NOT use the end-to end mechanism for reporting positive > acknowledgements. DSN would not necessarily be end-to-end, since, as you mention, relays=20 might generate them. Also, I accidentally introduced the acronym DSR due=20 to some email typos. I think we can drop it. > When an MSRP entity A (a user agent or a relay) sends/forwards a > message, it creates the message transaction state and starts a timer > (~30 sec).=20 Adam suggested that we don't really need a mandatory timer here. He=20 proposed that we say that a device MAY create a timer, and the value=20 would be local policy. If a device(endpoint or relay) does _not_ create=20 a timer, it would merely keep a record of the transaction until it got a=20 transaction response, at which time it could completely forget about it.=20 If a TCP error is encounted, it would then need to either send DSN(s)=20 for any outstanding transactions (if a relay), or inform the user (if=20 and endpoint.) I believe that removing the mandatory timer will make it=20 possible for a relay to greatly reduce the transaction overhead. The=20 only advantage in keeping such a timer is it could allow a device to=20 detect a problem faster than TCP will by itself. This would come at the=20 expense of more false failure notifications. > If there is an > immediate problem in the local handling of this message by B, the > MSRP entity (B) MUST generate an error report and send it all the wa= y > back to the originator (i.e. the original source) of the message > using the end-to-end mechanism described below. I don't think we have consensus on that point. This goes back to the=20 point about negative transaction responses. If the failure is immediate,=20 B could have just sent a negative transaction response. The DSN is=20 needed for failures that require too much time to detect to block the=20 sending of the transaction response. > In both cases, the > error reports must include a list the messages per originator that > haven=92t been acknowledged by the next hop. We still need to do work to determine whether a DSN can include a list=20 of failed messages, or we have a separate DSN per message. > o In addition, if as a result of the SDP negotiation, a user agent > agreed to provide an application layer positive and/or negative > report/receipt per message, the user agent MUST create the report > and send it back to the message originator in the same manner as > described above (i.e. inside the existing MSRP connection) I am confused by this paragraph. The section so far talked about how you=20 send DSN. This paragraph seems to say "And if you agreed to do so, you=20 also have to send DSN. How is this not redundant?" > The following known issues still need to be addressed by the MSRP > specification: >=20 > o Relationship between the MSRP end-to-end procedures and the > "application above the user agent" end-to-end procedures Our current expectation is the primary use of DSN would be to present=20 the information to the user, who then does whatever he or she chooses. I=20 expect it to be machine parseable, but do not expect to define any=20 normative behavior from the application beyond telling the user. > o The exact end-to-end operation modes and their negotiation using > the offer-answer SDP mechanism That work is currently in progress. (In fact, Chris Boulon just proposed=20 some text to me on DSN in general--Yeah Chris!!) In the past, though, you have suggested per-message negotiation, rather=20 than SDP based, i.e. per-session, negotiation. Are you saying you would=20 now prefer per-session? > o The exact format of the reports (both negative and positive) In progress. > o A mechanism needs to be defined so that all outstanding end-to-en= d > reports (i.e. belonging to sessions ended earlier by user agents) > are silently discarded by the system The next MSRP draft will call out an open issue on whether DSN can be=20 delivered after a session ends. > o A mechanism needs to be defined so that NO end-to-end status > reports will be generated about delivery of earlier end-to-end > status reports In progress. > o It is unclear why the status report messages need to be > acknowledged hop-by-hop (as per current design) because they MUST > not be included in the status reports (as stated above) It is a matter of balancing the complexity of having two different=20 transaction models with the cost of having a transaction model that=20 works well for the primary usage (sending IMs) but is less optimal for a=20 secondary usage (sending DSN, or other status reports.) Scalability analysis: > The most trivial consequence of the defined "hop-by-hop" mechanism i= s > the need to keep per message a state object (including a timer) and > to clear it upon receiving an acknowledgement for the message. >=20 As I mentioned above, we have a proposal to remove the requirement to=20 keep a timer. This should have a significant affect on the overall impact. > In order to fully realize the impact of this design on an IM system, > we need to translate it to numbers. For example, as of today, a > typical public IM service would have 150MM subscribed users with a > peak of 10MM simultaneous users. >=20 > Consequently, in order to compare the cost of such IM solution to > "less statefull" IM architectures, every additional bit of memory an= d > CPU processing power required for keeping the state per "message > transaction" need to be multiplied at least (since message > transactions can be overlapped) by 10MM. I'm confused. Are you saying that, if I have 10 million (I assume you=20 mean MM to represent a million.) concurrently logged in users, I have 10=20 million MSRP transactions in play at any moment? I would assume not all=20 active users are in a session at any moment, and not all that _are_ in a=20 session have an open transaction at any moment. Am I misunderastanding=20 your point? > It is interesting to mention that even modern TCP implementations > have moved away from acknowledging every TCP segment and today > acknowledge every second segment only=85 >=20 While I don't find TCP's ack rate to be particularly relevent to the=20 discussion, I believe that most implementations send _"at least that=20 often", which is very different than "no more often than". >=20 > One of the concerns with the suggested hop-by-hop mechanism is that > although the mechanism is very simple, it suffers from some of the > known TCP problems but, unlike TCP, doesn=92t address them. > Unfortunately, the current working assumption that the > "congestion-safe" TCP will automatically make the MSRP > congestion-safe is inaccurate. I think the point of congestion-safety, is the presence of MSRP on the=20 network should not interfere with the use of _other_ applications. It is=20 not the same as saying an MSRP relay cannot itself get congested. > Because each message will be acknowledged (by Response) by B > automatically, A needs to control the rate of the messages it sends > to B in order to be able to process the incoming responses. In order > to do so, A buffers messages before it sends them to B. In the same > time B sends its data messages (i.e. new Requests) asynchronously on > the same connection from B to A. As a result, the connection gets > throttled by new Requests while the old Requests (from A to B) > haven't been acknowledged yet. Provided A and B do not use common > throttling mechanism and/or have different processing power this > situation requires careful tuning (e.g. configuration or negotiation= ) > by each side. It seems to me that using chunking to cut down on message size, and the=20 removal of the transaction timer will help this issue quite a lot. Functional Overview: > Detection of TCP connection failure earlier than reported by TCP > itself: >=20 > o This can be useful if TCP connection shows a property of > unreasonably long (e.g. up to 9 minutes) TCP retry procedures. Th= e > reason for this pattern would be either improperly tuned TCP > configuration or/and transport layer intermediates (potentially > deployed for security or monitoring) that actively intervene the > TCP connection and, as a result, change its properties The 9 minute figure you have heard Adam and I throw out is _not_ the TCP=20 retransmission timer value . Rather, it is roughly the total time that=20 a TCP stack using default configurations is likely to continue=20 retransmission/backoff cycles before it gives up and tells the=20 application it has a problem. This is _not_ due to misconfiguration;=20 rather, it is the behavior using the _default_ configuration. Not all=20 implementations let you change this at all. I think Windows does, but at=20 a whole interface scope. > o Unfortunately, using the MSRP timer with shorter than TCP timeout > will increase the probability of message duplications as describe= d > in the next section See previous comments on the transaction timer. > o It=92s possible that an MSRP timer of the relay has expired or a > local TCP connection failure has been detected by the relay when > there are still locally unprocessed positive acknowledgments from > the next hop in the TCP pipe. These acknowledgements can be to th= e > messages that had been already forwarded by the next hop and > eventually got delivered to the destination Yes, I acknowledge this as true. (It is true of just about any protocol=20 I have ever seen.) > o Note that as shorter the local MSRP timer is, as more frequently > the scenario above can occur > o Note also that the scenario above can theoretically happen to any > or all of the relays for the same message. This will result in a > flood of error reports towards the message originator even in the > case of successful message delivery to its final destination Theoretically, yes. But in practice, rarely, as having multiple hops=20 along the way _each_ decide that a transaction had failed when it in=20 fact had succeeded is very unlikely. MSRP Abstraction: > As shown above, the defined hop-by-hop mechanism is incapable of > addressing most of the basic IM applications requirements when more > than a single hop is involved. >=20 You showed _one_ potential requirement it does not address by itself.=20 That is hardly "most". > As a result of the two statements above, this paper argues that the > end-to-end mechanism MUST be specified in the basic MSRP > specification: >=20 I believe we have already agreed that the base spec will describe=20 endpoint processing of DSN, to the degree that a non-relay aware=20 endpoint needs to understand to interwork with an endpoint that uses rela= ys. >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Review of MSRP Delivery Mechanisms > Author(s) : O. Levin > Filename : draft-levin-simple-msrp-review-00.txt > Pages : 16 > Date : 2004-4-6 > =20 > This paper shows that the currently defined per-message hop-by-hop > mechanism doesn=92t scale for large deployments and is not feasible = for > scalable IM conferencing. Instead, the paper proposes to replace thi= s > mechanism with an MSRP layer "per TCP connection keep-alive > mechanism". This paper also reinforces the need for the end-to-end > mechanism to be defined in the core MSRP specification and to become > the abstraction for all MSRP applications regardless the underlying > topology in use. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-levin-simple-msrp-review-00.t= xt >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 8 21:16:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19770 for ; Thu, 8 Apr 2004 21:16:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkdP-0000rr-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 21:16:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkL7-0006yS-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 20:57:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBk7N-0004PD-00; Thu, 08 Apr 2004 20:43:37 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBjti-0005I5-Je; Thu, 08 Apr 2004 20:29:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjtK-00053r-1a; Thu, 08 Apr 2004 20:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjQP-0000VO-0P for simple@optimus.ietf.org; Thu, 08 Apr 2004 19:59:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12396 for ; Thu, 8 Apr 2004 19:59:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjQM-0007m9-00 for simple@ietf.org; Thu, 08 Apr 2004 19:59:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiUE-00018a-00 for simple@ietf.org; Thu, 08 Apr 2004 18:59:10 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BBgqK-0004Q8-00 for simple@ietf.org; Thu, 08 Apr 2004 17:13:48 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i38LDgIx032445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Apr 2004 16:13:43 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4075C07A.4090505@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP message reliability(long) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Apr 2004 16:13:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hopefully, everyone has had a chance to look at Orit's draft giving an analysis and some recommendations concerning the way MSRP handles message acknowledgements. I responded separately with specific comments about that draft. However, I want to talk in general about the models that have been proposed, as I understand them. First, I would like to clarify the reliability requirements, as I see them, a little. As I see it, when I send a message, there are three levels of reliability that I might care about. Consider the following scenarios: 1) I really don't care at all. (Strangely, this is the mode used by a lot of existing large scale systems. If we are dealing with highly interactive conversations between humans, humans provide their own reliability mechanism. I find myself typing "Hey, did you get my IM about X a few minutes ago" frequently.) 2) I want a good effort to deliver, and a good attempt to tell me if something went wrong. If I hear nothing, I assume it most likely worked. 3) Delivery is critical. I want to be told that it worked, and if I don't hear anything, I assume it most likely failed. My personal opinion is that 1 is generally unacceptable (dispite current systems), 3 should be an option, but 2 will be the primary use case, and the one we should optimize for. The rest of this email takes that perspective; if consensus proves me wrong then my analysis will change. We have a controversy about whether MSRP, in the general case where relays exist, should use per-hop transaction acknowledgements, or whether acknowledgments should be strictly end-to-end. First, let us consider the success cases; that is, when everything works. The per-hop case looks something like the following: A R1 R2 B SEND------> <--------OK SEND------> <--------OK SEND------> <--------OK This is not-optimal for the happy case, because each device has to keep transaction state until it gets a response. This state is _only_ useful if a failure occurs. (We will look at failure cases in a minute.) However, this state is not huge. As currently defined in MSRP, it would be the transaction identity and a timer. Adam proposed we do not need a mandatory timer, which would make it even smaller. In a perfect world, the end-to-end approach would look like: A R1 R2 B SEND------> SEND------> SEND------> This looks great on the surface. Not only can the relays be transaction stateless, only half as many messages happen. But, for reasons I will explain in a moment, this approach makes it impractical to tell A if something goes wrong downstream. Therefore, in a realistic implementation, it looks more like: A R1 R2 B SEND------> SEND------> SEND------> <---DSN(success) <-------DSN <-------DSN This has the same number of messages. It does allow the relays to be stateless. So, now, lets assume a TCP failure happens between R1 and R2. The hop-hop case looks like the following. A gets a failure notification shortly after R1 notices the failure. A R1 R2 B SEND------> <--------OK SEND----X <----DSN(fail) One would hope to make the end-to-end case look similar. But, as I mentioned before, that is impractical. Assume R1 has had a TCP connection to R2 up for some time. R1 has sent a lot of messages in that time, including the one for A above. With hop-hop responses, R1 keeps state around for each message it relays, and destroys that state when it gets an OK response. When the TCP failure occurs, R1 sends failure reports for all messages for which it still has state. But in the end-end case, R1 cannot report the failure. (We said R1 would keep no state for end-to-end, remember.) But even if it _did_ keep state, it would have no good way to know where in the message stream the error occured. Unless it does something _extremely_ stateful, like watch for success DSNs to go by, then when a TCP error occurs, it must assume that every message it has every relayed on that connection failed, or at least every message sent for the past 9 minutes or so failed. (9 minutes being the normal time requried for the _application_ to learn of some TCP failures.) Since 9 minutes is an eternity for a busy relay, I assume this is not acceptable. Rather, the relay would report nothing. The flow would look like the following: A R1 R2 B SEND------> SEND---X A would eventually figure out the message failure due to the lack of a success report. A would have to wait some time before making this decision to avoid a high likelyhood of false positives. Using the 9 minute failure detection time above, this time would be something like (9*number of hops * 2) minutes. So, back to our scenarios. For scenario 1, the end-end approach clearly wins, assuming we have the option to turn off DSN entirely. Orit's draft suggested that, with all responses turned off, a relay would have about a %20 scale advantage. However, her experiment was based on SIP messages, which tend to be larger, more complicated to parse, and have a more complex transaction model, even over TCP. I have no way of knowing how much the SIP vs MSRP aspect will impact things, but I think it is safe to say that the savings for MSRP will be real, but less than the %20 savings she observed for SIP. For scenario 2, it is a harder call. The number of messages is the same for either approach. The work to do message parsing, etc is similar. Relays will have to keep state for the hop-hop approach, although if we accept Adam's proposal about removing transaction timers, this state is fairly small. Also, the time it requires for the sender to learn about the failure is considerably shorter for the hop-hop approach than for the end-end approach. Therefore, I personally think the hop-hop approach wins this one. For scenario 3, an end-end receipt will be required anytime relays are present. This means the hop-hop approach will require more messages than the end-end, giving the round to the end-end. So, considering that I believe 2 is the primary use case, I lean towards the hop-hop case. I would also like to address a few arguments that I have heard, and believe to be red herrings: 1) A failure report cannot be interpreted with certainty to mean that a message was not delivered. There are a number of edge cases where you can successfully deliver a message, but report it failed. However, this is _also_ true with the end-end case; as it is possible for the success report itself to get lost. We can build a system that never claims success unless it was really successful, but we cannot build a system that never claims failure unless it really failed. 2) Since the TCP connections are used in both directions, responses may backup behind IMs sent in the reverse direction. This has been an acknowledged problem with the use of full-duplex connections from the beginning. But the problem exists for the end-end case as well, as success reports can _also_ get stuck in traffic. We are taking steps in MSRP (chunking, possible removal of transaction timers) that I think will mitigate this somewhat. Conclusions: I personally prefer the hop-hop approach, with DSN on failure and DSN on success as optional. However, if I am in the minority on that point, I can live with the end to end model. I do, however, want the transaction model to be consistent. That is, I don't want to negotiate whether we send hop-hop transaction responses to SEND requests. Either MSRP calls for them, or it does not. Further, the VISIT request, and I assume BIND or whatever equivelant we come up with in the relay work, necessarily follow a hop-hop model. Making SEND end-end creates an inconsistency there. If we do decide to change (back) to e2e SEND requests, the impact on the base spec is not huge; it would involve taking away the transaction response to SEND, and putting in a stronger dependency on DSN. There would be more impact on the relay spec. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 8 21:17:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19871 for ; Thu, 8 Apr 2004 21:17:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkdT-0003LT-Sy for simple-archive@odin.ietf.org; Thu, 08 Apr 2004 21:16:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391GlLD012855 for simple-archive@odin.ietf.org; Thu, 8 Apr 2004 21:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkdT-0003LG-OD for simple-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:16:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19789 for ; Thu, 8 Apr 2004 21:16:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkdQ-0000s3-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 21:16:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkL9-0006yq-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 20:57:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBk7N-0004PD-00; Thu, 08 Apr 2004 20:43:37 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBjti-0005I5-Je; Thu, 08 Apr 2004 20:29:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjtK-00053r-1a; Thu, 08 Apr 2004 20:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjQP-0000VO-0P for simple@optimus.ietf.org; Thu, 08 Apr 2004 19:59:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12396 for ; Thu, 8 Apr 2004 19:59:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjQM-0007m9-00 for simple@ietf.org; Thu, 08 Apr 2004 19:59:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiUE-00018a-00 for simple@ietf.org; Thu, 08 Apr 2004 18:59:10 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BBgqK-0004Q8-00 for simple@ietf.org; Thu, 08 Apr 2004 17:13:48 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i38LDgIx032445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Apr 2004 16:13:43 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4075C07A.4090505@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP message reliability(long) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Apr 2004 16:13:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hopefully, everyone has had a chance to look at Orit's draft giving an analysis and some recommendations concerning the way MSRP handles message acknowledgements. I responded separately with specific comments about that draft. However, I want to talk in general about the models that have been proposed, as I understand them. First, I would like to clarify the reliability requirements, as I see them, a little. As I see it, when I send a message, there are three levels of reliability that I might care about. Consider the following scenarios: 1) I really don't care at all. (Strangely, this is the mode used by a lot of existing large scale systems. If we are dealing with highly interactive conversations between humans, humans provide their own reliability mechanism. I find myself typing "Hey, did you get my IM about X a few minutes ago" frequently.) 2) I want a good effort to deliver, and a good attempt to tell me if something went wrong. If I hear nothing, I assume it most likely worked. 3) Delivery is critical. I want to be told that it worked, and if I don't hear anything, I assume it most likely failed. My personal opinion is that 1 is generally unacceptable (dispite current systems), 3 should be an option, but 2 will be the primary use case, and the one we should optimize for. The rest of this email takes that perspective; if consensus proves me wrong then my analysis will change. We have a controversy about whether MSRP, in the general case where relays exist, should use per-hop transaction acknowledgements, or whether acknowledgments should be strictly end-to-end. First, let us consider the success cases; that is, when everything works. The per-hop case looks something like the following: A R1 R2 B SEND------> <--------OK SEND------> <--------OK SEND------> <--------OK This is not-optimal for the happy case, because each device has to keep transaction state until it gets a response. This state is _only_ useful if a failure occurs. (We will look at failure cases in a minute.) However, this state is not huge. As currently defined in MSRP, it would be the transaction identity and a timer. Adam proposed we do not need a mandatory timer, which would make it even smaller. In a perfect world, the end-to-end approach would look like: A R1 R2 B SEND------> SEND------> SEND------> This looks great on the surface. Not only can the relays be transaction stateless, only half as many messages happen. But, for reasons I will explain in a moment, this approach makes it impractical to tell A if something goes wrong downstream. Therefore, in a realistic implementation, it looks more like: A R1 R2 B SEND------> SEND------> SEND------> <---DSN(success) <-------DSN <-------DSN This has the same number of messages. It does allow the relays to be stateless. So, now, lets assume a TCP failure happens between R1 and R2. The hop-hop case looks like the following. A gets a failure notification shortly after R1 notices the failure. A R1 R2 B SEND------> <--------OK SEND----X <----DSN(fail) One would hope to make the end-to-end case look similar. But, as I mentioned before, that is impractical. Assume R1 has had a TCP connection to R2 up for some time. R1 has sent a lot of messages in that time, including the one for A above. With hop-hop responses, R1 keeps state around for each message it relays, and destroys that state when it gets an OK response. When the TCP failure occurs, R1 sends failure reports for all messages for which it still has state. But in the end-end case, R1 cannot report the failure. (We said R1 would keep no state for end-to-end, remember.) But even if it _did_ keep state, it would have no good way to know where in the message stream the error occured. Unless it does something _extremely_ stateful, like watch for success DSNs to go by, then when a TCP error occurs, it must assume that every message it has every relayed on that connection failed, or at least every message sent for the past 9 minutes or so failed. (9 minutes being the normal time requried for the _application_ to learn of some TCP failures.) Since 9 minutes is an eternity for a busy relay, I assume this is not acceptable. Rather, the relay would report nothing. The flow would look like the following: A R1 R2 B SEND------> SEND---X A would eventually figure out the message failure due to the lack of a success report. A would have to wait some time before making this decision to avoid a high likelyhood of false positives. Using the 9 minute failure detection time above, this time would be something like (9*number of hops * 2) minutes. So, back to our scenarios. For scenario 1, the end-end approach clearly wins, assuming we have the option to turn off DSN entirely. Orit's draft suggested that, with all responses turned off, a relay would have about a %20 scale advantage. However, her experiment was based on SIP messages, which tend to be larger, more complicated to parse, and have a more complex transaction model, even over TCP. I have no way of knowing how much the SIP vs MSRP aspect will impact things, but I think it is safe to say that the savings for MSRP will be real, but less than the %20 savings she observed for SIP. For scenario 2, it is a harder call. The number of messages is the same for either approach. The work to do message parsing, etc is similar. Relays will have to keep state for the hop-hop approach, although if we accept Adam's proposal about removing transaction timers, this state is fairly small. Also, the time it requires for the sender to learn about the failure is considerably shorter for the hop-hop approach than for the end-end approach. Therefore, I personally think the hop-hop approach wins this one. For scenario 3, an end-end receipt will be required anytime relays are present. This means the hop-hop approach will require more messages than the end-end, giving the round to the end-end. So, considering that I believe 2 is the primary use case, I lean towards the hop-hop case. I would also like to address a few arguments that I have heard, and believe to be red herrings: 1) A failure report cannot be interpreted with certainty to mean that a message was not delivered. There are a number of edge cases where you can successfully deliver a message, but report it failed. However, this is _also_ true with the end-end case; as it is possible for the success report itself to get lost. We can build a system that never claims success unless it was really successful, but we cannot build a system that never claims failure unless it really failed. 2) Since the TCP connections are used in both directions, responses may backup behind IMs sent in the reverse direction. This has been an acknowledged problem with the use of full-duplex connections from the beginning. But the problem exists for the end-end case as well, as success reports can _also_ get stuck in traffic. We are taking steps in MSRP (chunking, possible removal of transaction timers) that I think will mitigate this somewhat. Conclusions: I personally prefer the hop-hop approach, with DSN on failure and DSN on success as optional. However, if I am in the minority on that point, I can live with the end to end model. I do, however, want the transaction model to be consistent. That is, I don't want to negotiate whether we send hop-hop transaction responses to SEND requests. Either MSRP calls for them, or it does not. Further, the VISIT request, and I assume BIND or whatever equivelant we come up with in the relay work, necessarily follow a hop-hop model. Making SEND end-end creates an inconsistency there. If we do decide to change (back) to e2e SEND requests, the impact on the base spec is not huge; it would involve taking away the transaction response to SEND, and putting in a stronger dependency on DSN. There would be more impact on the relay spec. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 8 22:07:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22407 for ; Thu, 8 Apr 2004 22:07:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlQy-0004VJ-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 22:07:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlNW-0004Ek-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 22:04:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBlJR-0003vP-00; Thu, 08 Apr 2004 22:00:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlJJ-0007Jh-7t; Thu, 08 Apr 2004 22:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlIK-0007GL-Im for simple@optimus.ietf.org; Thu, 08 Apr 2004 21:59:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22098 for ; Thu, 8 Apr 2004 21:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlIG-0003sT-00 for simple@ietf.org; Thu, 08 Apr 2004 21:58:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlEP-0003bK-00 for simple@ietf.org; Thu, 08 Apr 2004 21:54:59 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BBl8i-0003E3-00 for simple@ietf.org; Thu, 08 Apr 2004 21:49:04 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 18:48:49 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 8 Apr 2004 18:48:35 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Apr 2004 18:48:28 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 18:48:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Message-ID: Thread-Topic: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Thread-Index: AcQdoqiqomGwOdJ0RcmI5CD2fA+NfQAIomrQ From: "Orit Levin" To: "Ben Campbell" Cc: "Simple WG" X-OriginalArrivalTime: 09 Apr 2004 01:48:33.0922 (UTC) FILETIME=[C470DE20:01C41DD4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 18:48:42 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ben, Thank you very much for commenting on the draft in details. I hope that the whole joined effort will help to keep the MSRP efforts focused and a successful protocol being defined and widely used. First, the two main points: 1. "I believe we have already agreed that the base spec will describe endpoint processing of DSN, to the degree that a non-relay aware endpoint needs to understand to interwork with an endpoint that uses relays." Excellent! Do we also agree that DSN contains at least the two primitives: "send-and-forget" and "send-with-receipt: negative or positive". Optionally also "send-negative-receipt-if possible", but I am less sure about this one. 2. As we discussed in our previous conversations, just making the timer optional will still require each entity to send the response per message (50% gain only). Also, this way we blindly apply the loose local policy to all the MSRP messages in the route. As we discussed earlier, a more flexible solution would be marking the messages with "respond"/"don't respond" bit being set by end-users and inspected by the relays/user agents as they forward the message anyway (to the next hop or to the applications). The other option would be the strict "single-hop" mechanism per TCP connection being proposed in the draft. (BTW The suggested value of the timer ~10 sec is a very poor choice (my fault) and the value will depend on topology requirements.) =20 I am leaving for a 10 days vacation this evening, so I apologize for the brief reply inline below... Orit. -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 Sent: Thursday, April 08, 2004 12:49 PM To: Orit Levin Cc: Simple WG Subject: Re: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Hi, thanks for sending this. I do have some comments and questions. This email is strictly in response to your draft. I will send general comments about MSRP with and without transaction responses in a separate email. The big ones first: You make a number of assertions of normative behavior for relays.=20 Considering that we do not have an MSRP relay draft yet, these assertions are a bit overstated. The recent discussions, both on and off the list, involved making some assumtions about how relays work, based on the SIMS draft. The reason for these assumptions was to determine what changes needed to be made to the MSRP base spec to minimally enable relay integration. OL: True. I summarized the current assumptions because I haven't seen them summarized anywhere else (beyond separate e-mails) to explain where my concerns and suggestions are coming from. Second, you use a SIP transaction model to prove the impact of transaction responses. I need to think that through better, but my first inclination is to say that it is not a good comparison to MSRP. This is because the SIP transaction model is much more complex and timing sensitive than anything currently proposed for MSRP. Further, the MSRP syntax is (hopefully) lighter weight, and easier to parse. Therefore, I think that, if you had done this test using an MSRP device, and kept the other factors the same, the difference in performance between running with and without responses would be smaller than that for a SIP device. OL: I hope that MSRP is lighter in general but not necessarily in %%. Further, if I understand your data correctly, with the SIP device you see a difference in performance of around %20. Is this correct? If so, I do not find that to be highly convincing by itself. If we were talking about order-of-magnitude differences, I would be more convinced. Of course, if we end up accepting your other assertions that the transaction response brings no value, then a %20 change might be worthwhile. OL: It is convincing to BIG deployments. It may be less crucial for enterprises. And now, some specific comments: > The hop-by-hop mechanism (sometimes referred to as the "ACCEPT" > mechanism) is modeled after the SIP transaction model.=20 We used the term "ACCEPT" in off line discussions as an abstraction to talk about transaction responses. I think in this draft, it would be less confusing to use the terminology from the MSRP draft. Perhaps "transaction response" would be more clear. OL: Sure. > (Negative responses are also defined but they are applicable only for > deployments with no relays in the network.) There has not been any agreement to that effect that I am aware of. We had a side conversation that we might want to get rid of negative transaction responses for relays, but no wg consensus. I personally do not like the idea of having a different set of allowed transaction responses depending on whether relays are present. OL: I don't like the different sets either. The point that I found disturbing was that the negative responses are useless when received by relays. > The negative "end-to-end" mechanism is mandatory for relays for error > reporting when connectivity problem is detected. In this context the > mechanism is interchangeably referred to as "DSR" or "DSN". Relays > MUST NOT use the end-to end mechanism for reporting positive > acknowledgements. DSN would not necessarily be end-to-end, since, as you mention, relays might generate them. Also, I accidentally introduced the acronym DSR due to some email typos. I think we can drop it. OL: No problem. That is why I used "". Still, currently these are the same messages. > When an MSRP entity A (a user agent or a relay) sends/forwards a > message, it creates the message transaction state and starts a timer > (~30 sec).=20 Adam suggested that we don't really need a mandatory timer here. He proposed that we say that a device MAY create a timer, and the value would be local policy. If a device(endpoint or relay) does _not_ create a timer, it would merely keep a record of the transaction until it got a transaction response, at which time it could completely forget about it. If a TCP error is encounted, it would then need to either send DSN(s) for any outstanding transactions (if a relay), or inform the user (if and endpoint.) I believe that removing the mandatory timer will make it possible for a relay to greatly reduce the transaction overhead. The only advantage in keeping such a timer is it could allow a device to detect a problem faster than TCP will by itself. This would come at the expense of more false failure notifications. OL: I commented in the beginning of this mail. > If there is an > immediate problem in the local handling of this message by B, the > MSRP entity (B) MUST generate an error report and send it all the way > back to the originator (i.e. the original source) of the message > using the end-to-end mechanism described below. I don't think we have consensus on that point. This goes back to the point about negative transaction responses. If the failure is immediate, B could have just sent a negative transaction response. The DSN is needed for failures that require too much time to detect to block the sending of the transaction response. > In both cases, the > error reports must include a list the messages per originator that > haven't been acknowledged by the next hop. We still need to do work to determine whether a DSN can include a list of failed messages, or we have a separate DSN per message. OL: Sure. I just took an assumption. > o In addition, if as a result of the SDP negotiation, a user agent > agreed to provide an application layer positive and/or negative > report/receipt per message, the user agent MUST create the report > and send it back to the message originator in the same manner as > described above (i.e. inside the existing MSRP connection) I am confused by this paragraph. The section so far talked about how you send DSN. This paragraph seems to say "And if you agreed to do so, you also have to send DSN. How is this not redundant?" OL: There are two mechanisms: one hop-by-hop (when the hop can be an end user as well) and the other is end-to-end. Currently the hop-by-hop negative responses are mandatory. If we keep the two mechanisms separate (which we should) the first will report about a failure on the low MSRP layer and stop the message processing. The second will try to report about a different error in a higher mechanism . Therefore there is no duplication here. > The following known issues still need to be addressed by the MSRP > specification: >=20 > o Relationship between the MSRP end-to-end procedures and the > "application above the user agent" end-to-end procedures Our current expectation is the primary use of DSN would be to present the information to the user, who then does whatever he or she chooses. I expect it to be machine parseable, but do not expect to define any normative behavior from the application beyond telling the user. OL: I agree with this approach. > o The exact end-to-end operation modes and their negotiation using > the offer-answer SDP mechanism That work is currently in progress. (In fact, Chris Boulon just proposed some text to me on DSN in general--Yeah Chris!!) In the past, though, you have suggested per-message negotiation, rather than SDP based, i.e. per-session, negotiation. Are you saying you would now prefer per-session? OL: My requirements are definitely per message. The point was that currently I haven't seen a definition even per session. > o The exact format of the reports (both negative and positive) In progress. > o A mechanism needs to be defined so that all outstanding end-to-end > reports (i.e. belonging to sessions ended earlier by user agents) > are silently discarded by the system The next MSRP draft will call out an open issue on whether DSN can be delivered after a session ends. > o A mechanism needs to be defined so that NO end-to-end status > reports will be generated about delivery of earlier end-to-end > status reports In progress. > o It is unclear why the status report messages need to be > acknowledged hop-by-hop (as per current design) because they MUST > not be included in the status reports (as stated above) It is a matter of balancing the complexity of having two different transaction models with the cost of having a transaction model that works well for the primary usage (sending IMs) but is less optimal for a secondary usage (sending DSN, or other status reports.) OL: As we talked before, the bit "response/don't response" per message will provide a solution to this problem as well. Scalability analysis: > The most trivial consequence of the defined "hop-by-hop" mechanism is > the need to keep per message a state object (including a timer) and > to clear it upon receiving an acknowledgement for the message. >=20 As I mentioned above, we have a proposal to remove the requirement to keep a timer. This should have a significant affect on the overall impact. > In order to fully realize the impact of this design on an IM system, > we need to translate it to numbers. For example, as of today, a > typical public IM service would have 150MM subscribed users with a > peak of 10MM simultaneous users. >=20 > Consequently, in order to compare the cost of such IM solution to > "less statefull" IM architectures, every additional bit of memory and > CPU processing power required for keeping the state per "message > transaction" need to be multiplied at least (since message > transactions can be overlapped) by 10MM. I'm confused. Are you saying that, if I have 10 million (I assume you mean MM to represent a million.) concurrently logged in users, I have 10 million MSRP transactions in play at any moment? I would assume not all active users are in a session at any moment, and not all that _are_ in a session have an open transaction at any moment. Am I misunderastanding your point? OL: Yes. It is a simplistic example, but each user can simultaneously have many open IM sessions with a number of outstanding messages on each. So at the overage it can be one IM message for an active user at a time. > It is interesting to mention that even modern TCP implementations > have moved away from acknowledging every TCP segment and today > acknowledge every second segment only... >=20 While I don't find TCP's ack rate to be particularly relevent to the discussion, I believe that most implementations send _"at least that often", which is very different than "no more often than". >=20 > One of the concerns with the suggested hop-by-hop mechanism is that > although the mechanism is very simple, it suffers from some of the > known TCP problems but, unlike TCP, doesn't address them. > Unfortunately, the current working assumption that the > "congestion-safe" TCP will automatically make the MSRP > congestion-safe is inaccurate. I think the point of congestion-safety, is the presence of MSRP on the network should not interfere with the use of _other_ applications. It is not the same as saying an MSRP relay cannot itself get congested. > Because each message will be acknowledged (by Response) by B > automatically, A needs to control the rate of the messages it sends > to B in order to be able to process the incoming responses. In order > to do so, A buffers messages before it sends them to B. In the same > time B sends its data messages (i.e. new Requests) asynchronously on > the same connection from B to A. As a result, the connection gets > throttled by new Requests while the old Requests (from A to B) > haven't been acknowledged yet. Provided A and B do not use common > throttling mechanism and/or have different processing power this > situation requires careful tuning (e.g. configuration or negotiation) > by each side. It seems to me that using chunking to cut down on message size, and the removal of the transaction timer will help this issue quite a lot. Functional Overview: > Detection of TCP connection failure earlier than reported by TCP > itself: >=20 > o This can be useful if TCP connection shows a property of > unreasonably long (e.g. up to 9 minutes) TCP retry procedures. The > reason for this pattern would be either improperly tuned TCP > configuration or/and transport layer intermediates (potentially > deployed for security or monitoring) that actively intervene the > TCP connection and, as a result, change its properties The 9 minute figure you have heard Adam and I throw out is _not_ the TCP retransmission timer value . Rather, it is roughly the total time that a TCP stack using default configurations is likely to continue retransmission/backoff cycles before it gives up and tells the application it has a problem. This is _not_ due to misconfiguration; rather, it is the behavior using the _default_ configuration. Not all implementations let you change this at all. I think Windows does, but at a whole interface scope. > o Unfortunately, using the MSRP timer with shorter than TCP timeout > will increase the probability of message duplications as described > in the next section See previous comments on the transaction timer. > o It's possible that an MSRP timer of the relay has expired or a > local TCP connection failure has been detected by the relay when > there are still locally unprocessed positive acknowledgments from > the next hop in the TCP pipe. These acknowledgements can be to the > messages that had been already forwarded by the next hop and > eventually got delivered to the destination Yes, I acknowledge this as true. (It is true of just about any protocol I have ever seen.) > o Note that as shorter the local MSRP timer is, as more frequently > the scenario above can occur > o Note also that the scenario above can theoretically happen to any > or all of the relays for the same message. This will result in a > flood of error reports towards the message originator even in the > case of successful message delivery to its final destination Theoretically, yes. But in practice, rarely, as having multiple hops along the way _each_ decide that a transaction had failed when it in fact had succeeded is very unlikely. MSRP Abstraction: > As shown above, the defined hop-by-hop mechanism is incapable of > addressing most of the basic IM applications requirements when more > than a single hop is involved. >=20 You showed _one_ potential requirement it does not address by itself.=20 That is hardly "most". > As a result of the two statements above, this paper argues that the > end-to-end mechanism MUST be specified in the basic MSRP > specification: >=20 I believe we have already agreed that the base spec will describe endpoint processing of DSN, to the degree that a non-relay aware endpoint needs to understand to interwork with an endpoint that uses relays. >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Review of MSRP Delivery Mechanisms > Author(s) : O. Levin > Filename : draft-levin-simple-msrp-review-00.txt > Pages : 16 > Date : 2004-4-6 > =20 > This paper shows that the currently defined per-message hop-by-hop > mechanism doesn't scale for large deployments and is not feasible for > scalable IM conferencing. Instead, the paper proposes to replace this > mechanism with an MSRP layer "per TCP connection keep-alive > mechanism". This paper also reinforces the need for the end-to-end > mechanism to be defined in the core MSRP specification and to become > the abstraction for all MSRP applications regardless the underlying > topology in use. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-levin-simple-msrp-review-00. > txt >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 8 22:08:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22470 for ; Thu, 8 Apr 2004 22:08:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlR8-0000BW-3b for simple-archive@odin.ietf.org; Thu, 08 Apr 2004 22:08:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i392863t000705 for simple-archive@odin.ietf.org; Thu, 8 Apr 2004 22:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlR7-0000BH-UT for simple-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 22:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22428 for ; Thu, 8 Apr 2004 22:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlR3-0004Vi-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 22:08:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlNZ-0004F7-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 22:04:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBlJR-0003vP-00; Thu, 08 Apr 2004 22:00:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlJJ-0007Jh-7t; Thu, 08 Apr 2004 22:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBlIK-0007GL-Im for simple@optimus.ietf.org; Thu, 08 Apr 2004 21:59:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22098 for ; Thu, 8 Apr 2004 21:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBlIG-0003sT-00 for simple@ietf.org; Thu, 08 Apr 2004 21:58:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlEP-0003bK-00 for simple@ietf.org; Thu, 08 Apr 2004 21:54:59 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BBl8i-0003E3-00 for simple@ietf.org; Thu, 08 Apr 2004 21:49:04 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 18:48:49 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 8 Apr 2004 18:48:35 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Apr 2004 18:48:28 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 18:48:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Message-ID: Thread-Topic: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Thread-Index: AcQdoqiqomGwOdJ0RcmI5CD2fA+NfQAIomrQ From: "Orit Levin" To: "Ben Campbell" Cc: "Simple WG" X-OriginalArrivalTime: 09 Apr 2004 01:48:33.0922 (UTC) FILETIME=[C470DE20:01C41DD4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 18:48:42 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ben, Thank you very much for commenting on the draft in details. I hope that the whole joined effort will help to keep the MSRP efforts focused and a successful protocol being defined and widely used. First, the two main points: 1. "I believe we have already agreed that the base spec will describe endpoint processing of DSN, to the degree that a non-relay aware endpoint needs to understand to interwork with an endpoint that uses relays." Excellent! Do we also agree that DSN contains at least the two primitives: "send-and-forget" and "send-with-receipt: negative or positive". Optionally also "send-negative-receipt-if possible", but I am less sure about this one. 2. As we discussed in our previous conversations, just making the timer optional will still require each entity to send the response per message (50% gain only). Also, this way we blindly apply the loose local policy to all the MSRP messages in the route. As we discussed earlier, a more flexible solution would be marking the messages with "respond"/"don't respond" bit being set by end-users and inspected by the relays/user agents as they forward the message anyway (to the next hop or to the applications). The other option would be the strict "single-hop" mechanism per TCP connection being proposed in the draft. (BTW The suggested value of the timer ~10 sec is a very poor choice (my fault) and the value will depend on topology requirements.) =20 I am leaving for a 10 days vacation this evening, so I apologize for the brief reply inline below... Orit. -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 Sent: Thursday, April 08, 2004 12:49 PM To: Orit Levin Cc: Simple WG Subject: Re: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Hi, thanks for sending this. I do have some comments and questions. This email is strictly in response to your draft. I will send general comments about MSRP with and without transaction responses in a separate email. The big ones first: You make a number of assertions of normative behavior for relays.=20 Considering that we do not have an MSRP relay draft yet, these assertions are a bit overstated. The recent discussions, both on and off the list, involved making some assumtions about how relays work, based on the SIMS draft. The reason for these assumptions was to determine what changes needed to be made to the MSRP base spec to minimally enable relay integration. OL: True. I summarized the current assumptions because I haven't seen them summarized anywhere else (beyond separate e-mails) to explain where my concerns and suggestions are coming from. Second, you use a SIP transaction model to prove the impact of transaction responses. I need to think that through better, but my first inclination is to say that it is not a good comparison to MSRP. This is because the SIP transaction model is much more complex and timing sensitive than anything currently proposed for MSRP. Further, the MSRP syntax is (hopefully) lighter weight, and easier to parse. Therefore, I think that, if you had done this test using an MSRP device, and kept the other factors the same, the difference in performance between running with and without responses would be smaller than that for a SIP device. OL: I hope that MSRP is lighter in general but not necessarily in %%. Further, if I understand your data correctly, with the SIP device you see a difference in performance of around %20. Is this correct? If so, I do not find that to be highly convincing by itself. If we were talking about order-of-magnitude differences, I would be more convinced. Of course, if we end up accepting your other assertions that the transaction response brings no value, then a %20 change might be worthwhile. OL: It is convincing to BIG deployments. It may be less crucial for enterprises. And now, some specific comments: > The hop-by-hop mechanism (sometimes referred to as the "ACCEPT" > mechanism) is modeled after the SIP transaction model.=20 We used the term "ACCEPT" in off line discussions as an abstraction to talk about transaction responses. I think in this draft, it would be less confusing to use the terminology from the MSRP draft. Perhaps "transaction response" would be more clear. OL: Sure. > (Negative responses are also defined but they are applicable only for > deployments with no relays in the network.) There has not been any agreement to that effect that I am aware of. We had a side conversation that we might want to get rid of negative transaction responses for relays, but no wg consensus. I personally do not like the idea of having a different set of allowed transaction responses depending on whether relays are present. OL: I don't like the different sets either. The point that I found disturbing was that the negative responses are useless when received by relays. > The negative "end-to-end" mechanism is mandatory for relays for error > reporting when connectivity problem is detected. In this context the > mechanism is interchangeably referred to as "DSR" or "DSN". Relays > MUST NOT use the end-to end mechanism for reporting positive > acknowledgements. DSN would not necessarily be end-to-end, since, as you mention, relays might generate them. Also, I accidentally introduced the acronym DSR due to some email typos. I think we can drop it. OL: No problem. That is why I used "". Still, currently these are the same messages. > When an MSRP entity A (a user agent or a relay) sends/forwards a > message, it creates the message transaction state and starts a timer > (~30 sec).=20 Adam suggested that we don't really need a mandatory timer here. He proposed that we say that a device MAY create a timer, and the value would be local policy. If a device(endpoint or relay) does _not_ create a timer, it would merely keep a record of the transaction until it got a transaction response, at which time it could completely forget about it. If a TCP error is encounted, it would then need to either send DSN(s) for any outstanding transactions (if a relay), or inform the user (if and endpoint.) I believe that removing the mandatory timer will make it possible for a relay to greatly reduce the transaction overhead. The only advantage in keeping such a timer is it could allow a device to detect a problem faster than TCP will by itself. This would come at the expense of more false failure notifications. OL: I commented in the beginning of this mail. > If there is an > immediate problem in the local handling of this message by B, the > MSRP entity (B) MUST generate an error report and send it all the way > back to the originator (i.e. the original source) of the message > using the end-to-end mechanism described below. I don't think we have consensus on that point. This goes back to the point about negative transaction responses. If the failure is immediate, B could have just sent a negative transaction response. The DSN is needed for failures that require too much time to detect to block the sending of the transaction response. > In both cases, the > error reports must include a list the messages per originator that > haven't been acknowledged by the next hop. We still need to do work to determine whether a DSN can include a list of failed messages, or we have a separate DSN per message. OL: Sure. I just took an assumption. > o In addition, if as a result of the SDP negotiation, a user agent > agreed to provide an application layer positive and/or negative > report/receipt per message, the user agent MUST create the report > and send it back to the message originator in the same manner as > described above (i.e. inside the existing MSRP connection) I am confused by this paragraph. The section so far talked about how you send DSN. This paragraph seems to say "And if you agreed to do so, you also have to send DSN. How is this not redundant?" OL: There are two mechanisms: one hop-by-hop (when the hop can be an end user as well) and the other is end-to-end. Currently the hop-by-hop negative responses are mandatory. If we keep the two mechanisms separate (which we should) the first will report about a failure on the low MSRP layer and stop the message processing. The second will try to report about a different error in a higher mechanism . Therefore there is no duplication here. > The following known issues still need to be addressed by the MSRP > specification: >=20 > o Relationship between the MSRP end-to-end procedures and the > "application above the user agent" end-to-end procedures Our current expectation is the primary use of DSN would be to present the information to the user, who then does whatever he or she chooses. I expect it to be machine parseable, but do not expect to define any normative behavior from the application beyond telling the user. OL: I agree with this approach. > o The exact end-to-end operation modes and their negotiation using > the offer-answer SDP mechanism That work is currently in progress. (In fact, Chris Boulon just proposed some text to me on DSN in general--Yeah Chris!!) In the past, though, you have suggested per-message negotiation, rather than SDP based, i.e. per-session, negotiation. Are you saying you would now prefer per-session? OL: My requirements are definitely per message. The point was that currently I haven't seen a definition even per session. > o The exact format of the reports (both negative and positive) In progress. > o A mechanism needs to be defined so that all outstanding end-to-end > reports (i.e. belonging to sessions ended earlier by user agents) > are silently discarded by the system The next MSRP draft will call out an open issue on whether DSN can be delivered after a session ends. > o A mechanism needs to be defined so that NO end-to-end status > reports will be generated about delivery of earlier end-to-end > status reports In progress. > o It is unclear why the status report messages need to be > acknowledged hop-by-hop (as per current design) because they MUST > not be included in the status reports (as stated above) It is a matter of balancing the complexity of having two different transaction models with the cost of having a transaction model that works well for the primary usage (sending IMs) but is less optimal for a secondary usage (sending DSN, or other status reports.) OL: As we talked before, the bit "response/don't response" per message will provide a solution to this problem as well. Scalability analysis: > The most trivial consequence of the defined "hop-by-hop" mechanism is > the need to keep per message a state object (including a timer) and > to clear it upon receiving an acknowledgement for the message. >=20 As I mentioned above, we have a proposal to remove the requirement to keep a timer. This should have a significant affect on the overall impact. > In order to fully realize the impact of this design on an IM system, > we need to translate it to numbers. For example, as of today, a > typical public IM service would have 150MM subscribed users with a > peak of 10MM simultaneous users. >=20 > Consequently, in order to compare the cost of such IM solution to > "less statefull" IM architectures, every additional bit of memory and > CPU processing power required for keeping the state per "message > transaction" need to be multiplied at least (since message > transactions can be overlapped) by 10MM. I'm confused. Are you saying that, if I have 10 million (I assume you mean MM to represent a million.) concurrently logged in users, I have 10 million MSRP transactions in play at any moment? I would assume not all active users are in a session at any moment, and not all that _are_ in a session have an open transaction at any moment. Am I misunderastanding your point? OL: Yes. It is a simplistic example, but each user can simultaneously have many open IM sessions with a number of outstanding messages on each. So at the overage it can be one IM message for an active user at a time. > It is interesting to mention that even modern TCP implementations > have moved away from acknowledging every TCP segment and today > acknowledge every second segment only... >=20 While I don't find TCP's ack rate to be particularly relevent to the discussion, I believe that most implementations send _"at least that often", which is very different than "no more often than". >=20 > One of the concerns with the suggested hop-by-hop mechanism is that > although the mechanism is very simple, it suffers from some of the > known TCP problems but, unlike TCP, doesn't address them. > Unfortunately, the current working assumption that the > "congestion-safe" TCP will automatically make the MSRP > congestion-safe is inaccurate. I think the point of congestion-safety, is the presence of MSRP on the network should not interfere with the use of _other_ applications. It is not the same as saying an MSRP relay cannot itself get congested. > Because each message will be acknowledged (by Response) by B > automatically, A needs to control the rate of the messages it sends > to B in order to be able to process the incoming responses. In order > to do so, A buffers messages before it sends them to B. In the same > time B sends its data messages (i.e. new Requests) asynchronously on > the same connection from B to A. As a result, the connection gets > throttled by new Requests while the old Requests (from A to B) > haven't been acknowledged yet. Provided A and B do not use common > throttling mechanism and/or have different processing power this > situation requires careful tuning (e.g. configuration or negotiation) > by each side. It seems to me that using chunking to cut down on message size, and the removal of the transaction timer will help this issue quite a lot. Functional Overview: > Detection of TCP connection failure earlier than reported by TCP > itself: >=20 > o This can be useful if TCP connection shows a property of > unreasonably long (e.g. up to 9 minutes) TCP retry procedures. The > reason for this pattern would be either improperly tuned TCP > configuration or/and transport layer intermediates (potentially > deployed for security or monitoring) that actively intervene the > TCP connection and, as a result, change its properties The 9 minute figure you have heard Adam and I throw out is _not_ the TCP retransmission timer value . Rather, it is roughly the total time that a TCP stack using default configurations is likely to continue retransmission/backoff cycles before it gives up and tells the application it has a problem. This is _not_ due to misconfiguration; rather, it is the behavior using the _default_ configuration. Not all implementations let you change this at all. I think Windows does, but at a whole interface scope. > o Unfortunately, using the MSRP timer with shorter than TCP timeout > will increase the probability of message duplications as described > in the next section See previous comments on the transaction timer. > o It's possible that an MSRP timer of the relay has expired or a > local TCP connection failure has been detected by the relay when > there are still locally unprocessed positive acknowledgments from > the next hop in the TCP pipe. These acknowledgements can be to the > messages that had been already forwarded by the next hop and > eventually got delivered to the destination Yes, I acknowledge this as true. (It is true of just about any protocol I have ever seen.) > o Note that as shorter the local MSRP timer is, as more frequently > the scenario above can occur > o Note also that the scenario above can theoretically happen to any > or all of the relays for the same message. This will result in a > flood of error reports towards the message originator even in the > case of successful message delivery to its final destination Theoretically, yes. But in practice, rarely, as having multiple hops along the way _each_ decide that a transaction had failed when it in fact had succeeded is very unlikely. MSRP Abstraction: > As shown above, the defined hop-by-hop mechanism is incapable of > addressing most of the basic IM applications requirements when more > than a single hop is involved. >=20 You showed _one_ potential requirement it does not address by itself.=20 That is hardly "most". > As a result of the two statements above, this paper argues that the > end-to-end mechanism MUST be specified in the basic MSRP > specification: >=20 I believe we have already agreed that the base spec will describe endpoint processing of DSN, to the degree that a non-relay aware endpoint needs to understand to interwork with an endpoint that uses relays. >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Review of MSRP Delivery Mechanisms > Author(s) : O. Levin > Filename : draft-levin-simple-msrp-review-00.txt > Pages : 16 > Date : 2004-4-6 > =20 > This paper shows that the currently defined per-message hop-by-hop > mechanism doesn't scale for large deployments and is not feasible for > scalable IM conferencing. Instead, the paper proposes to replace this > mechanism with an MSRP layer "per TCP connection keep-alive > mechanism". This paper also reinforces the need for the end-to-end > mechanism to be defined in the core MSRP specification and to become > the abstraction for all MSRP applications regardless the underlying > topology in use. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-levin-simple-msrp-review-00. > txt >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 8 22:47:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23642 for ; Thu, 8 Apr 2004 22:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBm35-0006wx-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 22:47:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBm2C-0006sk-00 for simple-archive@ietf.org; Thu, 08 Apr 2004 22:46:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBm11-0006os-00; Thu, 08 Apr 2004 22:45:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBm0r-0003VL-Pi; Thu, 08 Apr 2004 22:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBm0P-0003Oj-KA for simple@optimus.ietf.org; Thu, 08 Apr 2004 22:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23575 for ; Thu, 8 Apr 2004 22:44:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBm0K-0006ll-00 for simple@ietf.org; Thu, 08 Apr 2004 22:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlz0-0006gk-00 for simple@ietf.org; Thu, 08 Apr 2004 22:43:09 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BBlxi-0006ad-00 for simple@ietf.org; Thu, 08 Apr 2004 22:41:46 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i392fXIx057765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2004 21:41:34 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40760D56.7020206@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Simple WG Subject: Re: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Apr 2004 21:41:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Orit Levin wrote: > Ben, > Thank you very much for commenting on the draft in details. > I hope that the whole joined effort will help to keep the MSRP efforts > focused and a successful protocol being defined and widely used. > > First, the two main points: > > 1. "I believe we have already agreed that the base spec will describe > endpoint processing of DSN, to the degree that a non-relay aware > endpoint needs to understand to interwork with an endpoint that uses > relays." > Excellent! Do we also agree that DSN contains at least the two > primitives: "send-and-forget" and "send-with-receipt: negative or > positive". Optionally also "send-negative-receipt-if possible", but I am > less sure about this one. I think so. I was thinking in terms of "No DSN", "DSN on Error only", and "DSN on success". I think this maps to the same concepts, doesn't it? But keep in mind, I was talking _only_ about DSN, which I see as a separate issue from transaction responses. This would map to what you describe as "end-to-end" acknowledgments, although they can sometimes be middle-to-end. > > 2. As we discussed in our previous conversations, just making the timer > optional will still require each entity to send the response per message > (50% gain only). Agreed in principle, although whether the proportion of overhead is actually half is hard to say. Also, this way we blindly apply the loose local policy > to all the MSRP messages in the route. As we discussed earlier, a more > flexible solution would be marking the messages with "respond"/"don't > respond" bit being set by end-users and inspected by the relays/user > agents as they forward the message anyway (to the next hop or to the > applications). I am not sure whether you are talking about the DSN mechanism, or talking collectively about all acknowledgement mechanisms. I see the value of selecting on a per-message basis whether you want some form of DSN. As I mentioned in a separate email, I tend to not agree with selecting whether you send transaction responses on a per-message basis. The other option would be the strict "single-hop" > mechanism per TCP connection being proposed in the draft. (BTW The > suggested value of the timer ~10 sec is a very poor choice (my fault) > and the value will depend on topology requirements.) I assume you are referring to the per-connection keep-alive mechanism you propose, right? I need to think that through more thoroughly. Anyone else have thoughts on it? [...] >>(Negative responses are also defined but they are applicable only for >> deployments with no relays in the network.) > > > There has not been any agreement to that effect that I am aware of. We > had a side conversation that we might want to get rid of negative > transaction responses for relays, but no wg consensus. I personally do > not like the idea of having a different set of allowed transaction > responses depending on whether relays are present. > > OL: I don't like the different sets either. The point that I found > disturbing was that the negative responses are useless when received by > relays. > > I don't understand that statement. In the current MSRP/RELAY model (that is, the one with transaction responses), if an upstream relay gets a negative transaction response, it can then generate a failure DNS back to the sender. This is similar to the case where you get a TCP failure before getting a transaction response, but quicker. In [...] > It is a matter of balancing the complexity of having two different > transaction models with the cost of having a transaction model that > works well for the primary usage (sending IMs) but is less optimal for a > secondary usage (sending DSN, or other status reports.) > > OL: As we talked before, the bit "response/don't response" per message > will provide a solution to this problem as well. Again, just to clarify whether we are on the same page: I agree with selection DSN per message. I do not agree with selection transaction responses per message. These are two different mechanisms. If we decide it is generally better to not have transaction responses, then we should do away with them completely. Or not. I don't think we should be negotiating completely different protocol behaviors. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 8 22:47:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23681 for ; Thu, 8 Apr 2004 22:47:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBm3I-0003ir-Fr for simple-archive@odin.ietf.org; Thu, 08 Apr 2004 22:47:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i392lWJX014305 for simple-archive@odin.ietf.org; Thu, 8 Apr 2004 22:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBm3I-0003ie-BT for simple-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 22:47:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23661 for ; Thu, 8 Apr 2004 22:47:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBm3D-0006x6-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 22:47:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBm2D-0006sr-00 for simple-web-archive@ietf.org; Thu, 08 Apr 2004 22:46:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBm11-0006os-00; Thu, 08 Apr 2004 22:45:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBm0r-0003VL-Pi; Thu, 08 Apr 2004 22:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBm0P-0003Oj-KA for simple@optimus.ietf.org; Thu, 08 Apr 2004 22:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23575 for ; Thu, 8 Apr 2004 22:44:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBm0K-0006ll-00 for simple@ietf.org; Thu, 08 Apr 2004 22:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBlz0-0006gk-00 for simple@ietf.org; Thu, 08 Apr 2004 22:43:09 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BBlxi-0006ad-00 for simple@ietf.org; Thu, 08 Apr 2004 22:41:46 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i392fXIx057765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2004 21:41:34 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40760D56.7020206@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Simple WG Subject: Re: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Apr 2004 21:41:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit Levin wrote: > Ben, > Thank you very much for commenting on the draft in details. > I hope that the whole joined effort will help to keep the MSRP efforts > focused and a successful protocol being defined and widely used. > > First, the two main points: > > 1. "I believe we have already agreed that the base spec will describe > endpoint processing of DSN, to the degree that a non-relay aware > endpoint needs to understand to interwork with an endpoint that uses > relays." > Excellent! Do we also agree that DSN contains at least the two > primitives: "send-and-forget" and "send-with-receipt: negative or > positive". Optionally also "send-negative-receipt-if possible", but I am > less sure about this one. I think so. I was thinking in terms of "No DSN", "DSN on Error only", and "DSN on success". I think this maps to the same concepts, doesn't it? But keep in mind, I was talking _only_ about DSN, which I see as a separate issue from transaction responses. This would map to what you describe as "end-to-end" acknowledgments, although they can sometimes be middle-to-end. > > 2. As we discussed in our previous conversations, just making the timer > optional will still require each entity to send the response per message > (50% gain only). Agreed in principle, although whether the proportion of overhead is actually half is hard to say. Also, this way we blindly apply the loose local policy > to all the MSRP messages in the route. As we discussed earlier, a more > flexible solution would be marking the messages with "respond"/"don't > respond" bit being set by end-users and inspected by the relays/user > agents as they forward the message anyway (to the next hop or to the > applications). I am not sure whether you are talking about the DSN mechanism, or talking collectively about all acknowledgement mechanisms. I see the value of selecting on a per-message basis whether you want some form of DSN. As I mentioned in a separate email, I tend to not agree with selecting whether you send transaction responses on a per-message basis. The other option would be the strict "single-hop" > mechanism per TCP connection being proposed in the draft. (BTW The > suggested value of the timer ~10 sec is a very poor choice (my fault) > and the value will depend on topology requirements.) I assume you are referring to the per-connection keep-alive mechanism you propose, right? I need to think that through more thoroughly. Anyone else have thoughts on it? [...] >>(Negative responses are also defined but they are applicable only for >> deployments with no relays in the network.) > > > There has not been any agreement to that effect that I am aware of. We > had a side conversation that we might want to get rid of negative > transaction responses for relays, but no wg consensus. I personally do > not like the idea of having a different set of allowed transaction > responses depending on whether relays are present. > > OL: I don't like the different sets either. The point that I found > disturbing was that the negative responses are useless when received by > relays. > > I don't understand that statement. In the current MSRP/RELAY model (that is, the one with transaction responses), if an upstream relay gets a negative transaction response, it can then generate a failure DNS back to the sender. This is similar to the case where you get a TCP failure before getting a transaction response, but quicker. In [...] > It is a matter of balancing the complexity of having two different > transaction models with the cost of having a transaction model that > works well for the primary usage (sending IMs) but is less optimal for a > secondary usage (sending DSN, or other status reports.) > > OL: As we talked before, the bit "response/don't response" per message > will provide a solution to this problem as well. Again, just to clarify whether we are on the same page: I agree with selection DSN per message. I do not agree with selection transaction responses per message. These are two different mechanisms. If we decide it is generally better to not have transaction responses, then we should do away with them completely. Or not. I don't think we should be negotiating completely different protocol behaviors. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 9 03:13:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15500 for ; Fri, 9 Apr 2004 03:13:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBqCK-0001Sn-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 03:13:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBq9z-0001FY-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 03:10:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBq8V-00015E-00; Fri, 09 Apr 2004 03:09:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBq8K-00010B-Sx; Fri, 09 Apr 2004 03:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBq7b-0000xj-Dg for simple@optimus.ietf.org; Fri, 09 Apr 2004 03:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15270 for ; Fri, 9 Apr 2004 03:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBq7T-0000zu-00 for simple@ietf.org; Fri, 09 Apr 2004 03:08:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBq4Z-0000og-00 for simple@ietf.org; Fri, 09 Apr 2004 03:05:07 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BBq3S-0000ci-00 for simple@ietf.org; Fri, 09 Apr 2004 03:03:59 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 9 Apr 2004 00:03:45 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Apr 2004 00:03:13 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Apr 2004 00:03:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQdydNYMk4o/9/1RVavHV5HGsXgowAGTVgg From: "Orit Levin" To: "Ben Campbell" , "Simple WG" X-OriginalArrivalTime: 09 Apr 2004 07:03:10.0784 (UTC) FILETIME=[B7ED6C00:01C41E00] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 00:03:06 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ben, I am replying to this and some of the points from your following mail together. [...] First, I would like to clarify the reliability requirements, as I see=20 them, a little. As I see it, when I send a message, there are three=20 levels of reliability that I might care about. Consider the following=20 scenarios: 1) I really don't care at all. (Strangely, this is the mode used by a=20 lot of existing large scale systems. If we are dealing with highly=20 interactive conversations between humans, humans provide their own=20 reliability mechanism. I find myself typing "Hey, did you get my IM=20 about X a few minutes ago" frequently.) 2) I want a good effort to deliver, and a good attempt to tell me if=20 something went wrong. If I hear nothing, I assume it most likely worked. 3) Delivery is critical. I want to be told that it worked, and if I=20 don't hear anything, I assume it most likely failed. My personal opinion is that 1 is generally unacceptable (dispite current systems), 3 should be an option, but 2 will be the primary use case, and the one we should optimize for. The rest of this email takes that=20 perspective; if consensus proves me wrong then my analysis will change. OL: My opinion on 1 is very different from yours: we will not educate the existing and prosperous industry what it means "acceptable" vs. "unacceptable" service by defining a rigid protocol. The industry will just not use such a protocol at all. The only way to define an IM protocol that will link the IM islands together is to make it appealing to the industry and having the ability to upgrade the service (to better quality) without replacing all the end applications. Therefore, in my view, 1 is MUST. Also, I am not sure at all that most of the applications will use 2. Those applications that will prefer to use 1 for majority of the user messages, in parallel will use 3 with a DSN receipt for application level keep-alive mechanism potentially per MSRP session. Why are you opposing to a flexible hop-by-hop mechanism (in addition to DSN)? It doesn't necessarily require negotiation - only local policy for setting the bit. Let's assume for a moment that a bit per message exists saying "response/don't response" to the previous hop. This is how I can imagine the defined interface: Primitive "Send and Forget": This is #1 - the bit is set to FALSE Primitive "Send with no DSN": This is #2 - the bit can be either TRUE or FALSE Primitive "Send with DSN on Error only": This may be redundant - the bit can be either TRUE or FALSE Primitive "Send with DSN on success": This is #3 (application receipt) - the bit can be either TRUE or FALSE Orit. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 9 03:13:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15580 for ; Fri, 9 Apr 2004 03:13:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqCS-0001aL-Qm for simple-archive@odin.ietf.org; Fri, 09 Apr 2004 03:13:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i397DGnP006087 for simple-archive@odin.ietf.org; Fri, 9 Apr 2004 03:13:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqCS-0001a5-KL for simple-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 03:13:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15523 for ; Fri, 9 Apr 2004 03:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBqCQ-0001T0-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 03:13:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBqA0-0001Fg-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 03:10:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBq8V-00015E-00; Fri, 09 Apr 2004 03:09:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBq8K-00010B-Sx; Fri, 09 Apr 2004 03:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBq7b-0000xj-Dg for simple@optimus.ietf.org; Fri, 09 Apr 2004 03:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15270 for ; Fri, 9 Apr 2004 03:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBq7T-0000zu-00 for simple@ietf.org; Fri, 09 Apr 2004 03:08:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBq4Z-0000og-00 for simple@ietf.org; Fri, 09 Apr 2004 03:05:07 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BBq3S-0000ci-00 for simple@ietf.org; Fri, 09 Apr 2004 03:03:59 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 9 Apr 2004 00:03:45 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Apr 2004 00:03:13 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Apr 2004 00:03:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQdydNYMk4o/9/1RVavHV5HGsXgowAGTVgg From: "Orit Levin" To: "Ben Campbell" , "Simple WG" X-OriginalArrivalTime: 09 Apr 2004 07:03:10.0784 (UTC) FILETIME=[B7ED6C00:01C41E00] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 00:03:06 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ben, I am replying to this and some of the points from your following mail together. [...] First, I would like to clarify the reliability requirements, as I see=20 them, a little. As I see it, when I send a message, there are three=20 levels of reliability that I might care about. Consider the following=20 scenarios: 1) I really don't care at all. (Strangely, this is the mode used by a=20 lot of existing large scale systems. If we are dealing with highly=20 interactive conversations between humans, humans provide their own=20 reliability mechanism. I find myself typing "Hey, did you get my IM=20 about X a few minutes ago" frequently.) 2) I want a good effort to deliver, and a good attempt to tell me if=20 something went wrong. If I hear nothing, I assume it most likely worked. 3) Delivery is critical. I want to be told that it worked, and if I=20 don't hear anything, I assume it most likely failed. My personal opinion is that 1 is generally unacceptable (dispite current systems), 3 should be an option, but 2 will be the primary use case, and the one we should optimize for. The rest of this email takes that=20 perspective; if consensus proves me wrong then my analysis will change. OL: My opinion on 1 is very different from yours: we will not educate the existing and prosperous industry what it means "acceptable" vs. "unacceptable" service by defining a rigid protocol. The industry will just not use such a protocol at all. The only way to define an IM protocol that will link the IM islands together is to make it appealing to the industry and having the ability to upgrade the service (to better quality) without replacing all the end applications. Therefore, in my view, 1 is MUST. Also, I am not sure at all that most of the applications will use 2. Those applications that will prefer to use 1 for majority of the user messages, in parallel will use 3 with a DSN receipt for application level keep-alive mechanism potentially per MSRP session. Why are you opposing to a flexible hop-by-hop mechanism (in addition to DSN)? It doesn't necessarily require negotiation - only local policy for setting the bit. Let's assume for a moment that a bit per message exists saying "response/don't response" to the previous hop. This is how I can imagine the defined interface: Primitive "Send and Forget": This is #1 - the bit is set to FALSE Primitive "Send with no DSN": This is #2 - the bit can be either TRUE or FALSE Primitive "Send with DSN on Error only": This may be redundant - the bit can be either TRUE or FALSE Primitive "Send with DSN on success": This is #3 (application receipt) - the bit can be either TRUE or FALSE Orit. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 9 10:21:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29935 for ; Fri, 9 Apr 2004 10:21:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwtC-0001xi-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 10:21:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwsH-0001sr-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 10:20:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBwqd-0001lF-00; Fri, 09 Apr 2004 10:19:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwqT-0006XU-Gw; Fri, 09 Apr 2004 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwqD-0006In-Fj for simple@optimus.ietf.org; Fri, 09 Apr 2004 10:18:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29821 for ; Fri, 9 Apr 2004 10:18:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwq7-0001kB-00 for simple@ietf.org; Fri, 09 Apr 2004 10:18:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwoT-0001cT-00 for simple@ietf.org; Fri, 09 Apr 2004 10:16:57 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BBwn4-0001VQ-00 for simple@ietf.org; Fri, 09 Apr 2004 10:15:31 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i39EFFIx009020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2004 09:15:17 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4076AFE6.5000101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Simple WG Subject: Re: [Simple] MSRP message reliability(long) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Apr 2004 09:15:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Orit Levin wrote: [...] > Why are you opposing to a flexible hop-by-hop mechanism (in addition to > DSN)? It doesn't necessarily require negotiation - only local policy for > setting the bit. > Let's assume for a moment that a bit per message exists saying > "response/don't response" to the previous hop. I oppose the ability to select whether you use transaction responses or not because it adds a huge amount of complexity to the protocol and any implementations. Adding or removing transaction responses _completely_ changes the protocol semantics. In effect, it would be saying we have two different required protocols with the same syntax on top. If we make this selectable, we make every implementer build 2 protocols with different state machines, etc. I think that will be _much_ more of an impediment to acceptance than performance differences in the range you predict. My point is, if the working group were to decide we need to be able to run without transaction responses (a big if) , then we should _always_ run without transaction responses. As it is, earlier attempts at a message sessions did not have the transaction response, and the working group decided to put them it. (Does anyone remember the specific argument used at that time?) But, on all of these points, working group consensus trumps either of our opinions. Please, anyone who cares one way or another, state your opinion asap! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 9 10:22:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29960 for ; Fri, 9 Apr 2004 10:22:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwtO-0006pE-GO for simple-archive@odin.ietf.org; Fri, 09 Apr 2004 10:22:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39EM28K026232 for simple-archive@odin.ietf.org; Fri, 9 Apr 2004 10:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwtO-0006p1-C6 for simple-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 10:22:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29953 for ; Fri, 9 Apr 2004 10:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwtL-0001xr-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 10:21:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwsI-0001tA-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 10:20:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBwqd-0001lF-00; Fri, 09 Apr 2004 10:19:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwqT-0006XU-Gw; Fri, 09 Apr 2004 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwqD-0006In-Fj for simple@optimus.ietf.org; Fri, 09 Apr 2004 10:18:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29821 for ; Fri, 9 Apr 2004 10:18:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwq7-0001kB-00 for simple@ietf.org; Fri, 09 Apr 2004 10:18:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwoT-0001cT-00 for simple@ietf.org; Fri, 09 Apr 2004 10:16:57 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BBwn4-0001VQ-00 for simple@ietf.org; Fri, 09 Apr 2004 10:15:31 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i39EFFIx009020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2004 09:15:17 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4076AFE6.5000101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Simple WG Subject: Re: [Simple] MSRP message reliability(long) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Apr 2004 09:15:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit Levin wrote: [...] > Why are you opposing to a flexible hop-by-hop mechanism (in addition to > DSN)? It doesn't necessarily require negotiation - only local policy for > setting the bit. > Let's assume for a moment that a bit per message exists saying > "response/don't response" to the previous hop. I oppose the ability to select whether you use transaction responses or not because it adds a huge amount of complexity to the protocol and any implementations. Adding or removing transaction responses _completely_ changes the protocol semantics. In effect, it would be saying we have two different required protocols with the same syntax on top. If we make this selectable, we make every implementer build 2 protocols with different state machines, etc. I think that will be _much_ more of an impediment to acceptance than performance differences in the range you predict. My point is, if the working group were to decide we need to be able to run without transaction responses (a big if) , then we should _always_ run without transaction responses. As it is, earlier attempts at a message sessions did not have the transaction response, and the working group decided to put them it. (Does anyone remember the specific argument used at that time?) But, on all of these points, working group consensus trumps either of our opinions. Please, anyone who cares one way or another, state your opinion asap! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 9 10:36:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00764 for ; Fri, 9 Apr 2004 10:36:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBx7M-00039i-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 10:36:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBx5e-000340-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 10:34:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBx5A-0002y3-00; Fri, 09 Apr 2004 10:34:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBx4y-0007pX-Uo; Fri, 09 Apr 2004 10:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBx4D-0007ki-Oi for simple@optimus.ietf.org; Fri, 09 Apr 2004 10:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00455 for ; Fri, 9 Apr 2004 10:33:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBx4A-0002tM-00 for simple@ietf.org; Fri, 09 Apr 2004 10:33:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBx38-0002m6-00 for simple@ietf.org; Fri, 09 Apr 2004 10:32:07 -0400 Received: from website12.com ([203.194.209.81]) by ietf-mx with smtp (Exim 4.12) id 1BBx1H-0002ab-00 for simple@ietf.org; Fri, 09 Apr 2004 10:30:11 -0400 Received: (qmail 29747 invoked from network); 9 Apr 2004 14:30:18 -0000 Received: from unknown (HELO VIKAS) (61.247.240.212) by website12.com with SMTP; 9 Apr 2004 14:30:18 -0000 From: "Vikas Tandon" To: "'Ben Campbell'" , "'Orit Levin'" Cc: "'Simple WG'" Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <000201c41e3f$46e98ae0$0100a8c0@VIKAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 In-Reply-To: <4076AFE6.5000101@dynamicsoft.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 20:00:51 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Also as discussed earlier in this forum, this adds a lot of traffic to the client (specially the wireless mobile clients where the bandwidth is an issue). If the workgroup plans to make it configurable to set the delivery response for positive case off, then it has to be terminated earlier than reaching the wireless medium. E.g. terminate the positive response at the IM server in case the client has chosen not to receive the positive acknowledgements of delivery of IM. If we fail to do this, imagine for every message I'm sending, there is some traffic I'm getting back to my mobile device (which is painful because i may be paying by the amount of traffic i transact from my device). So although it becomes transparent to me from device, by i still pay for it. The workgroup needs to consider this matter. I somehow still prefer - "No news is good news". Would be good to know more thoughts on this. Regards, Vikas Tandon -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Ben Campbell Sent: vendredi 9 avril 2004 19:45 To: Orit Levin Cc: Simple WG Subject: Re: [Simple] MSRP message reliability(long) Orit Levin wrote: [...] > Why are you opposing to a flexible hop-by-hop mechanism (in addition > to DSN)? It doesn't necessarily require negotiation - only local > policy for setting the bit. Let's assume for a moment that a bit per > message exists saying "response/don't response" to the previous hop. I oppose the ability to select whether you use transaction responses or not because it adds a huge amount of complexity to the protocol and any implementations. Adding or removing transaction responses _completely_ changes the protocol semantics. In effect, it would be saying we have two different required protocols with the same syntax on top. If we make this selectable, we make every implementer build 2 protocols with different state machines, etc. I think that will be _much_ more of an impediment to acceptance than performance differences in the range you predict. My point is, if the working group were to decide we need to be able to run without transaction responses (a big if) , then we should _always_ run without transaction responses. As it is, earlier attempts at a message sessions did not have the transaction response, and the working group decided to put them it. (Does anyone remember the specific argument used at that time?) But, on all of these points, working group consensus trumps either of our opinions. Please, anyone who cares one way or another, state your opinion asap! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 9 10:37:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00786 for ; Fri, 9 Apr 2004 10:37:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBx7T-00082g-Jx for simple-archive@odin.ietf.org; Fri, 09 Apr 2004 10:36:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39EaZTi030910 for simple-archive@odin.ietf.org; Fri, 9 Apr 2004 10:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBx7T-00082T-FU for simple-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 10:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00782 for ; Fri, 9 Apr 2004 10:36:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBx7Q-00039p-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 10:36:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBx5f-000348-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 10:34:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBx5A-0002y3-00; Fri, 09 Apr 2004 10:34:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBx4y-0007pX-Uo; Fri, 09 Apr 2004 10:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBx4D-0007ki-Oi for simple@optimus.ietf.org; Fri, 09 Apr 2004 10:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00455 for ; Fri, 9 Apr 2004 10:33:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBx4A-0002tM-00 for simple@ietf.org; Fri, 09 Apr 2004 10:33:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBx38-0002m6-00 for simple@ietf.org; Fri, 09 Apr 2004 10:32:07 -0400 Received: from website12.com ([203.194.209.81]) by ietf-mx with smtp (Exim 4.12) id 1BBx1H-0002ab-00 for simple@ietf.org; Fri, 09 Apr 2004 10:30:11 -0400 Received: (qmail 29747 invoked from network); 9 Apr 2004 14:30:18 -0000 Received: from unknown (HELO VIKAS) (61.247.240.212) by website12.com with SMTP; 9 Apr 2004 14:30:18 -0000 From: "Vikas Tandon" To: "'Ben Campbell'" , "'Orit Levin'" Cc: "'Simple WG'" Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <000201c41e3f$46e98ae0$0100a8c0@VIKAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 In-Reply-To: <4076AFE6.5000101@dynamicsoft.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 20:00:51 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Also as discussed earlier in this forum, this adds a lot of traffic to the client (specially the wireless mobile clients where the bandwidth is an issue). If the workgroup plans to make it configurable to set the delivery response for positive case off, then it has to be terminated earlier than reaching the wireless medium. E.g. terminate the positive response at the IM server in case the client has chosen not to receive the positive acknowledgements of delivery of IM. If we fail to do this, imagine for every message I'm sending, there is some traffic I'm getting back to my mobile device (which is painful because i may be paying by the amount of traffic i transact from my device). So although it becomes transparent to me from device, by i still pay for it. The workgroup needs to consider this matter. I somehow still prefer - "No news is good news". Would be good to know more thoughts on this. Regards, Vikas Tandon -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Ben Campbell Sent: vendredi 9 avril 2004 19:45 To: Orit Levin Cc: Simple WG Subject: Re: [Simple] MSRP message reliability(long) Orit Levin wrote: [...] > Why are you opposing to a flexible hop-by-hop mechanism (in addition > to DSN)? It doesn't necessarily require negotiation - only local > policy for setting the bit. Let's assume for a moment that a bit per > message exists saying "response/don't response" to the previous hop. I oppose the ability to select whether you use transaction responses or not because it adds a huge amount of complexity to the protocol and any implementations. Adding or removing transaction responses _completely_ changes the protocol semantics. In effect, it would be saying we have two different required protocols with the same syntax on top. If we make this selectable, we make every implementer build 2 protocols with different state machines, etc. I think that will be _much_ more of an impediment to acceptance than performance differences in the range you predict. My point is, if the working group were to decide we need to be able to run without transaction responses (a big if) , then we should _always_ run without transaction responses. As it is, earlier attempts at a message sessions did not have the transaction response, and the working group decided to put them it. (Does anyone remember the specific argument used at that time?) But, on all of these points, working group consensus trumps either of our opinions. Please, anyone who cares one way or another, state your opinion asap! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 9 10:45:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01131 for ; Fri, 9 Apr 2004 10:45:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxG3-00040Y-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 10:45:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxF6-0003uX-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 10:44:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBxE5-0003oX-00; Fri, 09 Apr 2004 10:43:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxDh-0000Jo-Tl; Fri, 09 Apr 2004 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxCy-0000Ad-CL for simple@optimus.ietf.org; Fri, 09 Apr 2004 10:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01052 for ; Fri, 9 Apr 2004 10:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxCv-0003gQ-00 for simple@ietf.org; Fri, 09 Apr 2004 10:42:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxBi-0003bN-00 for simple@ietf.org; Fri, 09 Apr 2004 10:40:59 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BBxB0-0003Vw-00 for simple@ietf.org; Fri, 09 Apr 2004 10:40:14 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i39Ee7Ix011192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2004 09:40:09 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4076B5BB.2050606@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vikas Tandon CC: "'Orit Levin'" , "'Simple WG'" Subject: Re: [Simple] MSRP message reliability(long) References: <000201c41e3f$46e98ae0$0100a8c0@VIKAS> In-Reply-To: <000201c41e3f$46e98ae0$0100a8c0@VIKAS> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Apr 2004 09:39:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Vikas Tandon wrote: > Also as discussed earlier in this forum, this adds a lot of traffic to > the client (specially the wireless mobile clients where the bandwidth is > an issue). If the workgroup plans to make it configurable to set the > delivery response for positive case off, then it has to be terminated > earlier than reaching the wireless medium. E.g. terminate the positive > response at the IM server in case the client has chosen not to receive > the positive acknowledgements of delivery of IM. Hi, could you clarify what "this" refers to in the previous paragraph? Keep in mind that we are really discussion two things: the transaction responses between hops, and the sending of delivery reports. It sounds to me like you are talking delivery reports, but I am not certain. > > If we fail to do this, imagine for every message I'm sending, there is > some traffic I'm getting back to my mobile device (which is painful > because i may be paying by the amount of traffic i transact from my > device). So although it becomes transparent to me from device, by i > still pay for it. The workgroup needs to consider this matter. I somehow > still prefer - "No news is good news". > > Would be good to know more thoughts on this. > > Regards, > Vikas Tandon > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Ben Campbell > Sent: vendredi 9 avril 2004 19:45 > To: Orit Levin > Cc: Simple WG > Subject: Re: [Simple] MSRP message reliability(long) > > > Orit Levin wrote: > > [...] > >>Why are you opposing to a flexible hop-by-hop mechanism (in addition >>to DSN)? It doesn't necessarily require negotiation - only local >>policy for setting the bit. Let's assume for a moment that a bit per >>message exists saying "response/don't response" to the previous hop. > > > I oppose the ability to select whether you use transaction responses or > not because it adds a huge amount of complexity to the protocol and any > implementations. Adding or removing transaction responses _completely_ > changes the protocol semantics. In effect, it would be saying we have > two different required protocols with the same syntax on top. If we make > > this selectable, we make every implementer build 2 protocols with > different state machines, etc. I think that will be _much_ more of an > impediment to acceptance than performance differences in the range you > predict. > > My point is, if the working group were to decide we need to be able to > run without transaction responses (a big if) , then we should _always_ > run without transaction responses. As it is, earlier attempts at a > message sessions did not have the transaction response, and the working > group decided to put them it. (Does anyone remember the specific > argument used at that time?) > > But, on all of these points, working group consensus trumps either of > our opinions. Please, anyone who cares one way or another, state your > opinion asap! > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 9 10:46:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01183 for ; Fri, 9 Apr 2004 10:46:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxG9-0000YC-Dv for simple-archive@odin.ietf.org; Fri, 09 Apr 2004 10:45:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39EjXu7002112 for simple-archive@odin.ietf.org; Fri, 9 Apr 2004 10:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxG9-0000Xz-9d for simple-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 10:45:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01150 for ; Fri, 9 Apr 2004 10:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxG6-00040f-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 10:45:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxF7-0003ue-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 10:44:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBxE5-0003oX-00; Fri, 09 Apr 2004 10:43:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxDh-0000Jo-Tl; Fri, 09 Apr 2004 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxCy-0000Ad-CL for simple@optimus.ietf.org; Fri, 09 Apr 2004 10:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01052 for ; Fri, 9 Apr 2004 10:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxCv-0003gQ-00 for simple@ietf.org; Fri, 09 Apr 2004 10:42:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxBi-0003bN-00 for simple@ietf.org; Fri, 09 Apr 2004 10:40:59 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BBxB0-0003Vw-00 for simple@ietf.org; Fri, 09 Apr 2004 10:40:14 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i39Ee7Ix011192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2004 09:40:09 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4076B5BB.2050606@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vikas Tandon CC: "'Orit Levin'" , "'Simple WG'" Subject: Re: [Simple] MSRP message reliability(long) References: <000201c41e3f$46e98ae0$0100a8c0@VIKAS> In-Reply-To: <000201c41e3f$46e98ae0$0100a8c0@VIKAS> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Apr 2004 09:39:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vikas Tandon wrote: > Also as discussed earlier in this forum, this adds a lot of traffic to > the client (specially the wireless mobile clients where the bandwidth is > an issue). If the workgroup plans to make it configurable to set the > delivery response for positive case off, then it has to be terminated > earlier than reaching the wireless medium. E.g. terminate the positive > response at the IM server in case the client has chosen not to receive > the positive acknowledgements of delivery of IM. Hi, could you clarify what "this" refers to in the previous paragraph? Keep in mind that we are really discussion two things: the transaction responses between hops, and the sending of delivery reports. It sounds to me like you are talking delivery reports, but I am not certain. > > If we fail to do this, imagine for every message I'm sending, there is > some traffic I'm getting back to my mobile device (which is painful > because i may be paying by the amount of traffic i transact from my > device). So although it becomes transparent to me from device, by i > still pay for it. The workgroup needs to consider this matter. I somehow > still prefer - "No news is good news". > > Would be good to know more thoughts on this. > > Regards, > Vikas Tandon > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Ben Campbell > Sent: vendredi 9 avril 2004 19:45 > To: Orit Levin > Cc: Simple WG > Subject: Re: [Simple] MSRP message reliability(long) > > > Orit Levin wrote: > > [...] > >>Why are you opposing to a flexible hop-by-hop mechanism (in addition >>to DSN)? It doesn't necessarily require negotiation - only local >>policy for setting the bit. Let's assume for a moment that a bit per >>message exists saying "response/don't response" to the previous hop. > > > I oppose the ability to select whether you use transaction responses or > not because it adds a huge amount of complexity to the protocol and any > implementations. Adding or removing transaction responses _completely_ > changes the protocol semantics. In effect, it would be saying we have > two different required protocols with the same syntax on top. If we make > > this selectable, we make every implementer build 2 protocols with > different state machines, etc. I think that will be _much_ more of an > impediment to acceptance than performance differences in the range you > predict. > > My point is, if the working group were to decide we need to be able to > run without transaction responses (a big if) , then we should _always_ > run without transaction responses. As it is, earlier attempts at a > message sessions did not have the transaction response, and the working > group decided to put them it. (Does anyone remember the specific > argument used at that time?) > > But, on all of these points, working group consensus trumps either of > our opinions. Please, anyone who cares one way or another, state your > opinion asap! > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 9 10:47:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01263 for ; Fri, 9 Apr 2004 10:47:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxIH-0004Cj-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 10:47:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxHC-00046f-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 10:46:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBxG9-00040l-00; Fri, 09 Apr 2004 10:45:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxFe-0000RZ-8p; Fri, 09 Apr 2004 10:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuzJ-0008JO-MY for simple@optimus.ietf.org; Tue, 06 Apr 2004 14:07:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12746 for ; Tue, 6 Apr 2004 14:07:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuzH-0002MC-00 for simple@ietf.org; Tue, 06 Apr 2004 14:07:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAutD-0001J6-00 for simple@ietf.org; Tue, 06 Apr 2004 14:01:36 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BAujs-0000BK-00 for simple@ietf.org; Tue, 06 Apr 2004 13:51:56 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 10:00:44 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i36HpqKl013305; Tue, 6 Apr 2004 10:51:54 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARU49916; Tue, 6 Apr 2004 10:51:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53DAC4C0-87F3-11D8-BF5F-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Dean Willis , Hisham Khartabil , Allison Mankin , Robert Sparks , John Peterson , Ted Hardie , Gonzalo Camarillo , Rohan Mahy , Alan Johnston , Adam Roach From: Rohan Mahy To: simple@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Simple] Joint Interim Meeting Mon May 24 - Wed May 26 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 10:53:36 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hello All, Please mark your calendars. I'd like to announce a joint interim of the SIP, SIPPING, SIMPLE, and XCON WGs. Nokia has generously agreed to host the event either at their offices near Boston or in a neighboring hotel during the week of May 24. Please reserve the following dates for the WGs that you are interested in: Monday May 24 SIP and SIPPING tentatively 9 am start Tuesday May 25 SIMPLE All day Wednesday May 26 XCON tentatively finish at 4pm so folks can catch flights. (the actual agenda is subject to change, including the dates of various WG meetings). There will be no fee, however please let Hisham and myself know if you are planning to attend by clicking on the Yes or Maybe links below: mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]yes mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]maybe Wireless will be provided. As usual, I will be making T-shirts. If you are interested in buying one, please send your shirt size to me. More details on the agenda and hotel accommodations will be forthcoming shortly. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 9 10:48:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01300 for ; Fri, 9 Apr 2004 10:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxIW-0000qf-Dn for simple-archive@odin.ietf.org; Fri, 09 Apr 2004 10:48:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39Em0n4003257 for simple-archive@odin.ietf.org; Fri, 9 Apr 2004 10:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxIN-0000qR-RI for simple-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 10:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01280 for ; Fri, 9 Apr 2004 10:47:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxIL-0004Cp-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 10:47:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxHC-00046m-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 10:46:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBxG9-00040l-00; Fri, 09 Apr 2004 10:45:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxFe-0000RZ-8p; Fri, 09 Apr 2004 10:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuzJ-0008JO-MY for simple@optimus.ietf.org; Tue, 06 Apr 2004 14:07:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12746 for ; Tue, 6 Apr 2004 14:07:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuzH-0002MC-00 for simple@ietf.org; Tue, 06 Apr 2004 14:07:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAutD-0001J6-00 for simple@ietf.org; Tue, 06 Apr 2004 14:01:36 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BAujs-0000BK-00 for simple@ietf.org; Tue, 06 Apr 2004 13:51:56 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 10:00:44 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i36HpqKl013305; Tue, 6 Apr 2004 10:51:54 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARU49916; Tue, 6 Apr 2004 10:51:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53DAC4C0-87F3-11D8-BF5F-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Dean Willis , Hisham Khartabil , Allison Mankin , Robert Sparks , John Peterson , Ted Hardie , Gonzalo Camarillo , Rohan Mahy , Alan Johnston , Adam Roach From: Rohan Mahy To: simple@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Simple] Joint Interim Meeting Mon May 24 - Wed May 26 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 10:53:36 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All, Please mark your calendars. I'd like to announce a joint interim of the SIP, SIPPING, SIMPLE, and XCON WGs. Nokia has generously agreed to host the event either at their offices near Boston or in a neighboring hotel during the week of May 24. Please reserve the following dates for the WGs that you are interested in: Monday May 24 SIP and SIPPING tentatively 9 am start Tuesday May 25 SIMPLE All day Wednesday May 26 XCON tentatively finish at 4pm so folks can catch flights. (the actual agenda is subject to change, including the dates of various WG meetings). There will be no fee, however please let Hisham and myself know if you are planning to attend by clicking on the Yes or Maybe links below: mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]yes mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]maybe Wireless will be provided. As usual, I will be making T-shirts. If you are interested in buying one, please send your shirt size to me. More details on the agenda and hotel accommodations will be forthcoming shortly. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 9 16:11:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17036 for ; Fri, 9 Apr 2004 16:11:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC2Lt-0005hg-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 16:11:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC25g-00040O-00 for simple-archive@ietf.org; Fri, 09 Apr 2004 15:55:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC1zJ-000384-00; Fri, 09 Apr 2004 15:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1yB-0002An-AP; Fri, 09 Apr 2004 15:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1qm-0006fN-Gc for simple@optimus.ietf.org; Fri, 09 Apr 2004 15:39:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15607 for ; Fri, 9 Apr 2004 15:39:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1qL-0001lL-00 for simple@ietf.org; Fri, 09 Apr 2004 15:39:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1lS-0001LM-00 for simple@ietf.org; Fri, 09 Apr 2004 15:34:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BC1hA-0000mX-00 for simple@ietf.org; Fri, 09 Apr 2004 15:29:44 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2004 12:25:18 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i39JT1CC027022; Fri, 9 Apr 2004 15:29:02 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM61666; Fri, 9 Apr 2004 15:29:00 -0400 (EDT) Message-ID: <4076F97C.8070001@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP message reliability(long) References: <4075C07A.4090505@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Apr 2004 15:29:00 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sorry I have been absent - I have been preoccupied with other (work) things. I took a quick look at Orit's draft. Before getting into the main discussion, I don't think I understand the benchmark. As I understand, the server is in the middle of all the sessions between the 20000 endpoints. At any point in time there are a bunch of im conferences, each with 50 participants. For each conference, one of the participants is sending MESSAGE messages to the server, and the server is sending 49 MESSAGE messages out to the other participants in that conference. If so, in the normal run, for each incoming MESSAGE into the conference, the server will send one response, and will receive 49 responses. I can't reconcile that with the data in the draft, which shows a ratio of 1:4 for incoming requests to incoming responses. I don't want to use this data to draw conclusions about MSRP until I understand if/how it applies. Orit - am I just misinterpretting the data? Thanks, Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 9 16:12:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17106 for ; Fri, 9 Apr 2004 16:12:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2Lx-0000jO-WB for simple-archive@odin.ietf.org; Fri, 09 Apr 2004 16:11:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39KBrri002806 for simple-archive@odin.ietf.org; Fri, 9 Apr 2004 16:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2Lx-0000jB-RX for simple-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 16:11:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17055 for ; Fri, 9 Apr 2004 16:11:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC2Lv-0005hf-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 16:11:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC25h-00040V-00 for simple-web-archive@ietf.org; Fri, 09 Apr 2004 15:55:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC1zJ-000384-00; Fri, 09 Apr 2004 15:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1yB-0002An-AP; Fri, 09 Apr 2004 15:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1qm-0006fN-Gc for simple@optimus.ietf.org; Fri, 09 Apr 2004 15:39:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15607 for ; Fri, 9 Apr 2004 15:39:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1qL-0001lL-00 for simple@ietf.org; Fri, 09 Apr 2004 15:39:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1lS-0001LM-00 for simple@ietf.org; Fri, 09 Apr 2004 15:34:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BC1hA-0000mX-00 for simple@ietf.org; Fri, 09 Apr 2004 15:29:44 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2004 12:25:18 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i39JT1CC027022; Fri, 9 Apr 2004 15:29:02 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM61666; Fri, 9 Apr 2004 15:29:00 -0400 (EDT) Message-ID: <4076F97C.8070001@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP message reliability(long) References: <4075C07A.4090505@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Apr 2004 15:29:00 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry I have been absent - I have been preoccupied with other (work) things. I took a quick look at Orit's draft. Before getting into the main discussion, I don't think I understand the benchmark. As I understand, the server is in the middle of all the sessions between the 20000 endpoints. At any point in time there are a bunch of im conferences, each with 50 participants. For each conference, one of the participants is sending MESSAGE messages to the server, and the server is sending 49 MESSAGE messages out to the other participants in that conference. If so, in the normal run, for each incoming MESSAGE into the conference, the server will send one response, and will receive 49 responses. I can't reconcile that with the data in the draft, which shows a ratio of 1:4 for incoming requests to incoming responses. I don't want to use this data to draw conclusions about MSRP until I understand if/how it applies. Orit - am I just misinterpretting the data? Thanks, Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Apr 10 01:51:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10590 for ; Sat, 10 Apr 2004 01:51:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBOg-00040d-00 for simple-archive@ietf.org; Sat, 10 Apr 2004 01:51:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBNc-0003r8-00 for simple-archive@ietf.org; Sat, 10 Apr 2004 01:50:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BCBMa-0003iM-00; Sat, 10 Apr 2004 01:49:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBMS-0005ze-No; Sat, 10 Apr 2004 01:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBLq-0005v0-DE for simple@optimus.ietf.org; Sat, 10 Apr 2004 01:48:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10520 for ; Sat, 10 Apr 2004 01:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBLm-0003a6-00 for simple@ietf.org; Sat, 10 Apr 2004 01:48:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBKj-0003Rq-00 for simple@ietf.org; Sat, 10 Apr 2004 01:47:14 -0400 Received: from website12.com ([203.194.209.81]) by ietf-mx with smtp (Exim 4.12) id 1BCBJw-0003JJ-00 for simple@ietf.org; Sat, 10 Apr 2004 01:46:24 -0400 Received: (qmail 5233 invoked from network); 10 Apr 2004 05:46:30 -0000 Received: from unknown (HELO VIKAS) (61.247.241.9) by website12.com with SMTP; 10 Apr 2004 05:46:30 -0000 From: "Vikas Tandon" To: "'Ben Campbell'" Cc: "'Orit Levin'" , "'Simple WG'" Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <000b01c41ebf$3b7819d0$0100a8c0@VIKAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <4076B5BB.2050606@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Apr 2004 11:16:47 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Ben & Group, By "this" i mean the earlier messages exchanged between me, Mr. Vijay Gurbani, Mr. Hisham and a couple of more participants. Yes i am referring to the delivery reports. Regards, -Vikas -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: vendredi 9 avril 2004 20:10 To: Vikas Tandon Cc: 'Orit Levin'; 'Simple WG' Subject: Re: [Simple] MSRP message reliability(long) Vikas Tandon wrote: > Also as discussed earlier in this forum, this adds a lot of traffic to > the client (specially the wireless mobile clients where the bandwidth > is an issue). If the workgroup plans to make it configurable to set > the delivery response for positive case off, then it has to be > terminated earlier than reaching the wireless medium. E.g. terminate > the positive response at the IM server in case the client has chosen > not to receive the positive acknowledgements of delivery of IM. Hi, could you clarify what "this" refers to in the previous paragraph? Keep in mind that we are really discussion two things: the transaction responses between hops, and the sending of delivery reports. It sounds to me like you are talking delivery reports, but I am not certain. > > If we fail to do this, imagine for every message I'm sending, there is > some traffic I'm getting back to my mobile device (which is painful > because i may be paying by the amount of traffic i transact from my > device). So although it becomes transparent to me from device, by i > still pay for it. The workgroup needs to consider this matter. I > somehow still prefer - "No news is good news". > > Would be good to know more thoughts on this. > > Regards, > Vikas Tandon > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf > Of Ben Campbell > Sent: vendredi 9 avril 2004 19:45 > To: Orit Levin > Cc: Simple WG > Subject: Re: [Simple] MSRP message reliability(long) > > > Orit Levin wrote: > > [...] > >>Why are you opposing to a flexible hop-by-hop mechanism (in addition >>to DSN)? It doesn't necessarily require negotiation - only local >>policy for setting the bit. Let's assume for a moment that a bit per >>message exists saying "response/don't response" to the previous hop. > > > I oppose the ability to select whether you use transaction responses > or > not because it adds a huge amount of complexity to the protocol and any > implementations. Adding or removing transaction responses _completely_ > changes the protocol semantics. In effect, it would be saying we have > two different required protocols with the same syntax on top. If we make > > this selectable, we make every implementer build 2 protocols with > different state machines, etc. I think that will be _much_ more of an > impediment to acceptance than performance differences in the range you > predict. > > My point is, if the working group were to decide we need to be able to > run without transaction responses (a big if) , then we should _always_ > run without transaction responses. As it is, earlier attempts at a > message sessions did not have the transaction response, and the working > group decided to put them it. (Does anyone remember the specific > argument used at that time?) > > But, on all of these points, working group consensus trumps either of > our opinions. Please, anyone who cares one way or another, state your > opinion asap! > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Apr 10 01:51:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10627 for ; Sat, 10 Apr 2004 01:51:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBOp-0006AC-Dx for simple-archive@odin.ietf.org; Sat, 10 Apr 2004 01:51:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A5pRTb023692 for simple-archive@odin.ietf.org; Sat, 10 Apr 2004 01:51:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBOp-0006A3-9A for simple-web-archive@optimus.ietf.org; Sat, 10 Apr 2004 01:51:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10610 for ; Sat, 10 Apr 2004 01:51:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBOl-00040j-00 for simple-web-archive@ietf.org; Sat, 10 Apr 2004 01:51:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBNc-0003rF-00 for simple-web-archive@ietf.org; Sat, 10 Apr 2004 01:50:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BCBMa-0003iM-00; Sat, 10 Apr 2004 01:49:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBMS-0005ze-No; Sat, 10 Apr 2004 01:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBLq-0005v0-DE for simple@optimus.ietf.org; Sat, 10 Apr 2004 01:48:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10520 for ; Sat, 10 Apr 2004 01:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBLm-0003a6-00 for simple@ietf.org; Sat, 10 Apr 2004 01:48:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBKj-0003Rq-00 for simple@ietf.org; Sat, 10 Apr 2004 01:47:14 -0400 Received: from website12.com ([203.194.209.81]) by ietf-mx with smtp (Exim 4.12) id 1BCBJw-0003JJ-00 for simple@ietf.org; Sat, 10 Apr 2004 01:46:24 -0400 Received: (qmail 5233 invoked from network); 10 Apr 2004 05:46:30 -0000 Received: from unknown (HELO VIKAS) (61.247.241.9) by website12.com with SMTP; 10 Apr 2004 05:46:30 -0000 From: "Vikas Tandon" To: "'Ben Campbell'" Cc: "'Orit Levin'" , "'Simple WG'" Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <000b01c41ebf$3b7819d0$0100a8c0@VIKAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <4076B5BB.2050606@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Apr 2004 11:16:47 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ben & Group, By "this" i mean the earlier messages exchanged between me, Mr. Vijay Gurbani, Mr. Hisham and a couple of more participants. Yes i am referring to the delivery reports. Regards, -Vikas -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: vendredi 9 avril 2004 20:10 To: Vikas Tandon Cc: 'Orit Levin'; 'Simple WG' Subject: Re: [Simple] MSRP message reliability(long) Vikas Tandon wrote: > Also as discussed earlier in this forum, this adds a lot of traffic to > the client (specially the wireless mobile clients where the bandwidth > is an issue). If the workgroup plans to make it configurable to set > the delivery response for positive case off, then it has to be > terminated earlier than reaching the wireless medium. E.g. terminate > the positive response at the IM server in case the client has chosen > not to receive the positive acknowledgements of delivery of IM. Hi, could you clarify what "this" refers to in the previous paragraph? Keep in mind that we are really discussion two things: the transaction responses between hops, and the sending of delivery reports. It sounds to me like you are talking delivery reports, but I am not certain. > > If we fail to do this, imagine for every message I'm sending, there is > some traffic I'm getting back to my mobile device (which is painful > because i may be paying by the amount of traffic i transact from my > device). So although it becomes transparent to me from device, by i > still pay for it. The workgroup needs to consider this matter. I > somehow still prefer - "No news is good news". > > Would be good to know more thoughts on this. > > Regards, > Vikas Tandon > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf > Of Ben Campbell > Sent: vendredi 9 avril 2004 19:45 > To: Orit Levin > Cc: Simple WG > Subject: Re: [Simple] MSRP message reliability(long) > > > Orit Levin wrote: > > [...] > >>Why are you opposing to a flexible hop-by-hop mechanism (in addition >>to DSN)? It doesn't necessarily require negotiation - only local >>policy for setting the bit. Let's assume for a moment that a bit per >>message exists saying "response/don't response" to the previous hop. > > > I oppose the ability to select whether you use transaction responses > or > not because it adds a huge amount of complexity to the protocol and any > implementations. Adding or removing transaction responses _completely_ > changes the protocol semantics. In effect, it would be saying we have > two different required protocols with the same syntax on top. If we make > > this selectable, we make every implementer build 2 protocols with > different state machines, etc. I think that will be _much_ more of an > impediment to acceptance than performance differences in the range you > predict. > > My point is, if the working group were to decide we need to be able to > run without transaction responses (a big if) , then we should _always_ > run without transaction responses. As it is, earlier attempts at a > message sessions did not have the transaction response, and the working > group decided to put them it. (Does anyone remember the specific > argument used at that time?) > > But, on all of these points, working group consensus trumps either of > our opinions. Please, anyone who cares one way or another, state your > opinion asap! > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Apr 11 03:38:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15911 for ; Sun, 11 Apr 2004 03:38:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCZXd-0004bH-00 for simple-archive@ietf.org; Sun, 11 Apr 2004 03:38:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCZTM-0004CE-00 for simple-archive@ietf.org; Sun, 11 Apr 2004 03:33:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BCZPA-0003bP-00; Sun, 11 Apr 2004 03:29:24 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BCZ5s-0004DQ-5p; Sun, 11 Apr 2004 03:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZ5U-00086u-EE; Sun, 11 Apr 2004 03:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCVhI-0003F5-Hn for simple@optimus.ietf.org; Sat, 10 Apr 2004 23:31:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28142 for ; Sat, 10 Apr 2004 23:31:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCVhG-0006D4-00 for simple@ietf.org; Sat, 10 Apr 2004 23:31:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCVfk-0005xu-00 for simple@ietf.org; Sat, 10 Apr 2004 23:30:16 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BCVeu-0005p9-00 for simple@ietf.org; Sat, 10 Apr 2004 23:29:24 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3B3TNfF029519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Apr 2004 23:29:23 -0400 (EDT) Message-ID: <4078BB8D.2090304@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: eva-maria.leppanen@nokia.com CC: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Apr 2004 23:29:17 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Related question: I had actually used XMLSpy to validate the example in -03, but either XMLSpy is very liberal in what it considers validation ("where all the women are strong and where all the XML files are good-looking"...) or I'm doing something wrong. If somebody can enlighten me, I'd be grateful. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Apr 11 03:38:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15933 for ; Sun, 11 Apr 2004 03:38:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCZXn-0004bU-00 for simple-archive@ietf.org; Sun, 11 Apr 2004 03:38:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCZTN-0004CT-00 for simple-archive@ietf.org; Sun, 11 Apr 2004 03:33:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BCZPC-0003bo-00; Sun, 11 Apr 2004 03:29:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BCZ5p-0004DO-RX; Sun, 11 Apr 2004 03:09:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZ5T-00086S-6B; Sun, 11 Apr 2004 03:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCVem-0003Cp-Sg for simple@optimus.ietf.org; Sat, 10 Apr 2004 23:29:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28099 for ; Sat, 10 Apr 2004 23:29:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCVek-0005oN-00 for simple@ietf.org; Sat, 10 Apr 2004 23:29:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCVdI-0005fL-00 for simple@ietf.org; Sat, 10 Apr 2004 23:27:45 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BCVcK-0005PE-00 for simple@ietf.org; Sat, 10 Apr 2004 23:26:44 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3B3QVfF029260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Apr 2004 23:26:32 -0400 (EDT) Message-ID: <4078BAE2.4000202@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: eva-maria.leppanen@nokia.com CC: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Apr 2004 23:26:26 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks for your careful comments. I've updated the draft: http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-04.html Before I submit it, if you have a chance to check that I didn't miss anything. One question below: eva-maria.leppanen@nokia.com wrote: > - 6.1 and 6.2 (XML schemas): I did not find any reason to define the > pidf namespace in the schema (see xmlns:pidf="urn...") Can you explain this comment? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Apr 11 03:38:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15971 for ; Sun, 11 Apr 2004 03:38:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZXj-0003Zb-Nf for simple-archive@odin.ietf.org; Sun, 11 Apr 2004 03:38:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3B7cFtO013731 for simple-archive@odin.ietf.org; Sun, 11 Apr 2004 03:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZXj-0003ZG-Ft for simple-web-archive@optimus.ietf.org; Sun, 11 Apr 2004 03:38:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15929 for ; Sun, 11 Apr 2004 03:38:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCZXf-0004bJ-00 for simple-web-archive@ietf.org; Sun, 11 Apr 2004 03:38:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCZTM-0004CL-00 for simple-web-archive@ietf.org; Sun, 11 Apr 2004 03:33:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BCZPA-0003bP-00; Sun, 11 Apr 2004 03:29:24 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BCZ5s-0004DQ-5p; Sun, 11 Apr 2004 03:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZ5U-00086u-EE; Sun, 11 Apr 2004 03:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCVhI-0003F5-Hn for simple@optimus.ietf.org; Sat, 10 Apr 2004 23:31:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28142 for ; Sat, 10 Apr 2004 23:31:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCVhG-0006D4-00 for simple@ietf.org; Sat, 10 Apr 2004 23:31:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCVfk-0005xu-00 for simple@ietf.org; Sat, 10 Apr 2004 23:30:16 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BCVeu-0005p9-00 for simple@ietf.org; Sat, 10 Apr 2004 23:29:24 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3B3TNfF029519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Apr 2004 23:29:23 -0400 (EDT) Message-ID: <4078BB8D.2090304@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: eva-maria.leppanen@nokia.com CC: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Apr 2004 23:29:17 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Related question: I had actually used XMLSpy to validate the example in -03, but either XMLSpy is very liberal in what it considers validation ("where all the women are strong and where all the XML files are good-looking"...) or I'm doing something wrong. If somebody can enlighten me, I'd be grateful. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Apr 11 03:38:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15991 for ; Sun, 11 Apr 2004 03:38:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZXr-0003aZ-46 for simple-archive@odin.ietf.org; Sun, 11 Apr 2004 03:38:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3B7cNLR013791 for simple-archive@odin.ietf.org; Sun, 11 Apr 2004 03:38:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZXq-0003aM-Ut for simple-web-archive@optimus.ietf.org; Sun, 11 Apr 2004 03:38:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15951 for ; Sun, 11 Apr 2004 03:38:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCZXo-0004bX-00 for simple-web-archive@ietf.org; Sun, 11 Apr 2004 03:38:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCZTO-0004Ca-00 for simple-web-archive@ietf.org; Sun, 11 Apr 2004 03:33:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BCZPC-0003bo-00; Sun, 11 Apr 2004 03:29:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BCZ5p-0004DO-RX; Sun, 11 Apr 2004 03:09:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZ5T-00086S-6B; Sun, 11 Apr 2004 03:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCVem-0003Cp-Sg for simple@optimus.ietf.org; Sat, 10 Apr 2004 23:29:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28099 for ; Sat, 10 Apr 2004 23:29:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCVek-0005oN-00 for simple@ietf.org; Sat, 10 Apr 2004 23:29:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCVdI-0005fL-00 for simple@ietf.org; Sat, 10 Apr 2004 23:27:45 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BCVcK-0005PE-00 for simple@ietf.org; Sat, 10 Apr 2004 23:26:44 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3B3QVfF029260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Apr 2004 23:26:32 -0400 (EDT) Message-ID: <4078BAE2.4000202@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: eva-maria.leppanen@nokia.com CC: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Apr 2004 23:26:26 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your careful comments. I've updated the draft: http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-04.html Before I submit it, if you have a chance to check that I didn't miss anything. One question below: eva-maria.leppanen@nokia.com wrote: > - 6.1 and 6.2 (XML schemas): I did not find any reason to define the > pidf namespace in the schema (see xmlns:pidf="urn...") Can you explain this comment? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 12 09:20:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18821 for ; Mon, 12 Apr 2004 09:20:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1M6-0000ok-00 for simple-archive@ietf.org; Mon, 12 Apr 2004 09:20:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1L0-0000a8-00 for simple-archive@ietf.org; Mon, 12 Apr 2004 09:18:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD1JI-0000PQ-00; Mon, 12 Apr 2004 09:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1J7-0002Mz-HB; Mon, 12 Apr 2004 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1I6-0002IW-FR for simple@optimus.ietf.org; Mon, 12 Apr 2004 09:16:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18520 for ; Mon, 12 Apr 2004 09:15:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1I1-00009R-00 for simple@ietf.org; Mon, 12 Apr 2004 09:15:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1Fn-0007iI-00 for simple@ietf.org; Mon, 12 Apr 2004 09:13:36 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BD1Er-0007Rp-00 for simple@ietf.org; Mon, 12 Apr 2004 09:12:37 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Apr 2004 06:11:58 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 12 Apr 2004 06:11:58 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 12 Apr 2004 06:11:57 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Apr 2004 06:11:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQebCMOf6n1AzY+SCOLq9uIDLOLawCGm914 From: "Orit Levin" To: "Paul Kyzivat" , "Ben Campbell" Cc: "Simple WG" X-OriginalArrivalTime: 12 Apr 2004 13:11:56.0590 (UTC) FILETIME=[BB2CBCE0:01C4208F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Apr 2004 06:12:00 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Paul, The scenario shows a "normal" server application that periodically = performs other procedures than just processing the MESSAGEs. Even in = this mixed scenario, the difference in performance is substantial - 20%. =20 In order to understand the benchmark, the easiest is to take a look at = the "No response" column. You can see that out of all 1838.687 outgoing = messages, only 1178.341 were MESSAGEs (i.e. the funning of the 49 = MESSAGEs as a result of a single "trigger" MESSAGE being sent to the = server) . The "trigger MESSAGEs" are hidden in the 660.389 of other SIP = messages (e.g. REGISTER, INVITE, SUBSCRIBE, INFO, NOTIFY, ACK, etc.) = being received and processed by the server that don't necessarily belong = to the IM application itself. You can also see that the server sent = 660.346 (1838.687 - 1178.341 ) - messages as a part of this "other" = logic.=20 =20 It means that the server was busy with IM processing only ~ 47% = 1178/(660 +1838) of its whole processing time. This statistic may = represent some kind of an enterprise pattern... =20 According to the MSN data (typical public network), their deployment = statistics shows that today ~10% CPU go to "session establishment" and = ~90% CPU go to processing of IM data. If we apply this pattern to our = MESSAGE benchmark, the results would be MUCH worse! =20 Hope, it helps, Orit. =20 =20 ________________________________ From: simple-admin@ietf.org on behalf of Paul Kyzivat Sent: Fri 4/9/2004 12:29 PM To: Ben Campbell Cc: Simple WG Subject: Re: [Simple] MSRP message reliability(long) Sorry I have been absent - I have been preoccupied with other (work) = things. I took a quick look at Orit's draft. Before getting into the main discussion, I don't think I understand the benchmark. As I understand, the server is in the middle of all the sessions between the 20000 endpoints. At any point in time there are a bunch of im conferences, each with 50 participants. For each conference, one of the participants is sending MESSAGE messages to the server, and the server is sending 49 MESSAGE messages out to the other participants in that conference. If so, in the normal run, for each incoming MESSAGE into the conference, the server will send one response, and will receive 49 responses. I can't reconcile that with the data in the draft, which shows a ratio of 1:4 for incoming requests to incoming responses. I don't want to use this data to draw conclusions about MSRP until I understand if/how it applies. Orit - am I just misinterpretting the data? Thanks, Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 12 09:20:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18864 for ; Mon, 12 Apr 2004 09:20:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1MD-0002xg-Sj for simple-archive@odin.ietf.org; Mon, 12 Apr 2004 09:20:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CDKDKS011380 for simple-archive@odin.ietf.org; Mon, 12 Apr 2004 09:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1MD-0002xT-NJ for simple-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 09:20:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18844 for ; Mon, 12 Apr 2004 09:20:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1MB-0000or-00 for simple-web-archive@ietf.org; Mon, 12 Apr 2004 09:20:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1L1-0000aR-00 for simple-web-archive@ietf.org; Mon, 12 Apr 2004 09:19:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD1JI-0000PQ-00; Mon, 12 Apr 2004 09:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1J7-0002Mz-HB; Mon, 12 Apr 2004 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1I6-0002IW-FR for simple@optimus.ietf.org; Mon, 12 Apr 2004 09:16:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18520 for ; Mon, 12 Apr 2004 09:15:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1I1-00009R-00 for simple@ietf.org; Mon, 12 Apr 2004 09:15:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1Fn-0007iI-00 for simple@ietf.org; Mon, 12 Apr 2004 09:13:36 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BD1Er-0007Rp-00 for simple@ietf.org; Mon, 12 Apr 2004 09:12:37 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Apr 2004 06:11:58 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 12 Apr 2004 06:11:58 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 12 Apr 2004 06:11:57 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Apr 2004 06:11:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQebCMOf6n1AzY+SCOLq9uIDLOLawCGm914 From: "Orit Levin" To: "Paul Kyzivat" , "Ben Campbell" Cc: "Simple WG" X-OriginalArrivalTime: 12 Apr 2004 13:11:56.0590 (UTC) FILETIME=[BB2CBCE0:01C4208F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Apr 2004 06:12:00 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Paul, The scenario shows a "normal" server application that periodically = performs other procedures than just processing the MESSAGEs. Even in = this mixed scenario, the difference in performance is substantial - 20%. =20 In order to understand the benchmark, the easiest is to take a look at = the "No response" column. You can see that out of all 1838.687 outgoing = messages, only 1178.341 were MESSAGEs (i.e. the funning of the 49 = MESSAGEs as a result of a single "trigger" MESSAGE being sent to the = server) . The "trigger MESSAGEs" are hidden in the 660.389 of other SIP = messages (e.g. REGISTER, INVITE, SUBSCRIBE, INFO, NOTIFY, ACK, etc.) = being received and processed by the server that don't necessarily belong = to the IM application itself. You can also see that the server sent = 660.346 (1838.687 - 1178.341 ) - messages as a part of this "other" = logic.=20 =20 It means that the server was busy with IM processing only ~ 47% = 1178/(660 +1838) of its whole processing time. This statistic may = represent some kind of an enterprise pattern... =20 According to the MSN data (typical public network), their deployment = statistics shows that today ~10% CPU go to "session establishment" and = ~90% CPU go to processing of IM data. If we apply this pattern to our = MESSAGE benchmark, the results would be MUCH worse! =20 Hope, it helps, Orit. =20 =20 ________________________________ From: simple-admin@ietf.org on behalf of Paul Kyzivat Sent: Fri 4/9/2004 12:29 PM To: Ben Campbell Cc: Simple WG Subject: Re: [Simple] MSRP message reliability(long) Sorry I have been absent - I have been preoccupied with other (work) = things. I took a quick look at Orit's draft. Before getting into the main discussion, I don't think I understand the benchmark. As I understand, the server is in the middle of all the sessions between the 20000 endpoints. At any point in time there are a bunch of im conferences, each with 50 participants. For each conference, one of the participants is sending MESSAGE messages to the server, and the server is sending 49 MESSAGE messages out to the other participants in that conference. If so, in the normal run, for each incoming MESSAGE into the conference, the server will send one response, and will receive 49 responses. I can't reconcile that with the data in the draft, which shows a ratio of 1:4 for incoming requests to incoming responses. I don't want to use this data to draw conclusions about MSRP until I understand if/how it applies. Orit - am I just misinterpretting the data? Thanks, Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 12 23:18:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03719 for ; Mon, 12 Apr 2004 23:18:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDERb-0006OW-00 for simple-archive@ietf.org; Mon, 12 Apr 2004 23:18:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEQL-0006KX-00 for simple-archive@ietf.org; Mon, 12 Apr 2004 23:17:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDEPD-0006H6-00; Mon, 12 Apr 2004 23:16:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEP2-000514-RP; Mon, 12 Apr 2004 23:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEOp-0004zq-33 for simple@optimus.ietf.org; Mon, 12 Apr 2004 23:15:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03593 for ; Mon, 12 Apr 2004 23:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEOk-0006Fh-00 for simple@ietf.org; Mon, 12 Apr 2004 23:15:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEN2-0006Aq-00 for simple@ietf.org; Mon, 12 Apr 2004 23:13:57 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BDEL5-00065U-00 for simple@ietf.org; Mon, 12 Apr 2004 23:11:55 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3D3BnIx087693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Apr 2004 22:11:50 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407B5A73.1050506@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Yet another draft update Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Apr 2004 22:11:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, I've submitted another working version of the MSRP core spec draft. Until it hits the repository, you can find it at: http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-05.txt ...or... http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-05.html. This version takes a shot at adding the SIMS draft styled chunking, and DSN handling. It also adds Chris Boulton as a co-author, as the DSN text is his work. I have also fixed some syntax issues, and attempted to fix some unclear terminology about the remote URL path handling, both pointed out by Miguel Garcia. As I mentioned, this is still a working draft. We still need to do the work to change framing, allowing all mime headers, etc. Also, I have not yet changed anything based Orit's draft and the surrounding discussion. I will make any necessary changes there after the discussion converges some more. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 12 23:19:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03764 for ; Mon, 12 Apr 2004 23:19:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDERn-0005F8-7s for simple-archive@odin.ietf.org; Mon, 12 Apr 2004 23:18:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D3IpLg020153 for simple-archive@odin.ietf.org; Mon, 12 Apr 2004 23:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDERm-0005Ey-W7 for simple-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 23:18:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03744 for ; Mon, 12 Apr 2004 23:18:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDERj-0006Oc-00 for simple-web-archive@ietf.org; Mon, 12 Apr 2004 23:18:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEQM-0006Kl-00 for simple-web-archive@ietf.org; Mon, 12 Apr 2004 23:17:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDEPD-0006H6-00; Mon, 12 Apr 2004 23:16:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEP2-000514-RP; Mon, 12 Apr 2004 23:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEOp-0004zq-33 for simple@optimus.ietf.org; Mon, 12 Apr 2004 23:15:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03593 for ; Mon, 12 Apr 2004 23:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEOk-0006Fh-00 for simple@ietf.org; Mon, 12 Apr 2004 23:15:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEN2-0006Aq-00 for simple@ietf.org; Mon, 12 Apr 2004 23:13:57 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BDEL5-00065U-00 for simple@ietf.org; Mon, 12 Apr 2004 23:11:55 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3D3BnIx087693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Apr 2004 22:11:50 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407B5A73.1050506@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Yet another draft update Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Apr 2004 22:11:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I've submitted another working version of the MSRP core spec draft. Until it hits the repository, you can find it at: http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-05.txt ...or... http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-05.html. This version takes a shot at adding the SIMS draft styled chunking, and DSN handling. It also adds Chris Boulton as a co-author, as the DSN text is his work. I have also fixed some syntax issues, and attempted to fix some unclear terminology about the remote URL path handling, both pointed out by Miguel Garcia. As I mentioned, this is still a working draft. We still need to do the work to change framing, allowing all mime headers, etc. Also, I have not yet changed anything based Orit's draft and the surrounding discussion. I will make any necessary changes there after the discussion converges some more. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 03:12:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24960 for ; Tue, 13 Apr 2004 03:12:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI5f-0000WR-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 03:12:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDI2a-0000DS-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 03:09:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDHzt-00001e-00; Tue, 13 Apr 2004 03:06:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDHzd-0002en-Ui; Tue, 13 Apr 2004 03:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDHzA-0002da-CX for simple@optimus.ietf.org; Tue, 13 Apr 2004 03:05:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24556 for ; Tue, 13 Apr 2004 03:05:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDHz5-0007lB-00 for simple@ietf.org; Tue, 13 Apr 2004 03:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHwc-0007eu-00 for simple@ietf.org; Tue, 13 Apr 2004 03:02:55 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BDHvF-0007YP-00 for simple@ietf.org; Tue, 13 Apr 2004 03:01:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D70Lk02253; Tue, 13 Apr 2004 10:00:21 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 09:59:39 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3D6xduH004969; Tue, 13 Apr 2004 09:59:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00qbR95f; Tue, 13 Apr 2004 09:59:38 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D6xYs10225; Tue, 13 Apr 2004 09:59:34 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 09:59:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D2@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABHVohhZwkdFRBOap8axIdcipwFIxIcQ To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 06:59:32.0703 (UTC) FILETIME=[DF97E6F0:01C42124] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 09:59:31 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Here is the hotel information: Renaissance Boston Hotel Bedford 44 Middlesex Turnpike Bedford, MA 01730 USA Phone: 1 781-275-5500 Fax: 1 781-275-3042 http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB There are 50 rooms booked for this event at the rate of $99 per night = (from Sunday 23rd until Wednesday 26th). These rooms will be held until = 3th May, so please reserve your room on or before that date. You can reserve online or by telephone using the Group Code: NONOKA Also, please use the links that Rohan provided to confirm your = attendance. This will aid us in determining the catering requirements. = Here is the link again: mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim= ]yes Thanks, Hisham > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 06.April.2004 20:54 > To: simple@ietf.org > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > Rohan Mahy; Alan Johnston; Adam Roach > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Hello All, >=20 > Please mark your calendars. >=20 > I'd like to announce a joint interim of the SIP, SIPPING,=20 > SIMPLE, and =20 > XCON WGs. > Nokia has generously agreed to host the event either at their=20 > offices =20 > near Boston or in a neighboring hotel during the week of May 24. >=20 > Please reserve the following dates for the WGs that you are=20 > interested =20 > in: > Monday May 24 SIP and SIPPING tentatively 9 am start > Tuesday May 25 SIMPLE All day > Wednesday May 26 XCON tentatively finish at 4pm so folks can catch =20 > flights. > (the actual agenda is subject to change, including the dates=20 > of various =20 > WG meetings). >=20 > There will be no fee, however please let Hisham and myself=20 > know if you =20 > are planning to attend by clicking on the Yes or Maybe links below: >=20 > mailto:rohan@cisco.com?=20 > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > mailto:rohan@cisco.com?=20 > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe >=20 > Wireless will be provided. As usual, I will be making=20 > T-shirts. If you =20 > are interested in buying one, please send your shirt size to me. >=20 > More details on the agenda and hotel accommodations will be=20 > forthcoming =20 > shortly. >=20 > thanks, > -rohan >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 03:12:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25007 for ; Tue, 13 Apr 2004 03:12:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI5j-00040j-1J for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 03:12:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D7CIoF015413 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 03:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI5i-00040T-Cz for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 03:12:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24961 for ; Tue, 13 Apr 2004 03:12:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI5f-0000WS-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 03:12:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDI2b-0000Db-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 03:09:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDHzt-00001e-00; Tue, 13 Apr 2004 03:06:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDHzd-0002en-Ui; Tue, 13 Apr 2004 03:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDHzA-0002da-CX for simple@optimus.ietf.org; Tue, 13 Apr 2004 03:05:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24556 for ; Tue, 13 Apr 2004 03:05:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDHz5-0007lB-00 for simple@ietf.org; Tue, 13 Apr 2004 03:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHwc-0007eu-00 for simple@ietf.org; Tue, 13 Apr 2004 03:02:55 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BDHvF-0007YP-00 for simple@ietf.org; Tue, 13 Apr 2004 03:01:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D70Lk02253; Tue, 13 Apr 2004 10:00:21 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 09:59:39 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3D6xduH004969; Tue, 13 Apr 2004 09:59:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00qbR95f; Tue, 13 Apr 2004 09:59:38 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D6xYs10225; Tue, 13 Apr 2004 09:59:34 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 09:59:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D2@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABHVohhZwkdFRBOap8axIdcipwFIxIcQ To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 06:59:32.0703 (UTC) FILETIME=[DF97E6F0:01C42124] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 09:59:31 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is the hotel information: Renaissance Boston Hotel Bedford 44 Middlesex Turnpike Bedford, MA 01730 USA Phone: 1 781-275-5500 Fax: 1 781-275-3042 http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB There are 50 rooms booked for this event at the rate of $99 per night = (from Sunday 23rd until Wednesday 26th). These rooms will be held until = 3th May, so please reserve your room on or before that date. You can reserve online or by telephone using the Group Code: NONOKA Also, please use the links that Rohan provided to confirm your = attendance. This will aid us in determining the catering requirements. = Here is the link again: mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim= ]yes Thanks, Hisham > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 06.April.2004 20:54 > To: simple@ietf.org > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > Rohan Mahy; Alan Johnston; Adam Roach > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Hello All, >=20 > Please mark your calendars. >=20 > I'd like to announce a joint interim of the SIP, SIPPING,=20 > SIMPLE, and =20 > XCON WGs. > Nokia has generously agreed to host the event either at their=20 > offices =20 > near Boston or in a neighboring hotel during the week of May 24. >=20 > Please reserve the following dates for the WGs that you are=20 > interested =20 > in: > Monday May 24 SIP and SIPPING tentatively 9 am start > Tuesday May 25 SIMPLE All day > Wednesday May 26 XCON tentatively finish at 4pm so folks can catch =20 > flights. > (the actual agenda is subject to change, including the dates=20 > of various =20 > WG meetings). >=20 > There will be no fee, however please let Hisham and myself=20 > know if you =20 > are planning to attend by clicking on the Yes or Maybe links below: >=20 > mailto:rohan@cisco.com?=20 > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > mailto:rohan@cisco.com?=20 > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe >=20 > Wireless will be provided. As usual, I will be making=20 > T-shirts. If you =20 > are interested in buying one, please send your shirt size to me. >=20 > More details on the agenda and hotel accommodations will be=20 > forthcoming =20 > shortly. >=20 > thanks, > -rohan >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 03:39:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26176 for ; Tue, 13 Apr 2004 03:39:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDIWC-0002Ij-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 03:39:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDIMO-0001kl-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 03:29:33 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDIIT-0001KB-00; Tue, 13 Apr 2004 03:25:29 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDI3t-0000H2-1W; Tue, 13 Apr 2004 03:10:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI3V-0003SX-Pf; Tue, 13 Apr 2004 03:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI2d-0003Mj-Dz for simple@optimus.ietf.org; Tue, 13 Apr 2004 03:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24784 for ; Tue, 13 Apr 2004 03:09:02 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI2X-0000Cf-00 for simple@ietf.org; Tue, 13 Apr 2004 03:09:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHzl-00001L-00 for simple@ietf.org; Tue, 13 Apr 2004 03:06:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDHyC-0007hv-00 for simple@ietf.org; Tue, 13 Apr 2004 03:04:32 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D73jH28752; Tue, 13 Apr 2004 10:03:45 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:02:50 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3D72olQ006537; Tue, 13 Apr 2004 10:02:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004wRMpb; Tue, 13 Apr 2004 10:02:49 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D72ds12761; Tue, 13 Apr 2004 10:02:39 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:02:29 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:02:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D6@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABHVohhZwkdFRBOap8axIdcipwFIxIcQAACAHPA= To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 07:02:28.0008 (UTC) FILETIME=[48155280:01C42125] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 10:02:28 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable One small correction: Rooms will be help until 3rd May. Thanks, Hisham > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: 13.April.2004 10:00 > To: 'ext Rohan Mahy'; simple@ietf.org > Cc: Dean Willis; Allison Mankin; Robert Sparks; John Peterson; Ted > Hardie; Gonzalo Camarillo; Alan Johnston; Adam Roach > Subject: RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Here is the hotel information: >=20 > Renaissance Boston Hotel Bedford > 44 Middlesex Turnpike Bedford, MA 01730 USA > Phone: 1 781-275-5500 Fax: 1 781-275-3042 >=20 > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB >=20 > There are 50 rooms booked for this event at the rate of $99=20 > per night (from Sunday 23rd until Wednesday 26th). These=20 > rooms will be held until 3th May, so please reserve your room=20 > on or before that date. >=20 > You can reserve online or by telephone using the Group Code: NONOKA >=20 > Also, please use the links that Rohan provided to confirm=20 > your attendance. This will aid us in determining the catering=20 > requirements. Here is the link again: >=20 > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > interim]yes >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 06.April.2004 20:54 > > To: simple@ietf.org > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > > Rohan Mahy; Alan Johnston; Adam Roach > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Hello All, > >=20 > > Please mark your calendars. > >=20 > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > SIMPLE, and =20 > > XCON WGs. > > Nokia has generously agreed to host the event either at their=20 > > offices =20 > > near Boston or in a neighboring hotel during the week of May 24. > >=20 > > Please reserve the following dates for the WGs that you are=20 > > interested =20 > > in: > > Monday May 24 SIP and SIPPING tentatively 9 am start > > Tuesday May 25 SIMPLE All day > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > can catch =20 > > flights. > > (the actual agenda is subject to change, including the dates=20 > > of various =20 > > WG meetings). > >=20 > > There will be no fee, however please let Hisham and myself=20 > > know if you =20 > > are planning to attend by clicking on the Yes or Maybe links below: > >=20 > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > >=20 > > Wireless will be provided. As usual, I will be making=20 > > T-shirts. If you =20 > > are interested in buying one, please send your shirt size to me. > >=20 > > More details on the agenda and hotel accommodations will be=20 > > forthcoming =20 > > shortly. > >=20 > > thanks, > > -rohan > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 03:40:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26247 for ; Tue, 13 Apr 2004 03:40:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDIWO-0008Rz-6J for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 03:39:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D7dqLt032479 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 03:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDIWN-0008Ri-Sq for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 03:39:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26204 for ; Tue, 13 Apr 2004 03:39:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDIWJ-0002Iu-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 03:39:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDIMP-0001kt-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 03:29:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDIIT-0001KB-00; Tue, 13 Apr 2004 03:25:29 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDI3t-0000H2-1W; Tue, 13 Apr 2004 03:10:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI3V-0003SX-Pf; Tue, 13 Apr 2004 03:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI2d-0003Mj-Dz for simple@optimus.ietf.org; Tue, 13 Apr 2004 03:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24784 for ; Tue, 13 Apr 2004 03:09:02 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI2X-0000Cf-00 for simple@ietf.org; Tue, 13 Apr 2004 03:09:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHzl-00001L-00 for simple@ietf.org; Tue, 13 Apr 2004 03:06:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDHyC-0007hv-00 for simple@ietf.org; Tue, 13 Apr 2004 03:04:32 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D73jH28752; Tue, 13 Apr 2004 10:03:45 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:02:50 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3D72olQ006537; Tue, 13 Apr 2004 10:02:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004wRMpb; Tue, 13 Apr 2004 10:02:49 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D72ds12761; Tue, 13 Apr 2004 10:02:39 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:02:29 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:02:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D6@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABHVohhZwkdFRBOap8axIdcipwFIxIcQAACAHPA= To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 07:02:28.0008 (UTC) FILETIME=[48155280:01C42125] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 10:02:28 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable One small correction: Rooms will be help until 3rd May. Thanks, Hisham > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: 13.April.2004 10:00 > To: 'ext Rohan Mahy'; simple@ietf.org > Cc: Dean Willis; Allison Mankin; Robert Sparks; John Peterson; Ted > Hardie; Gonzalo Camarillo; Alan Johnston; Adam Roach > Subject: RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Here is the hotel information: >=20 > Renaissance Boston Hotel Bedford > 44 Middlesex Turnpike Bedford, MA 01730 USA > Phone: 1 781-275-5500 Fax: 1 781-275-3042 >=20 > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB >=20 > There are 50 rooms booked for this event at the rate of $99=20 > per night (from Sunday 23rd until Wednesday 26th). These=20 > rooms will be held until 3th May, so please reserve your room=20 > on or before that date. >=20 > You can reserve online or by telephone using the Group Code: NONOKA >=20 > Also, please use the links that Rohan provided to confirm=20 > your attendance. This will aid us in determining the catering=20 > requirements. Here is the link again: >=20 > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > interim]yes >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 06.April.2004 20:54 > > To: simple@ietf.org > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > > Rohan Mahy; Alan Johnston; Adam Roach > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Hello All, > >=20 > > Please mark your calendars. > >=20 > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > SIMPLE, and =20 > > XCON WGs. > > Nokia has generously agreed to host the event either at their=20 > > offices =20 > > near Boston or in a neighboring hotel during the week of May 24. > >=20 > > Please reserve the following dates for the WGs that you are=20 > > interested =20 > > in: > > Monday May 24 SIP and SIPPING tentatively 9 am start > > Tuesday May 25 SIMPLE All day > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > can catch =20 > > flights. > > (the actual agenda is subject to change, including the dates=20 > > of various =20 > > WG meetings). > >=20 > > There will be no fee, however please let Hisham and myself=20 > > know if you =20 > > are planning to attend by clicking on the Yes or Maybe links below: > >=20 > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > >=20 > > Wireless will be provided. As usual, I will be making=20 > > T-shirts. If you =20 > > are interested in buying one, please send your shirt size to me. > >=20 > > More details on the agenda and hotel accommodations will be=20 > > forthcoming =20 > > shortly. > >=20 > > thanks, > > -rohan > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 04:32:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28776 for ; Tue, 13 Apr 2004 04:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDJLL-0005JT-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 04:32:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDJJk-0005Cr-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 04:30:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDJI4-00056y-00; Tue, 13 Apr 2004 04:29:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJHx-0003aw-4b; Tue, 13 Apr 2004 04:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJHN-0003aV-A1 for simple@optimus.ietf.org; Tue, 13 Apr 2004 04:28:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28614 for ; Tue, 13 Apr 2004 04:28:23 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDJHK-00054c-00 for simple@ietf.org; Tue, 13 Apr 2004 04:28:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDJF9-0004xD-00 for simple@ietf.org; Tue, 13 Apr 2004 04:26:08 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BDJD1-0004nR-00 for simple@ietf.org; Tue, 13 Apr 2004 04:23:55 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D8Nok07265; Tue, 13 Apr 2004 11:23:50 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 11:23:04 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3D8N4CF020596; Tue, 13 Apr 2004 11:23:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 0057kQSF; Tue, 13 Apr 2004 11:22:39 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D8MYF28357; Tue, 13 Apr 2004 11:22:34 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 11:21:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978DB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQdyhERXdzXRkr4QniP3CrKlzsSUADYm0aw To: , X-OriginalArrivalTime: 13 Apr 2004 08:21:15.0528 (UTC) FILETIME=[49E7A080:01C42130] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 11:21:14 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable First off, let me say that I do not like 1 at all. You need some sort of = protocol level ACKs on messages. You cannot guarantee that if a TCP = socket received a message that also an application on top has also = received it. There could be a socket listing but the application on top = has crashed. Now, hop-by-hop vs. end-to-end: In this scenario (hop-by-hop) A R1 R2 B SEND------> <--------OK SEND------> <--------OK SEND------> <--------OK The OK does not tell the sender anything about the final delivery of the = SEND. It only tells that the next hop has successfully received the = SEND. Why is that important? Why is it important for A, R1 and R2 to = know that the next hop has received the SEND? Why isn't TCP good enough = here? That's the question that needs answering. In this scenario (end-to-end) A R1 R2 B SEND------> SEND------> SEND------> <------DSN <-------DSN <-------DSN IMO, the relays need to keep state and a timer, and sending a DSN is = mandatory. If the DSN does not arrive after x units of time, a failure = DSN is generated by the last hop that forwarded the SEND. Something like A R1 R2 B SEND------> SEND------> SEND--X <-------DSN (failure) <-------DSN Ben commented that "even if it (the relay) _did_ keep state, it would = have no good way to know where in the message stream the error occured." = My question is: is it important, say for R1, to know where the error = occured (at R2, R3, R4 or B)? Ben, can you also elaborate of this: > If we do decide to change (back) to e2e SEND requests ... There=20 > would be more impact on the relay spec. Thanks, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 09.April.2004 00:14 > To: Simple WG > Subject: [Simple] MSRP message reliability(long) >=20 >=20 > Hopefully, everyone has had a chance to look at Orit's draft=20 > giving an=20 > analysis and some recommendations concerning the way MSRP handles=20 > message acknowledgements. I responded separately with=20 > specific comments=20 > about that draft. However, I want to talk in general about the models=20 > that have been proposed, as I understand them. >=20 > First, I would like to clarify the reliability requirements, as I see=20 > them, a little. As I see it, when I send a message, there are three=20 > levels of reliability that I might care about. Consider the following=20 > scenarios: >=20 > 1) I really don't care at all. (Strangely, this is the mode used by a=20 > lot of existing large scale systems. If we are dealing with highly=20 > interactive conversations between humans, humans provide their own=20 > reliability mechanism. I find myself typing "Hey, did you get my IM=20 > about X a few minutes ago" frequently.) >=20 > 2) I want a good effort to deliver, and a good attempt to tell me if=20 > something went wrong. If I hear nothing, I assume it most=20 > likely worked. >=20 > 3) Delivery is critical. I want to be told that it worked, and if I=20 > don't hear anything, I assume it most likely failed. >=20 > My personal opinion is that 1 is generally unacceptable=20 > (dispite current=20 > systems), 3 should be an option, but 2 will be the primary=20 > use case, and=20 > the one we should optimize for. The rest of this email takes that=20 > perspective; if consensus proves me wrong then my analysis=20 > will change. >=20 > We have a controversy about whether MSRP, in the general case where=20 > relays exist, should use per-hop transaction acknowledgements, or=20 > whether acknowledgments should be strictly end-to-end. >=20 > First, let us consider the success cases; that is, when everything=20 > works. The per-hop case looks something like the following: >=20 > A R1 R2 B > SEND------> > <--------OK > SEND------> > <--------OK > SEND------> > <--------OK >=20 >=20 > This is not-optimal for the happy case, because each device=20 > has to keep=20 > transaction state until it gets a response. This state is=20 > _only_ useful=20 > if a failure occurs. (We will look at failure cases in a minute.)=20 > However, this state is not huge. As currently defined in=20 > MSRP, it would=20 > be the transaction identity and a timer. Adam proposed we do=20 > not need a=20 > mandatory timer, which would make it even smaller. >=20 > In a perfect world, the end-to-end approach would look like: >=20 > A R1 R2 B > SEND------> > SEND------> > SEND------> >=20 > This looks great on the surface. Not only can the relays be=20 > transaction=20 > stateless, only half as many messages happen. But, for reasons I will=20 > explain in a moment, this approach makes it impractical to tell A if=20 > something goes wrong downstream. Therefore, in a realistic=20 > implementation, it looks more like: >=20 > A R1 R2 B > SEND------> > SEND------> > SEND------> > <---DSN(success) > <-------DSN > <-------DSN >=20 > This has the same number of messages. It does allow the relays to be=20 > stateless. >=20 > So, now, lets assume a TCP failure happens between R1 and R2. >=20 > The hop-hop case looks like the following. A gets a failure=20 > notification=20 > shortly after R1 notices the failure. >=20 > A R1 R2 B > SEND------> > <--------OK > SEND----X > <----DSN(fail) >=20 > One would hope to make the end-to-end case look similar. But, as I=20 > mentioned before, that is impractical. Assume R1 has had a TCP=20 > connection to R2 up for some time. R1 has sent a lot of=20 > messages in that=20 > time, including the one for A above. With hop-hop responses, R1 keeps=20 > state around for each message it relays, and destroys that=20 > state when it=20 > gets an OK response. When the TCP failure occurs, R1 sends failure=20 > reports for all messages for which it still has state. >=20 > But in the end-end case, R1 cannot report the failure. (We=20 > said R1 would=20 > keep no state for end-to-end, remember.) But even if it _did_ keep=20 > state, it would have no good way to know where in the message=20 > stream the=20 > error occured. Unless it does something _extremely_ stateful,=20 > like watch=20 > for success DSNs to go by, then when a TCP error occurs, it=20 > must assume=20 > that every message it has every relayed on that connection=20 > failed, or at=20 > least every message sent for the past 9 minutes or so failed.=20 > (9 minutes=20 > being the normal time requried for the _application_ to learn of some=20 > TCP failures.) Since 9 minutes is an eternity for a busy=20 > relay, I assume=20 > this is not acceptable. Rather, the relay would report=20 > nothing. The flow=20 > would look like the following: >=20 > A R1 R2 B > SEND------> > SEND---X >=20 >=20 > A would eventually figure out the message failure due to the=20 > lack of a=20 > success report. A would have to wait some time before making this=20 > decision to avoid a high likelyhood of false positives. Using the 9=20 > minute failure detection time above, this time would be=20 > something like=20 > (9*number of hops * 2) minutes. >=20 > So, back to our scenarios. For scenario 1, the end-end=20 > approach clearly=20 > wins, assuming we have the option to turn off DSN entirely.=20 > Orit's draft=20 > suggested that, with all responses turned off, a relay would=20 > have about=20 > a %20 scale advantage. However, her experiment was based on SIP=20 > messages, which tend to be larger, more complicated to parse,=20 > and have a=20 > more complex transaction model, even over TCP. I have no way=20 > of knowing=20 > how much the SIP vs MSRP aspect will impact things, but I think it is=20 > safe to say that the savings for MSRP will be real, but less than the=20 > %20 savings she observed for SIP. >=20 > For scenario 2, it is a harder call. The number of messages=20 > is the same=20 > for either approach. The work to do message parsing, etc is similar.=20 > Relays will have to keep state for the hop-hop approach,=20 > although if we=20 > accept Adam's proposal about removing transaction timers,=20 > this state is=20 > fairly small. Also, the time it requires for the sender to=20 > learn about=20 > the failure is considerably shorter for the hop-hop approach than for=20 > the end-end approach. Therefore, I personally think the=20 > hop-hop approach=20 > wins this one. >=20 > For scenario 3, an end-end receipt will be required anytime=20 > relays are=20 > present. This means the hop-hop approach will require more=20 > messages than=20 > the end-end, giving the round to the end-end. >=20 > So, considering that I believe 2 is the primary use case, I=20 > lean towards=20 > the hop-hop case. >=20 > I would also like to address a few arguments that I have heard, and=20 > believe to be red herrings: >=20 > 1) A failure report cannot be interpreted with certainty to=20 > mean that a=20 > message was not delivered. There are a number of edge cases where you=20 > can successfully deliver a message, but report it failed.=20 > However, this=20 > is _also_ true with the end-end case; as it is possible for=20 > the success=20 > report itself to get lost. We can build a system that never claims=20 > success unless it was really successful, but we cannot build a system=20 > that never claims failure unless it really failed. >=20 > 2) Since the TCP connections are used in both directions,=20 > responses may=20 > backup behind IMs sent in the reverse direction. This has been an=20 > acknowledged problem with the use of full-duplex connections from the=20 > beginning. But the problem exists for the end-end case as well, as=20 > success reports can _also_ get stuck in traffic. We are=20 > taking steps in=20 > MSRP (chunking, possible removal of transaction timers) that I think=20 > will mitigate this somewhat. >=20 > Conclusions: >=20 > I personally prefer the hop-hop approach, with DSN on failure=20 > and DSN on=20 > success as optional. However, if I am in the minority on that=20 > point, I=20 > can live with the end to end model. I do, however, want the=20 > transaction=20 > model to be consistent. That is, I don't want to negotiate whether we=20 > send hop-hop transaction responses to SEND requests. Either=20 > MSRP calls=20 > for them, or it does not. >=20 > Further, the VISIT request, and I assume BIND or whatever=20 > equivelant we=20 > come up with in the relay work, necessarily follow a hop-hop model.=20 > Making SEND end-end creates an inconsistency there. >=20 > If we do decide to change (back) to e2e SEND requests, the=20 > impact on the=20 > base spec is not huge; it would involve taking away the transaction=20 > response to SEND, and putting in a stronger dependency on DSN. There=20 > would be more impact on the relay spec. >=20 > Thanks! >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 04:33:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28849 for ; Tue, 13 Apr 2004 04:33:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJLV-0003n6-CP for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 04:32:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D8WfOJ014573 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 04:32:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJLV-0003my-62 for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 04:32:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28801 for ; Tue, 13 Apr 2004 04:32:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDJLR-0005Jz-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 04:32:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDJJn-0005DH-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 04:30:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDJI4-00056y-00; Tue, 13 Apr 2004 04:29:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJHx-0003aw-4b; Tue, 13 Apr 2004 04:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJHN-0003aV-A1 for simple@optimus.ietf.org; Tue, 13 Apr 2004 04:28:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28614 for ; Tue, 13 Apr 2004 04:28:23 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDJHK-00054c-00 for simple@ietf.org; Tue, 13 Apr 2004 04:28:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDJF9-0004xD-00 for simple@ietf.org; Tue, 13 Apr 2004 04:26:08 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BDJD1-0004nR-00 for simple@ietf.org; Tue, 13 Apr 2004 04:23:55 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D8Nok07265; Tue, 13 Apr 2004 11:23:50 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 11:23:04 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3D8N4CF020596; Tue, 13 Apr 2004 11:23:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 0057kQSF; Tue, 13 Apr 2004 11:22:39 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3D8MYF28357; Tue, 13 Apr 2004 11:22:34 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 11:21:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978DB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQdyhERXdzXRkr4QniP3CrKlzsSUADYm0aw To: , X-OriginalArrivalTime: 13 Apr 2004 08:21:15.0528 (UTC) FILETIME=[49E7A080:01C42130] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 11:21:14 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable First off, let me say that I do not like 1 at all. You need some sort of = protocol level ACKs on messages. You cannot guarantee that if a TCP = socket received a message that also an application on top has also = received it. There could be a socket listing but the application on top = has crashed. Now, hop-by-hop vs. end-to-end: In this scenario (hop-by-hop) A R1 R2 B SEND------> <--------OK SEND------> <--------OK SEND------> <--------OK The OK does not tell the sender anything about the final delivery of the = SEND. It only tells that the next hop has successfully received the = SEND. Why is that important? Why is it important for A, R1 and R2 to = know that the next hop has received the SEND? Why isn't TCP good enough = here? That's the question that needs answering. In this scenario (end-to-end) A R1 R2 B SEND------> SEND------> SEND------> <------DSN <-------DSN <-------DSN IMO, the relays need to keep state and a timer, and sending a DSN is = mandatory. If the DSN does not arrive after x units of time, a failure = DSN is generated by the last hop that forwarded the SEND. Something like A R1 R2 B SEND------> SEND------> SEND--X <-------DSN (failure) <-------DSN Ben commented that "even if it (the relay) _did_ keep state, it would = have no good way to know where in the message stream the error occured." = My question is: is it important, say for R1, to know where the error = occured (at R2, R3, R4 or B)? Ben, can you also elaborate of this: > If we do decide to change (back) to e2e SEND requests ... There=20 > would be more impact on the relay spec. Thanks, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 09.April.2004 00:14 > To: Simple WG > Subject: [Simple] MSRP message reliability(long) >=20 >=20 > Hopefully, everyone has had a chance to look at Orit's draft=20 > giving an=20 > analysis and some recommendations concerning the way MSRP handles=20 > message acknowledgements. I responded separately with=20 > specific comments=20 > about that draft. However, I want to talk in general about the models=20 > that have been proposed, as I understand them. >=20 > First, I would like to clarify the reliability requirements, as I see=20 > them, a little. As I see it, when I send a message, there are three=20 > levels of reliability that I might care about. Consider the following=20 > scenarios: >=20 > 1) I really don't care at all. (Strangely, this is the mode used by a=20 > lot of existing large scale systems. If we are dealing with highly=20 > interactive conversations between humans, humans provide their own=20 > reliability mechanism. I find myself typing "Hey, did you get my IM=20 > about X a few minutes ago" frequently.) >=20 > 2) I want a good effort to deliver, and a good attempt to tell me if=20 > something went wrong. If I hear nothing, I assume it most=20 > likely worked. >=20 > 3) Delivery is critical. I want to be told that it worked, and if I=20 > don't hear anything, I assume it most likely failed. >=20 > My personal opinion is that 1 is generally unacceptable=20 > (dispite current=20 > systems), 3 should be an option, but 2 will be the primary=20 > use case, and=20 > the one we should optimize for. The rest of this email takes that=20 > perspective; if consensus proves me wrong then my analysis=20 > will change. >=20 > We have a controversy about whether MSRP, in the general case where=20 > relays exist, should use per-hop transaction acknowledgements, or=20 > whether acknowledgments should be strictly end-to-end. >=20 > First, let us consider the success cases; that is, when everything=20 > works. The per-hop case looks something like the following: >=20 > A R1 R2 B > SEND------> > <--------OK > SEND------> > <--------OK > SEND------> > <--------OK >=20 >=20 > This is not-optimal for the happy case, because each device=20 > has to keep=20 > transaction state until it gets a response. This state is=20 > _only_ useful=20 > if a failure occurs. (We will look at failure cases in a minute.)=20 > However, this state is not huge. As currently defined in=20 > MSRP, it would=20 > be the transaction identity and a timer. Adam proposed we do=20 > not need a=20 > mandatory timer, which would make it even smaller. >=20 > In a perfect world, the end-to-end approach would look like: >=20 > A R1 R2 B > SEND------> > SEND------> > SEND------> >=20 > This looks great on the surface. Not only can the relays be=20 > transaction=20 > stateless, only half as many messages happen. But, for reasons I will=20 > explain in a moment, this approach makes it impractical to tell A if=20 > something goes wrong downstream. Therefore, in a realistic=20 > implementation, it looks more like: >=20 > A R1 R2 B > SEND------> > SEND------> > SEND------> > <---DSN(success) > <-------DSN > <-------DSN >=20 > This has the same number of messages. It does allow the relays to be=20 > stateless. >=20 > So, now, lets assume a TCP failure happens between R1 and R2. >=20 > The hop-hop case looks like the following. A gets a failure=20 > notification=20 > shortly after R1 notices the failure. >=20 > A R1 R2 B > SEND------> > <--------OK > SEND----X > <----DSN(fail) >=20 > One would hope to make the end-to-end case look similar. But, as I=20 > mentioned before, that is impractical. Assume R1 has had a TCP=20 > connection to R2 up for some time. R1 has sent a lot of=20 > messages in that=20 > time, including the one for A above. With hop-hop responses, R1 keeps=20 > state around for each message it relays, and destroys that=20 > state when it=20 > gets an OK response. When the TCP failure occurs, R1 sends failure=20 > reports for all messages for which it still has state. >=20 > But in the end-end case, R1 cannot report the failure. (We=20 > said R1 would=20 > keep no state for end-to-end, remember.) But even if it _did_ keep=20 > state, it would have no good way to know where in the message=20 > stream the=20 > error occured. Unless it does something _extremely_ stateful,=20 > like watch=20 > for success DSNs to go by, then when a TCP error occurs, it=20 > must assume=20 > that every message it has every relayed on that connection=20 > failed, or at=20 > least every message sent for the past 9 minutes or so failed.=20 > (9 minutes=20 > being the normal time requried for the _application_ to learn of some=20 > TCP failures.) Since 9 minutes is an eternity for a busy=20 > relay, I assume=20 > this is not acceptable. Rather, the relay would report=20 > nothing. The flow=20 > would look like the following: >=20 > A R1 R2 B > SEND------> > SEND---X >=20 >=20 > A would eventually figure out the message failure due to the=20 > lack of a=20 > success report. A would have to wait some time before making this=20 > decision to avoid a high likelyhood of false positives. Using the 9=20 > minute failure detection time above, this time would be=20 > something like=20 > (9*number of hops * 2) minutes. >=20 > So, back to our scenarios. For scenario 1, the end-end=20 > approach clearly=20 > wins, assuming we have the option to turn off DSN entirely.=20 > Orit's draft=20 > suggested that, with all responses turned off, a relay would=20 > have about=20 > a %20 scale advantage. However, her experiment was based on SIP=20 > messages, which tend to be larger, more complicated to parse,=20 > and have a=20 > more complex transaction model, even over TCP. I have no way=20 > of knowing=20 > how much the SIP vs MSRP aspect will impact things, but I think it is=20 > safe to say that the savings for MSRP will be real, but less than the=20 > %20 savings she observed for SIP. >=20 > For scenario 2, it is a harder call. The number of messages=20 > is the same=20 > for either approach. The work to do message parsing, etc is similar.=20 > Relays will have to keep state for the hop-hop approach,=20 > although if we=20 > accept Adam's proposal about removing transaction timers,=20 > this state is=20 > fairly small. Also, the time it requires for the sender to=20 > learn about=20 > the failure is considerably shorter for the hop-hop approach than for=20 > the end-end approach. Therefore, I personally think the=20 > hop-hop approach=20 > wins this one. >=20 > For scenario 3, an end-end receipt will be required anytime=20 > relays are=20 > present. This means the hop-hop approach will require more=20 > messages than=20 > the end-end, giving the round to the end-end. >=20 > So, considering that I believe 2 is the primary use case, I=20 > lean towards=20 > the hop-hop case. >=20 > I would also like to address a few arguments that I have heard, and=20 > believe to be red herrings: >=20 > 1) A failure report cannot be interpreted with certainty to=20 > mean that a=20 > message was not delivered. There are a number of edge cases where you=20 > can successfully deliver a message, but report it failed.=20 > However, this=20 > is _also_ true with the end-end case; as it is possible for=20 > the success=20 > report itself to get lost. We can build a system that never claims=20 > success unless it was really successful, but we cannot build a system=20 > that never claims failure unless it really failed. >=20 > 2) Since the TCP connections are used in both directions,=20 > responses may=20 > backup behind IMs sent in the reverse direction. This has been an=20 > acknowledged problem with the use of full-duplex connections from the=20 > beginning. But the problem exists for the end-end case as well, as=20 > success reports can _also_ get stuck in traffic. We are=20 > taking steps in=20 > MSRP (chunking, possible removal of transaction timers) that I think=20 > will mitigate this somewhat. >=20 > Conclusions: >=20 > I personally prefer the hop-hop approach, with DSN on failure=20 > and DSN on=20 > success as optional. However, if I am in the minority on that=20 > point, I=20 > can live with the end to end model. I do, however, want the=20 > transaction=20 > model to be consistent. That is, I don't want to negotiate whether we=20 > send hop-hop transaction responses to SEND requests. Either=20 > MSRP calls=20 > for them, or it does not. >=20 > Further, the VISIT request, and I assume BIND or whatever=20 > equivelant we=20 > come up with in the relay work, necessarily follow a hop-hop model.=20 > Making SEND end-end creates an inconsistency there. >=20 > If we do decide to change (back) to e2e SEND requests, the=20 > impact on the=20 > base spec is not huge; it would involve taking away the transaction=20 > response to SEND, and putting in a stronger dependency on DSN. There=20 > would be more impact on the relay spec. >=20 > Thanks! >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 05:13:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00075 for ; Tue, 13 Apr 2004 05:13:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDJz7-0007aq-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 05:13:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDJxb-0007VK-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 05:12:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDJwl-0007Ql-00; Tue, 13 Apr 2004 05:11:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJwb-0006xX-Nt; Tue, 13 Apr 2004 05:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJwZ-0006wy-EH for simple@optimus.ietf.org; Tue, 13 Apr 2004 05:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29981 for ; Tue, 13 Apr 2004 05:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDJwV-0007QK-00 for simple@ietf.org; Tue, 13 Apr 2004 05:10:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDJvM-0007Md-00 for simple@ietf.org; Tue, 13 Apr 2004 05:09:44 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly07b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDJuM-0007Gd-00 for simple@ietf.org; Tue, 13 Apr 2004 05:08:42 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly07b.srv.mailcontrol.com (MailControl) with SMTP id i3D97vI7000856; Tue, 13 Apr 2004 10:07:57 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Tue, 13 Apr 2004 10:07:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Message-ID: <45730E094814E44488F789C1CDED27AE0219B25D@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Thread-Index: AcQdySsmHlD/p8v0R4mdNlAQpB6VzgDbH9yA From: "Chris Boulton" To: "Ben Campbell" , "Orit Levin" Cc: "Simple WG" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 10:07:57 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Comment in-line. > >> o The exact end-to-end operation modes and their negotiation using >> the offer-answer SDP mechanism > >That work is currently in progress. (In fact, Chris Boulon just proposed >some text to me on DSN in general--Yeah Chris!!) > >In the past, though, you have suggested per-message negotiation, rather >than SDP based, i.e. per-session, negotiation. Are you saying you would >now prefer per-session? [Chris Boulton] Sorry for the late response ;-). The current text proposes per message negotiation with a default payload. The only negotiation that can occur at the session level is for an alternative payload type to be negotiated for DSN.=20=20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 05:14:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00120 for ; Tue, 13 Apr 2004 05:14:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJzF-0007FM-QV for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 05:13:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D9Dj1C027852 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 05:13:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJzF-0007F9-M9 for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 05:13:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00093 for ; Tue, 13 Apr 2004 05:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDJzB-0007ay-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 05:13:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDJxc-0007VR-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 05:12:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDJwl-0007Ql-00; Tue, 13 Apr 2004 05:11:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJwb-0006xX-Nt; Tue, 13 Apr 2004 05:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDJwZ-0006wy-EH for simple@optimus.ietf.org; Tue, 13 Apr 2004 05:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29981 for ; Tue, 13 Apr 2004 05:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDJwV-0007QK-00 for simple@ietf.org; Tue, 13 Apr 2004 05:10:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDJvM-0007Md-00 for simple@ietf.org; Tue, 13 Apr 2004 05:09:44 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly07b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDJuM-0007Gd-00 for simple@ietf.org; Tue, 13 Apr 2004 05:08:42 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly07b.srv.mailcontrol.com (MailControl) with SMTP id i3D97vI7000856; Tue, 13 Apr 2004 10:07:57 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Tue, 13 Apr 2004 10:07:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Message-ID: <45730E094814E44488F789C1CDED27AE0219B25D@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] FW: I-D ACTION:draft-levin-simple-msrp-review-00.txt Thread-Index: AcQdySsmHlD/p8v0R4mdNlAQpB6VzgDbH9yA From: "Chris Boulton" To: "Ben Campbell" , "Orit Levin" Cc: "Simple WG" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 10:07:57 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Comment in-line. > >> o The exact end-to-end operation modes and their negotiation using >> the offer-answer SDP mechanism > >That work is currently in progress. (In fact, Chris Boulon just proposed >some text to me on DSN in general--Yeah Chris!!) > >In the past, though, you have suggested per-message negotiation, rather >than SDP based, i.e. per-session, negotiation. Are you saying you would >now prefer per-session? [Chris Boulton] Sorry for the late response ;-). The current text proposes per message negotiation with a default payload. The only negotiation that can occur at the session level is for an alternative payload type to be negotiated for DSN.=20=20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 08:58:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09590 for ; Tue, 13 Apr 2004 08:58:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNUw-0007Dt-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 08:58:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNTS-00077g-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 08:57:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDNSU-00071y-00; Tue, 13 Apr 2004 08:56:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNSL-0002dX-Sb; Tue, 13 Apr 2004 08:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNRt-0002UP-Jx for simple@optimus.ietf.org; Tue, 13 Apr 2004 08:55:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09449 for ; Tue, 13 Apr 2004 08:55:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNRq-0006z1-00 for simple@ietf.org; Tue, 13 Apr 2004 08:55:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNQu-0006tc-00 for simple@ietf.org; Tue, 13 Apr 2004 08:54:34 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BDNPe-0006pK-00 for simple@ietf.org; Tue, 13 Apr 2004 08:53:14 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3DCr1Ix031700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2004 07:53:02 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407BE2AA.7070606@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP message reliability(long) References: <2038BCC78B1AD641891A0D1AE133DBB7017978DB@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017978DB@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 07:52:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > First off, let me say that I do not like 1 at all. You need some sort of protocol level ACKs on messages. You cannot guarantee that if a TCP socket received a message that also an application on top has also received it. There could be a socket listing but the application on top has crashed. > > Now, hop-by-hop vs. end-to-end: > > In this scenario (hop-by-hop) > > A R1 R2 B > SEND------> > <--------OK > SEND------> > <--------OK > SEND------> > <--------OK > > The OK does not tell the sender anything about the final delivery of the SEND. It only tells that the next hop has successfully received the SEND. Why is that important? Why is it important for A, R1 and R2 to know that the next hop has received the SEND? Why isn't TCP good enough here? That's the question that needs answering. The value comes when an error occurs. Lets say R1 has had the connection up to R2 for some time. Then the connection fails in mid session.. Standard TCP interfaces give R1 know way of knowing how much data had been sent before the error occured. Therefore, R1 must assume that _nothing_ got delivered. This ties in with the DSN on error case below. > > > In this scenario (end-to-end) > > A R1 R2 B > SEND------> > SEND------> > SEND------> > <------DSN > <-------DSN > <-------DSN > > IMO, the relays need to keep state and a timer, and sending a DSN is mandatory. If the DSN does not arrive after x units of time, a failure DSN is generated by the last hop that forwarded the SEND. Something like > > A R1 R2 B > SEND------> > SEND------> > SEND--X > <-------DSN (failure) > <-------DSN > > Ben commented that "even if it (the relay) _did_ keep state, it would have no good way to know where in the message stream the error occured." My question is: is it important, say for R1, to know where the error occured (at R2, R3, R4 or B)? > Sorry, I was unclear. I did not mean where the error occured in space, but rather in time. As in my example above, R2 has no way of knowing how much data got sent before the error occured. So how does he know which messages require DSN? He must assume the answer is "all of them", or at least "all of them for the last 9 or so minutes", since that is the typical time TCP will keep retransmitting before it gives up. > Ben, can you also elaborate of this: > > >>If we do decide to change (back) to e2e SEND requests ... There >>would be more impact on the relay spec. > > > Thanks, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 09.April.2004 00:14 >>To: Simple WG >>Subject: [Simple] MSRP message reliability(long) >> >> >>Hopefully, everyone has had a chance to look at Orit's draft >>giving an >>analysis and some recommendations concerning the way MSRP handles >>message acknowledgements. I responded separately with >>specific comments >>about that draft. However, I want to talk in general about the models >>that have been proposed, as I understand them. >> >>First, I would like to clarify the reliability requirements, as I see >>them, a little. As I see it, when I send a message, there are three >>levels of reliability that I might care about. Consider the following >>scenarios: >> >>1) I really don't care at all. (Strangely, this is the mode used by a >>lot of existing large scale systems. If we are dealing with highly >>interactive conversations between humans, humans provide their own >>reliability mechanism. I find myself typing "Hey, did you get my IM >>about X a few minutes ago" frequently.) >> >>2) I want a good effort to deliver, and a good attempt to tell me if >>something went wrong. If I hear nothing, I assume it most >>likely worked. >> >>3) Delivery is critical. I want to be told that it worked, and if I >>don't hear anything, I assume it most likely failed. >> >>My personal opinion is that 1 is generally unacceptable >>(dispite current >>systems), 3 should be an option, but 2 will be the primary >>use case, and >>the one we should optimize for. The rest of this email takes that >>perspective; if consensus proves me wrong then my analysis >>will change. >> >>We have a controversy about whether MSRP, in the general case where >>relays exist, should use per-hop transaction acknowledgements, or >>whether acknowledgments should be strictly end-to-end. >> >>First, let us consider the success cases; that is, when everything >>works. The per-hop case looks something like the following: >> >> A R1 R2 B >> SEND------> >> <--------OK >> SEND------> >> <--------OK >> SEND------> >> <--------OK >> >> >>This is not-optimal for the happy case, because each device >>has to keep >>transaction state until it gets a response. This state is >>_only_ useful >>if a failure occurs. (We will look at failure cases in a minute.) >>However, this state is not huge. As currently defined in >>MSRP, it would >>be the transaction identity and a timer. Adam proposed we do >>not need a >>mandatory timer, which would make it even smaller. >> >>In a perfect world, the end-to-end approach would look like: >> >> A R1 R2 B >> SEND------> >> SEND------> >> SEND------> >> >>This looks great on the surface. Not only can the relays be >>transaction >>stateless, only half as many messages happen. But, for reasons I will >>explain in a moment, this approach makes it impractical to tell A if >>something goes wrong downstream. Therefore, in a realistic >>implementation, it looks more like: >> >> A R1 R2 B >> SEND------> >> SEND------> >> SEND------> >> <---DSN(success) >> <-------DSN >> <-------DSN >> >>This has the same number of messages. It does allow the relays to be >>stateless. >> >>So, now, lets assume a TCP failure happens between R1 and R2. >> >>The hop-hop case looks like the following. A gets a failure >>notification >>shortly after R1 notices the failure. >> >> A R1 R2 B >> SEND------> >> <--------OK >> SEND----X >> <----DSN(fail) >> >>One would hope to make the end-to-end case look similar. But, as I >>mentioned before, that is impractical. Assume R1 has had a TCP >>connection to R2 up for some time. R1 has sent a lot of >>messages in that >>time, including the one for A above. With hop-hop responses, R1 keeps >>state around for each message it relays, and destroys that >>state when it >>gets an OK response. When the TCP failure occurs, R1 sends failure >>reports for all messages for which it still has state. >> >>But in the end-end case, R1 cannot report the failure. (We >>said R1 would >>keep no state for end-to-end, remember.) But even if it _did_ keep >>state, it would have no good way to know where in the message >>stream the >>error occured. Unless it does something _extremely_ stateful, >>like watch >>for success DSNs to go by, then when a TCP error occurs, it >>must assume >>that every message it has every relayed on that connection >>failed, or at >>least every message sent for the past 9 minutes or so failed. >>(9 minutes >>being the normal time requried for the _application_ to learn of some >>TCP failures.) Since 9 minutes is an eternity for a busy >>relay, I assume >>this is not acceptable. Rather, the relay would report >>nothing. The flow >>would look like the following: >> >> A R1 R2 B >> SEND------> >> SEND---X >> >> >>A would eventually figure out the message failure due to the >>lack of a >>success report. A would have to wait some time before making this >>decision to avoid a high likelyhood of false positives. Using the 9 >>minute failure detection time above, this time would be >>something like >>(9*number of hops * 2) minutes. >> >>So, back to our scenarios. For scenario 1, the end-end >>approach clearly >>wins, assuming we have the option to turn off DSN entirely. >>Orit's draft >>suggested that, with all responses turned off, a relay would >>have about >>a %20 scale advantage. However, her experiment was based on SIP >>messages, which tend to be larger, more complicated to parse, >>and have a >>more complex transaction model, even over TCP. I have no way >>of knowing >>how much the SIP vs MSRP aspect will impact things, but I think it is >>safe to say that the savings for MSRP will be real, but less than the >>%20 savings she observed for SIP. >> >>For scenario 2, it is a harder call. The number of messages >>is the same >>for either approach. The work to do message parsing, etc is similar. >>Relays will have to keep state for the hop-hop approach, >>although if we >>accept Adam's proposal about removing transaction timers, >>this state is >>fairly small. Also, the time it requires for the sender to >>learn about >>the failure is considerably shorter for the hop-hop approach than for >>the end-end approach. Therefore, I personally think the >>hop-hop approach >>wins this one. >> >>For scenario 3, an end-end receipt will be required anytime >>relays are >>present. This means the hop-hop approach will require more >>messages than >>the end-end, giving the round to the end-end. >> >>So, considering that I believe 2 is the primary use case, I >>lean towards >>the hop-hop case. >> >>I would also like to address a few arguments that I have heard, and >>believe to be red herrings: >> >>1) A failure report cannot be interpreted with certainty to >>mean that a >>message was not delivered. There are a number of edge cases where you >>can successfully deliver a message, but report it failed. >>However, this >>is _also_ true with the end-end case; as it is possible for >>the success >>report itself to get lost. We can build a system that never claims >>success unless it was really successful, but we cannot build a system >>that never claims failure unless it really failed. >> >>2) Since the TCP connections are used in both directions, >>responses may >>backup behind IMs sent in the reverse direction. This has been an >>acknowledged problem with the use of full-duplex connections from the >>beginning. But the problem exists for the end-end case as well, as >>success reports can _also_ get stuck in traffic. We are >>taking steps in >>MSRP (chunking, possible removal of transaction timers) that I think >>will mitigate this somewhat. >> >>Conclusions: >> >>I personally prefer the hop-hop approach, with DSN on failure >>and DSN on >>success as optional. However, if I am in the minority on that >>point, I >>can live with the end to end model. I do, however, want the >>transaction >>model to be consistent. That is, I don't want to negotiate whether we >>send hop-hop transaction responses to SEND requests. Either >>MSRP calls >>for them, or it does not. >> >>Further, the VISIT request, and I assume BIND or whatever >>equivelant we >>come up with in the relay work, necessarily follow a hop-hop model. >>Making SEND end-end creates an inconsistency there. >> >>If we do decide to change (back) to e2e SEND requests, the >>impact on the >>base spec is not huge; it would involve taking away the transaction >>response to SEND, and putting in a stronger dependency on DSN. There >>would be more impact on the relay spec. >> >>Thanks! >> >>Ben. >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 08:59:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09625 for ; Tue, 13 Apr 2004 08:59:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNUz-0002uP-Fp for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 08:58:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DCwjQI011182 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 08:58:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNUz-0002uH-9o for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 08:58:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09608 for ; Tue, 13 Apr 2004 08:58:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNUx-0007Dz-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 08:58:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNTT-00077n-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 08:57:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDNSU-00071y-00; Tue, 13 Apr 2004 08:56:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNSL-0002dX-Sb; Tue, 13 Apr 2004 08:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNRt-0002UP-Jx for simple@optimus.ietf.org; Tue, 13 Apr 2004 08:55:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09449 for ; Tue, 13 Apr 2004 08:55:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNRq-0006z1-00 for simple@ietf.org; Tue, 13 Apr 2004 08:55:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNQu-0006tc-00 for simple@ietf.org; Tue, 13 Apr 2004 08:54:34 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BDNPe-0006pK-00 for simple@ietf.org; Tue, 13 Apr 2004 08:53:14 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3DCr1Ix031700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2004 07:53:02 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407BE2AA.7070606@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP message reliability(long) References: <2038BCC78B1AD641891A0D1AE133DBB7017978DB@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017978DB@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 07:52:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > First off, let me say that I do not like 1 at all. You need some sort of protocol level ACKs on messages. You cannot guarantee that if a TCP socket received a message that also an application on top has also received it. There could be a socket listing but the application on top has crashed. > > Now, hop-by-hop vs. end-to-end: > > In this scenario (hop-by-hop) > > A R1 R2 B > SEND------> > <--------OK > SEND------> > <--------OK > SEND------> > <--------OK > > The OK does not tell the sender anything about the final delivery of the SEND. It only tells that the next hop has successfully received the SEND. Why is that important? Why is it important for A, R1 and R2 to know that the next hop has received the SEND? Why isn't TCP good enough here? That's the question that needs answering. The value comes when an error occurs. Lets say R1 has had the connection up to R2 for some time. Then the connection fails in mid session.. Standard TCP interfaces give R1 know way of knowing how much data had been sent before the error occured. Therefore, R1 must assume that _nothing_ got delivered. This ties in with the DSN on error case below. > > > In this scenario (end-to-end) > > A R1 R2 B > SEND------> > SEND------> > SEND------> > <------DSN > <-------DSN > <-------DSN > > IMO, the relays need to keep state and a timer, and sending a DSN is mandatory. If the DSN does not arrive after x units of time, a failure DSN is generated by the last hop that forwarded the SEND. Something like > > A R1 R2 B > SEND------> > SEND------> > SEND--X > <-------DSN (failure) > <-------DSN > > Ben commented that "even if it (the relay) _did_ keep state, it would have no good way to know where in the message stream the error occured." My question is: is it important, say for R1, to know where the error occured (at R2, R3, R4 or B)? > Sorry, I was unclear. I did not mean where the error occured in space, but rather in time. As in my example above, R2 has no way of knowing how much data got sent before the error occured. So how does he know which messages require DSN? He must assume the answer is "all of them", or at least "all of them for the last 9 or so minutes", since that is the typical time TCP will keep retransmitting before it gives up. > Ben, can you also elaborate of this: > > >>If we do decide to change (back) to e2e SEND requests ... There >>would be more impact on the relay spec. > > > Thanks, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 09.April.2004 00:14 >>To: Simple WG >>Subject: [Simple] MSRP message reliability(long) >> >> >>Hopefully, everyone has had a chance to look at Orit's draft >>giving an >>analysis and some recommendations concerning the way MSRP handles >>message acknowledgements. I responded separately with >>specific comments >>about that draft. However, I want to talk in general about the models >>that have been proposed, as I understand them. >> >>First, I would like to clarify the reliability requirements, as I see >>them, a little. As I see it, when I send a message, there are three >>levels of reliability that I might care about. Consider the following >>scenarios: >> >>1) I really don't care at all. (Strangely, this is the mode used by a >>lot of existing large scale systems. If we are dealing with highly >>interactive conversations between humans, humans provide their own >>reliability mechanism. I find myself typing "Hey, did you get my IM >>about X a few minutes ago" frequently.) >> >>2) I want a good effort to deliver, and a good attempt to tell me if >>something went wrong. If I hear nothing, I assume it most >>likely worked. >> >>3) Delivery is critical. I want to be told that it worked, and if I >>don't hear anything, I assume it most likely failed. >> >>My personal opinion is that 1 is generally unacceptable >>(dispite current >>systems), 3 should be an option, but 2 will be the primary >>use case, and >>the one we should optimize for. The rest of this email takes that >>perspective; if consensus proves me wrong then my analysis >>will change. >> >>We have a controversy about whether MSRP, in the general case where >>relays exist, should use per-hop transaction acknowledgements, or >>whether acknowledgments should be strictly end-to-end. >> >>First, let us consider the success cases; that is, when everything >>works. The per-hop case looks something like the following: >> >> A R1 R2 B >> SEND------> >> <--------OK >> SEND------> >> <--------OK >> SEND------> >> <--------OK >> >> >>This is not-optimal for the happy case, because each device >>has to keep >>transaction state until it gets a response. This state is >>_only_ useful >>if a failure occurs. (We will look at failure cases in a minute.) >>However, this state is not huge. As currently defined in >>MSRP, it would >>be the transaction identity and a timer. Adam proposed we do >>not need a >>mandatory timer, which would make it even smaller. >> >>In a perfect world, the end-to-end approach would look like: >> >> A R1 R2 B >> SEND------> >> SEND------> >> SEND------> >> >>This looks great on the surface. Not only can the relays be >>transaction >>stateless, only half as many messages happen. But, for reasons I will >>explain in a moment, this approach makes it impractical to tell A if >>something goes wrong downstream. Therefore, in a realistic >>implementation, it looks more like: >> >> A R1 R2 B >> SEND------> >> SEND------> >> SEND------> >> <---DSN(success) >> <-------DSN >> <-------DSN >> >>This has the same number of messages. It does allow the relays to be >>stateless. >> >>So, now, lets assume a TCP failure happens between R1 and R2. >> >>The hop-hop case looks like the following. A gets a failure >>notification >>shortly after R1 notices the failure. >> >> A R1 R2 B >> SEND------> >> <--------OK >> SEND----X >> <----DSN(fail) >> >>One would hope to make the end-to-end case look similar. But, as I >>mentioned before, that is impractical. Assume R1 has had a TCP >>connection to R2 up for some time. R1 has sent a lot of >>messages in that >>time, including the one for A above. With hop-hop responses, R1 keeps >>state around for each message it relays, and destroys that >>state when it >>gets an OK response. When the TCP failure occurs, R1 sends failure >>reports for all messages for which it still has state. >> >>But in the end-end case, R1 cannot report the failure. (We >>said R1 would >>keep no state for end-to-end, remember.) But even if it _did_ keep >>state, it would have no good way to know where in the message >>stream the >>error occured. Unless it does something _extremely_ stateful, >>like watch >>for success DSNs to go by, then when a TCP error occurs, it >>must assume >>that every message it has every relayed on that connection >>failed, or at >>least every message sent for the past 9 minutes or so failed. >>(9 minutes >>being the normal time requried for the _application_ to learn of some >>TCP failures.) Since 9 minutes is an eternity for a busy >>relay, I assume >>this is not acceptable. Rather, the relay would report >>nothing. The flow >>would look like the following: >> >> A R1 R2 B >> SEND------> >> SEND---X >> >> >>A would eventually figure out the message failure due to the >>lack of a >>success report. A would have to wait some time before making this >>decision to avoid a high likelyhood of false positives. Using the 9 >>minute failure detection time above, this time would be >>something like >>(9*number of hops * 2) minutes. >> >>So, back to our scenarios. For scenario 1, the end-end >>approach clearly >>wins, assuming we have the option to turn off DSN entirely. >>Orit's draft >>suggested that, with all responses turned off, a relay would >>have about >>a %20 scale advantage. However, her experiment was based on SIP >>messages, which tend to be larger, more complicated to parse, >>and have a >>more complex transaction model, even over TCP. I have no way >>of knowing >>how much the SIP vs MSRP aspect will impact things, but I think it is >>safe to say that the savings for MSRP will be real, but less than the >>%20 savings she observed for SIP. >> >>For scenario 2, it is a harder call. The number of messages >>is the same >>for either approach. The work to do message parsing, etc is similar. >>Relays will have to keep state for the hop-hop approach, >>although if we >>accept Adam's proposal about removing transaction timers, >>this state is >>fairly small. Also, the time it requires for the sender to >>learn about >>the failure is considerably shorter for the hop-hop approach than for >>the end-end approach. Therefore, I personally think the >>hop-hop approach >>wins this one. >> >>For scenario 3, an end-end receipt will be required anytime >>relays are >>present. This means the hop-hop approach will require more >>messages than >>the end-end, giving the round to the end-end. >> >>So, considering that I believe 2 is the primary use case, I >>lean towards >>the hop-hop case. >> >>I would also like to address a few arguments that I have heard, and >>believe to be red herrings: >> >>1) A failure report cannot be interpreted with certainty to >>mean that a >>message was not delivered. There are a number of edge cases where you >>can successfully deliver a message, but report it failed. >>However, this >>is _also_ true with the end-end case; as it is possible for >>the success >>report itself to get lost. We can build a system that never claims >>success unless it was really successful, but we cannot build a system >>that never claims failure unless it really failed. >> >>2) Since the TCP connections are used in both directions, >>responses may >>backup behind IMs sent in the reverse direction. This has been an >>acknowledged problem with the use of full-duplex connections from the >>beginning. But the problem exists for the end-end case as well, as >>success reports can _also_ get stuck in traffic. We are >>taking steps in >>MSRP (chunking, possible removal of transaction timers) that I think >>will mitigate this somewhat. >> >>Conclusions: >> >>I personally prefer the hop-hop approach, with DSN on failure >>and DSN on >>success as optional. However, if I am in the minority on that >>point, I >>can live with the end to end model. I do, however, want the >>transaction >>model to be consistent. That is, I don't want to negotiate whether we >>send hop-hop transaction responses to SEND requests. Either >>MSRP calls >>for them, or it does not. >> >>Further, the VISIT request, and I assume BIND or whatever >>equivelant we >>come up with in the relay work, necessarily follow a hop-hop model. >>Making SEND end-end creates an inconsistency there. >> >>If we do decide to change (back) to e2e SEND requests, the >>impact on the >>base spec is not huge; it would involve taking away the transaction >>response to SEND, and putting in a stronger dependency on DSN. There >>would be more impact on the relay spec. >> >>Thanks! >> >>Ben. >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 09:03:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09825 for ; Tue, 13 Apr 2004 09:03:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNZU-0007bE-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 09:03:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNY3-0007UV-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 09:01:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDNXI-0007Pc-00; Tue, 13 Apr 2004 09:01:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNXA-0002yj-B5; Tue, 13 Apr 2004 09:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNWK-0002x2-1v for simple@optimus.ietf.org; Tue, 13 Apr 2004 09:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09672 for ; Tue, 13 Apr 2004 09:00:05 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNWH-0007KY-00 for simple@ietf.org; Tue, 13 Apr 2004 09:00:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNVF-0007Fg-00 for simple@ietf.org; Tue, 13 Apr 2004 08:59:02 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BDNU5-0007AM-00 for simple@ietf.org; Tue, 13 Apr 2004 08:57:49 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCvhn04046 for ; Tue, 13 Apr 2004 15:57:43 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 15:57:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3DCvbVX007249 for ; Tue, 13 Apr 2004 15:57:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00oRMDJt; Tue, 13 Apr 2004 15:57:35 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCvQs11788 for ; Tue, 13 Apr 2004 15:57:26 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 15:56:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978DD@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABHVohhZwkdFRBOap8axIdcipwFIxIcQAACAHPAADEHIYA== To: X-OriginalArrivalTime: 13 Apr 2004 12:56:51.0851 (UTC) FILETIME=[CA5245B0:01C42156] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 15:56:51 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BIZ_TLD,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable It was pointed out to me that the Group Code for booking was incorrect. = Here is the correct Group Code: NOKNOKA. Apologies for the inconvenience. Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 13.April.2004 10:02 > To: rohan@cisco.com; simple@ietf.org > Cc: dean.willis@softarmor.com; mankin@psg.com; rjsparks@nostrum.com; > jon.peterson@neustar.biz; hardie@qualcomm.com; > Gonzalo.Camarillo@ericsson.com; alan.johnston@wcom.com; > adam@dynamicsoft.com > Subject: [Simple] RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > One small correction: >=20 > Rooms will be help until 3rd May. >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > > Sent: 13.April.2004 10:00 > > To: 'ext Rohan Mahy'; simple@ietf.org > > Cc: Dean Willis; Allison Mankin; Robert Sparks; John Peterson; Ted > > Hardie; Gonzalo Camarillo; Alan Johnston; Adam Roach > > Subject: RE: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Here is the hotel information: > >=20 > > Renaissance Boston Hotel Bedford > > 44 Middlesex Turnpike Bedford, MA 01730 USA > > Phone: 1 781-275-5500 Fax: 1 781-275-3042 > >=20 > > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB > >=20 > > There are 50 rooms booked for this event at the rate of $99=20 > > per night (from Sunday 23rd until Wednesday 26th). These=20 > > rooms will be held until 3th May, so please reserve your room=20 > > on or before that date. > >=20 > > You can reserve online or by telephone using the Group Code: NONOKA > >=20 > > Also, please use the links that Rohan provided to confirm=20 > > your attendance. This will aid us in determining the catering=20 > > requirements. Here is the link again: > >=20 > > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > > interim]yes > >=20 > > Thanks, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: 06.April.2004 20:54 > > > To: simple@ietf.org > > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo=20 > Camarillo; > > > Rohan Mahy; Alan Johnston; Adam Roach > > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > > >=20 > > >=20 > > > Hello All, > > >=20 > > > Please mark your calendars. > > >=20 > > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > > SIMPLE, and =20 > > > XCON WGs. > > > Nokia has generously agreed to host the event either at their=20 > > > offices =20 > > > near Boston or in a neighboring hotel during the week of May 24. > > >=20 > > > Please reserve the following dates for the WGs that you are=20 > > > interested =20 > > > in: > > > Monday May 24 SIP and SIPPING tentatively 9 am start > > > Tuesday May 25 SIMPLE All day > > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > > can catch =20 > > > flights. > > > (the actual agenda is subject to change, including the dates=20 > > > of various =20 > > > WG meetings). > > >=20 > > > There will be no fee, however please let Hisham and myself=20 > > > know if you =20 > > > are planning to attend by clicking on the Yes or Maybe=20 > links below: > > >=20 > > > mailto:rohan@cisco.com?=20 > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > > mailto:rohan@cisco.com?=20 > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > > >=20 > > > Wireless will be provided. As usual, I will be making=20 > > > T-shirts. If you =20 > > > are interested in buying one, please send your shirt size to me. > > >=20 > > > More details on the agenda and hotel accommodations will be=20 > > > forthcoming =20 > > > shortly. > > >=20 > > > thanks, > > > -rohan > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 09:03:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09864 for ; Tue, 13 Apr 2004 09:03:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNZZ-0003gh-PD for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 09:03:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DD3T5c014171 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 09:03:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNZZ-0003gU-KI for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 09:03:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09843 for ; Tue, 13 Apr 2004 09:03:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNZY-0007bM-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 09:03:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNY4-0007Ud-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 09:01:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDNXI-0007Pc-00; Tue, 13 Apr 2004 09:01:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNXA-0002yj-B5; Tue, 13 Apr 2004 09:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNWK-0002x2-1v for simple@optimus.ietf.org; Tue, 13 Apr 2004 09:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09672 for ; Tue, 13 Apr 2004 09:00:05 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNWH-0007KY-00 for simple@ietf.org; Tue, 13 Apr 2004 09:00:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNVF-0007Fg-00 for simple@ietf.org; Tue, 13 Apr 2004 08:59:02 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BDNU5-0007AM-00 for simple@ietf.org; Tue, 13 Apr 2004 08:57:49 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCvhn04046 for ; Tue, 13 Apr 2004 15:57:43 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 15:57:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3DCvbVX007249 for ; Tue, 13 Apr 2004 15:57:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00oRMDJt; Tue, 13 Apr 2004 15:57:35 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCvQs11788 for ; Tue, 13 Apr 2004 15:57:26 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 15:56:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978DD@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABHVohhZwkdFRBOap8axIdcipwFIxIcQAACAHPAADEHIYA== To: X-OriginalArrivalTime: 13 Apr 2004 12:56:51.0851 (UTC) FILETIME=[CA5245B0:01C42156] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 15:56:51 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BIZ_TLD,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It was pointed out to me that the Group Code for booking was incorrect. = Here is the correct Group Code: NOKNOKA. Apologies for the inconvenience. Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 13.April.2004 10:02 > To: rohan@cisco.com; simple@ietf.org > Cc: dean.willis@softarmor.com; mankin@psg.com; rjsparks@nostrum.com; > jon.peterson@neustar.biz; hardie@qualcomm.com; > Gonzalo.Camarillo@ericsson.com; alan.johnston@wcom.com; > adam@dynamicsoft.com > Subject: [Simple] RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > One small correction: >=20 > Rooms will be help until 3rd May. >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > > Sent: 13.April.2004 10:00 > > To: 'ext Rohan Mahy'; simple@ietf.org > > Cc: Dean Willis; Allison Mankin; Robert Sparks; John Peterson; Ted > > Hardie; Gonzalo Camarillo; Alan Johnston; Adam Roach > > Subject: RE: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Here is the hotel information: > >=20 > > Renaissance Boston Hotel Bedford > > 44 Middlesex Turnpike Bedford, MA 01730 USA > > Phone: 1 781-275-5500 Fax: 1 781-275-3042 > >=20 > > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB > >=20 > > There are 50 rooms booked for this event at the rate of $99=20 > > per night (from Sunday 23rd until Wednesday 26th). These=20 > > rooms will be held until 3th May, so please reserve your room=20 > > on or before that date. > >=20 > > You can reserve online or by telephone using the Group Code: NONOKA > >=20 > > Also, please use the links that Rohan provided to confirm=20 > > your attendance. This will aid us in determining the catering=20 > > requirements. Here is the link again: > >=20 > > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > > interim]yes > >=20 > > Thanks, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: 06.April.2004 20:54 > > > To: simple@ietf.org > > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo=20 > Camarillo; > > > Rohan Mahy; Alan Johnston; Adam Roach > > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > > >=20 > > >=20 > > > Hello All, > > >=20 > > > Please mark your calendars. > > >=20 > > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > > SIMPLE, and =20 > > > XCON WGs. > > > Nokia has generously agreed to host the event either at their=20 > > > offices =20 > > > near Boston or in a neighboring hotel during the week of May 24. > > >=20 > > > Please reserve the following dates for the WGs that you are=20 > > > interested =20 > > > in: > > > Monday May 24 SIP and SIPPING tentatively 9 am start > > > Tuesday May 25 SIMPLE All day > > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > > can catch =20 > > > flights. > > > (the actual agenda is subject to change, including the dates=20 > > > of various =20 > > > WG meetings). > > >=20 > > > There will be no fee, however please let Hisham and myself=20 > > > know if you =20 > > > are planning to attend by clicking on the Yes or Maybe=20 > links below: > > >=20 > > > mailto:rohan@cisco.com?=20 > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > > mailto:rohan@cisco.com?=20 > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > > >=20 > > > Wireless will be provided. As usual, I will be making=20 > > > T-shirts. If you =20 > > > are interested in buying one, please send your shirt size to me. > > >=20 > > > More details on the agenda and hotel accommodations will be=20 > > > forthcoming =20 > > > shortly. > > >=20 > > > thanks, > > > -rohan > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 09:24:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10747 for ; Tue, 13 Apr 2004 09:24:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNu4-0001Ov-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 09:24:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNsF-0001IW-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 09:22:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDNqo-0001AP-00; Tue, 13 Apr 2004 09:21:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDNqk-0000LZ-MF; Tue, 13 Apr 2004 09:21:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNqY-0005TR-BI; Tue, 13 Apr 2004 09:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNq4-0005QL-PY for simple@optimus.ietf.org; Tue, 13 Apr 2004 09:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10547 for ; Tue, 13 Apr 2004 09:20:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNq0-00017y-00 for simple@ietf.org; Tue, 13 Apr 2004 09:20:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNnv-0000wU-00 for simple@ietf.org; Tue, 13 Apr 2004 09:18:21 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDNms-0000qb-00 for simple@ietf.org; Tue, 13 Apr 2004 09:17:15 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DDHAH15978; Tue, 13 Apr 2004 16:17:11 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 16:16:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3DDGuPi032289; Tue, 13 Apr 2004 16:16:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00xfa0RH; Tue, 13 Apr 2004 16:16:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DDGas27395; Tue, 13 Apr 2004 16:16:36 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 16:16:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978E4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQhVxMeijN6GQbFT9+Pcg4hHM5Z3QAAiUzw To: Cc: X-OriginalArrivalTime: 13 Apr 2004 13:16:33.0564 (UTC) FILETIME=[8AAD5DC0:01C42159] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 16:16:33 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ok, I'm sold with the hop-by-hop solution. But for completeness sake, = can you comment on my last question (I think you missed it). Here it is = again: > > Ben, can you also elaborate on this: > >=20 > >=20 > >>If we do decide to change (back) to e2e SEND requests ... There=20 > >>would be more impact on the relay spec. Thanks, Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 13.April.2004 15:53 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP message reliability(long) >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > First off, let me say that I do not like 1 at all. You need=20 > some sort of protocol level ACKs on messages. You cannot=20 > guarantee that if a TCP socket received a message that also=20 > an application on top has also received it. There could be a=20 > socket listing but the application on top has crashed. > >=20 > > Now, hop-by-hop vs. end-to-end: > >=20 > > In this scenario (hop-by-hop) > >=20 > > A R1 R2 B > > SEND------> > > <--------OK > > SEND------> > > <--------OK > > SEND------> > > <--------OK > >=20 > > The OK does not tell the sender anything about the final=20 > delivery of the SEND. It only tells that the next hop has=20 > successfully received the SEND. Why is that important? Why is=20 > it important for A, R1 and R2 to know that the next hop has=20 > received the SEND? Why isn't TCP good enough here? That's the=20 > question that needs answering. >=20 > The value comes when an error occurs. Lets say R1 has had the=20 > connection=20 > up to R2 for some time. Then the connection fails in mid session..=20 > Standard TCP interfaces give R1 know way of knowing how much data had=20 > been sent before the error occured. Therefore, R1 must assume that=20 > _nothing_ got delivered. This ties in with the DSN on error=20 > case below. >=20 > >=20 > >=20 > > In this scenario (end-to-end) > >=20 > > A R1 R2 B > > SEND------> > > SEND------> > > SEND------> > > <------DSN > > <-------DSN > > <-------DSN > >=20 > > IMO, the relays need to keep state and a timer, and sending=20 > a DSN is mandatory. If the DSN does not arrive after x units=20 > of time, a failure DSN is generated by the last hop that=20 > forwarded the SEND. Something like > >=20 > > A R1 R2 B > > SEND------> > > SEND------> > > SEND--X > > <-------DSN (failure) > > <-------DSN > >=20 > > Ben commented that "even if it (the relay) _did_ keep=20 > state, it would have no good way to know where in the message=20 > stream the error occured." My question is: is it important,=20 > say for R1, to know where the error occured (at R2, R3, R4 or B)? > > >=20 > Sorry, I was unclear. I did not mean where the error occured=20 > in space,=20 > but rather in time. As in my example above, R2 has no way of=20 > knowing how=20 > much data got sent before the error occured. So how does he=20 > know which=20 > messages require DSN? He must assume the answer is "all of=20 > them", or at=20 > least "all of them for the last 9 or so minutes", since that is the=20 > typical time TCP will keep retransmitting before it gives up. >=20 >=20 > > Ben, can you also elaborate of this: > >=20 > >=20 > >>If we do decide to change (back) to e2e SEND requests ... There=20 > >>would be more impact on the relay spec. > >=20 > >=20 > > Thanks, > > Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Ben Campbell > >>Sent: 09.April.2004 00:14 > >>To: Simple WG > >>Subject: [Simple] MSRP message reliability(long) > >> > >> > >>Hopefully, everyone has had a chance to look at Orit's draft=20 > >>giving an=20 > >>analysis and some recommendations concerning the way MSRP handles=20 > >>message acknowledgements. I responded separately with=20 > >>specific comments=20 > >>about that draft. However, I want to talk in general about=20 > the models=20 > >>that have been proposed, as I understand them. > >> > >>First, I would like to clarify the reliability=20 > requirements, as I see=20 > >>them, a little. As I see it, when I send a message, there are three=20 > >>levels of reliability that I might care about. Consider the=20 > following=20 > >>scenarios: > >> > >>1) I really don't care at all. (Strangely, this is the mode=20 > used by a=20 > >>lot of existing large scale systems. If we are dealing with highly=20 > >>interactive conversations between humans, humans provide their own=20 > >>reliability mechanism. I find myself typing "Hey, did you get my IM=20 > >>about X a few minutes ago" frequently.) > >> > >>2) I want a good effort to deliver, and a good attempt to=20 > tell me if=20 > >>something went wrong. If I hear nothing, I assume it most=20 > >>likely worked. > >> > >>3) Delivery is critical. I want to be told that it worked, and if I=20 > >>don't hear anything, I assume it most likely failed. > >> > >>My personal opinion is that 1 is generally unacceptable=20 > >>(dispite current=20 > >>systems), 3 should be an option, but 2 will be the primary=20 > >>use case, and=20 > >>the one we should optimize for. The rest of this email takes that=20 > >>perspective; if consensus proves me wrong then my analysis=20 > >>will change. > >> > >>We have a controversy about whether MSRP, in the general case where=20 > >>relays exist, should use per-hop transaction acknowledgements, or=20 > >>whether acknowledgments should be strictly end-to-end. > >> > >>First, let us consider the success cases; that is, when everything=20 > >>works. The per-hop case looks something like the following: > >> > >> A R1 R2 B > >> SEND------> > >> <--------OK > >> SEND------> > >> <--------OK > >> SEND------> > >> <--------OK > >> > >> > >>This is not-optimal for the happy case, because each device=20 > >>has to keep=20 > >>transaction state until it gets a response. This state is=20 > >>_only_ useful=20 > >>if a failure occurs. (We will look at failure cases in a minute.)=20 > >>However, this state is not huge. As currently defined in=20 > >>MSRP, it would=20 > >>be the transaction identity and a timer. Adam proposed we do=20 > >>not need a=20 > >>mandatory timer, which would make it even smaller. > >> > >>In a perfect world, the end-to-end approach would look like: > >> > >> A R1 R2 B > >> SEND------> > >> SEND------> > >> SEND------> > >> > >>This looks great on the surface. Not only can the relays be=20 > >>transaction=20 > >>stateless, only half as many messages happen. But, for=20 > reasons I will=20 > >>explain in a moment, this approach makes it impractical to=20 > tell A if=20 > >>something goes wrong downstream. Therefore, in a realistic=20 > >>implementation, it looks more like: > >> > >> A R1 R2 B > >> SEND------> > >> SEND------> > >> SEND------> > >> <---DSN(success) > >> <-------DSN > >> <-------DSN > >> > >>This has the same number of messages. It does allow the=20 > relays to be=20 > >>stateless. > >> > >>So, now, lets assume a TCP failure happens between R1 and R2. > >> > >>The hop-hop case looks like the following. A gets a failure=20 > >>notification=20 > >>shortly after R1 notices the failure. > >> > >> A R1 R2 B > >> SEND------> > >> <--------OK > >> SEND----X > >> <----DSN(fail) > >> > >>One would hope to make the end-to-end case look similar. But, as I=20 > >>mentioned before, that is impractical. Assume R1 has had a TCP=20 > >>connection to R2 up for some time. R1 has sent a lot of=20 > >>messages in that=20 > >>time, including the one for A above. With hop-hop=20 > responses, R1 keeps=20 > >>state around for each message it relays, and destroys that=20 > >>state when it=20 > >>gets an OK response. When the TCP failure occurs, R1 sends failure=20 > >>reports for all messages for which it still has state. > >> > >>But in the end-end case, R1 cannot report the failure. (We=20 > >>said R1 would=20 > >>keep no state for end-to-end, remember.) But even if it _did_ keep=20 > >>state, it would have no good way to know where in the message=20 > >>stream the=20 > >>error occured. Unless it does something _extremely_ stateful,=20 > >>like watch=20 > >>for success DSNs to go by, then when a TCP error occurs, it=20 > >>must assume=20 > >>that every message it has every relayed on that connection=20 > >>failed, or at=20 > >>least every message sent for the past 9 minutes or so failed.=20 > >>(9 minutes=20 > >>being the normal time requried for the _application_ to=20 > learn of some=20 > >>TCP failures.) Since 9 minutes is an eternity for a busy=20 > >>relay, I assume=20 > >>this is not acceptable. Rather, the relay would report=20 > >>nothing. The flow=20 > >>would look like the following: > >> > >> A R1 R2 B > >> SEND------> > >> SEND---X > >> > >> > >>A would eventually figure out the message failure due to the=20 > >>lack of a=20 > >>success report. A would have to wait some time before making this=20 > >>decision to avoid a high likelyhood of false positives. Using the 9=20 > >>minute failure detection time above, this time would be=20 > >>something like=20 > >>(9*number of hops * 2) minutes. > >> > >>So, back to our scenarios. For scenario 1, the end-end=20 > >>approach clearly=20 > >>wins, assuming we have the option to turn off DSN entirely.=20 > >>Orit's draft=20 > >>suggested that, with all responses turned off, a relay would=20 > >>have about=20 > >>a %20 scale advantage. However, her experiment was based on SIP=20 > >>messages, which tend to be larger, more complicated to parse,=20 > >>and have a=20 > >>more complex transaction model, even over TCP. I have no way=20 > >>of knowing=20 > >>how much the SIP vs MSRP aspect will impact things, but I=20 > think it is=20 > >>safe to say that the savings for MSRP will be real, but=20 > less than the=20 > >>%20 savings she observed for SIP. > >> > >>For scenario 2, it is a harder call. The number of messages=20 > >>is the same=20 > >>for either approach. The work to do message parsing, etc is=20 > similar.=20 > >>Relays will have to keep state for the hop-hop approach,=20 > >>although if we=20 > >>accept Adam's proposal about removing transaction timers,=20 > >>this state is=20 > >>fairly small. Also, the time it requires for the sender to=20 > >>learn about=20 > >>the failure is considerably shorter for the hop-hop=20 > approach than for=20 > >>the end-end approach. Therefore, I personally think the=20 > >>hop-hop approach=20 > >>wins this one. > >> > >>For scenario 3, an end-end receipt will be required anytime=20 > >>relays are=20 > >>present. This means the hop-hop approach will require more=20 > >>messages than=20 > >>the end-end, giving the round to the end-end. > >> > >>So, considering that I believe 2 is the primary use case, I=20 > >>lean towards=20 > >>the hop-hop case. > >> > >>I would also like to address a few arguments that I have heard, and=20 > >>believe to be red herrings: > >> > >>1) A failure report cannot be interpreted with certainty to=20 > >>mean that a=20 > >>message was not delivered. There are a number of edge cases=20 > where you=20 > >>can successfully deliver a message, but report it failed.=20 > >>However, this=20 > >>is _also_ true with the end-end case; as it is possible for=20 > >>the success=20 > >>report itself to get lost. We can build a system that never claims=20 > >>success unless it was really successful, but we cannot=20 > build a system=20 > >>that never claims failure unless it really failed. > >> > >>2) Since the TCP connections are used in both directions,=20 > >>responses may=20 > >>backup behind IMs sent in the reverse direction. This has been an=20 > >>acknowledged problem with the use of full-duplex=20 > connections from the=20 > >>beginning. But the problem exists for the end-end case as well, as=20 > >>success reports can _also_ get stuck in traffic. We are=20 > >>taking steps in=20 > >>MSRP (chunking, possible removal of transaction timers)=20 > that I think=20 > >>will mitigate this somewhat. > >> > >>Conclusions: > >> > >>I personally prefer the hop-hop approach, with DSN on failure=20 > >>and DSN on=20 > >>success as optional. However, if I am in the minority on that=20 > >>point, I=20 > >>can live with the end to end model. I do, however, want the=20 > >>transaction=20 > >>model to be consistent. That is, I don't want to negotiate=20 > whether we=20 > >>send hop-hop transaction responses to SEND requests. Either=20 > >>MSRP calls=20 > >>for them, or it does not. > >> > >>Further, the VISIT request, and I assume BIND or whatever=20 > >>equivelant we=20 > >>come up with in the relay work, necessarily follow a hop-hop model.=20 > >>Making SEND end-end creates an inconsistency there. > >> > >>If we do decide to change (back) to e2e SEND requests, the=20 > >>impact on the=20 > >>base spec is not huge; it would involve taking away the transaction=20 > >>response to SEND, and putting in a stronger dependency on=20 > DSN. There=20 > >>would be more impact on the relay spec. > >> > >>Thanks! > >> > >>Ben. > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 09:25:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10808 for ; Tue, 13 Apr 2004 09:25:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNu9-0005uQ-5x for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 09:24:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DDOjqZ022707 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 09:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNu8-0005u3-UD for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 09:24:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10769 for ; Tue, 13 Apr 2004 09:24:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNu7-0001QL-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 09:24:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNsH-0001Ie-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 09:22:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDNqo-0001AP-00; Tue, 13 Apr 2004 09:21:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDNqk-0000LZ-MF; Tue, 13 Apr 2004 09:21:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNqY-0005TR-BI; Tue, 13 Apr 2004 09:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNq4-0005QL-PY for simple@optimus.ietf.org; Tue, 13 Apr 2004 09:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10547 for ; Tue, 13 Apr 2004 09:20:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNq0-00017y-00 for simple@ietf.org; Tue, 13 Apr 2004 09:20:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNnv-0000wU-00 for simple@ietf.org; Tue, 13 Apr 2004 09:18:21 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDNms-0000qb-00 for simple@ietf.org; Tue, 13 Apr 2004 09:17:15 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DDHAH15978; Tue, 13 Apr 2004 16:17:11 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 16:16:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3DDGuPi032289; Tue, 13 Apr 2004 16:16:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00xfa0RH; Tue, 13 Apr 2004 16:16:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DDGas27395; Tue, 13 Apr 2004 16:16:36 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 16:16:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978E4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQhVxMeijN6GQbFT9+Pcg4hHM5Z3QAAiUzw To: Cc: X-OriginalArrivalTime: 13 Apr 2004 13:16:33.0564 (UTC) FILETIME=[8AAD5DC0:01C42159] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 16:16:33 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ok, I'm sold with the hop-by-hop solution. But for completeness sake, = can you comment on my last question (I think you missed it). Here it is = again: > > Ben, can you also elaborate on this: > >=20 > >=20 > >>If we do decide to change (back) to e2e SEND requests ... There=20 > >>would be more impact on the relay spec. Thanks, Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 13.April.2004 15:53 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP message reliability(long) >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > First off, let me say that I do not like 1 at all. You need=20 > some sort of protocol level ACKs on messages. You cannot=20 > guarantee that if a TCP socket received a message that also=20 > an application on top has also received it. There could be a=20 > socket listing but the application on top has crashed. > >=20 > > Now, hop-by-hop vs. end-to-end: > >=20 > > In this scenario (hop-by-hop) > >=20 > > A R1 R2 B > > SEND------> > > <--------OK > > SEND------> > > <--------OK > > SEND------> > > <--------OK > >=20 > > The OK does not tell the sender anything about the final=20 > delivery of the SEND. It only tells that the next hop has=20 > successfully received the SEND. Why is that important? Why is=20 > it important for A, R1 and R2 to know that the next hop has=20 > received the SEND? Why isn't TCP good enough here? That's the=20 > question that needs answering. >=20 > The value comes when an error occurs. Lets say R1 has had the=20 > connection=20 > up to R2 for some time. Then the connection fails in mid session..=20 > Standard TCP interfaces give R1 know way of knowing how much data had=20 > been sent before the error occured. Therefore, R1 must assume that=20 > _nothing_ got delivered. This ties in with the DSN on error=20 > case below. >=20 > >=20 > >=20 > > In this scenario (end-to-end) > >=20 > > A R1 R2 B > > SEND------> > > SEND------> > > SEND------> > > <------DSN > > <-------DSN > > <-------DSN > >=20 > > IMO, the relays need to keep state and a timer, and sending=20 > a DSN is mandatory. If the DSN does not arrive after x units=20 > of time, a failure DSN is generated by the last hop that=20 > forwarded the SEND. Something like > >=20 > > A R1 R2 B > > SEND------> > > SEND------> > > SEND--X > > <-------DSN (failure) > > <-------DSN > >=20 > > Ben commented that "even if it (the relay) _did_ keep=20 > state, it would have no good way to know where in the message=20 > stream the error occured." My question is: is it important,=20 > say for R1, to know where the error occured (at R2, R3, R4 or B)? > > >=20 > Sorry, I was unclear. I did not mean where the error occured=20 > in space,=20 > but rather in time. As in my example above, R2 has no way of=20 > knowing how=20 > much data got sent before the error occured. So how does he=20 > know which=20 > messages require DSN? He must assume the answer is "all of=20 > them", or at=20 > least "all of them for the last 9 or so minutes", since that is the=20 > typical time TCP will keep retransmitting before it gives up. >=20 >=20 > > Ben, can you also elaborate of this: > >=20 > >=20 > >>If we do decide to change (back) to e2e SEND requests ... There=20 > >>would be more impact on the relay spec. > >=20 > >=20 > > Thanks, > > Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Ben Campbell > >>Sent: 09.April.2004 00:14 > >>To: Simple WG > >>Subject: [Simple] MSRP message reliability(long) > >> > >> > >>Hopefully, everyone has had a chance to look at Orit's draft=20 > >>giving an=20 > >>analysis and some recommendations concerning the way MSRP handles=20 > >>message acknowledgements. I responded separately with=20 > >>specific comments=20 > >>about that draft. However, I want to talk in general about=20 > the models=20 > >>that have been proposed, as I understand them. > >> > >>First, I would like to clarify the reliability=20 > requirements, as I see=20 > >>them, a little. As I see it, when I send a message, there are three=20 > >>levels of reliability that I might care about. Consider the=20 > following=20 > >>scenarios: > >> > >>1) I really don't care at all. (Strangely, this is the mode=20 > used by a=20 > >>lot of existing large scale systems. If we are dealing with highly=20 > >>interactive conversations between humans, humans provide their own=20 > >>reliability mechanism. I find myself typing "Hey, did you get my IM=20 > >>about X a few minutes ago" frequently.) > >> > >>2) I want a good effort to deliver, and a good attempt to=20 > tell me if=20 > >>something went wrong. If I hear nothing, I assume it most=20 > >>likely worked. > >> > >>3) Delivery is critical. I want to be told that it worked, and if I=20 > >>don't hear anything, I assume it most likely failed. > >> > >>My personal opinion is that 1 is generally unacceptable=20 > >>(dispite current=20 > >>systems), 3 should be an option, but 2 will be the primary=20 > >>use case, and=20 > >>the one we should optimize for. The rest of this email takes that=20 > >>perspective; if consensus proves me wrong then my analysis=20 > >>will change. > >> > >>We have a controversy about whether MSRP, in the general case where=20 > >>relays exist, should use per-hop transaction acknowledgements, or=20 > >>whether acknowledgments should be strictly end-to-end. > >> > >>First, let us consider the success cases; that is, when everything=20 > >>works. The per-hop case looks something like the following: > >> > >> A R1 R2 B > >> SEND------> > >> <--------OK > >> SEND------> > >> <--------OK > >> SEND------> > >> <--------OK > >> > >> > >>This is not-optimal for the happy case, because each device=20 > >>has to keep=20 > >>transaction state until it gets a response. This state is=20 > >>_only_ useful=20 > >>if a failure occurs. (We will look at failure cases in a minute.)=20 > >>However, this state is not huge. As currently defined in=20 > >>MSRP, it would=20 > >>be the transaction identity and a timer. Adam proposed we do=20 > >>not need a=20 > >>mandatory timer, which would make it even smaller. > >> > >>In a perfect world, the end-to-end approach would look like: > >> > >> A R1 R2 B > >> SEND------> > >> SEND------> > >> SEND------> > >> > >>This looks great on the surface. Not only can the relays be=20 > >>transaction=20 > >>stateless, only half as many messages happen. But, for=20 > reasons I will=20 > >>explain in a moment, this approach makes it impractical to=20 > tell A if=20 > >>something goes wrong downstream. Therefore, in a realistic=20 > >>implementation, it looks more like: > >> > >> A R1 R2 B > >> SEND------> > >> SEND------> > >> SEND------> > >> <---DSN(success) > >> <-------DSN > >> <-------DSN > >> > >>This has the same number of messages. It does allow the=20 > relays to be=20 > >>stateless. > >> > >>So, now, lets assume a TCP failure happens between R1 and R2. > >> > >>The hop-hop case looks like the following. A gets a failure=20 > >>notification=20 > >>shortly after R1 notices the failure. > >> > >> A R1 R2 B > >> SEND------> > >> <--------OK > >> SEND----X > >> <----DSN(fail) > >> > >>One would hope to make the end-to-end case look similar. But, as I=20 > >>mentioned before, that is impractical. Assume R1 has had a TCP=20 > >>connection to R2 up for some time. R1 has sent a lot of=20 > >>messages in that=20 > >>time, including the one for A above. With hop-hop=20 > responses, R1 keeps=20 > >>state around for each message it relays, and destroys that=20 > >>state when it=20 > >>gets an OK response. When the TCP failure occurs, R1 sends failure=20 > >>reports for all messages for which it still has state. > >> > >>But in the end-end case, R1 cannot report the failure. (We=20 > >>said R1 would=20 > >>keep no state for end-to-end, remember.) But even if it _did_ keep=20 > >>state, it would have no good way to know where in the message=20 > >>stream the=20 > >>error occured. Unless it does something _extremely_ stateful,=20 > >>like watch=20 > >>for success DSNs to go by, then when a TCP error occurs, it=20 > >>must assume=20 > >>that every message it has every relayed on that connection=20 > >>failed, or at=20 > >>least every message sent for the past 9 minutes or so failed.=20 > >>(9 minutes=20 > >>being the normal time requried for the _application_ to=20 > learn of some=20 > >>TCP failures.) Since 9 minutes is an eternity for a busy=20 > >>relay, I assume=20 > >>this is not acceptable. Rather, the relay would report=20 > >>nothing. The flow=20 > >>would look like the following: > >> > >> A R1 R2 B > >> SEND------> > >> SEND---X > >> > >> > >>A would eventually figure out the message failure due to the=20 > >>lack of a=20 > >>success report. A would have to wait some time before making this=20 > >>decision to avoid a high likelyhood of false positives. Using the 9=20 > >>minute failure detection time above, this time would be=20 > >>something like=20 > >>(9*number of hops * 2) minutes. > >> > >>So, back to our scenarios. For scenario 1, the end-end=20 > >>approach clearly=20 > >>wins, assuming we have the option to turn off DSN entirely.=20 > >>Orit's draft=20 > >>suggested that, with all responses turned off, a relay would=20 > >>have about=20 > >>a %20 scale advantage. However, her experiment was based on SIP=20 > >>messages, which tend to be larger, more complicated to parse,=20 > >>and have a=20 > >>more complex transaction model, even over TCP. I have no way=20 > >>of knowing=20 > >>how much the SIP vs MSRP aspect will impact things, but I=20 > think it is=20 > >>safe to say that the savings for MSRP will be real, but=20 > less than the=20 > >>%20 savings she observed for SIP. > >> > >>For scenario 2, it is a harder call. The number of messages=20 > >>is the same=20 > >>for either approach. The work to do message parsing, etc is=20 > similar.=20 > >>Relays will have to keep state for the hop-hop approach,=20 > >>although if we=20 > >>accept Adam's proposal about removing transaction timers,=20 > >>this state is=20 > >>fairly small. Also, the time it requires for the sender to=20 > >>learn about=20 > >>the failure is considerably shorter for the hop-hop=20 > approach than for=20 > >>the end-end approach. Therefore, I personally think the=20 > >>hop-hop approach=20 > >>wins this one. > >> > >>For scenario 3, an end-end receipt will be required anytime=20 > >>relays are=20 > >>present. This means the hop-hop approach will require more=20 > >>messages than=20 > >>the end-end, giving the round to the end-end. > >> > >>So, considering that I believe 2 is the primary use case, I=20 > >>lean towards=20 > >>the hop-hop case. > >> > >>I would also like to address a few arguments that I have heard, and=20 > >>believe to be red herrings: > >> > >>1) A failure report cannot be interpreted with certainty to=20 > >>mean that a=20 > >>message was not delivered. There are a number of edge cases=20 > where you=20 > >>can successfully deliver a message, but report it failed.=20 > >>However, this=20 > >>is _also_ true with the end-end case; as it is possible for=20 > >>the success=20 > >>report itself to get lost. We can build a system that never claims=20 > >>success unless it was really successful, but we cannot=20 > build a system=20 > >>that never claims failure unless it really failed. > >> > >>2) Since the TCP connections are used in both directions,=20 > >>responses may=20 > >>backup behind IMs sent in the reverse direction. This has been an=20 > >>acknowledged problem with the use of full-duplex=20 > connections from the=20 > >>beginning. But the problem exists for the end-end case as well, as=20 > >>success reports can _also_ get stuck in traffic. We are=20 > >>taking steps in=20 > >>MSRP (chunking, possible removal of transaction timers)=20 > that I think=20 > >>will mitigate this somewhat. > >> > >>Conclusions: > >> > >>I personally prefer the hop-hop approach, with DSN on failure=20 > >>and DSN on=20 > >>success as optional. However, if I am in the minority on that=20 > >>point, I=20 > >>can live with the end to end model. I do, however, want the=20 > >>transaction=20 > >>model to be consistent. That is, I don't want to negotiate=20 > whether we=20 > >>send hop-hop transaction responses to SEND requests. Either=20 > >>MSRP calls=20 > >>for them, or it does not. > >> > >>Further, the VISIT request, and I assume BIND or whatever=20 > >>equivelant we=20 > >>come up with in the relay work, necessarily follow a hop-hop model.=20 > >>Making SEND end-end creates an inconsistency there. > >> > >>If we do decide to change (back) to e2e SEND requests, the=20 > >>impact on the=20 > >>base spec is not huge; it would involve taking away the transaction=20 > >>response to SEND, and putting in a stronger dependency on=20 > DSN. There=20 > >>would be more impact on the relay spec. > >> > >>Thanks! > >> > >>Ben. > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 10:29:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14663 for ; Tue, 13 Apr 2004 10:29:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOuy-0006K3-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 10:29:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOtf-0006DQ-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 10:28:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDOsP-00066r-00; Tue, 13 Apr 2004 10:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOsP-0000Tx-Un; Tue, 13 Apr 2004 10:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOrt-0000S3-7o for simple@optimus.ietf.org; Tue, 13 Apr 2004 10:26:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14496 for ; Tue, 13 Apr 2004 10:26:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOrp-00064Y-00 for simple@ietf.org; Tue, 13 Apr 2004 10:26:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOqn-0005xj-00 for simple@ietf.org; Tue, 13 Apr 2004 10:25:23 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BDOpL-0005qU-00 for simple@ietf.org; Tue, 13 Apr 2004 10:23:52 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3DENfIx039302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2004 09:23:42 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407BF7E4.9060504@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP message reliability(long) References: <2038BCC78B1AD641891A0D1AE133DBB7017978E4@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017978E4@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 09:23:32 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Ok, I'm sold with the hop-by-hop solution. But for completeness sake, can you comment on my last question (I think you missed it). Here it is again: > > >>>Ben, can you also elaborate on this: >>> >>> >>> >>>>If we do decide to change (back) to e2e SEND requests ... There >>>>would be more impact on the relay spec. Oops, sorry. I guess I did not scroll far enough. There would be impact on both relays and on the base spec. Since we have not written the relay spec yet, I am not all that worried. The impact would mean deviation from the way SIMS worked, but it would mainly mean removing functionality. As far as the base spec is concerned, we would need to remove the concept of a transaction response. We would no longer have transaction state, only message delivery state. (Similar, but subtlely different.) The only If a TCP failure occured, the only recourse to determine what messages had been delivered would be DSN, if it is turned on. Further, we would probably need to tighten behavior around failing to receiving positive DSN. It is not the effort to specify that worries me, as much as the effort to achieve consensus. > > > Thanks, > Hisham > > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 13.April.2004 15:53 >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP message reliability(long) >> >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>First off, let me say that I do not like 1 at all. You need >> >>some sort of protocol level ACKs on messages. You cannot >>guarantee that if a TCP socket received a message that also >>an application on top has also received it. There could be a >>socket listing but the application on top has crashed. >> >>>Now, hop-by-hop vs. end-to-end: >>> >>>In this scenario (hop-by-hop) >>> >>> A R1 R2 B >>> SEND------> >>> <--------OK >>> SEND------> >>> <--------OK >>> SEND------> >>> <--------OK >>> >>>The OK does not tell the sender anything about the final >> >>delivery of the SEND. It only tells that the next hop has >>successfully received the SEND. Why is that important? Why is >>it important for A, R1 and R2 to know that the next hop has >>received the SEND? Why isn't TCP good enough here? That's the >>question that needs answering. >> >>The value comes when an error occurs. Lets say R1 has had the >>connection >>up to R2 for some time. Then the connection fails in mid session.. >>Standard TCP interfaces give R1 know way of knowing how much data had >>been sent before the error occured. Therefore, R1 must assume that >>_nothing_ got delivered. This ties in with the DSN on error >>case below. >> >> >>> >>>In this scenario (end-to-end) >>> >>> A R1 R2 B >>> SEND------> >>> SEND------> >>> SEND------> >>> <------DSN >>> <-------DSN >>> <-------DSN >>> >>>IMO, the relays need to keep state and a timer, and sending >> >>a DSN is mandatory. If the DSN does not arrive after x units >>of time, a failure DSN is generated by the last hop that >>forwarded the SEND. Something like >> >>> A R1 R2 B >>> SEND------> >>> SEND------> >>> SEND--X >>> <-------DSN (failure) >>> <-------DSN >>> >>>Ben commented that "even if it (the relay) _did_ keep >> >>state, it would have no good way to know where in the message >>stream the error occured." My question is: is it important, >>say for R1, to know where the error occured (at R2, R3, R4 or B)? >> >>Sorry, I was unclear. I did not mean where the error occured >>in space, >>but rather in time. As in my example above, R2 has no way of >>knowing how >>much data got sent before the error occured. So how does he >>know which >>messages require DSN? He must assume the answer is "all of >>them", or at >>least "all of them for the last 9 or so minutes", since that is the >>typical time TCP will keep retransmitting before it gives up. >> >> >> >>>Ben, can you also elaborate of this: >>> >>> >>> >>>>If we do decide to change (back) to e2e SEND requests ... There >>>>would be more impact on the relay spec. >>> >>> >>>Thanks, >>>Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Ben Campbell >>>>Sent: 09.April.2004 00:14 >>>>To: Simple WG >>>>Subject: [Simple] MSRP message reliability(long) >>>> >>>> >>>>Hopefully, everyone has had a chance to look at Orit's draft >>>>giving an >>>>analysis and some recommendations concerning the way MSRP handles >>>>message acknowledgements. I responded separately with >>>>specific comments >>>>about that draft. However, I want to talk in general about >> >>the models >> >>>>that have been proposed, as I understand them. >>>> >>>>First, I would like to clarify the reliability >> >>requirements, as I see >> >>>>them, a little. As I see it, when I send a message, there are three >>>>levels of reliability that I might care about. Consider the >> >>following >> >>>>scenarios: >>>> >>>>1) I really don't care at all. (Strangely, this is the mode >> >>used by a >> >>>>lot of existing large scale systems. If we are dealing with highly >>>>interactive conversations between humans, humans provide their own >>>>reliability mechanism. I find myself typing "Hey, did you get my IM >>>>about X a few minutes ago" frequently.) >>>> >>>>2) I want a good effort to deliver, and a good attempt to >> >>tell me if >> >>>>something went wrong. If I hear nothing, I assume it most >>>>likely worked. >>>> >>>>3) Delivery is critical. I want to be told that it worked, and if I >>>>don't hear anything, I assume it most likely failed. >>>> >>>>My personal opinion is that 1 is generally unacceptable >>>>(dispite current >>>>systems), 3 should be an option, but 2 will be the primary >>>>use case, and >>>>the one we should optimize for. The rest of this email takes that >>>>perspective; if consensus proves me wrong then my analysis >>>>will change. >>>> >>>>We have a controversy about whether MSRP, in the general case where >>>>relays exist, should use per-hop transaction acknowledgements, or >>>>whether acknowledgments should be strictly end-to-end. >>>> >>>>First, let us consider the success cases; that is, when everything >>>>works. The per-hop case looks something like the following: >>>> >>>> A R1 R2 B >>>> SEND------> >>>> <--------OK >>>> SEND------> >>>> <--------OK >>>> SEND------> >>>> <--------OK >>>> >>>> >>>>This is not-optimal for the happy case, because each device >>>>has to keep >>>>transaction state until it gets a response. This state is >>>>_only_ useful >>>>if a failure occurs. (We will look at failure cases in a minute.) >>>>However, this state is not huge. As currently defined in >>>>MSRP, it would >>>>be the transaction identity and a timer. Adam proposed we do >>>>not need a >>>>mandatory timer, which would make it even smaller. >>>> >>>>In a perfect world, the end-to-end approach would look like: >>>> >>>> A R1 R2 B >>>> SEND------> >>>> SEND------> >>>> SEND------> >>>> >>>>This looks great on the surface. Not only can the relays be >>>>transaction >>>>stateless, only half as many messages happen. But, for >> >>reasons I will >> >>>>explain in a moment, this approach makes it impractical to >> >>tell A if >> >>>>something goes wrong downstream. Therefore, in a realistic >>>>implementation, it looks more like: >>>> >>>> A R1 R2 B >>>> SEND------> >>>> SEND------> >>>> SEND------> >>>> <---DSN(success) >>>> <-------DSN >>>> <-------DSN >>>> >>>>This has the same number of messages. It does allow the >> >>relays to be >> >>>>stateless. >>>> >>>>So, now, lets assume a TCP failure happens between R1 and R2. >>>> >>>>The hop-hop case looks like the following. A gets a failure >>>>notification >>>>shortly after R1 notices the failure. >>>> >>>> A R1 R2 B >>>> SEND------> >>>> <--------OK >>>> SEND----X >>>> <----DSN(fail) >>>> >>>>One would hope to make the end-to-end case look similar. But, as I >>>>mentioned before, that is impractical. Assume R1 has had a TCP >>>>connection to R2 up for some time. R1 has sent a lot of >>>>messages in that >>>>time, including the one for A above. With hop-hop >> >>responses, R1 keeps >> >>>>state around for each message it relays, and destroys that >>>>state when it >>>>gets an OK response. When the TCP failure occurs, R1 sends failure >>>>reports for all messages for which it still has state. >>>> >>>>But in the end-end case, R1 cannot report the failure. (We >>>>said R1 would >>>>keep no state for end-to-end, remember.) But even if it _did_ keep >>>>state, it would have no good way to know where in the message >>>>stream the >>>>error occured. Unless it does something _extremely_ stateful, >>>>like watch >>>>for success DSNs to go by, then when a TCP error occurs, it >>>>must assume >>>>that every message it has every relayed on that connection >>>>failed, or at >>>>least every message sent for the past 9 minutes or so failed. >>>>(9 minutes >>>>being the normal time requried for the _application_ to >> >>learn of some >> >>>>TCP failures.) Since 9 minutes is an eternity for a busy >>>>relay, I assume >>>>this is not acceptable. Rather, the relay would report >>>>nothing. The flow >>>>would look like the following: >>>> >>>> A R1 R2 B >>>> SEND------> >>>> SEND---X >>>> >>>> >>>>A would eventually figure out the message failure due to the >>>>lack of a >>>>success report. A would have to wait some time before making this >>>>decision to avoid a high likelyhood of false positives. Using the 9 >>>>minute failure detection time above, this time would be >>>>something like >>>>(9*number of hops * 2) minutes. >>>> >>>>So, back to our scenarios. For scenario 1, the end-end >>>>approach clearly >>>>wins, assuming we have the option to turn off DSN entirely. >>>>Orit's draft >>>>suggested that, with all responses turned off, a relay would >>>>have about >>>>a %20 scale advantage. However, her experiment was based on SIP >>>>messages, which tend to be larger, more complicated to parse, >>>>and have a >>>>more complex transaction model, even over TCP. I have no way >>>>of knowing >>>>how much the SIP vs MSRP aspect will impact things, but I >> >>think it is >> >>>>safe to say that the savings for MSRP will be real, but >> >>less than the >> >>>>%20 savings she observed for SIP. >>>> >>>>For scenario 2, it is a harder call. The number of messages >>>>is the same >>>>for either approach. The work to do message parsing, etc is >> >>similar. >> >>>>Relays will have to keep state for the hop-hop approach, >>>>although if we >>>>accept Adam's proposal about removing transaction timers, >>>>this state is >>>>fairly small. Also, the time it requires for the sender to >>>>learn about >>>>the failure is considerably shorter for the hop-hop >> >>approach than for >> >>>>the end-end approach. Therefore, I personally think the >>>>hop-hop approach >>>>wins this one. >>>> >>>>For scenario 3, an end-end receipt will be required anytime >>>>relays are >>>>present. This means the hop-hop approach will require more >>>>messages than >>>>the end-end, giving the round to the end-end. >>>> >>>>So, considering that I believe 2 is the primary use case, I >>>>lean towards >>>>the hop-hop case. >>>> >>>>I would also like to address a few arguments that I have heard, and >>>>believe to be red herrings: >>>> >>>>1) A failure report cannot be interpreted with certainty to >>>>mean that a >>>>message was not delivered. There are a number of edge cases >> >>where you >> >>>>can successfully deliver a message, but report it failed. >>>>However, this >>>>is _also_ true with the end-end case; as it is possible for >>>>the success >>>>report itself to get lost. We can build a system that never claims >>>>success unless it was really successful, but we cannot >> >>build a system >> >>>>that never claims failure unless it really failed. >>>> >>>>2) Since the TCP connections are used in both directions, >>>>responses may >>>>backup behind IMs sent in the reverse direction. This has been an >>>>acknowledged problem with the use of full-duplex >> >>connections from the >> >>>>beginning. But the problem exists for the end-end case as well, as >>>>success reports can _also_ get stuck in traffic. We are >>>>taking steps in >>>>MSRP (chunking, possible removal of transaction timers) >> >>that I think >> >>>>will mitigate this somewhat. >>>> >>>>Conclusions: >>>> >>>>I personally prefer the hop-hop approach, with DSN on failure >>>>and DSN on >>>>success as optional. However, if I am in the minority on that >>>>point, I >>>>can live with the end to end model. I do, however, want the >>>>transaction >>>>model to be consistent. That is, I don't want to negotiate >> >>whether we >> >>>>send hop-hop transaction responses to SEND requests. Either >>>>MSRP calls >>>>for them, or it does not. >>>> >>>>Further, the VISIT request, and I assume BIND or whatever >>>>equivelant we >>>>come up with in the relay work, necessarily follow a hop-hop model. >>>>Making SEND end-end creates an inconsistency there. >>>> >>>>If we do decide to change (back) to e2e SEND requests, the >>>>impact on the >>>>base spec is not huge; it would involve taking away the transaction >>>>response to SEND, and putting in a stronger dependency on >> >>DSN. There >> >>>>would be more impact on the relay spec. >>>> >>>>Thanks! >>>> >>>>Ben. >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 10:30:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14733 for ; Tue, 13 Apr 2004 10:30:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOv5-0000ui-4p for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 10:29:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DETld7003512 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 10:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOv4-0000uZ-Rl for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 10:29:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14683 for ; Tue, 13 Apr 2004 10:29:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOv1-0006Ln-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 10:29:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOth-0006DX-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 10:28:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDOsP-00066r-00; Tue, 13 Apr 2004 10:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOsP-0000Tx-Un; Tue, 13 Apr 2004 10:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOrt-0000S3-7o for simple@optimus.ietf.org; Tue, 13 Apr 2004 10:26:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14496 for ; Tue, 13 Apr 2004 10:26:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOrp-00064Y-00 for simple@ietf.org; Tue, 13 Apr 2004 10:26:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOqn-0005xj-00 for simple@ietf.org; Tue, 13 Apr 2004 10:25:23 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BDOpL-0005qU-00 for simple@ietf.org; Tue, 13 Apr 2004 10:23:52 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3DENfIx039302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2004 09:23:42 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407BF7E4.9060504@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP message reliability(long) References: <2038BCC78B1AD641891A0D1AE133DBB7017978E4@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017978E4@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 09:23:32 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Ok, I'm sold with the hop-by-hop solution. But for completeness sake, can you comment on my last question (I think you missed it). Here it is again: > > >>>Ben, can you also elaborate on this: >>> >>> >>> >>>>If we do decide to change (back) to e2e SEND requests ... There >>>>would be more impact on the relay spec. Oops, sorry. I guess I did not scroll far enough. There would be impact on both relays and on the base spec. Since we have not written the relay spec yet, I am not all that worried. The impact would mean deviation from the way SIMS worked, but it would mainly mean removing functionality. As far as the base spec is concerned, we would need to remove the concept of a transaction response. We would no longer have transaction state, only message delivery state. (Similar, but subtlely different.) The only If a TCP failure occured, the only recourse to determine what messages had been delivered would be DSN, if it is turned on. Further, we would probably need to tighten behavior around failing to receiving positive DSN. It is not the effort to specify that worries me, as much as the effort to achieve consensus. > > > Thanks, > Hisham > > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 13.April.2004 15:53 >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP message reliability(long) >> >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>First off, let me say that I do not like 1 at all. You need >> >>some sort of protocol level ACKs on messages. You cannot >>guarantee that if a TCP socket received a message that also >>an application on top has also received it. There could be a >>socket listing but the application on top has crashed. >> >>>Now, hop-by-hop vs. end-to-end: >>> >>>In this scenario (hop-by-hop) >>> >>> A R1 R2 B >>> SEND------> >>> <--------OK >>> SEND------> >>> <--------OK >>> SEND------> >>> <--------OK >>> >>>The OK does not tell the sender anything about the final >> >>delivery of the SEND. It only tells that the next hop has >>successfully received the SEND. Why is that important? Why is >>it important for A, R1 and R2 to know that the next hop has >>received the SEND? Why isn't TCP good enough here? That's the >>question that needs answering. >> >>The value comes when an error occurs. Lets say R1 has had the >>connection >>up to R2 for some time. Then the connection fails in mid session.. >>Standard TCP interfaces give R1 know way of knowing how much data had >>been sent before the error occured. Therefore, R1 must assume that >>_nothing_ got delivered. This ties in with the DSN on error >>case below. >> >> >>> >>>In this scenario (end-to-end) >>> >>> A R1 R2 B >>> SEND------> >>> SEND------> >>> SEND------> >>> <------DSN >>> <-------DSN >>> <-------DSN >>> >>>IMO, the relays need to keep state and a timer, and sending >> >>a DSN is mandatory. If the DSN does not arrive after x units >>of time, a failure DSN is generated by the last hop that >>forwarded the SEND. Something like >> >>> A R1 R2 B >>> SEND------> >>> SEND------> >>> SEND--X >>> <-------DSN (failure) >>> <-------DSN >>> >>>Ben commented that "even if it (the relay) _did_ keep >> >>state, it would have no good way to know where in the message >>stream the error occured." My question is: is it important, >>say for R1, to know where the error occured (at R2, R3, R4 or B)? >> >>Sorry, I was unclear. I did not mean where the error occured >>in space, >>but rather in time. As in my example above, R2 has no way of >>knowing how >>much data got sent before the error occured. So how does he >>know which >>messages require DSN? He must assume the answer is "all of >>them", or at >>least "all of them for the last 9 or so minutes", since that is the >>typical time TCP will keep retransmitting before it gives up. >> >> >> >>>Ben, can you also elaborate of this: >>> >>> >>> >>>>If we do decide to change (back) to e2e SEND requests ... There >>>>would be more impact on the relay spec. >>> >>> >>>Thanks, >>>Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Ben Campbell >>>>Sent: 09.April.2004 00:14 >>>>To: Simple WG >>>>Subject: [Simple] MSRP message reliability(long) >>>> >>>> >>>>Hopefully, everyone has had a chance to look at Orit's draft >>>>giving an >>>>analysis and some recommendations concerning the way MSRP handles >>>>message acknowledgements. I responded separately with >>>>specific comments >>>>about that draft. However, I want to talk in general about >> >>the models >> >>>>that have been proposed, as I understand them. >>>> >>>>First, I would like to clarify the reliability >> >>requirements, as I see >> >>>>them, a little. As I see it, when I send a message, there are three >>>>levels of reliability that I might care about. Consider the >> >>following >> >>>>scenarios: >>>> >>>>1) I really don't care at all. (Strangely, this is the mode >> >>used by a >> >>>>lot of existing large scale systems. If we are dealing with highly >>>>interactive conversations between humans, humans provide their own >>>>reliability mechanism. I find myself typing "Hey, did you get my IM >>>>about X a few minutes ago" frequently.) >>>> >>>>2) I want a good effort to deliver, and a good attempt to >> >>tell me if >> >>>>something went wrong. If I hear nothing, I assume it most >>>>likely worked. >>>> >>>>3) Delivery is critical. I want to be told that it worked, and if I >>>>don't hear anything, I assume it most likely failed. >>>> >>>>My personal opinion is that 1 is generally unacceptable >>>>(dispite current >>>>systems), 3 should be an option, but 2 will be the primary >>>>use case, and >>>>the one we should optimize for. The rest of this email takes that >>>>perspective; if consensus proves me wrong then my analysis >>>>will change. >>>> >>>>We have a controversy about whether MSRP, in the general case where >>>>relays exist, should use per-hop transaction acknowledgements, or >>>>whether acknowledgments should be strictly end-to-end. >>>> >>>>First, let us consider the success cases; that is, when everything >>>>works. The per-hop case looks something like the following: >>>> >>>> A R1 R2 B >>>> SEND------> >>>> <--------OK >>>> SEND------> >>>> <--------OK >>>> SEND------> >>>> <--------OK >>>> >>>> >>>>This is not-optimal for the happy case, because each device >>>>has to keep >>>>transaction state until it gets a response. This state is >>>>_only_ useful >>>>if a failure occurs. (We will look at failure cases in a minute.) >>>>However, this state is not huge. As currently defined in >>>>MSRP, it would >>>>be the transaction identity and a timer. Adam proposed we do >>>>not need a >>>>mandatory timer, which would make it even smaller. >>>> >>>>In a perfect world, the end-to-end approach would look like: >>>> >>>> A R1 R2 B >>>> SEND------> >>>> SEND------> >>>> SEND------> >>>> >>>>This looks great on the surface. Not only can the relays be >>>>transaction >>>>stateless, only half as many messages happen. But, for >> >>reasons I will >> >>>>explain in a moment, this approach makes it impractical to >> >>tell A if >> >>>>something goes wrong downstream. Therefore, in a realistic >>>>implementation, it looks more like: >>>> >>>> A R1 R2 B >>>> SEND------> >>>> SEND------> >>>> SEND------> >>>> <---DSN(success) >>>> <-------DSN >>>> <-------DSN >>>> >>>>This has the same number of messages. It does allow the >> >>relays to be >> >>>>stateless. >>>> >>>>So, now, lets assume a TCP failure happens between R1 and R2. >>>> >>>>The hop-hop case looks like the following. A gets a failure >>>>notification >>>>shortly after R1 notices the failure. >>>> >>>> A R1 R2 B >>>> SEND------> >>>> <--------OK >>>> SEND----X >>>> <----DSN(fail) >>>> >>>>One would hope to make the end-to-end case look similar. But, as I >>>>mentioned before, that is impractical. Assume R1 has had a TCP >>>>connection to R2 up for some time. R1 has sent a lot of >>>>messages in that >>>>time, including the one for A above. With hop-hop >> >>responses, R1 keeps >> >>>>state around for each message it relays, and destroys that >>>>state when it >>>>gets an OK response. When the TCP failure occurs, R1 sends failure >>>>reports for all messages for which it still has state. >>>> >>>>But in the end-end case, R1 cannot report the failure. (We >>>>said R1 would >>>>keep no state for end-to-end, remember.) But even if it _did_ keep >>>>state, it would have no good way to know where in the message >>>>stream the >>>>error occured. Unless it does something _extremely_ stateful, >>>>like watch >>>>for success DSNs to go by, then when a TCP error occurs, it >>>>must assume >>>>that every message it has every relayed on that connection >>>>failed, or at >>>>least every message sent for the past 9 minutes or so failed. >>>>(9 minutes >>>>being the normal time requried for the _application_ to >> >>learn of some >> >>>>TCP failures.) Since 9 minutes is an eternity for a busy >>>>relay, I assume >>>>this is not acceptable. Rather, the relay would report >>>>nothing. The flow >>>>would look like the following: >>>> >>>> A R1 R2 B >>>> SEND------> >>>> SEND---X >>>> >>>> >>>>A would eventually figure out the message failure due to the >>>>lack of a >>>>success report. A would have to wait some time before making this >>>>decision to avoid a high likelyhood of false positives. Using the 9 >>>>minute failure detection time above, this time would be >>>>something like >>>>(9*number of hops * 2) minutes. >>>> >>>>So, back to our scenarios. For scenario 1, the end-end >>>>approach clearly >>>>wins, assuming we have the option to turn off DSN entirely. >>>>Orit's draft >>>>suggested that, with all responses turned off, a relay would >>>>have about >>>>a %20 scale advantage. However, her experiment was based on SIP >>>>messages, which tend to be larger, more complicated to parse, >>>>and have a >>>>more complex transaction model, even over TCP. I have no way >>>>of knowing >>>>how much the SIP vs MSRP aspect will impact things, but I >> >>think it is >> >>>>safe to say that the savings for MSRP will be real, but >> >>less than the >> >>>>%20 savings she observed for SIP. >>>> >>>>For scenario 2, it is a harder call. The number of messages >>>>is the same >>>>for either approach. The work to do message parsing, etc is >> >>similar. >> >>>>Relays will have to keep state for the hop-hop approach, >>>>although if we >>>>accept Adam's proposal about removing transaction timers, >>>>this state is >>>>fairly small. Also, the time it requires for the sender to >>>>learn about >>>>the failure is considerably shorter for the hop-hop >> >>approach than for >> >>>>the end-end approach. Therefore, I personally think the >>>>hop-hop approach >>>>wins this one. >>>> >>>>For scenario 3, an end-end receipt will be required anytime >>>>relays are >>>>present. This means the hop-hop approach will require more >>>>messages than >>>>the end-end, giving the round to the end-end. >>>> >>>>So, considering that I believe 2 is the primary use case, I >>>>lean towards >>>>the hop-hop case. >>>> >>>>I would also like to address a few arguments that I have heard, and >>>>believe to be red herrings: >>>> >>>>1) A failure report cannot be interpreted with certainty to >>>>mean that a >>>>message was not delivered. There are a number of edge cases >> >>where you >> >>>>can successfully deliver a message, but report it failed. >>>>However, this >>>>is _also_ true with the end-end case; as it is possible for >>>>the success >>>>report itself to get lost. We can build a system that never claims >>>>success unless it was really successful, but we cannot >> >>build a system >> >>>>that never claims failure unless it really failed. >>>> >>>>2) Since the TCP connections are used in both directions, >>>>responses may >>>>backup behind IMs sent in the reverse direction. This has been an >>>>acknowledged problem with the use of full-duplex >> >>connections from the >> >>>>beginning. But the problem exists for the end-end case as well, as >>>>success reports can _also_ get stuck in traffic. We are >>>>taking steps in >>>>MSRP (chunking, possible removal of transaction timers) >> >>that I think >> >>>>will mitigate this somewhat. >>>> >>>>Conclusions: >>>> >>>>I personally prefer the hop-hop approach, with DSN on failure >>>>and DSN on >>>>success as optional. However, if I am in the minority on that >>>>point, I >>>>can live with the end to end model. I do, however, want the >>>>transaction >>>>model to be consistent. That is, I don't want to negotiate >> >>whether we >> >>>>send hop-hop transaction responses to SEND requests. Either >>>>MSRP calls >>>>for them, or it does not. >>>> >>>>Further, the VISIT request, and I assume BIND or whatever >>>>equivelant we >>>>come up with in the relay work, necessarily follow a hop-hop model. >>>>Making SEND end-end creates an inconsistency there. >>>> >>>>If we do decide to change (back) to e2e SEND requests, the >>>>impact on the >>>>base spec is not huge; it would involve taking away the transaction >>>>response to SEND, and putting in a stronger dependency on >> >>DSN. There >> >>>>would be more impact on the relay spec. >>>> >>>>Thanks! >>>> >>>>Ben. >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 15:06:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28146 for ; Tue, 13 Apr 2004 15:06:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTEO-00069a-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 15:06:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTCa-000624-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 15:04:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDTCF-0005x0-00; Tue, 13 Apr 2004 15:03:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDT3l-0003mY-9m; Tue, 13 Apr 2004 14:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSxj-0002qb-C3 for simple@optimus.ietf.org; Tue, 13 Apr 2004 14:48:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27043 for ; Tue, 13 Apr 2004 14:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDSxf-0004kK-00 for simple@ietf.org; Tue, 13 Apr 2004 14:48:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDSwQ-0004fD-00 for simple@ietf.org; Tue, 13 Apr 2004 14:47:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BDSvU-0004Yc-00 for simple@ietf.org; Tue, 13 Apr 2004 14:46:28 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2004 11:40:05 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3DIjqCC011451 for ; Tue, 13 Apr 2004 14:45:53 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO36822; Tue, 13 Apr 2004 14:45:51 -0400 (EDT) Message-ID: <407C355F.2010705@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] message-sessions-05 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 14:45:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, A few comments on the latest version. (I have been following the discussion on DSRs, but I just haven't had time to carefully think thru the issues, so no comment on the major issues of that right now.) I've recently been looking into generalized mime support in sip. As a result of that, I have concluded that its ugly to special case the mime headers in each protocol that embeds mime bodies. Doing so just complicates the code. So I think we should be careful to ensure that mime headers are handled compatibly in the enclosing protocol and in mime. There are a couple of implications here: - we ought to make the syntax of Content-Type identical to what it is in mime, either by copying or by reference. Currently it is the same, except that msrp doesn't define "token" at all. - there should be provision for other mime entity headers. (I know this is already on the to-do list.) Both of these can be covered by normatively referencing the definition of entity-headers from RFC 2045. To avoid confusion, msrp can either simply adopt the definition of token from 2045 for all purposes. Or it can provide its own definition of token but call it something else so its syntax can coexist with that of 2045. (Note that there is currently an inconsistency between 3261 and 2045 because they use different definitions of token. 2045 is less restrictive, so there could be some valid mime content-type headers that are not valid as sip content-type headers. The 2045 definition of token permits !#$&^{|} in addition to everything 3261 permits. Apparently it hasn't been a problem so far, but we might as well avoid that inconsistency in msrp.) Nit: in the definition of header: header = Tran-ID / Session-URL / Content-Types / From / To / Message-Receipt / Receipt-ID / Byte-Range Content-Types should be Content-Type. Nit: in the following: receipt-type = "receipt-type" "=" alt-receipt-type wouldn't it be simpler to just say receipt-type = "receipt-type" "=" media-type (from the definition of Content-Type) and avoid all the redundant definitions? Receipt-Type negotiation: Seems bad to have to accept a receipt as a regular message in order to negotiate it as an alternate receipt type. Seems better to just let receipt-type be a request for a different type that can be honored or not, with the default type being always acceptable. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 15:25:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01141 for ; Tue, 13 Apr 2004 15:25:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTO9-0007u9-7k for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 15:16:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DJG5CX030385 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 15:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTEU-0002HL-PA for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 15:06:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28168 for ; Tue, 13 Apr 2004 15:06:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTEQ-00069d-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 15:06:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTCa-00062B-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 15:04:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDTCF-0005x0-00; Tue, 13 Apr 2004 15:03:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDT3l-0003mY-9m; Tue, 13 Apr 2004 14:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSxj-0002qb-C3 for simple@optimus.ietf.org; Tue, 13 Apr 2004 14:48:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27043 for ; Tue, 13 Apr 2004 14:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDSxf-0004kK-00 for simple@ietf.org; Tue, 13 Apr 2004 14:48:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDSwQ-0004fD-00 for simple@ietf.org; Tue, 13 Apr 2004 14:47:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BDSvU-0004Yc-00 for simple@ietf.org; Tue, 13 Apr 2004 14:46:28 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2004 11:40:05 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3DIjqCC011451 for ; Tue, 13 Apr 2004 14:45:53 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO36822; Tue, 13 Apr 2004 14:45:51 -0400 (EDT) Message-ID: <407C355F.2010705@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] message-sessions-05 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 14:45:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben, A few comments on the latest version. (I have been following the discussion on DSRs, but I just haven't had time to carefully think thru the issues, so no comment on the major issues of that right now.) I've recently been looking into generalized mime support in sip. As a result of that, I have concluded that its ugly to special case the mime headers in each protocol that embeds mime bodies. Doing so just complicates the code. So I think we should be careful to ensure that mime headers are handled compatibly in the enclosing protocol and in mime. There are a couple of implications here: - we ought to make the syntax of Content-Type identical to what it is in mime, either by copying or by reference. Currently it is the same, except that msrp doesn't define "token" at all. - there should be provision for other mime entity headers. (I know this is already on the to-do list.) Both of these can be covered by normatively referencing the definition of entity-headers from RFC 2045. To avoid confusion, msrp can either simply adopt the definition of token from 2045 for all purposes. Or it can provide its own definition of token but call it something else so its syntax can coexist with that of 2045. (Note that there is currently an inconsistency between 3261 and 2045 because they use different definitions of token. 2045 is less restrictive, so there could be some valid mime content-type headers that are not valid as sip content-type headers. The 2045 definition of token permits !#$&^{|} in addition to everything 3261 permits. Apparently it hasn't been a problem so far, but we might as well avoid that inconsistency in msrp.) Nit: in the definition of header: header = Tran-ID / Session-URL / Content-Types / From / To / Message-Receipt / Receipt-ID / Byte-Range Content-Types should be Content-Type. Nit: in the following: receipt-type = "receipt-type" "=" alt-receipt-type wouldn't it be simpler to just say receipt-type = "receipt-type" "=" media-type (from the definition of Content-Type) and avoid all the redundant definitions? Receipt-Type negotiation: Seems bad to have to accept a receipt as a regular message in order to negotiate it as an alternate receipt type. Seems better to just let receipt-type be a request for a different type that can be honored or not, with the default type being always acceptable. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 17:12:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08619 for ; Tue, 13 Apr 2004 17:12:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVD9-0003CU-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 17:12:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDV28-0002J7-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 17:01:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDUuh-0001NC-00; Tue, 13 Apr 2004 16:53:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDToo-0004gn-1X; Tue, 13 Apr 2004 15:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTeE-0002u4-Uq for simple@optimus.ietf.org; Tue, 13 Apr 2004 15:32:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01730; Tue, 13 Apr 2004 15:32:40 -0400 (EDT) Message-Id: <200404131932.PAA01730@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-05.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 15:32:40 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : The Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-05.txt Pages : 41 Date : 2004-4-13 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model carried by a signaling protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-13155338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-13155338.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 13 17:16:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09039 for ; Tue, 13 Apr 2004 17:16:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVGV-0003aH-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 17:16:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDV7w-0002hy-00 for simple-archive@ietf.org; Tue, 13 Apr 2004 17:07:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDUy4-0001mh-00; Tue, 13 Apr 2004 16:57:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTor-0004hG-8J; Tue, 13 Apr 2004 15:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTeP-0002v8-7E for simple@optimus.ietf.org; Tue, 13 Apr 2004 15:32:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01737; Tue, 13 Apr 2004 15:32:51 -0400 (EDT) Message-Id: <200404131932.PAA01737@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-future-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 15:32:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Timed Presence Extensions to the Presence Information Data Format(PIDF) to Indicate Presence Information for Past and Future Time Intervals Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-01.txt Pages : 14 Date : 2004-4-13 The timed presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time interval fully in the future or the past. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-future-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-future-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-13155351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-future-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-future-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-13155351.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 17:37:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10782 for ; Tue, 13 Apr 2004 17:37:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVRx-0001sR-RT for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 17:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLS9eI007193 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 17:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVDI-0002AO-1J for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 17:13:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08641 for ; Tue, 13 Apr 2004 17:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVDF-0003Fp-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 17:12:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDV29-0002JG-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 17:01:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDUuh-0001NC-00; Tue, 13 Apr 2004 16:53:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDToo-0004gn-1X; Tue, 13 Apr 2004 15:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTeE-0002u4-Uq for simple@optimus.ietf.org; Tue, 13 Apr 2004 15:32:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01730; Tue, 13 Apr 2004 15:32:40 -0400 (EDT) Message-Id: <200404131932.PAA01730@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-05.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 15:32:40 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : The Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-05.txt Pages : 41 Date : 2004-4-13 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model carried by a signaling protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-13155338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-13155338.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 13 17:38:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10808 for ; Tue, 13 Apr 2004 17:38:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVSK-0002SK-2p for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 17:28:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLSWVk009436 for simple-archive@odin.ietf.org; Tue, 13 Apr 2004 17:28:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVGd-0005BZ-Sc for simple-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 17:16:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09074 for ; Tue, 13 Apr 2004 17:16:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVGb-0003aw-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 17:16:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDV7x-0002i9-00 for simple-web-archive@ietf.org; Tue, 13 Apr 2004 17:07:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDUy4-0001mh-00; Tue, 13 Apr 2004 16:57:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTor-0004hG-8J; Tue, 13 Apr 2004 15:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTeP-0002v8-7E for simple@optimus.ietf.org; Tue, 13 Apr 2004 15:32:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01737; Tue, 13 Apr 2004 15:32:51 -0400 (EDT) Message-Id: <200404131932.PAA01737@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-future-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 15:32:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Timed Presence Extensions to the Presence Information Data Format(PIDF) to Indicate Presence Information for Past and Future Time Intervals Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-01.txt Pages : 14 Date : 2004-4-13 The timed presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time interval fully in the future or the past. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-future-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-future-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-13155351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-future-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-future-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-13155351.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 04:49:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09985 for ; Wed, 14 Apr 2004 04:49:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDg5S-0006ki-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 04:49:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDg4a-0006Yz-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 04:48:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDg3d-0006P4-00; Wed, 14 Apr 2004 04:47:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfqK-00068V-FZ; Wed, 14 Apr 2004 04:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfmq-00059m-5O for simple@optimus.ietf.org; Wed, 14 Apr 2004 04:30:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09231 for ; Wed, 14 Apr 2004 04:30:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDfmn-0004ND-00 for simple@ietf.org; Wed, 14 Apr 2004 04:30:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDflo-0004GE-00 for simple@ietf.org; Wed, 14 Apr 2004 04:29:20 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDfkv-00044Z-00 for simple@ietf.org; Wed, 14 Apr 2004 04:28:25 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with SMTP id i3E8RpOl030135; Wed, 14 Apr 2004 09:27:51 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [217.68.146.190]) with SMTP; Wed, 14 Apr 2004 09:27:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE0219B262@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQhihEqJ/B+WQnQR3GhE/WF53jQYwAbsP0w From: "Chris Boulton" To: "Paul Kyzivat" , "Simple WG" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 09:27:50 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > >Ben, > >A few comments on the latest version. (I have been following the >discussion on DSRs, but I just haven't had time to carefully think thru >the issues, so no comment on the major issues of that right now.) > >I've recently been looking into generalized mime support in sip. As a >result of that, I have concluded that its ugly to special case the mime >headers in each protocol that embeds mime bodies. Doing so just >complicates the code. > >So I think we should be careful to ensure that mime headers are handled >compatibly in the enclosing protocol and in mime. There are a couple of >implications here: > >- we ought to make the syntax of Content-Type identical to what it is in >mime, either by copying or by reference. Currently it is the same, >except that msrp doesn't define "token" at all. > >- there should be provision for other mime entity headers. (I know this >is already on the to-do list.) > >Both of these can be covered by normatively referencing the definition >of entity-headers from RFC 2045. To avoid confusion, msrp can either >simply adopt the definition of token from 2045 for all purposes. Or it >can provide its own definition of token but call it something else so >its syntax can coexist with that of 2045. > >(Note that there is currently an inconsistency between 3261 and 2045 >because they use different definitions of token. 2045 is less >restrictive, so there could be some valid mime content-type headers that >are not valid as sip content-type headers. The 2045 definition of token >permits !#$&^{|} in addition to everything 3261 permits. Apparently it >hasn't been a problem so far, but we might as well avoid that >inconsistency in msrp.) > >Nit: in the definition of header: > > header =3D Tran-ID / Session-URL / Content-Types / > From / To / Message-Receipt / Receipt-ID / > Byte-Range > >Content-Types should be Content-Type. > >Nit: in the following: > > receipt-type =3D "receipt-type" "=3D" alt-receipt-type > >wouldn't it be simpler to just say > > receipt-type =3D "receipt-type" "=3D" media-type > >(from the definition of Content-Type) and avoid all the redundant >definitions? [Chris Boulton] Done Paul. > >Receipt-Type negotiation: Seems bad to have to accept a receipt as a >regular message in order to negotiate it as an alternate receipt type. >Seems better to just let receipt-type be a request for a different type >that can be honored or not, with the default type being always acceptable. [Chris Boulton] mmmmm - not convinced. Doesn't this all depend on the importance placed on receiving the receipt? It could be critical for me to know it has been delivered. If an alternative receipt type is specified it must be one that was specified in the offer-answer exchange. If, for some reason the far end can not create the receipt due to this type, it should kick back with an appropriate error response. If a relay was involved, it could generate a negative receipt on the endpoints behalf. > > Paul > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 05:07:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10830 for ; Wed, 14 Apr 2004 05:07:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgGO-0003h3-SF for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 05:00:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E90uKS014189 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 05:00:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDg5V-0000bB-TV for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 04:49:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10001 for ; Wed, 14 Apr 2004 04:49:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDg5S-0006kn-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 04:49:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDg4b-0006Z6-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 04:48:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDg3d-0006P4-00; Wed, 14 Apr 2004 04:47:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfqK-00068V-FZ; Wed, 14 Apr 2004 04:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfmq-00059m-5O for simple@optimus.ietf.org; Wed, 14 Apr 2004 04:30:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09231 for ; Wed, 14 Apr 2004 04:30:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDfmn-0004ND-00 for simple@ietf.org; Wed, 14 Apr 2004 04:30:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDflo-0004GE-00 for simple@ietf.org; Wed, 14 Apr 2004 04:29:20 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDfkv-00044Z-00 for simple@ietf.org; Wed, 14 Apr 2004 04:28:25 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with SMTP id i3E8RpOl030135; Wed, 14 Apr 2004 09:27:51 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [217.68.146.190]) with SMTP; Wed, 14 Apr 2004 09:27:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE0219B262@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQhihEqJ/B+WQnQR3GhE/WF53jQYwAbsP0w From: "Chris Boulton" To: "Paul Kyzivat" , "Simple WG" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 09:27:50 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >Ben, > >A few comments on the latest version. (I have been following the >discussion on DSRs, but I just haven't had time to carefully think thru >the issues, so no comment on the major issues of that right now.) > >I've recently been looking into generalized mime support in sip. As a >result of that, I have concluded that its ugly to special case the mime >headers in each protocol that embeds mime bodies. Doing so just >complicates the code. > >So I think we should be careful to ensure that mime headers are handled >compatibly in the enclosing protocol and in mime. There are a couple of >implications here: > >- we ought to make the syntax of Content-Type identical to what it is in >mime, either by copying or by reference. Currently it is the same, >except that msrp doesn't define "token" at all. > >- there should be provision for other mime entity headers. (I know this >is already on the to-do list.) > >Both of these can be covered by normatively referencing the definition >of entity-headers from RFC 2045. To avoid confusion, msrp can either >simply adopt the definition of token from 2045 for all purposes. Or it >can provide its own definition of token but call it something else so >its syntax can coexist with that of 2045. > >(Note that there is currently an inconsistency between 3261 and 2045 >because they use different definitions of token. 2045 is less >restrictive, so there could be some valid mime content-type headers that >are not valid as sip content-type headers. The 2045 definition of token >permits !#$&^{|} in addition to everything 3261 permits. Apparently it >hasn't been a problem so far, but we might as well avoid that >inconsistency in msrp.) > >Nit: in the definition of header: > > header =3D Tran-ID / Session-URL / Content-Types / > From / To / Message-Receipt / Receipt-ID / > Byte-Range > >Content-Types should be Content-Type. > >Nit: in the following: > > receipt-type =3D "receipt-type" "=3D" alt-receipt-type > >wouldn't it be simpler to just say > > receipt-type =3D "receipt-type" "=3D" media-type > >(from the definition of Content-Type) and avoid all the redundant >definitions? [Chris Boulton] Done Paul. > >Receipt-Type negotiation: Seems bad to have to accept a receipt as a >regular message in order to negotiate it as an alternate receipt type. >Seems better to just let receipt-type be a request for a different type >that can be honored or not, with the default type being always acceptable. [Chris Boulton] mmmmm - not convinced. Doesn't this all depend on the importance placed on receiving the receipt? It could be critical for me to know it has been delivered. If an alternative receipt type is specified it must be one that was specified in the offer-answer exchange. If, for some reason the far end can not create the receipt due to this type, it should kick back with an appropriate error response. If a relay was involved, it could generate a negative receipt on the endpoints behalf. > > Paul > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 06:41:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15883 for ; Wed, 14 Apr 2004 06:41:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhpj-0004k6-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 06:41:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhoo-0004cw-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 06:40:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDhoM-0004Vp-00; Wed, 14 Apr 2004 06:40:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhef-0004qZ-2Q; Wed, 14 Apr 2004 06:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhVS-0002mT-44 for simple@optimus.ietf.org; Wed, 14 Apr 2004 06:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13820 for ; Wed, 14 Apr 2004 06:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhVO-0002In-00 for simple@ietf.org; Wed, 14 Apr 2004 06:20:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhUg-0002CF-00 for simple@ietf.org; Wed, 14 Apr 2004 06:19:47 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BDhUC-00024C-00 for simple@ietf.org; Wed, 14 Apr 2004 06:19:16 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3EAJCn06413; Wed, 14 Apr 2004 12:19:12 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3EAJBc25096; Wed, 14 Apr 2004 12:19:12 +0200 (MEST) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA02182; Wed, 14 Apr 2004 12:19:11 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Apr 2004 12:18:56 +0200 Message-ID: From: Schmidt Christian To: "'hgs@cs.columbia.edu'" Cc: simple@ietf.org Subject: AW: [Simple] I-D ACTION:draft-ietf-simple-future-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 12:18:55 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Henning, would it make sense to add information about expiration date/time, especially to the Past Time Intervals? In your example about the meeting, this could be perhaps 8 hours after end of the meeting. Afterwards this information is obsolete and can be deleted. What do you think about? Best regards, Christian Schmidt 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 : Timed Presence Extensions to the Presence Information Data Format(PIDF) to Indicate Presence Information for Past and Future Time Intervals Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-01.txt Pages : 14 Date : 2004-4-13 The timed presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time interval fully in the future or the past. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 06:53:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16425 for ; Wed, 14 Apr 2004 06:53:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhy0-0000DD-5L for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 06:50:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EAo4r9000809 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 06:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhpo-0007Nc-2Q for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 06:41:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15901 for ; Wed, 14 Apr 2004 06:41:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhpk-0004kC-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 06:41:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhoo-0004d3-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 06:40:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDhoM-0004Vp-00; Wed, 14 Apr 2004 06:40:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhef-0004qZ-2Q; Wed, 14 Apr 2004 06:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhVS-0002mT-44 for simple@optimus.ietf.org; Wed, 14 Apr 2004 06:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13820 for ; Wed, 14 Apr 2004 06:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhVO-0002In-00 for simple@ietf.org; Wed, 14 Apr 2004 06:20:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhUg-0002CF-00 for simple@ietf.org; Wed, 14 Apr 2004 06:19:47 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BDhUC-00024C-00 for simple@ietf.org; Wed, 14 Apr 2004 06:19:16 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3EAJCn06413; Wed, 14 Apr 2004 12:19:12 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3EAJBc25096; Wed, 14 Apr 2004 12:19:12 +0200 (MEST) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA02182; Wed, 14 Apr 2004 12:19:11 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Apr 2004 12:18:56 +0200 Message-ID: From: Schmidt Christian To: "'hgs@cs.columbia.edu'" Cc: simple@ietf.org Subject: AW: [Simple] I-D ACTION:draft-ietf-simple-future-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 12:18:55 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Henning, would it make sense to add information about expiration date/time, especially to the Past Time Intervals? In your example about the meeting, this could be perhaps 8 hours after end of the meeting. Afterwards this information is obsolete and can be deleted. What do you think about? Best regards, Christian Schmidt 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 : Timed Presence Extensions to the Presence Information Data Format(PIDF) to Indicate Presence Information for Past and Future Time Intervals Author(s) : H. Schulzrinne Filename : draft-ietf-simple-future-01.txt Pages : 14 Date : 2004-4-13 The timed presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time interval fully in the future or the past. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 09:20:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23179 for ; Wed, 14 Apr 2004 09:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkJa-0002RD-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 09:20:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkIf-0002LS-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 09:19:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDkIF-0002Ff-00; Wed, 14 Apr 2004 09:19:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkAR-0003YS-Jo; Wed, 14 Apr 2004 09:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDk2U-0001ja-K3 for simple@optimus.ietf.org; Wed, 14 Apr 2004 09:02:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22367 for ; Wed, 14 Apr 2004 09:02:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDk2T-00006v-00 for simple@ietf.org; Wed, 14 Apr 2004 09:02:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDk1W-0007ls-00 for simple@ietf.org; Wed, 14 Apr 2004 09:01:50 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BDk16-0007dU-00 for simple@ietf.org; Wed, 14 Apr 2004 09:01:24 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3ED1NfF016381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Apr 2004 09:01:24 -0400 (EDT) Message-ID: <407D3623.1000507@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Schmidt Christian CC: simple@ietf.org Subject: Re: AW: [Simple] I-D ACTION:draft-ietf-simple-future-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 09:01:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Christian, I'm confused by your note. The timed status would indicate the start and end time of the event (in the past), i.e., the duration of the meeting. It is up to the receiver to decide how long to retain old data. Some may keep it forever for logging purposes (calendar synchronization), others may delete it as soon as newer information is available. The latter is probably the likely implementation since past information is mainly useful in the absence of more current information on the status of the presentity. Henning Schmidt Christian wrote: > Henning, > > would it make sense to add information about expiration date/time, > especially to the Past Time Intervals? In your example about the > meeting, this could be perhaps 8 hours after end of the meeting. > Afterwards this information is obsolete and can be deleted. What do > you think about? > > Best regards, Christian Schmidt > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 09:32:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23744 for ; Wed, 14 Apr 2004 09:32:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkNu-0006Cg-Pj for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 09:24:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EDOwZG023842 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 09:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkJc-0005Fy-Jc for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 09:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23197 for ; Wed, 14 Apr 2004 09:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkJb-0002RI-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 09:20:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkIg-0002LZ-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 09:19:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDkIF-0002Ff-00; Wed, 14 Apr 2004 09:19:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkAR-0003YS-Jo; Wed, 14 Apr 2004 09:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDk2U-0001ja-K3 for simple@optimus.ietf.org; Wed, 14 Apr 2004 09:02:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22367 for ; Wed, 14 Apr 2004 09:02:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDk2T-00006v-00 for simple@ietf.org; Wed, 14 Apr 2004 09:02:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDk1W-0007ls-00 for simple@ietf.org; Wed, 14 Apr 2004 09:01:50 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BDk16-0007dU-00 for simple@ietf.org; Wed, 14 Apr 2004 09:01:24 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3ED1NfF016381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Apr 2004 09:01:24 -0400 (EDT) Message-ID: <407D3623.1000507@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Schmidt Christian CC: simple@ietf.org Subject: Re: AW: [Simple] I-D ACTION:draft-ietf-simple-future-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 09:01:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian, I'm confused by your note. The timed status would indicate the start and end time of the event (in the past), i.e., the duration of the meeting. It is up to the receiver to decide how long to retain old data. Some may keep it forever for logging purposes (calendar synchronization), others may delete it as soon as newer information is available. The latter is probably the likely implementation since past information is mainly useful in the absence of more current information on the status of the presentity. Henning Schmidt Christian wrote: > Henning, > > would it make sense to add information about expiration date/time, > especially to the Past Time Intervals? In your example about the > meeting, this could be perhaps 8 hours after end of the meeting. > Afterwards this information is obsolete and can be deleted. What do > you think about? > > Best regards, Christian Schmidt > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 10:12:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26762 for ; Wed, 14 Apr 2004 10:12:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDl7v-0002nH-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 10:12:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDl6z-0002eQ-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 10:11:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDl63-0002WA-00; Wed, 14 Apr 2004 10:10:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDktz-0000Z8-CI; Wed, 14 Apr 2004 09:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkcF-0001uD-Tp for simple@optimus.ietf.org; Wed, 14 Apr 2004 09:39:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24038 for ; Wed, 14 Apr 2004 09:39:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkcD-00057r-00 for simple@ietf.org; Wed, 14 Apr 2004 09:39:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkbL-00050R-00 for simple@ietf.org; Wed, 14 Apr 2004 09:38:51 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDkaq-0004rL-00 for simple@ietf.org; Wed, 14 Apr 2004 09:38:20 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2004 05:46:59 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3EDbl2O006110; Wed, 14 Apr 2004 06:37:48 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO89534; Wed, 14 Apr 2004 09:37:46 -0400 (EDT) Message-ID: <407D3EAA.80501@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Simple WG Subject: Re: [Simple] message-sessions-05 References: <45730E094814E44488F789C1CDED27AE0219B262@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 09:37:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Chris Boulton wrote: > >>Receipt-Type negotiation: Seems bad to have to accept a receipt as a >>regular message in order to negotiate it as an alternate receipt type. >>Seems better to just let receipt-type be a request for a different type >>that can be honored or not, with the default type being always >>acceptable. > > [Chris Boulton] mmmmm - not convinced. Doesn't this all depend on the > importance placed on receiving the receipt? It could be critical for me > to know it has been delivered. If an alternative receipt type is > specified it must be one that was specified in the offer-answer > exchange. If, for some reason the far end can not create the receipt > due to this type, it should kick back with an appropriate error > response. If a relay was involved, it could generate a negative receipt > on the endpoints behalf. Actually, the possible involvement of a relay supports my argument. It doesn't get to participate in the media type negotiation, yet it may have to generate a negative receipt. And it may only be able to generate the default receipt type. So, the sender of a message that requests a receipt must be prepared to accept a receipt of the default type even if it would prefer some other type. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 10:20:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27675 for ; Wed, 14 Apr 2004 10:20:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDl9B-0003Xq-GI for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 10:13:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EEDnHF013620 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 10:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDl7y-0002lB-Sh for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 10:12:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26781 for ; Wed, 14 Apr 2004 10:12:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDl7w-0002nM-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 10:12:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDl70-0002eX-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 10:11:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDl63-0002WA-00; Wed, 14 Apr 2004 10:10:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDktz-0000Z8-CI; Wed, 14 Apr 2004 09:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkcF-0001uD-Tp for simple@optimus.ietf.org; Wed, 14 Apr 2004 09:39:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24038 for ; Wed, 14 Apr 2004 09:39:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkcD-00057r-00 for simple@ietf.org; Wed, 14 Apr 2004 09:39:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkbL-00050R-00 for simple@ietf.org; Wed, 14 Apr 2004 09:38:51 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDkaq-0004rL-00 for simple@ietf.org; Wed, 14 Apr 2004 09:38:20 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2004 05:46:59 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3EDbl2O006110; Wed, 14 Apr 2004 06:37:48 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO89534; Wed, 14 Apr 2004 09:37:46 -0400 (EDT) Message-ID: <407D3EAA.80501@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Simple WG Subject: Re: [Simple] message-sessions-05 References: <45730E094814E44488F789C1CDED27AE0219B262@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 09:37:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris Boulton wrote: > >>Receipt-Type negotiation: Seems bad to have to accept a receipt as a >>regular message in order to negotiate it as an alternate receipt type. >>Seems better to just let receipt-type be a request for a different type >>that can be honored or not, with the default type being always >>acceptable. > > [Chris Boulton] mmmmm - not convinced. Doesn't this all depend on the > importance placed on receiving the receipt? It could be critical for me > to know it has been delivered. If an alternative receipt type is > specified it must be one that was specified in the offer-answer > exchange. If, for some reason the far end can not create the receipt > due to this type, it should kick back with an appropriate error > response. If a relay was involved, it could generate a negative receipt > on the endpoints behalf. Actually, the possible involvement of a relay supports my argument. It doesn't get to participate in the media type negotiation, yet it may have to generate a negative receipt. And it may only be able to generate the default receipt type. So, the sender of a message that requests a receipt must be prepared to accept a receipt of the default type even if it would prefer some other type. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 10:20:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27705 for ; Wed, 14 Apr 2004 10:20:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlFs-00040t-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 10:20:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlEn-0003sq-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 10:19:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDlE1-0003mH-00; Wed, 14 Apr 2004 10:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDl8V-0003Dn-6f; Wed, 14 Apr 2004 10:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkxO-0002Gq-GO for simple@optimus.ietf.org; Wed, 14 Apr 2004 10:01:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25588 for ; Wed, 14 Apr 2004 10:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkxM-0001FR-00 for simple@ietf.org; Wed, 14 Apr 2004 10:01:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkwV-00013m-00 for simple@ietf.org; Wed, 14 Apr 2004 10:00:43 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly03b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDkv1-0000mN-00 for simple@ietf.org; Wed, 14 Apr 2004 09:59:11 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly03b.srv.mailcontrol.com (MailControl) with SMTP id i3EDwZEF006033; Wed, 14 Apr 2004 14:58:35 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [217.68.146.190]) with SMTP; Wed, 14 Apr 2004 14:58:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF340@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiJbbmDaIfX3Q6Tzq35wC/WKaySQAAtp9Q From: "Chris Boulton" To: "Paul Kyzivat" Cc: "Simple WG" X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 14:58:35 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Paul, That was the intention the intention from=20 An MSRP endpoint MUST be capable of performing the DSN operations described in this specification and SHOULD support the DSN MIME type outlined. Perhaps I could make this more explicit and add text to specify that even if an alternative is specified in the receipt request, a client SHOULD be able to receive the default receipt type. Chris. >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 14 April 2004 14:38 >To: Chris Boulton >Cc: Simple WG >Subject: Re: [Simple] message-sessions-05 > > > >Chris Boulton wrote: > > >>>Receipt-Type negotiation: Seems bad to have to accept a receipt as a >>>regular message in order to negotiate it as an alternate receipt type. >>>Seems better to just let receipt-type be a request for a different type >>>that can be honored or not, with the default type being always >>>acceptable. >> >> [Chris Boulton] mmmmm - not convinced. Doesn't this all depend on the >> importance placed on receiving the receipt? It could be critical for me >> to know it has been delivered. If an alternative receipt type is >> specified it must be one that was specified in the offer-answer >> exchange. If, for some reason the far end can not create the receipt >> due to this type, it should kick back with an appropriate error >> response. If a relay was involved, it could generate a negative receipt >> on the endpoints behalf. > >Actually, the possible involvement of a relay supports my argument. It >doesn't get to participate in the media type negotiation, yet it may >have to generate a negative receipt. And it may only be able to generate >the default receipt type. > >So, the sender of a message that requests a receipt must be prepared to >accept a receipt of the default type even if it would prefer some other >type. > > Paul This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 10:32:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28158 for ; Wed, 14 Apr 2004 10:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlKq-00087g-E1 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 10:25:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EEPqZX031222 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 10:25:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlFv-0006z3-Jy for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 10:20:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27719 for ; Wed, 14 Apr 2004 10:20:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlFt-000410-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 10:20:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlEo-0003sx-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 10:19:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDlE1-0003mH-00; Wed, 14 Apr 2004 10:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDl8V-0003Dn-6f; Wed, 14 Apr 2004 10:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkxO-0002Gq-GO for simple@optimus.ietf.org; Wed, 14 Apr 2004 10:01:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25588 for ; Wed, 14 Apr 2004 10:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkxM-0001FR-00 for simple@ietf.org; Wed, 14 Apr 2004 10:01:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkwV-00013m-00 for simple@ietf.org; Wed, 14 Apr 2004 10:00:43 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly03b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDkv1-0000mN-00 for simple@ietf.org; Wed, 14 Apr 2004 09:59:11 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly03b.srv.mailcontrol.com (MailControl) with SMTP id i3EDwZEF006033; Wed, 14 Apr 2004 14:58:35 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [217.68.146.190]) with SMTP; Wed, 14 Apr 2004 14:58:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF340@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiJbbmDaIfX3Q6Tzq35wC/WKaySQAAtp9Q From: "Chris Boulton" To: "Paul Kyzivat" Cc: "Simple WG" X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 14:58:35 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Paul, That was the intention the intention from=20 An MSRP endpoint MUST be capable of performing the DSN operations described in this specification and SHOULD support the DSN MIME type outlined. Perhaps I could make this more explicit and add text to specify that even if an alternative is specified in the receipt request, a client SHOULD be able to receive the default receipt type. Chris. >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 14 April 2004 14:38 >To: Chris Boulton >Cc: Simple WG >Subject: Re: [Simple] message-sessions-05 > > > >Chris Boulton wrote: > > >>>Receipt-Type negotiation: Seems bad to have to accept a receipt as a >>>regular message in order to negotiate it as an alternate receipt type. >>>Seems better to just let receipt-type be a request for a different type >>>that can be honored or not, with the default type being always >>>acceptable. >> >> [Chris Boulton] mmmmm - not convinced. Doesn't this all depend on the >> importance placed on receiving the receipt? It could be critical for me >> to know it has been delivered. If an alternative receipt type is >> specified it must be one that was specified in the offer-answer >> exchange. If, for some reason the far end can not create the receipt >> due to this type, it should kick back with an appropriate error >> response. If a relay was involved, it could generate a negative receipt >> on the endpoints behalf. > >Actually, the possible involvement of a relay supports my argument. It >doesn't get to participate in the media type negotiation, yet it may >have to generate a negative receipt. And it may only be able to generate >the default receipt type. > >So, the sender of a message that requests a receipt must be prepared to >accept a receipt of the default type even if it would prefer some other >type. > > Paul This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 11:04:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29798 for ; Wed, 14 Apr 2004 11:04:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlvo-0000hW-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 11:04:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDluu-0000ee-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 11:03:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDluZ-0000cU-00; Wed, 14 Apr 2004 11:02:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlm5-0004tX-H3; Wed, 14 Apr 2004 10:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlho-0004Ks-LY for simple@optimus.ietf.org; Wed, 14 Apr 2004 10:49:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28816 for ; Wed, 14 Apr 2004 10:49:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlhm-0007QQ-00 for simple@ietf.org; Wed, 14 Apr 2004 10:49:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlgu-0007JF-00 for simple@ietf.org; Wed, 14 Apr 2004 10:48:41 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BDlfx-00075z-00 for simple@ietf.org; Wed, 14 Apr 2004 10:47:41 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2004 07:58:30 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3EEl8NP007541; Wed, 14 Apr 2004 10:47:09 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO95895; Wed, 14 Apr 2004 10:47:08 -0400 (EDT) Message-ID: <407D4EEC.1090304@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Simple WG Subject: Re: [Simple] message-sessions-05 References: <45730E094814E44488F789C1CDED27AE02BDF340@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 10:47:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Chris Boulton wrote: > Paul, > That was the intention the intention from > > An MSRP endpoint MUST be capable of performing the DSN > operations described in this specification and SHOULD support the DSN > MIME type outlined. > > Perhaps I could make this more explicit and add text to specify that > even if an alternative is specified in the receipt request, a client > SHOULD be able to receive the default receipt type. OK. If we are agreed on that, then what is the value of negotiating alternative receipt types in the offer/answer? Just indicate your preferred optional type in the message. The recipient will honor it if it can and wants to, or else it will use the default type. You have to be prepared to accept the default type anyway, so nothing is gained by an earlier negotiation. Paul >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 14 April 2004 14:38 >>To: Chris Boulton >>Cc: Simple WG >>Subject: Re: [Simple] message-sessions-05 >> >> >> >>Chris Boulton wrote: >> >>>>Receipt-Type negotiation: Seems bad to have to accept a receipt as a >>>>regular message in order to negotiate it as an alternate receipt >>> > type. > >>>>Seems better to just let receipt-type be a request for a different >>> > type > >>>>that can be honored or not, with the default type being always >>>>acceptable. >>> >>>[Chris Boulton] mmmmm - not convinced. Doesn't this all depend on >> > the > >>>importance placed on receiving the receipt? It could be critical for >> > me > >>>to know it has been delivered. If an alternative receipt type is >>>specified it must be one that was specified in the offer-answer >>>exchange. If, for some reason the far end can not create the receipt >>>due to this type, it should kick back with an appropriate error >>>response. If a relay was involved, it could generate a negative >> > receipt > >>>on the endpoints behalf. >> >>Actually, the possible involvement of a relay supports my argument. It >>doesn't get to participate in the media type negotiation, yet it may >>have to generate a negative receipt. And it may only be able to > > generate > >>the default receipt type. >> >>So, the sender of a message that requests a receipt must be prepared to >>accept a receipt of the default type even if it would prefer some other >>type. >> >> Paul > > > > > This message has been scanned for viruses by MailControl - www.mailcontrol.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 11:23:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01306 for ; Wed, 14 Apr 2004 11:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2t-0000Pm-CC for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 11:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EFBNW1001588 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 11:11:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlvr-000758-S4 for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 11:04:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29811 for ; Wed, 14 Apr 2004 11:04:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlvp-0000hb-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 11:04:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDluu-0000em-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 11:03:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDluZ-0000cU-00; Wed, 14 Apr 2004 11:02:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlm5-0004tX-H3; Wed, 14 Apr 2004 10:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlho-0004Ks-LY for simple@optimus.ietf.org; Wed, 14 Apr 2004 10:49:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28816 for ; Wed, 14 Apr 2004 10:49:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlhm-0007QQ-00 for simple@ietf.org; Wed, 14 Apr 2004 10:49:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlgu-0007JF-00 for simple@ietf.org; Wed, 14 Apr 2004 10:48:41 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BDlfx-00075z-00 for simple@ietf.org; Wed, 14 Apr 2004 10:47:41 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2004 07:58:30 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3EEl8NP007541; Wed, 14 Apr 2004 10:47:09 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO95895; Wed, 14 Apr 2004 10:47:08 -0400 (EDT) Message-ID: <407D4EEC.1090304@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Simple WG Subject: Re: [Simple] message-sessions-05 References: <45730E094814E44488F789C1CDED27AE02BDF340@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 10:47:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris Boulton wrote: > Paul, > That was the intention the intention from > > An MSRP endpoint MUST be capable of performing the DSN > operations described in this specification and SHOULD support the DSN > MIME type outlined. > > Perhaps I could make this more explicit and add text to specify that > even if an alternative is specified in the receipt request, a client > SHOULD be able to receive the default receipt type. OK. If we are agreed on that, then what is the value of negotiating alternative receipt types in the offer/answer? Just indicate your preferred optional type in the message. The recipient will honor it if it can and wants to, or else it will use the default type. You have to be prepared to accept the default type anyway, so nothing is gained by an earlier negotiation. Paul >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 14 April 2004 14:38 >>To: Chris Boulton >>Cc: Simple WG >>Subject: Re: [Simple] message-sessions-05 >> >> >> >>Chris Boulton wrote: >> >>>>Receipt-Type negotiation: Seems bad to have to accept a receipt as a >>>>regular message in order to negotiate it as an alternate receipt >>> > type. > >>>>Seems better to just let receipt-type be a request for a different >>> > type > >>>>that can be honored or not, with the default type being always >>>>acceptable. >>> >>>[Chris Boulton] mmmmm - not convinced. Doesn't this all depend on >> > the > >>>importance placed on receiving the receipt? It could be critical for >> > me > >>>to know it has been delivered. If an alternative receipt type is >>>specified it must be one that was specified in the offer-answer >>>exchange. If, for some reason the far end can not create the receipt >>>due to this type, it should kick back with an appropriate error >>>response. If a relay was involved, it could generate a negative >> > receipt > >>>on the endpoints behalf. >> >>Actually, the possible involvement of a relay supports my argument. It >>doesn't get to participate in the media type negotiation, yet it may >>have to generate a negative receipt. And it may only be able to > > generate > >>the default receipt type. >> >>So, the sender of a message that requests a receipt must be prepared to >>accept a receipt of the default type even if it would prefer some other >>type. >> >> Paul > > > > > This message has been scanned for viruses by MailControl - www.mailcontrol.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 11:40:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02196 for ; Wed, 14 Apr 2004 11:40:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmV0-0002av-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 11:40:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmTw-0002Qc-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 11:39:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDmS8-0002DY-06; Wed, 14 Apr 2004 11:37:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2Z-0000G6-2M; Wed, 14 Apr 2004 11:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlqC-0005jT-1H for simple@optimus.ietf.org; Wed, 14 Apr 2004 10:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29338 for ; Wed, 14 Apr 2004 10:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlq9-0000NM-00 for simple@ietf.org; Wed, 14 Apr 2004 10:58:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlpE-0000KT-00 for simple@ietf.org; Wed, 14 Apr 2004 10:57:17 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDlop-0000HB-00 for simple@ietf.org; Wed, 14 Apr 2004 10:56:51 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with SMTP id i3EEuGOl002212; Wed, 14 Apr 2004 15:56:16 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [217.68.146.190]) with SMTP; Wed, 14 Apr 2004 15:56:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE0219B266@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiL2VWsvGPwQzCTZqziH//0acoiQAAFnmA From: "Chris Boulton" To: "Paul Kyzivat" Cc: "Simple WG" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 15:56:16 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > >Chris Boulton wrote: >> Paul, >> That was the intention the intention from >> >> An MSRP endpoint MUST be capable of performing the DSN >> operations described in this specification and SHOULD support the DSN >> MIME type outlined. >> >> Perhaps I could make this more explicit and add text to specify that >> even if an alternative is specified in the receipt request, a client >> SHOULD be able to receive the default receipt type. > >OK. If we are agreed on that, then what is the value of negotiating >alternative receipt types in the offer/answer? Just indicate your >preferred optional type in the message. The recipient will honor it if >it can and wants to, or else it will use the default type. You have to >be prepared to accept the default type anyway, so nothing is gained by >an earlier negotiation. > > Paul [Chris Boulton] The idea was that an alternative mechanism CAN be used BUT it MUST be listed as a supported type that appeared in the offer/answer exchange - there could be many supported types listed. This increases the likelihood that the alternative payload is supported by both clients. This does not override the default BUT enhances the options available on a per message basis and makes it far more extensible.=20 > >>>-----Original Message----- >>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>Sent: 14 April 2004 14:38 >>>To: Chris Boulton >>>Cc: Simple WG >>>Subject: Re: [Simple] message-sessions-05 >>> >>> >>> >>>Chris Boulton wrote: >>> >>>>>Receipt-Type negotiation: Seems bad to have to accept a receipt as a >>>>>regular message in order to negotiate it as an alternate receipt >>>> >> type. >> >>>>>Seems better to just let receipt-type be a request for a different >>>> >> type >> >>>>>that can be honored or not, with the default type being always >>>>>acceptable. >>>> >>>>[Chris Boulton] mmmmm - not convinced. Doesn't this all depend on >>> >> the >> >>>>importance placed on receiving the receipt? It could be critical for >>> >> me >> >>>>to know it has been delivered. If an alternative receipt type is >>>>specified it must be one that was specified in the offer-answer >>>>exchange. If, for some reason the far end can not create the receipt >>>>due to this type, it should kick back with an appropriate error >>>>response. If a relay was involved, it could generate a negative >>> >> receipt >> >>>>on the endpoints behalf. >>> >>>Actually, the possible involvement of a relay supports my argument. It >>>doesn't get to participate in the media type negotiation, yet it may >>>have to generate a negative receipt. And it may only be able to >> >> generate >> >>>the default receipt type. >>> >>>So, the sender of a message that requests a receipt must be prepared to >>>accept a receipt of the default type even if it would prefer some other >>>type. >>> >>> Paul >> >> >> >> >> This message has been scanned for viruses by MailControl - >www.mailcontrol.com >> This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 11:43:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02550 for ; Wed, 14 Apr 2004 11:43:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmXA-0006ak-2w for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 11:42:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EFgeZ4025334 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 11:42:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmV2-0006Dm-3T for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 11:40:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02213 for ; Wed, 14 Apr 2004 11:40:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmV1-0002b1-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 11:40:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmTy-0002Qy-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 11:39:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDmS8-0002DY-06; Wed, 14 Apr 2004 11:37:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2Z-0000G6-2M; Wed, 14 Apr 2004 11:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlqC-0005jT-1H for simple@optimus.ietf.org; Wed, 14 Apr 2004 10:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29338 for ; Wed, 14 Apr 2004 10:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlq9-0000NM-00 for simple@ietf.org; Wed, 14 Apr 2004 10:58:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlpE-0000KT-00 for simple@ietf.org; Wed, 14 Apr 2004 10:57:17 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDlop-0000HB-00 for simple@ietf.org; Wed, 14 Apr 2004 10:56:51 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with SMTP id i3EEuGOl002212; Wed, 14 Apr 2004 15:56:16 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [217.68.146.190]) with SMTP; Wed, 14 Apr 2004 15:56:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE0219B266@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiL2VWsvGPwQzCTZqziH//0acoiQAAFnmA From: "Chris Boulton" To: "Paul Kyzivat" Cc: "Simple WG" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 15:56:16 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >Chris Boulton wrote: >> Paul, >> That was the intention the intention from >> >> An MSRP endpoint MUST be capable of performing the DSN >> operations described in this specification and SHOULD support the DSN >> MIME type outlined. >> >> Perhaps I could make this more explicit and add text to specify that >> even if an alternative is specified in the receipt request, a client >> SHOULD be able to receive the default receipt type. > >OK. If we are agreed on that, then what is the value of negotiating >alternative receipt types in the offer/answer? Just indicate your >preferred optional type in the message. The recipient will honor it if >it can and wants to, or else it will use the default type. You have to >be prepared to accept the default type anyway, so nothing is gained by >an earlier negotiation. > > Paul [Chris Boulton] The idea was that an alternative mechanism CAN be used BUT it MUST be listed as a supported type that appeared in the offer/answer exchange - there could be many supported types listed. This increases the likelihood that the alternative payload is supported by both clients. This does not override the default BUT enhances the options available on a per message basis and makes it far more extensible.=20 > >>>-----Original Message----- >>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>Sent: 14 April 2004 14:38 >>>To: Chris Boulton >>>Cc: Simple WG >>>Subject: Re: [Simple] message-sessions-05 >>> >>> >>> >>>Chris Boulton wrote: >>> >>>>>Receipt-Type negotiation: Seems bad to have to accept a receipt as a >>>>>regular message in order to negotiate it as an alternate receipt >>>> >> type. >> >>>>>Seems better to just let receipt-type be a request for a different >>>> >> type >> >>>>>that can be honored or not, with the default type being always >>>>>acceptable. >>>> >>>>[Chris Boulton] mmmmm - not convinced. Doesn't this all depend on >>> >> the >> >>>>importance placed on receiving the receipt? It could be critical for >>> >> me >> >>>>to know it has been delivered. If an alternative receipt type is >>>>specified it must be one that was specified in the offer-answer >>>>exchange. If, for some reason the far end can not create the receipt >>>>due to this type, it should kick back with an appropriate error >>>>response. If a relay was involved, it could generate a negative >>> >> receipt >> >>>>on the endpoints behalf. >>> >>>Actually, the possible involvement of a relay supports my argument. It >>>doesn't get to participate in the media type negotiation, yet it may >>>have to generate a negative receipt. And it may only be able to >> >> generate >> >>>the default receipt type. >>> >>>So, the sender of a message that requests a receipt must be prepared to >>>accept a receipt of the default type even if it would prefer some other >>>type. >>> >>> Paul >> >> >> >> >> This message has been scanned for viruses by MailControl - >www.mailcontrol.com >> This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 12:36:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04796 for ; Wed, 14 Apr 2004 12:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnNk-0005Qn-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 12:37:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnMm-0005Oe-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 12:36:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDnLv-0005MG-00; Wed, 14 Apr 2004 12:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBV-0004zf-0q; Wed, 14 Apr 2004 12:24:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmJx-0003sC-Mk for simple@optimus.ietf.org; Wed, 14 Apr 2004 11:29:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01509 for ; Wed, 14 Apr 2004 11:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmJw-0001uE-00 for simple@ietf.org; Wed, 14 Apr 2004 11:29:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmIy-0001sy-00 for simple@ietf.org; Wed, 14 Apr 2004 11:28:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmIn-0001rt-00 for simple@ietf.org; Wed, 14 Apr 2004 11:27:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2004 07:36:28 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3EFRG2O012643; Wed, 14 Apr 2004 08:27:17 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO99866; Wed, 14 Apr 2004 11:27:15 -0400 (EDT) Message-ID: <407D5852.5090007@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Simple WG Subject: Re: [Simple] message-sessions-05 References: <45730E094814E44488F789C1CDED27AE0219B266@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 11:27:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Chris Boulton wrote: >> >>OK. If we are agreed on that, then what is the value of negotiating >>alternative receipt types in the offer/answer? Just indicate your >>preferred optional type in the message. The recipient will honor it if >>it can and wants to, or else it will use the default type. You have to >>be prepared to accept the default type anyway, so nothing is gained by >>an earlier negotiation. > > [Chris Boulton] The idea was that an alternative mechanism CAN be used > BUT it MUST be listed as a supported type that appeared in the > offer/answer exchange - there could be many supported types listed. > This increases the likelihood that the alternative payload is supported > by both clients. This does not override the default BUT enhances the > options available on a per message basis and makes it far more > extensible. I don't see how this enhances the options available on a per-message basis. I can request a particular type even if it hasn't been negotiated. And whether it has been negotiated or not, I may receive what I request or not. I think maybe we need a concrete use case here. I'm just making this up - it seems plausible, though I don't know if it is realistic: Lets assume I want to transfer a file over this msrp session. Maybe for file transfers there is extra information that is worth reporting back. (Whether the file could be stored in the file system, or whatever.) So to support this there are a pair of content types: application/file (wraps the mimetype of the file) application/file-transfer-report (the alternative report format) Conceivably I might like the UI of my application to only offer file transfer if I know I will get a file transfer report back. Following your proposal, I could negotiate both content types as part of the offer/answer, and disable file transfer in my UI if they aren't both accepted. But does that let me achieve what I want? No! The following bad things can happen: - I can send the file. The other end, while in some sense supporting the file-transfer-report format, decides not to use it in reporting the result. This might happen because it has a generic plugin mechanism for content types, and there is one installed that understands the type, but the receiving application doesn't know how to use that type in this context. So I get the default report. - I could start receiving file-transfer-reports as send message bodies. But I only know how to deal with them as reports, not as messages. The point is that supporting a type isn't an all or nothing thing. The type is supported for certain purposes. Exchanging as messages is one purpose. Exchanging as delivery reports is a different purpose. If you want to negotiate this, then the negotiation needs to include the usage context. Certainly we could introduce a separate a-line to be used for negotiating delivery report types. But I just don't see the value in doing so. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 14 12:57:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05830 for ; Wed, 14 Apr 2004 12:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDni5-00072X-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 12:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnfy-0006gN-00 for simple-archive@ietf.org; Wed, 14 Apr 2004 12:55:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDnem-0006VE-00; Wed, 14 Apr 2004 12:54:36 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDnbv-0002j7-Pe; Wed, 14 Apr 2004 12:51:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCF-0005HC-ET; Wed, 14 Apr 2004 12:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmnu-0000p1-Rv for simple@optimus.ietf.org; Wed, 14 Apr 2004 11:59:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03152 for ; Wed, 14 Apr 2004 11:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmnt-0003SN-00 for simple@ietf.org; Wed, 14 Apr 2004 11:59:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmmy-0003Qx-00 for simple@ietf.org; Wed, 14 Apr 2004 11:59:00 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmmD-0003O8-00 for simple@ietf.org; Wed, 14 Apr 2004 11:58:13 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with SMTP id i3EFvLOl017054; Wed, 14 Apr 2004 16:57:22 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [217.68.146.190]) with SMTP; Wed, 14 Apr 2004 16:57:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF345@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiNP3ebrbH6f6IR/KEjbV+PGocjAAA89VA From: "Chris Boulton" To: "Paul Kyzivat" Cc: "Simple WG" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 16:57:21 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 14 April 2004 16:27 >To: Chris Boulton >Cc: Simple WG >Subject: Re: [Simple] message-sessions-05 > >Chris Boulton wrote: >>> >>>OK. If we are agreed on that, then what is the value of negotiating >>>alternative receipt types in the offer/answer? Just indicate your >>>preferred optional type in the message. The recipient will honor it if >>>it can and wants to, or else it will use the default type. You have to >>>be prepared to accept the default type anyway, so nothing is gained by >>>an earlier negotiation. >> >> [Chris Boulton] The idea was that an alternative mechanism CAN be used >> BUT it MUST be listed as a supported type that appeared in the >> offer/answer exchange - there could be many supported types listed. >> This increases the likelihood that the alternative payload is supported >> by both clients. This does not override the default BUT enhances the >> options available on a per message basis and makes it far more >> extensible. > >I don't see how this enhances the options available on a per-message >basis. I can request a particular type even if it hasn't been >negotiated. And whether it has been negotiated or not, I may receive >what I request or not. > >I think maybe we need a concrete use case here. I'm just making this up >- it seems plausible, though I don't know if it is realistic: > >Lets assume I want to transfer a file over this msrp session. Maybe for >file transfers there is extra information that is worth reporting back. >(Whether the file could be stored in the file system, or whatever.) > >So to support this there are a pair of content types: > > application/file (wraps the mimetype of the file) > application/file-transfer-report (the alternative report format) > >Conceivably I might like the UI of my application to only offer file >transfer if I know I will get a file transfer report back. > >Following your proposal, I could negotiate both content types as part of >the offer/answer, and disable file transfer in my UI if they aren't both >accepted. But does that let me achieve what I want? No! The following >bad things can happen: > >- I can send the file. The other end, while in some sense supporting > the file-transfer-report format, decides not to use it in reporting > the result. This might happen because it has a generic plugin > mechanism for content types, and there is one installed that > understands the type, but the receiving application doesn't know > how to use that type in this context. So I get the default report. > >- I could start receiving file-transfer-reports as send message bodies. > But I only know how to deal with them as reports, not as messages. > >The point is that supporting a type isn't an all or nothing thing. The >type is supported for certain purposes. Exchanging as messages is one >purpose. Exchanging as delivery reports is a different purpose. If you >want to negotiate this, then the negotiation needs to include the usage >context. Certainly we could introduce a separate a-line to be used for >negotiating delivery report types. But I just don't see the value in >doing so. > > Paul > [Chris Boulton] Paul - I'm not disagreeing with you - this is good stuff. I was just trying to offer a mechanism where by a strong hint of supported types was agreed + increasing the likelihood that the far end will support the type that I have explicitly specified on a per MSRP transaction basis - rather than just a hit and hope. This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 13:20:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08086 for ; Wed, 14 Apr 2004 13:20:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnsO-0007RJ-Ci for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 13:08:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EH8eRK028589 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 13:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnNn-0007jj-24 for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 12:37:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04813 for ; Wed, 14 Apr 2004 12:36:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnNl-0005Qt-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 12:37:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnMn-0005Om-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 12:36:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDnLv-0005MG-00; Wed, 14 Apr 2004 12:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBV-0004zf-0q; Wed, 14 Apr 2004 12:24:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmJx-0003sC-Mk for simple@optimus.ietf.org; Wed, 14 Apr 2004 11:29:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01509 for ; Wed, 14 Apr 2004 11:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmJw-0001uE-00 for simple@ietf.org; Wed, 14 Apr 2004 11:29:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmIy-0001sy-00 for simple@ietf.org; Wed, 14 Apr 2004 11:28:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmIn-0001rt-00 for simple@ietf.org; Wed, 14 Apr 2004 11:27:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2004 07:36:28 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3EFRG2O012643; Wed, 14 Apr 2004 08:27:17 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO99866; Wed, 14 Apr 2004 11:27:15 -0400 (EDT) Message-ID: <407D5852.5090007@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Simple WG Subject: Re: [Simple] message-sessions-05 References: <45730E094814E44488F789C1CDED27AE0219B266@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 11:27:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris Boulton wrote: >> >>OK. If we are agreed on that, then what is the value of negotiating >>alternative receipt types in the offer/answer? Just indicate your >>preferred optional type in the message. The recipient will honor it if >>it can and wants to, or else it will use the default type. You have to >>be prepared to accept the default type anyway, so nothing is gained by >>an earlier negotiation. > > [Chris Boulton] The idea was that an alternative mechanism CAN be used > BUT it MUST be listed as a supported type that appeared in the > offer/answer exchange - there could be many supported types listed. > This increases the likelihood that the alternative payload is supported > by both clients. This does not override the default BUT enhances the > options available on a per message basis and makes it far more > extensible. I don't see how this enhances the options available on a per-message basis. I can request a particular type even if it hasn't been negotiated. And whether it has been negotiated or not, I may receive what I request or not. I think maybe we need a concrete use case here. I'm just making this up - it seems plausible, though I don't know if it is realistic: Lets assume I want to transfer a file over this msrp session. Maybe for file transfers there is extra information that is worth reporting back. (Whether the file could be stored in the file system, or whatever.) So to support this there are a pair of content types: application/file (wraps the mimetype of the file) application/file-transfer-report (the alternative report format) Conceivably I might like the UI of my application to only offer file transfer if I know I will get a file transfer report back. Following your proposal, I could negotiate both content types as part of the offer/answer, and disable file transfer in my UI if they aren't both accepted. But does that let me achieve what I want? No! The following bad things can happen: - I can send the file. The other end, while in some sense supporting the file-transfer-report format, decides not to use it in reporting the result. This might happen because it has a generic plugin mechanism for content types, and there is one installed that understands the type, but the receiving application doesn't know how to use that type in this context. So I get the default report. - I could start receiving file-transfer-reports as send message bodies. But I only know how to deal with them as reports, not as messages. The point is that supporting a type isn't an all or nothing thing. The type is supported for certain purposes. Exchanging as messages is one purpose. Exchanging as delivery reports is a different purpose. If you want to negotiate this, then the negotiation needs to include the usage context. Certainly we could introduce a separate a-line to be used for negotiating delivery report types. But I just don't see the value in doing so. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 14 13:24:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08413 for ; Wed, 14 Apr 2004 13:24:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo0f-0001An-R3 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHHD1i004503 for simple-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDni8-0005Zp-5v for simple-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 12:58:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05848 for ; Wed, 14 Apr 2004 12:58:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDni6-00072c-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 12:58:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnfz-0006gU-00 for simple-web-archive@ietf.org; Wed, 14 Apr 2004 12:55:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDnem-0006VE-00; Wed, 14 Apr 2004 12:54:36 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDnbv-0002j7-Pe; Wed, 14 Apr 2004 12:51:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCF-0005HC-ET; Wed, 14 Apr 2004 12:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmnu-0000p1-Rv for simple@optimus.ietf.org; Wed, 14 Apr 2004 11:59:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03152 for ; Wed, 14 Apr 2004 11:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmnt-0003SN-00 for simple@ietf.org; Wed, 14 Apr 2004 11:59:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmmy-0003Qx-00 for simple@ietf.org; Wed, 14 Apr 2004 11:59:00 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmmD-0003O8-00 for simple@ietf.org; Wed, 14 Apr 2004 11:58:13 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with SMTP id i3EFvLOl017054; Wed, 14 Apr 2004 16:57:22 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for [217.68.146.190]) with SMTP; Wed, 14 Apr 2004 16:57:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF345@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiNP3ebrbH6f6IR/KEjbV+PGocjAAA89VA From: "Chris Boulton" To: "Paul Kyzivat" Cc: "Simple WG" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 16:57:21 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 14 April 2004 16:27 >To: Chris Boulton >Cc: Simple WG >Subject: Re: [Simple] message-sessions-05 > >Chris Boulton wrote: >>> >>>OK. If we are agreed on that, then what is the value of negotiating >>>alternative receipt types in the offer/answer? Just indicate your >>>preferred optional type in the message. The recipient will honor it if >>>it can and wants to, or else it will use the default type. You have to >>>be prepared to accept the default type anyway, so nothing is gained by >>>an earlier negotiation. >> >> [Chris Boulton] The idea was that an alternative mechanism CAN be used >> BUT it MUST be listed as a supported type that appeared in the >> offer/answer exchange - there could be many supported types listed. >> This increases the likelihood that the alternative payload is supported >> by both clients. This does not override the default BUT enhances the >> options available on a per message basis and makes it far more >> extensible. > >I don't see how this enhances the options available on a per-message >basis. I can request a particular type even if it hasn't been >negotiated. And whether it has been negotiated or not, I may receive >what I request or not. > >I think maybe we need a concrete use case here. I'm just making this up >- it seems plausible, though I don't know if it is realistic: > >Lets assume I want to transfer a file over this msrp session. Maybe for >file transfers there is extra information that is worth reporting back. >(Whether the file could be stored in the file system, or whatever.) > >So to support this there are a pair of content types: > > application/file (wraps the mimetype of the file) > application/file-transfer-report (the alternative report format) > >Conceivably I might like the UI of my application to only offer file >transfer if I know I will get a file transfer report back. > >Following your proposal, I could negotiate both content types as part of >the offer/answer, and disable file transfer in my UI if they aren't both >accepted. But does that let me achieve what I want? No! The following >bad things can happen: > >- I can send the file. The other end, while in some sense supporting > the file-transfer-report format, decides not to use it in reporting > the result. This might happen because it has a generic plugin > mechanism for content types, and there is one installed that > understands the type, but the receiving application doesn't know > how to use that type in this context. So I get the default report. > >- I could start receiving file-transfer-reports as send message bodies. > But I only know how to deal with them as reports, not as messages. > >The point is that supporting a type isn't an all or nothing thing. The >type is supported for certain purposes. Exchanging as messages is one >purpose. Exchanging as delivery reports is a different purpose. If you >want to negotiate this, then the negotiation needs to include the usage >context. Certainly we could introduce a separate a-line to be used for >negotiating delivery report types. But I just don't see the value in >doing so. > > Paul > [Chris Boulton] Paul - I'm not disagreeing with you - this is good stuff. I was just trying to offer a mechanism where by a strong hint of supported types was agreed + increasing the likelihood that the far end will support the type that I have explicitly specified on a per MSRP transaction basis - rather than just a hit and hope. This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 15 02:56:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05986 for ; Thu, 15 Apr 2004 02:56:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0n7-0001uK-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 02:56:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0m4-0001pa-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 02:55:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE0lp-0001lx-00; Thu, 15 Apr 2004 02:54:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0eM-0005AG-8Z; Thu, 15 Apr 2004 02:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0cK-0004Fa-Cl for simple@optimus.ietf.org; Thu, 15 Apr 2004 02:44:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05373 for ; Thu, 15 Apr 2004 02:44:53 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0cG-0000yp-00 for simple@ietf.org; Thu, 15 Apr 2004 02:44:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0bH-0000wD-00 for simple@ietf.org; Thu, 15 Apr 2004 02:43:52 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BE0aO-0000tz-00 for simple@ietf.org; Thu, 15 Apr 2004 02:42:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F6glk19813; Thu, 15 Apr 2004 09:42:47 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 09:42:41 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3F6gfZR031531; Thu, 15 Apr 2004 09:42:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ZiIBxC; Thu, 15 Apr 2004 09:42:40 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F6gds15820; Thu, 15 Apr 2004 09:42:39 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 09:42:19 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 09:42:18 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 09:42:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt Message-ID: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt Thread-Index: AcQflC3jV6aXvZaDTgijoiNePBI4XgDHfzmQ To: Cc: X-OriginalArrivalTime: 15 Apr 2004 06:42:18.0159 (UTC) FILETIME=[CBC883F0:01C422B4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 09:42:18 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I did not have time to read the draft so carefully this time, but=20 it seems that you have considered my comments. Thanks! A couple of other minor issues which I happened to notice (v. 04): - 4.1/the 1st chapter: also the could be mentioned (extends the = element) - 4.5/the last sentence: to be replaced by - 4.8: shouldn't the "RPID " be "PIDF "? >> - 6.1 and 6.2 (XML schemas): I did not find any reason to define the >> pidf namespace in the schema (see xmlns:pidf=3D"urn...") >Can you explain this comment? According to my understanding it is correct to define whichever = namespaces in the schema definition, but if they are not used by the XML Schema there is no need to define = them.=20 BR, Eva > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Henning Schulzrinne > Sent: 11 April, 2004 06:26 > To: Leppanen Eva-Maria (Nokia-NET/Tampere) > Cc: simple@ietf.org > Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt >=20 >=20 > Thanks for your careful comments. I've updated the draft: >=20 > http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rp id-04.html Before I submit it, if you have a chance to check that I didn't miss anything. One question below: eva-maria.leppanen@nokia.com wrote: > - 6.1 and 6.2 (XML schemas): I did not find any reason to define the > pidf namespace in the schema (see xmlns:pidf=3D"urn...") Can you explain this comment? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 15 03:06:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06436 for ; Thu, 15 Apr 2004 03:06:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0wQ-0001gy-Di for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 03:05:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F75gHA006499 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 03:05:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0nC-0007hK-3u for simple-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 02:56:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05996 for ; Thu, 15 Apr 2004 02:56:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0n8-0001uP-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 02:56:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0m5-0001ph-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 02:55:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE0lp-0001lx-00; Thu, 15 Apr 2004 02:54:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0eM-0005AG-8Z; Thu, 15 Apr 2004 02:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0cK-0004Fa-Cl for simple@optimus.ietf.org; Thu, 15 Apr 2004 02:44:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05373 for ; Thu, 15 Apr 2004 02:44:53 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0cG-0000yp-00 for simple@ietf.org; Thu, 15 Apr 2004 02:44:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0bH-0000wD-00 for simple@ietf.org; Thu, 15 Apr 2004 02:43:52 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BE0aO-0000tz-00 for simple@ietf.org; Thu, 15 Apr 2004 02:42:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F6glk19813; Thu, 15 Apr 2004 09:42:47 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 09:42:41 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3F6gfZR031531; Thu, 15 Apr 2004 09:42:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ZiIBxC; Thu, 15 Apr 2004 09:42:40 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F6gds15820; Thu, 15 Apr 2004 09:42:39 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 09:42:19 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 09:42:18 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 09:42:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt Message-ID: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt Thread-Index: AcQflC3jV6aXvZaDTgijoiNePBI4XgDHfzmQ To: Cc: X-OriginalArrivalTime: 15 Apr 2004 06:42:18.0159 (UTC) FILETIME=[CBC883F0:01C422B4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 09:42:18 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I did not have time to read the draft so carefully this time, but=20 it seems that you have considered my comments. Thanks! A couple of other minor issues which I happened to notice (v. 04): - 4.1/the 1st chapter: also the could be mentioned (extends the = element) - 4.5/the last sentence: to be replaced by - 4.8: shouldn't the "RPID " be "PIDF "? >> - 6.1 and 6.2 (XML schemas): I did not find any reason to define the >> pidf namespace in the schema (see xmlns:pidf=3D"urn...") >Can you explain this comment? According to my understanding it is correct to define whichever = namespaces in the schema definition, but if they are not used by the XML Schema there is no need to define = them.=20 BR, Eva > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Henning Schulzrinne > Sent: 11 April, 2004 06:26 > To: Leppanen Eva-Maria (Nokia-NET/Tampere) > Cc: simple@ietf.org > Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-rpid-03.txt >=20 >=20 > Thanks for your careful comments. I've updated the draft: >=20 > http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rp id-04.html Before I submit it, if you have a chance to check that I didn't miss anything. One question below: eva-maria.leppanen@nokia.com wrote: > - 6.1 and 6.2 (XML schemas): I did not find any reason to define the > pidf namespace in the schema (see xmlns:pidf=3D"urn...") Can you explain this comment? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 15 03:38:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08492 for ; Thu, 15 Apr 2004 03:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE1Sb-0005bq-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 03:38:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE1Qm-0005P2-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 03:37:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE1OV-0004zb-00; Thu, 15 Apr 2004 03:34:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1Kv-0001I1-U2; Thu, 15 Apr 2004 03:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1D3-0007wU-O0 for simple@optimus.ietf.org; Thu, 15 Apr 2004 03:22:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07399 for ; Thu, 15 Apr 2004 03:22:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE1D1-00044a-00 for simple@ietf.org; Thu, 15 Apr 2004 03:22:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE1C2-00041O-00 for simple@ietf.org; Thu, 15 Apr 2004 03:21:51 -0400 Received: from [202.177.179.184] (helo=Satyam) by ietf-mx with smtp (Exim 4.12) id 1BE1B3-0003wR-00 for simple@ietf.org; Thu, 15 Apr 2004 03:20:49 -0400 To: simple@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ddtrcakkphtsrvmwdgvt" Subject: [Simple] Hey, dude, it's me ^_^ :P Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 00:57:42 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 ----------ddtrcakkphtsrvmwdgvt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file Readme.zip The file Readme.zip is moved to /etc/iscan/virus/virHKAwyay4C. --------------------------------------------------------- ----------ddtrcakkphtsrvmwdgvt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) ..btw, "34006" is a password for archive ----------ddtrcakkphtsrvmwdgvt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Readme.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------ddtrcakkphtsrvmwdgvt-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 15 03:54:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09222 for ; Thu, 15 Apr 2004 03:54:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1Yk-0006md-Rp for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 03:45:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F7jIUq026067 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 03:45:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1Sf-0004tY-C4 for simple-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 03:39:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08510 for ; Thu, 15 Apr 2004 03:38:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE1Sd-0005cB-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 03:38:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE1Qn-0005PK-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 03:37:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE1OV-0004zb-00; Thu, 15 Apr 2004 03:34:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1Kv-0001I1-U2; Thu, 15 Apr 2004 03:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1D3-0007wU-O0 for simple@optimus.ietf.org; Thu, 15 Apr 2004 03:22:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07399 for ; Thu, 15 Apr 2004 03:22:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE1D1-00044a-00 for simple@ietf.org; Thu, 15 Apr 2004 03:22:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE1C2-00041O-00 for simple@ietf.org; Thu, 15 Apr 2004 03:21:51 -0400 Received: from [202.177.179.184] (helo=Satyam) by ietf-mx with smtp (Exim 4.12) id 1BE1B3-0003wR-00 for simple@ietf.org; Thu, 15 Apr 2004 03:20:49 -0400 To: simple@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ddtrcakkphtsrvmwdgvt" Subject: [Simple] Hey, dude, it's me ^_^ :P Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 00:57:42 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 ----------ddtrcakkphtsrvmwdgvt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file Readme.zip The file Readme.zip is moved to /etc/iscan/virus/virHKAwyay4C. --------------------------------------------------------- ----------ddtrcakkphtsrvmwdgvt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) ..btw, "34006" is a password for archive ----------ddtrcakkphtsrvmwdgvt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Readme.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------ddtrcakkphtsrvmwdgvt-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 15 04:51:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11930 for ; Thu, 15 Apr 2004 04:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2bF-0003FG-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 04:51:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2aK-0003Bg-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 04:51:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Zd-00038V-00; Thu, 15 Apr 2004 04:50:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2UZ-0008FY-Bj; Thu, 15 Apr 2004 04:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2Lp-0004sa-9h for simple@optimus.ietf.org; Thu, 15 Apr 2004 04:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11282 for ; Thu, 15 Apr 2004 04:35:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Lm-00021q-00 for simple@ietf.org; Thu, 15 Apr 2004 04:35:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2Ks-0001w4-00 for simple@ietf.org; Thu, 15 Apr 2004 04:35:02 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Jr-0001qV-00 for simple@ietf.org; Thu, 15 Apr 2004 04:33:59 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8XFn00881; Thu, 15 Apr 2004 11:33:15 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 11:32:39 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3F8WdpA009097; Thu, 15 Apr 2004 11:32:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00S9XhiK; Thu, 15 Apr 2004 11:32:28 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8WRF10018; Thu, 15 Apr 2004 11:32:28 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 11:32:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978FC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiJbbmDaIfX3Q6Tzq35wC/WKaySQAAtp9QACbjgOA= To: , Cc: X-OriginalArrivalTime: 15 Apr 2004 08:32:25.0697 (UTC) FILETIME=[2E2ECD10:01C422C4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 11:32:24 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Chris Boulton > Sent: 14.April.2004 16:59 > To: Paul Kyzivat > Cc: Simple WG > Subject: RE: [Simple] message-sessions-05 >=20 >=20 > Paul, > That was the intention the intention from=20 >=20 > An MSRP endpoint MUST be capable of performing the DSN > operations described in this specification and SHOULD=20 > support the DSN > MIME type outlined. >=20 > Perhaps I could make this more explicit and add text to specify that > even if an alternative is specified in the receipt request, a client > SHOULD be able to receive the default receipt type. >=20 I would say a MUST. /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 15 04:53:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12011 for ; Thu, 15 Apr 2004 04:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2cK-0003Lr-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 04:53:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2bP-0003H9-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 04:52:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2at-0003Co-00; Thu, 15 Apr 2004 04:51:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2VY-00008a-4u; Thu, 15 Apr 2004 04:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2TW-0007uc-H6 for simple@optimus.ietf.org; Thu, 15 Apr 2004 04:43:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11575 for ; Thu, 15 Apr 2004 04:43:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2TT-0002ba-00 for simple@ietf.org; Thu, 15 Apr 2004 04:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2SW-0002X6-00 for simple@ietf.org; Thu, 15 Apr 2004 04:42:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Rk-0002TP-00 for simple@ietf.org; Thu, 15 Apr 2004 04:42:08 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8fYH05301; Thu, 15 Apr 2004 11:41:34 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 11:41:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3F8fEF4000499; Thu, 15 Apr 2004 11:41:14 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00G5Tb4H; Thu, 15 Apr 2004 11:40:33 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8eSF14460; Thu, 15 Apr 2004 11:40:28 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 11:36:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 11:36:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978FD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiPsQQz2/FTcjoRfWkUOdt9VOFxAAhW1BA To: , Cc: X-OriginalArrivalTime: 15 Apr 2004 08:36:18.0878 (UTC) FILETIME=[B92B65E0:01C422C4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 11:36:18 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Paul is right. There is no point in negotiating. The recipient may = either choose a receipt type from the list as offered by the sender, or = it can use the default (if it chooses not to honour the sender's = preferred receipt types). The sender MUST be prepared to receive = receipts in the default format as well as all the formats it offered. Thanks, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Paul Kyzivat > Sent: 14.April.2004 18:27 > To: Chris Boulton > Cc: Simple WG > Subject: Re: [Simple] message-sessions-05 >=20 >=20 > Chris Boulton wrote: > >> > >>OK. If we are agreed on that, then what is the value of negotiating > >>alternative receipt types in the offer/answer? Just indicate your > >>preferred optional type in the message. The recipient will=20 > honor it if > >>it can and wants to, or else it will use the default type.=20 > You have to > >>be prepared to accept the default type anyway, so nothing=20 > is gained by > >>an earlier negotiation. > >=20 > > [Chris Boulton] The idea was that an alternative mechanism=20 > CAN be used > > BUT it MUST be listed as a supported type that appeared in the > > offer/answer exchange - there could be many supported types listed. > > This increases the likelihood that the alternative payload=20 > is supported > > by both clients. This does not override the default BUT=20 > enhances the > > options available on a per message basis and makes it far more > > extensible.=20 >=20 > I don't see how this enhances the options available on a per-message=20 > basis. I can request a particular type even if it hasn't been=20 > negotiated. And whether it has been negotiated or not, I may receive=20 > what I request or not. >=20 > I think maybe we need a concrete use case here. I'm just=20 > making this up=20 > - it seems plausible, though I don't know if it is realistic: >=20 > Lets assume I want to transfer a file over this msrp session.=20 > Maybe for=20 > file transfers there is extra information that is worth=20 > reporting back.=20 > (Whether the file could be stored in the file system, or whatever.) >=20 > So to support this there are a pair of content types: >=20 > application/file (wraps the mimetype of the file) > application/file-transfer-report (the alternative report format) >=20 > Conceivably I might like the UI of my application to only offer file=20 > transfer if I know I will get a file transfer report back. >=20 > Following your proposal, I could negotiate both content types=20 > as part of=20 > the offer/answer, and disable file transfer in my UI if they=20 > aren't both=20 > accepted. But does that let me achieve what I want? No! The following=20 > bad things can happen: >=20 > - I can send the file. The other end, while in some sense supporting > the file-transfer-report format, decides not to use it in reporting > the result. This might happen because it has a generic plugin > mechanism for content types, and there is one installed that > understands the type, but the receiving application doesn't know > how to use that type in this context. So I get the default report. >=20 > - I could start receiving file-transfer-reports as send=20 > message bodies. > But I only know how to deal with them as reports, not as messages. >=20 > The point is that supporting a type isn't an all or nothing=20 > thing. The=20 > type is supported for certain purposes. Exchanging as messages is one=20 > purpose. Exchanging as delivery reports is a different=20 > purpose. If you=20 > want to negotiate this, then the negotiation needs to include=20 > the usage=20 > context. Certainly we could introduce a separate a-line to be=20 > used for=20 > negotiating delivery report types. But I just don't see the value in=20 > doing so. >=20 > Paul >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 15 04:55:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12155 for ; Thu, 15 Apr 2004 04:55:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2cG-0002FM-Be for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 04:53:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F8r0eB008632 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 04:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2bI-0001sL-Rg for simple-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 04:52:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11942 for ; Thu, 15 Apr 2004 04:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2bF-0003FL-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 04:51:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2aL-0003Bo-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 04:51:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Zd-00038V-00; Thu, 15 Apr 2004 04:50:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2UZ-0008FY-Bj; Thu, 15 Apr 2004 04:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2Lp-0004sa-9h for simple@optimus.ietf.org; Thu, 15 Apr 2004 04:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11282 for ; Thu, 15 Apr 2004 04:35:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Lm-00021q-00 for simple@ietf.org; Thu, 15 Apr 2004 04:35:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2Ks-0001w4-00 for simple@ietf.org; Thu, 15 Apr 2004 04:35:02 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Jr-0001qV-00 for simple@ietf.org; Thu, 15 Apr 2004 04:33:59 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8XFn00881; Thu, 15 Apr 2004 11:33:15 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 11:32:39 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3F8WdpA009097; Thu, 15 Apr 2004 11:32:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00S9XhiK; Thu, 15 Apr 2004 11:32:28 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8WRF10018; Thu, 15 Apr 2004 11:32:28 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 11:32:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978FC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiJbbmDaIfX3Q6Tzq35wC/WKaySQAAtp9QACbjgOA= To: , Cc: X-OriginalArrivalTime: 15 Apr 2004 08:32:25.0697 (UTC) FILETIME=[2E2ECD10:01C422C4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 11:32:24 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Chris Boulton > Sent: 14.April.2004 16:59 > To: Paul Kyzivat > Cc: Simple WG > Subject: RE: [Simple] message-sessions-05 >=20 >=20 > Paul, > That was the intention the intention from=20 >=20 > An MSRP endpoint MUST be capable of performing the DSN > operations described in this specification and SHOULD=20 > support the DSN > MIME type outlined. >=20 > Perhaps I could make this more explicit and add text to specify that > even if an alternative is specified in the receipt request, a client > SHOULD be able to receive the default receipt type. >=20 I would say a MUST. /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 15 05:09:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12567 for ; Thu, 15 Apr 2004 05:09:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2mX-0004Pu-W0 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 05:03:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F93b7T016974 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 05:03:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2cO-0002Gg-Fb for simple-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 04:53:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12021 for ; Thu, 15 Apr 2004 04:53:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2cL-0003Lw-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 04:53:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2bQ-0003HG-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 04:52:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2at-0003Co-00; Thu, 15 Apr 2004 04:51:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2VY-00008a-4u; Thu, 15 Apr 2004 04:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2TW-0007uc-H6 for simple@optimus.ietf.org; Thu, 15 Apr 2004 04:43:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11575 for ; Thu, 15 Apr 2004 04:43:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2TT-0002ba-00 for simple@ietf.org; Thu, 15 Apr 2004 04:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2SW-0002X6-00 for simple@ietf.org; Thu, 15 Apr 2004 04:42:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BE2Rk-0002TP-00 for simple@ietf.org; Thu, 15 Apr 2004 04:42:08 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8fYH05301; Thu, 15 Apr 2004 11:41:34 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 11:41:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3F8fEF4000499; Thu, 15 Apr 2004 11:41:14 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00G5Tb4H; Thu, 15 Apr 2004 11:40:33 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F8eSF14460; Thu, 15 Apr 2004 11:40:28 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 11:36:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 11:36:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978FD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiPsQQz2/FTcjoRfWkUOdt9VOFxAAhW1BA To: , Cc: X-OriginalArrivalTime: 15 Apr 2004 08:36:18.0878 (UTC) FILETIME=[B92B65E0:01C422C4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 11:36:18 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Paul is right. There is no point in negotiating. The recipient may = either choose a receipt type from the list as offered by the sender, or = it can use the default (if it chooses not to honour the sender's = preferred receipt types). The sender MUST be prepared to receive = receipts in the default format as well as all the formats it offered. Thanks, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Paul Kyzivat > Sent: 14.April.2004 18:27 > To: Chris Boulton > Cc: Simple WG > Subject: Re: [Simple] message-sessions-05 >=20 >=20 > Chris Boulton wrote: > >> > >>OK. If we are agreed on that, then what is the value of negotiating > >>alternative receipt types in the offer/answer? Just indicate your > >>preferred optional type in the message. The recipient will=20 > honor it if > >>it can and wants to, or else it will use the default type.=20 > You have to > >>be prepared to accept the default type anyway, so nothing=20 > is gained by > >>an earlier negotiation. > >=20 > > [Chris Boulton] The idea was that an alternative mechanism=20 > CAN be used > > BUT it MUST be listed as a supported type that appeared in the > > offer/answer exchange - there could be many supported types listed. > > This increases the likelihood that the alternative payload=20 > is supported > > by both clients. This does not override the default BUT=20 > enhances the > > options available on a per message basis and makes it far more > > extensible.=20 >=20 > I don't see how this enhances the options available on a per-message=20 > basis. I can request a particular type even if it hasn't been=20 > negotiated. And whether it has been negotiated or not, I may receive=20 > what I request or not. >=20 > I think maybe we need a concrete use case here. I'm just=20 > making this up=20 > - it seems plausible, though I don't know if it is realistic: >=20 > Lets assume I want to transfer a file over this msrp session.=20 > Maybe for=20 > file transfers there is extra information that is worth=20 > reporting back.=20 > (Whether the file could be stored in the file system, or whatever.) >=20 > So to support this there are a pair of content types: >=20 > application/file (wraps the mimetype of the file) > application/file-transfer-report (the alternative report format) >=20 > Conceivably I might like the UI of my application to only offer file=20 > transfer if I know I will get a file transfer report back. >=20 > Following your proposal, I could negotiate both content types=20 > as part of=20 > the offer/answer, and disable file transfer in my UI if they=20 > aren't both=20 > accepted. But does that let me achieve what I want? No! The following=20 > bad things can happen: >=20 > - I can send the file. The other end, while in some sense supporting > the file-transfer-report format, decides not to use it in reporting > the result. This might happen because it has a generic plugin > mechanism for content types, and there is one installed that > understands the type, but the receiving application doesn't know > how to use that type in this context. So I get the default report. >=20 > - I could start receiving file-transfer-reports as send=20 > message bodies. > But I only know how to deal with them as reports, not as messages. >=20 > The point is that supporting a type isn't an all or nothing=20 > thing. The=20 > type is supported for certain purposes. Exchanging as messages is one=20 > purpose. Exchanging as delivery reports is a different=20 > purpose. If you=20 > want to negotiate this, then the negotiation needs to include=20 > the usage=20 > context. Certainly we could introduce a separate a-line to be=20 > used for=20 > negotiating delivery report types. But I just don't see the value in=20 > doing so. >=20 > Paul >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 15 05:12:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12622 for ; Thu, 15 Apr 2004 05:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2ue-0004fN-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 05:12:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2tg-0004bu-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 05:11:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2tJ-0004Ys-00; Thu, 15 Apr 2004 05:10:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2mv-0004RY-Ca; Thu, 15 Apr 2004 05:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2cH-0002Fg-Io for simple@optimus.ietf.org; Thu, 15 Apr 2004 04:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11984 for ; Thu, 15 Apr 2004 04:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2cE-0003L3-00 for simple@ietf.org; Thu, 15 Apr 2004 04:52:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2bI-0003Fp-00 for simple@ietf.org; Thu, 15 Apr 2004 04:52:01 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly03b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BE2aZ-00038v-00 for simple@ietf.org; Thu, 15 Apr 2004 04:51:15 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly03b.srv.mailcontrol.com (MailControl) with SMTP id i3F8odEF010964; Thu, 15 Apr 2004 09:50:39 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Thu, 15 Apr 2004 09:50:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF347@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiJbbmDaIfX3Q6Tzq35wC/WKaySQAAtp9QACbjgOAAAJl24A== From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 09:50:40 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Yes - I agree. Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 15 April 2004 09:32 >To: Chris Boulton; pkyzivat@cisco.com >Cc: simple@ietf.org >Subject: RE: [Simple] message-sessions-05 > > > >> -----Original Message----- >> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >> ext Chris Boulton >> Sent: 14.April.2004 16:59 >> To: Paul Kyzivat >> Cc: Simple WG >> Subject: RE: [Simple] message-sessions-05 >> >> >> Paul, >> That was the intention the intention from >> >> An MSRP endpoint MUST be capable of performing the DSN >> operations described in this specification and SHOULD >> support the DSN >> MIME type outlined. >> >> Perhaps I could make this more explicit and add text to specify that >> even if an alternative is specified in the receipt request, a client >> SHOULD be able to receive the default receipt type. >> > >I would say a MUST. > >/Hisham This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 15 05:17:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12783 for ; Thu, 15 Apr 2004 05:17:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2yW-0000dQ-P4 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 05:16:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F9G0Ip002436 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 05:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2ui-0007mh-2R for simple-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 05:12:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12635 for ; Thu, 15 Apr 2004 05:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2ue-0004fS-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 05:12:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2tg-0004c1-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 05:11:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE2tJ-0004Ys-00; Thu, 15 Apr 2004 05:10:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2mv-0004RY-Ca; Thu, 15 Apr 2004 05:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2cH-0002Fg-Io for simple@optimus.ietf.org; Thu, 15 Apr 2004 04:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11984 for ; Thu, 15 Apr 2004 04:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2cE-0003L3-00 for simple@ietf.org; Thu, 15 Apr 2004 04:52:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2bI-0003Fp-00 for simple@ietf.org; Thu, 15 Apr 2004 04:52:01 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly03b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BE2aZ-00038v-00 for simple@ietf.org; Thu, 15 Apr 2004 04:51:15 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly03b.srv.mailcontrol.com (MailControl) with SMTP id i3F8odEF010964; Thu, 15 Apr 2004 09:50:39 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Thu, 15 Apr 2004 09:50:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF347@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiJbbmDaIfX3Q6Tzq35wC/WKaySQAAtp9QACbjgOAAAJl24A== From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 09:50:40 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes - I agree. Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 15 April 2004 09:32 >To: Chris Boulton; pkyzivat@cisco.com >Cc: simple@ietf.org >Subject: RE: [Simple] message-sessions-05 > > > >> -----Original Message----- >> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >> ext Chris Boulton >> Sent: 14.April.2004 16:59 >> To: Paul Kyzivat >> Cc: Simple WG >> Subject: RE: [Simple] message-sessions-05 >> >> >> Paul, >> That was the intention the intention from >> >> An MSRP endpoint MUST be capable of performing the DSN >> operations described in this specification and SHOULD >> support the DSN >> MIME type outlined. >> >> Perhaps I could make this more explicit and add text to specify that >> even if an alternative is specified in the receipt request, a client >> SHOULD be able to receive the default receipt type. >> > >I would say a MUST. > >/Hisham This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 15 06:01:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14485 for ; Thu, 15 Apr 2004 06:01:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3gz-0000VO-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 06:01:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3g8-0000Rz-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 06:01:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE3fR-0000OT-00; Thu, 15 Apr 2004 06:00:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3WQ-0002JK-Ng; Thu, 15 Apr 2004 05:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3SW-0001Ky-4C for simple@optimus.ietf.org; Thu, 15 Apr 2004 05:47:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13849 for ; Thu, 15 Apr 2004 05:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3SS-0007HC-00 for simple@ietf.org; Thu, 15 Apr 2004 05:46:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3RV-0007Cd-00 for simple@ietf.org; Thu, 15 Apr 2004 05:45:58 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly04b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BE3QY-00075E-00 for simple@ietf.org; Thu, 15 Apr 2004 05:44:58 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly04b.srv.mailcontrol.com (MailControl) with SMTP id i3F9iNdx028499; Thu, 15 Apr 2004 10:44:24 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Thu, 15 Apr 2004 10:44:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF34A@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiPsQQz2/FTcjoRfWkUOdt9VOFxAAhW1BAAAJupbA= From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 10:44:24 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable OK - I will change the text and remove the references to offer/answer negotiation. Thanks for the input, Regards, Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 15 April 2004 09:36 >To: pkyzivat@cisco.com; Chris Boulton >Cc: simple@ietf.org >Subject: RE: [Simple] message-sessions-05 > >Paul is right. There is no point in negotiating. The recipient may either >choose a receipt type from the list as offered by the sender, or it can use >the default (if it chooses not to honour the sender's preferred receipt >types). The sender MUST be prepared to receive receipts in the default >format as well as all the formats it offered. > >Thanks, >Hisham > >> -----Original Message----- >> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >> ext Paul Kyzivat >> Sent: 14.April.2004 18:27 >> To: Chris Boulton >> Cc: Simple WG >> Subject: Re: [Simple] message-sessions-05 >> >> >> Chris Boulton wrote: >> >> >> >>OK. If we are agreed on that, then what is the value of negotiating >> >>alternative receipt types in the offer/answer? Just indicate your >> >>preferred optional type in the message. The recipient will >> honor it if >> >>it can and wants to, or else it will use the default type. >> You have to >> >>be prepared to accept the default type anyway, so nothing >> is gained by >> >>an earlier negotiation. >> > >> > [Chris Boulton] The idea was that an alternative mechanism >> CAN be used >> > BUT it MUST be listed as a supported type that appeared in the >> > offer/answer exchange - there could be many supported types listed. >> > This increases the likelihood that the alternative payload >> is supported >> > by both clients. This does not override the default BUT >> enhances the >> > options available on a per message basis and makes it far more >> > extensible. >> >> I don't see how this enhances the options available on a per-message >> basis. I can request a particular type even if it hasn't been >> negotiated. And whether it has been negotiated or not, I may receive >> what I request or not. >> >> I think maybe we need a concrete use case here. I'm just >> making this up >> - it seems plausible, though I don't know if it is realistic: >> >> Lets assume I want to transfer a file over this msrp session. >> Maybe for >> file transfers there is extra information that is worth >> reporting back. >> (Whether the file could be stored in the file system, or whatever.) >> >> So to support this there are a pair of content types: >> >> application/file (wraps the mimetype of the file) >> application/file-transfer-report (the alternative report format) >> >> Conceivably I might like the UI of my application to only offer file >> transfer if I know I will get a file transfer report back. >> >> Following your proposal, I could negotiate both content types >> as part of >> the offer/answer, and disable file transfer in my UI if they >> aren't both >> accepted. But does that let me achieve what I want? No! The following >> bad things can happen: >> >> - I can send the file. The other end, while in some sense supporting >> the file-transfer-report format, decides not to use it in reporting >> the result. This might happen because it has a generic plugin >> mechanism for content types, and there is one installed that >> understands the type, but the receiving application doesn't know >> how to use that type in this context. So I get the default report. >> >> - I could start receiving file-transfer-reports as send >> message bodies. >> But I only know how to deal with them as reports, not as messages. >> >> The point is that supporting a type isn't an all or nothing >> thing. The >> type is supported for certain purposes. Exchanging as messages is one >> purpose. Exchanging as delivery reports is a different >> purpose. If you >> want to negotiate this, then the negotiation needs to include >> the usage >> context. Certainly we could introduce a separate a-line to be >> used for >> negotiating delivery report types. But I just don't see the value in >> doing so. >> >> Paul >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 15 06:22:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15294 for ; Thu, 15 Apr 2004 06:22:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3ug-0001ip-6p for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 06:16:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FAG6h4006606 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 06:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3h4-00056i-8h for simple-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 06:02:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14503 for ; Thu, 15 Apr 2004 06:01:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3h0-0000Vb-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 06:01:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3g9-0000S8-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 06:01:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE3fR-0000OT-00; Thu, 15 Apr 2004 06:00:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3WQ-0002JK-Ng; Thu, 15 Apr 2004 05:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3SW-0001Ky-4C for simple@optimus.ietf.org; Thu, 15 Apr 2004 05:47:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13849 for ; Thu, 15 Apr 2004 05:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3SS-0007HC-00 for simple@ietf.org; Thu, 15 Apr 2004 05:46:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3RV-0007Cd-00 for simple@ietf.org; Thu, 15 Apr 2004 05:45:58 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly04b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BE3QY-00075E-00 for simple@ietf.org; Thu, 15 Apr 2004 05:44:58 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly04b.srv.mailcontrol.com (MailControl) with SMTP id i3F9iNdx028499; Thu, 15 Apr 2004 10:44:24 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Thu, 15 Apr 2004 10:44:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-05 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF34A@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] message-sessions-05 Thread-Index: AcQiPsQQz2/FTcjoRfWkUOdt9VOFxAAhW1BAAAJupbA= From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 10:44:24 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable OK - I will change the text and remove the references to offer/answer negotiation. Thanks for the input, Regards, Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 15 April 2004 09:36 >To: pkyzivat@cisco.com; Chris Boulton >Cc: simple@ietf.org >Subject: RE: [Simple] message-sessions-05 > >Paul is right. There is no point in negotiating. The recipient may either >choose a receipt type from the list as offered by the sender, or it can use >the default (if it chooses not to honour the sender's preferred receipt >types). The sender MUST be prepared to receive receipts in the default >format as well as all the formats it offered. > >Thanks, >Hisham > >> -----Original Message----- >> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >> ext Paul Kyzivat >> Sent: 14.April.2004 18:27 >> To: Chris Boulton >> Cc: Simple WG >> Subject: Re: [Simple] message-sessions-05 >> >> >> Chris Boulton wrote: >> >> >> >>OK. If we are agreed on that, then what is the value of negotiating >> >>alternative receipt types in the offer/answer? Just indicate your >> >>preferred optional type in the message. The recipient will >> honor it if >> >>it can and wants to, or else it will use the default type. >> You have to >> >>be prepared to accept the default type anyway, so nothing >> is gained by >> >>an earlier negotiation. >> > >> > [Chris Boulton] The idea was that an alternative mechanism >> CAN be used >> > BUT it MUST be listed as a supported type that appeared in the >> > offer/answer exchange - there could be many supported types listed. >> > This increases the likelihood that the alternative payload >> is supported >> > by both clients. This does not override the default BUT >> enhances the >> > options available on a per message basis and makes it far more >> > extensible. >> >> I don't see how this enhances the options available on a per-message >> basis. I can request a particular type even if it hasn't been >> negotiated. And whether it has been negotiated or not, I may receive >> what I request or not. >> >> I think maybe we need a concrete use case here. I'm just >> making this up >> - it seems plausible, though I don't know if it is realistic: >> >> Lets assume I want to transfer a file over this msrp session. >> Maybe for >> file transfers there is extra information that is worth >> reporting back. >> (Whether the file could be stored in the file system, or whatever.) >> >> So to support this there are a pair of content types: >> >> application/file (wraps the mimetype of the file) >> application/file-transfer-report (the alternative report format) >> >> Conceivably I might like the UI of my application to only offer file >> transfer if I know I will get a file transfer report back. >> >> Following your proposal, I could negotiate both content types >> as part of >> the offer/answer, and disable file transfer in my UI if they >> aren't both >> accepted. But does that let me achieve what I want? No! The following >> bad things can happen: >> >> - I can send the file. The other end, while in some sense supporting >> the file-transfer-report format, decides not to use it in reporting >> the result. This might happen because it has a generic plugin >> mechanism for content types, and there is one installed that >> understands the type, but the receiving application doesn't know >> how to use that type in this context. So I get the default report. >> >> - I could start receiving file-transfer-reports as send >> message bodies. >> But I only know how to deal with them as reports, not as messages. >> >> The point is that supporting a type isn't an all or nothing >> thing. The >> type is supported for certain purposes. Exchanging as messages is one >> purpose. Exchanging as delivery reports is a different >> purpose. If you >> want to negotiate this, then the negotiation needs to include >> the usage >> context. Certainly we could introduce a separate a-line to be >> used for >> negotiating delivery report types. But I just don't see the value in >> doing so. >> >> Paul >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 15 11:54:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01649 for ; Thu, 15 Apr 2004 11:54:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9Br-0000hS-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 11:54:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9Aw-0000dU-00 for simple-archive@ietf.org; Thu, 15 Apr 2004 11:53:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9AF-0000Zt-00; Thu, 15 Apr 2004 11:52:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE94v-0008S1-0V; Thu, 15 Apr 2004 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8rV-0004E0-6k for simple@optimus.ietf.org; Thu, 15 Apr 2004 11:33:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00842 for ; Thu, 15 Apr 2004 11:33:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8rU-0006eI-00 for simple@ietf.org; Thu, 15 Apr 2004 11:33:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8qX-0006Z2-00 for simple@ietf.org; Thu, 15 Apr 2004 11:32:10 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BE8pd-0006P8-00 for simple@ietf.org; Thu, 15 Apr 2004 11:31:14 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3FFV4Ix079643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Apr 2004 10:31:04 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407EAAAB.5050502@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: DSN lifetime open issue Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 10:30:51 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit One open issue concerning MSRP usage of DSN that I would like to close on is, what happens to DSNs after a session is torn down? Example: A R B SEND-------> <---------OK SEND----X <---session teardown---> <-----REPORT In this example, A sends a message to B via relay R. The A-->R hop works fine. The R->B hop failes, due to a tcp error. For the sake of argument, consider this to be a worst case TCP error where the TCP stack has to work through the entire retransmission sequence before it gives up, that is, a non-trivial amount of time passes. A and B tear down the session. But since R is not session stateful, it does not know about this. So, the question becomes, what happens to outstanding DSN after a session is closed? Do they just get dropped? (This is not as simple as it sounds, since if a relay is not aware of the session closure, it will still try to send the DSN, wasting resources.) Or, do we want to be able to deliver DSN outside of the scope of the session in which it was generated? I have had several offline discussions with people, and have gotten opinions that range from allowing DSN to be sent days later, to assuming that all outstanding DSN just get discarded. Thoughts? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 15 12:28:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02797 for ; Thu, 15 Apr 2004 12:28:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9NX-0004xW-9g for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 12:06:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FG6FxI019060 for simple-archive@odin.ietf.org; Thu, 15 Apr 2004 12:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9Bt-0002NL-Hk for simple-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 11:54:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01660 for ; Thu, 15 Apr 2004 11:54:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9Bs-0000hZ-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 11:54:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9Aw-0000dc-00 for simple-web-archive@ietf.org; Thu, 15 Apr 2004 11:53:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9AF-0000Zt-00; Thu, 15 Apr 2004 11:52:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE94v-0008S1-0V; Thu, 15 Apr 2004 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8rV-0004E0-6k for simple@optimus.ietf.org; Thu, 15 Apr 2004 11:33:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00842 for ; Thu, 15 Apr 2004 11:33:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8rU-0006eI-00 for simple@ietf.org; Thu, 15 Apr 2004 11:33:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8qX-0006Z2-00 for simple@ietf.org; Thu, 15 Apr 2004 11:32:10 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BE8pd-0006P8-00 for simple@ietf.org; Thu, 15 Apr 2004 11:31:14 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3FFV4Ix079643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Apr 2004 10:31:04 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407EAAAB.5050502@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: DSN lifetime open issue Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 10:30:51 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One open issue concerning MSRP usage of DSN that I would like to close on is, what happens to DSNs after a session is torn down? Example: A R B SEND-------> <---------OK SEND----X <---session teardown---> <-----REPORT In this example, A sends a message to B via relay R. The A-->R hop works fine. The R->B hop failes, due to a tcp error. For the sake of argument, consider this to be a worst case TCP error where the TCP stack has to work through the entire retransmission sequence before it gives up, that is, a non-trivial amount of time passes. A and B tear down the session. But since R is not session stateful, it does not know about this. So, the question becomes, what happens to outstanding DSN after a session is closed? Do they just get dropped? (This is not as simple as it sounds, since if a relay is not aware of the session closure, it will still try to send the DSN, wasting resources.) Or, do we want to be able to deliver DSN outside of the scope of the session in which it was generated? I have had several offline discussions with people, and have gotten opinions that range from allowing DSN to be sent days later, to assuming that all outstanding DSN just get discarded. Thoughts? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 16 03:38:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19948 for ; Fri, 16 Apr 2004 03:38:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENvS-0005CY-FX for simple-archive@ietf.org; Fri, 16 Apr 2004 03:38:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENuf-00055e-00 for simple-archive@ietf.org; Fri, 16 Apr 2004 03:37:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BENto-0004yc-00; Fri, 16 Apr 2004 03:36:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENlf-0001Jb-Ft; Fri, 16 Apr 2004 03:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENjY-0000mA-Qm for simple@optimus.ietf.org; Fri, 16 Apr 2004 03:25:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19119 for ; Fri, 16 Apr 2004 03:25:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENjW-0003qm-HH for simple@ietf.org; Fri, 16 Apr 2004 03:25:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENic-0003jM-00 for simple@ietf.org; Fri, 16 Apr 2004 03:24:59 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BENhl-0003Zh-00 for simple@ietf.org; Fri, 16 Apr 2004 03:24:05 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3G7O3O04051; Fri, 16 Apr 2004 10:24:03 +0300 (EET DST) X-Scanned: Fri, 16 Apr 2004 10:23:51 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3G7NpRH026395; Fri, 16 Apr 2004 10:23:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00hkcmm7; Fri, 16 Apr 2004 10:23:49 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3G7NnF18934; Fri, 16 Apr 2004 10:23:49 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 16 Apr 2004 10:22:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: DSN lifetime open issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797918@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: DSN lifetime open issue Thread-Index: AcQjAZDagK1dvRLnQn2hUVLdTxbE2wAgEnAw To: , X-OriginalArrivalTime: 16 Apr 2004 07:22:13.0865 (UTC) FILETIME=[8A25FD90:01C42383] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 10:22:13 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This is a session mode instant messaging, therefore I would think that = participants would not care about any DSNs after the session has been = torn down. If they want the DSN, then they need to wait before tearing = down the session. In page mode, you would need to allow the DSN to come days later. But = that is not the issue here. I guess I'm suggesting that all outstanding DSNs are discarded. I don't = think that the penalty that the relay has to try to send the DSN anyway = is such a huge problem. If it is, then we probably need to send a MSRP = level BYE request that traverses relays. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 15.April.2004 18:31 > To: Simple WG > Subject: [Simple] MSRP: DSN lifetime open issue >=20 >=20 > One open issue concerning MSRP usage of DSN that I would like=20 > to close=20 > on is, what happens to DSNs after a session is torn down? >=20 > Example: >=20 > A R B > SEND-------> > <---------OK > SEND----X > <---session teardown---> > <-----REPORT >=20 >=20 > In this example, A sends a message to B via relay R. The=20 > A-->R hop works=20 > fine. The R->B hop failes, due to a tcp error. For the sake=20 > of argument,=20 > consider this to be a worst case TCP error where the TCP stack has to=20 > work through the entire retransmission sequence before it=20 > gives up, that=20 > is, a non-trivial amount of time passes. >=20 > A and B tear down the session. But since R is not session=20 > stateful, it=20 > does not know about this. >=20 > So, the question becomes, what happens to outstanding DSN after a=20 > session is closed? Do they just get dropped? (This is not as=20 > simple as=20 > it sounds, since if a relay is not aware of the session=20 > closure, it will=20 > still try to send the DSN, wasting resources.) >=20 > Or, do we want to be able to deliver DSN outside of the scope of the=20 > session in which it was generated? >=20 > I have had several offline discussions with people, and have gotten=20 > opinions that range from allowing DSN to be sent days later,=20 > to assuming=20 > that all outstanding DSN just get discarded. >=20 > Thoughts? >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 16 03:51:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20738 for ; Fri, 16 Apr 2004 03:51:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEO4e-0006tG-Oa for simple-archive@odin.ietf.org; Fri, 16 Apr 2004 03:47:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G7liuT026482 for simple-archive@odin.ietf.org; Fri, 16 Apr 2004 03:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENvW-0003zu-Qh for simple-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 03:38:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19978 for ; Fri, 16 Apr 2004 03:38:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENvU-0005Cn-BD for simple-web-archive@ietf.org; Fri, 16 Apr 2004 03:38:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENug-00055l-00 for simple-web-archive@ietf.org; Fri, 16 Apr 2004 03:37:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BENto-0004yc-00; Fri, 16 Apr 2004 03:36:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENlf-0001Jb-Ft; Fri, 16 Apr 2004 03:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENjY-0000mA-Qm for simple@optimus.ietf.org; Fri, 16 Apr 2004 03:25:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19119 for ; Fri, 16 Apr 2004 03:25:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENjW-0003qm-HH for simple@ietf.org; Fri, 16 Apr 2004 03:25:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENic-0003jM-00 for simple@ietf.org; Fri, 16 Apr 2004 03:24:59 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BENhl-0003Zh-00 for simple@ietf.org; Fri, 16 Apr 2004 03:24:05 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3G7O3O04051; Fri, 16 Apr 2004 10:24:03 +0300 (EET DST) X-Scanned: Fri, 16 Apr 2004 10:23:51 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3G7NpRH026395; Fri, 16 Apr 2004 10:23:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00hkcmm7; Fri, 16 Apr 2004 10:23:49 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3G7NnF18934; Fri, 16 Apr 2004 10:23:49 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 16 Apr 2004 10:22:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: DSN lifetime open issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797918@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: DSN lifetime open issue Thread-Index: AcQjAZDagK1dvRLnQn2hUVLdTxbE2wAgEnAw To: , X-OriginalArrivalTime: 16 Apr 2004 07:22:13.0865 (UTC) FILETIME=[8A25FD90:01C42383] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 10:22:13 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is a session mode instant messaging, therefore I would think that = participants would not care about any DSNs after the session has been = torn down. If they want the DSN, then they need to wait before tearing = down the session. In page mode, you would need to allow the DSN to come days later. But = that is not the issue here. I guess I'm suggesting that all outstanding DSNs are discarded. I don't = think that the penalty that the relay has to try to send the DSN anyway = is such a huge problem. If it is, then we probably need to send a MSRP = level BYE request that traverses relays. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 15.April.2004 18:31 > To: Simple WG > Subject: [Simple] MSRP: DSN lifetime open issue >=20 >=20 > One open issue concerning MSRP usage of DSN that I would like=20 > to close=20 > on is, what happens to DSNs after a session is torn down? >=20 > Example: >=20 > A R B > SEND-------> > <---------OK > SEND----X > <---session teardown---> > <-----REPORT >=20 >=20 > In this example, A sends a message to B via relay R. The=20 > A-->R hop works=20 > fine. The R->B hop failes, due to a tcp error. For the sake=20 > of argument,=20 > consider this to be a worst case TCP error where the TCP stack has to=20 > work through the entire retransmission sequence before it=20 > gives up, that=20 > is, a non-trivial amount of time passes. >=20 > A and B tear down the session. But since R is not session=20 > stateful, it=20 > does not know about this. >=20 > So, the question becomes, what happens to outstanding DSN after a=20 > session is closed? Do they just get dropped? (This is not as=20 > simple as=20 > it sounds, since if a relay is not aware of the session=20 > closure, it will=20 > still try to send the DSN, wasting resources.) >=20 > Or, do we want to be able to deliver DSN outside of the scope of the=20 > session in which it was generated? >=20 > I have had several offline discussions with people, and have gotten=20 > opinions that range from allowing DSN to be sent days later,=20 > to assuming=20 > that all outstanding DSN just get discarded. >=20 > Thoughts? >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 16 09:34:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07884 for ; Fri, 16 Apr 2004 09:34:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BETTw-0005eM-T4 for simple-archive@ietf.org; Fri, 16 Apr 2004 09:34:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BETT7-0005aA-00 for simple-archive@ietf.org; Fri, 16 Apr 2004 09:33:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BETSF-0005TD-00; Fri, 16 Apr 2004 09:32:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETK5-0003A1-0s; Fri, 16 Apr 2004 09:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETFM-0002GE-Nl for simple@optimus.ietf.org; Fri, 16 Apr 2004 09:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06668 for ; Fri, 16 Apr 2004 09:19:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BETFK-0004P6-QN for simple@ietf.org; Fri, 16 Apr 2004 09:19:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BETEQ-0004Mz-00 for simple@ietf.org; Fri, 16 Apr 2004 09:18:11 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly06b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BETDr-0004KZ-00 for simple@ietf.org; Fri, 16 Apr 2004 09:17:35 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly06b.srv.mailcontrol.com (MailControl) with SMTP id i3GDGsUj022980; Fri, 16 Apr 2004 14:16:54 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Fri, 16 Apr 2004 14:16:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: DSN lifetime open issue Message-ID: <45730E094814E44488F789C1CDED27AE02BDF35A@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: DSN lifetime open issue Thread-Index: AcQjAZDagK1dvRLnQn2hUVLdTxbE2wAgEnAwAAy7cCA= From: "Chris Boulton" To: , , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 14:16:53 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I agree with Hisham - If you want to save resources, some form of MSRP termination will be required ELSE we leave this open to the implementation of the client. Either they can discard or remember for a period of time after session tear down. Chris. =20 >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 16 April 2004 08:22 >To: bcampbell@dynamicsoft.com; simple@ietf.org >Subject: RE: [Simple] MSRP: DSN lifetime open issue > >This is a session mode instant messaging, therefore I would think that >participants would not care about any DSNs after the session has been torn >down. If they want the DSN, then they need to wait before tearing down the >session. > >In page mode, you would need to allow the DSN to come days later. But that >is not the issue here. > >I guess I'm suggesting that all outstanding DSNs are discarded. I don't >think that the penalty that the relay has to try to send the DSN anyway is >such a huge problem. If it is, then we probably need to send a MSRP level >BYE request that traverses relays. > > >/Hisham > >> -----Original Message----- >> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >> ext Ben Campbell >> Sent: 15.April.2004 18:31 >> To: Simple WG >> Subject: [Simple] MSRP: DSN lifetime open issue >> >> >> One open issue concerning MSRP usage of DSN that I would like >> to close >> on is, what happens to DSNs after a session is torn down? >> >> Example: >> >> A R B >> SEND-------> >> <---------OK >> SEND----X >> <---session teardown---> >> <-----REPORT >> >> >> In this example, A sends a message to B via relay R. The >> A-->R hop works >> fine. The R->B hop failes, due to a tcp error. For the sake >> of argument, >> consider this to be a worst case TCP error where the TCP stack has to >> work through the entire retransmission sequence before it >> gives up, that >> is, a non-trivial amount of time passes. >> >> A and B tear down the session. But since R is not session >> stateful, it >> does not know about this. >> >> So, the question becomes, what happens to outstanding DSN after a >> session is closed? Do they just get dropped? (This is not as >> simple as >> it sounds, since if a relay is not aware of the session >> closure, it will >> still try to send the DSN, wasting resources.) >> >> Or, do we want to be able to deliver DSN outside of the scope of the >> session in which it was generated? >> >> I have had several offline discussions with people, and have gotten >> opinions that range from allowing DSN to be sent days later, >> to assuming >> that all outstanding DSN just get discarded. >> >> Thoughts? >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 16 09:39:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08197 for ; Fri, 16 Apr 2004 09:39:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETVD-0005Tc-8T for simple-archive@odin.ietf.org; Fri, 16 Apr 2004 09:35:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GDZVtU021049 for simple-archive@odin.ietf.org; Fri, 16 Apr 2004 09:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETTz-00050k-B0 for simple-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 09:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07902 for ; Fri, 16 Apr 2004 09:34:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BETTx-0005eR-J7 for simple-web-archive@ietf.org; Fri, 16 Apr 2004 09:34:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BETT8-0005aH-00 for simple-web-archive@ietf.org; Fri, 16 Apr 2004 09:33:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BETSF-0005TD-00; Fri, 16 Apr 2004 09:32:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETK5-0003A1-0s; Fri, 16 Apr 2004 09:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETFM-0002GE-Nl for simple@optimus.ietf.org; Fri, 16 Apr 2004 09:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06668 for ; Fri, 16 Apr 2004 09:19:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BETFK-0004P6-QN for simple@ietf.org; Fri, 16 Apr 2004 09:19:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BETEQ-0004Mz-00 for simple@ietf.org; Fri, 16 Apr 2004 09:18:11 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly06b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BETDr-0004KZ-00 for simple@ietf.org; Fri, 16 Apr 2004 09:17:35 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly06b.srv.mailcontrol.com (MailControl) with SMTP id i3GDGsUj022980; Fri, 16 Apr 2004 14:16:54 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Fri, 16 Apr 2004 14:16:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: DSN lifetime open issue Message-ID: <45730E094814E44488F789C1CDED27AE02BDF35A@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: DSN lifetime open issue Thread-Index: AcQjAZDagK1dvRLnQn2hUVLdTxbE2wAgEnAwAAy7cCA= From: "Chris Boulton" To: , , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 14:16:53 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Hisham - If you want to save resources, some form of MSRP termination will be required ELSE we leave this open to the implementation of the client. Either they can discard or remember for a period of time after session tear down. Chris. =20 >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 16 April 2004 08:22 >To: bcampbell@dynamicsoft.com; simple@ietf.org >Subject: RE: [Simple] MSRP: DSN lifetime open issue > >This is a session mode instant messaging, therefore I would think that >participants would not care about any DSNs after the session has been torn >down. If they want the DSN, then they need to wait before tearing down the >session. > >In page mode, you would need to allow the DSN to come days later. But that >is not the issue here. > >I guess I'm suggesting that all outstanding DSNs are discarded. I don't >think that the penalty that the relay has to try to send the DSN anyway is >such a huge problem. If it is, then we probably need to send a MSRP level >BYE request that traverses relays. > > >/Hisham > >> -----Original Message----- >> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >> ext Ben Campbell >> Sent: 15.April.2004 18:31 >> To: Simple WG >> Subject: [Simple] MSRP: DSN lifetime open issue >> >> >> One open issue concerning MSRP usage of DSN that I would like >> to close >> on is, what happens to DSNs after a session is torn down? >> >> Example: >> >> A R B >> SEND-------> >> <---------OK >> SEND----X >> <---session teardown---> >> <-----REPORT >> >> >> In this example, A sends a message to B via relay R. The >> A-->R hop works >> fine. The R->B hop failes, due to a tcp error. For the sake >> of argument, >> consider this to be a worst case TCP error where the TCP stack has to >> work through the entire retransmission sequence before it >> gives up, that >> is, a non-trivial amount of time passes. >> >> A and B tear down the session. But since R is not session >> stateful, it >> does not know about this. >> >> So, the question becomes, what happens to outstanding DSN after a >> session is closed? Do they just get dropped? (This is not as >> simple as >> it sounds, since if a relay is not aware of the session >> closure, it will >> still try to send the DSN, wasting resources.) >> >> Or, do we want to be able to deliver DSN outside of the scope of the >> session in which it was generated? >> >> I have had several offline discussions with people, and have gotten >> opinions that range from allowing DSN to be sent days later, >> to assuming >> that all outstanding DSN just get discarded. >> >> Thoughts? >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 16 11:16:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15327 for ; Fri, 16 Apr 2004 11:16:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEV4j-0004GT-RP for simple-archive@ietf.org; Fri, 16 Apr 2004 11:16:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEV4U-0004DY-00 for simple-archive@ietf.org; Fri, 16 Apr 2004 11:16:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEV3C-00049Y-00; Fri, 16 Apr 2004 11:14:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUxl-0003Nn-GD; Fri, 16 Apr 2004 11:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUrK-0007YE-Rx for simple@optimus.ietf.org; Fri, 16 Apr 2004 11:02:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14540 for ; Fri, 16 Apr 2004 11:02:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEUrI-0003Px-9T for simple@ietf.org; Fri, 16 Apr 2004 11:02:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUqV-0003Lq-00 for simple@ietf.org; Fri, 16 Apr 2004 11:01:36 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BEUpa-0003Ga-00 for simple@ietf.org; Fri, 16 Apr 2004 11:00:39 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3GF0SIx088385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Apr 2004 10:00:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407FF4FE.8030501@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: <45730E094814E44488F789C1CDED27AE02BDF35A@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF35A@gbnewp0758m.eu.ubiquity.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 10:00:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit One further complication on the "remember for a period of time approach" is the fact that the client may close its TCP connection. I expect relays will generally not be able to re-open the connections back towards the client. (The main point of relays is NAT/FW traversal.) Chris Boulton wrote: > I agree with Hisham - If you want to save resources, some form of MSRP > termination will be required ELSE we leave this open to the > implementation of the client. Either they can discard or remember for a > period of time after session tear down. > > Chris. > > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: 16 April 2004 08:22 >>To: bcampbell@dynamicsoft.com; simple@ietf.org >>Subject: RE: [Simple] MSRP: DSN lifetime open issue >> >>This is a session mode instant messaging, therefore I would think that >>participants would not care about any DSNs after the session has been > > torn > >>down. If they want the DSN, then they need to wait before tearing down > > the > >>session. >> >>In page mode, you would need to allow the DSN to come days later. But > > that > >>is not the issue here. >> >>I guess I'm suggesting that all outstanding DSNs are discarded. I don't >>think that the penalty that the relay has to try to send the DSN anyway > > is > >>such a huge problem. If it is, then we probably need to send a MSRP > > level > >>BYE request that traverses relays. >> >> >>/Hisham >> >> >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf > > Of > >>>ext Ben Campbell >>>Sent: 15.April.2004 18:31 >>>To: Simple WG >>>Subject: [Simple] MSRP: DSN lifetime open issue >>> >>> >>>One open issue concerning MSRP usage of DSN that I would like >>>to close >>>on is, what happens to DSNs after a session is torn down? >>> >>>Example: >>> >>>A R B >>>SEND-------> >>><---------OK >>> SEND----X >>><---session teardown---> >>><-----REPORT >>> >>> >>>In this example, A sends a message to B via relay R. The >>>A-->R hop works >>>fine. The R->B hop failes, due to a tcp error. For the sake >>>of argument, >>>consider this to be a worst case TCP error where the TCP stack has to >>>work through the entire retransmission sequence before it >>>gives up, that >>>is, a non-trivial amount of time passes. >>> >>>A and B tear down the session. But since R is not session >>>stateful, it >>>does not know about this. >>> >>>So, the question becomes, what happens to outstanding DSN after a >>>session is closed? Do they just get dropped? (This is not as >>>simple as >>>it sounds, since if a relay is not aware of the session >>>closure, it will >>>still try to send the DSN, wasting resources.) >>> >>>Or, do we want to be able to deliver DSN outside of the scope of the >>>session in which it was generated? >>> >>>I have had several offline discussions with people, and have gotten >>>opinions that range from allowing DSN to be sent days later, >>>to assuming >>>that all outstanding DSN just get discarded. >>> >>>Thoughts? >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 16 11:28:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16164 for ; Fri, 16 Apr 2004 11:28:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVA1-0006k2-2Q for simple-archive@odin.ietf.org; Fri, 16 Apr 2004 11:21:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GFLja4025906 for simple-archive@odin.ietf.org; Fri, 16 Apr 2004 11:21:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEV4l-0005RQ-I0 for simple-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 11:16:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15343 for ; Fri, 16 Apr 2004 11:16:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEV4k-0004GY-Hl for simple-web-archive@ietf.org; Fri, 16 Apr 2004 11:16:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEV4V-0004Dg-00 for simple-web-archive@ietf.org; Fri, 16 Apr 2004 11:16:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEV3C-00049Y-00; Fri, 16 Apr 2004 11:14:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUxl-0003Nn-GD; Fri, 16 Apr 2004 11:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUrK-0007YE-Rx for simple@optimus.ietf.org; Fri, 16 Apr 2004 11:02:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14540 for ; Fri, 16 Apr 2004 11:02:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEUrI-0003Px-9T for simple@ietf.org; Fri, 16 Apr 2004 11:02:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUqV-0003Lq-00 for simple@ietf.org; Fri, 16 Apr 2004 11:01:36 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BEUpa-0003Ga-00 for simple@ietf.org; Fri, 16 Apr 2004 11:00:39 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3GF0SIx088385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Apr 2004 10:00:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <407FF4FE.8030501@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: <45730E094814E44488F789C1CDED27AE02BDF35A@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF35A@gbnewp0758m.eu.ubiquity.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 10:00:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One further complication on the "remember for a period of time approach" is the fact that the client may close its TCP connection. I expect relays will generally not be able to re-open the connections back towards the client. (The main point of relays is NAT/FW traversal.) Chris Boulton wrote: > I agree with Hisham - If you want to save resources, some form of MSRP > termination will be required ELSE we leave this open to the > implementation of the client. Either they can discard or remember for a > period of time after session tear down. > > Chris. > > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: 16 April 2004 08:22 >>To: bcampbell@dynamicsoft.com; simple@ietf.org >>Subject: RE: [Simple] MSRP: DSN lifetime open issue >> >>This is a session mode instant messaging, therefore I would think that >>participants would not care about any DSNs after the session has been > > torn > >>down. If they want the DSN, then they need to wait before tearing down > > the > >>session. >> >>In page mode, you would need to allow the DSN to come days later. But > > that > >>is not the issue here. >> >>I guess I'm suggesting that all outstanding DSNs are discarded. I don't >>think that the penalty that the relay has to try to send the DSN anyway > > is > >>such a huge problem. If it is, then we probably need to send a MSRP > > level > >>BYE request that traverses relays. >> >> >>/Hisham >> >> >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf > > Of > >>>ext Ben Campbell >>>Sent: 15.April.2004 18:31 >>>To: Simple WG >>>Subject: [Simple] MSRP: DSN lifetime open issue >>> >>> >>>One open issue concerning MSRP usage of DSN that I would like >>>to close >>>on is, what happens to DSNs after a session is torn down? >>> >>>Example: >>> >>>A R B >>>SEND-------> >>><---------OK >>> SEND----X >>><---session teardown---> >>><-----REPORT >>> >>> >>>In this example, A sends a message to B via relay R. The >>>A-->R hop works >>>fine. The R->B hop failes, due to a tcp error. For the sake >>>of argument, >>>consider this to be a worst case TCP error where the TCP stack has to >>>work through the entire retransmission sequence before it >>>gives up, that >>>is, a non-trivial amount of time passes. >>> >>>A and B tear down the session. But since R is not session >>>stateful, it >>>does not know about this. >>> >>>So, the question becomes, what happens to outstanding DSN after a >>>session is closed? Do they just get dropped? (This is not as >>>simple as >>>it sounds, since if a relay is not aware of the session >>>closure, it will >>>still try to send the DSN, wasting resources.) >>> >>>Or, do we want to be able to deliver DSN outside of the scope of the >>>session in which it was generated? >>> >>>I have had several offline discussions with people, and have gotten >>>opinions that range from allowing DSN to be sent days later, >>>to assuming >>>that all outstanding DSN just get discarded. >>> >>>Thoughts? >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 19 09:26:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09935 for ; Mon, 19 Apr 2004 09:26:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYmf-0005bw-Fd for simple-archive@ietf.org; Mon, 19 Apr 2004 09:26:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYlr-0005P1-00 for simple-archive@ietf.org; Mon, 19 Apr 2004 09:25:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFYks-0005BZ-00; Mon, 19 Apr 2004 09:24:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYgs-0003CJ-Du; Mon, 19 Apr 2004 09:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYc4-0002Bd-Sg for simple@optimus.ietf.org; Mon, 19 Apr 2004 09:15:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09563 for ; Mon, 19 Apr 2004 09:15:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYc2-0003CP-0t for simple@ietf.org; Mon, 19 Apr 2004 09:15:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYb8-0002zD-00 for simple@ietf.org; Mon, 19 Apr 2004 09:14:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BFYaO-0002Xc-00 for simple@ietf.org; Mon, 19 Apr 2004 09:13:20 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Apr 2004 05:24:09 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3JDCk8k016597; Mon, 19 Apr 2004 06:12:47 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHR66943; Mon, 19 Apr 2004 09:12:45 -0400 (EDT) Message-ID: <4083D055.9040209@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Chris Boulton , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: <45730E094814E44488F789C1CDED27AE02BDF35A@gbnewp0758m.eu.ubiquity.net> <407FF4FE.8030501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 09:12:53 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I think I agree that DSNs are only needed for the duration of the session, given a suitable definition of the session. But I don't think the session can be equated with the TCP connection. That connection may indeed need to be reestablished after some kind of glitch, such as one server falling over and being replaced by a redundant backup. I think the duration of the session has to be tied to signaling - the offer/answer exchange. But that makes life difficult for the relays, that aren't parties in that exchange. But before considering relays, lets consider a simpler case and see what issues there are: Assume we have established a dialog and MSRP session between A & B. Then, perhaps as a result of a 3pcc transfer, A receives a reinvite that retargets the MSRP media stream to C. As a result, the old TCP connection between A&B will be dropped and a new one between A&C will be established. The signaling that accomplishes this won't necessarily be synchronized with the media. For instance, an MSRP SEND message from A to B (requiring a DSN) may overlap with the sending of an offer from B to A to move the stream to C. We need rules for managing the transition that ensure that the DSN from B to A is delivered while the connection is still up and being processed by A. Paul Ben Campbell wrote: > One further complication on the "remember for a period of time approach" > is the fact that the client may close its TCP connection. I expect > relays will generally not be able to re-open the connections back > towards the client. (The main point of relays is NAT/FW traversal.) > > Chris Boulton wrote: > >> I agree with Hisham - If you want to save resources, some form of MSRP >> termination will be required ELSE we leave this open to the >> implementation of the client. Either they can discard or remember for a >> period of time after session tear down. >> >> Chris. >> >> >> >>> -----Original Message----- >>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>> Sent: 16 April 2004 08:22 >>> To: bcampbell@dynamicsoft.com; simple@ietf.org >>> Subject: RE: [Simple] MSRP: DSN lifetime open issue >>> >>> This is a session mode instant messaging, therefore I would think that >>> participants would not care about any DSNs after the session has been >> >> >> torn >> >>> down. If they want the DSN, then they need to wait before tearing down >> >> >> the >> >>> session. >>> >>> In page mode, you would need to allow the DSN to come days later. But >> >> >> that >> >>> is not the issue here. >>> >>> I guess I'm suggesting that all outstanding DSNs are discarded. I don't >>> think that the penalty that the relay has to try to send the DSN anyway >> >> >> is >> >>> such a huge problem. If it is, then we probably need to send a MSRP >> >> >> level >> >>> BYE request that traverses relays. >>> >>> >>> /Hisham >>> >>> >>>> -----Original Message----- >>>> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf >>> >> >> Of >> >>>> ext Ben Campbell >>>> Sent: 15.April.2004 18:31 >>>> To: Simple WG >>>> Subject: [Simple] MSRP: DSN lifetime open issue >>>> >>>> >>>> One open issue concerning MSRP usage of DSN that I would like >>>> to close >>>> on is, what happens to DSNs after a session is torn down? >>>> >>>> Example: >>>> >>>> A R B >>>> SEND-------> >>>> <---------OK >>>> SEND----X >>>> <---session teardown---> >>>> <-----REPORT >>>> >>>> >>>> In this example, A sends a message to B via relay R. The >>>> A-->R hop works >>>> fine. The R->B hop failes, due to a tcp error. For the sake >>>> of argument, >>>> consider this to be a worst case TCP error where the TCP stack has to >>>> work through the entire retransmission sequence before it >>>> gives up, that >>>> is, a non-trivial amount of time passes. >>>> >>>> A and B tear down the session. But since R is not session >>>> stateful, it >>>> does not know about this. >>>> >>>> So, the question becomes, what happens to outstanding DSN after a >>>> session is closed? Do they just get dropped? (This is not as >>>> simple as >>>> it sounds, since if a relay is not aware of the session >>>> closure, it will >>>> still try to send the DSN, wasting resources.) >>>> >>>> Or, do we want to be able to deliver DSN outside of the scope of the >>>> session in which it was generated? >>>> >>>> I have had several offline discussions with people, and have gotten >>>> opinions that range from allowing DSN to be sent days later, >>>> to assuming >>>> that all outstanding DSN just get discarded. >>>> >>>> Thoughts? >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> >> This message has been scanned for viruses by MailControl - >> www.mailcontrol.com > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 19 09:30:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10155 for ; Mon, 19 Apr 2004 09:30:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYoh-00058m-Sv for simple-archive@odin.ietf.org; Mon, 19 Apr 2004 09:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JDS7CM019756 for simple-archive@odin.ietf.org; Mon, 19 Apr 2004 09:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYmi-0004ha-OW for simple-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 09:26:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09957 for ; Mon, 19 Apr 2004 09:26:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYmh-0005c4-19 for simple-web-archive@ietf.org; Mon, 19 Apr 2004 09:26:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYls-0005PA-00 for simple-web-archive@ietf.org; Mon, 19 Apr 2004 09:25:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFYks-0005BZ-00; Mon, 19 Apr 2004 09:24:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYgs-0003CJ-Du; Mon, 19 Apr 2004 09:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYc4-0002Bd-Sg for simple@optimus.ietf.org; Mon, 19 Apr 2004 09:15:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09563 for ; Mon, 19 Apr 2004 09:15:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYc2-0003CP-0t for simple@ietf.org; Mon, 19 Apr 2004 09:15:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYb8-0002zD-00 for simple@ietf.org; Mon, 19 Apr 2004 09:14:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BFYaO-0002Xc-00 for simple@ietf.org; Mon, 19 Apr 2004 09:13:20 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Apr 2004 05:24:09 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3JDCk8k016597; Mon, 19 Apr 2004 06:12:47 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHR66943; Mon, 19 Apr 2004 09:12:45 -0400 (EDT) Message-ID: <4083D055.9040209@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Chris Boulton , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: <45730E094814E44488F789C1CDED27AE02BDF35A@gbnewp0758m.eu.ubiquity.net> <407FF4FE.8030501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 09:12:53 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think I agree that DSNs are only needed for the duration of the session, given a suitable definition of the session. But I don't think the session can be equated with the TCP connection. That connection may indeed need to be reestablished after some kind of glitch, such as one server falling over and being replaced by a redundant backup. I think the duration of the session has to be tied to signaling - the offer/answer exchange. But that makes life difficult for the relays, that aren't parties in that exchange. But before considering relays, lets consider a simpler case and see what issues there are: Assume we have established a dialog and MSRP session between A & B. Then, perhaps as a result of a 3pcc transfer, A receives a reinvite that retargets the MSRP media stream to C. As a result, the old TCP connection between A&B will be dropped and a new one between A&C will be established. The signaling that accomplishes this won't necessarily be synchronized with the media. For instance, an MSRP SEND message from A to B (requiring a DSN) may overlap with the sending of an offer from B to A to move the stream to C. We need rules for managing the transition that ensure that the DSN from B to A is delivered while the connection is still up and being processed by A. Paul Ben Campbell wrote: > One further complication on the "remember for a period of time approach" > is the fact that the client may close its TCP connection. I expect > relays will generally not be able to re-open the connections back > towards the client. (The main point of relays is NAT/FW traversal.) > > Chris Boulton wrote: > >> I agree with Hisham - If you want to save resources, some form of MSRP >> termination will be required ELSE we leave this open to the >> implementation of the client. Either they can discard or remember for a >> period of time after session tear down. >> >> Chris. >> >> >> >>> -----Original Message----- >>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>> Sent: 16 April 2004 08:22 >>> To: bcampbell@dynamicsoft.com; simple@ietf.org >>> Subject: RE: [Simple] MSRP: DSN lifetime open issue >>> >>> This is a session mode instant messaging, therefore I would think that >>> participants would not care about any DSNs after the session has been >> >> >> torn >> >>> down. If they want the DSN, then they need to wait before tearing down >> >> >> the >> >>> session. >>> >>> In page mode, you would need to allow the DSN to come days later. But >> >> >> that >> >>> is not the issue here. >>> >>> I guess I'm suggesting that all outstanding DSNs are discarded. I don't >>> think that the penalty that the relay has to try to send the DSN anyway >> >> >> is >> >>> such a huge problem. If it is, then we probably need to send a MSRP >> >> >> level >> >>> BYE request that traverses relays. >>> >>> >>> /Hisham >>> >>> >>>> -----Original Message----- >>>> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf >>> >> >> Of >> >>>> ext Ben Campbell >>>> Sent: 15.April.2004 18:31 >>>> To: Simple WG >>>> Subject: [Simple] MSRP: DSN lifetime open issue >>>> >>>> >>>> One open issue concerning MSRP usage of DSN that I would like >>>> to close >>>> on is, what happens to DSNs after a session is torn down? >>>> >>>> Example: >>>> >>>> A R B >>>> SEND-------> >>>> <---------OK >>>> SEND----X >>>> <---session teardown---> >>>> <-----REPORT >>>> >>>> >>>> In this example, A sends a message to B via relay R. The >>>> A-->R hop works >>>> fine. The R->B hop failes, due to a tcp error. For the sake >>>> of argument, >>>> consider this to be a worst case TCP error where the TCP stack has to >>>> work through the entire retransmission sequence before it >>>> gives up, that >>>> is, a non-trivial amount of time passes. >>>> >>>> A and B tear down the session. But since R is not session >>>> stateful, it >>>> does not know about this. >>>> >>>> So, the question becomes, what happens to outstanding DSN after a >>>> session is closed? Do they just get dropped? (This is not as >>>> simple as >>>> it sounds, since if a relay is not aware of the session >>>> closure, it will >>>> still try to send the DSN, wasting resources.) >>>> >>>> Or, do we want to be able to deliver DSN outside of the scope of the >>>> session in which it was generated? >>>> >>>> I have had several offline discussions with people, and have gotten >>>> opinions that range from allowing DSN to be sent days later, >>>> to assuming >>>> that all outstanding DSN just get discarded. >>>> >>>> Thoughts? >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> >> This message has been scanned for viruses by MailControl - >> www.mailcontrol.com > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 19 10:05:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11951 for ; Mon, 19 Apr 2004 10:05:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZOU-0006qX-DX for simple-archive@ietf.org; Mon, 19 Apr 2004 10:05:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZNR-0006bL-00 for simple-archive@ietf.org; Mon, 19 Apr 2004 10:04:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFZMV-0006Lu-00; Mon, 19 Apr 2004 10:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZGf-0002mc-OS; Mon, 19 Apr 2004 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZCs-0001e0-Fn for simple@optimus.ietf.org; Mon, 19 Apr 2004 09:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11105 for ; Mon, 19 Apr 2004 09:53:03 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZCq-0003wh-EW for simple@ietf.org; Mon, 19 Apr 2004 09:53:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZBv-0003j9-00 for simple@ietf.org; Mon, 19 Apr 2004 09:52:08 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BFZBQ-0003Vy-00 for simple@ietf.org; Mon, 19 Apr 2004 09:51:36 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JDonm07948; Mon, 19 Apr 2004 16:50:49 +0300 (EET DST) X-Scanned: Mon, 19 Apr 2004 16:50:41 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3JDofnx010900; Mon, 19 Apr 2004 16:50:41 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00SU5Q3z; Mon, 19 Apr 2004 16:50:39 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JDoaF00592; Mon, 19 Apr 2004 16:50:36 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Apr 2004 16:50:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: DSN lifetime open issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179793A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: DSN lifetime open issue Thread-Index: AcQmEHk6BkdLquo/SdGAi3Wm2Z8JKQAAh7kw To: , Cc: , X-OriginalArrivalTime: 19 Apr 2004 13:50:25.0379 (UTC) FILETIME=[44363B30:01C42615] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 16:50:24 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable There are 2 cases here: 1. The SEND arrives at B before the transfer is complete and the TCP = connection is dropped 2. The SEND does not arrive at B before the transfer is complete and the = TCP connection is dropped. 2 is easier to solve, A would probably get a negative DSN or no response = at all (if no relays) 1 might be solved by mandating that B must not drop the connection = unless it has sent all pending DSNs. /Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 19.April.2004 16:13 > To: Ben Campbell > Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > simple@ietf.org > Subject: Re: [Simple] MSRP: DSN lifetime open issue >=20 >=20 > I think I agree that DSNs are only needed for the duration of the=20 > session, given a suitable definition of the session. But I=20 > don't think=20 > the session can be equated with the TCP connection. That=20 > connection may=20 > indeed need to be reestablished after some kind of glitch,=20 > such as one=20 > server falling over and being replaced by a redundant backup. >=20 > I think the duration of the session has to be tied to signaling - the=20 > offer/answer exchange. But that makes life difficult for the relays,=20 > that aren't parties in that exchange. >=20 > But before considering relays, lets consider a simpler case=20 > and see what=20 > issues there are: >=20 > Assume we have established a dialog and MSRP session between A & B.=20 > Then, perhaps as a result of a 3pcc transfer, A receives a=20 > reinvite that=20 > retargets the MSRP media stream to C. As a result, the old TCP=20 > connection between A&B will be dropped and a new one between=20 > A&C will be=20 > established. >=20 > The signaling that accomplishes this won't necessarily be=20 > synchronized=20 > with the media. For instance, an MSRP SEND message from A to B=20 > (requiring a DSN) may overlap with the sending of an offer=20 > from B to A=20 > to move the stream to C. >=20 > We need rules for managing the transition that ensure that=20 > the DSN from=20 > B to A is delivered while the connection is still up and=20 > being processed=20 > by A. >=20 > Paul >=20 > Ben Campbell wrote: > > One further complication on the "remember for a period of=20 > time approach"=20 > > is the fact that the client may close its TCP connection. I expect=20 > > relays will generally not be able to re-open the connections back=20 > > towards the client. (The main point of relays is NAT/FW traversal.) > >=20 > > Chris Boulton wrote: > >=20 > >> I agree with Hisham - If you want to save resources, some=20 > form of MSRP > >> termination will be required ELSE we leave this open to the > >> implementation of the client. Either they can discard or=20 > remember for a > >> period of time after session tear down. > >> > >> Chris. > >> =20 > >> > >> > >>> -----Original Message----- > >>> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > >>> Sent: 16 April 2004 08:22 > >>> To: bcampbell@dynamicsoft.com; simple@ietf.org > >>> Subject: RE: [Simple] MSRP: DSN lifetime open issue > >>> > >>> This is a session mode instant messaging, therefore I=20 > would think that > >>> participants would not care about any DSNs after the=20 > session has been > >> > >> > >> torn > >> > >>> down. If they want the DSN, then they need to wait before=20 > tearing down > >> > >> > >> the > >> > >>> session. > >>> > >>> In page mode, you would need to allow the DSN to come=20 > days later. But > >> > >> > >> that > >> > >>> is not the issue here. > >>> > >>> I guess I'm suggesting that all outstanding DSNs are=20 > discarded. I don't > >>> think that the penalty that the relay has to try to send=20 > the DSN anyway > >> > >> > >> is > >> > >>> such a huge problem. If it is, then we probably need to=20 > send a MSRP > >> > >> > >> level > >> > >>> BYE request that traverses relays. > >>> > >>> > >>> /Hisham > >>> > >>> > >>>> -----Original Message----- > >>>> From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf > >>> > >> > >> Of > >> > >>>> ext Ben Campbell > >>>> Sent: 15.April.2004 18:31 > >>>> To: Simple WG > >>>> Subject: [Simple] MSRP: DSN lifetime open issue > >>>> > >>>> > >>>> One open issue concerning MSRP usage of DSN that I would like > >>>> to close > >>>> on is, what happens to DSNs after a session is torn down? > >>>> > >>>> Example: > >>>> > >>>> A R B > >>>> SEND-------> > >>>> <---------OK > >>>> SEND----X > >>>> <---session teardown---> > >>>> <-----REPORT > >>>> > >>>> > >>>> In this example, A sends a message to B via relay R. The > >>>> A-->R hop works > >>>> fine. The R->B hop failes, due to a tcp error. For the sake > >>>> of argument, > >>>> consider this to be a worst case TCP error where the TCP=20 > stack has to > >>>> work through the entire retransmission sequence before it > >>>> gives up, that > >>>> is, a non-trivial amount of time passes. > >>>> > >>>> A and B tear down the session. But since R is not session > >>>> stateful, it > >>>> does not know about this. > >>>> > >>>> So, the question becomes, what happens to outstanding DSN after a > >>>> session is closed? Do they just get dropped? (This is not as > >>>> simple as > >>>> it sounds, since if a relay is not aware of the session > >>>> closure, it will > >>>> still try to send the DSN, wasting resources.) > >>>> > >>>> Or, do we want to be able to deliver DSN outside of the=20 > scope of the > >>>> session in which it was generated? > >>>> > >>>> I have had several offline discussions with people, and=20 > have gotten > >>>> opinions that range from allowing DSN to be sent days later, > >>>> to assuming > >>>> that all outstanding DSN just get discarded. > >>>> > >>>> Thoughts? > >>>> > >>>> _______________________________________________ > >>>> Simple mailing list > >>>> Simple@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/simple > >>>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >> > >> > >> > >> > >> This message has been scanned for viruses by MailControl -=20 > >> www.mailcontrol.com > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 19 10:12:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12812 for ; Mon, 19 Apr 2004 10:12:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZTN-0000rP-Vb for simple-archive@odin.ietf.org; Mon, 19 Apr 2004 10:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JEA9at003302 for simple-archive@odin.ietf.org; Mon, 19 Apr 2004 10:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZOX-00072W-70 for simple-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 10:05:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11970 for ; Mon, 19 Apr 2004 10:05:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZOV-0006qe-1c for simple-web-archive@ietf.org; Mon, 19 Apr 2004 10:05:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZNS-0006bS-00 for simple-web-archive@ietf.org; Mon, 19 Apr 2004 10:04:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFZMV-0006Lu-00; Mon, 19 Apr 2004 10:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZGf-0002mc-OS; Mon, 19 Apr 2004 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZCs-0001e0-Fn for simple@optimus.ietf.org; Mon, 19 Apr 2004 09:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11105 for ; Mon, 19 Apr 2004 09:53:03 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZCq-0003wh-EW for simple@ietf.org; Mon, 19 Apr 2004 09:53:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZBv-0003j9-00 for simple@ietf.org; Mon, 19 Apr 2004 09:52:08 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BFZBQ-0003Vy-00 for simple@ietf.org; Mon, 19 Apr 2004 09:51:36 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JDonm07948; Mon, 19 Apr 2004 16:50:49 +0300 (EET DST) X-Scanned: Mon, 19 Apr 2004 16:50:41 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3JDofnx010900; Mon, 19 Apr 2004 16:50:41 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00SU5Q3z; Mon, 19 Apr 2004 16:50:39 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JDoaF00592; Mon, 19 Apr 2004 16:50:36 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Apr 2004 16:50:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: DSN lifetime open issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179793A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: DSN lifetime open issue Thread-Index: AcQmEHk6BkdLquo/SdGAi3Wm2Z8JKQAAh7kw To: , Cc: , X-OriginalArrivalTime: 19 Apr 2004 13:50:25.0379 (UTC) FILETIME=[44363B30:01C42615] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 16:50:24 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable There are 2 cases here: 1. The SEND arrives at B before the transfer is complete and the TCP = connection is dropped 2. The SEND does not arrive at B before the transfer is complete and the = TCP connection is dropped. 2 is easier to solve, A would probably get a negative DSN or no response = at all (if no relays) 1 might be solved by mandating that B must not drop the connection = unless it has sent all pending DSNs. /Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 19.April.2004 16:13 > To: Ben Campbell > Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > simple@ietf.org > Subject: Re: [Simple] MSRP: DSN lifetime open issue >=20 >=20 > I think I agree that DSNs are only needed for the duration of the=20 > session, given a suitable definition of the session. But I=20 > don't think=20 > the session can be equated with the TCP connection. That=20 > connection may=20 > indeed need to be reestablished after some kind of glitch,=20 > such as one=20 > server falling over and being replaced by a redundant backup. >=20 > I think the duration of the session has to be tied to signaling - the=20 > offer/answer exchange. But that makes life difficult for the relays,=20 > that aren't parties in that exchange. >=20 > But before considering relays, lets consider a simpler case=20 > and see what=20 > issues there are: >=20 > Assume we have established a dialog and MSRP session between A & B.=20 > Then, perhaps as a result of a 3pcc transfer, A receives a=20 > reinvite that=20 > retargets the MSRP media stream to C. As a result, the old TCP=20 > connection between A&B will be dropped and a new one between=20 > A&C will be=20 > established. >=20 > The signaling that accomplishes this won't necessarily be=20 > synchronized=20 > with the media. For instance, an MSRP SEND message from A to B=20 > (requiring a DSN) may overlap with the sending of an offer=20 > from B to A=20 > to move the stream to C. >=20 > We need rules for managing the transition that ensure that=20 > the DSN from=20 > B to A is delivered while the connection is still up and=20 > being processed=20 > by A. >=20 > Paul >=20 > Ben Campbell wrote: > > One further complication on the "remember for a period of=20 > time approach"=20 > > is the fact that the client may close its TCP connection. I expect=20 > > relays will generally not be able to re-open the connections back=20 > > towards the client. (The main point of relays is NAT/FW traversal.) > >=20 > > Chris Boulton wrote: > >=20 > >> I agree with Hisham - If you want to save resources, some=20 > form of MSRP > >> termination will be required ELSE we leave this open to the > >> implementation of the client. Either they can discard or=20 > remember for a > >> period of time after session tear down. > >> > >> Chris. > >> =20 > >> > >> > >>> -----Original Message----- > >>> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > >>> Sent: 16 April 2004 08:22 > >>> To: bcampbell@dynamicsoft.com; simple@ietf.org > >>> Subject: RE: [Simple] MSRP: DSN lifetime open issue > >>> > >>> This is a session mode instant messaging, therefore I=20 > would think that > >>> participants would not care about any DSNs after the=20 > session has been > >> > >> > >> torn > >> > >>> down. If they want the DSN, then they need to wait before=20 > tearing down > >> > >> > >> the > >> > >>> session. > >>> > >>> In page mode, you would need to allow the DSN to come=20 > days later. But > >> > >> > >> that > >> > >>> is not the issue here. > >>> > >>> I guess I'm suggesting that all outstanding DSNs are=20 > discarded. I don't > >>> think that the penalty that the relay has to try to send=20 > the DSN anyway > >> > >> > >> is > >> > >>> such a huge problem. If it is, then we probably need to=20 > send a MSRP > >> > >> > >> level > >> > >>> BYE request that traverses relays. > >>> > >>> > >>> /Hisham > >>> > >>> > >>>> -----Original Message----- > >>>> From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf > >>> > >> > >> Of > >> > >>>> ext Ben Campbell > >>>> Sent: 15.April.2004 18:31 > >>>> To: Simple WG > >>>> Subject: [Simple] MSRP: DSN lifetime open issue > >>>> > >>>> > >>>> One open issue concerning MSRP usage of DSN that I would like > >>>> to close > >>>> on is, what happens to DSNs after a session is torn down? > >>>> > >>>> Example: > >>>> > >>>> A R B > >>>> SEND-------> > >>>> <---------OK > >>>> SEND----X > >>>> <---session teardown---> > >>>> <-----REPORT > >>>> > >>>> > >>>> In this example, A sends a message to B via relay R. The > >>>> A-->R hop works > >>>> fine. The R->B hop failes, due to a tcp error. For the sake > >>>> of argument, > >>>> consider this to be a worst case TCP error where the TCP=20 > stack has to > >>>> work through the entire retransmission sequence before it > >>>> gives up, that > >>>> is, a non-trivial amount of time passes. > >>>> > >>>> A and B tear down the session. But since R is not session > >>>> stateful, it > >>>> does not know about this. > >>>> > >>>> So, the question becomes, what happens to outstanding DSN after a > >>>> session is closed? Do they just get dropped? (This is not as > >>>> simple as > >>>> it sounds, since if a relay is not aware of the session > >>>> closure, it will > >>>> still try to send the DSN, wasting resources.) > >>>> > >>>> Or, do we want to be able to deliver DSN outside of the=20 > scope of the > >>>> session in which it was generated? > >>>> > >>>> I have had several offline discussions with people, and=20 > have gotten > >>>> opinions that range from allowing DSN to be sent days later, > >>>> to assuming > >>>> that all outstanding DSN just get discarded. > >>>> > >>>> Thoughts? > >>>> > >>>> _______________________________________________ > >>>> Simple mailing list > >>>> Simple@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/simple > >>>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >> > >> > >> > >> > >> This message has been scanned for viruses by MailControl -=20 > >> www.mailcontrol.com > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 19 10:48:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14818 for ; Mon, 19 Apr 2004 10:48:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFa43-0000zp-My for simple-archive@ietf.org; Mon, 19 Apr 2004 10:48:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFa39-0000ml-00 for simple-archive@ietf.org; Mon, 19 Apr 2004 10:47:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFa2B-0000Zk-00; Mon, 19 Apr 2004 10:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZxG-0001cF-KJ; Mon, 19 Apr 2004 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZvX-00014B-LK for simple@optimus.ietf.org; Mon, 19 Apr 2004 10:39:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14506 for ; Mon, 19 Apr 2004 10:39:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZvV-0006pq-6t for simple@ietf.org; Mon, 19 Apr 2004 10:39:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZua-0006bP-00 for simple@ietf.org; Mon, 19 Apr 2004 10:38:17 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BFZu9-0006MD-00 for simple@ietf.org; Mon, 19 Apr 2004 10:37:49 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3JEbRIx007370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2004 09:37:28 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4083E419.7070408@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, cboulton@ubiquity.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: <2038BCC78B1AD641891A0D1AE133DBB70179793A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179793A@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 09:37:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > There are 2 cases here: > > 1. The SEND arrives at B before the transfer is complete and the TCP connection is dropped > 2. The SEND does not arrive at B before the transfer is complete and the TCP connection is dropped. > > 2 is easier to solve, A would probably get a negative DSN or no response at all (if no relays) > > 1 might be solved by mandating that B must not drop the connection unless it has sent all pending DSNs. That handles _intentional_ dropping of tcp. But it does not handle _unexpected_ failures. > > /Hisham > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 19.April.2004 16:13 >>To: Ben Campbell >>Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>simple@ietf.org >>Subject: Re: [Simple] MSRP: DSN lifetime open issue >> >> >>I think I agree that DSNs are only needed for the duration of the >>session, given a suitable definition of the session. But I >>don't think >>the session can be equated with the TCP connection. That >>connection may >>indeed need to be reestablished after some kind of glitch, >>such as one >>server falling over and being replaced by a redundant backup. >> >>I think the duration of the session has to be tied to signaling - the >>offer/answer exchange. But that makes life difficult for the relays, >>that aren't parties in that exchange. >> >>But before considering relays, lets consider a simpler case >>and see what >>issues there are: >> >>Assume we have established a dialog and MSRP session between A & B. >>Then, perhaps as a result of a 3pcc transfer, A receives a >>reinvite that >>retargets the MSRP media stream to C. As a result, the old TCP >>connection between A&B will be dropped and a new one between >>A&C will be >>established. >> >>The signaling that accomplishes this won't necessarily be >>synchronized >>with the media. For instance, an MSRP SEND message from A to B >>(requiring a DSN) may overlap with the sending of an offer >>from B to A >>to move the stream to C. >> >>We need rules for managing the transition that ensure that >>the DSN from >>B to A is delivered while the connection is still up and >>being processed >>by A. >> >> Paul >> >>Ben Campbell wrote: >> >>>One further complication on the "remember for a period of >> >>time approach" >> >>>is the fact that the client may close its TCP connection. I expect >>>relays will generally not be able to re-open the connections back >>>towards the client. (The main point of relays is NAT/FW traversal.) >>> >>>Chris Boulton wrote: >>> >>> >>>>I agree with Hisham - If you want to save resources, some >> >>form of MSRP >> >>>>termination will be required ELSE we leave this open to the >>>>implementation of the client. Either they can discard or >> >>remember for a >> >>>>period of time after session tear down. >>>> >>>>Chris. >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: hisham.khartabil@nokia.com >> >>[mailto:hisham.khartabil@nokia.com] >> >>>>>Sent: 16 April 2004 08:22 >>>>>To: bcampbell@dynamicsoft.com; simple@ietf.org >>>>>Subject: RE: [Simple] MSRP: DSN lifetime open issue >>>>> >>>>>This is a session mode instant messaging, therefore I >> >>would think that >> >>>>>participants would not care about any DSNs after the >> >>session has been >> >>>> >>>>torn >>>> >>>> >>>>>down. If they want the DSN, then they need to wait before >> >>tearing down >> >>>> >>>>the >>>> >>>> >>>>>session. >>>>> >>>>>In page mode, you would need to allow the DSN to come >> >>days later. But >> >>>> >>>>that >>>> >>>> >>>>>is not the issue here. >>>>> >>>>>I guess I'm suggesting that all outstanding DSNs are >> >>discarded. I don't >> >>>>>think that the penalty that the relay has to try to send >> >>the DSN anyway >> >>>> >>>>is >>>> >>>> >>>>>such a huge problem. If it is, then we probably need to >> >>send a MSRP >> >>>> >>>>level >>>> >>>> >>>>>BYE request that traverses relays. >>>>> >>>>> >>>>>/Hisham >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf >> >>>>Of >>>> >>>> >>>>>>ext Ben Campbell >>>>>>Sent: 15.April.2004 18:31 >>>>>>To: Simple WG >>>>>>Subject: [Simple] MSRP: DSN lifetime open issue >>>>>> >>>>>> >>>>>>One open issue concerning MSRP usage of DSN that I would like >>>>>>to close >>>>>>on is, what happens to DSNs after a session is torn down? >>>>>> >>>>>>Example: >>>>>> >>>>>>A R B >>>>>>SEND-------> >>>>>><---------OK >>>>>> SEND----X >>>>>><---session teardown---> >>>>>><-----REPORT >>>>>> >>>>>> >>>>>>In this example, A sends a message to B via relay R. The >>>>>>A-->R hop works >>>>>>fine. The R->B hop failes, due to a tcp error. For the sake >>>>>>of argument, >>>>>>consider this to be a worst case TCP error where the TCP >> >>stack has to >> >>>>>>work through the entire retransmission sequence before it >>>>>>gives up, that >>>>>>is, a non-trivial amount of time passes. >>>>>> >>>>>>A and B tear down the session. But since R is not session >>>>>>stateful, it >>>>>>does not know about this. >>>>>> >>>>>>So, the question becomes, what happens to outstanding DSN after a >>>>>>session is closed? Do they just get dropped? (This is not as >>>>>>simple as >>>>>>it sounds, since if a relay is not aware of the session >>>>>>closure, it will >>>>>>still try to send the DSN, wasting resources.) >>>>>> >>>>>>Or, do we want to be able to deliver DSN outside of the >> >>scope of the >> >>>>>>session in which it was generated? >>>>>> >>>>>>I have had several offline discussions with people, and >> >>have gotten >> >>>>>>opinions that range from allowing DSN to be sent days later, >>>>>>to assuming >>>>>>that all outstanding DSN just get discarded. >>>>>> >>>>>>Thoughts? >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> >>>>This message has been scanned for viruses by MailControl - >>>>www.mailcontrol.com >>> >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 19 10:58:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15547 for ; Mon, 19 Apr 2004 10:58:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFa5U-0003JL-Bg for simple-archive@odin.ietf.org; Mon, 19 Apr 2004 10:49:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JEnWkO012722 for simple-archive@odin.ietf.org; Mon, 19 Apr 2004 10:49:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFa46-000372-Pm for simple-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 10:48:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14836 for ; Mon, 19 Apr 2004 10:48:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFa44-0000zu-Cv for simple-web-archive@ietf.org; Mon, 19 Apr 2004 10:48:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFa3A-0000mt-00 for simple-web-archive@ietf.org; Mon, 19 Apr 2004 10:47:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFa2B-0000Zk-00; Mon, 19 Apr 2004 10:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZxG-0001cF-KJ; Mon, 19 Apr 2004 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZvX-00014B-LK for simple@optimus.ietf.org; Mon, 19 Apr 2004 10:39:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14506 for ; Mon, 19 Apr 2004 10:39:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZvV-0006pq-6t for simple@ietf.org; Mon, 19 Apr 2004 10:39:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZua-0006bP-00 for simple@ietf.org; Mon, 19 Apr 2004 10:38:17 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BFZu9-0006MD-00 for simple@ietf.org; Mon, 19 Apr 2004 10:37:49 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3JEbRIx007370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2004 09:37:28 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4083E419.7070408@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, cboulton@ubiquity.com, simple@ietf.org Subject: Re: [Simple] MSRP: DSN lifetime open issue References: <2038BCC78B1AD641891A0D1AE133DBB70179793A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179793A@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 09:37:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > There are 2 cases here: > > 1. The SEND arrives at B before the transfer is complete and the TCP connection is dropped > 2. The SEND does not arrive at B before the transfer is complete and the TCP connection is dropped. > > 2 is easier to solve, A would probably get a negative DSN or no response at all (if no relays) > > 1 might be solved by mandating that B must not drop the connection unless it has sent all pending DSNs. That handles _intentional_ dropping of tcp. But it does not handle _unexpected_ failures. > > /Hisham > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 19.April.2004 16:13 >>To: Ben Campbell >>Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>simple@ietf.org >>Subject: Re: [Simple] MSRP: DSN lifetime open issue >> >> >>I think I agree that DSNs are only needed for the duration of the >>session, given a suitable definition of the session. But I >>don't think >>the session can be equated with the TCP connection. That >>connection may >>indeed need to be reestablished after some kind of glitch, >>such as one >>server falling over and being replaced by a redundant backup. >> >>I think the duration of the session has to be tied to signaling - the >>offer/answer exchange. But that makes life difficult for the relays, >>that aren't parties in that exchange. >> >>But before considering relays, lets consider a simpler case >>and see what >>issues there are: >> >>Assume we have established a dialog and MSRP session between A & B. >>Then, perhaps as a result of a 3pcc transfer, A receives a >>reinvite that >>retargets the MSRP media stream to C. As a result, the old TCP >>connection between A&B will be dropped and a new one between >>A&C will be >>established. >> >>The signaling that accomplishes this won't necessarily be >>synchronized >>with the media. For instance, an MSRP SEND message from A to B >>(requiring a DSN) may overlap with the sending of an offer >>from B to A >>to move the stream to C. >> >>We need rules for managing the transition that ensure that >>the DSN from >>B to A is delivered while the connection is still up and >>being processed >>by A. >> >> Paul >> >>Ben Campbell wrote: >> >>>One further complication on the "remember for a period of >> >>time approach" >> >>>is the fact that the client may close its TCP connection. I expect >>>relays will generally not be able to re-open the connections back >>>towards the client. (The main point of relays is NAT/FW traversal.) >>> >>>Chris Boulton wrote: >>> >>> >>>>I agree with Hisham - If you want to save resources, some >> >>form of MSRP >> >>>>termination will be required ELSE we leave this open to the >>>>implementation of the client. Either they can discard or >> >>remember for a >> >>>>period of time after session tear down. >>>> >>>>Chris. >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: hisham.khartabil@nokia.com >> >>[mailto:hisham.khartabil@nokia.com] >> >>>>>Sent: 16 April 2004 08:22 >>>>>To: bcampbell@dynamicsoft.com; simple@ietf.org >>>>>Subject: RE: [Simple] MSRP: DSN lifetime open issue >>>>> >>>>>This is a session mode instant messaging, therefore I >> >>would think that >> >>>>>participants would not care about any DSNs after the >> >>session has been >> >>>> >>>>torn >>>> >>>> >>>>>down. If they want the DSN, then they need to wait before >> >>tearing down >> >>>> >>>>the >>>> >>>> >>>>>session. >>>>> >>>>>In page mode, you would need to allow the DSN to come >> >>days later. But >> >>>> >>>>that >>>> >>>> >>>>>is not the issue here. >>>>> >>>>>I guess I'm suggesting that all outstanding DSNs are >> >>discarded. I don't >> >>>>>think that the penalty that the relay has to try to send >> >>the DSN anyway >> >>>> >>>>is >>>> >>>> >>>>>such a huge problem. If it is, then we probably need to >> >>send a MSRP >> >>>> >>>>level >>>> >>>> >>>>>BYE request that traverses relays. >>>>> >>>>> >>>>>/Hisham >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf >> >>>>Of >>>> >>>> >>>>>>ext Ben Campbell >>>>>>Sent: 15.April.2004 18:31 >>>>>>To: Simple WG >>>>>>Subject: [Simple] MSRP: DSN lifetime open issue >>>>>> >>>>>> >>>>>>One open issue concerning MSRP usage of DSN that I would like >>>>>>to close >>>>>>on is, what happens to DSNs after a session is torn down? >>>>>> >>>>>>Example: >>>>>> >>>>>>A R B >>>>>>SEND-------> >>>>>><---------OK >>>>>> SEND----X >>>>>><---session teardown---> >>>>>><-----REPORT >>>>>> >>>>>> >>>>>>In this example, A sends a message to B via relay R. The >>>>>>A-->R hop works >>>>>>fine. The R->B hop failes, due to a tcp error. For the sake >>>>>>of argument, >>>>>>consider this to be a worst case TCP error where the TCP >> >>stack has to >> >>>>>>work through the entire retransmission sequence before it >>>>>>gives up, that >>>>>>is, a non-trivial amount of time passes. >>>>>> >>>>>>A and B tear down the session. But since R is not session >>>>>>stateful, it >>>>>>does not know about this. >>>>>> >>>>>>So, the question becomes, what happens to outstanding DSN after a >>>>>>session is closed? Do they just get dropped? (This is not as >>>>>>simple as >>>>>>it sounds, since if a relay is not aware of the session >>>>>>closure, it will >>>>>>still try to send the DSN, wasting resources.) >>>>>> >>>>>>Or, do we want to be able to deliver DSN outside of the >> >>scope of the >> >>>>>>session in which it was generated? >>>>>> >>>>>>I have had several offline discussions with people, and >> >>have gotten >> >>>>>>opinions that range from allowing DSN to be sent days later, >>>>>>to assuming >>>>>>that all outstanding DSN just get discarded. >>>>>> >>>>>>Thoughts? >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> >>>>This message has been scanned for viruses by MailControl - >>>>www.mailcontrol.com >>> >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 19 11:52:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18015 for ; Mon, 19 Apr 2004 11:52:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFb45-0000I6-Eq for simple-archive@ietf.org; Mon, 19 Apr 2004 11:52:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFb3J-00003u-00 for simple-archive@ietf.org; Mon, 19 Apr 2004 11:51:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFb2V-0007d9-00; Mon, 19 Apr 2004 11:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFauH-0005Zo-8N; Mon, 19 Apr 2004 11:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFapW-00041z-O5 for simple@optimus.ietf.org; Mon, 19 Apr 2004 11:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17266 for ; Mon, 19 Apr 2004 11:37:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFapV-0004aX-MG for simple@ietf.org; Mon, 19 Apr 2004 11:37:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFaoY-0004LT-00 for simple@ietf.org; Mon, 19 Apr 2004 11:36:06 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BFanW-0003uO-00 for simple@ietf.org; Mon, 19 Apr 2004 11:35:02 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3JFYI6r001902; Mon, 19 Apr 2004 10:34:18 -0500 From: Robert Sparks To: simple@ietf.org Cc: Hisham Khartabil Content-Type: text/plain Message-Id: <1082388863.2202.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] ACTION: Call for consensus : Adopt XCAP auth replacement drafts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 10:34:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks - During the Korea meeting, we had a strong feeling of consent (but no hum) to replace draft-ietf-simple-auth-usage with the following three drafts reflecting alignment with the common-policy work in geopriv: draft-rosenberg-simple-rules-00.txt draft-rosenberg-simple-common-policy-caps-00.txt draft-rosenberg-simple-pres-policy-caps-00.txt We'd like to verify that consensus via the list this week. If you object to adopting these drafts as working group items replacing draft-ietf-simple-auth-usage, please respond with comments before Friday April 23. Feel free to send those comments directly to the list or privately to the chairs (please copy both me and Hisham). Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 19 12:02:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18827 for ; Mon, 19 Apr 2004 12:02:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbBC-0000tr-Kj for simple-archive@odin.ietf.org; Mon, 19 Apr 2004 11:59:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JFxU1e003454 for simple-archive@odin.ietf.org; Mon, 19 Apr 2004 11:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFb4B-0007zn-UQ for simple-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 11:52:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18033 for ; Mon, 19 Apr 2004 11:52:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFb4A-0000ID-OP for simple-web-archive@ietf.org; Mon, 19 Apr 2004 11:52:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFb3K-000041-00 for simple-web-archive@ietf.org; Mon, 19 Apr 2004 11:51:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFb2V-0007d9-00; Mon, 19 Apr 2004 11:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFauH-0005Zo-8N; Mon, 19 Apr 2004 11:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFapW-00041z-O5 for simple@optimus.ietf.org; Mon, 19 Apr 2004 11:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17266 for ; Mon, 19 Apr 2004 11:37:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFapV-0004aX-MG for simple@ietf.org; Mon, 19 Apr 2004 11:37:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFaoY-0004LT-00 for simple@ietf.org; Mon, 19 Apr 2004 11:36:06 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BFanW-0003uO-00 for simple@ietf.org; Mon, 19 Apr 2004 11:35:02 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3JFYI6r001902; Mon, 19 Apr 2004 10:34:18 -0500 From: Robert Sparks To: simple@ietf.org Cc: Hisham Khartabil Content-Type: text/plain Message-Id: <1082388863.2202.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] ACTION: Call for consensus : Adopt XCAP auth replacement drafts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 10:34:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks - During the Korea meeting, we had a strong feeling of consent (but no hum) to replace draft-ietf-simple-auth-usage with the following three drafts reflecting alignment with the common-policy work in geopriv: draft-rosenberg-simple-rules-00.txt draft-rosenberg-simple-common-policy-caps-00.txt draft-rosenberg-simple-pres-policy-caps-00.txt We'd like to verify that consensus via the list this week. If you object to adopting these drafts as working group items replacing draft-ietf-simple-auth-usage, please respond with comments before Friday April 23. Feel free to send those comments directly to the list or privately to the chairs (please copy both me and Hisham). Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 10:56:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23305 for ; Tue, 20 Apr 2004 10:56:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwfO-00016Q-Ot for simple-archive@ietf.org; Tue, 20 Apr 2004 10:56:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFweU-0000qe-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 10:55:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwe7-0000ag-00; Tue, 20 Apr 2004 10:54:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwPt-0003oy-Rk; Tue, 20 Apr 2004 10:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwJD-0001Bd-0h for simple@optimus.ietf.org; Tue, 20 Apr 2004 10:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21851 for ; Tue, 20 Apr 2004 10:33:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwJA-0002Ud-K4 for simple@ietf.org; Tue, 20 Apr 2004 10:33:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwID-0002AI-00 for simple@ietf.org; Tue, 20 Apr 2004 10:32:09 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BFwHD-0001sj-00; Tue, 20 Apr 2004 10:31:07 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KEV3O08090; Tue, 20 Apr 2004 17:31:03 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 17:30:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3KEUuQo005960; Tue, 20 Apr 2004 17:30:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gQUF5i; Tue, 20 Apr 2004 17:30:55 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KEUUs06672; Tue, 20 Apr 2004 17:30:30 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 17:30:33 +0300 Message-ID: <40853408.1020804@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Ben Campbell CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406DE1C8.3040309@dynamicsoft.com> In-Reply-To: <406DE1C8.3040309@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 14:30:33.0100 (UTC) FILETIME=[09BD0CC0:01C426E4] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 17:30:32 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben: Thanks for your comments. Sorry for my late answer. See my inline comments ext Ben Campbell wrote: > I like this approach overall. > > A couple of comments and questions. Apologies if these have already been > discussed. > > Is it legal for the list parameter to point to something other than a > body part? That is, can I have external lists? I believe this question lies in the field of the URI list draft (draft-camarillo-sipping-uri-list-02.txt). Section 8 of that draft has a discussion. > Saying the exploder MUST NOT include the URI list in the outbound > messages seems a little severe. I can imagine applications where I want > the recipients to know the list. This could be useful for "reply to all" > sort of functions. But if we do allow this, we would need to give the > sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. > "bcc" thing.) It seems reasonable to me. I think what we wanted to say is that the Request-URI of the outboud message SHOULD NOT contain a list parameter. The body need not carry the list, but may carry it for other purposes (such as the one you mentioned). > > Instead of saying that message exploders must always send message > requests, we might consider saying the outbound request method must > match the outbound method. This would allow for exploders that know how > to explode more than one method. No, I don't agree. In the past we got an agreement that we will create a message-specific exploder draft. There is a draft that says how to deal with INVITE, other for SUBSCRIBE, other for REFER, and this draft is about MESSAGE. We don't want to go back and make the draft generic, to be applicable to any method. So I believe the wording is correct as it is now. > > > When condidering DoS issues, it might be worth suggesting behavior if > the exploder finds duplicate URIs on the list. For example, I could put > the same URI in a bunch of times, and have a nice DoS amplifier.' Good point. We will add a discussion on the subject. Miguel. > > > Miguel Garcia wrote: > >>Hi: >> >>I have just submitted a draft that discusses a exploder of MESSAGEs. >> >>While it appears in the repository, you can download them from: >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html >> >> >>Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING >>(exploders), I am copying both mailing lists. >> >>Regards, >> >> Miguel > > > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 11:05:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23994 for ; Tue, 20 Apr 2004 11:05:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwl8-0002Ns-TU for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 11:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KF22sk009164 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 11:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwfT-0000GR-2F for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 10:56:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23325 for ; Tue, 20 Apr 2004 10:56:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwfQ-00016e-JF for simple-web-archive@ietf.org; Tue, 20 Apr 2004 10:56:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFweV-0000qn-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 10:55:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwe7-0000ag-00; Tue, 20 Apr 2004 10:54:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwPt-0003oy-Rk; Tue, 20 Apr 2004 10:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwJD-0001Bd-0h for simple@optimus.ietf.org; Tue, 20 Apr 2004 10:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21851 for ; Tue, 20 Apr 2004 10:33:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwJA-0002Ud-K4 for simple@ietf.org; Tue, 20 Apr 2004 10:33:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwID-0002AI-00 for simple@ietf.org; Tue, 20 Apr 2004 10:32:09 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BFwHD-0001sj-00; Tue, 20 Apr 2004 10:31:07 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KEV3O08090; Tue, 20 Apr 2004 17:31:03 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 17:30:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3KEUuQo005960; Tue, 20 Apr 2004 17:30:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gQUF5i; Tue, 20 Apr 2004 17:30:55 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KEUUs06672; Tue, 20 Apr 2004 17:30:30 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 17:30:33 +0300 Message-ID: <40853408.1020804@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Ben Campbell CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406DE1C8.3040309@dynamicsoft.com> In-Reply-To: <406DE1C8.3040309@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 14:30:33.0100 (UTC) FILETIME=[09BD0CC0:01C426E4] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 17:30:32 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben: Thanks for your comments. Sorry for my late answer. See my inline comments ext Ben Campbell wrote: > I like this approach overall. > > A couple of comments and questions. Apologies if these have already been > discussed. > > Is it legal for the list parameter to point to something other than a > body part? That is, can I have external lists? I believe this question lies in the field of the URI list draft (draft-camarillo-sipping-uri-list-02.txt). Section 8 of that draft has a discussion. > Saying the exploder MUST NOT include the URI list in the outbound > messages seems a little severe. I can imagine applications where I want > the recipients to know the list. This could be useful for "reply to all" > sort of functions. But if we do allow this, we would need to give the > sender a way to choose, possibly on a per-URI basis. (Sort of a "cc" vs. > "bcc" thing.) It seems reasonable to me. I think what we wanted to say is that the Request-URI of the outboud message SHOULD NOT contain a list parameter. The body need not carry the list, but may carry it for other purposes (such as the one you mentioned). > > Instead of saying that message exploders must always send message > requests, we might consider saying the outbound request method must > match the outbound method. This would allow for exploders that know how > to explode more than one method. No, I don't agree. In the past we got an agreement that we will create a message-specific exploder draft. There is a draft that says how to deal with INVITE, other for SUBSCRIBE, other for REFER, and this draft is about MESSAGE. We don't want to go back and make the draft generic, to be applicable to any method. So I believe the wording is correct as it is now. > > > When condidering DoS issues, it might be worth suggesting behavior if > the exploder finds duplicate URIs on the list. For example, I could put > the same URI in a bunch of times, and have a nice DoS amplifier.' Good point. We will add a discussion on the subject. Miguel. > > > Miguel Garcia wrote: > >>Hi: >> >>I have just submitted a draft that discusses a exploder of MESSAGEs. >> >>While it appears in the repository, you can download them from: >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html >> >> >>Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING >>(exploders), I am copying both mailing lists. >> >>Regards, >> >> Miguel > > > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 11:09:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24263 for ; Tue, 20 Apr 2004 11:09:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFws1-0004pp-DE for simple-archive@ietf.org; Tue, 20 Apr 2004 11:09:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwr3-0004XW-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 11:08:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwq7-0004Ei-00; Tue, 20 Apr 2004 11:07:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwlA-0002P9-ME; Tue, 20 Apr 2004 11:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwSu-0004Qh-SV for simple@optimus.ietf.org; Tue, 20 Apr 2004 10:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22625 for ; Tue, 20 Apr 2004 10:43:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwSs-0005LJ-8E for simple@ietf.org; Tue, 20 Apr 2004 10:43:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwS2-00055h-00 for simple@ietf.org; Tue, 20 Apr 2004 10:42:19 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly10b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BFwRa-0004oh-00 for simple@ietf.org; Tue, 20 Apr 2004 10:41:50 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly10b.srv.mailcontrol.com (MailControl) with SMTP id i3KEf9rj031095; Tue, 20 Apr 2004 15:41:11 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Tue, 20 Apr 2004 15:41:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C426E5.85A213B8" Message-ID: <45730E094814E44488F789C1CDED27AE0219B26E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: MSRP Details Thread-Index: AcQm5YWjgVaLAGZjQjuvnCrZqb8mXQ== From: "Chris Boulton" To: Cc: "Ben Campbell" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Subject: [Simple] MSRP Details Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 15:41:10 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format... ------_=_NextPart_001_01C426E5.85A213B8 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi to all on the list, =20 I've got a question that I wouldn't mind some input + closure on. I am currently completing the DSN details for MSRP reports and in RFC 1894 - It specifies that the format for 'status' code in a DSN message is:- =20 status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT =20 This does not map exactly to an MSRP status code and I was trying to look at the best solution - does anyone have any input? =20 Should we spread the status code e.g. 200 =3D 2.0.0 =20 OR =20 Use the last 3 digit field e.g. 0.0.200 =20 I would appreciate some input. =20 Best Regards, =20 Chris Boulton. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 =20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com ------_=_NextPart_001_01C426E5.85A213B8 Content-Type: text/html; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi to all on the list,

 

         &n= bsp;            = ;  I’ve got a question that I wouldn’t mind some input + closure on.  I = am currently completing the DSN details for MSRP reports and in RFC 1894 ̵= 1; It specifies that the format for ‘status’ code in a DSN message is= :-

 

status-code =3D DIGIT "." 1*3DIGIT ".&quo= t; 1*3DIGIT

 

This does not map exactly to an MSRP status code and I w= as trying to look at the best solution – does anyone have any input?

 

Should we spread the status code e.g. 200 =3D 2.0.0

 

OR

 

Use the last 3 digit field e.g. 0.0.200

 

I would appreciate some input.

 

Best Regards,

 

Chris Boulton= .

 

 

------------------------------------------------
Chris Boulton
Ubiquity Software

 

Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601
------------------------------------------------

 

 

 



This message ha= s been scanned for viruses by MailControl, a service from BlackSpider Technologies.

------_=_NextPart_001_01C426E5.85A213B8-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 11:21:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24895 for ; Tue, 20 Apr 2004 11:21:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx3f-0000Hp-T6 for simple-archive@ietf.org; Tue, 20 Apr 2004 11:21:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx2h-000018-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 11:20:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFx1s-0007Yr-00; Tue, 20 Apr 2004 11:19:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwlF-0002Rx-Lu; Tue, 20 Apr 2004 11:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwWt-0005kM-Ew for simple@optimus.ietf.org; Tue, 20 Apr 2004 10:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22818 for ; Tue, 20 Apr 2004 10:47:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwWr-0006SM-11 for simple@ietf.org; Tue, 20 Apr 2004 10:47:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwVx-0006Br-00 for simple@ietf.org; Tue, 20 Apr 2004 10:46:21 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BFwVS-0005ur-00; Tue, 20 Apr 2004 10:45:50 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3KEjRIx023203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2004 09:45:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4085377E.602@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406DE1C8.3040309@dynamicsoft.com> <40853408.1020804@nokia.com> In-Reply-To: <40853408.1020804@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 09:45:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Miguel Garcia wrote: [...] >> >> Instead of saying that message exploders must always send message >> requests, we might consider saying the outbound request method must >> match the outbound method. This would allow for exploders that know >> how to explode more than one method. > > > No, I don't agree. In the past we got an agreement that we will create a > message-specific exploder draft. There is a draft that says how to deal > with INVITE, other for SUBSCRIBE, other for REFER, and this draft is > about MESSAGE. We don't want to go back and make the draft generic, to > be applicable to any method. So I believe the wording is correct as it > is now. My concern is, the text as written can be interpreted to mean that device cannot be both a MESSAGE exploder and an INVITE exploder, because exploding INVITE explicitly violates a normative requirement for MESSAGE exploders. I know that is not the intent, but I think it can be misread. Perhaps we simply need to say that exploding non-MESSAGE methods is out of scope for this document. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 12:18:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00836 for ; Tue, 20 Apr 2004 12:18:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxeL-0007VZ-Tf for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 11:59:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KFx56a028857 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 11:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFws4-0005U5-LA for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 11:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24272 for ; Tue, 20 Apr 2004 11:09:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFws1-0004pu-VT for simple-web-archive@ietf.org; Tue, 20 Apr 2004 11:09:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwr4-0004Xe-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 11:08:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwq7-0004Ei-00; Tue, 20 Apr 2004 11:07:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwlA-0002P9-ME; Tue, 20 Apr 2004 11:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwSu-0004Qh-SV for simple@optimus.ietf.org; Tue, 20 Apr 2004 10:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22625 for ; Tue, 20 Apr 2004 10:43:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwSs-0005LJ-8E for simple@ietf.org; Tue, 20 Apr 2004 10:43:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwS2-00055h-00 for simple@ietf.org; Tue, 20 Apr 2004 10:42:19 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly10b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BFwRa-0004oh-00 for simple@ietf.org; Tue, 20 Apr 2004 10:41:50 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly10b.srv.mailcontrol.com (MailControl) with SMTP id i3KEf9rj031095; Tue, 20 Apr 2004 15:41:11 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Tue, 20 Apr 2004 15:41:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C426E5.85A213B8" Message-ID: <45730E094814E44488F789C1CDED27AE0219B26E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: MSRP Details Thread-Index: AcQm5YWjgVaLAGZjQjuvnCrZqb8mXQ== From: "Chris Boulton" To: Cc: "Ben Campbell" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Subject: [Simple] MSRP Details Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 15:41:10 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format... ------_=_NextPart_001_01C426E5.85A213B8 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi to all on the list, =20 I've got a question that I wouldn't mind some input + closure on. I am currently completing the DSN details for MSRP reports and in RFC 1894 - It specifies that the format for 'status' code in a DSN message is:- =20 status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT =20 This does not map exactly to an MSRP status code and I was trying to look at the best solution - does anyone have any input? =20 Should we spread the status code e.g. 200 =3D 2.0.0 =20 OR =20 Use the last 3 digit field e.g. 0.0.200 =20 I would appreciate some input. =20 Best Regards, =20 Chris Boulton. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 =20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com ------_=_NextPart_001_01C426E5.85A213B8 Content-Type: text/html; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi to all on the list,

 

         &n= bsp;            = ;  I’ve got a question that I wouldn’t mind some input + closure on.  I = am currently completing the DSN details for MSRP reports and in RFC 1894 ̵= 1; It specifies that the format for ‘status’ code in a DSN message is= :-

 

status-code =3D DIGIT "." 1*3DIGIT ".&quo= t; 1*3DIGIT

 

This does not map exactly to an MSRP status code and I w= as trying to look at the best solution – does anyone have any input?

 

Should we spread the status code e.g. 200 =3D 2.0.0

 

OR

 

Use the last 3 digit field e.g. 0.0.200

 

I would appreciate some input.

 

Best Regards,

 

Chris Boulton= .

 

 

------------------------------------------------
Chris Boulton
Ubiquity Software

 

Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601
------------------------------------------------

 

 

 



This message ha= s been scanned for viruses by MailControl, a service from BlackSpider Technologies.

------_=_NextPart_001_01C426E5.85A213B8-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 12:35:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01581 for ; Tue, 20 Apr 2004 12:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxgi-0008CL-3O for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 12:01:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KG1WFr031509 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 12:01:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFx3h-0000fi-E5 for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 11:21:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24913 for ; Tue, 20 Apr 2004 11:21:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx3g-0000Hy-IV for simple-web-archive@ietf.org; Tue, 20 Apr 2004 11:21:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx2i-00001F-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 11:20:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFx1s-0007Yr-00; Tue, 20 Apr 2004 11:19:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwlF-0002Rx-Lu; Tue, 20 Apr 2004 11:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwWt-0005kM-Ew for simple@optimus.ietf.org; Tue, 20 Apr 2004 10:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22818 for ; Tue, 20 Apr 2004 10:47:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwWr-0006SM-11 for simple@ietf.org; Tue, 20 Apr 2004 10:47:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwVx-0006Br-00 for simple@ietf.org; Tue, 20 Apr 2004 10:46:21 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BFwVS-0005ur-00; Tue, 20 Apr 2004 10:45:50 -0400 Received: from dynamicsoft.com (bdsl.66.12.12.222.gte.net [66.12.12.222]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3KEjRIx023203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2004 09:45:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4085377E.602@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406DE1C8.3040309@dynamicsoft.com> <40853408.1020804@nokia.com> In-Reply-To: <40853408.1020804@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 09:45:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel Garcia wrote: [...] >> >> Instead of saying that message exploders must always send message >> requests, we might consider saying the outbound request method must >> match the outbound method. This would allow for exploders that know >> how to explode more than one method. > > > No, I don't agree. In the past we got an agreement that we will create a > message-specific exploder draft. There is a draft that says how to deal > with INVITE, other for SUBSCRIBE, other for REFER, and this draft is > about MESSAGE. We don't want to go back and make the draft generic, to > be applicable to any method. So I believe the wording is correct as it > is now. My concern is, the text as written can be interpreted to mean that device cannot be both a MESSAGE exploder and an INVITE exploder, because exploding INVITE explicitly violates a normative requirement for MESSAGE exploders. I know that is not the intent, but I think it can be misread. Perhaps we simply need to say that exploding non-MESSAGE methods is out of scope for this document. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 12:40:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02083 for ; Tue, 20 Apr 2004 12:40:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyIF-0001cC-Go for simple-archive@ietf.org; Tue, 20 Apr 2004 12:40:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyH7-0001FB-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 12:39:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyG4-0000s4-00; Tue, 20 Apr 2004 12:38:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxhG-00007q-DL; Tue, 20 Apr 2004 12:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFx6h-0002Bi-B9 for simple@optimus.ietf.org; Tue, 20 Apr 2004 11:24:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25112 for ; Tue, 20 Apr 2004 11:24:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx6g-0001A0-G2 for simple@ietf.org; Tue, 20 Apr 2004 11:24:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx5l-0000s9-00 for simple@ietf.org; Tue, 20 Apr 2004 11:23:21 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BFx4w-0000az-00; Tue, 20 Apr 2004 11:22:30 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KFMLm15100; Tue, 20 Apr 2004 18:22:21 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 18:22:07 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3KFM7u7006218; Tue, 20 Apr 2004 18:22:07 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MseyvS; Tue, 20 Apr 2004 18:22:04 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KFM2F24506; Tue, 20 Apr 2004 18:22:02 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 18:22:04 +0300 Message-ID: <4085401C.2000008@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Paul Kyzivat CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406DF1EC.4050400@cisco.com> In-Reply-To: <406DF1EC.4050400@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 15:22:04.0911 (UTC) FILETIME=[3C99F7F0:01C426EB] Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sipping] MESSAGE Exploders draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 18:22:04 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Paul: Thanks for your comments. Answers inline. ext Paul Kyzivat wrote: > Miguel, > > In general the approach in the draft seems reasonable to me. > > I see one area of ambiguity, having to do with how multipart bodies are > handled. The draft says to remove the list and include everything else. > But even your example doesn't do that - it also removes the > multipart/mixed wrapper. Of course in this particular example that makes > perfect sense, but it goes beyond what the draft says to do. We start from the the fact that there will be as a minimum, two bodies, the list, and the actual payload. There might be more bodies, such as multiple payloads, S/MIME signatures, etc. I guess the algorithm should be: - If there is any kind of security body for the exploder (e.g., signed with the public key of the exploder), then remove that body. - Remove the list itself (in a typical use case, unless an extension says the oposite; I am referring to Ben's suggestion to allow it). - If there is only one body left, then remove the multipart/mixed wrapper. - Send the remaining stuff. > > There are more complex cases: > > - for security there could be signed body parts. > > - The signature could be on the multipart containing the message > and list. It would have to be removed. > > - The signature could be on just the message. Presumably > it should remain. > I agree. > > - There could be other body parts referenced by cid: urls in > other headers in the message. Yes, they should remain. > > I think there needs to be a more prescriptive way of defining what gets > passed on in the exploded messages. This is really just a manifestation > of a more general problem of how to decide how different body parts > should be processed. It potentially exists in a normal, unexploded, MESSAGE. > > I think at least part of the answer lies with Content-Disposition. I > think there should be clarity about the content-disposition should be > for the body part(s) that MESSAGE interprets as message content. > Probably "render" (which is default for sip) would be an appropriate > content-disposition for message content. Agree so far. It may happen that some of this stuff is generic enough (not MESSAGE specific). > > Also, I think there should be some clarity about what the > content-disposition should be for various kinds of multipart containers > when used in the various ways they may be used in sip. I'm not quite > sure what the answer is here. > > The list itself is of course referenced from a cid: url. It is the url > and its placement that determines how the corresponding body part should > be processed. For these, the content-disposition should be some value > that doesn't imply some other sort of processing. I think it can't be > any of "session", "render", "alert", or "icon". Maybe it could be > "attachment". I will be happy to have a very clear deterministic way to find out what to pass and what to keep to the other side of the exploder, base on presumabley the content-disposition. Let's see if I can come up with something. Thanks, Miguel > > Paul > > > > Miguel Garcia wrote: > >>Hi: >> >>I have just submitted a draft that discusses a exploder of MESSAGEs. >> >>While it appears in the repository, you can download them from: >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html >> >> >>Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING >>(exploders), I am copying both mailing lists. >> >>Regards, >> >> Miguel > > > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 12:43:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02468 for ; Tue, 20 Apr 2004 12:43:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyL2-0002eD-En for simple-archive@ietf.org; Tue, 20 Apr 2004 12:43:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyJr-00023C-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 12:42:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyIQ-0001df-00; Tue, 20 Apr 2004 12:40:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxn2-000313-Dp; Tue, 20 Apr 2004 12:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxAL-0003yY-El for simple@optimus.ietf.org; Tue, 20 Apr 2004 11:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25454 for ; Tue, 20 Apr 2004 11:28:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxAK-0002Mr-FX for simple@ietf.org; Tue, 20 Apr 2004 11:28:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx8i-0001rW-00 for simple@ietf.org; Tue, 20 Apr 2004 11:26:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BFx7T-0001SC-00; Tue, 20 Apr 2004 11:25:07 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KFP3j15868; Tue, 20 Apr 2004 18:25:03 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 18:25:01 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3KFP1oJ019074; Tue, 20 Apr 2004 18:25:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004Iqyi3; Tue, 20 Apr 2004 18:25:01 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KFOms08142; Tue, 20 Apr 2004 18:24:48 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 18:24:48 +0300 Message-ID: <408540BF.6080102@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Ben Campbell CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406DE1C8.3040309@dynamicsoft.com> <40853408.1020804@nokia.com> <4085377E.602@dynamicsoft.com> In-Reply-To: <4085377E.602@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 15:24:48.0287 (UTC) FILETIME=[9DFB2AF0:01C426EB] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 18:24:47 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit ext Ben Campbell wrote: > > Miguel Garcia wrote: > > [...] > >>> >>> Instead of saying that message exploders must always send message >>> requests, we might consider saying the outbound request method must >>> match the outbound method. This would allow for exploders that know >>> how to explode more than one method. >> >> >> >> No, I don't agree. In the past we got an agreement that we will create >> a message-specific exploder draft. There is a draft that says how to >> deal with INVITE, other for SUBSCRIBE, other for REFER, and this draft >> is about MESSAGE. We don't want to go back and make the draft >> generic, to be applicable to any method. So I believe the wording is >> correct as it is now. > > > My concern is, the text as written can be interpreted to mean that > device cannot be both a MESSAGE exploder and an INVITE exploder, because > exploding INVITE explicitly violates a normative requirement for MESSAGE > exploders. I know that is not the intent, but I think it can be misread. > Perhaps we simply need to say that exploding non-MESSAGE methods is out > of scope for this document. > > Thanks! > > Ben. Ok, I understand your concern, and it sounds fine to me. We will specify that other messages are outside the scope of the document. Thanks. Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 12:44:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02585 for ; Tue, 20 Apr 2004 12:44:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyLv-0002z4-EA for simple-archive@ietf.org; Tue, 20 Apr 2004 12:44:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyKq-0002PP-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 12:43:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyJZ-00021A-00; Tue, 20 Apr 2004 12:41:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxnK-0003Bf-KW; Tue, 20 Apr 2004 12:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxCs-00052s-4r for simple@optimus.ietf.org; Tue, 20 Apr 2004 11:30:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25822 for ; Tue, 20 Apr 2004 11:30:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxCr-0003Lr-3L for simple@ietf.org; Tue, 20 Apr 2004 11:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxBT-0002nH-00 for simple@ietf.org; Tue, 20 Apr 2004 11:29:15 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BFx9u-00020x-00 for simple@ietf.org; Tue, 20 Apr 2004 11:27:38 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3KFQp6r003267 for ; Tue, 20 Apr 2004 10:26:51 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1082474818.2217.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE schedule for next few weeks Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 10:26:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks - We have a lot of work that is nearly complete, and a lot of other work that we need to bring to completion very soon. Hisham and I have sketched out a WG Last Call calendar to work against while we bring these items into a state we can send to the IESG. It's currently available at http://www.nostrum.com/~rjsparks/simple-plan We'll move it to softarmor soon and maintain it there. The schedule is very aggressive, and we will have several documents in WGLC at a time. It's going to take a lot of diligent work on everyone's part to get this done. The editors of the drafts are ready to push to meet these dates. We need each of you to get beside them and help. Here are some things you can do that will help most: 1) Reread those drafts that we've been working on for awhile. Enter the coming weeks ready to discuss what they drafts say now instead relying on memory of what previous versions have contained. 2) Stay current on the list discussion - We're working to close the last issues on these drafts, early participation and comments are much more valuable than later ones. 3) Reply to each last call with comments, even if the comment is only "I believe this work is ready send on". If you're willing to help with NIT reviews in addition to working on technical polish, please send Hisham and me a note. The next few weeks are going to be both intense and exciting. We'll be wrapping up a major portion of this group's work. Thanks in advance for joining in the push to get it over the goal-line. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 13:18:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05540 for ; Tue, 20 Apr 2004 13:18:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFycu-0002kp-St for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 13:01:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KH1eVt010583 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 13:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyIJ-0001dB-3c for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 12:40:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02101 for ; Tue, 20 Apr 2004 12:40:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyIH-0001cU-HN for simple-web-archive@ietf.org; Tue, 20 Apr 2004 12:40:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyH8-0001FJ-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 12:39:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyG4-0000s4-00; Tue, 20 Apr 2004 12:38:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxhG-00007q-DL; Tue, 20 Apr 2004 12:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFx6h-0002Bi-B9 for simple@optimus.ietf.org; Tue, 20 Apr 2004 11:24:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25112 for ; Tue, 20 Apr 2004 11:24:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx6g-0001A0-G2 for simple@ietf.org; Tue, 20 Apr 2004 11:24:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx5l-0000s9-00 for simple@ietf.org; Tue, 20 Apr 2004 11:23:21 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BFx4w-0000az-00; Tue, 20 Apr 2004 11:22:30 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KFMLm15100; Tue, 20 Apr 2004 18:22:21 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 18:22:07 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3KFM7u7006218; Tue, 20 Apr 2004 18:22:07 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MseyvS; Tue, 20 Apr 2004 18:22:04 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KFM2F24506; Tue, 20 Apr 2004 18:22:02 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 18:22:04 +0300 Message-ID: <4085401C.2000008@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Paul Kyzivat CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406DF1EC.4050400@cisco.com> In-Reply-To: <406DF1EC.4050400@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 15:22:04.0911 (UTC) FILETIME=[3C99F7F0:01C426EB] Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sipping] MESSAGE Exploders draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 18:22:04 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Paul: Thanks for your comments. Answers inline. ext Paul Kyzivat wrote: > Miguel, > > In general the approach in the draft seems reasonable to me. > > I see one area of ambiguity, having to do with how multipart bodies are > handled. The draft says to remove the list and include everything else. > But even your example doesn't do that - it also removes the > multipart/mixed wrapper. Of course in this particular example that makes > perfect sense, but it goes beyond what the draft says to do. We start from the the fact that there will be as a minimum, two bodies, the list, and the actual payload. There might be more bodies, such as multiple payloads, S/MIME signatures, etc. I guess the algorithm should be: - If there is any kind of security body for the exploder (e.g., signed with the public key of the exploder), then remove that body. - Remove the list itself (in a typical use case, unless an extension says the oposite; I am referring to Ben's suggestion to allow it). - If there is only one body left, then remove the multipart/mixed wrapper. - Send the remaining stuff. > > There are more complex cases: > > - for security there could be signed body parts. > > - The signature could be on the multipart containing the message > and list. It would have to be removed. > > - The signature could be on just the message. Presumably > it should remain. > I agree. > > - There could be other body parts referenced by cid: urls in > other headers in the message. Yes, they should remain. > > I think there needs to be a more prescriptive way of defining what gets > passed on in the exploded messages. This is really just a manifestation > of a more general problem of how to decide how different body parts > should be processed. It potentially exists in a normal, unexploded, MESSAGE. > > I think at least part of the answer lies with Content-Disposition. I > think there should be clarity about the content-disposition should be > for the body part(s) that MESSAGE interprets as message content. > Probably "render" (which is default for sip) would be an appropriate > content-disposition for message content. Agree so far. It may happen that some of this stuff is generic enough (not MESSAGE specific). > > Also, I think there should be some clarity about what the > content-disposition should be for various kinds of multipart containers > when used in the various ways they may be used in sip. I'm not quite > sure what the answer is here. > > The list itself is of course referenced from a cid: url. It is the url > and its placement that determines how the corresponding body part should > be processed. For these, the content-disposition should be some value > that doesn't imply some other sort of processing. I think it can't be > any of "session", "render", "alert", or "icon". Maybe it could be > "attachment". I will be happy to have a very clear deterministic way to find out what to pass and what to keep to the other side of the exploder, base on presumabley the content-disposition. Let's see if I can come up with something. Thanks, Miguel > > Paul > > > > Miguel Garcia wrote: > >>Hi: >> >>I have just submitted a draft that discusses a exploder of MESSAGEs. >> >>While it appears in the repository, you can download them from: >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.txt >> >>http://people.nokia.net/~miguel/drafts/draft-garcia-simple-message-exploder-00.html >> >> >>Since this is an area covered by SIMPLE (Instant Messaging) and SIPPING >>(exploders), I am copying both mailing lists. >> >>Regards, >> >> Miguel > > > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 13:23:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05987 for ; Tue, 20 Apr 2004 13:23:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyfQ-00040b-JA for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 13:04:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KH4GuN015405 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 13:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyL5-0002pc-Mf for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 12:43:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02486 for ; Tue, 20 Apr 2004 12:43:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyL4-0002eN-4u for simple-web-archive@ietf.org; Tue, 20 Apr 2004 12:43:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyJs-00023N-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 12:42:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyIQ-0001df-00; Tue, 20 Apr 2004 12:40:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxn2-000313-Dp; Tue, 20 Apr 2004 12:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxAL-0003yY-El for simple@optimus.ietf.org; Tue, 20 Apr 2004 11:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25454 for ; Tue, 20 Apr 2004 11:28:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxAK-0002Mr-FX for simple@ietf.org; Tue, 20 Apr 2004 11:28:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx8i-0001rW-00 for simple@ietf.org; Tue, 20 Apr 2004 11:26:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BFx7T-0001SC-00; Tue, 20 Apr 2004 11:25:07 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KFP3j15868; Tue, 20 Apr 2004 18:25:03 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 18:25:01 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3KFP1oJ019074; Tue, 20 Apr 2004 18:25:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004Iqyi3; Tue, 20 Apr 2004 18:25:01 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KFOms08142; Tue, 20 Apr 2004 18:24:48 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 18:24:48 +0300 Message-ID: <408540BF.6080102@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Ben Campbell CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo Subject: Re: [Simple] MESSAGE Exploders draft References: <406DE1C8.3040309@dynamicsoft.com> <40853408.1020804@nokia.com> <4085377E.602@dynamicsoft.com> In-Reply-To: <4085377E.602@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2004 15:24:48.0287 (UTC) FILETIME=[9DFB2AF0:01C426EB] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 18:24:47 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Ben Campbell wrote: > > Miguel Garcia wrote: > > [...] > >>> >>> Instead of saying that message exploders must always send message >>> requests, we might consider saying the outbound request method must >>> match the outbound method. This would allow for exploders that know >>> how to explode more than one method. >> >> >> >> No, I don't agree. In the past we got an agreement that we will create >> a message-specific exploder draft. There is a draft that says how to >> deal with INVITE, other for SUBSCRIBE, other for REFER, and this draft >> is about MESSAGE. We don't want to go back and make the draft >> generic, to be applicable to any method. So I believe the wording is >> correct as it is now. > > > My concern is, the text as written can be interpreted to mean that > device cannot be both a MESSAGE exploder and an INVITE exploder, because > exploding INVITE explicitly violates a normative requirement for MESSAGE > exploders. I know that is not the intent, but I think it can be misread. > Perhaps we simply need to say that exploding non-MESSAGE methods is out > of scope for this document. > > Thanks! > > Ben. Ok, I understand your concern, and it sounds fine to me. We will specify that other messages are outside the scope of the document. Thanks. Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 13:23:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06037 for ; Tue, 20 Apr 2004 13:23:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyfU-00044k-TM for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 13:04:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KH4KMp015661 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 13:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyLx-0003AV-O4 for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 12:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02603 for ; Tue, 20 Apr 2004 12:44:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyLw-0002z9-3M for simple-web-archive@ietf.org; Tue, 20 Apr 2004 12:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyKq-0002PY-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 12:43:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyJZ-00021A-00; Tue, 20 Apr 2004 12:41:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxnK-0003Bf-KW; Tue, 20 Apr 2004 12:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxCs-00052s-4r for simple@optimus.ietf.org; Tue, 20 Apr 2004 11:30:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25822 for ; Tue, 20 Apr 2004 11:30:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxCr-0003Lr-3L for simple@ietf.org; Tue, 20 Apr 2004 11:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxBT-0002nH-00 for simple@ietf.org; Tue, 20 Apr 2004 11:29:15 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BFx9u-00020x-00 for simple@ietf.org; Tue, 20 Apr 2004 11:27:38 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3KFQp6r003267 for ; Tue, 20 Apr 2004 10:26:51 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1082474818.2217.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE schedule for next few weeks Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 10:26:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks - We have a lot of work that is nearly complete, and a lot of other work that we need to bring to completion very soon. Hisham and I have sketched out a WG Last Call calendar to work against while we bring these items into a state we can send to the IESG. It's currently available at http://www.nostrum.com/~rjsparks/simple-plan We'll move it to softarmor soon and maintain it there. The schedule is very aggressive, and we will have several documents in WGLC at a time. It's going to take a lot of diligent work on everyone's part to get this done. The editors of the drafts are ready to push to meet these dates. We need each of you to get beside them and help. Here are some things you can do that will help most: 1) Reread those drafts that we've been working on for awhile. Enter the coming weeks ready to discuss what they drafts say now instead relying on memory of what previous versions have contained. 2) Stay current on the list discussion - We're working to close the last issues on these drafts, early participation and comments are much more valuable than later ones. 3) Reply to each last call with comments, even if the comment is only "I believe this work is ready send on". If you're willing to help with NIT reviews in addition to working on technical polish, please send Hisham and me a note. The next few weeks are going to be both intense and exciting. We'll be wrapping up a major portion of this group's work. Thanks in advance for joining in the push to get it over the goal-line. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 17:25:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26745 for ; Tue, 20 Apr 2004 17:25:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG2k4-0000f3-WD for simple-archive@ietf.org; Tue, 20 Apr 2004 17:25:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2jF-0000ah-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 17:24:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG2ik-0000WC-00; Tue, 20 Apr 2004 17:23:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1UQ-0002f0-N7; Tue, 20 Apr 2004 16:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Hy-0006Dg-Sd for simple@optimus.ietf.org; Tue, 20 Apr 2004 15:52:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18255; Tue, 20 Apr 2004 15:52:12 -0400 (EDT) Message-Id: <200404201952.PAA18255@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 15:52:12 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Partial Notification of Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-notify-02.txt Pages : 17 Date : 2004-4-20 A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Limitations can also be caused by the interface between the terminal and the network, i.e. radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase transport efficiency, by introducing a mechanism called partial notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-notify-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-20160920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160920.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 17:31:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27276 for ; Tue, 20 Apr 2004 17:31:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG2q3-0001GT-JQ for simple-archive@ietf.org; Tue, 20 Apr 2004 17:31:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2pE-0001As-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 17:30:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG2oY-00015D-00; Tue, 20 Apr 2004 17:29:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1UU-0002fg-3N; Tue, 20 Apr 2004 16:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1I5-0006EI-ND for simple@optimus.ietf.org; Tue, 20 Apr 2004 15:52:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18287; Tue, 20 Apr 2004 15:52:19 -0400 (EDT) Message-Id: <200404201952.PAA18287@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 15:52:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-01.txt Pages : 14 Date : 2004-4-20 The presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-20160929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160929.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 18:13:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01723 for ; Tue, 20 Apr 2004 18:13:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG37w-00031W-E4 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 17:50:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KLo0n9011612 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 17:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2k7-0008JZ-S1 for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 17:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26763 for ; Tue, 20 Apr 2004 17:25:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG2k5-0000f9-J7 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 17:25:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2jG-0000ap-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 17:24:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG2ik-0000WC-00; Tue, 20 Apr 2004 17:23:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1UQ-0002f0-N7; Tue, 20 Apr 2004 16:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Hy-0006Dg-Sd for simple@optimus.ietf.org; Tue, 20 Apr 2004 15:52:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18255; Tue, 20 Apr 2004 15:52:12 -0400 (EDT) Message-Id: <200404201952.PAA18255@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 15:52:12 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Partial Notification of Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-notify-02.txt Pages : 17 Date : 2004-4-20 A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Limitations can also be caused by the interface between the terminal and the network, i.e. radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase transport efficiency, by introducing a mechanism called partial notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-notify-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-20160920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160920.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 18:15:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02075 for ; Tue, 20 Apr 2004 18:15:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3EW-0005Tt-Ev for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 17:56:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KLumrH021064 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 17:56:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2q6-0001AN-GV for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 17:31:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27293 for ; Tue, 20 Apr 2004 17:31:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG2q4-0001GY-5u for simple-web-archive@ietf.org; Tue, 20 Apr 2004 17:31:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2pE-0001B0-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 17:30:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG2oY-00015D-00; Tue, 20 Apr 2004 17:29:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1UU-0002fg-3N; Tue, 20 Apr 2004 16:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1I5-0006EI-ND for simple@optimus.ietf.org; Tue, 20 Apr 2004 15:52:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18287; Tue, 20 Apr 2004 15:52:19 -0400 (EDT) Message-Id: <200404201952.PAA18287@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 15:52:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-01.txt Pages : 14 Date : 2004-4-20 The presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-20160929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160929.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 20 21:05:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12690 for ; Tue, 20 Apr 2004 21:05:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6B4-00057k-KS for simple-archive@ietf.org; Tue, 20 Apr 2004 21:05:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6AA-00052I-00 for simple-archive@ietf.org; Tue, 20 Apr 2004 21:04:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG69S-0004xT-00; Tue, 20 Apr 2004 21:03:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5xC-0004GQ-QI; Tue, 20 Apr 2004 20:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5mp-00009u-QM for simple@optimus.ietf.org; Tue, 20 Apr 2004 20:40:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11347 for ; Tue, 20 Apr 2004 20:40:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG5mn-0002la-IZ for simple@ietf.org; Tue, 20 Apr 2004 20:40:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5lq-0002hO-00 for simple@ietf.org; Tue, 20 Apr 2004 20:39:23 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BG5ld-0002ds-00 for simple@ietf.org; Tue, 20 Apr 2004 20:39:10 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 20 Apr 2004 17:39:00 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Apr 2004 17:38:39 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 20 Apr 2004 17:38:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: Thread-Topic: [Simple] MSRP message reliability(long) thread-index: AcQevzmYZiEaOXSARYiJXxgqQGDR3AIeJonQ From: "Orit Levin" To: "Vikas Tandon" Cc: "Simple WG" , "Ben Campbell" X-OriginalArrivalTime: 21 Apr 2004 00:38:23.0265 (UTC) FILETIME=[F3A69910:01C42738] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 17:38:12 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Vicas, I understand that you don't see a problem in unconditionally sending a (hop-by-hop) response to every message (regardless the end-to-end mode being used). If my understanding is correct, how are you planning to address the wireless bandwidth problem in this case? Thanks, Orit. -----Original Message----- From: Vikas Tandon [mailto:vikas@arciis.com]=20 Sent: Friday, April 09, 2004 10:47 PM To: 'Ben Campbell' Cc: Orit Levin; 'Simple WG' Subject: RE: [Simple] MSRP message reliability(long) Hi Ben & Group, By "this" i mean the earlier messages exchanged between me, Mr. Vijay Gurbani, Mr. Hisham and a couple of more participants. Yes i am referring to the delivery reports. =20 Regards, -Vikas -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: vendredi 9 avril 2004 20:10 To: Vikas Tandon Cc: 'Orit Levin'; 'Simple WG' Subject: Re: [Simple] MSRP message reliability(long) Vikas Tandon wrote: > Also as discussed earlier in this forum, this adds a lot of traffic to > the client (specially the wireless mobile clients where the bandwidth=20 > is an issue). If the workgroup plans to make it configurable to set=20 > the delivery response for positive case off, then it has to be=20 > terminated earlier than reaching the wireless medium. E.g. terminate=20 > the positive response at the IM server in case the client has chosen=20 > not to receive the positive acknowledgements of delivery of IM. Hi, could you clarify what "this" refers to in the previous paragraph?=20 Keep in mind that we are really discussion two things: the transaction=20 responses between hops, and the sending of delivery reports. It sounds=20 to me like you are talking delivery reports, but I am not certain. >=20 > If we fail to do this, imagine for every message I'm sending, there is > some traffic I'm getting back to my mobile device (which is painful=20 > because i may be paying by the amount of traffic i transact from my=20 > device). So although it becomes transparent to me from device, by i=20 > still pay for it. The workgroup needs to consider this matter. I=20 > somehow still prefer - "No news is good news". >=20 > Would be good to know more thoughts on this. >=20 > Regards, > Vikas Tandon >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf=20 > Of Ben Campbell > Sent: vendredi 9 avril 2004 19:45 > To: Orit Levin > Cc: Simple WG > Subject: Re: [Simple] MSRP message reliability(long) >=20 >=20 > Orit Levin wrote: >=20 > [...] >=20 >>Why are you opposing to a flexible hop-by-hop mechanism (in addition >>to DSN)? It doesn't necessarily require negotiation - only local=20 >>policy for setting the bit. Let's assume for a moment that a bit per=20 >>message exists saying "response/don't response" to the previous hop. >=20 >=20 > I oppose the ability to select whether you use transaction responses=20 > or > not because it adds a huge amount of complexity to the protocol and any=20 > implementations. Adding or removing transaction responses _completely_ > changes the protocol semantics. In effect, it would be saying we have=20 > two different required protocols with the same syntax on top. If we make >=20 > this selectable, we make every implementer build 2 protocols with > different state machines, etc. I think that will be _much_ more of an=20 > impediment to acceptance than performance differences in the range you > predict. >=20 > My point is, if the working group were to decide we need to be able to > run without transaction responses (a big if) , then we should _always_ > run without transaction responses. As it is, earlier attempts at a=20 > message sessions did not have the transaction response, and the working=20 > group decided to put them it. (Does anyone remember the specific=20 > argument used at that time?) >=20 > But, on all of these points, working group consensus trumps either of > our opinions. Please, anyone who cares one way or another, state your=20 > opinion asap! >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 20 21:27:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13629 for ; Tue, 20 Apr 2004 21:27:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6OC-0008Lm-S9 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 21:19:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L1J0ee032098 for simple-archive@odin.ietf.org; Tue, 20 Apr 2004 21:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6B7-00030e-R3 for simple-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 21:05:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12707 for ; Tue, 20 Apr 2004 21:05:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6B5-00057p-9y for simple-web-archive@ietf.org; Tue, 20 Apr 2004 21:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6AB-00052P-00 for simple-web-archive@ietf.org; Tue, 20 Apr 2004 21:04:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG69S-0004xT-00; Tue, 20 Apr 2004 21:03:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5xC-0004GQ-QI; Tue, 20 Apr 2004 20:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5mp-00009u-QM for simple@optimus.ietf.org; Tue, 20 Apr 2004 20:40:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11347 for ; Tue, 20 Apr 2004 20:40:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG5mn-0002la-IZ for simple@ietf.org; Tue, 20 Apr 2004 20:40:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5lq-0002hO-00 for simple@ietf.org; Tue, 20 Apr 2004 20:39:23 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BG5ld-0002ds-00 for simple@ietf.org; Tue, 20 Apr 2004 20:39:10 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 20 Apr 2004 17:39:00 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Apr 2004 17:38:39 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 20 Apr 2004 17:38:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: Thread-Topic: [Simple] MSRP message reliability(long) thread-index: AcQevzmYZiEaOXSARYiJXxgqQGDR3AIeJonQ From: "Orit Levin" To: "Vikas Tandon" Cc: "Simple WG" , "Ben Campbell" X-OriginalArrivalTime: 21 Apr 2004 00:38:23.0265 (UTC) FILETIME=[F3A69910:01C42738] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 17:38:12 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vicas, I understand that you don't see a problem in unconditionally sending a (hop-by-hop) response to every message (regardless the end-to-end mode being used). If my understanding is correct, how are you planning to address the wireless bandwidth problem in this case? Thanks, Orit. -----Original Message----- From: Vikas Tandon [mailto:vikas@arciis.com]=20 Sent: Friday, April 09, 2004 10:47 PM To: 'Ben Campbell' Cc: Orit Levin; 'Simple WG' Subject: RE: [Simple] MSRP message reliability(long) Hi Ben & Group, By "this" i mean the earlier messages exchanged between me, Mr. Vijay Gurbani, Mr. Hisham and a couple of more participants. Yes i am referring to the delivery reports. =20 Regards, -Vikas -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: vendredi 9 avril 2004 20:10 To: Vikas Tandon Cc: 'Orit Levin'; 'Simple WG' Subject: Re: [Simple] MSRP message reliability(long) Vikas Tandon wrote: > Also as discussed earlier in this forum, this adds a lot of traffic to > the client (specially the wireless mobile clients where the bandwidth=20 > is an issue). If the workgroup plans to make it configurable to set=20 > the delivery response for positive case off, then it has to be=20 > terminated earlier than reaching the wireless medium. E.g. terminate=20 > the positive response at the IM server in case the client has chosen=20 > not to receive the positive acknowledgements of delivery of IM. Hi, could you clarify what "this" refers to in the previous paragraph?=20 Keep in mind that we are really discussion two things: the transaction=20 responses between hops, and the sending of delivery reports. It sounds=20 to me like you are talking delivery reports, but I am not certain. >=20 > If we fail to do this, imagine for every message I'm sending, there is > some traffic I'm getting back to my mobile device (which is painful=20 > because i may be paying by the amount of traffic i transact from my=20 > device). So although it becomes transparent to me from device, by i=20 > still pay for it. The workgroup needs to consider this matter. I=20 > somehow still prefer - "No news is good news". >=20 > Would be good to know more thoughts on this. >=20 > Regards, > Vikas Tandon >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf=20 > Of Ben Campbell > Sent: vendredi 9 avril 2004 19:45 > To: Orit Levin > Cc: Simple WG > Subject: Re: [Simple] MSRP message reliability(long) >=20 >=20 > Orit Levin wrote: >=20 > [...] >=20 >>Why are you opposing to a flexible hop-by-hop mechanism (in addition >>to DSN)? It doesn't necessarily require negotiation - only local=20 >>policy for setting the bit. Let's assume for a moment that a bit per=20 >>message exists saying "response/don't response" to the previous hop. >=20 >=20 > I oppose the ability to select whether you use transaction responses=20 > or > not because it adds a huge amount of complexity to the protocol and any=20 > implementations. Adding or removing transaction responses _completely_ > changes the protocol semantics. In effect, it would be saying we have=20 > two different required protocols with the same syntax on top. If we make >=20 > this selectable, we make every implementer build 2 protocols with > different state machines, etc. I think that will be _much_ more of an=20 > impediment to acceptance than performance differences in the range you > predict. >=20 > My point is, if the working group were to decide we need to be able to > run without transaction responses (a big if) , then we should _always_ > run without transaction responses. As it is, earlier attempts at a=20 > message sessions did not have the transaction response, and the working=20 > group decided to put them it. (Does anyone remember the specific=20 > argument used at that time?) >=20 > But, on all of these points, working group consensus trumps either of > our opinions. Please, anyone who cares one way or another, state your=20 > opinion asap! >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 02:51:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28826 for ; Wed, 21 Apr 2004 02:51:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBa3-0000hK-KW for simple-archive@ietf.org; Wed, 21 Apr 2004 02:51:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBZA-0000bl-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 02:50:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGBYT-0000WG-00; Wed, 21 Apr 2004 02:49:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBSj-0008Iz-Q7; Wed, 21 Apr 2004 02:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBOS-0006xE-C9 for simple@optimus.ietf.org; Wed, 21 Apr 2004 02:39:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27897 for ; Wed, 21 Apr 2004 02:39:33 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBOO-00070F-M3 for simple@ietf.org; Wed, 21 Apr 2004 02:39:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBNR-0006vO-00 for simple@ietf.org; Wed, 21 Apr 2004 02:38:33 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BGBMs-0006qk-00 for simple@ietf.org; Wed, 21 Apr 2004 02:37:58 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L6bsj18081; Wed, 21 Apr 2004 09:37:54 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 09:37:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3L6bbEq024334; Wed, 21 Apr 2004 09:37:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00Tg3XzR; Wed, 21 Apr 2004 09:37:36 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L6bPs01234; Wed, 21 Apr 2004 09:37:25 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 09:36:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Details Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797952@esebe019.ntc.nokia.com> Thread-Topic: MSRP Details Thread-Index: AcQm5YWjgVaLAGZjQjuvnCrZqb8mXQAhTBcQ To: , Cc: X-OriginalArrivalTime: 21 Apr 2004 06:36:47.0914 (UTC) FILETIME=[056BA0A0:01C4276B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 09:36:47 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Is the REPORT method part of MSRP? If yes, then what is wrong with using = the status-code as is currently defined in MSRP draft? Status-Code =3D 200 ;Success / 400 ;Bad Request / 403 ;Forbidden / 415 ;Unsupported Content Type / 426 ;Upgrade Required / 481 ;No session / 506 ;duplicate session I don't think you need to define your own for DSN here. Thanks, Hisham -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of = ext Chris Boulton Sent: 20.April.2004 17:41 To: simple@ietf.org Cc: Ben Campbell Subject: [Simple] MSRP Details Hi to all on the list, I've got a question that I wouldn't mind some = input + closure on. I am currently completing the DSN details for MSRP = reports and in RFC 1894 - It specifies that the format for 'status' code = in a DSN message is:- status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT This does not map exactly to an MSRP status code and I was trying to = look at the best solution - does anyone have any input? Should we spread the status code e.g. 200 =3D 2.0.0 OR Use the last 3 digit field e.g. 0.0.200 I would appreciate some input. Best Regards, Chris Boulton. ------------------------------------------------ Chris Boulton Ubiquity Software Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ This message has been scanned for viruses by MailControl, a service from = BlackSpider Technologies. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 03:05:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29411 for ; Wed, 21 Apr 2004 03:05:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBlO-0007iY-TT for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 03:03:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L73Ip6029664 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 03:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBa7-0003fL-Uc for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 02:51:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28843 for ; Wed, 21 Apr 2004 02:51:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBa4-0000hP-6b for simple-web-archive@ietf.org; Wed, 21 Apr 2004 02:51:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBZB-0000bs-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 02:50:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGBYT-0000WG-00; Wed, 21 Apr 2004 02:49:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBSj-0008Iz-Q7; Wed, 21 Apr 2004 02:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBOS-0006xE-C9 for simple@optimus.ietf.org; Wed, 21 Apr 2004 02:39:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27897 for ; Wed, 21 Apr 2004 02:39:33 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBOO-00070F-M3 for simple@ietf.org; Wed, 21 Apr 2004 02:39:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBNR-0006vO-00 for simple@ietf.org; Wed, 21 Apr 2004 02:38:33 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BGBMs-0006qk-00 for simple@ietf.org; Wed, 21 Apr 2004 02:37:58 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L6bsj18081; Wed, 21 Apr 2004 09:37:54 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 09:37:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3L6bbEq024334; Wed, 21 Apr 2004 09:37:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00Tg3XzR; Wed, 21 Apr 2004 09:37:36 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L6bPs01234; Wed, 21 Apr 2004 09:37:25 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 09:36:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Details Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797952@esebe019.ntc.nokia.com> Thread-Topic: MSRP Details Thread-Index: AcQm5YWjgVaLAGZjQjuvnCrZqb8mXQAhTBcQ To: , Cc: X-OriginalArrivalTime: 21 Apr 2004 06:36:47.0914 (UTC) FILETIME=[056BA0A0:01C4276B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 09:36:47 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Is the REPORT method part of MSRP? If yes, then what is wrong with using = the status-code as is currently defined in MSRP draft? Status-Code =3D 200 ;Success / 400 ;Bad Request / 403 ;Forbidden / 415 ;Unsupported Content Type / 426 ;Upgrade Required / 481 ;No session / 506 ;duplicate session I don't think you need to define your own for DSN here. Thanks, Hisham -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of = ext Chris Boulton Sent: 20.April.2004 17:41 To: simple@ietf.org Cc: Ben Campbell Subject: [Simple] MSRP Details Hi to all on the list, I've got a question that I wouldn't mind some = input + closure on. I am currently completing the DSN details for MSRP = reports and in RFC 1894 - It specifies that the format for 'status' code = in a DSN message is:- status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT This does not map exactly to an MSRP status code and I was trying to = look at the best solution - does anyone have any input? Should we spread the status code e.g. 200 =3D 2.0.0 OR Use the last 3 digit field e.g. 0.0.200 I would appreciate some input. Best Regards, Chris Boulton. ------------------------------------------------ Chris Boulton Ubiquity Software Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ This message has been scanned for viruses by MailControl, a service from = BlackSpider Technologies. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 03:14:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29819 for ; Wed, 21 Apr 2004 03:14:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBwQ-00030v-Ej for simple-archive@ietf.org; Wed, 21 Apr 2004 03:14:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBvg-0002uR-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 03:13:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGBun-0002nN-00; Wed, 21 Apr 2004 03:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBm4-000882-L7; Wed, 21 Apr 2004 03:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBa6-0003fJ-RK for simple@optimus.ietf.org; Wed, 21 Apr 2004 02:51:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28823 for ; Wed, 21 Apr 2004 02:51:35 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBa2-0000hF-W4 for simple@ietf.org; Wed, 21 Apr 2004 02:51:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBZ9-0000bc-00 for simple@ietf.org; Wed, 21 Apr 2004 02:50:40 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGBYS-0000WE-00 for simple@ietf.org; Wed, 21 Apr 2004 02:49:56 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L6nqm07835; Wed, 21 Apr 2004 09:49:52 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 09:48:40 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3L6meJ3014325; Wed, 21 Apr 2004 09:48:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00yYFKDO; Wed, 21 Apr 2004 09:48:38 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L6mSs08280; Wed, 21 Apr 2004 09:48:28 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 09:48:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797953@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQevzmYZiEaOXSARYiJXxgqQGDR3AIeJonQAAz73cA= To: , Cc: , X-OriginalArrivalTime: 21 Apr 2004 06:48:03.0377 (UTC) FILETIME=[98071A10:01C4276C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 09:48:03 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Orit, One message (the 200 ok for SEND) is hardly a problem to the air = interface, which is between the terminal and the first relay only. Can = you elaborate on why it is a problem? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Orit Levin > Sent: 21.April.2004 03:38 > To: Vikas Tandon > Cc: Simple WG; Ben Campbell > Subject: RE: [Simple] MSRP message reliability(long) >=20 >=20 > Hi Vicas, > I understand that you don't see a problem in unconditionally sending a > (hop-by-hop) response to every message (regardless the end-to-end mode > being used). If my understanding is correct, how are you planning to > address the wireless bandwidth problem in this case? >=20 > Thanks, > Orit. >=20 > -----Original Message----- > From: Vikas Tandon [mailto:vikas@arciis.com]=20 > Sent: Friday, April 09, 2004 10:47 PM > To: 'Ben Campbell' > Cc: Orit Levin; 'Simple WG' > Subject: RE: [Simple] MSRP message reliability(long) >=20 > Hi Ben & Group, > By "this" i mean the earlier messages exchanged between me, Mr. Vijay > Gurbani, Mr. Hisham and a couple of more participants. Yes i am > referring to the delivery reports. =20 > Regards, > -Vikas >=20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: vendredi 9 avril 2004 20:10 > To: Vikas Tandon > Cc: 'Orit Levin'; 'Simple WG' > Subject: Re: [Simple] MSRP message reliability(long) >=20 >=20 > Vikas Tandon wrote: >=20 > > Also as discussed earlier in this forum, this adds a lot of=20 > traffic to >=20 > > the client (specially the wireless mobile clients where the=20 > bandwidth=20 > > is an issue). If the workgroup plans to make it configurable to set=20 > > the delivery response for positive case off, then it has to be=20 > > terminated earlier than reaching the wireless medium. E.g.=20 > terminate=20 > > the positive response at the IM server in case the client=20 > has chosen=20 > > not to receive the positive acknowledgements of delivery of IM. >=20 > Hi, could you clarify what "this" refers to in the previous=20 > paragraph?=20 > Keep in mind that we are really discussion two things: the=20 > transaction=20 > responses between hops, and the sending of delivery reports.=20 > It sounds=20 > to me like you are talking delivery reports, but I am not certain. >=20 > >=20 > > If we fail to do this, imagine for every message I'm=20 > sending, there is >=20 > > some traffic I'm getting back to my mobile device (which is painful=20 > > because i may be paying by the amount of traffic i transact from my=20 > > device). So although it becomes transparent to me from device, by i=20 > > still pay for it. The workgroup needs to consider this matter. I=20 > > somehow still prefer - "No news is good news". > >=20 > > Would be good to know more thoughts on this. > >=20 > > Regards, > > Vikas Tandon > >=20 > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]=20 > On Behalf=20 > > Of Ben Campbell > > Sent: vendredi 9 avril 2004 19:45 > > To: Orit Levin > > Cc: Simple WG > > Subject: Re: [Simple] MSRP message reliability(long) > >=20 > >=20 > > Orit Levin wrote: > >=20 > > [...] > >=20 > >>Why are you opposing to a flexible hop-by-hop mechanism (in addition > >>to DSN)? It doesn't necessarily require negotiation - only local=20 > >>policy for setting the bit. Let's assume for a moment that=20 > a bit per=20 > >>message exists saying "response/don't response" to the previous hop. > >=20 > >=20 > > I oppose the ability to select whether you use transaction=20 > responses=20 > > or > > not because it adds a huge amount of complexity to the protocol and > any=20 > > implementations. Adding or removing transaction responses=20 > _completely_ >=20 > > changes the protocol semantics. In effect, it would be=20 > saying we have=20 > > two different required protocols with the same syntax on top. If we > make > >=20 > > this selectable, we make every implementer build 2 protocols with > > different state machines, etc. I think that will be _much_=20 > more of an=20 > > impediment to acceptance than performance differences in=20 > the range you >=20 > > predict. > >=20 > > My point is, if the working group were to decide we need to=20 > be able to > > run without transaction responses (a big if) , then we=20 > should _always_ >=20 > > run without transaction responses. As it is, earlier attempts at a=20 > > message sessions did not have the transaction response, and the > working=20 > > group decided to put them it. (Does anyone remember the specific=20 > > argument used at that time?) > >=20 > > But, on all of these points, working group consensus trumps=20 > either of > > our opinions. Please, anyone who cares one way or another,=20 > state your=20 > > opinion asap! > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 03:28:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00340 for ; Wed, 21 Apr 2004 03:28:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBzQ-0005vp-HS for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 03:17:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L7Hmte022785 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 03:17:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBwT-0004C7-He for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 03:14:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29837 for ; Wed, 21 Apr 2004 03:14:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBwR-000310-Dz for simple-web-archive@ietf.org; Wed, 21 Apr 2004 03:14:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBvh-0002uY-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 03:13:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGBun-0002nN-00; Wed, 21 Apr 2004 03:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBm4-000882-L7; Wed, 21 Apr 2004 03:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBa6-0003fJ-RK for simple@optimus.ietf.org; Wed, 21 Apr 2004 02:51:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28823 for ; Wed, 21 Apr 2004 02:51:35 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBa2-0000hF-W4 for simple@ietf.org; Wed, 21 Apr 2004 02:51:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBZ9-0000bc-00 for simple@ietf.org; Wed, 21 Apr 2004 02:50:40 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGBYS-0000WE-00 for simple@ietf.org; Wed, 21 Apr 2004 02:49:56 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L6nqm07835; Wed, 21 Apr 2004 09:49:52 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 09:48:40 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3L6meJ3014325; Wed, 21 Apr 2004 09:48:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00yYFKDO; Wed, 21 Apr 2004 09:48:38 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L6mSs08280; Wed, 21 Apr 2004 09:48:28 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 09:48:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797953@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP message reliability(long) Thread-Index: AcQevzmYZiEaOXSARYiJXxgqQGDR3AIeJonQAAz73cA= To: , Cc: , X-OriginalArrivalTime: 21 Apr 2004 06:48:03.0377 (UTC) FILETIME=[98071A10:01C4276C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 09:48:03 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Orit, One message (the 200 ok for SEND) is hardly a problem to the air = interface, which is between the terminal and the first relay only. Can = you elaborate on why it is a problem? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Orit Levin > Sent: 21.April.2004 03:38 > To: Vikas Tandon > Cc: Simple WG; Ben Campbell > Subject: RE: [Simple] MSRP message reliability(long) >=20 >=20 > Hi Vicas, > I understand that you don't see a problem in unconditionally sending a > (hop-by-hop) response to every message (regardless the end-to-end mode > being used). If my understanding is correct, how are you planning to > address the wireless bandwidth problem in this case? >=20 > Thanks, > Orit. >=20 > -----Original Message----- > From: Vikas Tandon [mailto:vikas@arciis.com]=20 > Sent: Friday, April 09, 2004 10:47 PM > To: 'Ben Campbell' > Cc: Orit Levin; 'Simple WG' > Subject: RE: [Simple] MSRP message reliability(long) >=20 > Hi Ben & Group, > By "this" i mean the earlier messages exchanged between me, Mr. Vijay > Gurbani, Mr. Hisham and a couple of more participants. Yes i am > referring to the delivery reports. =20 > Regards, > -Vikas >=20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: vendredi 9 avril 2004 20:10 > To: Vikas Tandon > Cc: 'Orit Levin'; 'Simple WG' > Subject: Re: [Simple] MSRP message reliability(long) >=20 >=20 > Vikas Tandon wrote: >=20 > > Also as discussed earlier in this forum, this adds a lot of=20 > traffic to >=20 > > the client (specially the wireless mobile clients where the=20 > bandwidth=20 > > is an issue). If the workgroup plans to make it configurable to set=20 > > the delivery response for positive case off, then it has to be=20 > > terminated earlier than reaching the wireless medium. E.g.=20 > terminate=20 > > the positive response at the IM server in case the client=20 > has chosen=20 > > not to receive the positive acknowledgements of delivery of IM. >=20 > Hi, could you clarify what "this" refers to in the previous=20 > paragraph?=20 > Keep in mind that we are really discussion two things: the=20 > transaction=20 > responses between hops, and the sending of delivery reports.=20 > It sounds=20 > to me like you are talking delivery reports, but I am not certain. >=20 > >=20 > > If we fail to do this, imagine for every message I'm=20 > sending, there is >=20 > > some traffic I'm getting back to my mobile device (which is painful=20 > > because i may be paying by the amount of traffic i transact from my=20 > > device). So although it becomes transparent to me from device, by i=20 > > still pay for it. The workgroup needs to consider this matter. I=20 > > somehow still prefer - "No news is good news". > >=20 > > Would be good to know more thoughts on this. > >=20 > > Regards, > > Vikas Tandon > >=20 > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]=20 > On Behalf=20 > > Of Ben Campbell > > Sent: vendredi 9 avril 2004 19:45 > > To: Orit Levin > > Cc: Simple WG > > Subject: Re: [Simple] MSRP message reliability(long) > >=20 > >=20 > > Orit Levin wrote: > >=20 > > [...] > >=20 > >>Why are you opposing to a flexible hop-by-hop mechanism (in addition > >>to DSN)? It doesn't necessarily require negotiation - only local=20 > >>policy for setting the bit. Let's assume for a moment that=20 > a bit per=20 > >>message exists saying "response/don't response" to the previous hop. > >=20 > >=20 > > I oppose the ability to select whether you use transaction=20 > responses=20 > > or > > not because it adds a huge amount of complexity to the protocol and > any=20 > > implementations. Adding or removing transaction responses=20 > _completely_ >=20 > > changes the protocol semantics. In effect, it would be=20 > saying we have=20 > > two different required protocols with the same syntax on top. If we > make > >=20 > > this selectable, we make every implementer build 2 protocols with > > different state machines, etc. I think that will be _much_=20 > more of an=20 > > impediment to acceptance than performance differences in=20 > the range you >=20 > > predict. > >=20 > > My point is, if the working group were to decide we need to=20 > be able to > > run without transaction responses (a big if) , then we=20 > should _always_ >=20 > > run without transaction responses. As it is, earlier attempts at a=20 > > message sessions did not have the transaction response, and the > working=20 > > group decided to put them it. (Does anyone remember the specific=20 > > argument used at that time?) > >=20 > > But, on all of these points, working group consensus trumps=20 > either of > > our opinions. Please, anyone who cares one way or another,=20 > state your=20 > > opinion asap! > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 03:29:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00463 for ; Wed, 21 Apr 2004 03:29:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCAk-0004VI-Mi for simple-archive@ietf.org; Wed, 21 Apr 2004 03:29:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGC9n-0004Nr-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 03:28:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGC8p-0004Fi-00; Wed, 21 Apr 2004 03:27:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGByi-0005dA-U1; Wed, 21 Apr 2004 03:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBuZ-0003Y5-Mb for simple@optimus.ietf.org; Wed, 21 Apr 2004 03:12:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29699 for ; Wed, 21 Apr 2004 03:12:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBuX-0002mJ-HB for simple@ietf.org; Wed, 21 Apr 2004 03:12:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBtV-0002ft-00 for simple@ietf.org; Wed, 21 Apr 2004 03:11:42 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BGBsp-0002Y9-00 for simple@ietf.org; Wed, 21 Apr 2004 03:11:00 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with SMTP id i3L7AMOl019368; Wed, 21 Apr 2004 08:10:22 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Wed, 21 Apr 2004 08:10:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Details Message-ID: <45730E094814E44488F789C1CDED27AE0219B270@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP Details Thread-Index: AcQm5YWjgVaLAGZjQjuvnCrZqb8mXQAhTBcQAAEckTA= From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 08:10:22 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hisham - these are the codes that I want to represent in the DSN payload of a REPORT method. But the format of the status field in RFC 1894 is:- status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT e.g. 2.1.2 So the question was - How is best to represent this code in the DSN payload, as per RFC 1894. Should we spread the status code e.g. 200 =3D 2.0.0 OR Use the last 3 digit field e.g. 0.0.200 OR=20 Some other suggestion. Regards, Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 21 April 2004 07:37 >To: Chris Boulton; simple@ietf.org >Cc: bcampbell@dynamicsoft.com >Subject: RE: [Simple] MSRP Details > >Is the REPORT method part of MSRP? If yes, then what is wrong with using >the status-code as is currently defined in MSRP draft? > >Status-Code =3D 200 ;Success > / 400 ;Bad Request > / 403 ;Forbidden > / 415 ;Unsupported Content Type > / 426 ;Upgrade Required > / 481 ;No session > / 506 ;duplicate session > >I don't think you need to define your own for DSN here. > >Thanks, >Hisham > > >-----Original Message----- >From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of ext >Chris Boulton >Sent: 20.April.2004 17:41 >To: simple@ietf.org >Cc: Ben Campbell >Subject: [Simple] MSRP Details > > >Hi to all on the list, > > I've got a question that I wouldn't mind some input >+ closure on. I am currently completing the DSN details for MSRP reports >and in RFC 1894 - It specifies that the format for 'status' code in a DSN >message is:- > >status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT > >This does not map exactly to an MSRP status code and I was trying to look >at the best solution - does anyone have any input? > >Should we spread the status code e.g. 200 =3D 2.0.0 > >OR > >Use the last 3 digit field e.g. 0.0.200 > >I would appreciate some input. > >Best Regards, > >Chris Boulton. > > >------------------------------------------------ >Chris Boulton >Ubiquity Software > >Tel : +44 (0) 1633765600 >Fax : +44 (0) 1633765601 >------------------------------------------------ > > > > > > >This message has been scanned for viruses by MailControl, a service from >BlackSpider Technologies. This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 03:35:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00920 for ; Wed, 21 Apr 2004 03:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCFf-0003zw-51 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 03:34:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L7YZ8c015368 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 03:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCAn-0001yx-JC for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 03:29:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00481 for ; Wed, 21 Apr 2004 03:29:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCAl-0004VN-8t for simple-web-archive@ietf.org; Wed, 21 Apr 2004 03:29:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGC9o-0004Ny-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 03:28:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGC8p-0004Fi-00; Wed, 21 Apr 2004 03:27:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGByi-0005dA-U1; Wed, 21 Apr 2004 03:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBuZ-0003Y5-Mb for simple@optimus.ietf.org; Wed, 21 Apr 2004 03:12:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29699 for ; Wed, 21 Apr 2004 03:12:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBuX-0002mJ-HB for simple@ietf.org; Wed, 21 Apr 2004 03:12:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBtV-0002ft-00 for simple@ietf.org; Wed, 21 Apr 2004 03:11:42 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly11b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BGBsp-0002Y9-00 for simple@ietf.org; Wed, 21 Apr 2004 03:11:00 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly11b.srv.mailcontrol.com (MailControl) with SMTP id i3L7AMOl019368; Wed, 21 Apr 2004 08:10:22 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Wed, 21 Apr 2004 08:10:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Details Message-ID: <45730E094814E44488F789C1CDED27AE0219B270@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP Details Thread-Index: AcQm5YWjgVaLAGZjQjuvnCrZqb8mXQAhTBcQAAEckTA= From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 08:10:22 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hisham - these are the codes that I want to represent in the DSN payload of a REPORT method. But the format of the status field in RFC 1894 is:- status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT e.g. 2.1.2 So the question was - How is best to represent this code in the DSN payload, as per RFC 1894. Should we spread the status code e.g. 200 =3D 2.0.0 OR Use the last 3 digit field e.g. 0.0.200 OR=20 Some other suggestion. Regards, Chris. >-----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 21 April 2004 07:37 >To: Chris Boulton; simple@ietf.org >Cc: bcampbell@dynamicsoft.com >Subject: RE: [Simple] MSRP Details > >Is the REPORT method part of MSRP? If yes, then what is wrong with using >the status-code as is currently defined in MSRP draft? > >Status-Code =3D 200 ;Success > / 400 ;Bad Request > / 403 ;Forbidden > / 415 ;Unsupported Content Type > / 426 ;Upgrade Required > / 481 ;No session > / 506 ;duplicate session > >I don't think you need to define your own for DSN here. > >Thanks, >Hisham > > >-----Original Message----- >From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of ext >Chris Boulton >Sent: 20.April.2004 17:41 >To: simple@ietf.org >Cc: Ben Campbell >Subject: [Simple] MSRP Details > > >Hi to all on the list, > > I've got a question that I wouldn't mind some input >+ closure on. I am currently completing the DSN details for MSRP reports >and in RFC 1894 - It specifies that the format for 'status' code in a DSN >message is:- > >status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT > >This does not map exactly to an MSRP status code and I was trying to look >at the best solution - does anyone have any input? > >Should we spread the status code e.g. 200 =3D 2.0.0 > >OR > >Use the last 3 digit field e.g. 0.0.200 > >I would appreciate some input. > >Best Regards, > >Chris Boulton. > > >------------------------------------------------ >Chris Boulton >Ubiquity Software > >Tel : +44 (0) 1633765600 >Fax : +44 (0) 1633765601 >------------------------------------------------ > > > > > > >This message has been scanned for viruses by MailControl, a service from >BlackSpider Technologies. This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 03:40:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01301 for ; Wed, 21 Apr 2004 03:40:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCKu-0005oR-W3 for simple-archive@ietf.org; Wed, 21 Apr 2004 03:40:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCK7-0005gi-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 03:39:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGCJ3-0005WJ-00; Wed, 21 Apr 2004 03:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCG9-0004RF-QR; Wed, 21 Apr 2004 03:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCF0-0003mY-VJ for simple@optimus.ietf.org; Wed, 21 Apr 2004 03:33:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00864 for ; Wed, 21 Apr 2004 03:33:53 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCEy-00050n-MT for simple@ietf.org; Wed, 21 Apr 2004 03:33:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCE5-0004sq-00 for simple@ietf.org; Wed, 21 Apr 2004 03:32:58 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGCD8-0004kO-00 for simple@ietf.org; Wed, 21 Apr 2004 03:31:58 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L7Vrm26443; Wed, 21 Apr 2004 10:31:53 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 10:31:32 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3L7VWQV014357; Wed, 21 Apr 2004 10:31:32 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00dlGk3z; Wed, 21 Apr 2004 10:31:30 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L7Uks02648; Wed, 21 Apr 2004 10:30:51 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 10:27:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 10:27:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Details Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797955@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP Details Thread-Index: AcQm5YWjgVaLAGZjQjuvnCrZqb8mXQAhTBcQAAEckTAAAKuJUA== To: , Cc: X-OriginalArrivalTime: 21 Apr 2004 07:27:14.0721 (UTC) FILETIME=[1189B910:01C42772] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 10:27:14 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ok, sorry I misinterpreted what you were asking. I would vote for 2.0.0 style. It is more appropriate and fits what RFC = 1894 is trying to do, IMHO. Thanks, Hisham > -----Original Message----- > From: ext Chris Boulton [mailto:cboulton@ubiquity.com] > Sent: 21.April.2004 10:10 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Cc: bcampbell@dynamicsoft.com > Subject: RE: [Simple] MSRP Details >=20 >=20 >=20 > Hisham - these are the codes that I want to represent in the=20 > DSN payload > of a REPORT method. But the format of the status field in=20 > RFC 1894 is:- >=20 > status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT >=20 > e.g. 2.1.2 >=20 > So the question was - How is best to represent this code in the DSN > payload, as per RFC 1894. >=20 > Should we spread the status code e.g. 200 =3D 2.0.0 >=20 > OR >=20 > Use the last 3 digit field e.g. 0.0.200 >=20 > OR=20 >=20 > Some other suggestion. >=20 > Regards, >=20 > Chris. >=20 >=20 > >-----Original Message----- > >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >Sent: 21 April 2004 07:37 > >To: Chris Boulton; simple@ietf.org > >Cc: bcampbell@dynamicsoft.com > >Subject: RE: [Simple] MSRP Details > > > >Is the REPORT method part of MSRP? If yes, then what is wrong with > using > >the status-code as is currently defined in MSRP draft? > > > >Status-Code =3D 200 ;Success > > / 400 ;Bad Request > > / 403 ;Forbidden > > / 415 ;Unsupported Content Type > > / 426 ;Upgrade Required > > / 481 ;No session > > / 506 ;duplicate session > > > >I don't think you need to define your own for DSN here. > > > >Thanks, > >Hisham > > > > > >-----Original Message----- > >From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > Behalf Of > ext > >Chris Boulton > >Sent: 20.April.2004 17:41 > >To: simple@ietf.org > >Cc: Ben Campbell > >Subject: [Simple] MSRP Details > > > > > >Hi to all on the list, > > > > I've got a question that I wouldn't mind some > input > >+ closure on. I am currently completing the DSN details for MSRP > reports > >and in RFC 1894 - It specifies that the format for 'status' code in a > DSN > >message is:- > > > >status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT > > > >This does not map exactly to an MSRP status code and I was trying to > look > >at the best solution - does anyone have any input? > > > >Should we spread the status code e.g. 200 =3D 2.0.0 > > > >OR > > > >Use the last 3 digit field e.g. 0.0.200 > > > >I would appreciate some input. > > > >Best Regards, > > > >Chris Boulton. > > > > > >------------------------------------------------ > >Chris Boulton > >Ubiquity Software > > > >Tel : +44 (0) 1633765600 > >Fax : +44 (0) 1633765601 > >------------------------------------------------ > > > > > > > > > > > > > >This message has been scanned for viruses by MailControl, a service > from > >BlackSpider Technologies. >=20 >=20 > This message has been scanned for viruses by MailControl -=20 www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 03:52:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01656 for ; Wed, 21 Apr 2004 03:52:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCSV-0000rL-Hr for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 03:47:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L7lpg8003287 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 03:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCKy-0006Pf-0i for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 03:40:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01319 for ; Wed, 21 Apr 2004 03:40:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCKv-0005oW-Lp for simple-web-archive@ietf.org; Wed, 21 Apr 2004 03:40:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCK8-0005gp-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 03:39:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGCJ3-0005WJ-00; Wed, 21 Apr 2004 03:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCG9-0004RF-QR; Wed, 21 Apr 2004 03:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCF0-0003mY-VJ for simple@optimus.ietf.org; Wed, 21 Apr 2004 03:33:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00864 for ; Wed, 21 Apr 2004 03:33:53 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCEy-00050n-MT for simple@ietf.org; Wed, 21 Apr 2004 03:33:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCE5-0004sq-00 for simple@ietf.org; Wed, 21 Apr 2004 03:32:58 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGCD8-0004kO-00 for simple@ietf.org; Wed, 21 Apr 2004 03:31:58 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L7Vrm26443; Wed, 21 Apr 2004 10:31:53 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 10:31:32 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3L7VWQV014357; Wed, 21 Apr 2004 10:31:32 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00dlGk3z; Wed, 21 Apr 2004 10:31:30 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L7Uks02648; Wed, 21 Apr 2004 10:30:51 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 10:27:16 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 10:27:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Details Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797955@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP Details Thread-Index: AcQm5YWjgVaLAGZjQjuvnCrZqb8mXQAhTBcQAAEckTAAAKuJUA== To: , Cc: X-OriginalArrivalTime: 21 Apr 2004 07:27:14.0721 (UTC) FILETIME=[1189B910:01C42772] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 10:27:14 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ok, sorry I misinterpreted what you were asking. I would vote for 2.0.0 style. It is more appropriate and fits what RFC = 1894 is trying to do, IMHO. Thanks, Hisham > -----Original Message----- > From: ext Chris Boulton [mailto:cboulton@ubiquity.com] > Sent: 21.April.2004 10:10 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > Cc: bcampbell@dynamicsoft.com > Subject: RE: [Simple] MSRP Details >=20 >=20 >=20 > Hisham - these are the codes that I want to represent in the=20 > DSN payload > of a REPORT method. But the format of the status field in=20 > RFC 1894 is:- >=20 > status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT >=20 > e.g. 2.1.2 >=20 > So the question was - How is best to represent this code in the DSN > payload, as per RFC 1894. >=20 > Should we spread the status code e.g. 200 =3D 2.0.0 >=20 > OR >=20 > Use the last 3 digit field e.g. 0.0.200 >=20 > OR=20 >=20 > Some other suggestion. >=20 > Regards, >=20 > Chris. >=20 >=20 > >-----Original Message----- > >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >Sent: 21 April 2004 07:37 > >To: Chris Boulton; simple@ietf.org > >Cc: bcampbell@dynamicsoft.com > >Subject: RE: [Simple] MSRP Details > > > >Is the REPORT method part of MSRP? If yes, then what is wrong with > using > >the status-code as is currently defined in MSRP draft? > > > >Status-Code =3D 200 ;Success > > / 400 ;Bad Request > > / 403 ;Forbidden > > / 415 ;Unsupported Content Type > > / 426 ;Upgrade Required > > / 481 ;No session > > / 506 ;duplicate session > > > >I don't think you need to define your own for DSN here. > > > >Thanks, > >Hisham > > > > > >-----Original Message----- > >From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > Behalf Of > ext > >Chris Boulton > >Sent: 20.April.2004 17:41 > >To: simple@ietf.org > >Cc: Ben Campbell > >Subject: [Simple] MSRP Details > > > > > >Hi to all on the list, > > > > I've got a question that I wouldn't mind some > input > >+ closure on. I am currently completing the DSN details for MSRP > reports > >and in RFC 1894 - It specifies that the format for 'status' code in a > DSN > >message is:- > > > >status-code =3D DIGIT "." 1*3DIGIT "." 1*3DIGIT > > > >This does not map exactly to an MSRP status code and I was trying to > look > >at the best solution - does anyone have any input? > > > >Should we spread the status code e.g. 200 =3D 2.0.0 > > > >OR > > > >Use the last 3 digit field e.g. 0.0.200 > > > >I would appreciate some input. > > > >Best Regards, > > > >Chris Boulton. > > > > > >------------------------------------------------ > >Chris Boulton > >Ubiquity Software > > > >Tel : +44 (0) 1633765600 > >Fax : +44 (0) 1633765601 > >------------------------------------------------ > > > > > > > > > > > > > >This message has been scanned for viruses by MailControl, a service > from > >BlackSpider Technologies. >=20 >=20 > This message has been scanned for viruses by MailControl -=20 www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 05:20:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05929 for ; Wed, 21 Apr 2004 05:20:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGDuS-0001eD-WA for simple-archive@ietf.org; Wed, 21 Apr 2004 05:20:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGDtS-0001VF-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 05:19:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGDsX-0001OH-00; Wed, 21 Apr 2004 05:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDkz-00084f-JX; Wed, 21 Apr 2004 05:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDe0-0004ho-PY for simple@optimus.ietf.org; Wed, 21 Apr 2004 05:03:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05262 for ; Wed, 21 Apr 2004 05:03:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGDdx-0007Sj-Je for simple@ietf.org; Wed, 21 Apr 2004 05:03:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGDd3-0007Ll-00 for simple@ietf.org; Wed, 21 Apr 2004 05:02:50 -0400 Received: from [200.45.191.180] (helo=smtp-mx-01.ti.local) by ietf-mx with esmtp (Exim 4.12) id 1BGDcb-0006jJ-00; Wed, 21 Apr 2004 05:02:21 -0400 Received: from MSG-BE-02.ti.local ([192.168.220.105]) by smtp-mx-01.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Apr 2004 05:57:07 -0300 Received: from mail pickup service by MSG-BE-02.ti.local with Microsoft SMTPSVC; Wed, 21 Apr 2004 05:57:07 -0300 Received: from smtp-mx-04.ti.local ([192.168.220.23]) by MSG-BE-02.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 18:24:13 -0300 Received: from qsmtp-mx-02.arnet.com.ar ([200.45.191.165]) by smtp-mx-04.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 18:24:13 -0300 Received: from unknown (HELO optimus.ietf.org) (132.151.6.22) by host191165.arnet.net.ar with SMTP; 20 Apr 2004 21:23:03 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1UR-0002fB-PB; Tue, 20 Apr 2004 16:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1I5-0006EI-Kj for i-d-announce@optimus.ietf.org; Tue, 20 Apr 2004 15:52:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18287; Tue, 20 Apr 2004 15:52:19 -0400 (EDT) Message-Id: <200404201952.PAA18287@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org X-OriginalArrivalTime: 20 Apr 2004 21:24:13.0077 (UTC) FILETIME=[D398FC50:01C4271D] Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 15:52:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-01.txt Pages : 14 Date : 2004-4-20 The presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-20160929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160929.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 05:24:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06218 for ; Wed, 21 Apr 2004 05:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDvb-0003GA-Ut for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 05:21:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L9Lx26012526 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 05:21:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDuW-0002dj-VM for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 05:20:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05947 for ; Wed, 21 Apr 2004 05:20:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGDuT-0001eI-N2 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 05:20:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGDtT-0001VM-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 05:19:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGDsX-0001OH-00; Wed, 21 Apr 2004 05:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDkz-00084f-JX; Wed, 21 Apr 2004 05:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGDe0-0004ho-PY for simple@optimus.ietf.org; Wed, 21 Apr 2004 05:03:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05262 for ; Wed, 21 Apr 2004 05:03:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGDdx-0007Sj-Je for simple@ietf.org; Wed, 21 Apr 2004 05:03:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGDd3-0007Ll-00 for simple@ietf.org; Wed, 21 Apr 2004 05:02:50 -0400 Received: from [200.45.191.180] (helo=smtp-mx-01.ti.local) by ietf-mx with esmtp (Exim 4.12) id 1BGDcb-0006jJ-00; Wed, 21 Apr 2004 05:02:21 -0400 Received: from MSG-BE-02.ti.local ([192.168.220.105]) by smtp-mx-01.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Apr 2004 05:57:07 -0300 Received: from mail pickup service by MSG-BE-02.ti.local with Microsoft SMTPSVC; Wed, 21 Apr 2004 05:57:07 -0300 Received: from smtp-mx-04.ti.local ([192.168.220.23]) by MSG-BE-02.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 18:24:13 -0300 Received: from qsmtp-mx-02.arnet.com.ar ([200.45.191.165]) by smtp-mx-04.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 18:24:13 -0300 Received: from unknown (HELO optimus.ietf.org) (132.151.6.22) by host191165.arnet.net.ar with SMTP; 20 Apr 2004 21:23:03 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1UR-0002fB-PB; Tue, 20 Apr 2004 16:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1I5-0006EI-Kj for i-d-announce@optimus.ietf.org; Tue, 20 Apr 2004 15:52:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18287; Tue, 20 Apr 2004 15:52:19 -0400 (EDT) Message-Id: <200404201952.PAA18287@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: simple@ietf.org From: Internet-Drafts@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org X-OriginalArrivalTime: 20 Apr 2004 21:24:13.0077 (UTC) FILETIME=[D398FC50:01C4271D] Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 15:52:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-01.txt Pages : 14 Date : 2004-4-20 The presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-20160929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160929.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 06:07:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08474 for ; Wed, 21 Apr 2004 06:07:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGEdq-0007iS-I6 for simple-archive@ietf.org; Wed, 21 Apr 2004 06:07:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGEcv-0007ah-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 06:06:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGEc7-0007Sn-00; Wed, 21 Apr 2004 06:05:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEYL-0000PY-Au; Wed, 21 Apr 2004 06:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGETA-00077X-L5 for simple@optimus.ietf.org; Wed, 21 Apr 2004 05:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07919 for ; Wed, 21 Apr 2004 05:56:36 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGET7-0006K8-0N for simple@ietf.org; Wed, 21 Apr 2004 05:56:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGESB-0006Di-00 for simple@ietf.org; Wed, 21 Apr 2004 05:55:39 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGERS-00067x-00 for simple@ietf.org; Wed, 21 Apr 2004 05:54:54 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L9ssP15547 for ; Wed, 21 Apr 2004 12:54:54 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 12:54:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3L9sZbN003252 for ; Wed, 21 Apr 2004 12:54:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00PE4msT; Wed, 21 Apr 2004 12:54:34 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L9sSs28386 for ; Wed, 21 Apr 2004 12:54:28 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 12:52:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE64@esebe004.ntc.nokia.com> Thread-Topic: Open issues and changes to prescaps Thread-Index: AcQnhl6CB6fHHHY+SBy4y+j88Sx6Cg== To: X-OriginalArrivalTime: 21 Apr 2004 09:52:34.0532 (UTC) FILETIME=[5EF34A40:01C42786] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Open issues and changes to prescaps Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 12:52:34 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Here is a list of open issues and changes that were agreed in Seoul. If I have missed something please let me know. We should get consensus on open issue(s) quite soon (hopefully within a week or so).=20 Open issues: - Extension mechanism. Currently draft contains two extension mechanisms. One is XML extension mechanism (mechanism 1) and the other one is based on XML elements token, string, boolean, and numeric which allow usage of other tags that are not specified in callee caps (mechanism 2). We have had some list discussion about this topic and below I try summarize discussion so far: Arguments for having mechanism 2 have been that for some applications it might be easier to use. Using this mechanism applications would not need to define new XML namespaces for every new attribute. For applications which can 'dynamically' use or come up with new attributes this mechanism would be good. Argument for having only XML extension mechanism have been that for having two extension mechanisms may lead to some inconsistencies like same extension attribute could be applied using both mechanisms simultaneously. It has also being argued that applications cannot or should not use new attributes unless their semantics has been clearly defined. Also mechanism 1 may have some problems with presence authorization and filtering.=20 Personally I think we can live with only XML extension mechanism (mechanism 1). For applications that would like to use extension tag this means defining a new XML schema. However, this may be a good thing because applications must in any case define some kind of semantics for new attributes and as far as I know this doesn't need to involve any standardization. Changes: - remove elements from all media type tags (voice, video, application, data, control, text) and change these to be of boolean type - Add separate element into XML schema - Remove text from section 5 which talks about adding Accept-Contact header based on prescaps into SIP requests. - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 06:13:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08665 for ; Wed, 21 Apr 2004 06:13:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEhG-0004KO-QN for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 06:11:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LABEtP016632 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 06:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEdu-0002os-T3 for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 06:07:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08492 for ; Wed, 21 Apr 2004 06:07:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGEdr-0007iX-9r for simple-web-archive@ietf.org; Wed, 21 Apr 2004 06:07:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGEcv-0007ao-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 06:06:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGEc7-0007Sn-00; Wed, 21 Apr 2004 06:05:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEYL-0000PY-Au; Wed, 21 Apr 2004 06:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGETA-00077X-L5 for simple@optimus.ietf.org; Wed, 21 Apr 2004 05:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07919 for ; Wed, 21 Apr 2004 05:56:36 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGET7-0006K8-0N for simple@ietf.org; Wed, 21 Apr 2004 05:56:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGESB-0006Di-00 for simple@ietf.org; Wed, 21 Apr 2004 05:55:39 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGERS-00067x-00 for simple@ietf.org; Wed, 21 Apr 2004 05:54:54 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L9ssP15547 for ; Wed, 21 Apr 2004 12:54:54 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 12:54:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3L9sZbN003252 for ; Wed, 21 Apr 2004 12:54:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00PE4msT; Wed, 21 Apr 2004 12:54:34 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L9sSs28386 for ; Wed, 21 Apr 2004 12:54:28 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 12:52:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE64@esebe004.ntc.nokia.com> Thread-Topic: Open issues and changes to prescaps Thread-Index: AcQnhl6CB6fHHHY+SBy4y+j88Sx6Cg== To: X-OriginalArrivalTime: 21 Apr 2004 09:52:34.0532 (UTC) FILETIME=[5EF34A40:01C42786] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Open issues and changes to prescaps Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 12:52:34 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Here is a list of open issues and changes that were agreed in Seoul. If I have missed something please let me know. We should get consensus on open issue(s) quite soon (hopefully within a week or so).=20 Open issues: - Extension mechanism. Currently draft contains two extension mechanisms. One is XML extension mechanism (mechanism 1) and the other one is based on XML elements token, string, boolean, and numeric which allow usage of other tags that are not specified in callee caps (mechanism 2). We have had some list discussion about this topic and below I try summarize discussion so far: Arguments for having mechanism 2 have been that for some applications it might be easier to use. Using this mechanism applications would not need to define new XML namespaces for every new attribute. For applications which can 'dynamically' use or come up with new attributes this mechanism would be good. Argument for having only XML extension mechanism have been that for having two extension mechanisms may lead to some inconsistencies like same extension attribute could be applied using both mechanisms simultaneously. It has also being argued that applications cannot or should not use new attributes unless their semantics has been clearly defined. Also mechanism 1 may have some problems with presence authorization and filtering.=20 Personally I think we can live with only XML extension mechanism (mechanism 1). For applications that would like to use extension tag this means defining a new XML schema. However, this may be a good thing because applications must in any case define some kind of semantics for new attributes and as far as I know this doesn't need to involve any standardization. Changes: - remove elements from all media type tags (voice, video, application, data, control, text) and change these to be of boolean type - Add separate element into XML schema - Remove text from section 5 which talks about adding Accept-Contact header based on prescaps into SIP requests. - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 09:12:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19021 for ; Wed, 21 Apr 2004 09:12:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHWy-00033G-0J for simple-archive@ietf.org; Wed, 21 Apr 2004 09:12:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHW0-0002uD-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 09:11:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGHV2-0002kZ-00; Wed, 21 Apr 2004 09:10:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHNY-0007so-3k; Wed, 21 Apr 2004 09:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHHc-0004nU-Oe for simple@optimus.ietf.org; Wed, 21 Apr 2004 08:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17957 for ; Wed, 21 Apr 2004 08:56:54 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHHb-0000SK-8w for simple@ietf.org; Wed, 21 Apr 2004 08:56:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHGh-0000KT-00 for simple@ietf.org; Wed, 21 Apr 2004 08:55:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGHGF-0000CJ-00 for simple@ietf.org; Wed, 21 Apr 2004 08:55:31 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LCtR319161 for ; Wed, 21 Apr 2004 15:55:28 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 15:55:22 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3LCtMlQ017065 for ; Wed, 21 Apr 2004 15:55:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 000i8x0i; Wed, 21 Apr 2004 15:55:20 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LCtIF13528 for ; Wed, 21 Apr 2004 15:55:18 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 15:54:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> Thread-Topic: WGLC on isComposing draft Thread-Index: AcQnn8nsMEVcsGTYTZeoEy+h9hyXwQ== To: X-OriginalArrivalTime: 21 Apr 2004 12:54:31.0817 (UTC) FILETIME=[CA28C790:01C4279F] Content-Transfer-Encoding: quoted-printable Subject: [Simple] WGLC on isComposing draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 15:54:30 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The WG chairs would like to start a Working Group Last Call on the = following drafts: http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt This WGLC will end on May 5th. Please send your comments to this mailing list and to the authors.=20 If you reviewed the draft and found no issues, please indicate so also = on the mailing list. This will help us evaluate the level of review and = group consensus. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 09:22:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19409 for ; Wed, 21 Apr 2004 09:22:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHa0-0005Bi-Ea for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 09:15:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LDFuCt019938 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 09:15:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHX0-0003DU-7v for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 09:12:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19039 for ; Wed, 21 Apr 2004 09:12:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHWy-00033L-MI for simple-web-archive@ietf.org; Wed, 21 Apr 2004 09:12:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHW1-0002uK-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 09:11:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGHV2-0002kZ-00; Wed, 21 Apr 2004 09:10:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHNY-0007so-3k; Wed, 21 Apr 2004 09:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHHc-0004nU-Oe for simple@optimus.ietf.org; Wed, 21 Apr 2004 08:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17957 for ; Wed, 21 Apr 2004 08:56:54 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHHb-0000SK-8w for simple@ietf.org; Wed, 21 Apr 2004 08:56:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHGh-0000KT-00 for simple@ietf.org; Wed, 21 Apr 2004 08:55:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGHGF-0000CJ-00 for simple@ietf.org; Wed, 21 Apr 2004 08:55:31 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LCtR319161 for ; Wed, 21 Apr 2004 15:55:28 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 15:55:22 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3LCtMlQ017065 for ; Wed, 21 Apr 2004 15:55:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 000i8x0i; Wed, 21 Apr 2004 15:55:20 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LCtIF13528 for ; Wed, 21 Apr 2004 15:55:18 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 15:54:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> Thread-Topic: WGLC on isComposing draft Thread-Index: AcQnn8nsMEVcsGTYTZeoEy+h9hyXwQ== To: X-OriginalArrivalTime: 21 Apr 2004 12:54:31.0817 (UTC) FILETIME=[CA28C790:01C4279F] Content-Transfer-Encoding: quoted-printable Subject: [Simple] WGLC on isComposing draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 15:54:30 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The WG chairs would like to start a Working Group Last Call on the = following drafts: http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt This WGLC will end on May 5th. Please send your comments to this mailing list and to the authors.=20 If you reviewed the draft and found no issues, please indicate so also = on the mailing list. This will help us evaluate the level of review and = group consensus. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 09:51:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21083 for ; Wed, 21 Apr 2004 09:51:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGI8B-0001aM-GL for simple-archive@ietf.org; Wed, 21 Apr 2004 09:51:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGI6b-00017b-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 09:49:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGI5R-0000rt-00; Wed, 21 Apr 2004 09:48:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHx6-00072S-JE; Wed, 21 Apr 2004 09:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHuU-0005LJ-Iu for simple@optimus.ietf.org; Wed, 21 Apr 2004 09:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20360 for ; Wed, 21 Apr 2004 09:37:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHuS-00071B-NQ for simple@ietf.org; Wed, 21 Apr 2004 09:37:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHtX-0006sV-00 for simple@ietf.org; Wed, 21 Apr 2004 09:36:07 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BGHt2-0006iv-00 for simple@ietf.org; Wed, 21 Apr 2004 09:35:36 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3LDZSIx032259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Apr 2004 08:35:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4086789C.1000901@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.com, simple@ietf.org Subject: Re: [Simple] MSRP Details References: <2038BCC78B1AD641891A0D1AE133DBB701797952@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797952@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 08:35:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The RFC1894 syntax for status-code is something like (from memory) status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT So our HTTP style codes do not naturally fit. hisham.khartabil@nokia.com wrote: > Is the REPORT method part of MSRP? If yes, then what is wrong with using the status-code as is currently defined in MSRP draft? > > Status-Code = 200 ;Success > / 400 ;Bad Request > / 403 ;Forbidden > / 415 ;Unsupported Content Type > / 426 ;Upgrade Required > / 481 ;No session > / 506 ;duplicate session > > I don't think you need to define your own for DSN here. > > Thanks, > Hisham > > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of ext Chris Boulton > Sent: 20.April.2004 17:41 > To: simple@ietf.org > Cc: Ben Campbell > Subject: [Simple] MSRP Details > > > Hi to all on the list, > > I've got a question that I wouldn't mind some input + closure on. I am currently completing the DSN details for MSRP reports and in RFC 1894 - It specifies that the format for 'status' code in a DSN message is:- > > status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT > > This does not map exactly to an MSRP status code and I was trying to look at the best solution - does anyone have any input? > > Should we spread the status code e.g. 200 = 2.0.0 > > OR > > Use the last 3 digit field e.g. 0.0.200 > > I would appreciate some input. > > Best Regards, > > Chris Boulton. > > > ------------------------------------------------ > Chris Boulton > Ubiquity Software > > Tel : +44 (0) 1633765600 > Fax : +44 (0) 1633765601 > ------------------------------------------------ > > > > > > > This message has been scanned for viruses by MailControl, a service from BlackSpider Technologies. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 10:08:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22756 for ; Wed, 21 Apr 2004 10:08:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGIPF-0004fV-2i for simple-archive@ietf.org; Wed, 21 Apr 2004 10:08:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGIOJ-0004Vh-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 10:07:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGINL-0004Ln-00; Wed, 21 Apr 2004 10:06:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI8v-0004NJ-Kd; Wed, 21 Apr 2004 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHzE-0007pf-8W for simple@optimus.ietf.org; Wed, 21 Apr 2004 09:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20621 for ; Wed, 21 Apr 2004 09:41:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHzC-0007lp-DN for simple@ietf.org; Wed, 21 Apr 2004 09:41:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHyH-0007dF-00 for simple@ietf.org; Wed, 21 Apr 2004 09:41:02 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly05b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BGHxp-0007UA-00 for simple@ietf.org; Wed, 21 Apr 2004 09:40:33 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05b.srv.mailcontrol.com (MailControl) with SMTP id i3LDe0Sc029549; Wed, 21 Apr 2004 14:40:01 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Wed, 21 Apr 2004 14:40:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on isComposing draft Message-ID: <45730E094814E44488F789C1CDED27AE02BDF373@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] WGLC on isComposing draft Thread-Index: AcQnn8nsMEVcsGTYTZeoEy+h9hyXwQABijdQ From: "Chris Boulton" To: , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 14:40:00 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Out of interest - why is -----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 21 April 2004 13:54 >To: simple@ietf.org >Subject: [Simple] WGLC on isComposing draft > >The WG chairs would like to start a Working Group Last Call on the >following drafts: > >http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.tx t > >This WGLC will end on May 5th. > >Please send your comments to this mailing list and to the authors. > >If you reviewed the draft and found no issues, please indicate so also on >the mailing list. This will help us evaluate the level of review and group >consensus. > >Thanks, >Hisham > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 10:11:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23130 for ; Wed, 21 Apr 2004 10:11:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIJ2-0001Gy-GV for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 10:02:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LE2SHY004878 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 10:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI8E-0003xD-6n for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 09:51:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21101 for ; Wed, 21 Apr 2004 09:51:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGI8C-0001aU-BN for simple-web-archive@ietf.org; Wed, 21 Apr 2004 09:51:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGI6c-00017i-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 09:49:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGI5R-0000rt-00; Wed, 21 Apr 2004 09:48:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHx6-00072S-JE; Wed, 21 Apr 2004 09:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHuU-0005LJ-Iu for simple@optimus.ietf.org; Wed, 21 Apr 2004 09:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20360 for ; Wed, 21 Apr 2004 09:37:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHuS-00071B-NQ for simple@ietf.org; Wed, 21 Apr 2004 09:37:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHtX-0006sV-00 for simple@ietf.org; Wed, 21 Apr 2004 09:36:07 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BGHt2-0006iv-00 for simple@ietf.org; Wed, 21 Apr 2004 09:35:36 -0400 Received: from dynamicsoft.com (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i3LDZSIx032259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Apr 2004 08:35:29 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <4086789C.1000901@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.com, simple@ietf.org Subject: Re: [Simple] MSRP Details References: <2038BCC78B1AD641891A0D1AE133DBB701797952@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797952@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 08:35:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The RFC1894 syntax for status-code is something like (from memory) status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT So our HTTP style codes do not naturally fit. hisham.khartabil@nokia.com wrote: > Is the REPORT method part of MSRP? If yes, then what is wrong with using the status-code as is currently defined in MSRP draft? > > Status-Code = 200 ;Success > / 400 ;Bad Request > / 403 ;Forbidden > / 415 ;Unsupported Content Type > / 426 ;Upgrade Required > / 481 ;No session > / 506 ;duplicate session > > I don't think you need to define your own for DSN here. > > Thanks, > Hisham > > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of ext Chris Boulton > Sent: 20.April.2004 17:41 > To: simple@ietf.org > Cc: Ben Campbell > Subject: [Simple] MSRP Details > > > Hi to all on the list, > > I've got a question that I wouldn't mind some input + closure on. I am currently completing the DSN details for MSRP reports and in RFC 1894 - It specifies that the format for 'status' code in a DSN message is:- > > status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT > > This does not map exactly to an MSRP status code and I was trying to look at the best solution - does anyone have any input? > > Should we spread the status code e.g. 200 = 2.0.0 > > OR > > Use the last 3 digit field e.g. 0.0.200 > > I would appreciate some input. > > Best Regards, > > Chris Boulton. > > > ------------------------------------------------ > Chris Boulton > Ubiquity Software > > Tel : +44 (0) 1633765600 > Fax : +44 (0) 1633765601 > ------------------------------------------------ > > > > > > > This message has been scanned for viruses by MailControl, a service from BlackSpider Technologies. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 10:19:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24194 for ; Wed, 21 Apr 2004 10:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIUk-0000pU-OZ for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 10:14:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LEEYdr003184 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 10:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIPI-0005lU-0f for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 10:08:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22771 for ; Wed, 21 Apr 2004 10:08:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGIPF-0004fa-OV for simple-web-archive@ietf.org; Wed, 21 Apr 2004 10:08:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGIOJ-0004Vr-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 10:07:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGINL-0004Ln-00; Wed, 21 Apr 2004 10:06:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI8v-0004NJ-Kd; Wed, 21 Apr 2004 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHzE-0007pf-8W for simple@optimus.ietf.org; Wed, 21 Apr 2004 09:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20621 for ; Wed, 21 Apr 2004 09:41:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHzC-0007lp-DN for simple@ietf.org; Wed, 21 Apr 2004 09:41:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHyH-0007dF-00 for simple@ietf.org; Wed, 21 Apr 2004 09:41:02 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly05b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BGHxp-0007UA-00 for simple@ietf.org; Wed, 21 Apr 2004 09:40:33 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05b.srv.mailcontrol.com (MailControl) with SMTP id i3LDe0Sc029549; Wed, 21 Apr 2004 14:40:01 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Wed, 21 Apr 2004 14:40:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on isComposing draft Message-ID: <45730E094814E44488F789C1CDED27AE02BDF373@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] WGLC on isComposing draft Thread-Index: AcQnn8nsMEVcsGTYTZeoEy+h9hyXwQABijdQ From: "Chris Boulton" To: , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 14:40:00 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Out of interest - why is -----Original Message----- >From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >Sent: 21 April 2004 13:54 >To: simple@ietf.org >Subject: [Simple] WGLC on isComposing draft > >The WG chairs would like to start a Working Group Last Call on the >following drafts: > >http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.tx t > >This WGLC will end on May 5th. > >Please send your comments to this mailing list and to the authors. > >If you reviewed the draft and found no issues, please indicate so also on >the mailing list. This will help us evaluate the level of review and group >consensus. > >Thanks, >Hisham > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 12:04:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29099 for ; Wed, 21 Apr 2004 12:04:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKDB-0000Po-2O for simple-archive@ietf.org; Wed, 21 Apr 2004 12:04:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKCE-00009k-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 12:03:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKB9-0007gY-00; Wed, 21 Apr 2004 12:02:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzW-00031s-O0; Wed, 21 Apr 2004 11:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJAm-0001DV-TH for simple@optimus.ietf.org; Wed, 21 Apr 2004 10:58:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26267 for ; Wed, 21 Apr 2004 10:57:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJAk-000519-BA for simple@ietf.org; Wed, 21 Apr 2004 10:57:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJ9o-0004s1-00 for simple@ietf.org; Wed, 21 Apr 2004 10:57:01 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGJ9L-0004iy-00 for simple@ietf.org; Wed, 21 Apr 2004 10:56:31 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3LEtd6r004664 for ; Wed, 21 Apr 2004 09:55:39 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1082559342.2204.52.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC: partial notification Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 09:55:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is a Working Group Last call on the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt This abbreviated WGLC will end on Wednesday, April 28. These drafts went through a previous last call at the beginning of March. These versions reflect changes due to comments received during that period. See https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html for details. Please send comments to the list, copying the editor. If you reviewed the draft and found no issues, please indicate so on the list. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 12:35:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01002 for ; Wed, 21 Apr 2004 12:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKai-0002hc-ST for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 12:28:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGSqAi010370 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 12:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKDD-0000Nu-41 for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:04:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29119 for ; Wed, 21 Apr 2004 12:04:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKDB-0000Pt-TA for simple-web-archive@ietf.org; Wed, 21 Apr 2004 12:04:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKCF-00009r-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 12:03:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKB9-0007gY-00; Wed, 21 Apr 2004 12:02:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzW-00031s-O0; Wed, 21 Apr 2004 11:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJAm-0001DV-TH for simple@optimus.ietf.org; Wed, 21 Apr 2004 10:58:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26267 for ; Wed, 21 Apr 2004 10:57:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJAk-000519-BA for simple@ietf.org; Wed, 21 Apr 2004 10:57:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJ9o-0004s1-00 for simple@ietf.org; Wed, 21 Apr 2004 10:57:01 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGJ9L-0004iy-00 for simple@ietf.org; Wed, 21 Apr 2004 10:56:31 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3LEtd6r004664 for ; Wed, 21 Apr 2004 09:55:39 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1082559342.2204.52.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC: partial notification Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 09:55:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a Working Group Last call on the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt This abbreviated WGLC will end on Wednesday, April 28. These drafts went through a previous last call at the beginning of March. These versions reflect changes due to comments received during that period. See https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html for details. Please send comments to the list, copying the editor. If you reviewed the draft and found no issues, please indicate so on the list. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 17:25:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15987 for ; Wed, 21 Apr 2004 17:25:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPEB-0002Kj-9h for simple-archive@ietf.org; Wed, 21 Apr 2004 17:25:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPAr-0001d1-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 17:22:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGP80-0000oz-00; Wed, 21 Apr 2004 17:19:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOb4-000438-Ke; Wed, 21 Apr 2004 16:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGNHQ-0008EQ-0x for simple@optimus.ietf.org; Wed, 21 Apr 2004 15:21:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09342 for ; Wed, 21 Apr 2004 15:21:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGNHO-0002gX-Kw for simple@ietf.org; Wed, 21 Apr 2004 15:21:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGNGQ-0002VJ-00 for simple@ietf.org; Wed, 21 Apr 2004 15:20:07 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGNFZ-0002B1-00 for simple@ietf.org; Wed, 21 Apr 2004 15:19:13 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 21 Apr 2004 12:18:42 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Apr 2004 12:18:42 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Apr 2004 12:18:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: Thread-Topic: [Simple] MSRP message reliability(long) thread-index: AcQevzmYZiEaOXSARYiJXxgqQGDR3AIeJonQAAz73cAAGGUMEA== From: "Orit Levin" To: , Cc: , X-OriginalArrivalTime: 21 Apr 2004 19:18:42.0436 (UTC) FILETIME=[75661C40:01C427D5] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 12:18:40 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hisham, My guess is that "200 OK" vs. minimum positive DSNs will have a similar impact on the bandwidth between a phone and the first relay/switch. Of course, using both simultaneously will have a double impact. 1. You can not use "200 OK" information for building (even somewhat) reliable IM applications. These applications need to use DSN mechanism instead (regardless the physical interface beneath). 2. The "200 OK" model is inapplicable for scalable IM conferencing (please, see the draft for details). 3. Looking at a bigger picture (not the access interface only), core network/service providers will have a MUCH BIGGER problem with "200 OKs" compared to positive DSNs because of performance issues. To summarize, by applying the "200 OK" model for EVERY message above (a chain of) TCP connection(s), you basically loose the main motivation for the "sessions mode" to start with. Although it is lighter than SIP and MESSAGE page mode, it is still not as efficient as required compared to existing commercial implementations.=20 Orit.=20 -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Sent: Tuesday, April 20, 2004 11:48 PM To: Orit Levin; vikas@arciis.com Cc: simple@ietf.org; bcampbell@dynamicsoft.com Subject: RE: [Simple] MSRP message reliability(long) Hi Orit, One message (the 200 ok for SEND) is hardly a problem to the air interface, which is between the terminal and the first relay only. Can you elaborate on why it is a problem? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Orit Levin > Sent: 21.April.2004 03:38 > To: Vikas Tandon > Cc: Simple WG; Ben Campbell > Subject: RE: [Simple] MSRP message reliability(long) >=20 >=20 > Hi Vicas, > I understand that you don't see a problem in unconditionally sending a > (hop-by-hop) response to every message (regardless the end-to-end mode > being used). If my understanding is correct, how are you planning to=20 > address the wireless bandwidth problem in this case? >=20 > Thanks, > Orit. >=20 > -----Original Message----- > From: Vikas Tandon [mailto:vikas@arciis.com] > Sent: Friday, April 09, 2004 10:47 PM > To: 'Ben Campbell' > Cc: Orit Levin; 'Simple WG' > Subject: RE: [Simple] MSRP message reliability(long) >=20 > Hi Ben & Group, > By "this" i mean the earlier messages exchanged between me, Mr. Vijay=20 > Gurbani, Mr. Hisham and a couple of more participants. Yes i am > referring to the delivery reports. =20 > Regards, > -Vikas >=20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: vendredi 9 avril 2004 20:10 > To: Vikas Tandon > Cc: 'Orit Levin'; 'Simple WG' > Subject: Re: [Simple] MSRP message reliability(long) >=20 >=20 > Vikas Tandon wrote: >=20 > > Also as discussed earlier in this forum, this adds a lot of > traffic to >=20 > > the client (specially the wireless mobile clients where the > bandwidth > > is an issue). If the workgroup plans to make it configurable to set=20 > > the delivery response for positive case off, then it has to be=20 > > terminated earlier than reaching the wireless medium. E.g. > terminate > > the positive response at the IM server in case the client > has chosen > > not to receive the positive acknowledgements of delivery of IM. >=20 > Hi, could you clarify what "this" refers to in the previous paragraph? > Keep in mind that we are really discussion two things: the transaction > responses between hops, and the sending of delivery reports. > It sounds > to me like you are talking delivery reports, but I am not certain. >=20 > >=20 > > If we fail to do this, imagine for every message I'm > sending, there is >=20 > > some traffic I'm getting back to my mobile device (which is painful=20 > > because i may be paying by the amount of traffic i transact from my=20 > > device). So although it becomes transparent to me from device, by i=20 > > still pay for it. The workgroup needs to consider this matter. I=20 > > somehow still prefer - "No news is good news". > >=20 > > Would be good to know more thoughts on this. > >=20 > > Regards, > > Vikas Tandon > >=20 > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] > On Behalf > > Of Ben Campbell > > Sent: vendredi 9 avril 2004 19:45 > > To: Orit Levin > > Cc: Simple WG > > Subject: Re: [Simple] MSRP message reliability(long) > >=20 > >=20 > > Orit Levin wrote: > >=20 > > [...] > >=20 > >>Why are you opposing to a flexible hop-by-hop mechanism (in addition > >>to DSN)? It doesn't necessarily require negotiation - only local=20 > >>policy for setting the bit. Let's assume for a moment that > a bit per > >>message exists saying "response/don't response" to the previous hop. > >=20 > >=20 > > I oppose the ability to select whether you use transaction > responses > > or > > not because it adds a huge amount of complexity to the protocol and > any > > implementations. Adding or removing transaction responses > _completely_ >=20 > > changes the protocol semantics. In effect, it would be > saying we have > > two different required protocols with the same syntax on top. If we > make > >=20 > > this selectable, we make every implementer build 2 protocols with=20 > > different state machines, etc. I think that will be _much_ > more of an > > impediment to acceptance than performance differences in > the range you >=20 > > predict. > >=20 > > My point is, if the working group were to decide we need to > be able to > > run without transaction responses (a big if) , then we > should _always_ >=20 > > run without transaction responses. As it is, earlier attempts at a=20 > > message sessions did not have the transaction response, and the > working > > group decided to put them it. (Does anyone remember the specific=20 > > argument used at that time?) > >=20 > > But, on all of these points, working group consensus trumps > either of > > our opinions. Please, anyone who cares one way or another, > state your > > opinion asap! > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 18:32:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25264 for ; Wed, 21 Apr 2004 18:32:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQGc-0001dj-Cv for simple-archive@ietf.org; Wed, 21 Apr 2004 18:32:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQEE-0000vq-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 18:30:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQ9U-0007ek-00; Wed, 21 Apr 2004 18:25:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPqF-0003Fr-QK; Wed, 21 Apr 2004 18:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOtW-0003Z0-Ez for simple@optimus.ietf.org; Wed, 21 Apr 2004 17:04:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14274 for ; Wed, 21 Apr 2004 17:04:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOtU-0005Om-7U for simple@ietf.org; Wed, 21 Apr 2004 17:04:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOsT-00058J-00 for simple@ietf.org; Wed, 21 Apr 2004 17:03:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BGOrb-0004oJ-00; Wed, 21 Apr 2004 17:02:35 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2004 14:01:31 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3LL226L014439; Wed, 21 Apr 2004 17:02:03 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHT76259; Wed, 21 Apr 2004 17:02:02 -0400 (EDT) Message-ID: <4086E14A.6080403@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Managing multiple body parts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 17:02:02 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I changed the subject of this because it is generalized. See below for details. The general question is: Is there a need for some sort of draft (beyond what is already in 3261) explaining how body parts are to be arranged and tagged so that they will be found and processed in an interoperable way? I think there is. I have spent time working on sip stack support for managing body parts, and I came up with all kinds of questions about what is valid and what is not. Paul Miguel Garcia wrote: > Hi Paul: > > Thanks for your comments. Answers inline. > > ext Paul Kyzivat wrote: > >> Miguel, >> >> In general the approach in the draft seems reasonable to me. >> >> I see one area of ambiguity, having to do with how multipart bodies >> are handled. The draft says to remove the list and include everything >> else. But even your example doesn't do that - it also removes the >> multipart/mixed wrapper. Of course in this particular example that >> makes perfect sense, but it goes beyond what the draft says to do. > > > We start from the the fact that there will be as a minimum, two bodies, > the list, and the actual payload. There might be more bodies, such as > multiple payloads, S/MIME signatures, etc. > > I guess the algorithm should be: > > - If there is any kind of security body for the exploder (e.g., signed > with the public key of the exploder), then remove that body. > > - Remove the list itself (in a typical use case, unless an extension > says the oposite; I am referring to Ben's suggestion to allow it). > > - If there is only one body left, then remove the multipart/mixed wrapper. > > - Send the remaining stuff. This seems like the ad hoc approach. It will probably work in a lot of cases. In the absence of more general rules this is probably a pragmatic approach to take. But I think there is a more general problem - not specific to message exploders, or exploders, or message - that applies to management of body parts in general. Part of it is just: - in a hierarchy of mime entities, how do I identify the body parts that interest me? And the flip side of that is: - How do I arrange the body parts that I need to convey into a hierarchy of mime entities so that the recipient will find and process them correctly? This is then further complicated by servers in the signaling path that are permitted to mess with body parts. (That currently is only B2BUAs, but with the m2m and m2e discussions it may eventually include proxies.) For them there are the following additional questions: - Should I (and if so how) modify the mime entity hierarchy to remove body parts that I have processed? - How should I modify the mime entity hierarchy to add additional body parts that are to be processed further downstream, so that the recipient will process them correctly? >> There are more complex cases: >> >> - for security there could be signed body parts. >> >> - The signature could be on the multipart containing the message >> and list. It would have to be removed. >> >> - The signature could be on just the message. Presumably >> it should remain. > > > > > I agree. > >> >> - There could be other body parts referenced by cid: urls in >> other headers in the message. > > > Yes, they should remain. > >> >> I think there needs to be a more prescriptive way of defining what >> gets passed on in the exploded messages. This is really just a >> manifestation of a more general problem of how to decide how different >> body parts should be processed. It potentially exists in a normal, >> unexploded, MESSAGE. >> >> I think at least part of the answer lies with Content-Disposition. I >> think there should be clarity about the content-disposition should be >> for the body part(s) that MESSAGE interprets as message content. >> Probably "render" (which is default for sip) would be an appropriate >> content-disposition for message content. > > > Agree so far. It may happen that some of this stuff is generic enough > (not MESSAGE specific). Yes, very much so. >> Also, I think there should be some clarity about what the >> content-disposition should be for various kinds of multipart >> containers when used in the various ways they may be used in sip. I'm >> not quite sure what the answer is here. >> >> The list itself is of course referenced from a cid: url. It is the url >> and its placement that determines how the corresponding body part >> should be processed. For these, the content-disposition should be some >> value that doesn't imply some other sort of processing. I think it >> can't be any of "session", "render", "alert", or "icon". Maybe it >> could be "attachment". > > > I will be happy to have a very clear deterministic way to find out what > to pass and what to keep to the other side of the exploder, base on > presumabley the content-disposition. Let's see if I can come up with > something. I'm interested in this. Do you think this is suitable as a new work item? (Probably for sipping at first.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 18:33:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25653 for ; Wed, 21 Apr 2004 18:33:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ2i-0004Wi-2I for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 18:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMI8eP017393 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 18:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPEJ-0006aR-5l for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:26:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16008 for ; Wed, 21 Apr 2004 17:25:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPEG-0002Ld-RI for simple-web-archive@ietf.org; Wed, 21 Apr 2004 17:26:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPAv-0001dU-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 17:22:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGP80-0000oz-00; Wed, 21 Apr 2004 17:19:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOb4-000438-Ke; Wed, 21 Apr 2004 16:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGNHQ-0008EQ-0x for simple@optimus.ietf.org; Wed, 21 Apr 2004 15:21:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09342 for ; Wed, 21 Apr 2004 15:21:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGNHO-0002gX-Kw for simple@ietf.org; Wed, 21 Apr 2004 15:21:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGNGQ-0002VJ-00 for simple@ietf.org; Wed, 21 Apr 2004 15:20:07 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGNFZ-0002B1-00 for simple@ietf.org; Wed, 21 Apr 2004 15:19:13 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 21 Apr 2004 12:18:42 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Apr 2004 12:18:42 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Apr 2004 12:18:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP message reliability(long) Message-ID: Thread-Topic: [Simple] MSRP message reliability(long) thread-index: AcQevzmYZiEaOXSARYiJXxgqQGDR3AIeJonQAAz73cAAGGUMEA== From: "Orit Levin" To: , Cc: , X-OriginalArrivalTime: 21 Apr 2004 19:18:42.0436 (UTC) FILETIME=[75661C40:01C427D5] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 12:18:40 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hisham, My guess is that "200 OK" vs. minimum positive DSNs will have a similar impact on the bandwidth between a phone and the first relay/switch. Of course, using both simultaneously will have a double impact. 1. You can not use "200 OK" information for building (even somewhat) reliable IM applications. These applications need to use DSN mechanism instead (regardless the physical interface beneath). 2. The "200 OK" model is inapplicable for scalable IM conferencing (please, see the draft for details). 3. Looking at a bigger picture (not the access interface only), core network/service providers will have a MUCH BIGGER problem with "200 OKs" compared to positive DSNs because of performance issues. To summarize, by applying the "200 OK" model for EVERY message above (a chain of) TCP connection(s), you basically loose the main motivation for the "sessions mode" to start with. Although it is lighter than SIP and MESSAGE page mode, it is still not as efficient as required compared to existing commercial implementations.=20 Orit.=20 -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Sent: Tuesday, April 20, 2004 11:48 PM To: Orit Levin; vikas@arciis.com Cc: simple@ietf.org; bcampbell@dynamicsoft.com Subject: RE: [Simple] MSRP message reliability(long) Hi Orit, One message (the 200 ok for SEND) is hardly a problem to the air interface, which is between the terminal and the first relay only. Can you elaborate on why it is a problem? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Orit Levin > Sent: 21.April.2004 03:38 > To: Vikas Tandon > Cc: Simple WG; Ben Campbell > Subject: RE: [Simple] MSRP message reliability(long) >=20 >=20 > Hi Vicas, > I understand that you don't see a problem in unconditionally sending a > (hop-by-hop) response to every message (regardless the end-to-end mode > being used). If my understanding is correct, how are you planning to=20 > address the wireless bandwidth problem in this case? >=20 > Thanks, > Orit. >=20 > -----Original Message----- > From: Vikas Tandon [mailto:vikas@arciis.com] > Sent: Friday, April 09, 2004 10:47 PM > To: 'Ben Campbell' > Cc: Orit Levin; 'Simple WG' > Subject: RE: [Simple] MSRP message reliability(long) >=20 > Hi Ben & Group, > By "this" i mean the earlier messages exchanged between me, Mr. Vijay=20 > Gurbani, Mr. Hisham and a couple of more participants. Yes i am > referring to the delivery reports. =20 > Regards, > -Vikas >=20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: vendredi 9 avril 2004 20:10 > To: Vikas Tandon > Cc: 'Orit Levin'; 'Simple WG' > Subject: Re: [Simple] MSRP message reliability(long) >=20 >=20 > Vikas Tandon wrote: >=20 > > Also as discussed earlier in this forum, this adds a lot of > traffic to >=20 > > the client (specially the wireless mobile clients where the > bandwidth > > is an issue). If the workgroup plans to make it configurable to set=20 > > the delivery response for positive case off, then it has to be=20 > > terminated earlier than reaching the wireless medium. E.g. > terminate > > the positive response at the IM server in case the client > has chosen > > not to receive the positive acknowledgements of delivery of IM. >=20 > Hi, could you clarify what "this" refers to in the previous paragraph? > Keep in mind that we are really discussion two things: the transaction > responses between hops, and the sending of delivery reports. > It sounds > to me like you are talking delivery reports, but I am not certain. >=20 > >=20 > > If we fail to do this, imagine for every message I'm > sending, there is >=20 > > some traffic I'm getting back to my mobile device (which is painful=20 > > because i may be paying by the amount of traffic i transact from my=20 > > device). So although it becomes transparent to me from device, by i=20 > > still pay for it. The workgroup needs to consider this matter. I=20 > > somehow still prefer - "No news is good news". > >=20 > > Would be good to know more thoughts on this. > >=20 > > Regards, > > Vikas Tandon > >=20 > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] > On Behalf > > Of Ben Campbell > > Sent: vendredi 9 avril 2004 19:45 > > To: Orit Levin > > Cc: Simple WG > > Subject: Re: [Simple] MSRP message reliability(long) > >=20 > >=20 > > Orit Levin wrote: > >=20 > > [...] > >=20 > >>Why are you opposing to a flexible hop-by-hop mechanism (in addition > >>to DSN)? It doesn't necessarily require negotiation - only local=20 > >>policy for setting the bit. Let's assume for a moment that > a bit per > >>message exists saying "response/don't response" to the previous hop. > >=20 > >=20 > > I oppose the ability to select whether you use transaction > responses > > or > > not because it adds a huge amount of complexity to the protocol and > any > > implementations. Adding or removing transaction responses > _completely_ >=20 > > changes the protocol semantics. In effect, it would be > saying we have > > two different required protocols with the same syntax on top. If we > make > >=20 > > this selectable, we make every implementer build 2 protocols with=20 > > different state machines, etc. I think that will be _much_ > more of an > > impediment to acceptance than performance differences in > the range you >=20 > > predict. > >=20 > > My point is, if the working group were to decide we need to > be able to > > run without transaction responses (a big if) , then we > should _always_ >=20 > > run without transaction responses. As it is, earlier attempts at a=20 > > message sessions did not have the transaction response, and the > working > > group decided to put them it. (Does anyone remember the specific=20 > > argument used at that time?) > >=20 > > But, on all of these points, working group consensus trumps > either of > > our opinions. Please, anyone who cares one way or another, > state your > > opinion asap! > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 19:18:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29351 for ; Wed, 21 Apr 2004 19:18:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQbi-0000TF-7c for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 18:54:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMsIZN001805 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 18:54:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQGf-0005n0-Tt for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 18:32:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25278 for ; Wed, 21 Apr 2004 18:32:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQGc-0001do-Ur for simple-web-archive@ietf.org; Wed, 21 Apr 2004 18:32:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQEH-0000wH-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 18:30:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQ9U-0007ek-00; Wed, 21 Apr 2004 18:25:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPqF-0003Fr-QK; Wed, 21 Apr 2004 18:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOtW-0003Z0-Ez for simple@optimus.ietf.org; Wed, 21 Apr 2004 17:04:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14274 for ; Wed, 21 Apr 2004 17:04:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOtU-0005Om-7U for simple@ietf.org; Wed, 21 Apr 2004 17:04:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOsT-00058J-00 for simple@ietf.org; Wed, 21 Apr 2004 17:03:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BGOrb-0004oJ-00; Wed, 21 Apr 2004 17:02:35 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2004 14:01:31 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3LL226L014439; Wed, 21 Apr 2004 17:02:03 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHT76259; Wed, 21 Apr 2004 17:02:02 -0400 (EDT) Message-ID: <4086E14A.6080403@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: SIMPLE mailing list , SIPPING mailing list , Gonzalo Camarillo References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Managing multiple body parts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 17:02:02 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I changed the subject of this because it is generalized. See below for details. The general question is: Is there a need for some sort of draft (beyond what is already in 3261) explaining how body parts are to be arranged and tagged so that they will be found and processed in an interoperable way? I think there is. I have spent time working on sip stack support for managing body parts, and I came up with all kinds of questions about what is valid and what is not. Paul Miguel Garcia wrote: > Hi Paul: > > Thanks for your comments. Answers inline. > > ext Paul Kyzivat wrote: > >> Miguel, >> >> In general the approach in the draft seems reasonable to me. >> >> I see one area of ambiguity, having to do with how multipart bodies >> are handled. The draft says to remove the list and include everything >> else. But even your example doesn't do that - it also removes the >> multipart/mixed wrapper. Of course in this particular example that >> makes perfect sense, but it goes beyond what the draft says to do. > > > We start from the the fact that there will be as a minimum, two bodies, > the list, and the actual payload. There might be more bodies, such as > multiple payloads, S/MIME signatures, etc. > > I guess the algorithm should be: > > - If there is any kind of security body for the exploder (e.g., signed > with the public key of the exploder), then remove that body. > > - Remove the list itself (in a typical use case, unless an extension > says the oposite; I am referring to Ben's suggestion to allow it). > > - If there is only one body left, then remove the multipart/mixed wrapper. > > - Send the remaining stuff. This seems like the ad hoc approach. It will probably work in a lot of cases. In the absence of more general rules this is probably a pragmatic approach to take. But I think there is a more general problem - not specific to message exploders, or exploders, or message - that applies to management of body parts in general. Part of it is just: - in a hierarchy of mime entities, how do I identify the body parts that interest me? And the flip side of that is: - How do I arrange the body parts that I need to convey into a hierarchy of mime entities so that the recipient will find and process them correctly? This is then further complicated by servers in the signaling path that are permitted to mess with body parts. (That currently is only B2BUAs, but with the m2m and m2e discussions it may eventually include proxies.) For them there are the following additional questions: - Should I (and if so how) modify the mime entity hierarchy to remove body parts that I have processed? - How should I modify the mime entity hierarchy to add additional body parts that are to be processed further downstream, so that the recipient will process them correctly? >> There are more complex cases: >> >> - for security there could be signed body parts. >> >> - The signature could be on the multipart containing the message >> and list. It would have to be removed. >> >> - The signature could be on just the message. Presumably >> it should remain. > > > > > I agree. > >> >> - There could be other body parts referenced by cid: urls in >> other headers in the message. > > > Yes, they should remain. > >> >> I think there needs to be a more prescriptive way of defining what >> gets passed on in the exploded messages. This is really just a >> manifestation of a more general problem of how to decide how different >> body parts should be processed. It potentially exists in a normal, >> unexploded, MESSAGE. >> >> I think at least part of the answer lies with Content-Disposition. I >> think there should be clarity about the content-disposition should be >> for the body part(s) that MESSAGE interprets as message content. >> Probably "render" (which is default for sip) would be an appropriate >> content-disposition for message content. > > > Agree so far. It may happen that some of this stuff is generic enough > (not MESSAGE specific). Yes, very much so. >> Also, I think there should be some clarity about what the >> content-disposition should be for various kinds of multipart >> containers when used in the various ways they may be used in sip. I'm >> not quite sure what the answer is here. >> >> The list itself is of course referenced from a cid: url. It is the url >> and its placement that determines how the corresponding body part >> should be processed. For these, the content-disposition should be some >> value that doesn't imply some other sort of processing. I think it >> can't be any of "session", "render", "alert", or "icon". Maybe it >> could be "attachment". > > > I will be happy to have a very clear deterministic way to find out what > to pass and what to keep to the other side of the exploder, base on > presumabley the content-disposition. Let's see if I can come up with > something. I'm interested in this. Do you think this is suitable as a new work item? (Probably for sipping at first.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 21 19:24:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29890 for ; Wed, 21 Apr 2004 19:24:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGR50-0005bq-13 for simple-archive@ietf.org; Wed, 21 Apr 2004 19:24:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGR4D-0005Og-00 for simple-archive@ietf.org; Wed, 21 Apr 2004 19:23:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGR3L-0005Ah-00; Wed, 21 Apr 2004 19:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQgI-0003GW-07; Wed, 21 Apr 2004 18:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQNd-0001lk-JL for simple@optimus.ietf.org; Wed, 21 Apr 2004 18:39:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26182 for ; Wed, 21 Apr 2004 18:39:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQNa-0003MA-J2 for simple@ietf.org; Wed, 21 Apr 2004 18:39:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQMf-00037K-00 for simple@ietf.org; Wed, 21 Apr 2004 18:38:46 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGQLn-0002rJ-00 for simple@ietf.org; Wed, 21 Apr 2004 18:37:51 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 14:47:57 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LMbJW9016640 for ; Wed, 21 Apr 2004 15:37:20 -0700 (PDT) Received: from [128.107.170.235] ([128.107.170.235]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOH68477; Wed, 21 Apr 2004 15:37:18 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] WGLC on isComposing draft From: Cullen Jennings To: Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 15:37:17 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I had a quick read of this and I like it. One questions on correlating with the message. Say I opened a windows, a is composing message was sent, call this M1, then I very quickly typed a message and this got sent, call this M2. Not idle message is sent. Now the network might deliver M2 ahead of M1. The client receiving these would display the text from M2 then show that the other side was composing when really it was not. This might be a weird corner case not worth solving. It could be solved with high resolution sender time in both M1 and M2. It could be solved with the is Composing passing on the message ID of the message that was being composed. I don't care if we choose to ignore this problem but thought it was worth mentioning. On 4/21/04 5:54 AM, "hisham.khartabil@nokia.com" wrote: > The WG chairs would like to start a Working Group Last Call on the following > drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt > > This WGLC will end on May 5th. > > Please send your comments to this mailing list and to the authors. > > If you reviewed the draft and found no issues, please indicate so also on the > mailing list. This will help us evaluate the level of review and group > consensus. > > Thanks, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 21 19:45:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01476 for ; Wed, 21 Apr 2004 19:45:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRJ1-0007mj-KE for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 19:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LNd3oC029921 for simple-archive@odin.ietf.org; Wed, 21 Apr 2004 19:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGR52-0008TQ-88 for simple-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 19:24:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29908 for ; Wed, 21 Apr 2004 19:24:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGR50-0005c2-MS for simple-web-archive@ietf.org; Wed, 21 Apr 2004 19:24:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGR4E-0005On-00 for simple-web-archive@ietf.org; Wed, 21 Apr 2004 19:23:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGR3L-0005Ah-00; Wed, 21 Apr 2004 19:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQgI-0003GW-07; Wed, 21 Apr 2004 18:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQNd-0001lk-JL for simple@optimus.ietf.org; Wed, 21 Apr 2004 18:39:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26182 for ; Wed, 21 Apr 2004 18:39:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQNa-0003MA-J2 for simple@ietf.org; Wed, 21 Apr 2004 18:39:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQMf-00037K-00 for simple@ietf.org; Wed, 21 Apr 2004 18:38:46 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGQLn-0002rJ-00 for simple@ietf.org; Wed, 21 Apr 2004 18:37:51 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 14:47:57 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LMbJW9016640 for ; Wed, 21 Apr 2004 15:37:20 -0700 (PDT) Received: from [128.107.170.235] ([128.107.170.235]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOH68477; Wed, 21 Apr 2004 15:37:18 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] WGLC on isComposing draft From: Cullen Jennings To: Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 15:37:17 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I had a quick read of this and I like it. One questions on correlating with the message. Say I opened a windows, a is composing message was sent, call this M1, then I very quickly typed a message and this got sent, call this M2. Not idle message is sent. Now the network might deliver M2 ahead of M1. The client receiving these would display the text from M2 then show that the other side was composing when really it was not. This might be a weird corner case not worth solving. It could be solved with high resolution sender time in both M1 and M2. It could be solved with the is Composing passing on the message ID of the message that was being composed. I don't care if we choose to ignore this problem but thought it was worth mentioning. On 4/21/04 5:54 AM, "hisham.khartabil@nokia.com" wrote: > The WG chairs would like to start a Working Group Last Call on the following > drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt > > This WGLC will end on May 5th. > > Please send your comments to this mailing list and to the authors. > > If you reviewed the draft and found no issues, please indicate so also on the > mailing list. This will help us evaluate the level of review and group > consensus. > > Thanks, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 05:33:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14239 for ; Thu, 22 Apr 2004 05:33:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGaag-0001fT-OP for simple-archive@ietf.org; Thu, 22 Apr 2004 05:33:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGaZh-0001Qf-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 05:32:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGaYy-0001Cx-00; Thu, 22 Apr 2004 05:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaPB-0006y1-FT; Thu, 22 Apr 2004 05:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaHE-0002Jh-AE for simple@optimus.ietf.org; Thu, 22 Apr 2004 05:13:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13608 for ; Thu, 22 Apr 2004 05:13:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGaH9-00052B-72 for simple@ietf.org; Thu, 22 Apr 2004 05:13:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGaGA-0004ng-00 for simple@ietf.org; Thu, 22 Apr 2004 05:12:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BGaFM-0004L5-00 for simple@ietf.org; Thu, 22 Apr 2004 05:11:52 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2004 02:11:25 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3M9BL0Q001135; Thu, 22 Apr 2004 02:11:22 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOI00680; Thu, 22 Apr 2004 02:11:20 -0700 (PDT) From: David Oran To: Cullen Jennings , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft Message-ID: <2147483647.1082610679@[10.32.245.156]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 05:11:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit It would be solved more elegantly by adding causal ordering to CPIM, which would also solve about 100 other related problems and allow distributed mixing for chat rooms as well. I suggested this a couple of years ago to Henning and others but we got sucked into a long thread about whether the combination of message-id and "in-reply-to" could do causal ordering and the inadequacies of message threading in email... Dave. --On Wednesday, April 21, 2004 3:37 PM -0700 Cullen Jennings wrote: > > I had a quick read of this and I like it. > > One questions on correlating with the message. Say I opened a windows, a > is composing message was sent, call this M1, then I very quickly typed a > message and this got sent, call this M2. Not idle message is sent. > > Now the network might deliver M2 ahead of M1. The client receiving these > would display the text from M2 then show that the other side was composing > when really it was not. > > This might be a weird corner case not worth solving. It could be solved > with high resolution sender time in both M1 and M2. It could be solved > with the is Composing passing on the message ID of the message that was > being composed. > > I don't care if we choose to ignore this problem but thought it was worth > mentioning. > > > > On 4/21/04 5:54 AM, "hisham.khartabil@nokia.com" > wrote: > >> The WG chairs would like to start a Working Group Last Call on the >> following drafts: >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >> >> This WGLC will end on May 5th. >> >> Please send your comments to this mailing list and to the authors. >> >> If you reviewed the draft and found no issues, please indicate so also >> on the mailing list. This will help us evaluate the level of review and >> group consensus. >> >> Thanks, >> Hisham >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 05:37:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14461 for ; Thu, 22 Apr 2004 05:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGacK-00046E-G9 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 05:35:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M9Zafi015754 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 05:35:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaam-0003Cj-Kl for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 05:34:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14257 for ; Thu, 22 Apr 2004 05:33:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGaah-0001fa-AX for simple-web-archive@ietf.org; Thu, 22 Apr 2004 05:33:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGaZh-0001Qm-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 05:32:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGaYy-0001Cx-00; Thu, 22 Apr 2004 05:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaPB-0006y1-FT; Thu, 22 Apr 2004 05:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGaHE-0002Jh-AE for simple@optimus.ietf.org; Thu, 22 Apr 2004 05:13:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13608 for ; Thu, 22 Apr 2004 05:13:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGaH9-00052B-72 for simple@ietf.org; Thu, 22 Apr 2004 05:13:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGaGA-0004ng-00 for simple@ietf.org; Thu, 22 Apr 2004 05:12:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BGaFM-0004L5-00 for simple@ietf.org; Thu, 22 Apr 2004 05:11:52 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2004 02:11:25 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3M9BL0Q001135; Thu, 22 Apr 2004 02:11:22 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOI00680; Thu, 22 Apr 2004 02:11:20 -0700 (PDT) From: David Oran To: Cullen Jennings , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft Message-ID: <2147483647.1082610679@[10.32.245.156]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 05:11:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It would be solved more elegantly by adding causal ordering to CPIM, which would also solve about 100 other related problems and allow distributed mixing for chat rooms as well. I suggested this a couple of years ago to Henning and others but we got sucked into a long thread about whether the combination of message-id and "in-reply-to" could do causal ordering and the inadequacies of message threading in email... Dave. --On Wednesday, April 21, 2004 3:37 PM -0700 Cullen Jennings wrote: > > I had a quick read of this and I like it. > > One questions on correlating with the message. Say I opened a windows, a > is composing message was sent, call this M1, then I very quickly typed a > message and this got sent, call this M2. Not idle message is sent. > > Now the network might deliver M2 ahead of M1. The client receiving these > would display the text from M2 then show that the other side was composing > when really it was not. > > This might be a weird corner case not worth solving. It could be solved > with high resolution sender time in both M1 and M2. It could be solved > with the is Composing passing on the message ID of the message that was > being composed. > > I don't care if we choose to ignore this problem but thought it was worth > mentioning. > > > > On 4/21/04 5:54 AM, "hisham.khartabil@nokia.com" > wrote: > >> The WG chairs would like to start a Working Group Last Call on the >> following drafts: >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >> >> This WGLC will end on May 5th. >> >> Please send your comments to this mailing list and to the authors. >> >> If you reviewed the draft and found no issues, please indicate so also >> on the mailing list. This will help us evaluate the level of review and >> group consensus. >> >> Thanks, >> Hisham >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 08:40:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22998 for ; Thu, 22 Apr 2004 08:40:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdVb-0000sq-DP for simple-archive@ietf.org; Thu, 22 Apr 2004 08:40:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdUk-0000eV-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 08:39:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdTt-0000Qi-00; Thu, 22 Apr 2004 08:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdL9-0004bx-6g; Thu, 22 Apr 2004 08:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdFG-0002p1-6l for simple@optimus.ietf.org; Thu, 22 Apr 2004 08:23:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21549 for ; Thu, 22 Apr 2004 08:23:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdF9-00047Z-74 for simple@ietf.org; Thu, 22 Apr 2004 08:23:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdEH-0003tZ-00 for simple@ietf.org; Thu, 22 Apr 2004 08:22:57 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGdDW-0003fW-00 for simple@ietf.org; Thu, 22 Apr 2004 08:22:10 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MCLx627173; Thu, 22 Apr 2004 15:21:59 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 15:21:50 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3MCLop0015505; Thu, 22 Apr 2004 15:21:50 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00rqRaoo; Thu, 22 Apr 2004 15:21:48 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MCLiF25831; Thu, 22 Apr 2004 15:21:44 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 15:21:46 +0300 Message-ID: <4087B8DA.2010202@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: hgs@cs.columbia.edu CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 12:21:46.0691 (UTC) FILETIME=[61441930:01C42864] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:21:46 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henning: Is there a reason why the schema does no have a maxOccurs attribute set to 1 for the "state" and "lastactive" elements, whereas other elements have it? I guess there should be just one state element, and if a lastactive element is present, there should be just one. Then I question the usage of the "contenttype" element. I can envision systems where I can start typing a text message and then drag and drop any object (audio or video file). The application will first generate an istyping message with the "contenttype" element presumably set to text, which is not correct, because I dragged some object later. I doubt about the usability of this feature. Furthermore, no application will be able to a priori determine whether the user us typing text/plain or text/html, as a user could just add an html tag afterwords. A conservative application will notify only "text", which as I said before, might not even be true. On the format of the draft, I believe newcomers will find hard to read the document with the current structure. It assumes a lot of previous reading. It is nowhere written that the isComposing indication is carried in an XML document composed according to the schema defined in section 6 (it is just assumed). The Content-Type is never introduced in the text, just registered in section 8. The example precedes the schema definition (I believe the example should be at the end of the document). I am also missing the normative statements saying something on the following lines: An isComposing document is an XML document that MUST be well-formed and SHOULD be valid. isComposing documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying isComposing documents The namespace URI for elements defined for this purpose is a URN, using the namespace identifier 'ietf'. This URN is: urn:ietf:params:xml:ns:sip-iscomposing BR, Miguel ext hisham.khartabil@nokia.com wrote: > The WG chairs would like to start a Working Group Last Call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt > > This WGLC will end on May 5th. > > Please send your comments to this mailing list and to the authors. > > If you reviewed the draft and found no issues, please indicate so also on the mailing list. This will help us evaluate the level of review and group consensus. > > Thanks, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 08:53:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23703 for ; Thu, 22 Apr 2004 08:53:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdiC-0004N9-Bh for simple-archive@ietf.org; Thu, 22 Apr 2004 08:53:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdhB-00045P-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 08:52:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdgD-0003pZ-00; Thu, 22 Apr 2004 08:51:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdWo-0007bk-St; Thu, 22 Apr 2004 08:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdPd-0005E5-Vn for simple@optimus.ietf.org; Thu, 22 Apr 2004 08:34:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22208 for ; Thu, 22 Apr 2004 08:34:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdPW-0006oB-GT for simple@ietf.org; Thu, 22 Apr 2004 08:34:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdNI-0006Iw-00 for simple@ietf.org; Thu, 22 Apr 2004 08:32:17 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BGdM2-0005gK-00; Thu, 22 Apr 2004 08:30:58 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i3MCULfX001167; Thu, 22 Apr 2004 07:30:21 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.44]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J170J6QL; Thu, 22 Apr 2004 07:30:01 -0500 Message-ID: <4087BADB.70004@ericsson.com> X-Sybari-Trust: d9940463 2c4885b5 0a80fa4f 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Miguel Garcia , SIMPLE mailing list , SIPPING mailing list References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> <4086E14A.6080403@cisco.com> In-Reply-To: <4086E14A.6080403@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Managing multiple body parts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:30:19 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Paul, typically you either tag the body with a content disposition tag, or have a pointer somewhere in the message pointing to the body part... or both. What sort of things do you have in mind, besides the ones I mentioned? Thanks, Gonzalo Paul Kyzivat wrote: > I changed the subject of this because it is generalized. > > See below for details. The general question is: > > Is there a need for some sort of draft (beyond what is already in 3261) > explaining how body parts are to be arranged and tagged so that they > will be found and processed in an interoperable way? > > I think there is. I have spent time working on sip stack support for > managing body parts, and I came up with all kinds of questions about > what is valid and what is not. > > Paul > > Miguel Garcia wrote: > >> Hi Paul: >> >> Thanks for your comments. Answers inline. >> >> ext Paul Kyzivat wrote: >> >>> Miguel, >>> >>> In general the approach in the draft seems reasonable to me. >>> >>> I see one area of ambiguity, having to do with how multipart bodies >>> are handled. The draft says to remove the list and include everything >>> else. But even your example doesn't do that - it also removes the >>> multipart/mixed wrapper. Of course in this particular example that >>> makes perfect sense, but it goes beyond what the draft says to do. >> >> >> >> We start from the the fact that there will be as a minimum, two >> bodies, the list, and the actual payload. There might be more bodies, >> such as multiple payloads, S/MIME signatures, etc. >> >> I guess the algorithm should be: >> >> - If there is any kind of security body for the exploder (e.g., signed >> with the public key of the exploder), then remove that body. >> >> - Remove the list itself (in a typical use case, unless an extension >> says the oposite; I am referring to Ben's suggestion to allow it). >> >> - If there is only one body left, then remove the multipart/mixed >> wrapper. >> >> - Send the remaining stuff. > > > This seems like the ad hoc approach. It will probably work in a lot of > cases. In the absence of more general rules this is probably a pragmatic > approach to take. > > But I think there is a more general problem - not specific to message > exploders, or exploders, or message - that applies to management of body > parts in general. > > Part of it is just: > - in a hierarchy of mime entities, how do I identify the body parts that > interest me? > > And the flip side of that is: > - How do I arrange the body parts that I need to convey into a hierarchy > of mime entities so that the recipient will find and process them > correctly? > > This is then further complicated by servers in the signaling path that > are permitted to mess with body parts. (That currently is only B2BUAs, > but with the m2m and m2e discussions it may eventually include proxies.) > For them there are the following additional questions: > > - Should I (and if so how) modify the mime entity hierarchy to remove > body parts that I have processed? > > - How should I modify the mime entity hierarchy to add additional body > parts that are to be processed further downstream, so that the recipient > will process them correctly? > >>> There are more complex cases: >>> >>> - for security there could be signed body parts. >>> >>> - The signature could be on the multipart containing the message >>> and list. It would have to be removed. >>> >>> - The signature could be on just the message. Presumably >>> it should remain. >> >> >> > >> >> I agree. >> >>> >>> - There could be other body parts referenced by cid: urls in >>> other headers in the message. >> >> >> >> Yes, they should remain. >> >>> >>> I think there needs to be a more prescriptive way of defining what >>> gets passed on in the exploded messages. This is really just a >>> manifestation of a more general problem of how to decide how >>> different body parts should be processed. It potentially exists in a >>> normal, unexploded, MESSAGE. >>> >>> I think at least part of the answer lies with Content-Disposition. I >>> think there should be clarity about the content-disposition should be >>> for the body part(s) that MESSAGE interprets as message content. >>> Probably "render" (which is default for sip) would be an appropriate >>> content-disposition for message content. >> >> >> >> Agree so far. It may happen that some of this stuff is generic enough >> (not MESSAGE specific). > > > Yes, very much so. > >>> Also, I think there should be some clarity about what the >>> content-disposition should be for various kinds of multipart >>> containers when used in the various ways they may be used in sip. I'm >>> not quite sure what the answer is here. >>> >>> The list itself is of course referenced from a cid: url. It is the >>> url and its placement that determines how the corresponding body part >>> should be processed. For these, the content-disposition should be >>> some value that doesn't imply some other sort of processing. I think >>> it can't be any of "session", "render", "alert", or "icon". Maybe it >>> could be "attachment". >> >> >> >> I will be happy to have a very clear deterministic way to find out >> what to pass and what to keep to the other side of the exploder, base >> on presumabley the content-disposition. Let's see if I can come up >> with something. > > > I'm interested in this. Do you think this is suitable as a new work > item? (Probably for sipping at first.) > > Paul -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 08:56:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23993 for ; Thu, 22 Apr 2004 08:56:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdbE-0000ON-GT for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 08:46:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MCkeA9001495 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 08:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdVj-0007B1-2o for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 08:40:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23015 for ; Thu, 22 Apr 2004 08:40:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdVc-0000sv-3K for simple-web-archive@ietf.org; Thu, 22 Apr 2004 08:40:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdUl-0000ed-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 08:40:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdTt-0000Qi-00; Thu, 22 Apr 2004 08:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdL9-0004bx-6g; Thu, 22 Apr 2004 08:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdFG-0002p1-6l for simple@optimus.ietf.org; Thu, 22 Apr 2004 08:23:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21549 for ; Thu, 22 Apr 2004 08:23:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdF9-00047Z-74 for simple@ietf.org; Thu, 22 Apr 2004 08:23:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdEH-0003tZ-00 for simple@ietf.org; Thu, 22 Apr 2004 08:22:57 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGdDW-0003fW-00 for simple@ietf.org; Thu, 22 Apr 2004 08:22:10 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MCLx627173; Thu, 22 Apr 2004 15:21:59 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 15:21:50 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3MCLop0015505; Thu, 22 Apr 2004 15:21:50 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00rqRaoo; Thu, 22 Apr 2004 15:21:48 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MCLiF25831; Thu, 22 Apr 2004 15:21:44 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 15:21:46 +0300 Message-ID: <4087B8DA.2010202@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: hgs@cs.columbia.edu CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 12:21:46.0691 (UTC) FILETIME=[61441930:01C42864] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:21:46 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning: Is there a reason why the schema does no have a maxOccurs attribute set to 1 for the "state" and "lastactive" elements, whereas other elements have it? I guess there should be just one state element, and if a lastactive element is present, there should be just one. Then I question the usage of the "contenttype" element. I can envision systems where I can start typing a text message and then drag and drop any object (audio or video file). The application will first generate an istyping message with the "contenttype" element presumably set to text, which is not correct, because I dragged some object later. I doubt about the usability of this feature. Furthermore, no application will be able to a priori determine whether the user us typing text/plain or text/html, as a user could just add an html tag afterwords. A conservative application will notify only "text", which as I said before, might not even be true. On the format of the draft, I believe newcomers will find hard to read the document with the current structure. It assumes a lot of previous reading. It is nowhere written that the isComposing indication is carried in an XML document composed according to the schema defined in section 6 (it is just assumed). The Content-Type is never introduced in the text, just registered in section 8. The example precedes the schema definition (I believe the example should be at the end of the document). I am also missing the normative statements saying something on the following lines: An isComposing document is an XML document that MUST be well-formed and SHOULD be valid. isComposing documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying isComposing documents The namespace URI for elements defined for this purpose is a URN, using the namespace identifier 'ietf'. This URN is: urn:ietf:params:xml:ns:sip-iscomposing BR, Miguel ext hisham.khartabil@nokia.com wrote: > The WG chairs would like to start a Working Group Last Call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt > > This WGLC will end on May 5th. > > Please send your comments to this mailing list and to the authors. > > If you reviewed the draft and found no issues, please indicate so also on the mailing list. This will help us evaluate the level of review and group consensus. > > Thanks, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 09:04:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24438 for ; Thu, 22 Apr 2004 09:04:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdpJ-0005q5-E2 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 09:01:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MD1D7C022441 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 09:01:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdiL-0003bG-7r for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 08:54:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23721 for ; Thu, 22 Apr 2004 08:53:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdiE-0004NU-5B for simple-web-archive@ietf.org; Thu, 22 Apr 2004 08:53:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdhD-00045W-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 08:52:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdgD-0003pZ-00; Thu, 22 Apr 2004 08:51:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdWo-0007bk-St; Thu, 22 Apr 2004 08:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdPd-0005E5-Vn for simple@optimus.ietf.org; Thu, 22 Apr 2004 08:34:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22208 for ; Thu, 22 Apr 2004 08:34:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdPW-0006oB-GT for simple@ietf.org; Thu, 22 Apr 2004 08:34:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdNI-0006Iw-00 for simple@ietf.org; Thu, 22 Apr 2004 08:32:17 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BGdM2-0005gK-00; Thu, 22 Apr 2004 08:30:58 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i3MCULfX001167; Thu, 22 Apr 2004 07:30:21 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.44]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J170J6QL; Thu, 22 Apr 2004 07:30:01 -0500 Message-ID: <4087BADB.70004@ericsson.com> X-Sybari-Trust: d9940463 2c4885b5 0a80fa4f 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Miguel Garcia , SIMPLE mailing list , SIPPING mailing list References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> <4086E14A.6080403@cisco.com> In-Reply-To: <4086E14A.6080403@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Managing multiple body parts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:30:19 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Paul, typically you either tag the body with a content disposition tag, or have a pointer somewhere in the message pointing to the body part... or both. What sort of things do you have in mind, besides the ones I mentioned? Thanks, Gonzalo Paul Kyzivat wrote: > I changed the subject of this because it is generalized. > > See below for details. The general question is: > > Is there a need for some sort of draft (beyond what is already in 3261) > explaining how body parts are to be arranged and tagged so that they > will be found and processed in an interoperable way? > > I think there is. I have spent time working on sip stack support for > managing body parts, and I came up with all kinds of questions about > what is valid and what is not. > > Paul > > Miguel Garcia wrote: > >> Hi Paul: >> >> Thanks for your comments. Answers inline. >> >> ext Paul Kyzivat wrote: >> >>> Miguel, >>> >>> In general the approach in the draft seems reasonable to me. >>> >>> I see one area of ambiguity, having to do with how multipart bodies >>> are handled. The draft says to remove the list and include everything >>> else. But even your example doesn't do that - it also removes the >>> multipart/mixed wrapper. Of course in this particular example that >>> makes perfect sense, but it goes beyond what the draft says to do. >> >> >> >> We start from the the fact that there will be as a minimum, two >> bodies, the list, and the actual payload. There might be more bodies, >> such as multiple payloads, S/MIME signatures, etc. >> >> I guess the algorithm should be: >> >> - If there is any kind of security body for the exploder (e.g., signed >> with the public key of the exploder), then remove that body. >> >> - Remove the list itself (in a typical use case, unless an extension >> says the oposite; I am referring to Ben's suggestion to allow it). >> >> - If there is only one body left, then remove the multipart/mixed >> wrapper. >> >> - Send the remaining stuff. > > > This seems like the ad hoc approach. It will probably work in a lot of > cases. In the absence of more general rules this is probably a pragmatic > approach to take. > > But I think there is a more general problem - not specific to message > exploders, or exploders, or message - that applies to management of body > parts in general. > > Part of it is just: > - in a hierarchy of mime entities, how do I identify the body parts that > interest me? > > And the flip side of that is: > - How do I arrange the body parts that I need to convey into a hierarchy > of mime entities so that the recipient will find and process them > correctly? > > This is then further complicated by servers in the signaling path that > are permitted to mess with body parts. (That currently is only B2BUAs, > but with the m2m and m2e discussions it may eventually include proxies.) > For them there are the following additional questions: > > - Should I (and if so how) modify the mime entity hierarchy to remove > body parts that I have processed? > > - How should I modify the mime entity hierarchy to add additional body > parts that are to be processed further downstream, so that the recipient > will process them correctly? > >>> There are more complex cases: >>> >>> - for security there could be signed body parts. >>> >>> - The signature could be on the multipart containing the message >>> and list. It would have to be removed. >>> >>> - The signature could be on just the message. Presumably >>> it should remain. >> >> >> > >> >> I agree. >> >>> >>> - There could be other body parts referenced by cid: urls in >>> other headers in the message. >> >> >> >> Yes, they should remain. >> >>> >>> I think there needs to be a more prescriptive way of defining what >>> gets passed on in the exploded messages. This is really just a >>> manifestation of a more general problem of how to decide how >>> different body parts should be processed. It potentially exists in a >>> normal, unexploded, MESSAGE. >>> >>> I think at least part of the answer lies with Content-Disposition. I >>> think there should be clarity about the content-disposition should be >>> for the body part(s) that MESSAGE interprets as message content. >>> Probably "render" (which is default for sip) would be an appropriate >>> content-disposition for message content. >> >> >> >> Agree so far. It may happen that some of this stuff is generic enough >> (not MESSAGE specific). > > > Yes, very much so. > >>> Also, I think there should be some clarity about what the >>> content-disposition should be for various kinds of multipart >>> containers when used in the various ways they may be used in sip. I'm >>> not quite sure what the answer is here. >>> >>> The list itself is of course referenced from a cid: url. It is the >>> url and its placement that determines how the corresponding body part >>> should be processed. For these, the content-disposition should be >>> some value that doesn't imply some other sort of processing. I think >>> it can't be any of "session", "render", "alert", or "icon". Maybe it >>> could be "attachment". >> >> >> >> I will be happy to have a very clear deterministic way to find out >> what to pass and what to keep to the other side of the exploder, base >> on presumabley the content-disposition. Let's see if I can come up >> with something. > > > I'm interested in this. Do you think this is suitable as a new work > item? (Probably for sipping at first.) > > Paul -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 10:42:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01353 for ; Thu, 22 Apr 2004 10:42:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfPk-0001om-Ti for simple-archive@ietf.org; Thu, 22 Apr 2004 10:42:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfOn-0001Ur-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 10:41:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGfNk-00018b-00; Thu, 22 Apr 2004 10:40:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGf9S-0004th-24; Thu, 22 Apr 2004 10:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeuv-0005sD-Kn for simple@optimus.ietf.org; Thu, 22 Apr 2004 10:11:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28626 for ; Thu, 22 Apr 2004 10:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGeun-0000zs-Mb for simple@ietf.org; Thu, 22 Apr 2004 10:10:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeto-0000jj-00 for simple@ietf.org; Thu, 22 Apr 2004 10:09:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BGesw-0000GG-00 for simple@ietf.org; Thu, 22 Apr 2004 10:09:02 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 22 Apr 2004 07:07:38 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3ME8W6L000622; Thu, 22 Apr 2004 10:08:32 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU21480; Thu, 22 Apr 2004 10:08:30 -0400 (EDT) Message-ID: <4087D1DE.5020601@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 10:08:30 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Miguel Garcia wrote: [snip] > Then I question the usage of the "contenttype" element. I can envision > systems where I can start typing a text message and then drag and drop > any object (audio or video file). The application will first generate an > istyping message with the "contenttype" element presumably set to text, > which is not correct, It would be correct at the time it is sent. There is never any guarantee that the typing will result in a message being sent at all, much less what type. > because I dragged some object later. When you drag in an object of some other type, your client will need to reconsider what the content type is. Then it could send a new isComposing message with the new content type. > I doubt about the usability of this feature. Well, I agree it isn't clear what the recipient would do with the content type information. But other than consuming bandwidth it doesn't hurt. > Furthermore, no application will be able to a priori determine whether > the user us typing text/plain or text/html, as a user could just add an > html tag afterwords. Adding html tags doesn't make the content type html. The sending application will have to decide to set the content type to text/html. It *might* do that by inspecting the message for html tags, but I would find that surprising. I would imagine that some application control would need to be selected to cause this to happen. In any case, as with the drag/drop case above, if/when the application decides on a different content type than it previously communicated, it can send another isComposing with the new content type. But if the decision isn't made until the message is sent then presumably it wouldn't bother. It might not bother in any case. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 10:54:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02066 for ; Thu, 22 Apr 2004 10:54:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfaT-0004pH-NL for simple-archive@ietf.org; Thu, 22 Apr 2004 10:54:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfZb-0004XY-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 10:53:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGfYe-0004GW-00; Thu, 22 Apr 2004 10:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfSk-0002Q5-CP; Thu, 22 Apr 2004 10:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfAU-0005Gs-EV for simple@optimus.ietf.org; Thu, 22 Apr 2004 10:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00084 for ; Thu, 22 Apr 2004 10:27:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfAM-0005BO-D2 for simple@ietf.org; Thu, 22 Apr 2004 10:27:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGf9W-0004vh-00 for simple@ietf.org; Thu, 22 Apr 2004 10:26:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGf8n-0004dC-00 for simple@ietf.org; Thu, 22 Apr 2004 10:25:25 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 06:36:52 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3MEOsC1002174; Thu, 22 Apr 2004 07:24:54 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU22979; Thu, 22 Apr 2004 10:24:53 -0400 (EDT) Message-ID: <4087D5B4.60302@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Oran CC: Cullen Jennings , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2147483647.1082610679@[10.32.245.156]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 10:24:52 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit David Oran wrote: > It would be solved more elegantly by adding causal ordering to CPIM, > which would also solve about 100 other related problems and allow > distributed mixing for chat rooms as well. > > I suggested this a couple of years ago to Henning and others but we got > sucked into a long thread about whether the combination of message-id > and "in-reply-to" could do causal ordering and the inadequacies of > message threading in email... Well, we could resume that discussion. :-) It would require a more sophisticated client application that is typically seen for IM before the application could even generate in-reply-to. That might be more complex than the typical IM user would want. If we want to tackle this problem, then I think there will need to be flexible mechanisms that can be used by the client application based on what understanding it has of the ordering dependencies. Its probably best to leave the solution of this problem to later. Note that this is less of a problem with MSRP because it imposes an ordering on messages within the session. One might argue that isComposing is only appropriate with session oriented messaging and shouldn't be used with page mode. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 10:57:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02286 for ; Thu, 22 Apr 2004 10:57:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfe5-0005nV-E4 for simple-archive@ietf.org; Thu, 22 Apr 2004 10:57:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfcV-0005OC-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 10:56:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGfbc-000574-00; Thu, 22 Apr 2004 10:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfSl-0002Qb-Hn; Thu, 22 Apr 2004 10:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfBL-0005UU-Ce for simple@optimus.ietf.org; Thu, 22 Apr 2004 10:28:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00101 for ; Thu, 22 Apr 2004 10:27:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfBD-0005RI-Bc for simple@ietf.org; Thu, 22 Apr 2004 10:27:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfAF-0005AS-00 for simple@ietf.org; Thu, 22 Apr 2004 10:26:56 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGf9I-0004tt-00 for simple@ietf.org; Thu, 22 Apr 2004 10:25:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MEOlG22078; Thu, 22 Apr 2004 17:24:47 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 17:24:42 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3MEOg4g025336; Thu, 22 Apr 2004 17:24:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 009KW9MT; Thu, 22 Apr 2004 17:24:41 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MEOcs01721; Thu, 22 Apr 2004 17:24:38 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 17:24:36 +0300 Message-ID: <4087D5A3.5040609@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Paul Kyzivat CC: hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> <4087D1DE.5020601@cisco.com> In-Reply-To: <4087D1DE.5020601@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 14:24:36.0695 (UTC) FILETIME=[8A217670:01C42875] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 17:24:35 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Well, so let me try to see if understand. We are adding a feature that just uses bandwidth, because it represents some information that is able to change so oftenly that may require to be updated oftenly. Furthermore, it is not clear what the receiver can do with such information. Will an application at the receiver's indicate "Miguel is composing audio" or "Miguel is composing video" ? I don't think that is useful. Mmmm... in these days of wireless devices and saving bandwidth, this element seems to go against those principles. /Miguel ext Paul Kyzivat wrote: > > > Miguel Garcia wrote: > [snip] > >> Then I question the usage of the "contenttype" element. I can envision >> systems where I can start typing a text message and then drag and drop >> any object (audio or video file). The application will first generate >> an istyping message with the "contenttype" element presumably set to >> text, which is not correct, > > > It would be correct at the time it is sent. There is never any guarantee > that the typing will result in a message being sent at all, much less > what type. > > > because I dragged some object later. > > When you drag in an object of some other type, your client will need to > reconsider what the content type is. Then it could send a new > isComposing message with the new content type. > > > I doubt about the usability of this feature. > > Well, I agree it isn't clear what the recipient would do with the > content type information. But other than consuming bandwidth it doesn't > hurt. > >> Furthermore, no application will be able to a priori determine whether >> the user us typing text/plain or text/html, as a user could just add >> an html tag afterwords. > > > Adding html tags doesn't make the content type html. The sending > application will have to decide to set the content type to text/html. It > *might* do that by inspecting the message for html tags, but I would > find that surprising. I would imagine that some application control > would need to be selected to cause this to happen. > > In any case, as with the drag/drop case above, if/when the application > decides on a different content type than it previously communicated, it > can send another isComposing with the new content type. But if the > decision isn't made until the message is sent then presumably it > wouldn't bother. It might not bother in any case. > > Paul > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 11:00:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02878 for ; Thu, 22 Apr 2004 11:00:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfTd-0002xW-MN for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 10:46:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MEkv4e011374 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 10:46:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfPt-0001WS-Fq for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 10:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01370 for ; Thu, 22 Apr 2004 10:42:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfPl-0001os-Fy for simple-web-archive@ietf.org; Thu, 22 Apr 2004 10:42:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfOn-0001Uz-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 10:41:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGfNk-00018b-00; Thu, 22 Apr 2004 10:40:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGf9S-0004th-24; Thu, 22 Apr 2004 10:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeuv-0005sD-Kn for simple@optimus.ietf.org; Thu, 22 Apr 2004 10:11:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28626 for ; Thu, 22 Apr 2004 10:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGeun-0000zs-Mb for simple@ietf.org; Thu, 22 Apr 2004 10:10:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeto-0000jj-00 for simple@ietf.org; Thu, 22 Apr 2004 10:09:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BGesw-0000GG-00 for simple@ietf.org; Thu, 22 Apr 2004 10:09:02 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 22 Apr 2004 07:07:38 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3ME8W6L000622; Thu, 22 Apr 2004 10:08:32 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU21480; Thu, 22 Apr 2004 10:08:30 -0400 (EDT) Message-ID: <4087D1DE.5020601@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 10:08:30 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel Garcia wrote: [snip] > Then I question the usage of the "contenttype" element. I can envision > systems where I can start typing a text message and then drag and drop > any object (audio or video file). The application will first generate an > istyping message with the "contenttype" element presumably set to text, > which is not correct, It would be correct at the time it is sent. There is never any guarantee that the typing will result in a message being sent at all, much less what type. > because I dragged some object later. When you drag in an object of some other type, your client will need to reconsider what the content type is. Then it could send a new isComposing message with the new content type. > I doubt about the usability of this feature. Well, I agree it isn't clear what the recipient would do with the content type information. But other than consuming bandwidth it doesn't hurt. > Furthermore, no application will be able to a priori determine whether > the user us typing text/plain or text/html, as a user could just add an > html tag afterwords. Adding html tags doesn't make the content type html. The sending application will have to decide to set the content type to text/html. It *might* do that by inspecting the message for html tags, but I would find that surprising. I would imagine that some application control would need to be selected to cause this to happen. In any case, as with the drag/drop case above, if/when the application decides on a different content type than it previously communicated, it can send another isComposing with the new content type. But if the decision isn't made until the message is sent then presumably it wouldn't bother. It might not bother in any case. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 11:19:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04474 for ; Thu, 22 Apr 2004 11:19:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfmb-0007g8-Gx for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 11:06:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MF6Xl7029512 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 11:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfac-0004Es-Mk for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 10:54:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02089 for ; Thu, 22 Apr 2004 10:54:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfaU-0004pM-Cc for simple-web-archive@ietf.org; Thu, 22 Apr 2004 10:54:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfZc-0004Xg-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 10:53:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGfYe-0004GW-00; Thu, 22 Apr 2004 10:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfSk-0002Q5-CP; Thu, 22 Apr 2004 10:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfAU-0005Gs-EV for simple@optimus.ietf.org; Thu, 22 Apr 2004 10:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00084 for ; Thu, 22 Apr 2004 10:27:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfAM-0005BO-D2 for simple@ietf.org; Thu, 22 Apr 2004 10:27:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGf9W-0004vh-00 for simple@ietf.org; Thu, 22 Apr 2004 10:26:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGf8n-0004dC-00 for simple@ietf.org; Thu, 22 Apr 2004 10:25:25 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 06:36:52 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3MEOsC1002174; Thu, 22 Apr 2004 07:24:54 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU22979; Thu, 22 Apr 2004 10:24:53 -0400 (EDT) Message-ID: <4087D5B4.60302@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Oran CC: Cullen Jennings , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2147483647.1082610679@[10.32.245.156]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 10:24:52 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Oran wrote: > It would be solved more elegantly by adding causal ordering to CPIM, > which would also solve about 100 other related problems and allow > distributed mixing for chat rooms as well. > > I suggested this a couple of years ago to Henning and others but we got > sucked into a long thread about whether the combination of message-id > and "in-reply-to" could do causal ordering and the inadequacies of > message threading in email... Well, we could resume that discussion. :-) It would require a more sophisticated client application that is typically seen for IM before the application could even generate in-reply-to. That might be more complex than the typical IM user would want. If we want to tackle this problem, then I think there will need to be flexible mechanisms that can be used by the client application based on what understanding it has of the ordering dependencies. Its probably best to leave the solution of this problem to later. Note that this is less of a problem with MSRP because it imposes an ordering on messages within the session. One might argue that isComposing is only appropriate with session oriented messaging and shouldn't be used with page mode. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 11:25:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04993 for ; Thu, 22 Apr 2004 11:25:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGg4Z-0005bN-UX for simple-archive@ietf.org; Thu, 22 Apr 2004 11:25:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGg3e-0005J8-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 11:24:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGg2b-0004yn-00; Thu, 22 Apr 2004 11:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfnD-0007kg-6d; Thu, 22 Apr 2004 11:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfbd-0004PI-M4 for simple@optimus.ietf.org; Thu, 22 Apr 2004 10:55:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02178 for ; Thu, 22 Apr 2004 10:55:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfbV-00056a-G1 for simple@ietf.org; Thu, 22 Apr 2004 10:55:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfaj-0004qv-00 for simple@ietf.org; Thu, 22 Apr 2004 10:54:18 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BGfa5-0004Xc-00; Thu, 22 Apr 2004 10:53:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2004 07:53:14 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MEr6W9024399; Thu, 22 Apr 2004 07:53:07 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU25730; Thu, 22 Apr 2004 10:53:05 -0400 (EDT) Message-ID: <4087DC51.2050508@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Miguel Garcia , SIMPLE mailing list , SIPPING mailing list References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> <4086E14A.6080403@cisco.com> <4087BADB.70004@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Managing multiple body parts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 10:53:05 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hi Paul, > > typically you either tag the body with a content disposition tag, or > have a pointer somewhere in the message pointing to the body part... or > both. Note that even if you don't explicitly tag a body with a content disposition it implicitly has one, because there is a defaulting rule. > What sort of things do you have in mind, besides the ones I mentioned? Here are a few fuzzy issues: - what content-disposition should a multipart/mixed body have? Should the recipient always look inside one for interesting content, regardless of the disposition? - It is ok to nest body parts arbitrarily deep in nested multipart/mixed bodies? Or is there a cannonical way that body parts should be composed? - What should happen, in an invite, to a body part with content-type of application/sdp but with a content-disposition of something other than "session"? (E.g. "render".) - What should happen if an invite contains two body parts that both have content-type of application/sdp and content-disposition of session. (In a multipart/mixed, not multipart/alternative.) - What content-disposition should be used for the content of a MESSAGE message? A NOTIFY message? A SUBSCRIBE message? - What content-disposition should be used for multipart/signed and multipart/encrypted bodies? Should it match whatever it is that is signed or encrypted? - What content-disposition should be used for body parts that are referenced via a cid: uri somewhere in the message? - Does the fact that a body part is referenced by a cid: uri mean that it shouldn't also be processed as it would have been had it not been referenced by a cid: uri? What if the reference is from an extension header that the recipient doesn't understand? - The content-disposition header has a handling parameter. An error should be generated if any parts with handling=required aren't able to be processed. In the context of sip, how is a determination made whether a part has been processed? Is it sufficient that it be understood even if it isn't acted upon? I can probably come up with more, but that is a start. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 11:25:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05046 for ; Thu, 22 Apr 2004 11:25:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfow-000862-Er for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 11:08:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MF8wc1031117 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 11:08:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfeE-0004UT-D1 for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 10:57:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02304 for ; Thu, 22 Apr 2004 10:57:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfe6-0005nb-44 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 10:57:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfcW-0005OO-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 10:56:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGfbc-000574-00; Thu, 22 Apr 2004 10:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfSl-0002Qb-Hn; Thu, 22 Apr 2004 10:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfBL-0005UU-Ce for simple@optimus.ietf.org; Thu, 22 Apr 2004 10:28:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00101 for ; Thu, 22 Apr 2004 10:27:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfBD-0005RI-Bc for simple@ietf.org; Thu, 22 Apr 2004 10:27:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfAF-0005AS-00 for simple@ietf.org; Thu, 22 Apr 2004 10:26:56 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGf9I-0004tt-00 for simple@ietf.org; Thu, 22 Apr 2004 10:25:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MEOlG22078; Thu, 22 Apr 2004 17:24:47 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 17:24:42 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3MEOg4g025336; Thu, 22 Apr 2004 17:24:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 009KW9MT; Thu, 22 Apr 2004 17:24:41 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MEOcs01721; Thu, 22 Apr 2004 17:24:38 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 17:24:36 +0300 Message-ID: <4087D5A3.5040609@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Paul Kyzivat CC: hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> <4087D1DE.5020601@cisco.com> In-Reply-To: <4087D1DE.5020601@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 14:24:36.0695 (UTC) FILETIME=[8A217670:01C42875] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 17:24:35 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, so let me try to see if understand. We are adding a feature that just uses bandwidth, because it represents some information that is able to change so oftenly that may require to be updated oftenly. Furthermore, it is not clear what the receiver can do with such information. Will an application at the receiver's indicate "Miguel is composing audio" or "Miguel is composing video" ? I don't think that is useful. Mmmm... in these days of wireless devices and saving bandwidth, this element seems to go against those principles. /Miguel ext Paul Kyzivat wrote: > > > Miguel Garcia wrote: > [snip] > >> Then I question the usage of the "contenttype" element. I can envision >> systems where I can start typing a text message and then drag and drop >> any object (audio or video file). The application will first generate >> an istyping message with the "contenttype" element presumably set to >> text, which is not correct, > > > It would be correct at the time it is sent. There is never any guarantee > that the typing will result in a message being sent at all, much less > what type. > > > because I dragged some object later. > > When you drag in an object of some other type, your client will need to > reconsider what the content type is. Then it could send a new > isComposing message with the new content type. > > > I doubt about the usability of this feature. > > Well, I agree it isn't clear what the recipient would do with the > content type information. But other than consuming bandwidth it doesn't > hurt. > >> Furthermore, no application will be able to a priori determine whether >> the user us typing text/plain or text/html, as a user could just add >> an html tag afterwords. > > > Adding html tags doesn't make the content type html. The sending > application will have to decide to set the content type to text/html. It > *might* do that by inspecting the message for html tags, but I would > find that surprising. I would imagine that some application control > would need to be selected to cause this to happen. > > In any case, as with the drag/drop case above, if/when the application > decides on a different content type than it previously communicated, it > can send another isComposing with the new content type. But if the > decision isn't made until the message is sent then presumably it > wouldn't bother. It might not bother in any case. > > Paul > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 11:42:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06254 for ; Thu, 22 Apr 2004 11:42:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgKv-0002v7-Ol for simple-archive@ietf.org; Thu, 22 Apr 2004 11:42:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgJt-0002df-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 11:40:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGgIp-0002CJ-00; Thu, 22 Apr 2004 11:39:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgAH-0007fc-Bp; Thu, 22 Apr 2004 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfzl-0003kS-Qf for simple@optimus.ietf.org; Thu, 22 Apr 2004 11:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04503 for ; Thu, 22 Apr 2004 11:20:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfzi-00044l-Px for simple@ietf.org; Thu, 22 Apr 2004 11:20:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfyg-0003nq-00 for simple@ietf.org; Thu, 22 Apr 2004 11:19:03 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGfxf-0003YD-00 for simple@ietf.org; Thu, 22 Apr 2004 11:17:59 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MFHuA0021422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 11:17:57 -0400 (EDT) Message-ID: <4087E224.6070207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: ext Paul Kyzivat , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> <4087D1DE.5020601@cisco.com> <4087D5A3.5040609@nokia.com> In-Reply-To: <4087D5A3.5040609@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 11:17:56 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Two quick remarks: - A UA can decide not to send media type information if ten bytes of bandwidth break the bank or if you consider it difficult to generate in your particular implementation. - I don't see why this changes often unless you can't make up your mind whether you are composing a video, voice or text message and switch between those editors. - If you are sending a video or audio note, it is likely to be several orders of magnitude larger than the indication. Having the indication is helpful since it provides the receiver some warning. Think of an audio message - I can then turn the volume up or down before it blasts from my screen. Henning Miguel Garcia wrote: > Well, so let me try to see if understand. We are adding a feature that > just uses bandwidth, because it represents some information that is able > to change so oftenly that may require to be updated oftenly. > Furthermore, it is not clear what the receiver can do with such > information. Will an application at the receiver's indicate "Miguel is > composing audio" or "Miguel is composing video" ? I don't think that is > useful. > > Mmmm... in these days of wireless devices and saving bandwidth, this > element seems to go against those principles. > > /Miguel > > ext Paul Kyzivat wrote: > >> >> >> Miguel Garcia wrote: >> [snip] >> >>> Then I question the usage of the "contenttype" element. I can >>> envision systems where I can start typing a text message and then >>> drag and drop any object (audio or video file). The application will >>> first generate an istyping message with the "contenttype" element >>> presumably set to text, which is not correct, >> >> >> >> It would be correct at the time it is sent. There is never any >> guarantee that the typing will result in a message being sent at all, >> much less what type. >> >> > because I dragged some object later. >> >> When you drag in an object of some other type, your client will need >> to reconsider what the content type is. Then it could send a new >> isComposing message with the new content type. >> >> > I doubt about the usability of this feature. >> >> Well, I agree it isn't clear what the recipient would do with the >> content type information. But other than consuming bandwidth it >> doesn't hurt. >> >>> Furthermore, no application will be able to a priori determine >>> whether the user us typing text/plain or text/html, as a user could >>> just add an html tag afterwords. >> >> >> >> Adding html tags doesn't make the content type html. The sending >> application will have to decide to set the content type to text/html. >> It *might* do that by inspecting the message for html tags, but I >> would find that surprising. I would imagine that some application >> control would need to be selected to cause this to happen. >> >> In any case, as with the drag/drop case above, if/when the application >> decides on a different content type than it previously communicated, >> it can send another isComposing with the new content type. But if the >> decision isn't made until the message is sent then presumably it >> wouldn't bother. It might not bother in any case. >> >> Paul >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 11:42:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06278 for ; Thu, 22 Apr 2004 11:42:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgDz-0000dJ-K3 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 11:34:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MFYpim002425 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 11:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGg4d-0005wf-GM for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 11:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05011 for ; Thu, 22 Apr 2004 11:25:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGg4a-0005bS-HT for simple-web-archive@ietf.org; Thu, 22 Apr 2004 11:25:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGg3f-0005JG-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 11:24:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGg2b-0004yn-00; Thu, 22 Apr 2004 11:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfnD-0007kg-6d; Thu, 22 Apr 2004 11:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfbd-0004PI-M4 for simple@optimus.ietf.org; Thu, 22 Apr 2004 10:55:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02178 for ; Thu, 22 Apr 2004 10:55:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfbV-00056a-G1 for simple@ietf.org; Thu, 22 Apr 2004 10:55:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfaj-0004qv-00 for simple@ietf.org; Thu, 22 Apr 2004 10:54:18 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BGfa5-0004Xc-00; Thu, 22 Apr 2004 10:53:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2004 07:53:14 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MEr6W9024399; Thu, 22 Apr 2004 07:53:07 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU25730; Thu, 22 Apr 2004 10:53:05 -0400 (EDT) Message-ID: <4087DC51.2050508@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Miguel Garcia , SIMPLE mailing list , SIPPING mailing list References: <406DF1EC.4050400@cisco.com> <4085401C.2000008@nokia.com> <4086E14A.6080403@cisco.com> <4087BADB.70004@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Managing multiple body parts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 10:53:05 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hi Paul, > > typically you either tag the body with a content disposition tag, or > have a pointer somewhere in the message pointing to the body part... or > both. Note that even if you don't explicitly tag a body with a content disposition it implicitly has one, because there is a defaulting rule. > What sort of things do you have in mind, besides the ones I mentioned? Here are a few fuzzy issues: - what content-disposition should a multipart/mixed body have? Should the recipient always look inside one for interesting content, regardless of the disposition? - It is ok to nest body parts arbitrarily deep in nested multipart/mixed bodies? Or is there a cannonical way that body parts should be composed? - What should happen, in an invite, to a body part with content-type of application/sdp but with a content-disposition of something other than "session"? (E.g. "render".) - What should happen if an invite contains two body parts that both have content-type of application/sdp and content-disposition of session. (In a multipart/mixed, not multipart/alternative.) - What content-disposition should be used for the content of a MESSAGE message? A NOTIFY message? A SUBSCRIBE message? - What content-disposition should be used for multipart/signed and multipart/encrypted bodies? Should it match whatever it is that is signed or encrypted? - What content-disposition should be used for body parts that are referenced via a cid: uri somewhere in the message? - Does the fact that a body part is referenced by a cid: uri mean that it shouldn't also be processed as it would have been had it not been referenced by a cid: uri? What if the reference is from an extension header that the recipient doesn't understand? - The content-disposition header has a handling parameter. An error should be generated if any parts with handling=required aren't able to be processed. In the context of sip, how is a determination made whether a part has been processed? Is it sufficient that it be understood even if it isn't acted upon? I can probably come up with more, but that is a start. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 11:54:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07013 for ; Thu, 22 Apr 2004 11:54:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgSw-0005wV-Fn for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 11:50:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MFoI4n022839 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 11:50:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgKz-0003po-KO for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 11:42:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06272 for ; Thu, 22 Apr 2004 11:42:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgKw-0002vC-DX for simple-web-archive@ietf.org; Thu, 22 Apr 2004 11:42:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgJu-0002dn-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 11:40:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGgIp-0002CJ-00; Thu, 22 Apr 2004 11:39:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgAH-0007fc-Bp; Thu, 22 Apr 2004 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfzl-0003kS-Qf for simple@optimus.ietf.org; Thu, 22 Apr 2004 11:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04503 for ; Thu, 22 Apr 2004 11:20:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfzi-00044l-Px for simple@ietf.org; Thu, 22 Apr 2004 11:20:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfyg-0003nq-00 for simple@ietf.org; Thu, 22 Apr 2004 11:19:03 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGfxf-0003YD-00 for simple@ietf.org; Thu, 22 Apr 2004 11:17:59 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MFHuA0021422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 11:17:57 -0400 (EDT) Message-ID: <4087E224.6070207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: ext Paul Kyzivat , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> <4087D1DE.5020601@cisco.com> <4087D5A3.5040609@nokia.com> In-Reply-To: <4087D5A3.5040609@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 11:17:56 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Two quick remarks: - A UA can decide not to send media type information if ten bytes of bandwidth break the bank or if you consider it difficult to generate in your particular implementation. - I don't see why this changes often unless you can't make up your mind whether you are composing a video, voice or text message and switch between those editors. - If you are sending a video or audio note, it is likely to be several orders of magnitude larger than the indication. Having the indication is helpful since it provides the receiver some warning. Think of an audio message - I can then turn the volume up or down before it blasts from my screen. Henning Miguel Garcia wrote: > Well, so let me try to see if understand. We are adding a feature that > just uses bandwidth, because it represents some information that is able > to change so oftenly that may require to be updated oftenly. > Furthermore, it is not clear what the receiver can do with such > information. Will an application at the receiver's indicate "Miguel is > composing audio" or "Miguel is composing video" ? I don't think that is > useful. > > Mmmm... in these days of wireless devices and saving bandwidth, this > element seems to go against those principles. > > /Miguel > > ext Paul Kyzivat wrote: > >> >> >> Miguel Garcia wrote: >> [snip] >> >>> Then I question the usage of the "contenttype" element. I can >>> envision systems where I can start typing a text message and then >>> drag and drop any object (audio or video file). The application will >>> first generate an istyping message with the "contenttype" element >>> presumably set to text, which is not correct, >> >> >> >> It would be correct at the time it is sent. There is never any >> guarantee that the typing will result in a message being sent at all, >> much less what type. >> >> > because I dragged some object later. >> >> When you drag in an object of some other type, your client will need >> to reconsider what the content type is. Then it could send a new >> isComposing message with the new content type. >> >> > I doubt about the usability of this feature. >> >> Well, I agree it isn't clear what the recipient would do with the >> content type information. But other than consuming bandwidth it >> doesn't hurt. >> >>> Furthermore, no application will be able to a priori determine >>> whether the user us typing text/plain or text/html, as a user could >>> just add an html tag afterwords. >> >> >> >> Adding html tags doesn't make the content type html. The sending >> application will have to decide to set the content type to text/html. >> It *might* do that by inspecting the message for html tags, but I >> would find that surprising. I would imagine that some application >> control would need to be selected to cause this to happen. >> >> In any case, as with the drag/drop case above, if/when the application >> decides on a different content type than it previously communicated, >> it can send another isComposing with the new content type. But if the >> decision isn't made until the message is sent then presumably it >> wouldn't bother. It might not bother in any case. >> >> Paul >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 12:44:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09562 for ; Thu, 22 Apr 2004 12:44:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhJ2-0004Qg-Lr for simple-archive@ietf.org; Thu, 22 Apr 2004 12:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhHy-0004Av-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 12:43:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGhHT-0003vo-00; Thu, 22 Apr 2004 12:42:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh4T-0002CW-2Z; Thu, 22 Apr 2004 12:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgnz-0004gz-Sf for simple@optimus.ietf.org; Thu, 22 Apr 2004 12:12:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07919 for ; Thu, 22 Apr 2004 12:12:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgnw-0003GI-8n for simple@ietf.org; Thu, 22 Apr 2004 12:12:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgn0-00031M-00 for simple@ietf.org; Thu, 22 Apr 2004 12:11:02 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGgmM-0002Zd-00 for simple@ietf.org; Thu, 22 Apr 2004 12:10:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 08:21:50 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MG9nWB023882; Thu, 22 Apr 2004 09:09:52 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU33743; Thu, 22 Apr 2004 12:09:48 -0400 (EDT) Message-ID: <4087EE4C.8060608@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 12:09:48 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I like it. I see one new thing that I consider small: - I'm a little concerned about the idle timeout being as small as 10 seconds. Personally, I am often inclined to stop and think in the middle of composing an IM, which could trigger the idle transition fairly often. This might generate more traffic than we might like. Then there is the ordering issue that Cullen brought up. It is largely an issue because of the possibility of closely spaced messages, which in turn relates to more traffic. All in all I wonder if we mignt be better to recommend that isComposing SHOULD NOT be used with page mode. Paul hisham.khartabil@nokia.com wrote: > The WG chairs would like to start a Working Group Last Call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt > > This WGLC will end on May 5th. > > Please send your comments to this mailing list and to the authors. > > If you reviewed the draft and found no issues, please indicate so also on the mailing list. This will help us evaluate the level of review and group consensus. > > Thanks, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 12:57:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10306 for ; Thu, 22 Apr 2004 12:57:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhVs-0000Js-Dv for simple-archive@ietf.org; Thu, 22 Apr 2004 12:57:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhV4-00001F-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 12:56:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGhUM-0007Vl-00; Thu, 22 Apr 2004 12:55:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhNn-0000lI-Hl; Thu, 22 Apr 2004 12:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh5e-0002Ts-PB for simple@optimus.ietf.org; Thu, 22 Apr 2004 12:30:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08717 for ; Thu, 22 Apr 2004 12:30:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGh5Z-0000T5-Qo for simple@ietf.org; Thu, 22 Apr 2004 12:30:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGh4g-00008a-00 for simple@ietf.org; Thu, 22 Apr 2004 12:29:19 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BGh3h-0007Ke-00 for simple@ietf.org; Thu, 22 Apr 2004 12:28:17 -0400 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 09:27:48 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Apr 2004 09:27:49 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 09:27:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on isComposing draft Message-ID: Thread-Topic: [Simple] WGLC on isComposing draft thread-index: AcQoedL8VowllDHwRvSmkoKt5zjXVQACqrqw From: "Orit Levin" To: "Miguel Garcia" , "ext Paul Kyzivat" Cc: , X-OriginalArrivalTime: 22 Apr 2004 16:27:37.0386 (UTC) FILETIME=[B95D88A0:01C42886] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 09:27:45 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The "isComposing" (or the "isTyping" indication in its simplest use) greatly improves user experience and is widely used today. This is an example of data that does use bandwidth - for IM it can even double it. On the other hand - this is a kind of data that you really don't want any responses or acknowledges to: neither end-to-end nor hop-by-hop. I have this example in my "MSRP review" draft. By making hop-by-hop responses optional per message you immediately reduce the traffic by 1/4 in this case (even if you response hop-by-hop to every user message)! Orit. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Miguel Garcia Sent: Thursday, April 22, 2004 7:25 AM To: ext Paul Kyzivat Cc: hgs@cs.columbia.edu; simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft Well, so let me try to see if understand. We are adding a feature that=20 just uses bandwidth, because it represents some information that is able to change so oftenly that may require to be updated oftenly.=20 Furthermore, it is not clear what the receiver can do with such=20 information. Will an application at the receiver's indicate "Miguel is=20 composing audio" or "Miguel is composing video" ? I don't think that is=20 useful. Mmmm... in these days of wireless devices and saving bandwidth, this=20 element seems to go against those principles. /Miguel ext Paul Kyzivat wrote: >=20 >=20 > Miguel Garcia wrote: > [snip] >=20 >> Then I question the usage of the "contenttype" element. I can envision=20 >> systems where I can start typing a text message and then drag and drop=20 >> any object (audio or video file). The application will first generate >> an istyping message with the "contenttype" element presumably set to=20 >> text, which is not correct, >=20 >=20 > It would be correct at the time it is sent. There is never any guarantee=20 > that the typing will result in a message being sent at all, much less=20 > what type. >=20 > > because I dragged some object later. >=20 > When you drag in an object of some other type, your client will need to=20 > reconsider what the content type is. Then it could send a new=20 > isComposing message with the new content type. >=20 > > I doubt about the usability of this feature. >=20 > Well, I agree it isn't clear what the recipient would do with the=20 > content type information. But other than consuming bandwidth it doesn't=20 > hurt. >=20 >> Furthermore, no application will be able to a priori determine whether=20 >> the user us typing text/plain or text/html, as a user could just add=20 >> an html tag afterwords. >=20 >=20 > Adding html tags doesn't make the content type html. The sending=20 > application will have to decide to set the content type to text/html. It=20 > *might* do that by inspecting the message for html tags, but I would=20 > find that surprising. I would imagine that some application control=20 > would need to be selected to cause this to happen. >=20 > In any case, as with the drag/drop case above, if/when the application > decides on a different content type than it previously communicated, it=20 > can send another isComposing with the new content type. But if the=20 > decision isn't made until the message is sent then presumably it=20 > wouldn't bother. It might not bother in any case. >=20 > Paul >=20 --=20 Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 13:00:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10668 for ; Thu, 22 Apr 2004 13:00:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhSk-000249-J9 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 12:54:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MGsACG007936 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 12:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhJ7-0006su-99 for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 12:44:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09578 for ; Thu, 22 Apr 2004 12:44:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhJ3-0004Qm-G0 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 12:44:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhHz-0004B3-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 12:43:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGhHT-0003vo-00; Thu, 22 Apr 2004 12:42:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh4T-0002CW-2Z; Thu, 22 Apr 2004 12:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgnz-0004gz-Sf for simple@optimus.ietf.org; Thu, 22 Apr 2004 12:12:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07919 for ; Thu, 22 Apr 2004 12:12:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgnw-0003GI-8n for simple@ietf.org; Thu, 22 Apr 2004 12:12:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgn0-00031M-00 for simple@ietf.org; Thu, 22 Apr 2004 12:11:02 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGgmM-0002Zd-00 for simple@ietf.org; Thu, 22 Apr 2004 12:10:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 08:21:50 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MG9nWB023882; Thu, 22 Apr 2004 09:09:52 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU33743; Thu, 22 Apr 2004 12:09:48 -0400 (EDT) Message-ID: <4087EE4C.8060608@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 12:09:48 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I like it. I see one new thing that I consider small: - I'm a little concerned about the idle timeout being as small as 10 seconds. Personally, I am often inclined to stop and think in the middle of composing an IM, which could trigger the idle transition fairly often. This might generate more traffic than we might like. Then there is the ordering issue that Cullen brought up. It is largely an issue because of the possibility of closely spaced messages, which in turn relates to more traffic. All in all I wonder if we mignt be better to recommend that isComposing SHOULD NOT be used with page mode. Paul hisham.khartabil@nokia.com wrote: > The WG chairs would like to start a Working Group Last Call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt > > This WGLC will end on May 5th. > > Please send your comments to this mailing list and to the authors. > > If you reviewed the draft and found no issues, please indicate so also on the mailing list. This will help us evaluate the level of review and group consensus. > > Thanks, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 13:12:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11138 for ; Thu, 22 Apr 2004 13:12:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhcG-0005QC-Do for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 13:04:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MH406W020834 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 13:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhVx-0003XM-4g for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 12:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10319 for ; Thu, 22 Apr 2004 12:57:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhVt-0000Jx-56 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 12:57:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhV5-00001M-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 12:56:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGhUM-0007Vl-00; Thu, 22 Apr 2004 12:55:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhNn-0000lI-Hl; Thu, 22 Apr 2004 12:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh5e-0002Ts-PB for simple@optimus.ietf.org; Thu, 22 Apr 2004 12:30:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08717 for ; Thu, 22 Apr 2004 12:30:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGh5Z-0000T5-Qo for simple@ietf.org; Thu, 22 Apr 2004 12:30:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGh4g-00008a-00 for simple@ietf.org; Thu, 22 Apr 2004 12:29:19 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BGh3h-0007Ke-00 for simple@ietf.org; Thu, 22 Apr 2004 12:28:17 -0400 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 09:27:48 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Apr 2004 09:27:49 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 09:27:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on isComposing draft Message-ID: Thread-Topic: [Simple] WGLC on isComposing draft thread-index: AcQoedL8VowllDHwRvSmkoKt5zjXVQACqrqw From: "Orit Levin" To: "Miguel Garcia" , "ext Paul Kyzivat" Cc: , X-OriginalArrivalTime: 22 Apr 2004 16:27:37.0386 (UTC) FILETIME=[B95D88A0:01C42886] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 09:27:45 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The "isComposing" (or the "isTyping" indication in its simplest use) greatly improves user experience and is widely used today. This is an example of data that does use bandwidth - for IM it can even double it. On the other hand - this is a kind of data that you really don't want any responses or acknowledges to: neither end-to-end nor hop-by-hop. I have this example in my "MSRP review" draft. By making hop-by-hop responses optional per message you immediately reduce the traffic by 1/4 in this case (even if you response hop-by-hop to every user message)! Orit. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Miguel Garcia Sent: Thursday, April 22, 2004 7:25 AM To: ext Paul Kyzivat Cc: hgs@cs.columbia.edu; simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft Well, so let me try to see if understand. We are adding a feature that=20 just uses bandwidth, because it represents some information that is able to change so oftenly that may require to be updated oftenly.=20 Furthermore, it is not clear what the receiver can do with such=20 information. Will an application at the receiver's indicate "Miguel is=20 composing audio" or "Miguel is composing video" ? I don't think that is=20 useful. Mmmm... in these days of wireless devices and saving bandwidth, this=20 element seems to go against those principles. /Miguel ext Paul Kyzivat wrote: >=20 >=20 > Miguel Garcia wrote: > [snip] >=20 >> Then I question the usage of the "contenttype" element. I can envision=20 >> systems where I can start typing a text message and then drag and drop=20 >> any object (audio or video file). The application will first generate >> an istyping message with the "contenttype" element presumably set to=20 >> text, which is not correct, >=20 >=20 > It would be correct at the time it is sent. There is never any guarantee=20 > that the typing will result in a message being sent at all, much less=20 > what type. >=20 > > because I dragged some object later. >=20 > When you drag in an object of some other type, your client will need to=20 > reconsider what the content type is. Then it could send a new=20 > isComposing message with the new content type. >=20 > > I doubt about the usability of this feature. >=20 > Well, I agree it isn't clear what the recipient would do with the=20 > content type information. But other than consuming bandwidth it doesn't=20 > hurt. >=20 >> Furthermore, no application will be able to a priori determine whether=20 >> the user us typing text/plain or text/html, as a user could just add=20 >> an html tag afterwords. >=20 >=20 > Adding html tags doesn't make the content type html. The sending=20 > application will have to decide to set the content type to text/html. It=20 > *might* do that by inspecting the message for html tags, but I would=20 > find that surprising. I would imagine that some application control=20 > would need to be selected to cause this to happen. >=20 > In any case, as with the drag/drop case above, if/when the application > decides on a different content type than it previously communicated, it=20 > can send another isComposing with the new content type. But if the=20 > decision isn't made until the message is sent then presumably it=20 > wouldn't bother. It might not bother in any case. >=20 > Paul >=20 --=20 Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 13:38:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12814 for ; Thu, 22 Apr 2004 13:38:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGi9q-0004Mn-Pw for simple-archive@ietf.org; Thu, 22 Apr 2004 13:38:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGi8l-00040w-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 13:37:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGi7u-0003hr-00; Thu, 22 Apr 2004 13:36:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhxZ-0004C2-4P; Thu, 22 Apr 2004 13:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhsX-0002dZ-LJ for simple@optimus.ietf.org; Thu, 22 Apr 2004 13:20:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11830 for ; Thu, 22 Apr 2004 13:20:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhsT-0006we-Dt for simple@ietf.org; Thu, 22 Apr 2004 13:20:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhrU-0006al-00 for simple@ietf.org; Thu, 22 Apr 2004 13:19:45 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGhpn-0005sK-00 for simple@ietf.org; Thu, 22 Apr 2004 13:17:59 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MHHsA0029435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 13:17:58 -0400 (EDT) Message-ID: <4087FE42.7090608@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> In-Reply-To: <4087EE4C.8060608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 13:17:54 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I like it. I see one new thing that I consider small: > > - I'm a little concerned about the idle timeout being as small as 10 > seconds. Personally, I am often inclined to stop and think in the middle > of composing an IM, which could trigger the idle transition fairly > often. This might generate more traffic than we might like. I'm happy to raise it to 30 seconds. It is a configured interval, so you could have a philosopher mode that triggers messages less frequently and an ADD mode that indicates idle sooner... > > Then there is the ordering issue that Cullen brought up. It is largely > an issue because of the possibility of closely spaced messages, which in > turn relates to more traffic. All in all I wonder if we mignt be better > to recommend that isComposing SHOULD NOT be used with page mode. I don't see a message from Cullen in the discussion thread, so I'm probably missing the point. End systems can detect, via the CSeq, that an isComposing message postdates the actual message. Also, has somebody measured in real life how common reordering is? Packet-level re-ordering is very rare, only affects UDP-bessed messaging and unlikely to span more than a few milliseconds. Also, according to RFC 3428, A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there is a previous out-of-dialog transaction pending for the same URI. Similarly, A UAC SHOULD NOT initiate overlapping MESSAGE transactions inside a dialog, and MUST NOT do so unless the route set for that dialog uses a congestion-controlled transport at every hop. This further decreases the likelihood of re-ordering at the application layer. In our implementation, we've found isComposing rather useful, even in page mode, thus I'm not sure that the drawbacks merit a SHOULD NOT restraint. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 13:43:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13291 for ; Thu, 22 Apr 2004 13:43:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiBU-0001OD-R8 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 13:40:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MHeOPD005337 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 13:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGi9v-0000mY-EY for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 13:38:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12832 for ; Thu, 22 Apr 2004 13:38:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGi9r-0004Mu-CP for simple-web-archive@ietf.org; Thu, 22 Apr 2004 13:38:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGi8m-000414-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 13:37:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGi7u-0003hr-00; Thu, 22 Apr 2004 13:36:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhxZ-0004C2-4P; Thu, 22 Apr 2004 13:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhsX-0002dZ-LJ for simple@optimus.ietf.org; Thu, 22 Apr 2004 13:20:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11830 for ; Thu, 22 Apr 2004 13:20:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhsT-0006we-Dt for simple@ietf.org; Thu, 22 Apr 2004 13:20:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhrU-0006al-00 for simple@ietf.org; Thu, 22 Apr 2004 13:19:45 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGhpn-0005sK-00 for simple@ietf.org; Thu, 22 Apr 2004 13:17:59 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MHHsA0029435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 13:17:58 -0400 (EDT) Message-ID: <4087FE42.7090608@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> In-Reply-To: <4087EE4C.8060608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 13:17:54 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I like it. I see one new thing that I consider small: > > - I'm a little concerned about the idle timeout being as small as 10 > seconds. Personally, I am often inclined to stop and think in the middle > of composing an IM, which could trigger the idle transition fairly > often. This might generate more traffic than we might like. I'm happy to raise it to 30 seconds. It is a configured interval, so you could have a philosopher mode that triggers messages less frequently and an ADD mode that indicates idle sooner... > > Then there is the ordering issue that Cullen brought up. It is largely > an issue because of the possibility of closely spaced messages, which in > turn relates to more traffic. All in all I wonder if we mignt be better > to recommend that isComposing SHOULD NOT be used with page mode. I don't see a message from Cullen in the discussion thread, so I'm probably missing the point. End systems can detect, via the CSeq, that an isComposing message postdates the actual message. Also, has somebody measured in real life how common reordering is? Packet-level re-ordering is very rare, only affects UDP-bessed messaging and unlikely to span more than a few milliseconds. Also, according to RFC 3428, A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there is a previous out-of-dialog transaction pending for the same URI. Similarly, A UAC SHOULD NOT initiate overlapping MESSAGE transactions inside a dialog, and MUST NOT do so unless the route set for that dialog uses a congestion-controlled transport at every hop. This further decreases the likelihood of re-ordering at the application layer. In our implementation, we've found isComposing rather useful, even in page mode, thus I'm not sure that the drawbacks merit a SHOULD NOT restraint. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 14:20:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15603 for ; Thu, 22 Apr 2004 14:20:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGioH-0000eb-3r for simple-archive@ietf.org; Thu, 22 Apr 2004 14:20:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGinM-0000Ln-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 14:19:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGimg-00003O-00; Thu, 22 Apr 2004 14:18:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiaK-0000b9-SP; Thu, 22 Apr 2004 14:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiXX-0008GC-Fg for simple@optimus.ietf.org; Thu, 22 Apr 2004 14:03:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14649 for ; Thu, 22 Apr 2004 14:03:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGiXT-0003cn-3N for simple@ietf.org; Thu, 22 Apr 2004 14:03:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGiWZ-0003ML-00 for simple@ietf.org; Thu, 22 Apr 2004 14:02:12 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BGiVs-00036l-00 for simple@ietf.org; Thu, 22 Apr 2004 14:01:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MI1Ku05337; Thu, 22 Apr 2004 21:01:20 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 21:01:09 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3MI19P5017295; Thu, 22 Apr 2004 21:01:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00F88kkT; Thu, 22 Apr 2004 21:01:08 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MHP5s12857; Thu, 22 Apr 2004 20:25:05 +0300 (EET DST) Received: from nokia.com ([172.21.81.173]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 20:25:06 +0300 Message-ID: <4087FFF2.2090509@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> In-Reply-To: <4087EE4C.8060608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 17:25:06.0520 (UTC) FILETIME=[C1359D80:01C4288E] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 20:25:06 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit ext Paul Kyzivat wrote: > Then there is the ordering issue that Cullen brought up. It is largely > an issue because of the possibility of closely spaced messages, which in > turn relates to more traffic. All in all I wonder if we mignt be better > to recommend that isComposing SHOULD NOT be used with page mode. I agree. I think isComposing is very valuable for session-mode, but have strong doubts about it being useful in page-mode. When I start composing a completely new IM, would the recipient first get a notification of this? What does it mean if the message is never sent (i.e., I decide it was a bad idea and trash it.) To be useful, I think the isComposing indications need to be sent inside an explicit, existing dialogue, and with page-mode there is none, since the whole notion of a discussion exists only in the minds of the participants. Cheers, Aki > > Paul > > hisham.khartabil@nokia.com wrote: > >> The WG chairs would like to start a Working Group Last Call on the >> following drafts: >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >> >> This WGLC will end on May 5th. >> >> Please send your comments to this mailing list and to the authors. >> If you reviewed the draft and found no issues, please indicate so also >> on the mailing list. This will help us evaluate the level of review >> and group consensus. >> >> Thanks, >> Hisham >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 14:26:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16048 for ; Thu, 22 Apr 2004 14:26:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiqI-0005aH-Od for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 14:22:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MIMYb7021461 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 14:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGioM-0004uh-6w for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 14:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15620 for ; Thu, 22 Apr 2004 14:20:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGioH-0000eg-Mr for simple-web-archive@ietf.org; Thu, 22 Apr 2004 14:20:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGinN-0000Lu-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 14:19:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGimg-00003O-00; Thu, 22 Apr 2004 14:18:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiaK-0000b9-SP; Thu, 22 Apr 2004 14:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiXX-0008GC-Fg for simple@optimus.ietf.org; Thu, 22 Apr 2004 14:03:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14649 for ; Thu, 22 Apr 2004 14:03:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGiXT-0003cn-3N for simple@ietf.org; Thu, 22 Apr 2004 14:03:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGiWZ-0003ML-00 for simple@ietf.org; Thu, 22 Apr 2004 14:02:12 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BGiVs-00036l-00 for simple@ietf.org; Thu, 22 Apr 2004 14:01:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MI1Ku05337; Thu, 22 Apr 2004 21:01:20 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 21:01:09 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3MI19P5017295; Thu, 22 Apr 2004 21:01:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00F88kkT; Thu, 22 Apr 2004 21:01:08 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MHP5s12857; Thu, 22 Apr 2004 20:25:05 +0300 (EET DST) Received: from nokia.com ([172.21.81.173]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 20:25:06 +0300 Message-ID: <4087FFF2.2090509@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> In-Reply-To: <4087EE4C.8060608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 17:25:06.0520 (UTC) FILETIME=[C1359D80:01C4288E] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 20:25:06 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Paul Kyzivat wrote: > Then there is the ordering issue that Cullen brought up. It is largely > an issue because of the possibility of closely spaced messages, which in > turn relates to more traffic. All in all I wonder if we mignt be better > to recommend that isComposing SHOULD NOT be used with page mode. I agree. I think isComposing is very valuable for session-mode, but have strong doubts about it being useful in page-mode. When I start composing a completely new IM, would the recipient first get a notification of this? What does it mean if the message is never sent (i.e., I decide it was a bad idea and trash it.) To be useful, I think the isComposing indications need to be sent inside an explicit, existing dialogue, and with page-mode there is none, since the whole notion of a discussion exists only in the minds of the participants. Cheers, Aki > > Paul > > hisham.khartabil@nokia.com wrote: > >> The WG chairs would like to start a Working Group Last Call on the >> following drafts: >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >> >> This WGLC will end on May 5th. >> >> Please send your comments to this mailing list and to the authors. >> If you reviewed the draft and found no issues, please indicate so also >> on the mailing list. This will help us evaluate the level of review >> and group consensus. >> >> Thanks, >> Hisham >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 14:52:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17512 for ; Thu, 22 Apr 2004 14:52:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjIy-0001xW-NP for simple-archive@ietf.org; Thu, 22 Apr 2004 14:52:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjI5-0001fC-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 14:51:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjH9-0001O3-00; Thu, 22 Apr 2004 14:50:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj8B-0002Gp-5Z; Thu, 22 Apr 2004 14:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGixY-0007Qf-Ic for simple@optimus.ietf.org; Thu, 22 Apr 2004 14:30:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16329 for ; Thu, 22 Apr 2004 14:30:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGixT-0003Vq-Td for simple@ietf.org; Thu, 22 Apr 2004 14:30:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGive-00039x-00 for simple@ietf.org; Thu, 22 Apr 2004 14:28:07 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGiua-0002g0-00 for simple@ietf.org; Thu, 22 Apr 2004 14:27:00 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MIQvA0003599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 14:26:57 -0400 (EDT) Message-ID: <40880E70.9020905@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Espoo)" CC: ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> In-Reply-To: <4087FFF2.2090509@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 14:26:56 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > I agree. I think isComposing is very valuable for session-mode, but have > strong doubts about it being useful in page-mode. When I start > composing a completely new IM, would the recipient first get a > notification of this? What does it mean if the message is never sent > (i.e., I decide it was a bad idea and trash it.) This can happen in either page or session mode, unless session mode has a mechanism that forces uses to press the 'send' key once they have started typing. One could argue that the indication is most useful after receiving a message from the party I'm typing to, rather than before sending the first message. A simple heuristic (only send indication if within some number of minutes since receiving a message from the other party) would seem sufficient, but doesn't need standardizing since it's a UI issue. It may be worth hinting at this, however. I don't think the session aspect matters, since the lower-layer sessions could last for days and weeks without activity. What matters here is the 'human' session, i.e., the notion that I'm responding to an earlier comment and that it avoids the equivalent of double-talking to have this indication available. > > To be useful, I think the isComposing indications need to be sent inside > an explicit, existing dialogue, and with page-mode there is none, since > the whole notion of a discussion exists only in the minds of the > participants. I don't see how this follows. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 15:00:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18011 for ; Thu, 22 Apr 2004 15:00:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjQb-0004B8-JH for simple-archive@ietf.org; Thu, 22 Apr 2004 15:00:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjPd-0003tD-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 14:59:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjOa-0003Tt-00; Thu, 22 Apr 2004 14:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj97-0002ZI-SM; Thu, 22 Apr 2004 14:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj6S-0001fr-Ju for simple@optimus.ietf.org; Thu, 22 Apr 2004 14:39:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16764 for ; Thu, 22 Apr 2004 14:39:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGj6N-0006Ao-Ld for simple@ietf.org; Thu, 22 Apr 2004 14:39:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGj5W-0005uk-00 for simple@ietf.org; Thu, 22 Apr 2004 14:38:19 -0400 Received: from website12.com ([203.194.209.81]) by ietf-mx with smtp (Exim 4.12) id 1BGj4X-0005eV-00 for simple@ietf.org; Thu, 22 Apr 2004 14:37:17 -0400 Received: (qmail 14571 invoked from network); 22 Apr 2004 18:37:34 -0000 Received: from unknown (HELO VIKAS) (61.247.240.206) by website12.com with SMTP; 22 Apr 2004 18:37:34 -0000 From: "Vikas Tandon" To: "'Niemi Aki \(Nokia-M/Espoo\)'" , "'ext Paul Kyzivat'" Cc: , Subject: RE: [Simple] WGLC on isComposing draft Message-ID: <000401c42898$a9ffcc30$0100a8c0@VIKAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <4087FFF2.2090509@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2739.300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 00:05:54 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I too agree with - no need for isComposing in page mode. Regards, -Vikas -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Niemi Aki (Nokia-M/Espoo) Sent: jeudi 22 avril 2004 22:55 To: ext Paul Kyzivat Cc: hisham.khartabil@nokia.com; simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft ext Paul Kyzivat wrote: > Then there is the ordering issue that Cullen brought up. It is largely > an issue because of the possibility of closely spaced messages, which in > turn relates to more traffic. All in all I wonder if we mignt be better > to recommend that isComposing SHOULD NOT be used with page mode. I agree. I think isComposing is very valuable for session-mode, but have strong doubts about it being useful in page-mode. When I start composing a completely new IM, would the recipient first get a notification of this? What does it mean if the message is never sent (i.e., I decide it was a bad idea and trash it.) To be useful, I think the isComposing indications need to be sent inside an explicit, existing dialogue, and with page-mode there is none, since the whole notion of a discussion exists only in the minds of the participants. Cheers, Aki > > Paul > > hisham.khartabil@nokia.com wrote: > >> The WG chairs would like to start a Working Group Last Call on the >> following drafts: >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00. >> txt >> >> This WGLC will end on May 5th. >> >> Please send your comments to this mailing list and to the authors. If >> you reviewed the draft and found no issues, please indicate so also >> on the mailing list. This will help us evaluate the level of review >> and group consensus. >> >> Thanks, >> Hisham >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 15:05:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18527 for ; Thu, 22 Apr 2004 15:05:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjVe-0005aF-6k for simple-archive@ietf.org; Thu, 22 Apr 2004 15:05:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjUm-0005JE-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 15:04:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjU0-00052S-00; Thu, 22 Apr 2004 15:03:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjPZ-00073s-Q4; Thu, 22 Apr 2004 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj9U-0002av-1u for simple@optimus.ietf.org; Thu, 22 Apr 2004 14:42:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16931 for ; Thu, 22 Apr 2004 14:42:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGj9P-00070V-AP for simple@ietf.org; Thu, 22 Apr 2004 14:42:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGj8S-0006jS-00 for simple@ietf.org; Thu, 22 Apr 2004 14:41:21 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGj82-0006Rr-00 for simple@ietf.org; Thu, 22 Apr 2004 14:40:54 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3MIeIjO024361; Thu, 22 Apr 2004 11:40:19 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOI36047; Thu, 22 Apr 2004 11:40:17 -0700 (PDT) From: David Oran To: "Niemi Aki (Nokia-M/Espoo)" , ext Paul Kyzivat cc: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft Message-ID: <2147483647.1082644817@[10.32.245.156]> In-Reply-To: <4087FFF2.2090509@nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 14:40:17 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit --On Thursday, April 22, 2004 8:25 PM +0300 "Niemi Aki (Nokia-M/Espoo)" wrote: > > ext Paul Kyzivat wrote: >> Then there is the ordering issue that Cullen brought up. It is largely >> an issue because of the possibility of closely spaced messages, which in >> turn relates to more traffic. All in all I wonder if we mignt be better >> to recommend that isComposing SHOULD NOT be used with page mode. > > I agree. I think isComposing is very valuable for session-mode, but have > strong doubts about it being useful in page-mode. When I start composing > a completely new IM, would the recipient first get a notification of > this? What does it mean if the message is never sent (i.e., I decide it > was a bad idea and trash it.) > Hmmm, I have an IM client which pops an incoming IM window as soon as the isComposing comes in. I can really freak people out by quickly typing them a message ad send it back. They think I'm clairvoyant! Is this a really useful feature? Beats me, but why prohibit something which does no damage? > To be useful, I think the isComposing indications need to be sent inside > an explicit, existing dialogue, and with page-mode there is none, since > the whole notion of a discussion exists only in the minds of the > participants. > Depends on your attitude about what's useful... > Cheers, > Aki > >> >> Paul >> >> hisham.khartabil@nokia.com wrote: >> >>> The WG chairs would like to start a Working Group Last Call on the >>> following drafts: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >>> >>> This WGLC will end on May 5th. >>> >>> Please send your comments to this mailing list and to the authors. >>> If you reviewed the draft and found no issues, please indicate so also >>> on the mailing list. This will help us evaluate the level of review >>> and group consensus. >>> >>> Thanks, >>> Hisham >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 15:21:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20749 for ; Thu, 22 Apr 2004 15:21:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjQu-0008MJ-K7 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 15:00:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MJ0O1r032101 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 15:00:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjJ4-0005Ca-6i for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 14:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17530 for ; Thu, 22 Apr 2004 14:52:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjIz-0001xg-D6 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 14:52:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjI7-0001fL-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 14:51:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjH9-0001O3-00; Thu, 22 Apr 2004 14:50:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj8B-0002Gp-5Z; Thu, 22 Apr 2004 14:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGixY-0007Qf-Ic for simple@optimus.ietf.org; Thu, 22 Apr 2004 14:30:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16329 for ; Thu, 22 Apr 2004 14:30:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGixT-0003Vq-Td for simple@ietf.org; Thu, 22 Apr 2004 14:30:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGive-00039x-00 for simple@ietf.org; Thu, 22 Apr 2004 14:28:07 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGiua-0002g0-00 for simple@ietf.org; Thu, 22 Apr 2004 14:27:00 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MIQvA0003599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 14:26:57 -0400 (EDT) Message-ID: <40880E70.9020905@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Espoo)" CC: ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> In-Reply-To: <4087FFF2.2090509@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 14:26:56 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I agree. I think isComposing is very valuable for session-mode, but have > strong doubts about it being useful in page-mode. When I start > composing a completely new IM, would the recipient first get a > notification of this? What does it mean if the message is never sent > (i.e., I decide it was a bad idea and trash it.) This can happen in either page or session mode, unless session mode has a mechanism that forces uses to press the 'send' key once they have started typing. One could argue that the indication is most useful after receiving a message from the party I'm typing to, rather than before sending the first message. A simple heuristic (only send indication if within some number of minutes since receiving a message from the other party) would seem sufficient, but doesn't need standardizing since it's a UI issue. It may be worth hinting at this, however. I don't think the session aspect matters, since the lower-layer sessions could last for days and weeks without activity. What matters here is the 'human' session, i.e., the notion that I'm responding to an earlier comment and that it avoids the equivalent of double-talking to have this indication available. > > To be useful, I think the isComposing indications need to be sent inside > an explicit, existing dialogue, and with page-mode there is none, since > the whole notion of a discussion exists only in the minds of the > participants. I don't see how this follows. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 15:47:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22939 for ; Thu, 22 Apr 2004 15:47:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjkQ-0007A2-Vo for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 15:20:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MJKYaD027519 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 15:20:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjQi-0007QM-1V for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 15:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18029 for ; Thu, 22 Apr 2004 15:00:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjQd-0004BL-7o for simple-web-archive@ietf.org; Thu, 22 Apr 2004 15:00:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjPe-0003tN-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 14:59:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjOa-0003Tt-00; Thu, 22 Apr 2004 14:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj97-0002ZI-SM; Thu, 22 Apr 2004 14:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj6S-0001fr-Ju for simple@optimus.ietf.org; Thu, 22 Apr 2004 14:39:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16764 for ; Thu, 22 Apr 2004 14:39:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGj6N-0006Ao-Ld for simple@ietf.org; Thu, 22 Apr 2004 14:39:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGj5W-0005uk-00 for simple@ietf.org; Thu, 22 Apr 2004 14:38:19 -0400 Received: from website12.com ([203.194.209.81]) by ietf-mx with smtp (Exim 4.12) id 1BGj4X-0005eV-00 for simple@ietf.org; Thu, 22 Apr 2004 14:37:17 -0400 Received: (qmail 14571 invoked from network); 22 Apr 2004 18:37:34 -0000 Received: from unknown (HELO VIKAS) (61.247.240.206) by website12.com with SMTP; 22 Apr 2004 18:37:34 -0000 From: "Vikas Tandon" To: "'Niemi Aki \(Nokia-M/Espoo\)'" , "'ext Paul Kyzivat'" Cc: , Subject: RE: [Simple] WGLC on isComposing draft Message-ID: <000401c42898$a9ffcc30$0100a8c0@VIKAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <4087FFF2.2090509@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2739.300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 00:05:54 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I too agree with - no need for isComposing in page mode. Regards, -Vikas -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Niemi Aki (Nokia-M/Espoo) Sent: jeudi 22 avril 2004 22:55 To: ext Paul Kyzivat Cc: hisham.khartabil@nokia.com; simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft ext Paul Kyzivat wrote: > Then there is the ordering issue that Cullen brought up. It is largely > an issue because of the possibility of closely spaced messages, which in > turn relates to more traffic. All in all I wonder if we mignt be better > to recommend that isComposing SHOULD NOT be used with page mode. I agree. I think isComposing is very valuable for session-mode, but have strong doubts about it being useful in page-mode. When I start composing a completely new IM, would the recipient first get a notification of this? What does it mean if the message is never sent (i.e., I decide it was a bad idea and trash it.) To be useful, I think the isComposing indications need to be sent inside an explicit, existing dialogue, and with page-mode there is none, since the whole notion of a discussion exists only in the minds of the participants. Cheers, Aki > > Paul > > hisham.khartabil@nokia.com wrote: > >> The WG chairs would like to start a Working Group Last Call on the >> following drafts: >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00. >> txt >> >> This WGLC will end on May 5th. >> >> Please send your comments to this mailing list and to the authors. If >> you reviewed the draft and found no issues, please indicate so also >> on the mailing list. This will help us evaluate the level of review >> and group consensus. >> >> Thanks, >> Hisham >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 15:57:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24304 for ; Thu, 22 Apr 2004 15:57:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk7P-0001mD-5y for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 15:44:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MJiJvi006825 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 15:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjVk-0005Ha-9k for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 15:05:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18545 for ; Thu, 22 Apr 2004 15:05:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjVf-0005aS-FQ for simple-web-archive@ietf.org; Thu, 22 Apr 2004 15:05:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjUn-0005JN-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 15:04:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjU0-00052S-00; Thu, 22 Apr 2004 15:03:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjPZ-00073s-Q4; Thu, 22 Apr 2004 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj9U-0002av-1u for simple@optimus.ietf.org; Thu, 22 Apr 2004 14:42:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16931 for ; Thu, 22 Apr 2004 14:42:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGj9P-00070V-AP for simple@ietf.org; Thu, 22 Apr 2004 14:42:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGj8S-0006jS-00 for simple@ietf.org; Thu, 22 Apr 2004 14:41:21 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGj82-0006Rr-00 for simple@ietf.org; Thu, 22 Apr 2004 14:40:54 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3MIeIjO024361; Thu, 22 Apr 2004 11:40:19 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOI36047; Thu, 22 Apr 2004 11:40:17 -0700 (PDT) From: David Oran To: "Niemi Aki (Nokia-M/Espoo)" , ext Paul Kyzivat cc: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft Message-ID: <2147483647.1082644817@[10.32.245.156]> In-Reply-To: <4087FFF2.2090509@nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 14:40:17 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Thursday, April 22, 2004 8:25 PM +0300 "Niemi Aki (Nokia-M/Espoo)" wrote: > > ext Paul Kyzivat wrote: >> Then there is the ordering issue that Cullen brought up. It is largely >> an issue because of the possibility of closely spaced messages, which in >> turn relates to more traffic. All in all I wonder if we mignt be better >> to recommend that isComposing SHOULD NOT be used with page mode. > > I agree. I think isComposing is very valuable for session-mode, but have > strong doubts about it being useful in page-mode. When I start composing > a completely new IM, would the recipient first get a notification of > this? What does it mean if the message is never sent (i.e., I decide it > was a bad idea and trash it.) > Hmmm, I have an IM client which pops an incoming IM window as soon as the isComposing comes in. I can really freak people out by quickly typing them a message ad send it back. They think I'm clairvoyant! Is this a really useful feature? Beats me, but why prohibit something which does no damage? > To be useful, I think the isComposing indications need to be sent inside > an explicit, existing dialogue, and with page-mode there is none, since > the whole notion of a discussion exists only in the minds of the > participants. > Depends on your attitude about what's useful... > Cheers, > Aki > >> >> Paul >> >> hisham.khartabil@nokia.com wrote: >> >>> The WG chairs would like to start a Working Group Last Call on the >>> following drafts: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >>> >>> This WGLC will end on May 5th. >>> >>> Please send your comments to this mailing list and to the authors. >>> If you reviewed the draft and found no issues, please indicate so also >>> on the mailing list. This will help us evaluate the level of review >>> and group consensus. >>> >>> Thanks, >>> Hisham >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 16:03:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24729 for ; Thu, 22 Apr 2004 16:03:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGkPd-0007e4-QB for simple-archive@ietf.org; Thu, 22 Apr 2004 16:03:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGkOe-0007Nr-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 16:02:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGkNf-0006tc-00; Thu, 22 Apr 2004 16:01:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk87-0001yn-Ad; Thu, 22 Apr 2004 15:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjXV-0006Ym-Pc for simple@optimus.ietf.org; Thu, 22 Apr 2004 15:07:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18713 for ; Thu, 22 Apr 2004 15:07:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjXQ-00066m-Eo for simple@ietf.org; Thu, 22 Apr 2004 15:07:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjWS-0005qG-00 for simple@ietf.org; Thu, 22 Apr 2004 15:06:08 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGjVS-0005Yo-00 for simple@ietf.org; Thu, 22 Apr 2004 15:05:06 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MJ58A0006259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 15:05:08 -0400 (EDT) Message-ID: <40881763.1050507@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <45730E094814E44488F789C1CDED27AE02BDF373@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF373@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:05:07 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Because I made a last-minute change that I didn't check :-) Fixed. Chris Boulton wrote: > Out of interest - why is > > > NOT > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 17:42:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03049 for ; Thu, 22 Apr 2004 17:42:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlOT-00050p-Vk for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 17:06:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ML61n8019258 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 17:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkPi-0007fn-3D for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 16:03:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24746 for ; Thu, 22 Apr 2004 16:03:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGkPe-0007e9-Fi for simple-web-archive@ietf.org; Thu, 22 Apr 2004 16:03:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGkOf-0007Nz-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 16:02:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGkNf-0006tc-00; Thu, 22 Apr 2004 16:01:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk87-0001yn-Ad; Thu, 22 Apr 2004 15:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjXV-0006Ym-Pc for simple@optimus.ietf.org; Thu, 22 Apr 2004 15:07:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18713 for ; Thu, 22 Apr 2004 15:07:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjXQ-00066m-Eo for simple@ietf.org; Thu, 22 Apr 2004 15:07:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjWS-0005qG-00 for simple@ietf.org; Thu, 22 Apr 2004 15:06:08 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGjVS-0005Yo-00 for simple@ietf.org; Thu, 22 Apr 2004 15:05:06 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MJ58A0006259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 15:05:08 -0400 (EDT) Message-ID: <40881763.1050507@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <45730E094814E44488F789C1CDED27AE02BDF373@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDF373@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:05:07 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Because I made a last-minute change that I didn't check :-) Fixed. Chris Boulton wrote: > Out of interest - why is > > > NOT > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:01:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05079 for ; Thu, 22 Apr 2004 18:01:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmGH-0004Cr-W5 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:01:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmFM-0003ts-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:00:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmEg-0003ay-00; Thu, 22 Apr 2004 17:59:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlw0-0006WB-6B; Thu, 22 Apr 2004 17:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGl3W-0001E9-74 for simple@optimus.ietf.org; Thu, 22 Apr 2004 16:44:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28254 for ; Thu, 22 Apr 2004 16:44:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGl3S-00055S-66 for simple@ietf.org; Thu, 22 Apr 2004 16:44:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGl2U-0004mT-00 for simple@ietf.org; Thu, 22 Apr 2004 16:43:18 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGl1a-0004Dd-00 for simple@ietf.org; Thu, 22 Apr 2004 16:42:23 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKfIh29600; Thu, 22 Apr 2004 15:41:18 -0500 Message-ID: <40882DE6.5070405@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:41:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Would the expiration of the "active" state cause this problem to self-heal? Cullen Jennings wrote: > I had a quick read of this and I like it. > > One questions on correlating with the message. Say I opened a windows, a is > composing message was sent, call this M1, then I very quickly typed a > message and this got sent, call this M2. Not idle message is sent. > > Now the network might deliver M2 ahead of M1. The client receiving these > would display the text from M2 then show that the other side was composing > when really it was not. > > This might be a weird corner case not worth solving. It could be solved with > high resolution sender time in both M1 and M2. It could be solved with the > is Composing passing on the message ID of the message that was being > composed. > > I don't care if we choose to ignore this problem but thought it was worth > mentioning. > > > > On 4/21/04 5:54 AM, "hisham.khartabil@nokia.com" > wrote: > > >>The WG chairs would like to start a Working Group Last Call on the following >>drafts: >> >>http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >> >>This WGLC will end on May 5th. >> >>Please send your comments to this mailing list and to the authors. >> >>If you reviewed the draft and found no issues, please indicate so also on the >>mailing list. This will help us evaluate the level of review and group >>consensus. >> >>Thanks, >>Hisham >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:03:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05246 for ; Thu, 22 Apr 2004 18:03:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmI1-0004n6-IF for simple-archive@ietf.org; Thu, 22 Apr 2004 18:03:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmH6-0004V5-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:02:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmG2-0004An-00; Thu, 22 Apr 2004 18:01:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlwR-0006uG-Sb; Thu, 22 Apr 2004 17:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlBZ-0002Rz-Qv for simple@optimus.ietf.org; Thu, 22 Apr 2004 16:52:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29338 for ; Thu, 22 Apr 2004 16:52:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlBV-00002W-N6 for simple@ietf.org; Thu, 22 Apr 2004 16:52:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlAO-0007TU-00 for simple@ietf.org; Thu, 22 Apr 2004 16:51:29 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGl93-0006kT-00 for simple@ietf.org; Thu, 22 Apr 2004 16:50:06 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKjXh29703; Thu, 22 Apr 2004 15:45:33 -0500 Message-ID: <40882EE3.5090208@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> In-Reply-To: <4087B8DA.2010202@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:45:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Miguel Garcia wrote: [...] > Then I question the usage of the "contenttype" element. I can envision > systems where I can start typing a text message and then drag and drop > any object (audio or video file). The application will first generate an > istyping message with the "contenttype" element presumably set to text, > which is not correct, because I dragged some object later. I doubt about > the usability of this feature. I think contenttype can be useful, as long as the receiver knows it is just a hint. This is true of is-Composing in general, as I might type something into an external editor and paste it into a message. But if my messaging system happens to have sound recording features built in, and I use them instead of adding a sound attachment, it might be useful. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:04:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05344 for ; Thu, 22 Apr 2004 18:04:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmIn-00053e-5Z for simple-archive@ietf.org; Thu, 22 Apr 2004 18:04:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmHp-0004lJ-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:03:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmGr-0004SV-00; Thu, 22 Apr 2004 18:02:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlwS-0006uk-Mj; Thu, 22 Apr 2004 17:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlBs-0002ZY-Th for simple@optimus.ietf.org; Thu, 22 Apr 2004 16:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29385 for ; Thu, 22 Apr 2004 16:52:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlBo-00004o-Q0 for simple@ietf.org; Thu, 22 Apr 2004 16:52:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlAc-0007VH-00 for simple@ietf.org; Thu, 22 Apr 2004 16:51:42 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGl9C-0006m5-00 for simple@ietf.org; Thu, 22 Apr 2004 16:50:14 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKnKh29732; Thu, 22 Apr 2004 15:49:20 -0500 Message-ID: <40882FC6.7030002@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FE42.7090608@cs.columbia.edu> In-Reply-To: <4087FE42.7090608@cs.columbia.edu> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:49:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > Paul Kyzivat wrote: > >> I like it. I see one new thing that I consider small: >> >> - I'm a little concerned about the idle timeout being as small as 10 >> seconds. Personally, I am often inclined to stop and think in the >> middle of composing an IM, which could trigger the idle transition >> fairly often. This might generate more traffic than we might like. > > > I'm happy to raise it to 30 seconds. It is a configured interval, so you > could have a philosopher mode that triggers messages less frequently and > an ADD mode that indicates idle sooner... Now that you mention it, is there a conflict between saying this is a "configured interval" and saying it "SHOULD be X seconds"? Does that simply mean it should be X if the user chooses not to configure anything? [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:23:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07397 for ; Thu, 22 Apr 2004 18:23:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbB-0002E1-PM for simple-archive@ietf.org; Thu, 22 Apr 2004 18:23:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmYo-0001Q6-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:20:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX3-0000tJ-02; Thu, 22 Apr 2004 18:18:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmMY-0004ad-PI; Thu, 22 Apr 2004 18:08:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlyd-0008Mw-BR; Thu, 22 Apr 2004 17:43:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlVt-0007if-P3 for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:13:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01267 for ; Thu, 22 Apr 2004 17:13:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlVp-0006J7-C2 for simple@ietf.org; Thu, 22 Apr 2004 17:13:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlTs-0005e0-00 for simple@ietf.org; Thu, 22 Apr 2004 17:11:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGlQp-0004oh-02 for simple@ietf.org; Thu, 22 Apr 2004 17:08:27 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGlCD-0003df-Qn for simple@ietf.org; Thu, 22 Apr 2004 16:53:22 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKr9h29831; Thu, 22 Apr 2004 15:53:09 -0500 Message-ID: <408830AC.8080409@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Espoo)" CC: ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> In-Reply-To: <4087FFF2.2090509@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:53:00 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Niemi Aki (Nokia-M/Espoo) wrote: > > ext Paul Kyzivat wrote: > >> Then there is the ordering issue that Cullen brought up. It is largely >> an issue because of the possibility of closely spaced messages, which >> in turn relates to more traffic. All in all I wonder if we mignt be >> better to recommend that isComposing SHOULD NOT be used with page mode. > > > I agree. I think isComposing is very valuable for session-mode, but have > strong doubts about it being useful in page-mode. When I start > composing a completely new IM, would the recipient first get a > notification of this? What does it mean if the message is never sent > (i.e., I decide it was a bad idea and trash it.) As I commented in a separate thread, endpoints using page-mode may still have a local idea of a "virtual confersation". isComposing may be useful in that context. But I think we may need more guidelines for using it in page-mode, if we support that at all. How is the issue of the message not being sent differ for page-mode and session-mode? > > To be useful, I think the isComposing indications need to be sent inside > an explicit, existing dialogue, and with page-mode there is none, since > the whole notion of a discussion exists only in the minds of the > participants. > But the notion _does_ exist, even if only in the minds. I have seen SMS clients that give a conversational user experience. If you can do it in SMS, you should be able to do it with page-mode IM. > Cheers, > Aki > >> >> Paul >> >> hisham.khartabil@nokia.com wrote: >> >>> The WG chairs would like to start a Working Group Last Call on the >>> following drafts: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >>> >>> This WGLC will end on May 5th. >>> >>> Please send your comments to this mailing list and to the authors. >>> If you reviewed the draft and found no issues, please indicate so >>> also on the mailing list. This will help us evaluate the level of >>> review and group consensus. >>> >>> Thanks, >>> Hisham >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:23:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07537 for ; Thu, 22 Apr 2004 18:23:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbe-0002RU-Ot for simple-archive@ietf.org; Thu, 22 Apr 2004 18:23:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZN-0001ZK-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:21:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX6-0000tV-01; Thu, 22 Apr 2004 18:19:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmJA-0004V7-61; Thu, 22 Apr 2004 18:04:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlxI-0007X2-QR; Thu, 22 Apr 2004 17:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlIv-0003uS-7n for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:00:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29965 for ; Thu, 22 Apr 2004 17:00:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlIr-0002Qj-1A for simple@ietf.org; Thu, 22 Apr 2004 17:00:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlHq-00029t-00 for simple@ietf.org; Thu, 22 Apr 2004 16:59:10 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGlGr-0001dT-00 for simple@ietf.org; Thu, 22 Apr 2004 16:58:09 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKuth29935; Thu, 22 Apr 2004 15:56:55 -0500 Message-ID: <4088318F.40101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:56:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I like this in general. Some minor comments and questions: Am I correct in assuming you never need to refresh idle state? The idea of the idle timeout seems pretty text centric. Would you expect the same behavior if they were recording audio? Maybe you would go to idle when they pressed stop or pause, rather than when a timeout occurred. Nit: "Recipients of messages implementing this specification MUST treat state tokens other than "idle" and "active" as "idle"." You mean "unknown" state tokens, right? Do we have enough guidelines for using with page-mode? It does not seem to make sense to send unsolicited is-composing messages, but it might make sense to create sort of a pseudo-session when one receives a pager-mode message, then send these within that context. By pseudo-session, I mean having the endpoints keep track of a conversation, event though the protocol may not be providing explicit session info. Do you have thoughts about the interaction between is-composing and DSN/MDN? Would you ever want a delivery report for an is-composing message? hisham.khartabil@nokia.com wrote: > The WG chairs would like to start a Working Group Last Call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt > > This WGLC will end on May 5th. > > Please send your comments to this mailing list and to the authors. > > If you reviewed the draft and found no issues, please indicate so also on the mailing list. This will help us evaluate the level of review and group consensus. > > Thanks, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:23:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07562 for ; Thu, 22 Apr 2004 18:23:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbg-0002Rt-FM for simple-archive@ietf.org; Thu, 22 Apr 2004 18:23:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZQ-0001a9-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:21:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX6-0000th-01; Thu, 22 Apr 2004 18:19:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmJR-0004VK-A3; Thu, 22 Apr 2004 18:04:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlxJ-0007XE-Cp; Thu, 22 Apr 2004 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlIv-0003uU-W2 for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:00:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29968 for ; Thu, 22 Apr 2004 17:00:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlIr-0002Qp-Mk for simple@ietf.org; Thu, 22 Apr 2004 17:00:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlHq-0002A1-00 for simple@ietf.org; Thu, 22 Apr 2004 16:59:11 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGlGs-0001db-00 for simple@ietf.org; Thu, 22 Apr 2004 16:58:10 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKudh29931; Thu, 22 Apr 2004 15:56:40 -0500 Message-ID: <4088317F.2060803@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Miguel Garcia , ext Paul Kyzivat , hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:56:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit As the possibility of removing transaction responses is still a controversial issue in MSRP, I think we can consider it orthagonal to the isComposing draft. That is, we can progress the isComposing draft while still arguing that issue for MSRP. I agree (and commented so in a separate thread.) that we probably don't want DSN/MDN reports for isComposing messages. Orit Levin wrote: > The "isComposing" (or the "isTyping" indication in its simplest use) > greatly improves user experience and is widely used today. > > This is an example of data that does use bandwidth - for IM it can even > double it. On the other hand - this is a kind of data that you really > don't want any responses or acknowledges to: neither end-to-end nor > hop-by-hop. > > I have this example in my "MSRP review" draft. By making hop-by-hop > responses optional per message you immediately reduce the traffic by 1/4 > in this case (even if you response hop-by-hop to every user message)! > > Orit. > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Miguel Garcia > Sent: Thursday, April 22, 2004 7:25 AM > To: ext Paul Kyzivat > Cc: hgs@cs.columbia.edu; simple@ietf.org > Subject: Re: [Simple] WGLC on isComposing draft > > Well, so let me try to see if understand. We are adding a feature that > just uses bandwidth, because it represents some information that is able > > to change so oftenly that may require to be updated oftenly. > Furthermore, it is not clear what the receiver can do with such > information. Will an application at the receiver's indicate "Miguel is > composing audio" or "Miguel is composing video" ? I don't think that is > useful. > > Mmmm... in these days of wireless devices and saving bandwidth, this > element seems to go against those principles. > > /Miguel > > ext Paul Kyzivat wrote: > > >> >>Miguel Garcia wrote: >>[snip] >> >> >>>Then I question the usage of the "contenttype" element. I can > > envision > >>>systems where I can start typing a text message and then drag and > > drop > >>>any object (audio or video file). The application will first generate > > >>>an istyping message with the "contenttype" element presumably set to >>>text, which is not correct, >> >> >>It would be correct at the time it is sent. There is never any > > guarantee > >>that the typing will result in a message being sent at all, much less >>what type. >> >> > because I dragged some object later. >> >>When you drag in an object of some other type, your client will need > > to > >>reconsider what the content type is. Then it could send a new >>isComposing message with the new content type. >> >> > I doubt about the usability of this feature. >> >>Well, I agree it isn't clear what the recipient would do with the >>content type information. But other than consuming bandwidth it > > doesn't > >>hurt. >> >> >>>Furthermore, no application will be able to a priori determine > > whether > >>>the user us typing text/plain or text/html, as a user could just add >>>an html tag afterwords. >> >> >>Adding html tags doesn't make the content type html. The sending >>application will have to decide to set the content type to text/html. > > It > >>*might* do that by inspecting the message for html tags, but I would >>find that surprising. I would imagine that some application control >>would need to be selected to cause this to happen. >> >>In any case, as with the drag/drop case above, if/when the application > > >>decides on a different content type than it previously communicated, > > it > >>can send another isComposing with the new content type. But if the >>decision isn't made until the message is sent then presumably it >>wouldn't bother. It might not bother in any case. >> >> Paul >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:24:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07700 for ; Thu, 22 Apr 2004 18:24:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbw-0002Uk-KH for simple-archive@ietf.org; Thu, 22 Apr 2004 18:24:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZu-0001gs-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:21:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX8-0000tV-01; Thu, 22 Apr 2004 18:19:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmHi-0004Td-Tn; Thu, 22 Apr 2004 18:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlwV-0006vn-VO; Thu, 22 Apr 2004 17:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlDC-0002pu-JT for simple@optimus.ietf.org; Thu, 22 Apr 2004 16:54:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29518 for ; Thu, 22 Apr 2004 16:54:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlD8-0000dc-Fk for simple@ietf.org; Thu, 22 Apr 2004 16:54:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlC9-0000LX-00 for simple@ietf.org; Thu, 22 Apr 2004 16:53:17 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGlBF-0007ki-00 for simple@ietf.org; Thu, 22 Apr 2004 16:52:21 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MKqBA0013057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 16:52:12 -0400 (EDT) Message-ID: <4088307C.3060701@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FE42.7090608@cs.columbia.edu> <40882FC6.7030002@dynamicsoft.com> In-Reply-To: <40882FC6.7030002@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 16:52:12 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > Now that you mention it, is there a conflict between saying this is a > "configured interval" and saying it "SHOULD be X seconds"? Does that > simply mean it should be X if the user chooses not to configure anything? Yes; I'll clarify. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:30:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08211 for ; Thu, 22 Apr 2004 18:30:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmi2-0004aI-9Z for simple-archive@ietf.org; Thu, 22 Apr 2004 18:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmgz-0004G9-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:29:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmfv-0003h8-00; Thu, 22 Apr 2004 18:28:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmQf-0000Oo-Q5; Thu, 22 Apr 2004 18:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm57-0002XP-RR for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03992 for ; Thu, 22 Apr 2004 17:50:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGm53-0000iD-6y for simple@ietf.org; Thu, 22 Apr 2004 17:50:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGm21-0007kI-00 for simple@ietf.org; Thu, 22 Apr 2004 17:46:53 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGly8-0006my-00 for simple@ietf.org; Thu, 22 Apr 2004 17:42:52 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MLgmG14955; Fri, 23 Apr 2004 00:42:48 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 00:42:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3MLgZux017816; Fri, 23 Apr 2004 00:42:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00XvPCvy; Fri, 23 Apr 2004 00:42:34 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MLgVs23286; Fri, 23 Apr 2004 00:42:31 +0300 (EET DST) Received: from nokia.com ([10.162.253.251]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 00:42:32 +0300 Message-ID: <40883C46.3020005@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext David Oran CC: ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <2147483647.1082644817@[10.32.245.156]> In-Reply-To: <2147483647.1082644817@[10.32.245.156]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 21:42:32.0783 (UTC) FILETIME=[B7E64DF0:01C428B2] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 00:42:30 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit ext David Oran wrote: >> I agree. I think isComposing is very valuable for session-mode, but have >> strong doubts about it being useful in page-mode. When I start composing >> a completely new IM, would the recipient first get a notification of >> this? What does it mean if the message is never sent (i.e., I decide it >> was a bad idea and trash it.) >> > Hmmm, I have an IM client which pops an incoming IM window as soon as > the isComposing comes in. I can really freak people out by quickly > typing them a message ad send it back. They think I'm clairvoyant! > > Is this a really useful feature? Beats me, but why prohibit something > which does no damage? That's just it, it might do damage, because as you point out, the sender isn't aware that information about her messaging activities is leaking out before the send-button is even pushed. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:34:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08517 for ; Thu, 22 Apr 2004 18:34:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmld-0005eV-5v for simple-archive@ietf.org; Thu, 22 Apr 2004 18:34:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmkT-0005Ib-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:32:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmjO-0004xY-00; Thu, 22 Apr 2004 18:31:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmQs-0000cK-LA; Thu, 22 Apr 2004 18:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm6i-0002vd-34 for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04275 for ; Thu, 22 Apr 2004 17:51:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGm6d-0001CP-DC for simple@ietf.org; Thu, 22 Apr 2004 17:51:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGm4Z-0000eD-00 for simple@ietf.org; Thu, 22 Apr 2004 17:49:31 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGm1N-0007V7-00 for simple@ietf.org; Thu, 22 Apr 2004 17:46:13 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MLk5607897; Fri, 23 Apr 2004 00:46:05 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 00:45:50 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3MLjo6A021744; Fri, 23 Apr 2004 00:45:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 002Qmq76; Fri, 23 Apr 2004 00:45:49 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MLjks24949; Fri, 23 Apr 2004 00:45:46 +0300 (EET DST) Received: from nokia.com ([10.162.253.251]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 00:45:41 +0300 Message-ID: <40883D03.9020307@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Ben Campbell CC: ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> In-Reply-To: <408830AC.8080409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 21:45:41.0474 (UTC) FILETIME=[285E4420:01C428B3] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 00:45:39 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit ext Ben Campbell wrote: >> I agree. I think isComposing is very valuable for session-mode, but >> have strong doubts about it being useful in page-mode. When I start >> composing a completely new IM, would the recipient first get a >> notification of this? What does it mean if the message is never sent >> (i.e., I decide it was a bad idea and trash it.) > > > As I commented in a separate thread, endpoints using page-mode may still > have a local idea of a "virtual confersation". isComposing may be useful > in that context. But I think we may need more guidelines for using it in > page-mode, if we support that at all. > > How is the issue of the message not being sent differ for page-mode and > session-mode? In session-mode, the window that pops up can be kept up even if an isComposing never results in a message actually being received. The SIP BYE marks the end of the session very clearly. For page-mode, it isn't as easy to determine when the UA should stop waiting for an IM after an isComposing was received. There are also privacy issues about sending an isComposing before the actual IM. But I agree with you that proper guidelines might solve these issues. >> To be useful, I think the isComposing indications need to be sent >> inside an explicit, existing dialogue, and with page-mode there is >> none, since the whole notion of a discussion exists only in the minds >> of the participants. >> > > But the notion _does_ exist, even if only in the minds. I have seen SMS > clients that give a conversational user experience. If you can do it in > SMS, you should be able to do it with page-mode IM. Oh, by all means. I'm not arguing against having page-mode give a conversational user experience. It definitely should, but it doesn't necessarily require isComposing just like SMS doesn't. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 18:37:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08868 for ; Thu, 22 Apr 2004 18:37:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmeF-0007Tz-ND for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:26:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMQNkW028756 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:26:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmGN-0000Dm-KH for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:01:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05096 for ; Thu, 22 Apr 2004 18:01:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmGI-0004Cw-LH for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:01:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmFN-0003tz-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:00:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmEg-0003ay-00; Thu, 22 Apr 2004 17:59:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlw0-0006WB-6B; Thu, 22 Apr 2004 17:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGl3W-0001E9-74 for simple@optimus.ietf.org; Thu, 22 Apr 2004 16:44:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28254 for ; Thu, 22 Apr 2004 16:44:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGl3S-00055S-66 for simple@ietf.org; Thu, 22 Apr 2004 16:44:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGl2U-0004mT-00 for simple@ietf.org; Thu, 22 Apr 2004 16:43:18 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGl1a-0004Dd-00 for simple@ietf.org; Thu, 22 Apr 2004 16:42:23 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKfIh29600; Thu, 22 Apr 2004 15:41:18 -0500 Message-ID: <40882DE6.5070405@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:41:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Would the expiration of the "active" state cause this problem to self-heal? Cullen Jennings wrote: > I had a quick read of this and I like it. > > One questions on correlating with the message. Say I opened a windows, a is > composing message was sent, call this M1, then I very quickly typed a > message and this got sent, call this M2. Not idle message is sent. > > Now the network might deliver M2 ahead of M1. The client receiving these > would display the text from M2 then show that the other side was composing > when really it was not. > > This might be a weird corner case not worth solving. It could be solved with > high resolution sender time in both M1 and M2. It could be solved with the > is Composing passing on the message ID of the message that was being > composed. > > I don't care if we choose to ignore this problem but thought it was worth > mentioning. > > > > On 4/21/04 5:54 AM, "hisham.khartabil@nokia.com" > wrote: > > >>The WG chairs would like to start a Working Group Last Call on the following >>drafts: >> >>http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >> >>This WGLC will end on May 5th. >> >>Please send your comments to this mailing list and to the authors. >> >>If you reviewed the draft and found no issues, please indicate so also on the >>mailing list. This will help us evaluate the level of review and group >>consensus. >> >>Thanks, >>Hisham >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 18:37:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08888 for ; Thu, 22 Apr 2004 18:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmoq-0006sI-TT for simple-archive@ietf.org; Thu, 22 Apr 2004 18:37:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmnm-0006YD-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 18:36:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmmk-000669-00; Thu, 22 Apr 2004 18:35:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmTF-00027f-Nz; Thu, 22 Apr 2004 18:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmC7-0004qJ-Vk for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:57:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04679 for ; Thu, 22 Apr 2004 17:57:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmC3-0002xh-63 for simple@ietf.org; Thu, 22 Apr 2004 17:57:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmB5-0002is-00 for simple@ietf.org; Thu, 22 Apr 2004 17:56:16 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGmAu-0002UD-00 for simple@ietf.org; Thu, 22 Apr 2004 17:56:04 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 22 Apr 2004 14:55:34 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Apr 2004 14:55:35 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 14:55:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: "isComposing" and such using MSRP thread-index: AcQorFke9/BbLVyOT7i7BnSY8sTrEgABmjKw From: "Orit Levin" To: "Ben Campbell" Cc: X-OriginalArrivalTime: 22 Apr 2004 21:55:37.0396 (UTC) FILETIME=[8B90BF40:01C428B4] Content-Transfer-Encoding: quoted-printable Subject: [Simple] "isComposing" and such using MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 14:55:35 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I agree that it doesn't relate to the "isComposing" draft itself and consequently to its last call. It is not totally "orthogonal" because it directly feeds the MSRP requirements, the MSRP mechanisms. and the probability that isComposing and MSRP are going to be used together. I would like to understand from the SIMPLE community why they would they oppose to defining "a bit" in the SEND message (being set by the end user) saying respond/don't respond to this message hop-by-hop??? Orit. =20 -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 Sent: Thursday, April 22, 2004 1:57 PM To: Orit Levin Cc: Miguel Garcia; ext Paul Kyzivat; hgs@cs.columbia.edu; simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft As the possibility of removing transaction responses is still a controversial issue in MSRP, I think we can consider it orthagonal to the isComposing draft. That is, we can progress the isComposing draft while still arguing that issue for MSRP. I agree (and commented so in a separate thread.) that we probably don't want DSN/MDN reports for isComposing messages. Orit Levin wrote: > The "isComposing" (or the "isTyping" indication in its simplest use)=20 > greatly improves user experience and is widely used today. >=20 > This is an example of data that does use bandwidth - for IM it can=20 > even double it. On the other hand - this is a kind of data that you=20 > really don't want any responses or acknowledges to: neither end-to-end > nor hop-by-hop. >=20 > I have this example in my "MSRP review" draft. By making hop-by-hop=20 > responses optional per message you immediately reduce the traffic by=20 > 1/4 in this case (even if you response hop-by-hop to every user message)! >=20 > Orit. >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf=20 > Of Miguel Garcia > Sent: Thursday, April 22, 2004 7:25 AM > To: ext Paul Kyzivat > Cc: hgs@cs.columbia.edu; simple@ietf.org > Subject: Re: [Simple] WGLC on isComposing draft >=20 > Well, so let me try to see if understand. We are adding a feature that > just uses bandwidth, because it represents some information that is=20 > able >=20 > to change so oftenly that may require to be updated oftenly.=20 > Furthermore, it is not clear what the receiver can do with such=20 > information. Will an application at the receiver's indicate "Miguel is > composing audio" or "Miguel is composing video" ? I don't think that=20 > is useful. >=20 > Mmmm... in these days of wireless devices and saving bandwidth, this=20 > element seems to go against those principles. >=20 > /Miguel >=20 > ext Paul Kyzivat wrote: >=20 >=20 >> >>Miguel Garcia wrote: >>[snip] >> >> >>>Then I question the usage of the "contenttype" element. I can >=20 > envision >=20 >>>systems where I can start typing a text message and then drag and >=20 > drop >=20 >>>any object (audio or video file). The application will first generate >=20 >=20 >>>an istyping message with the "contenttype" element presumably set to=20 >>>text, which is not correct, >> >> >>It would be correct at the time it is sent. There is never any >=20 > guarantee >=20 >>that the typing will result in a message being sent at all, much less=20 >>what type. >> >> > because I dragged some object later. >> >>When you drag in an object of some other type, your client will need >=20 > to >=20 >>reconsider what the content type is. Then it could send a new=20 >>isComposing message with the new content type. >> >> > I doubt about the usability of this feature. >> >>Well, I agree it isn't clear what the recipient would do with the=20 >>content type information. But other than consuming bandwidth it >=20 > doesn't >=20 >>hurt. >> >> >>>Furthermore, no application will be able to a priori determine >=20 > whether >=20 >>>the user us typing text/plain or text/html, as a user could just add=20 >>>an html tag afterwords. >> >> >>Adding html tags doesn't make the content type html. The sending=20 >>application will have to decide to set the content type to text/html. >=20 > It >=20 >>*might* do that by inspecting the message for html tags, but I would=20 >>find that surprising. I would imagine that some application control=20 >>would need to be selected to cause this to happen. >> >>In any case, as with the drag/drop case above, if/when the application >=20 >=20 >>decides on a different content type than it previously communicated, >=20 > it >=20 >>can send another isComposing with the new content type. But if the=20 >>decision isn't made until the message is sent then presumably it=20 >>wouldn't bother. It might not bother in any case. >> >> Paul >> >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 18:37:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08917 for ; Thu, 22 Apr 2004 18:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmeI-0007WS-7B for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:26:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMQQFY028911 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:26:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmI7-0002Kd-42 for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05262 for ; Thu, 22 Apr 2004 18:03:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmI2-0004nB-8C for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:03:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmH7-0004VC-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:02:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmG2-0004An-00; Thu, 22 Apr 2004 18:01:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlwR-0006uG-Sb; Thu, 22 Apr 2004 17:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlBZ-0002Rz-Qv for simple@optimus.ietf.org; Thu, 22 Apr 2004 16:52:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29338 for ; Thu, 22 Apr 2004 16:52:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlBV-00002W-N6 for simple@ietf.org; Thu, 22 Apr 2004 16:52:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlAO-0007TU-00 for simple@ietf.org; Thu, 22 Apr 2004 16:51:29 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGl93-0006kT-00 for simple@ietf.org; Thu, 22 Apr 2004 16:50:06 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKjXh29703; Thu, 22 Apr 2004 15:45:33 -0500 Message-ID: <40882EE3.5090208@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia CC: hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> In-Reply-To: <4087B8DA.2010202@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:45:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel Garcia wrote: [...] > Then I question the usage of the "contenttype" element. I can envision > systems where I can start typing a text message and then drag and drop > any object (audio or video file). The application will first generate an > istyping message with the "contenttype" element presumably set to text, > which is not correct, because I dragged some object later. I doubt about > the usability of this feature. I think contenttype can be useful, as long as the receiver knows it is just a hint. This is true of is-Composing in general, as I might type something into an external editor and paste it into a message. But if my messaging system happens to have sound recording features built in, and I use them instead of adding a sound attachment, it might be useful. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 18:37:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08920 for ; Thu, 22 Apr 2004 18:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmeI-0007X3-LX for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:26:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMQQ4h028942 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:26:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmIs-0002t6-OK for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:04:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05358 for ; Thu, 22 Apr 2004 18:04:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmIn-00053j-Rh for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:04:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmHq-0004lR-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:03:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmGr-0004SV-00; Thu, 22 Apr 2004 18:02:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlwS-0006uk-Mj; Thu, 22 Apr 2004 17:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlBs-0002ZY-Th for simple@optimus.ietf.org; Thu, 22 Apr 2004 16:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29385 for ; Thu, 22 Apr 2004 16:52:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlBo-00004o-Q0 for simple@ietf.org; Thu, 22 Apr 2004 16:52:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlAc-0007VH-00 for simple@ietf.org; Thu, 22 Apr 2004 16:51:42 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGl9C-0006m5-00 for simple@ietf.org; Thu, 22 Apr 2004 16:50:14 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKnKh29732; Thu, 22 Apr 2004 15:49:20 -0500 Message-ID: <40882FC6.7030002@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FE42.7090608@cs.columbia.edu> In-Reply-To: <4087FE42.7090608@cs.columbia.edu> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:49:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > Paul Kyzivat wrote: > >> I like it. I see one new thing that I consider small: >> >> - I'm a little concerned about the idle timeout being as small as 10 >> seconds. Personally, I am often inclined to stop and think in the >> middle of composing an IM, which could trigger the idle transition >> fairly often. This might generate more traffic than we might like. > > > I'm happy to raise it to 30 seconds. It is a configured interval, so you > could have a philosopher mode that triggers messages less frequently and > an ADD mode that indicates idle sooner... Now that you mention it, is there a conflict between saying this is a "configured interval" and saying it "SHOULD be X seconds"? Does that simply mean it should be X if the user chooses not to configure anything? [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:00:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10187 for ; Thu, 22 Apr 2004 19:00:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmny-00041g-KG for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMaQXq015469 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmbH-0006En-Ja for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:23:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07412 for ; Thu, 22 Apr 2004 18:23:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbC-0002EZ-FM for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:23:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmYp-0001QJ-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:20:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX3-0000tJ-02; Thu, 22 Apr 2004 18:18:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmMY-0004ad-PI; Thu, 22 Apr 2004 18:08:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlyd-0008Mw-BR; Thu, 22 Apr 2004 17:43:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlVt-0007if-P3 for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:13:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01267 for ; Thu, 22 Apr 2004 17:13:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlVp-0006J7-C2 for simple@ietf.org; Thu, 22 Apr 2004 17:13:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlTs-0005e0-00 for simple@ietf.org; Thu, 22 Apr 2004 17:11:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGlQp-0004oh-02 for simple@ietf.org; Thu, 22 Apr 2004 17:08:27 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGlCD-0003df-Qn for simple@ietf.org; Thu, 22 Apr 2004 16:53:22 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKr9h29831; Thu, 22 Apr 2004 15:53:09 -0500 Message-ID: <408830AC.8080409@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Espoo)" CC: ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> In-Reply-To: <4087FFF2.2090509@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:53:00 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Niemi Aki (Nokia-M/Espoo) wrote: > > ext Paul Kyzivat wrote: > >> Then there is the ordering issue that Cullen brought up. It is largely >> an issue because of the possibility of closely spaced messages, which >> in turn relates to more traffic. All in all I wonder if we mignt be >> better to recommend that isComposing SHOULD NOT be used with page mode. > > > I agree. I think isComposing is very valuable for session-mode, but have > strong doubts about it being useful in page-mode. When I start > composing a completely new IM, would the recipient first get a > notification of this? What does it mean if the message is never sent > (i.e., I decide it was a bad idea and trash it.) As I commented in a separate thread, endpoints using page-mode may still have a local idea of a "virtual confersation". isComposing may be useful in that context. But I think we may need more guidelines for using it in page-mode, if we support that at all. How is the issue of the message not being sent differ for page-mode and session-mode? > > To be useful, I think the isComposing indications need to be sent inside > an explicit, existing dialogue, and with page-mode there is none, since > the whole notion of a discussion exists only in the minds of the > participants. > But the notion _does_ exist, even if only in the minds. I have seen SMS clients that give a conversational user experience. If you can do it in SMS, you should be able to do it with page-mode IM. > Cheers, > Aki > >> >> Paul >> >> hisham.khartabil@nokia.com wrote: >> >>> The WG chairs would like to start a Working Group Last Call on the >>> following drafts: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >>> >>> This WGLC will end on May 5th. >>> >>> Please send your comments to this mailing list and to the authors. >>> If you reviewed the draft and found no issues, please indicate so >>> also on the mailing list. This will help us evaluate the level of >>> review and group consensus. >>> >>> Thanks, >>> Hisham >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:00:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10205 for ; Thu, 22 Apr 2004 19:00:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmo1-00044Q-Iw for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMaTGo015642 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmbj-0006Gu-JR for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:23:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07535 for ; Thu, 22 Apr 2004 18:23:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbe-0002Ra-Kk for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:23:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZO-0001ZV-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:21:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX6-0000tV-01; Thu, 22 Apr 2004 18:19:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmJA-0004V7-61; Thu, 22 Apr 2004 18:04:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlxI-0007X2-QR; Thu, 22 Apr 2004 17:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlIv-0003uS-7n for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:00:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29965 for ; Thu, 22 Apr 2004 17:00:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlIr-0002Qj-1A for simple@ietf.org; Thu, 22 Apr 2004 17:00:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlHq-00029t-00 for simple@ietf.org; Thu, 22 Apr 2004 16:59:10 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGlGr-0001dT-00 for simple@ietf.org; Thu, 22 Apr 2004 16:58:09 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKuth29935; Thu, 22 Apr 2004 15:56:55 -0500 Message-ID: <4088318F.40101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:56:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I like this in general. Some minor comments and questions: Am I correct in assuming you never need to refresh idle state? The idea of the idle timeout seems pretty text centric. Would you expect the same behavior if they were recording audio? Maybe you would go to idle when they pressed stop or pause, rather than when a timeout occurred. Nit: "Recipients of messages implementing this specification MUST treat state tokens other than "idle" and "active" as "idle"." You mean "unknown" state tokens, right? Do we have enough guidelines for using with page-mode? It does not seem to make sense to send unsolicited is-composing messages, but it might make sense to create sort of a pseudo-session when one receives a pager-mode message, then send these within that context. By pseudo-session, I mean having the endpoints keep track of a conversation, event though the protocol may not be providing explicit session info. Do you have thoughts about the interaction between is-composing and DSN/MDN? Would you ever want a delivery report for an is-composing message? hisham.khartabil@nokia.com wrote: > The WG chairs would like to start a Working Group Last Call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt > > This WGLC will end on May 5th. > > Please send your comments to this mailing list and to the authors. > > If you reviewed the draft and found no issues, please indicate so also on the mailing list. This will help us evaluate the level of review and group consensus. > > Thanks, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:00:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10239 for ; Thu, 22 Apr 2004 19:00:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmo1-000451-P9 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMaTXI015674 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmbl-0006Hi-Qi for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:23:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07564 for ; Thu, 22 Apr 2004 18:23:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbg-0002Rx-Fz for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:23:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZS-0001aN-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:21:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX6-0000th-01; Thu, 22 Apr 2004 18:19:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmJR-0004VK-A3; Thu, 22 Apr 2004 18:04:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlxJ-0007XE-Cp; Thu, 22 Apr 2004 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlIv-0003uU-W2 for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:00:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29968 for ; Thu, 22 Apr 2004 17:00:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlIr-0002Qp-Mk for simple@ietf.org; Thu, 22 Apr 2004 17:00:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlHq-0002A1-00 for simple@ietf.org; Thu, 22 Apr 2004 16:59:11 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGlGs-0001db-00 for simple@ietf.org; Thu, 22 Apr 2004 16:58:10 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MKudh29931; Thu, 22 Apr 2004 15:56:40 -0500 Message-ID: <4088317F.2060803@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Miguel Garcia , ext Paul Kyzivat , hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 15:56:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As the possibility of removing transaction responses is still a controversial issue in MSRP, I think we can consider it orthagonal to the isComposing draft. That is, we can progress the isComposing draft while still arguing that issue for MSRP. I agree (and commented so in a separate thread.) that we probably don't want DSN/MDN reports for isComposing messages. Orit Levin wrote: > The "isComposing" (or the "isTyping" indication in its simplest use) > greatly improves user experience and is widely used today. > > This is an example of data that does use bandwidth - for IM it can even > double it. On the other hand - this is a kind of data that you really > don't want any responses or acknowledges to: neither end-to-end nor > hop-by-hop. > > I have this example in my "MSRP review" draft. By making hop-by-hop > responses optional per message you immediately reduce the traffic by 1/4 > in this case (even if you response hop-by-hop to every user message)! > > Orit. > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Miguel Garcia > Sent: Thursday, April 22, 2004 7:25 AM > To: ext Paul Kyzivat > Cc: hgs@cs.columbia.edu; simple@ietf.org > Subject: Re: [Simple] WGLC on isComposing draft > > Well, so let me try to see if understand. We are adding a feature that > just uses bandwidth, because it represents some information that is able > > to change so oftenly that may require to be updated oftenly. > Furthermore, it is not clear what the receiver can do with such > information. Will an application at the receiver's indicate "Miguel is > composing audio" or "Miguel is composing video" ? I don't think that is > useful. > > Mmmm... in these days of wireless devices and saving bandwidth, this > element seems to go against those principles. > > /Miguel > > ext Paul Kyzivat wrote: > > >> >>Miguel Garcia wrote: >>[snip] >> >> >>>Then I question the usage of the "contenttype" element. I can > > envision > >>>systems where I can start typing a text message and then drag and > > drop > >>>any object (audio or video file). The application will first generate > > >>>an istyping message with the "contenttype" element presumably set to >>>text, which is not correct, >> >> >>It would be correct at the time it is sent. There is never any > > guarantee > >>that the typing will result in a message being sent at all, much less >>what type. >> >> > because I dragged some object later. >> >>When you drag in an object of some other type, your client will need > > to > >>reconsider what the content type is. Then it could send a new >>isComposing message with the new content type. >> >> > I doubt about the usability of this feature. >> >>Well, I agree it isn't clear what the recipient would do with the >>content type information. But other than consuming bandwidth it > > doesn't > >>hurt. >> >> >>>Furthermore, no application will be able to a priori determine > > whether > >>>the user us typing text/plain or text/html, as a user could just add >>>an html tag afterwords. >> >> >>Adding html tags doesn't make the content type html. The sending >>application will have to decide to set the content type to text/html. > > It > >>*might* do that by inspecting the message for html tags, but I would >>find that surprising. I would imagine that some application control >>would need to be selected to cause this to happen. >> >>In any case, as with the drag/drop case above, if/when the application > > >>decides on a different content type than it previously communicated, > > it > >>can send another isComposing with the new content type. But if the >>decision isn't made until the message is sent then presumably it >>wouldn't bother. It might not bother in any case. >> >> Paul >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:00:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10278 for ; Thu, 22 Apr 2004 19:00:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmo3-00047E-QN for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMaV08015816 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmc1-0006Y3-Nt for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:24:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07701 for ; Thu, 22 Apr 2004 18:24:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbw-0002Ur-Jp for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:24:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZu-0001gz-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:21:55 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX8-0000tV-01; Thu, 22 Apr 2004 18:19:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmHi-0004Td-Tn; Thu, 22 Apr 2004 18:03:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlwV-0006vn-VO; Thu, 22 Apr 2004 17:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlDC-0002pu-JT for simple@optimus.ietf.org; Thu, 22 Apr 2004 16:54:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29518 for ; Thu, 22 Apr 2004 16:54:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlD8-0000dc-Fk for simple@ietf.org; Thu, 22 Apr 2004 16:54:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlC9-0000LX-00 for simple@ietf.org; Thu, 22 Apr 2004 16:53:17 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGlBF-0007ki-00 for simple@ietf.org; Thu, 22 Apr 2004 16:52:21 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3MKqBA0013057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 16:52:12 -0400 (EDT) Message-ID: <4088307C.3060701@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FE42.7090608@cs.columbia.edu> <40882FC6.7030002@dynamicsoft.com> In-Reply-To: <40882FC6.7030002@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 16:52:12 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Now that you mention it, is there a conflict between saying this is a > "configured interval" and saying it "SHOULD be X seconds"? Does that > simply mean it should be X if the user chooses not to configure anything? Yes; I'll clarify. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 19:02:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10449 for ; Thu, 22 Apr 2004 19:02:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnDG-00063Z-Kz for simple-archive@ietf.org; Thu, 22 Apr 2004 19:02:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnCL-0005kd-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 19:01:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnBN-0005RE-00; Thu, 22 Apr 2004 19:00:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmoY-0004Jg-3U; Thu, 22 Apr 2004 18:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmWU-0003zs-Re for simple@optimus.ietf.org; Thu, 22 Apr 2004 18:18:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06941 for ; Thu, 22 Apr 2004 18:18:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmWP-0000sO-Ky for simple@ietf.org; Thu, 22 Apr 2004 18:18:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmVU-0000d3-00 for simple@ietf.org; Thu, 22 Apr 2004 18:17:21 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmUo-00008U-00 for simple@ietf.org; Thu, 22 Apr 2004 18:16:38 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MMG4h31521; Thu, 22 Apr 2004 17:16:04 -0500 Message-ID: <4088441B.9010000@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: simple@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: "isComposing" and such using MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 17:15:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Orit Levin wrote: > I agree that it doesn't relate to the "isComposing" draft itself and > consequently to its last call. > > It is not totally "orthogonal" because it directly feeds the MSRP > requirements, the MSRP mechanisms. and the probability that isComposing > and MSRP are going to be used together. My point was the first, that we should not confuse the isComposing wglc with this issue. I agree this discussion is relevant to MSRP. > > I would like to understand from the SIMPLE community why they would they > oppose to defining "a bit" in the SEND message (being set by the end > user) saying respond/don't respond to this message hop-by-hop??? > The main problem I have with it is it creates protocol complexity. This would require an implementation to understand both transaction models (with or without responses) which adds size to the implementation and extra conditional processing for each request. > Orit. > > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, April 22, 2004 1:57 PM > To: Orit Levin > Cc: Miguel Garcia; ext Paul Kyzivat; hgs@cs.columbia.edu; > simple@ietf.org > Subject: Re: [Simple] WGLC on isComposing draft > > As the possibility of removing transaction responses is still a > controversial issue in MSRP, I think we can consider it orthagonal to > the isComposing draft. That is, we can progress the isComposing draft > while still arguing that issue for MSRP. > > I agree (and commented so in a separate thread.) that we probably don't > want DSN/MDN reports for isComposing messages. > > Orit Levin wrote: > > >>The "isComposing" (or the "isTyping" indication in its simplest use) >>greatly improves user experience and is widely used today. >> >>This is an example of data that does use bandwidth - for IM it can >>even double it. On the other hand - this is a kind of data that you >>really don't want any responses or acknowledges to: neither end-to-end > > >>nor hop-by-hop. >> >>I have this example in my "MSRP review" draft. By making hop-by-hop >>responses optional per message you immediately reduce the traffic by >>1/4 in this case (even if you response hop-by-hop to every user > > message)! > >>Orit. >> >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf >>Of Miguel Garcia >>Sent: Thursday, April 22, 2004 7:25 AM >>To: ext Paul Kyzivat >>Cc: hgs@cs.columbia.edu; simple@ietf.org >>Subject: Re: [Simple] WGLC on isComposing draft >> >>Well, so let me try to see if understand. We are adding a feature that > > >>just uses bandwidth, because it represents some information that is >>able >> >>to change so oftenly that may require to be updated oftenly. >>Furthermore, it is not clear what the receiver can do with such >>information. Will an application at the receiver's indicate "Miguel is > > >>composing audio" or "Miguel is composing video" ? I don't think that >>is useful. >> >>Mmmm... in these days of wireless devices and saving bandwidth, this >>element seems to go against those principles. >> >>/Miguel >> >>ext Paul Kyzivat wrote: >> >> >> >>>Miguel Garcia wrote: >>>[snip] >>> >>> >>> >>>>Then I question the usage of the "contenttype" element. I can >> >>envision >> >> >>>>systems where I can start typing a text message and then drag and >> >>drop >> >> >>>>any object (audio or video file). The application will first generate >> >> >>>>an istyping message with the "contenttype" element presumably set to >>>>text, which is not correct, >>> >>> >>>It would be correct at the time it is sent. There is never any >> >>guarantee >> >> >>>that the typing will result in a message being sent at all, much less >>>what type. >>> >>> >>>>because I dragged some object later. >>> >>>When you drag in an object of some other type, your client will need >> >>to >> >> >>>reconsider what the content type is. Then it could send a new >>>isComposing message with the new content type. >>> >>> >>>>I doubt about the usability of this feature. >>> >>>Well, I agree it isn't clear what the recipient would do with the >>>content type information. But other than consuming bandwidth it >> >>doesn't >> >> >>>hurt. >>> >>> >>> >>>>Furthermore, no application will be able to a priori determine >> >>whether >> >> >>>>the user us typing text/plain or text/html, as a user could just add >>>>an html tag afterwords. >>> >>> >>>Adding html tags doesn't make the content type html. The sending >>>application will have to decide to set the content type to text/html. >> >>It >> >> >>>*might* do that by inspecting the message for html tags, but I would >>>find that surprising. I would imagine that some application control >>>would need to be selected to cause this to happen. >>> >>>In any case, as with the drag/drop case above, if/when the application >> >> >>>decides on a different content type than it previously communicated, >> >>it >> >> >>>can send another isComposing with the new content type. But if the >>>decision isn't made until the message is sent then presumably it >>>wouldn't bother. It might not bother in any case. >>> >>> Paul >>> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:03:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10505 for ; Thu, 22 Apr 2004 19:03:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGn3F-0000oF-OP for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:52:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMqDlo003106 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:52:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmi8-0001DK-6A for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:30:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08226 for ; Thu, 22 Apr 2004 18:30:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmi2-0004aP-Vk for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:30:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmh0-0004GG-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:29:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmfv-0003h8-00; Thu, 22 Apr 2004 18:28:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmQf-0000Oo-Q5; Thu, 22 Apr 2004 18:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm57-0002XP-RR for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03992 for ; Thu, 22 Apr 2004 17:50:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGm53-0000iD-6y for simple@ietf.org; Thu, 22 Apr 2004 17:50:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGm21-0007kI-00 for simple@ietf.org; Thu, 22 Apr 2004 17:46:53 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGly8-0006my-00 for simple@ietf.org; Thu, 22 Apr 2004 17:42:52 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MLgmG14955; Fri, 23 Apr 2004 00:42:48 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 00:42:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3MLgZux017816; Fri, 23 Apr 2004 00:42:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00XvPCvy; Fri, 23 Apr 2004 00:42:34 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MLgVs23286; Fri, 23 Apr 2004 00:42:31 +0300 (EET DST) Received: from nokia.com ([10.162.253.251]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 00:42:32 +0300 Message-ID: <40883C46.3020005@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext David Oran CC: ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <2147483647.1082644817@[10.32.245.156]> In-Reply-To: <2147483647.1082644817@[10.32.245.156]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 21:42:32.0783 (UTC) FILETIME=[B7E64DF0:01C428B2] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 00:42:30 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext David Oran wrote: >> I agree. I think isComposing is very valuable for session-mode, but have >> strong doubts about it being useful in page-mode. When I start composing >> a completely new IM, would the recipient first get a notification of >> this? What does it mean if the message is never sent (i.e., I decide it >> was a bad idea and trash it.) >> > Hmmm, I have an IM client which pops an incoming IM window as soon as > the isComposing comes in. I can really freak people out by quickly > typing them a message ad send it back. They think I'm clairvoyant! > > Is this a really useful feature? Beats me, but why prohibit something > which does no damage? That's just it, it might do damage, because as you point out, the sender isn't aware that information about her messaging activities is leaking out before the send-button is even pushed. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 19:03:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10588 for ; Thu, 22 Apr 2004 19:03:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnEc-0006QD-9s for simple-archive@ietf.org; Thu, 22 Apr 2004 19:03:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnDR-00065l-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 19:02:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnCo-0005mn-00; Thu, 22 Apr 2004 19:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmon-0004P1-O3; Thu, 22 Apr 2004 18:37:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmc0-0006Y0-SZ for simple@optimus.ietf.org; Thu, 22 Apr 2004 18:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07696 for ; Thu, 22 Apr 2004 18:23:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbv-0002Ue-R8 for simple@ietf.org; Thu, 22 Apr 2004 18:23:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZt-0001ge-00 for simple@ietf.org; Thu, 22 Apr 2004 18:21:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX8-0000tV-00 for simple@ietf.org; Thu, 22 Apr 2004 18:19:02 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmHq-0004Tl-2I for simple@ietf.org; Thu, 22 Apr 2004 18:03:14 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3MM2j6r006484 for ; Thu, 22 Apr 2004 17:02:45 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: simple@ietf.org In-Reply-To: <1082559342.2204.52.camel@localhost.localdomain> References: <1082559342.2204.52.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1082671367.2157.256.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 17:02:48 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Writing as a WG member - not as chair - I've sent a list of typo level nits in these drafts to Mikko privately - While doing a nit review, I found some things that should have received list attention earlier. In section 4.4 of -partial-notify it says "The PA SHOULD construct the partial presence document according to the following logic:" followed by a bunch of MUST level statements. Why is that SHOULD there? What would it mean to violate it? I suggest striking it and simply saying "The PA constructs" Why do we have both "state" and "version"? As defined in these drafts, state=full if and only if version=0. You could delete the state parameter with no loss of information, so why is it there? 3261 currently allows overlapping non-INVITE transactions inside a dialog (there's an open issue suggesting this might be a bad thing, see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither 3265 or simple-presence prohibit overlapping NOTIFYs. For full state documents, having multiple outstanding NOTIFYs is probably manageable. For partial state documents, at least as they are specified here, it could be disastrous. Consider four notifies N1(full), N2(partial), N3(full), N4(partial). If the recipient receives only N1 and N4 (something prevents N2 and N3 from being delivered or simply delays them (packetloss over UDP for example)), it will apply the delta in N4 to the wrong full state document (N1 instead of N3). We can preserve the properties of the existing system is we forbid sending a NOTIFY with a document with state="partial" when any other NOTIFY transaction is still in progress on this dialog. Section 4.5 of partial-notify says "If the watcher receives a presence document whose "version" attribute value (is) higher by more than one with the locally stored value, the watcher assumes that one or more NOTIFYs were lost. The watcher SHOULD either refresh the subscription in order to receive a full presence document or terminate the subscription." Why is that SHOULD? In what scenario is any other course of action reasonable? (The only one I can think of is _if_ we allow overlapping partial NOTIFYs, then the watcher can wait around for awhile for the gaps to fill in - if we allow this, then we need to explicitly state this as why the above is SHOULD, not MUST. However, I think this should be a MUST.) Just below that, there's a "SHOULD discard the document" if it gets a partial notification with a lower version number. I don't see how this is right at all, and suggest that this MUST trigger a refresh or termination instead. (We wouldn't get to this logic if a NOTIFY was reordered and arrived late - the CSeq processing logic would have caught it). I'll send a separate message on the Security Considerations section for -partial-notify. RjS On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > This is a Working Group Last call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt > > This abbreviated WGLC will end on Wednesday, April 28. > > These drafts went through a previous last call at the beginning of > March. These versions reflect changes due to comments received during > that period. See > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html > for details. > > Please send comments to the list, copying the editor. If you reviewed > the draft and found no issues, please indicate so on the list. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:04:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10653 for ; Thu, 22 Apr 2004 19:04:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGn4O-00015r-UV for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:53:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMrONb004198 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 18:53:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmli-0002wh-MN for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:34:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08529 for ; Thu, 22 Apr 2004 18:34:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmld-0005ea-P6 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:34:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmkT-0005Ii-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:32:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmjO-0004xY-00; Thu, 22 Apr 2004 18:31:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmQs-0000cK-LA; Thu, 22 Apr 2004 18:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm6i-0002vd-34 for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04275 for ; Thu, 22 Apr 2004 17:51:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGm6d-0001CP-DC for simple@ietf.org; Thu, 22 Apr 2004 17:51:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGm4Z-0000eD-00 for simple@ietf.org; Thu, 22 Apr 2004 17:49:31 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGm1N-0007V7-00 for simple@ietf.org; Thu, 22 Apr 2004 17:46:13 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MLk5607897; Fri, 23 Apr 2004 00:46:05 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 00:45:50 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3MLjo6A021744; Fri, 23 Apr 2004 00:45:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 002Qmq76; Fri, 23 Apr 2004 00:45:49 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MLjks24949; Fri, 23 Apr 2004 00:45:46 +0300 (EET DST) Received: from nokia.com ([10.162.253.251]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 00:45:41 +0300 Message-ID: <40883D03.9020307@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Ben Campbell CC: ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> In-Reply-To: <408830AC.8080409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 21:45:41.0474 (UTC) FILETIME=[285E4420:01C428B3] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 00:45:39 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Ben Campbell wrote: >> I agree. I think isComposing is very valuable for session-mode, but >> have strong doubts about it being useful in page-mode. When I start >> composing a completely new IM, would the recipient first get a >> notification of this? What does it mean if the message is never sent >> (i.e., I decide it was a bad idea and trash it.) > > > As I commented in a separate thread, endpoints using page-mode may still > have a local idea of a "virtual confersation". isComposing may be useful > in that context. But I think we may need more guidelines for using it in > page-mode, if we support that at all. > > How is the issue of the message not being sent differ for page-mode and > session-mode? In session-mode, the window that pops up can be kept up even if an isComposing never results in a message actually being received. The SIP BYE marks the end of the session very clearly. For page-mode, it isn't as easy to determine when the UA should stop waiting for an IM after an isComposing was received. There are also privacy issues about sending an isComposing before the actual IM. But I agree with you that proper guidelines might solve these issues. >> To be useful, I think the isComposing indications need to be sent >> inside an explicit, existing dialogue, and with page-mode there is >> none, since the whole notion of a discussion exists only in the minds >> of the participants. >> > > But the notion _does_ exist, even if only in the minds. I have seen SMS > clients that give a conversational user experience. If you can do it in > SMS, you should be able to do it with page-mode IM. Oh, by all means. I'm not arguing against having page-mode give a conversational user experience. It definitely should, but it doesn't necessarily require isComposing just like SMS doesn't. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:05:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10807 for ; Thu, 22 Apr 2004 19:05:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnD9-0004mN-5B for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:02:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MN2RTY018364 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:02:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmox-0004RL-GG for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:37:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08906 for ; Thu, 22 Apr 2004 18:37:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmos-0006sV-G2 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:37:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmnn-0006YM-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 18:36:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmmk-000669-00; Thu, 22 Apr 2004 18:35:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmTF-00027f-Nz; Thu, 22 Apr 2004 18:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmC7-0004qJ-Vk for simple@optimus.ietf.org; Thu, 22 Apr 2004 17:57:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04679 for ; Thu, 22 Apr 2004 17:57:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmC3-0002xh-63 for simple@ietf.org; Thu, 22 Apr 2004 17:57:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmB5-0002is-00 for simple@ietf.org; Thu, 22 Apr 2004 17:56:16 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGmAu-0002UD-00 for simple@ietf.org; Thu, 22 Apr 2004 17:56:04 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 22 Apr 2004 14:55:34 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Apr 2004 14:55:35 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 14:55:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: "isComposing" and such using MSRP thread-index: AcQorFke9/BbLVyOT7i7BnSY8sTrEgABmjKw From: "Orit Levin" To: "Ben Campbell" Cc: X-OriginalArrivalTime: 22 Apr 2004 21:55:37.0396 (UTC) FILETIME=[8B90BF40:01C428B4] Content-Transfer-Encoding: quoted-printable Subject: [Simple] "isComposing" and such using MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 14:55:35 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree that it doesn't relate to the "isComposing" draft itself and consequently to its last call. It is not totally "orthogonal" because it directly feeds the MSRP requirements, the MSRP mechanisms. and the probability that isComposing and MSRP are going to be used together. I would like to understand from the SIMPLE community why they would they oppose to defining "a bit" in the SEND message (being set by the end user) saying respond/don't respond to this message hop-by-hop??? Orit. =20 -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 Sent: Thursday, April 22, 2004 1:57 PM To: Orit Levin Cc: Miguel Garcia; ext Paul Kyzivat; hgs@cs.columbia.edu; simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft As the possibility of removing transaction responses is still a controversial issue in MSRP, I think we can consider it orthagonal to the isComposing draft. That is, we can progress the isComposing draft while still arguing that issue for MSRP. I agree (and commented so in a separate thread.) that we probably don't want DSN/MDN reports for isComposing messages. Orit Levin wrote: > The "isComposing" (or the "isTyping" indication in its simplest use)=20 > greatly improves user experience and is widely used today. >=20 > This is an example of data that does use bandwidth - for IM it can=20 > even double it. On the other hand - this is a kind of data that you=20 > really don't want any responses or acknowledges to: neither end-to-end > nor hop-by-hop. >=20 > I have this example in my "MSRP review" draft. By making hop-by-hop=20 > responses optional per message you immediately reduce the traffic by=20 > 1/4 in this case (even if you response hop-by-hop to every user message)! >=20 > Orit. >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf=20 > Of Miguel Garcia > Sent: Thursday, April 22, 2004 7:25 AM > To: ext Paul Kyzivat > Cc: hgs@cs.columbia.edu; simple@ietf.org > Subject: Re: [Simple] WGLC on isComposing draft >=20 > Well, so let me try to see if understand. We are adding a feature that > just uses bandwidth, because it represents some information that is=20 > able >=20 > to change so oftenly that may require to be updated oftenly.=20 > Furthermore, it is not clear what the receiver can do with such=20 > information. Will an application at the receiver's indicate "Miguel is > composing audio" or "Miguel is composing video" ? I don't think that=20 > is useful. >=20 > Mmmm... in these days of wireless devices and saving bandwidth, this=20 > element seems to go against those principles. >=20 > /Miguel >=20 > ext Paul Kyzivat wrote: >=20 >=20 >> >>Miguel Garcia wrote: >>[snip] >> >> >>>Then I question the usage of the "contenttype" element. I can >=20 > envision >=20 >>>systems where I can start typing a text message and then drag and >=20 > drop >=20 >>>any object (audio or video file). The application will first generate >=20 >=20 >>>an istyping message with the "contenttype" element presumably set to=20 >>>text, which is not correct, >> >> >>It would be correct at the time it is sent. There is never any >=20 > guarantee >=20 >>that the typing will result in a message being sent at all, much less=20 >>what type. >> >> > because I dragged some object later. >> >>When you drag in an object of some other type, your client will need >=20 > to >=20 >>reconsider what the content type is. Then it could send a new=20 >>isComposing message with the new content type. >> >> > I doubt about the usability of this feature. >> >>Well, I agree it isn't clear what the recipient would do with the=20 >>content type information. But other than consuming bandwidth it >=20 > doesn't >=20 >>hurt. >> >> >>>Furthermore, no application will be able to a priori determine >=20 > whether >=20 >>>the user us typing text/plain or text/html, as a user could just add=20 >>>an html tag afterwords. >> >> >>Adding html tags doesn't make the content type html. The sending=20 >>application will have to decide to set the content type to text/html. >=20 > It >=20 >>*might* do that by inspecting the message for html tags, but I would=20 >>find that surprising. I would imagine that some application control=20 >>would need to be selected to cause this to happen. >> >>In any case, as with the drag/drop case above, if/when the application >=20 >=20 >>decides on a different content type than it previously communicated, >=20 > it >=20 >>can send another isComposing with the new content type. But if the=20 >>decision isn't made until the message is sent then presumably it=20 >>wouldn't bother. It might not bother in any case. >> >> Paul >> >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 19:11:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11302 for ; Thu, 22 Apr 2004 19:11:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnLp-000108-8W for simple-archive@ietf.org; Thu, 22 Apr 2004 19:11:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnKr-0000kJ-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 19:10:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnKS-0000V0-00; Thu, 22 Apr 2004 19:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnDj-0004zc-QL; Thu, 22 Apr 2004 19:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmq8-0004yt-7T for simple@optimus.ietf.org; Thu, 22 Apr 2004 18:38:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09077 for ; Thu, 22 Apr 2004 18:38:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmq3-0007D8-4X for simple@ietf.org; Thu, 22 Apr 2004 18:38:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmp2-0006tx-00 for simple@ietf.org; Thu, 22 Apr 2004 18:37:33 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmoA-0006Lj-00 for simple@ietf.org; Thu, 22 Apr 2004 18:36:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 14:46:57 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3MMa8Su001918; Thu, 22 Apr 2004 15:36:08 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU69989; Thu, 22 Apr 2004 18:36:06 -0400 (EDT) Message-ID: <408848D6.7020205@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4088318F.40101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 18:36:06 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > Do we have enough guidelines for using with page-mode? It does not seem > to make sense to send unsolicited is-composing messages, but it might > make sense to create sort of a pseudo-session when one receives a > pager-mode message, then send these within that context. By > pseudo-session, I mean having the endpoints keep track of a > conversation, event though the protocol may not be providing explicit > session info. I think this is just a glimse of a bigger iceburg lurking on the horizon: I think there we are eventually going to have to provide some sort of guidelines for when to use page mode, when to use session mode, and when to transition between them. Whe we start to talk about pseudo-sessions that tie together page mode messages we are heading in that direction. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:14:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11512 for ; Thu, 22 Apr 2004 19:14:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnGF-0005xV-77 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:05:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MN5d7k022899 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:05:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnDM-0004pX-JP for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 19:02:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10467 for ; Thu, 22 Apr 2004 19:02:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnDH-00063e-B2 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 19:02:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnCM-0005kk-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 19:01:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnBN-0005RE-00; Thu, 22 Apr 2004 19:00:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmoY-0004Jg-3U; Thu, 22 Apr 2004 18:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmWU-0003zs-Re for simple@optimus.ietf.org; Thu, 22 Apr 2004 18:18:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06941 for ; Thu, 22 Apr 2004 18:18:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmWP-0000sO-Ky for simple@ietf.org; Thu, 22 Apr 2004 18:18:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmVU-0000d3-00 for simple@ietf.org; Thu, 22 Apr 2004 18:17:21 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmUo-00008U-00 for simple@ietf.org; Thu, 22 Apr 2004 18:16:38 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MMG4h31521; Thu, 22 Apr 2004 17:16:04 -0500 Message-ID: <4088441B.9010000@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: simple@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: "isComposing" and such using MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 17:15:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit Levin wrote: > I agree that it doesn't relate to the "isComposing" draft itself and > consequently to its last call. > > It is not totally "orthogonal" because it directly feeds the MSRP > requirements, the MSRP mechanisms. and the probability that isComposing > and MSRP are going to be used together. My point was the first, that we should not confuse the isComposing wglc with this issue. I agree this discussion is relevant to MSRP. > > I would like to understand from the SIMPLE community why they would they > oppose to defining "a bit" in the SEND message (being set by the end > user) saying respond/don't respond to this message hop-by-hop??? > The main problem I have with it is it creates protocol complexity. This would require an implementation to understand both transaction models (with or without responses) which adds size to the implementation and extra conditional processing for each request. > Orit. > > > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, April 22, 2004 1:57 PM > To: Orit Levin > Cc: Miguel Garcia; ext Paul Kyzivat; hgs@cs.columbia.edu; > simple@ietf.org > Subject: Re: [Simple] WGLC on isComposing draft > > As the possibility of removing transaction responses is still a > controversial issue in MSRP, I think we can consider it orthagonal to > the isComposing draft. That is, we can progress the isComposing draft > while still arguing that issue for MSRP. > > I agree (and commented so in a separate thread.) that we probably don't > want DSN/MDN reports for isComposing messages. > > Orit Levin wrote: > > >>The "isComposing" (or the "isTyping" indication in its simplest use) >>greatly improves user experience and is widely used today. >> >>This is an example of data that does use bandwidth - for IM it can >>even double it. On the other hand - this is a kind of data that you >>really don't want any responses or acknowledges to: neither end-to-end > > >>nor hop-by-hop. >> >>I have this example in my "MSRP review" draft. By making hop-by-hop >>responses optional per message you immediately reduce the traffic by >>1/4 in this case (even if you response hop-by-hop to every user > > message)! > >>Orit. >> >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf >>Of Miguel Garcia >>Sent: Thursday, April 22, 2004 7:25 AM >>To: ext Paul Kyzivat >>Cc: hgs@cs.columbia.edu; simple@ietf.org >>Subject: Re: [Simple] WGLC on isComposing draft >> >>Well, so let me try to see if understand. We are adding a feature that > > >>just uses bandwidth, because it represents some information that is >>able >> >>to change so oftenly that may require to be updated oftenly. >>Furthermore, it is not clear what the receiver can do with such >>information. Will an application at the receiver's indicate "Miguel is > > >>composing audio" or "Miguel is composing video" ? I don't think that >>is useful. >> >>Mmmm... in these days of wireless devices and saving bandwidth, this >>element seems to go against those principles. >> >>/Miguel >> >>ext Paul Kyzivat wrote: >> >> >> >>>Miguel Garcia wrote: >>>[snip] >>> >>> >>> >>>>Then I question the usage of the "contenttype" element. I can >> >>envision >> >> >>>>systems where I can start typing a text message and then drag and >> >>drop >> >> >>>>any object (audio or video file). The application will first generate >> >> >>>>an istyping message with the "contenttype" element presumably set to >>>>text, which is not correct, >>> >>> >>>It would be correct at the time it is sent. There is never any >> >>guarantee >> >> >>>that the typing will result in a message being sent at all, much less >>>what type. >>> >>> >>>>because I dragged some object later. >>> >>>When you drag in an object of some other type, your client will need >> >>to >> >> >>>reconsider what the content type is. Then it could send a new >>>isComposing message with the new content type. >>> >>> >>>>I doubt about the usability of this feature. >>> >>>Well, I agree it isn't clear what the recipient would do with the >>>content type information. But other than consuming bandwidth it >> >>doesn't >> >> >>>hurt. >>> >>> >>> >>>>Furthermore, no application will be able to a priori determine >> >>whether >> >> >>>>the user us typing text/plain or text/html, as a user could just add >>>>an html tag afterwords. >>> >>> >>>Adding html tags doesn't make the content type html. The sending >>>application will have to decide to set the content type to text/html. >> >>It >> >> >>>*might* do that by inspecting the message for html tags, but I would >>>find that surprising. I would imagine that some application control >>>would need to be selected to cause this to happen. >>> >>>In any case, as with the drag/drop case above, if/when the application >> >> >>>decides on a different content type than it previously communicated, >> >>it >> >> >>>can send another isComposing with the new content type. But if the >>>decision isn't made until the message is sent then presumably it >>>wouldn't bother. It might not bother in any case. >>> >>> Paul >>> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 19:14:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11566 for ; Thu, 22 Apr 2004 19:14:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnOk-0001tq-CX for simple-archive@ietf.org; Thu, 22 Apr 2004 19:14:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnNq-0001bP-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 19:13:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnMp-0001I3-00; Thu, 22 Apr 2004 19:12:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnFh-0005uA-4b; Thu, 22 Apr 2004 19:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnAC-0002hU-O8 for simple@optimus.ietf.org; Thu, 22 Apr 2004 18:59:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10069 for ; Thu, 22 Apr 2004 18:59:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnA7-00056w-D7 for simple@ietf.org; Thu, 22 Apr 2004 18:59:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGn9A-0004rE-00 for simple@ietf.org; Thu, 22 Apr 2004 18:58:20 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGn8O-0004MZ-00 for simple@ietf.org; Thu, 22 Apr 2004 18:57:32 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MMuDh32255; Thu, 22 Apr 2004 17:56:13 -0500 Message-ID: <40884D84.8080108@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4088318F.40101@dynamicsoft.com> <408848D6.7020205@cisco.com> In-Reply-To: <408848D6.7020205@cisco.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 17:56:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> Do we have enough guidelines for using with page-mode? It does not >> seem to make sense to send unsolicited is-composing messages, but it >> might make sense to create sort of a pseudo-session when one receives >> a pager-mode message, then send these within that context. By >> pseudo-session, I mean having the endpoints keep track of a >> conversation, event though the protocol may not be providing explicit >> session info. > > > I think this is just a glimse of a bigger iceburg lurking on the horizon: > > I think there we are eventually going to have to provide some sort of > guidelines for when to use page mode, when to use session mode, and when > to transition between them. Whe we start to talk about pseudo-sessions > that tie together page mode messages we are heading in that direction. Agreed. We have a lot of guidelines we need to write, and not just for this. The last SIPIT made it clear that we need to get the SIMPLE architecture work moving again. This is one item that probably should be addressed there. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:26:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11987 for ; Thu, 22 Apr 2004 19:26:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnMX-0000I1-84 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:12:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MNC9GS001109 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:12:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnEk-0005JF-PL for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 19:04:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10607 for ; Thu, 22 Apr 2004 19:04:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnEf-0006Qm-Gt for simple-web-archive@ietf.org; Thu, 22 Apr 2004 19:04:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnDS-00065w-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 19:02:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnCo-0005mn-00; Thu, 22 Apr 2004 19:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmon-0004P1-O3; Thu, 22 Apr 2004 18:37:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmc0-0006Y0-SZ for simple@optimus.ietf.org; Thu, 22 Apr 2004 18:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07696 for ; Thu, 22 Apr 2004 18:23:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbv-0002Ue-R8 for simple@ietf.org; Thu, 22 Apr 2004 18:23:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZt-0001ge-00 for simple@ietf.org; Thu, 22 Apr 2004 18:21:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX8-0000tV-00 for simple@ietf.org; Thu, 22 Apr 2004 18:19:02 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmHq-0004Tl-2I for simple@ietf.org; Thu, 22 Apr 2004 18:03:14 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3MM2j6r006484 for ; Thu, 22 Apr 2004 17:02:45 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: simple@ietf.org In-Reply-To: <1082559342.2204.52.camel@localhost.localdomain> References: <1082559342.2204.52.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1082671367.2157.256.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 17:02:48 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Writing as a WG member - not as chair - I've sent a list of typo level nits in these drafts to Mikko privately - While doing a nit review, I found some things that should have received list attention earlier. In section 4.4 of -partial-notify it says "The PA SHOULD construct the partial presence document according to the following logic:" followed by a bunch of MUST level statements. Why is that SHOULD there? What would it mean to violate it? I suggest striking it and simply saying "The PA constructs" Why do we have both "state" and "version"? As defined in these drafts, state=full if and only if version=0. You could delete the state parameter with no loss of information, so why is it there? 3261 currently allows overlapping non-INVITE transactions inside a dialog (there's an open issue suggesting this might be a bad thing, see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither 3265 or simple-presence prohibit overlapping NOTIFYs. For full state documents, having multiple outstanding NOTIFYs is probably manageable. For partial state documents, at least as they are specified here, it could be disastrous. Consider four notifies N1(full), N2(partial), N3(full), N4(partial). If the recipient receives only N1 and N4 (something prevents N2 and N3 from being delivered or simply delays them (packetloss over UDP for example)), it will apply the delta in N4 to the wrong full state document (N1 instead of N3). We can preserve the properties of the existing system is we forbid sending a NOTIFY with a document with state="partial" when any other NOTIFY transaction is still in progress on this dialog. Section 4.5 of partial-notify says "If the watcher receives a presence document whose "version" attribute value (is) higher by more than one with the locally stored value, the watcher assumes that one or more NOTIFYs were lost. The watcher SHOULD either refresh the subscription in order to receive a full presence document or terminate the subscription." Why is that SHOULD? In what scenario is any other course of action reasonable? (The only one I can think of is _if_ we allow overlapping partial NOTIFYs, then the watcher can wait around for awhile for the gaps to fill in - if we allow this, then we need to explicitly state this as why the above is SHOULD, not MUST. However, I think this should be a MUST.) Just below that, there's a "SHOULD discard the document" if it gets a partial notification with a lower version number. I don't see how this is right at all, and suggest that this MUST trigger a refresh or termination instead. (We wouldn't get to this logic if a NOTIFY was reordered and arrived late - the CSeq processing logic would have caught it). I'll send a separate message on the Security Considerations section for -partial-notify. RjS On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > This is a Working Group Last call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt > > This abbreviated WGLC will end on Wednesday, April 28. > > These drafts went through a previous last call at the beginning of > March. These versions reflect changes due to comments received during > that period. See > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html > for details. > > Please send comments to the list, copying the editor. If you reviewed > the draft and found no issues, please indicate so on the list. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:28:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12193 for ; Thu, 22 Apr 2004 19:28:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnOp-0001AX-MM for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:14:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MNEV4g004489 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:14:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnLv-0008GQ-G4 for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 19:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11320 for ; Thu, 22 Apr 2004 19:11:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnLq-00010E-4M for simple-web-archive@ietf.org; Thu, 22 Apr 2004 19:11:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnKr-0000kQ-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 19:10:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnKS-0000V0-00; Thu, 22 Apr 2004 19:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnDj-0004zc-QL; Thu, 22 Apr 2004 19:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmq8-0004yt-7T for simple@optimus.ietf.org; Thu, 22 Apr 2004 18:38:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09077 for ; Thu, 22 Apr 2004 18:38:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmq3-0007D8-4X for simple@ietf.org; Thu, 22 Apr 2004 18:38:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmp2-0006tx-00 for simple@ietf.org; Thu, 22 Apr 2004 18:37:33 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmoA-0006Lj-00 for simple@ietf.org; Thu, 22 Apr 2004 18:36:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 14:46:57 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3MMa8Su001918; Thu, 22 Apr 2004 15:36:08 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU69989; Thu, 22 Apr 2004 18:36:06 -0400 (EDT) Message-ID: <408848D6.7020205@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4088318F.40101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 18:36:06 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > Do we have enough guidelines for using with page-mode? It does not seem > to make sense to send unsolicited is-composing messages, but it might > make sense to create sort of a pseudo-session when one receives a > pager-mode message, then send these within that context. By > pseudo-session, I mean having the endpoints keep track of a > conversation, event though the protocol may not be providing explicit > session info. I think this is just a glimse of a bigger iceburg lurking on the horizon: I think there we are eventually going to have to provide some sort of guidelines for when to use page mode, when to use session mode, and when to transition between them. Whe we start to talk about pseudo-sessions that tie together page mode messages we are heading in that direction. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 19:32:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12466 for ; Thu, 22 Apr 2004 19:32:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGncE-0004ph-3O for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:28:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MNSMLJ018571 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 19:28:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnOo-00019o-JG for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 19:14:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11584 for ; Thu, 22 Apr 2004 19:14:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnOl-0001tw-2W for simple-web-archive@ietf.org; Thu, 22 Apr 2004 19:14:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnNq-0001bW-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 19:13:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnMp-0001I3-00; Thu, 22 Apr 2004 19:12:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnFh-0005uA-4b; Thu, 22 Apr 2004 19:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnAC-0002hU-O8 for simple@optimus.ietf.org; Thu, 22 Apr 2004 18:59:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10069 for ; Thu, 22 Apr 2004 18:59:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnA7-00056w-D7 for simple@ietf.org; Thu, 22 Apr 2004 18:59:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGn9A-0004rE-00 for simple@ietf.org; Thu, 22 Apr 2004 18:58:20 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BGn8O-0004MZ-00 for simple@ietf.org; Thu, 22 Apr 2004 18:57:32 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3MMuDh32255; Thu, 22 Apr 2004 17:56:13 -0500 Message-ID: <40884D84.8080108@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4088318F.40101@dynamicsoft.com> <408848D6.7020205@cisco.com> In-Reply-To: <408848D6.7020205@cisco.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 17:56:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> Do we have enough guidelines for using with page-mode? It does not >> seem to make sense to send unsolicited is-composing messages, but it >> might make sense to create sort of a pseudo-session when one receives >> a pager-mode message, then send these within that context. By >> pseudo-session, I mean having the endpoints keep track of a >> conversation, event though the protocol may not be providing explicit >> session info. > > > I think this is just a glimse of a bigger iceburg lurking on the horizon: > > I think there we are eventually going to have to provide some sort of > guidelines for when to use page mode, when to use session mode, and when > to transition between them. Whe we start to talk about pseudo-sessions > that tie together page mode messages we are heading in that direction. Agreed. We have a lot of guidelines we need to write, and not just for this. The last SIPIT made it clear that we need to get the SIMPLE architecture work moving again. This is one item that probably should be addressed there. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 21:40:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18387 for ; Thu, 22 Apr 2004 21:40:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpg6-0001aJ-Qp for simple-archive@ietf.org; Thu, 22 Apr 2004 21:40:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpf3-0001Jz-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 21:39:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGpeV-000157-00; Thu, 22 Apr 2004 21:38:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpVx-0002GV-SD; Thu, 22 Apr 2004 21:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpMz-0007sX-VO for simple@optimus.ietf.org; Thu, 22 Apr 2004 21:20:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17705 for ; Thu, 22 Apr 2004 21:20:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpMv-0004Cg-39 for simple@ietf.org; Thu, 22 Apr 2004 21:20:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpLd-0003wL-00 for simple@ietf.org; Thu, 22 Apr 2004 21:19:21 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGpKe-0003RF-00 for simple@ietf.org; Thu, 22 Apr 2004 21:18:20 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 22 Apr 2004 18:17:48 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Apr 2004 18:17:52 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 18:18:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: "isComposing" and such using MSRP thread-index: AcQot2Im9tc2x6B7TYCKMXKoKihYMwAGIiOg From: "Orit Levin" To: "Ben Campbell" Cc: X-OriginalArrivalTime: 23 Apr 2004 01:18:08.0951 (UTC) FILETIME=[D674E470:01C428D0] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: "isComposing" and such using MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 18:17:52 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable =20 >=20 > I would like to understand from the SIMPLE community why they would=20 > they oppose to defining "a bit" in the SEND message (being set by the=20 > end > user) saying respond/don't respond to this message hop-by-hop??? >=20 The main problem I have with it is it creates protocol complexity. This would require an implementation to understand both transaction models (with or without responses) which adds size to the implementation and extra conditional processing for each request. OL: The involved "complexity" means: - Looking into the header (which is being processed anyway for routing purposes) - A single additional "If" with the resultant skipping of related logic Does anybody consider it as a real overhead? Any other objections? Orit. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 21:44:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18622 for ; Thu, 22 Apr 2004 21:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpiR-0006bW-H7 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 21:42:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N1gtxs025386 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 21:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpgF-0005oU-Gv for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 21:40:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18405 for ; Thu, 22 Apr 2004 21:40:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpgA-0001ay-KX for simple-web-archive@ietf.org; Thu, 22 Apr 2004 21:40:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpf4-0001KE-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 21:39:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGpeV-000157-00; Thu, 22 Apr 2004 21:38:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpVx-0002GV-SD; Thu, 22 Apr 2004 21:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpMz-0007sX-VO for simple@optimus.ietf.org; Thu, 22 Apr 2004 21:20:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17705 for ; Thu, 22 Apr 2004 21:20:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpMv-0004Cg-39 for simple@ietf.org; Thu, 22 Apr 2004 21:20:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpLd-0003wL-00 for simple@ietf.org; Thu, 22 Apr 2004 21:19:21 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BGpKe-0003RF-00 for simple@ietf.org; Thu, 22 Apr 2004 21:18:20 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 22 Apr 2004 18:17:48 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Apr 2004 18:17:52 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Apr 2004 18:18:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: "isComposing" and such using MSRP thread-index: AcQot2Im9tc2x6B7TYCKMXKoKihYMwAGIiOg From: "Orit Levin" To: "Ben Campbell" Cc: X-OriginalArrivalTime: 23 Apr 2004 01:18:08.0951 (UTC) FILETIME=[D674E470:01C428D0] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: "isComposing" and such using MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 18:17:52 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 >=20 > I would like to understand from the SIMPLE community why they would=20 > they oppose to defining "a bit" in the SEND message (being set by the=20 > end > user) saying respond/don't respond to this message hop-by-hop??? >=20 The main problem I have with it is it creates protocol complexity. This would require an implementation to understand both transaction models (with or without responses) which adds size to the implementation and extra conditional processing for each request. OL: The involved "complexity" means: - Looking into the header (which is being processed anyway for routing purposes) - A single additional "If" with the resultant skipping of related logic Does anybody consider it as a real overhead? Any other objections? Orit. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 22:48:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22213 for ; Thu, 22 Apr 2004 22:48:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqjx-0004ln-V8 for simple-archive@ietf.org; Thu, 22 Apr 2004 22:48:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqiz-0004VV-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 22:47:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGqid-0004G0-00; Thu, 22 Apr 2004 22:47:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqak-0007Vl-1y; Thu, 22 Apr 2004 22:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqRa-0003rj-Gf for simple@optimus.ietf.org; Thu, 22 Apr 2004 22:29:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21388 for ; Thu, 22 Apr 2004 22:29:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqRV-0007Qd-5s for simple@ietf.org; Thu, 22 Apr 2004 22:29:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqQZ-000793-00 for simple@ietf.org; Thu, 22 Apr 2004 22:28:31 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGqPk-0006tC-00 for simple@ietf.org; Thu, 22 Apr 2004 22:27:40 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3N2RTA0004341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 22:27:30 -0400 (EDT) Message-ID: <40887F0B.6070007@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Espoo)" CC: ext Ben Campbell , ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> <40883D03.9020307@nokia.com> In-Reply-To: <40883D03.9020307@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 22:27:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > For page-mode, it isn't as easy to determine when the UA should stop > waiting for an IM after an isComposing was received. There wouldn't really be waiting. At least in our implementation, you just see a message "Alice is composing a message" or something like that, which disappears after a while. > > There are also privacy issues about sending an isComposing before the > actual IM. I can see this for the first IM in page mode, but otherwise I fail to see the difference between the two modes. > Oh, by all means. I'm not arguing against having page-mode give a > conversational user experience. It definitely should, but it doesn't > necessarily require isComposing just like SMS doesn't. You can certainly do page mode (or session mode) without isComposing, but I find the user experience much better with it. In both scenarios, it avoids 'double-talking', in that the sender of the last message is not sure if the other side is responding, if the conversation snippet is over or if the other side expects more. As a practical matter, page-mode style systems (like MSN messenger) have the feature, and it doesn't seem to have caused a problem. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 22 22:50:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22328 for ; Thu, 22 Apr 2004 22:50:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqls-0005Ip-AO for simple-archive@ietf.org; Thu, 22 Apr 2004 22:50:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGql1-00053D-00 for simple-archive@ietf.org; Thu, 22 Apr 2004 22:49:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGqkd-0004mi-00; Thu, 22 Apr 2004 22:49:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqan-0007XG-NV; Thu, 22 Apr 2004 22:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqZK-0006VH-9o for simple@optimus.ietf.org; Thu, 22 Apr 2004 22:37:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21680 for ; Thu, 22 Apr 2004 22:37:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqZE-0001lO-ST for simple@ietf.org; Thu, 22 Apr 2004 22:37:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqYI-0001W9-00 for simple@ietf.org; Thu, 22 Apr 2004 22:36:30 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGqXm-0001Gx-00 for simple@ietf.org; Thu, 22 Apr 2004 22:35:58 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3N2ZvA0005069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 22:35:58 -0400 (EDT) Message-ID: <40888107.7080207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Ben Campbell CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> In-Reply-To: <408830AC.8080409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 22:35:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > As I commented in a separate thread, endpoints using page-mode may still > have a local idea of a "virtual confersation". isComposing may be useful > in that context. But I think we may need more guidelines for using it in > page-mode, if we support that at all. I suppose this comes back to how much user interface guidance we want to provide. None of this is necessary for interoperability - if I want to send isComposing before the first bit of text, this will work just fine and there may even be scenarios where this makes sense. For example, for audio and video messages, a bit of warning before the message comes out of the speaker wouldn't hurt. I think we should not assume that MSRP sessions correspond to human conversations. IM conversations seem to come in brief spurts, with pauses in between, but no formal farewell or 'ringing' (beyond, maybe, an initial Hi!). I would imagine that the lower-layer sessions will often stay up indefinitely between co-workers, so that a sudden isComposing after two days of silence is not substantially different, from a user experience and privacy perspective, just because there is an on-going SIP session underneath that is largely invisible to the user. If a session has to be manually 'picked up' at the receiver, users aren't likely to tear them down. If they wanted a phone call experience, they would place a call. If the session is automatically accepted, the user experience doesn't differ from page mode. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 22:55:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22522 for ; Thu, 22 Apr 2004 22:55:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqlS-0002Gc-Nw for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 22:50:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N2o64E008708 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 22:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqk4-0001WP-4P for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 22:48:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22231 for ; Thu, 22 Apr 2004 22:48:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqjy-0004ls-Kd for simple-web-archive@ietf.org; Thu, 22 Apr 2004 22:48:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqiz-0004Vd-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 22:47:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGqid-0004G0-00; Thu, 22 Apr 2004 22:47:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqak-0007Vl-1y; Thu, 22 Apr 2004 22:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqRa-0003rj-Gf for simple@optimus.ietf.org; Thu, 22 Apr 2004 22:29:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21388 for ; Thu, 22 Apr 2004 22:29:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqRV-0007Qd-5s for simple@ietf.org; Thu, 22 Apr 2004 22:29:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqQZ-000793-00 for simple@ietf.org; Thu, 22 Apr 2004 22:28:31 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGqPk-0006tC-00 for simple@ietf.org; Thu, 22 Apr 2004 22:27:40 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3N2RTA0004341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 22:27:30 -0400 (EDT) Message-ID: <40887F0B.6070007@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Espoo)" CC: ext Ben Campbell , ext Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> <40883D03.9020307@nokia.com> In-Reply-To: <40883D03.9020307@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 22:27:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > For page-mode, it isn't as easy to determine when the UA should stop > waiting for an IM after an isComposing was received. There wouldn't really be waiting. At least in our implementation, you just see a message "Alice is composing a message" or something like that, which disappears after a while. > > There are also privacy issues about sending an isComposing before the > actual IM. I can see this for the first IM in page mode, but otherwise I fail to see the difference between the two modes. > Oh, by all means. I'm not arguing against having page-mode give a > conversational user experience. It definitely should, but it doesn't > necessarily require isComposing just like SMS doesn't. You can certainly do page mode (or session mode) without isComposing, but I find the user experience much better with it. In both scenarios, it avoids 'double-talking', in that the sender of the last message is not sure if the other side is responding, if the conversation snippet is over or if the other side expects more. As a practical matter, page-mode style systems (like MSN messenger) have the feature, and it doesn't seem to have caused a problem. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 22 23:05:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23112 for ; Thu, 22 Apr 2004 23:05:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqrA-00044P-LD for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 22:56:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N2u0mq015641 for simple-archive@odin.ietf.org; Thu, 22 Apr 2004 22:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqly-0002LH-GE for simple-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 22:50:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22346 for ; Thu, 22 Apr 2004 22:50:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqls-0005Iu-W8 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 22:50:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGql2-00053K-00 for simple-web-archive@ietf.org; Thu, 22 Apr 2004 22:49:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGqkd-0004mi-00; Thu, 22 Apr 2004 22:49:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqan-0007XG-NV; Thu, 22 Apr 2004 22:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqZK-0006VH-9o for simple@optimus.ietf.org; Thu, 22 Apr 2004 22:37:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21680 for ; Thu, 22 Apr 2004 22:37:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqZE-0001lO-ST for simple@ietf.org; Thu, 22 Apr 2004 22:37:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqYI-0001W9-00 for simple@ietf.org; Thu, 22 Apr 2004 22:36:30 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BGqXm-0001Gx-00 for simple@ietf.org; Thu, 22 Apr 2004 22:35:58 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3N2ZvA0005069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Apr 2004 22:35:58 -0400 (EDT) Message-ID: <40888107.7080207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Ben Campbell CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> In-Reply-To: <408830AC.8080409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 22:35:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > As I commented in a separate thread, endpoints using page-mode may still > have a local idea of a "virtual confersation". isComposing may be useful > in that context. But I think we may need more guidelines for using it in > page-mode, if we support that at all. I suppose this comes back to how much user interface guidance we want to provide. None of this is necessary for interoperability - if I want to send isComposing before the first bit of text, this will work just fine and there may even be scenarios where this makes sense. For example, for audio and video messages, a bit of warning before the message comes out of the speaker wouldn't hurt. I think we should not assume that MSRP sessions correspond to human conversations. IM conversations seem to come in brief spurts, with pauses in between, but no formal farewell or 'ringing' (beyond, maybe, an initial Hi!). I would imagine that the lower-layer sessions will often stay up indefinitely between co-workers, so that a sudden isComposing after two days of silence is not substantially different, from a user experience and privacy perspective, just because there is an on-going SIP session underneath that is largely invisible to the user. If a session has to be manually 'picked up' at the receiver, users aren't likely to tear them down. If they wanted a phone call experience, they would place a call. If the session is automatically accepted, the user experience doesn't differ from page mode. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 03:54:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20441 for ; Fri, 23 Apr 2004 03:54:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGvWM-0002WD-R0 for simple-archive@ietf.org; Fri, 23 Apr 2004 03:54:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGvVN-0002Dz-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 03:53:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGvUS-0001vo-00; Fri, 23 Apr 2004 03:52:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGvPp-0007xD-Gj; Fri, 23 Apr 2004 03:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGvMd-0006Uv-Rp for simple@optimus.ietf.org; Fri, 23 Apr 2004 03:44:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19917 for ; Fri, 23 Apr 2004 03:44:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGvMZ-0007Pu-9G for simple@ietf.org; Fri, 23 Apr 2004 03:44:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGvLg-0007AI-00 for simple@ietf.org; Fri, 23 Apr 2004 03:43:49 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BGvLN-0006uT-00 for simple@ietf.org; Fri, 23 Apr 2004 03:43:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3N7hAm17044; Fri, 23 Apr 2004 10:43:10 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 10:42:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3N7gt69006722; Fri, 23 Apr 2004 10:42:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00xzr4qn; Fri, 23 Apr 2004 10:42:53 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3N7Ous11160; Fri, 23 Apr 2004 10:24:56 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 10:24:56 +0300 Message-ID: <4088C4C8.7030902@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Henning Schulzrinne CC: ext Paul Kyzivat , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> <4087D1DE.5020601@cisco.com> <4087D5A3.5040609@nokia.com> <4087E224.6070207@cs.columbia.edu> In-Reply-To: <4087E224.6070207@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2004 07:24:56.0081 (UTC) FILETIME=[13BA7010:01C42904] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 10:24:56 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit ext Henning Schulzrinne wrote: > > Two quick remarks: > > - A UA can decide not to send media type information if ten bytes of > bandwidth break the bank or if you consider it difficult to generate in > your particular implementation. This is not about difficulty in an implementation, and is not about the 10 bytes that the contentype itself adds. Is about resource utilization when you consider the whole picture, which is: if an implementation uses the contenttype to give a hint during the composition of a message, whenever the contenttype changes, the implemenation has to send a new update with the new contentype. This is more than 10 bytes, specially if used in page mode. Having said that, fortunately we are discussino a corner case that will not happen typically. > > - I don't see why this changes often unless you can't make up your mind > whether you are composing a video, voice or text message and switch > between those editors. The case I have in my mind is when you start composing a text message, and then start recording an audio or video file that is embedded in the message. > - If you are sending a video or audio note, it is likely to be several > orders of magnitude larger than the indication. Sure, no doubt. > Having the indication is helpful since it provides the receiver some > warning. Think of an audio message - I can then turn the volume up or > down before it blasts from my screen. Ok, sounds reasonable. Miguel > > Henning > > Miguel Garcia wrote: > >> Well, so let me try to see if understand. We are adding a feature that >> just uses bandwidth, because it represents some information that is >> able to change so oftenly that may require to be updated oftenly. >> Furthermore, it is not clear what the receiver can do with such >> information. Will an application at the receiver's indicate "Miguel is >> composing audio" or "Miguel is composing video" ? I don't think that >> is useful. >> >> Mmmm... in these days of wireless devices and saving bandwidth, this >> element seems to go against those principles. >> >> /Miguel >> >> ext Paul Kyzivat wrote: >> >>> >>> >>> Miguel Garcia wrote: >>> [snip] >>> >>>> Then I question the usage of the "contenttype" element. I can >>>> envision systems where I can start typing a text message and then >>>> drag and drop any object (audio or video file). The application will >>>> first generate an istyping message with the "contenttype" element >>>> presumably set to text, which is not correct, >>> >>> >>> >>> >>> It would be correct at the time it is sent. There is never any >>> guarantee that the typing will result in a message being sent at all, >>> much less what type. >>> >>> > because I dragged some object later. >>> >>> When you drag in an object of some other type, your client will need >>> to reconsider what the content type is. Then it could send a new >>> isComposing message with the new content type. >>> >>> > I doubt about the usability of this feature. >>> >>> Well, I agree it isn't clear what the recipient would do with the >>> content type information. But other than consuming bandwidth it >>> doesn't hurt. >>> >>>> Furthermore, no application will be able to a priori determine >>>> whether the user us typing text/plain or text/html, as a user could >>>> just add an html tag afterwords. >>> >>> >>> >>> >>> Adding html tags doesn't make the content type html. The sending >>> application will have to decide to set the content type to text/html. >>> It *might* do that by inspecting the message for html tags, but I >>> would find that surprising. I would imagine that some application >>> control would need to be selected to cause this to happen. >>> >>> In any case, as with the drag/drop case above, if/when the >>> application decides on a different content type than it previously >>> communicated, it can send another isComposing with the new content >>> type. But if the decision isn't made until the message is sent then >>> presumably it wouldn't bother. It might not bother in any case. >>> >>> Paul >>> >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 04:01:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20760 for ; Fri, 23 Apr 2004 04:01:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGvbS-00037d-8d for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 04:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N806Pj011987 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 04:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGvWS-0001dS-6P for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 03:54:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20459 for ; Fri, 23 Apr 2004 03:54:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGvWN-0002WI-HC for simple-web-archive@ietf.org; Fri, 23 Apr 2004 03:54:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGvVO-0002E6-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 03:53:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGvUS-0001vo-00; Fri, 23 Apr 2004 03:52:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGvPp-0007xD-Gj; Fri, 23 Apr 2004 03:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGvMd-0006Uv-Rp for simple@optimus.ietf.org; Fri, 23 Apr 2004 03:44:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19917 for ; Fri, 23 Apr 2004 03:44:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGvMZ-0007Pu-9G for simple@ietf.org; Fri, 23 Apr 2004 03:44:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGvLg-0007AI-00 for simple@ietf.org; Fri, 23 Apr 2004 03:43:49 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BGvLN-0006uT-00 for simple@ietf.org; Fri, 23 Apr 2004 03:43:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3N7hAm17044; Fri, 23 Apr 2004 10:43:10 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 10:42:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3N7gt69006722; Fri, 23 Apr 2004 10:42:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00xzr4qn; Fri, 23 Apr 2004 10:42:53 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3N7Ous11160; Fri, 23 Apr 2004 10:24:56 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 10:24:56 +0300 Message-ID: <4088C4C8.7030902@nokia.com> From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ext Henning Schulzrinne CC: ext Paul Kyzivat , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> <4087D1DE.5020601@cisco.com> <4087D5A3.5040609@nokia.com> <4087E224.6070207@cs.columbia.edu> In-Reply-To: <4087E224.6070207@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2004 07:24:56.0081 (UTC) FILETIME=[13BA7010:01C42904] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 10:24:56 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Henning Schulzrinne wrote: > > Two quick remarks: > > - A UA can decide not to send media type information if ten bytes of > bandwidth break the bank or if you consider it difficult to generate in > your particular implementation. This is not about difficulty in an implementation, and is not about the 10 bytes that the contentype itself adds. Is about resource utilization when you consider the whole picture, which is: if an implementation uses the contenttype to give a hint during the composition of a message, whenever the contenttype changes, the implemenation has to send a new update with the new contentype. This is more than 10 bytes, specially if used in page mode. Having said that, fortunately we are discussino a corner case that will not happen typically. > > - I don't see why this changes often unless you can't make up your mind > whether you are composing a video, voice or text message and switch > between those editors. The case I have in my mind is when you start composing a text message, and then start recording an audio or video file that is embedded in the message. > - If you are sending a video or audio note, it is likely to be several > orders of magnitude larger than the indication. Sure, no doubt. > Having the indication is helpful since it provides the receiver some > warning. Think of an audio message - I can then turn the volume up or > down before it blasts from my screen. Ok, sounds reasonable. Miguel > > Henning > > Miguel Garcia wrote: > >> Well, so let me try to see if understand. We are adding a feature that >> just uses bandwidth, because it represents some information that is >> able to change so oftenly that may require to be updated oftenly. >> Furthermore, it is not clear what the receiver can do with such >> information. Will an application at the receiver's indicate "Miguel is >> composing audio" or "Miguel is composing video" ? I don't think that >> is useful. >> >> Mmmm... in these days of wireless devices and saving bandwidth, this >> element seems to go against those principles. >> >> /Miguel >> >> ext Paul Kyzivat wrote: >> >>> >>> >>> Miguel Garcia wrote: >>> [snip] >>> >>>> Then I question the usage of the "contenttype" element. I can >>>> envision systems where I can start typing a text message and then >>>> drag and drop any object (audio or video file). The application will >>>> first generate an istyping message with the "contenttype" element >>>> presumably set to text, which is not correct, >>> >>> >>> >>> >>> It would be correct at the time it is sent. There is never any >>> guarantee that the typing will result in a message being sent at all, >>> much less what type. >>> >>> > because I dragged some object later. >>> >>> When you drag in an object of some other type, your client will need >>> to reconsider what the content type is. Then it could send a new >>> isComposing message with the new content type. >>> >>> > I doubt about the usability of this feature. >>> >>> Well, I agree it isn't clear what the recipient would do with the >>> content type information. But other than consuming bandwidth it >>> doesn't hurt. >>> >>>> Furthermore, no application will be able to a priori determine >>>> whether the user us typing text/plain or text/html, as a user could >>>> just add an html tag afterwords. >>> >>> >>> >>> >>> Adding html tags doesn't make the content type html. The sending >>> application will have to decide to set the content type to text/html. >>> It *might* do that by inspecting the message for html tags, but I >>> would find that surprising. I would imagine that some application >>> control would need to be selected to cause this to happen. >>> >>> In any case, as with the drag/drop case above, if/when the >>> application decides on a different content type than it previously >>> communicated, it can send another isComposing with the new content >>> type. But if the decision isn't made until the message is sent then >>> presumably it wouldn't bother. It might not bother in any case. >>> >>> Paul >>> >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 09:33:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06706 for ; Fri, 23 Apr 2004 09:33:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0nr-0007Dr-Ta for simple-archive@ietf.org; Fri, 23 Apr 2004 09:33:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0mz-0006wG-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 09:32:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH0mG-0006fe-00; Fri, 23 Apr 2004 09:31:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0h0-0004Q4-46; Fri, 23 Apr 2004 09:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0ZE-0001FN-G8 for simple@optimus.ietf.org; Fri, 23 Apr 2004 09:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05573 for ; Fri, 23 Apr 2004 09:18:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0ZC-00034j-N6 for simple@ietf.org; Fri, 23 Apr 2004 09:18:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0YL-0002pQ-00 for simple@ietf.org; Fri, 23 Apr 2004 09:17:13 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BH0XU-0002Z9-00 for simple@ietf.org; Fri, 23 Apr 2004 09:16:20 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3NDG6C3009421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Apr 2004 09:16:07 -0400 (EDT) Message-ID: <40891710.6070008@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Miguel Garcia CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> <4087D1DE.5020601@cisco.com> <4087D5A3.5040609@nokia.com> <4087E224.6070207@cs.columbia.edu> <4088C4C8.7030902@nokia.com> In-Reply-To: <4088C4C8.7030902@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 09:16:00 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > This is not about difficulty in an implementation, and is not about the > 10 bytes that the contentype itself adds. Is about resource utilization > when you consider the whole picture, which is: if an implementation uses > the contenttype to give a hint during the composition of a message, > whenever the contenttype changes, the implemenation has to send a new > update with the new contentype. This is more than 10 bytes, specially if > used in page mode. > > Having said that, fortunately we are discussino a corner case that will > not happen typically. I'd agree - I just can't see as being close to common. After all, if you're composing an elaborate message, IM doesn't seem like the typical venue for it. I see audio and video messages primarily for devices that have limited text capabilities or situations where keyboarding is inappropriate (say, while driving), not as a way to create a home movie or multimedia documentary. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 09:37:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07014 for ; Fri, 23 Apr 2004 09:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0q9-0007Jl-T4 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 09:35:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NDZbOV028124 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 09:35:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0nu-0006q4-Du for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 09:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06724 for ; Fri, 23 Apr 2004 09:33:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0ns-0007Dx-Io for simple-web-archive@ietf.org; Fri, 23 Apr 2004 09:33:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0n0-0006wO-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 09:32:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH0mG-0006fe-00; Fri, 23 Apr 2004 09:31:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0h0-0004Q4-46; Fri, 23 Apr 2004 09:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0ZE-0001FN-G8 for simple@optimus.ietf.org; Fri, 23 Apr 2004 09:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05573 for ; Fri, 23 Apr 2004 09:18:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0ZC-00034j-N6 for simple@ietf.org; Fri, 23 Apr 2004 09:18:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0YL-0002pQ-00 for simple@ietf.org; Fri, 23 Apr 2004 09:17:13 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BH0XU-0002Z9-00 for simple@ietf.org; Fri, 23 Apr 2004 09:16:20 -0400 Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3NDG6C3009421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Apr 2004 09:16:07 -0400 (EDT) Message-ID: <40891710.6070008@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Miguel Garcia CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087B8DA.2010202@nokia.com> <4087D1DE.5020601@cisco.com> <4087D5A3.5040609@nokia.com> <4087E224.6070207@cs.columbia.edu> <4088C4C8.7030902@nokia.com> In-Reply-To: <4088C4C8.7030902@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 09:16:00 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This is not about difficulty in an implementation, and is not about the > 10 bytes that the contentype itself adds. Is about resource utilization > when you consider the whole picture, which is: if an implementation uses > the contenttype to give a hint during the composition of a message, > whenever the contenttype changes, the implemenation has to send a new > update with the new contentype. This is more than 10 bytes, specially if > used in page mode. > > Having said that, fortunately we are discussino a corner case that will > not happen typically. I'd agree - I just can't see as being close to common. After all, if you're composing an elaborate message, IM doesn't seem like the typical venue for it. I see audio and video messages primarily for devices that have limited text capabilities or situations where keyboarding is inappropriate (say, while driving), not as a way to create a home movie or multimedia documentary. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 10:27:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11630 for ; Fri, 23 Apr 2004 10:27:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1eq-0006zF-Mk for simple-archive@ietf.org; Fri, 23 Apr 2004 10:28:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1dt-0006k5-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 10:27:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH1cv-0006Ud-00; Fri, 23 Apr 2004 10:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1X8-0007v4-6W; Fri, 23 Apr 2004 10:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1Od-0003pP-3d for simple@optimus.ietf.org; Fri, 23 Apr 2004 10:11:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10250 for ; Fri, 23 Apr 2004 10:11:11 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1Oa-0002Qq-Qk for simple@ietf.org; Fri, 23 Apr 2004 10:11:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1Na-00028z-00 for simple@ietf.org; Fri, 23 Apr 2004 10:10:10 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BH1Mi-0001pX-00 for simple@ietf.org; Fri, 23 Apr 2004 10:09:16 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NE9AX29327; Fri, 23 Apr 2004 17:09:10 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 17:08:42 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3NE8gw3027469; Fri, 23 Apr 2004 17:08:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ffTQrq; Fri, 23 Apr 2004 17:06:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NE6ns01847; Fri, 23 Apr 2004 17:06:49 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 17:06:42 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Updating the XCAP PIDF manipulation draft Thread-Index: AcQpPDOc6vE+fbPPTEyD9Nkylh+vxA== To: Cc: , , X-OriginalArrivalTime: 23 Apr 2004 14:06:42.0231 (UTC) FILETIME=[341D0470:01C4293C] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Updating the XCAP PIDF manipulation draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 17:06:42 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Me and Eva are working on an update to the XCAP PIDF manipulation usage. = Based on the earlier version there was some confusion on the = relationship of the presence state set by SIP PUBLISH and XCAP PIDF = manipulation. I've come up with the text below. I would like to get some = feedback whether you think it is clear enough. At least George and = Jonathan have commented the previous version, so I would especially like = your comments. Chapter 1 contains the motivation, I think no changes are needed for = that. This is for Chapter 3 (the figure is unmodified): --- The framework for publishing presence state is introduced in . A central part of the framework is the = event state compositor element whose function is to compose presence = information received from serveral sources into a single coherent = presence document. The presence state manipulated with XCAP can be seen as one of the = information sources for the compositor to be combined with the soft = state information published using SIP PUBLISH. This is illustrated in = Figure 1. It is expected that in the normal case there can be several = PUAs publishing their separate views with SIP PUBLISH, but only single = XCAP manipulated presence document. As shown in the figure, there can be = multiple XCAP clients (for instance in different physical devices) = manipulating the same document on the XCAP server, but this still = creates only one input to the event state compositor. As individual inputs the presence states set by XCAP and SIP PUBLISH are = completely separated and it is not possible to directly manipulate the = state set by one mechanism with the other. How the compositor treats = XCAP based inputs with respect to SIP PUBLISH based inputs is a matter = of compositor policy, which is beyond the scope of this specification. = Since the SIP PUBLISH specification already mandates the compositor to = be able to deal with multiple inputs, this XCAP usage does not impose = any new requirements on the compositor functionality. =20 --- Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 10:41:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12306 for ; Fri, 23 Apr 2004 10:41:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1i0-0002mz-7S for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 10:31:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NEVGn8010716 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 10:31:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1et-00029C-Eu for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:28:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11644 for ; Fri, 23 Apr 2004 10:27:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1er-0006zK-AA for simple-web-archive@ietf.org; Fri, 23 Apr 2004 10:28:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1du-0006kC-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 10:27:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH1cv-0006Ud-00; Fri, 23 Apr 2004 10:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1X8-0007v4-6W; Fri, 23 Apr 2004 10:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1Od-0003pP-3d for simple@optimus.ietf.org; Fri, 23 Apr 2004 10:11:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10250 for ; Fri, 23 Apr 2004 10:11:11 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1Oa-0002Qq-Qk for simple@ietf.org; Fri, 23 Apr 2004 10:11:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1Na-00028z-00 for simple@ietf.org; Fri, 23 Apr 2004 10:10:10 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BH1Mi-0001pX-00 for simple@ietf.org; Fri, 23 Apr 2004 10:09:16 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NE9AX29327; Fri, 23 Apr 2004 17:09:10 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 17:08:42 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3NE8gw3027469; Fri, 23 Apr 2004 17:08:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ffTQrq; Fri, 23 Apr 2004 17:06:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NE6ns01847; Fri, 23 Apr 2004 17:06:49 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 17:06:42 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Updating the XCAP PIDF manipulation draft Thread-Index: AcQpPDOc6vE+fbPPTEyD9Nkylh+vxA== To: Cc: , , X-OriginalArrivalTime: 23 Apr 2004 14:06:42.0231 (UTC) FILETIME=[341D0470:01C4293C] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Updating the XCAP PIDF manipulation draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 17:06:42 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Me and Eva are working on an update to the XCAP PIDF manipulation usage. = Based on the earlier version there was some confusion on the = relationship of the presence state set by SIP PUBLISH and XCAP PIDF = manipulation. I've come up with the text below. I would like to get some = feedback whether you think it is clear enough. At least George and = Jonathan have commented the previous version, so I would especially like = your comments. Chapter 1 contains the motivation, I think no changes are needed for = that. This is for Chapter 3 (the figure is unmodified): --- The framework for publishing presence state is introduced in . A central part of the framework is the = event state compositor element whose function is to compose presence = information received from serveral sources into a single coherent = presence document. The presence state manipulated with XCAP can be seen as one of the = information sources for the compositor to be combined with the soft = state information published using SIP PUBLISH. This is illustrated in = Figure 1. It is expected that in the normal case there can be several = PUAs publishing their separate views with SIP PUBLISH, but only single = XCAP manipulated presence document. As shown in the figure, there can be = multiple XCAP clients (for instance in different physical devices) = manipulating the same document on the XCAP server, but this still = creates only one input to the event state compositor. As individual inputs the presence states set by XCAP and SIP PUBLISH are = completely separated and it is not possible to directly manipulate the = state set by one mechanism with the other. How the compositor treats = XCAP based inputs with respect to SIP PUBLISH based inputs is a matter = of compositor policy, which is beyond the scope of this specification. = Since the SIP PUBLISH specification already mandates the compositor to = be able to deal with multiple inputs, this XCAP usage does not impose = any new requirements on the compositor functionality. =20 --- Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 11:30:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14651 for ; Fri, 23 Apr 2004 11:30:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2cu-0007VZ-3n for simple-archive@ietf.org; Fri, 23 Apr 2004 11:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2bv-0007H0-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 11:29:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2bH-00072c-00; Fri, 23 Apr 2004 11:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2UA-00072v-OC; Fri, 23 Apr 2004 11:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Mb-0005Az-Lv for simple@optimus.ietf.org; Fri, 23 Apr 2004 11:13:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13786 for ; Fri, 23 Apr 2004 11:13:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2Ma-00035u-PI for simple@ietf.org; Fri, 23 Apr 2004 11:13:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2Lh-0002pC-00 for simple@ietf.org; Fri, 23 Apr 2004 11:12:17 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BH2Kz-0002WJ-00 for simple@ietf.org; Fri, 23 Apr 2004 11:11:33 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i3NFAufX014425; Fri, 23 Apr 2004 10:10:56 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Apr 2004 10:10:34 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9732@lmc37.lmc.ericsson.se> From: "George Foti (QA/EMC)" To: "'Markus.Isomaki@nokia.com'" , simple@ietf.org Cc: eva-maria.leppanen@nokia.com, jdrosen@dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 10:09:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Markus, Here are my comments: Second paragraph: Replace: "but only single XCAP manipulated presence document", by "but only single XCAP publishing source" Third paragraph: replace the following section "As individual inputs ................one mechanism with the other" by the following: "Although presence states set by XCAP, on behalf of XCAP clients, and SIP PUBLISH, on behalf of PUAs, are completely separated, conflicting information may occur within the composer for a presence state" Rgds/gf > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, April 23, 2004 10:07 AM > To: simple@ietf.org > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com; George Foti > (QA/EMC) > Subject: Updating the XCAP PIDF manipulation draft > > > Hi, > > Me and Eva are working on an update to the XCAP PIDF > manipulation usage. Based on the earlier version there was > some confusion on the relationship of the presence state set > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with > the text below. I would like to get some feedback whether you > think it is clear enough. At least George and Jonathan have > commented the previous version, so I would especially like > your comments. > > Chapter 1 contains the motivation, I think no changes are > needed for that. This is for Chapter 3 (the figure is unmodified): > > --- > > The framework for publishing presence state is introduced in > . A central part of the > framework is the event state compositor element whose > function is to compose presence information received from > serveral sources into a single coherent presence document. > > The presence state manipulated with XCAP can be seen as one > of the information sources for the compositor to be combined > with the soft state information published using SIP PUBLISH. > This is illustrated in Figure 1. It is expected that in the > normal case there can be several PUAs publishing their > separate views with SIP PUBLISH, but only single XCAP > manipulated presence document. As shown in the figure, there > can be multiple XCAP clients (for instance in different > physical devices) manipulating the same document on the XCAP > server, but this still creates only one input to the event > state compositor. > > As individual inputs the presence states set by XCAP and SIP > PUBLISH are completely separated and it is not possible to > directly manipulate the state set by one mechanism with the > other. How the compositor treats XCAP based inputs with > respect to SIP PUBLISH based inputs is a matter of compositor > policy, which is beyond the scope of this specification. > Since the SIP PUBLISH specification already mandates the > compositor to be able to deal with multiple inputs, this XCAP > usage does not impose any new requirements on the compositor > functionality. > > --- > > Regards, > Markus > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 11:49:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15723 for ; Fri, 23 Apr 2004 11:49:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2lf-0003nV-ET for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 11:39:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NFd7hT014592 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 11:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2cv-0001KG-Mr for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:30:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14661 for ; Fri, 23 Apr 2004 11:30:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2cu-0007Ve-NM for simple-web-archive@ietf.org; Fri, 23 Apr 2004 11:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2bv-0007H8-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 11:29:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2bH-00072c-00; Fri, 23 Apr 2004 11:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2UA-00072v-OC; Fri, 23 Apr 2004 11:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Mb-0005Az-Lv for simple@optimus.ietf.org; Fri, 23 Apr 2004 11:13:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13786 for ; Fri, 23 Apr 2004 11:13:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2Ma-00035u-PI for simple@ietf.org; Fri, 23 Apr 2004 11:13:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2Lh-0002pC-00 for simple@ietf.org; Fri, 23 Apr 2004 11:12:17 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1BH2Kz-0002WJ-00 for simple@ietf.org; Fri, 23 Apr 2004 11:11:33 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i3NFAufX014425; Fri, 23 Apr 2004 10:10:56 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Apr 2004 10:10:34 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9732@lmc37.lmc.ericsson.se> From: "George Foti (QA/EMC)" To: "'Markus.Isomaki@nokia.com'" , simple@ietf.org Cc: eva-maria.leppanen@nokia.com, jdrosen@dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 10:09:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Markus, Here are my comments: Second paragraph: Replace: "but only single XCAP manipulated presence document", by "but only single XCAP publishing source" Third paragraph: replace the following section "As individual inputs ................one mechanism with the other" by the following: "Although presence states set by XCAP, on behalf of XCAP clients, and SIP PUBLISH, on behalf of PUAs, are completely separated, conflicting information may occur within the composer for a presence state" Rgds/gf > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, April 23, 2004 10:07 AM > To: simple@ietf.org > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com; George Foti > (QA/EMC) > Subject: Updating the XCAP PIDF manipulation draft > > > Hi, > > Me and Eva are working on an update to the XCAP PIDF > manipulation usage. Based on the earlier version there was > some confusion on the relationship of the presence state set > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with > the text below. I would like to get some feedback whether you > think it is clear enough. At least George and Jonathan have > commented the previous version, so I would especially like > your comments. > > Chapter 1 contains the motivation, I think no changes are > needed for that. This is for Chapter 3 (the figure is unmodified): > > --- > > The framework for publishing presence state is introduced in > . A central part of the > framework is the event state compositor element whose > function is to compose presence information received from > serveral sources into a single coherent presence document. > > The presence state manipulated with XCAP can be seen as one > of the information sources for the compositor to be combined > with the soft state information published using SIP PUBLISH. > This is illustrated in Figure 1. It is expected that in the > normal case there can be several PUAs publishing their > separate views with SIP PUBLISH, but only single XCAP > manipulated presence document. As shown in the figure, there > can be multiple XCAP clients (for instance in different > physical devices) manipulating the same document on the XCAP > server, but this still creates only one input to the event > state compositor. > > As individual inputs the presence states set by XCAP and SIP > PUBLISH are completely separated and it is not possible to > directly manipulate the state set by one mechanism with the > other. How the compositor treats XCAP based inputs with > respect to SIP PUBLISH based inputs is a matter of compositor > policy, which is beyond the scope of this specification. > Since the SIP PUBLISH specification already mandates the > compositor to be able to deal with multiple inputs, this XCAP > usage does not impose any new requirements on the compositor > functionality. > > --- > > Regards, > Markus > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 11:54:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16090 for ; Fri, 23 Apr 2004 11:54:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH30C-000651-57 for simple-archive@ietf.org; Fri, 23 Apr 2004 11:54:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2zM-0005po-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 11:53:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2yc-0005aA-00; Fri, 23 Apr 2004 11:52:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2uG-0005Ya-Sd; Fri, 23 Apr 2004 11:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2im-0002sM-8Z for simple@optimus.ietf.org; Fri, 23 Apr 2004 11:36:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15083 for ; Fri, 23 Apr 2004 11:36:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2il-0001Ja-7e for simple@ietf.org; Fri, 23 Apr 2004 11:36:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2hg-000126-00 for simple@ietf.org; Fri, 23 Apr 2004 11:35:00 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BH2gc-0000YJ-00 for simple@ietf.org; Fri, 23 Apr 2004 11:33:55 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3NFWr6r007588 for ; Fri, 23 Apr 2004 10:32:53 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: simple@ietf.org In-Reply-To: <1082559342.2204.52.camel@localhost.localdomain> References: <1082559342.2204.52.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1082734377.2183.46.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 10:32:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The abstract for -partial-notification needs to focus more on what the document is defining. I suggest this as a replacement for the current text: Abstract By default, presence delivered using the Presence Event Package for the Session Initiation Protocol is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of tuples, each representing a different aspect of the presence being reported. When one tuple changes, a new document containing the full set of tuples is delivered. This memo defines an extension allowing delivery of a new document type that contains information about only those tuples that have actually changed. On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > This is a Working Group Last call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt > > This abbreviated WGLC will end on Wednesday, April 28. > > These drafts went through a previous last call at the beginning of > March. These versions reflect changes due to comments received during > that period. See > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html > for details. > > Please send comments to the list, copying the editor. If you reviewed > the draft and found no issues, please indicate so on the list. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 12:26:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17032 for ; Fri, 23 Apr 2004 12:26:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3D0-0002V4-FO for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 12:07:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NG7M9R009606 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 12:07:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH30E-00074h-L1 for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:54:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16108 for ; Fri, 23 Apr 2004 11:54:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH30D-00065G-Gn for simple-web-archive@ietf.org; Fri, 23 Apr 2004 11:54:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2zN-0005pv-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 11:53:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2yc-0005aA-00; Fri, 23 Apr 2004 11:52:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2uG-0005Ya-Sd; Fri, 23 Apr 2004 11:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2im-0002sM-8Z for simple@optimus.ietf.org; Fri, 23 Apr 2004 11:36:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15083 for ; Fri, 23 Apr 2004 11:36:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2il-0001Ja-7e for simple@ietf.org; Fri, 23 Apr 2004 11:36:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2hg-000126-00 for simple@ietf.org; Fri, 23 Apr 2004 11:35:00 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BH2gc-0000YJ-00 for simple@ietf.org; Fri, 23 Apr 2004 11:33:55 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3NFWr6r007588 for ; Fri, 23 Apr 2004 10:32:53 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: simple@ietf.org In-Reply-To: <1082559342.2204.52.camel@localhost.localdomain> References: <1082559342.2204.52.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1082734377.2183.46.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 10:32:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The abstract for -partial-notification needs to focus more on what the document is defining. I suggest this as a replacement for the current text: Abstract By default, presence delivered using the Presence Event Package for the Session Initiation Protocol is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of tuples, each representing a different aspect of the presence being reported. When one tuple changes, a new document containing the full set of tuples is delivered. This memo defines an extension allowing delivery of a new document type that contains information about only those tuples that have actually changed. On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > This is a Working Group Last call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt > > This abbreviated WGLC will end on Wednesday, April 28. > > These drafts went through a previous last call at the beginning of > March. These versions reflect changes due to comments received during > that period. See > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html > for details. > > Please send comments to the list, copying the editor. If you reviewed > the draft and found no issues, please indicate so on the list. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 12:54:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19308 for ; Fri, 23 Apr 2004 12:54:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3wE-0006Yp-Dy for simple-archive@ietf.org; Fri, 23 Apr 2004 12:54:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3vD-0006G0-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 12:53:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3uC-0005qk-00; Fri, 23 Apr 2004 12:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3c2-0003c1-5x; Fri, 23 Apr 2004 12:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Xf-0001Mv-U6 for simple@optimus.ietf.org; Fri, 23 Apr 2004 12:28:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17413 for ; Fri, 23 Apr 2004 12:28:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3Dl-0001o8-Om for simple@ietf.org; Fri, 23 Apr 2004 12:08:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3Bq-0001OM-00 for simple@ietf.org; Fri, 23 Apr 2004 12:06:10 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1BH3Ai-0000uR-00 for simple@ietf.org; Fri, 23 Apr 2004 12:05:00 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3NG4LDm021235; Fri, 23 Apr 2004 11:04:21 -0500 (CDT) Message-ID: <40893E84.4070207@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@ietf.org, eva-maria.leppanen@nokia.com, jdrosen@dynamicsoft.com, george.foti@ericsson.com Subject: Re: [Simple] Updating the XCAP PIDF manipulation draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 11:04:20 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Would it add more clarity to also state that XCAP state manipulation should be done before SIP PUBLISH, since the XCAP process sets the policy rules that determine which watcher gets what published information? Regards, Alex. Markus.Isomaki@nokia.com wrote: >Hi, > >Me and Eva are working on an update to the XCAP PIDF manipulation usage. Based on the earlier version there was some confusion on the relationship of the presence state set by SIP PUBLISH and XCAP PIDF manipulation. I've come up with the text below. I would like to get some feedback whether you think it is clear enough. At least George and Jonathan have commented the previous version, so I would especially like your comments. > >Chapter 1 contains the motivation, I think no changes are needed for that. This is for Chapter 3 (the figure is unmodified): > >--- > >The framework for publishing presence state is introduced in . A central part of the framework is the event state compositor element whose function is to compose presence information received from serveral sources into a single coherent presence document. > >The presence state manipulated with XCAP can be seen as one of the information sources for the compositor to be combined with the soft state information published using SIP PUBLISH. This is illustrated in Figure 1. It is expected that in the normal case there can be several PUAs publishing their separate views with SIP PUBLISH, but only single XCAP manipulated presence document. As shown in the figure, there can be multiple XCAP clients (for instance in different physical devices) manipulating the same document on the XCAP server, but this still creates only one input to the event state compositor. > >As individual inputs the presence states set by XCAP and SIP PUBLISH are completely separated and it is not possible to directly manipulate the state set by one mechanism with the other. How the compositor treats XCAP based inputs with respect to SIP PUBLISH based inputs is a matter of compositor policy, which is beyond the scope of this specification. Since the SIP PUBLISH specification already mandates the compositor to be able to deal with multiple inputs, this XCAP usage does not impose any new requirements on the compositor functionality. > >--- > >Regards, > Markus > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 13:03:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20203 for ; Fri, 23 Apr 2004 13:03:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH40U-00038s-S3 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 12:58:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGwUEv012073 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 12:58:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3wH-0001tA-4Z for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19328 for ; Fri, 23 Apr 2004 12:54:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3wF-0006Yu-6z for simple-web-archive@ietf.org; Fri, 23 Apr 2004 12:54:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3vE-0006G8-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 12:53:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3uC-0005qk-00; Fri, 23 Apr 2004 12:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3c2-0003c1-5x; Fri, 23 Apr 2004 12:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Xf-0001Mv-U6 for simple@optimus.ietf.org; Fri, 23 Apr 2004 12:28:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17413 for ; Fri, 23 Apr 2004 12:28:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3Dl-0001o8-Om for simple@ietf.org; Fri, 23 Apr 2004 12:08:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3Bq-0001OM-00 for simple@ietf.org; Fri, 23 Apr 2004 12:06:10 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1BH3Ai-0000uR-00 for simple@ietf.org; Fri, 23 Apr 2004 12:05:00 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i3NG4LDm021235; Fri, 23 Apr 2004 11:04:21 -0500 (CDT) Message-ID: <40893E84.4070207@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@ietf.org, eva-maria.leppanen@nokia.com, jdrosen@dynamicsoft.com, george.foti@ericsson.com Subject: Re: [Simple] Updating the XCAP PIDF manipulation draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 11:04:20 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Would it add more clarity to also state that XCAP state manipulation should be done before SIP PUBLISH, since the XCAP process sets the policy rules that determine which watcher gets what published information? Regards, Alex. Markus.Isomaki@nokia.com wrote: >Hi, > >Me and Eva are working on an update to the XCAP PIDF manipulation usage. Based on the earlier version there was some confusion on the relationship of the presence state set by SIP PUBLISH and XCAP PIDF manipulation. I've come up with the text below. I would like to get some feedback whether you think it is clear enough. At least George and Jonathan have commented the previous version, so I would especially like your comments. > >Chapter 1 contains the motivation, I think no changes are needed for that. This is for Chapter 3 (the figure is unmodified): > >--- > >The framework for publishing presence state is introduced in . A central part of the framework is the event state compositor element whose function is to compose presence information received from serveral sources into a single coherent presence document. > >The presence state manipulated with XCAP can be seen as one of the information sources for the compositor to be combined with the soft state information published using SIP PUBLISH. This is illustrated in Figure 1. It is expected that in the normal case there can be several PUAs publishing their separate views with SIP PUBLISH, but only single XCAP manipulated presence document. As shown in the figure, there can be multiple XCAP clients (for instance in different physical devices) manipulating the same document on the XCAP server, but this still creates only one input to the event state compositor. > >As individual inputs the presence states set by XCAP and SIP PUBLISH are completely separated and it is not possible to directly manipulate the state set by one mechanism with the other. How the compositor treats XCAP based inputs with respect to SIP PUBLISH based inputs is a matter of compositor policy, which is beyond the scope of this specification. Since the SIP PUBLISH specification already mandates the compositor to be able to deal with multiple inputs, this XCAP usage does not impose any new requirements on the compositor functionality. > >--- > >Regards, > Markus > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 13:14:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20800 for ; Fri, 23 Apr 2004 13:14:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4Fo-0004H5-Ju for simple-archive@ietf.org; Fri, 23 Apr 2004 13:14:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4F1-000411-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 13:13:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4ER-0003jo-00; Fri, 23 Apr 2004 13:12:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH44v-0004G0-0n; Fri, 23 Apr 2004 13:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3zJ-0002nS-9O for simple@optimus.ietf.org; Fri, 23 Apr 2004 12:57:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19757 for ; Fri, 23 Apr 2004 12:57:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3zH-0007V2-Fx for simple@ietf.org; Fri, 23 Apr 2004 12:57:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3yW-0007El-00 for simple@ietf.org; Fri, 23 Apr 2004 12:56:29 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH3xo-0006rY-00 for simple@ietf.org; Fri, 23 Apr 2004 12:55:44 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NGt7W9018655; Fri, 23 Apr 2004 09:55:08 -0700 (PDT) Received: from [128.107.170.253] ([128.107.170.253]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOJ12628; Fri, 23 Apr 2004 09:55:06 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] WGLC on isComposing draft From: Cullen Jennings To: Paul H Kyzivat , Dave Oran CC: Message-ID: In-Reply-To: <4087D5B4.60302@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 09:55:06 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On 4/22/04 7:24 AM, "Paul Kyzivat" wrote: > > Note that this is less of a problem with MSRP because it imposes an > ordering on messages within the session. One might argue that > isComposing is only appropriate with session oriented messaging and > shouldn't be used with page mode. Once we allow both small and large message to go over MSRP, We loose this ordering of messages property. This should be in the next draft. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 13:15:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20870 for ; Fri, 23 Apr 2004 13:15:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4Gm-0004YS-Tx for simple-archive@ietf.org; Fri, 23 Apr 2004 13:15:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4Fu-0004I2-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 13:14:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4FK-00041N-00; Fri, 23 Apr 2004 13:13:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Cc-0006R1-53; Fri, 23 Apr 2004 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH41N-0003Pj-Pw for simple@optimus.ietf.org; Fri, 23 Apr 2004 12:59:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19852 for ; Fri, 23 Apr 2004 12:59:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH41L-0000Dz-W7 for simple@ietf.org; Fri, 23 Apr 2004 12:59:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH40F-0007lF-00 for simple@ietf.org; Fri, 23 Apr 2004 12:58:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH3zh-0007UR-00 for simple@ietf.org; Fri, 23 Apr 2004 12:57:41 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 09:08:07 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NGv9W9021876; Fri, 23 Apr 2004 09:57:09 -0700 (PDT) Received: from [128.107.170.253] ([128.107.170.253]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOJ12865; Fri, 23 Apr 2004 09:57:08 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] WGLC on isComposing draft From: Cullen Jennings To: Ben Campbell CC: Message-ID: In-Reply-To: <40882DE6.5070405@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 09:57:08 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Yes it would after some period of time but it's still sort of ugly. On 4/22/04 1:41 PM, "Ben Campbell" wrote: > Would the expiration of the "active" state cause this problem to self-heal? > > Cullen Jennings wrote: >> I had a quick read of this and I like it. >> >> One questions on correlating with the message. Say I opened a windows, a is >> composing message was sent, call this M1, then I very quickly typed a >> message and this got sent, call this M2. Not idle message is sent. >> >> Now the network might deliver M2 ahead of M1. The client receiving these >> would display the text from M2 then show that the other side was composing >> when really it was not. >> >> This might be a weird corner case not worth solving. It could be solved with >> high resolution sender time in both M1 and M2. It could be solved with the >> is Composing passing on the message ID of the message that was being >> composed. >> >> I don't care if we choose to ignore this problem but thought it was worth >> mentioning. >> >> >> >> On 4/21/04 5:54 AM, "hisham.khartabil@nokia.com" >> wrote: >> >> >>> The WG chairs would like to start a Working Group Last Call on the following >>> drafts: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >>> >>> This WGLC will end on May 5th. >>> >>> Please send your comments to this mailing list and to the authors. >>> >>> If you reviewed the draft and found no issues, please indicate so also on >>> the >>> mailing list. This will help us evaluate the level of review and group >>> consensus. >>> >>> Thanks, >>> Hisham >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 13:27:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21940 for ; Fri, 23 Apr 2004 13:27:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Lx-0000aA-6L for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 13:20:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NHKfsC002233 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 13:20:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Fs-0007bt-16 for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 13:14:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20818 for ; Fri, 23 Apr 2004 13:14:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4Fq-0004HK-5L for simple-web-archive@ietf.org; Fri, 23 Apr 2004 13:14:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4F1-00041A-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 13:13:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4ER-0003jo-00; Fri, 23 Apr 2004 13:12:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH44v-0004G0-0n; Fri, 23 Apr 2004 13:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3zJ-0002nS-9O for simple@optimus.ietf.org; Fri, 23 Apr 2004 12:57:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19757 for ; Fri, 23 Apr 2004 12:57:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3zH-0007V2-Fx for simple@ietf.org; Fri, 23 Apr 2004 12:57:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3yW-0007El-00 for simple@ietf.org; Fri, 23 Apr 2004 12:56:29 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH3xo-0006rY-00 for simple@ietf.org; Fri, 23 Apr 2004 12:55:44 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NGt7W9018655; Fri, 23 Apr 2004 09:55:08 -0700 (PDT) Received: from [128.107.170.253] ([128.107.170.253]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOJ12628; Fri, 23 Apr 2004 09:55:06 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] WGLC on isComposing draft From: Cullen Jennings To: Paul H Kyzivat , Dave Oran CC: Message-ID: In-Reply-To: <4087D5B4.60302@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 09:55:06 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 4/22/04 7:24 AM, "Paul Kyzivat" wrote: > > Note that this is less of a problem with MSRP because it imposes an > ordering on messages within the session. One might argue that > isComposing is only appropriate with session oriented messaging and > shouldn't be used with page mode. Once we allow both small and large message to go over MSRP, We loose this ordering of messages property. This should be in the next draft. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 13:27:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21963 for ; Fri, 23 Apr 2004 13:27:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Ly-0000ao-6a for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 13:20:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NHKgFx002271 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 13:20:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Gp-0007sD-J5 for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 13:15:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20884 for ; Fri, 23 Apr 2004 13:15:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4Gn-0004YX-Hs for simple-web-archive@ietf.org; Fri, 23 Apr 2004 13:15:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4Fu-0004IA-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 13:14:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4FK-00041N-00; Fri, 23 Apr 2004 13:13:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Cc-0006R1-53; Fri, 23 Apr 2004 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH41N-0003Pj-Pw for simple@optimus.ietf.org; Fri, 23 Apr 2004 12:59:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19852 for ; Fri, 23 Apr 2004 12:59:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH41L-0000Dz-W7 for simple@ietf.org; Fri, 23 Apr 2004 12:59:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH40F-0007lF-00 for simple@ietf.org; Fri, 23 Apr 2004 12:58:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH3zh-0007UR-00 for simple@ietf.org; Fri, 23 Apr 2004 12:57:41 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 09:08:07 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NGv9W9021876; Fri, 23 Apr 2004 09:57:09 -0700 (PDT) Received: from [128.107.170.253] ([128.107.170.253]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOJ12865; Fri, 23 Apr 2004 09:57:08 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] WGLC on isComposing draft From: Cullen Jennings To: Ben Campbell CC: Message-ID: In-Reply-To: <40882DE6.5070405@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 09:57:08 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes it would after some period of time but it's still sort of ugly. On 4/22/04 1:41 PM, "Ben Campbell" wrote: > Would the expiration of the "active" state cause this problem to self-heal? > > Cullen Jennings wrote: >> I had a quick read of this and I like it. >> >> One questions on correlating with the message. Say I opened a windows, a is >> composing message was sent, call this M1, then I very quickly typed a >> message and this got sent, call this M2. Not idle message is sent. >> >> Now the network might deliver M2 ahead of M1. The client receiving these >> would display the text from M2 then show that the other side was composing >> when really it was not. >> >> This might be a weird corner case not worth solving. It could be solved with >> high resolution sender time in both M1 and M2. It could be solved with the >> is Composing passing on the message ID of the message that was being >> composed. >> >> I don't care if we choose to ignore this problem but thought it was worth >> mentioning. >> >> >> >> On 4/21/04 5:54 AM, "hisham.khartabil@nokia.com" >> wrote: >> >> >>> The WG chairs would like to start a Working Group Last Call on the following >>> drafts: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt >>> >>> This WGLC will end on May 5th. >>> >>> Please send your comments to this mailing list and to the authors. >>> >>> If you reviewed the draft and found no issues, please indicate so also on >>> the >>> mailing list. This will help us evaluate the level of review and group >>> consensus. >>> >>> Thanks, >>> Hisham >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 13:40:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22633 for ; Fri, 23 Apr 2004 13:40:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4em-0003L8-Fj for simple-archive@ietf.org; Fri, 23 Apr 2004 13:40:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4dp-00034f-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 13:39:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4cs-0002nw-00; Fri, 23 Apr 2004 13:38:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Xs-0003nl-VU; Fri, 23 Apr 2004 13:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4RG-0002CZ-DP for simple@optimus.ietf.org; Fri, 23 Apr 2004 13:26:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21772 for ; Fri, 23 Apr 2004 13:26:07 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4RE-0007UR-Bp for simple@ietf.org; Fri, 23 Apr 2004 13:26:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4QD-0007EG-00 for simple@ietf.org; Fri, 23 Apr 2004 13:25:06 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BH4PM-0006y1-00 for simple@ietf.org; Fri, 23 Apr 2004 13:24:13 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NHOAY07110; Fri, 23 Apr 2004 20:24:10 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 20:23:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3NHNwdl027080; Fri, 23 Apr 2004 20:23:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00d1GkmB; Fri, 23 Apr 2004 20:23:57 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NHNqs15438; Fri, 23 Apr 2004 20:23:52 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 20:23:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17301@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQpS0K8Hp7VGESBT2C3Jq378IdA7AAC5/LA To: , X-OriginalArrivalTime: 23 Apr 2004 17:23:53.0444 (UTC) FILETIME=[C010DA40:01C42957] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 20:23:55 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Your proposal sounds good. Probably the sentence "When one tuple changes, a new document containing the full set of tuples is delivered." should read something like -> "When any number of tuples change, a new document containing the full set of tuples is delivered" - Mikko > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of ext Robert Sparks > Sent: Friday, April 23, 2004 6:33 PM > To: simple@ietf.org > Subject: Re: [Simple] WGLC: partial notification >=20 >=20 > The abstract for -partial-notification needs to focus=20 > more on what the document is defining. I suggest this > as a replacement for the current text: > =20 > Abstract >=20 > By default, presence delivered using the Presence Event > Package for the Session Initiation Protocol is represented > in the Presence Information Data Format (PIDF). A PIDF > document contains a set of tuples, each representing > a different aspect of the presence being reported. When > one tuple changes, a new document containing the full set > of tuples is delivered. This memo defines an extension > allowing delivery of a new document type that contains > information about only those tuples that have actually > changed. >=20 > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > This is a Working Group Last call on the following drafts: > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-> ietf-simple-partial-notify-0 > > 2.txt > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- pidf-format-01.txt >=20 > This abbreviated WGLC will end on Wednesday, April 28. >=20 > These drafts went through a previous last call at the beginning of=20 > March. These versions reflect changes due to comments received during=20 > that period. See=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > 519.html > for details. >=20 > Please send comments to the list, copying the editor. If you reviewed=20 > the draft and found no issues, please indicate so on the list. >=20 > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 13:58:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23594 for ; Fri, 23 Apr 2004 13:58:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4wT-0000O5-Al for simple-archive@ietf.org; Fri, 23 Apr 2004 13:58:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4vV-00007g-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 13:57:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4uy-0007eu-00; Fri, 23 Apr 2004 13:56:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4oN-0000nz-Kj; Fri, 23 Apr 2004 13:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4ZK-0004Cg-8w for simple@optimus.ietf.org; Fri, 23 Apr 2004 13:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22375 for ; Fri, 23 Apr 2004 13:34:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4ZI-0001n3-4q for simple@ietf.org; Fri, 23 Apr 2004 13:34:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4YR-0001Wr-00 for simple@ietf.org; Fri, 23 Apr 2004 13:33:36 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BH4Xo-0001F8-00 for simple@ietf.org; Fri, 23 Apr 2004 13:32:56 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3NHWOh17859; Fri, 23 Apr 2004 12:32:24 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Mikko Lonnfors Cc: simple@ietf.org In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17301@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17301@esebe004.ntc.nokia.com> Content-Type: text/plain Message-Id: <1082741516.2183.60.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 12:31:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit That's more correct, but to emphasize the extent of the optimization being defined, maybe: "When any subset of the tuples change, even a just a single tuple, a new document containing the full set of tuples is delivered." RjS On Fri, 2004-04-23 at 12:23, mikko.lonnfors@nokia.com wrote: > Hi, > > Your proposal sounds good. Probably the sentence "When one tuple > changes, a new document containing the full set of tuples is delivered." > should read something like -> "When any number of tuples change, a new > document containing the full set of tuples is delivered" > > - Mikko > > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On > > Behalf Of ext Robert Sparks > > Sent: Friday, April 23, 2004 6:33 PM > > To: simple@ietf.org > > Subject: Re: [Simple] WGLC: partial notification > > > > > > The abstract for -partial-notification needs to focus > > more on what the document is defining. I suggest this > > as a replacement for the current text: > > > > Abstract > > > > By default, presence delivered using the Presence Event > > Package for the Session Initiation Protocol is represented > > in the Presence Information Data Format (PIDF). A PIDF > > document contains a set of tuples, each representing > > a different aspect of the presence being reported. When > > one tuple changes, a new document containing the full set > > of tuples is delivered. This memo defines an extension > > allowing delivery of a new document type that contains > > information about only those tuples that have actually > > changed. > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > This is a Working Group Last call on the following drafts: > > > > > > > > http://www.ietf.org/internet-drafts/draft-> > ietf-simple-partial-notify-0 > > > 2.txt > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > pidf-format-01.txt > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > > These drafts went through a previous last call at the beginning of > > March. These versions reflect changes due to comments received during > > that period. See > > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > > > > Please send comments to the list, copying the editor. If you reviewed > > the draft and found no issues, please indicate so on the list. > > > > RjS > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 13:58:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23615 for ; Fri, 23 Apr 2004 13:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4oa-0000s4-OX for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 13:50:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NHoGr5003344 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 13:50:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4ep-0005pV-By for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 13:40:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22651 for ; Fri, 23 Apr 2004 13:40:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4en-0003LC-5e for simple-web-archive@ietf.org; Fri, 23 Apr 2004 13:40:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4dq-00034m-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 13:39:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4cs-0002nw-00; Fri, 23 Apr 2004 13:38:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Xs-0003nl-VU; Fri, 23 Apr 2004 13:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4RG-0002CZ-DP for simple@optimus.ietf.org; Fri, 23 Apr 2004 13:26:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21772 for ; Fri, 23 Apr 2004 13:26:07 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4RE-0007UR-Bp for simple@ietf.org; Fri, 23 Apr 2004 13:26:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4QD-0007EG-00 for simple@ietf.org; Fri, 23 Apr 2004 13:25:06 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BH4PM-0006y1-00 for simple@ietf.org; Fri, 23 Apr 2004 13:24:13 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NHOAY07110; Fri, 23 Apr 2004 20:24:10 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 20:23:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3NHNwdl027080; Fri, 23 Apr 2004 20:23:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00d1GkmB; Fri, 23 Apr 2004 20:23:57 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NHNqs15438; Fri, 23 Apr 2004 20:23:52 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 20:23:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17301@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQpS0K8Hp7VGESBT2C3Jq378IdA7AAC5/LA To: , X-OriginalArrivalTime: 23 Apr 2004 17:23:53.0444 (UTC) FILETIME=[C010DA40:01C42957] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 20:23:55 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Your proposal sounds good. Probably the sentence "When one tuple changes, a new document containing the full set of tuples is delivered." should read something like -> "When any number of tuples change, a new document containing the full set of tuples is delivered" - Mikko > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On=20 > Behalf Of ext Robert Sparks > Sent: Friday, April 23, 2004 6:33 PM > To: simple@ietf.org > Subject: Re: [Simple] WGLC: partial notification >=20 >=20 > The abstract for -partial-notification needs to focus=20 > more on what the document is defining. I suggest this > as a replacement for the current text: > =20 > Abstract >=20 > By default, presence delivered using the Presence Event > Package for the Session Initiation Protocol is represented > in the Presence Information Data Format (PIDF). A PIDF > document contains a set of tuples, each representing > a different aspect of the presence being reported. When > one tuple changes, a new document containing the full set > of tuples is delivered. This memo defines an extension > allowing delivery of a new document type that contains > information about only those tuples that have actually > changed. >=20 > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > This is a Working Group Last call on the following drafts: > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-> ietf-simple-partial-notify-0 > > 2.txt > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- pidf-format-01.txt >=20 > This abbreviated WGLC will end on Wednesday, April 28. >=20 > These drafts went through a previous last call at the beginning of=20 > March. These versions reflect changes due to comments received during=20 > that period. See=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > 519.html > for details. >=20 > Please send comments to the list, copying the editor. If you reviewed=20 > the draft and found no issues, please indicate so on the list. >=20 > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 14:12:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24305 for ; Fri, 23 Apr 2004 14:12:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4zj-0004GB-SL for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 14:01:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NI1lqN016360 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 14:01:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4wW-0003Hp-9m for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 13:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23606 for ; Fri, 23 Apr 2004 13:58:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4wT-0000OA-TF for simple-web-archive@ietf.org; Fri, 23 Apr 2004 13:58:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4vV-00007n-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 13:57:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4uy-0007eu-00; Fri, 23 Apr 2004 13:56:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4oN-0000nz-Kj; Fri, 23 Apr 2004 13:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4ZK-0004Cg-8w for simple@optimus.ietf.org; Fri, 23 Apr 2004 13:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22375 for ; Fri, 23 Apr 2004 13:34:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4ZI-0001n3-4q for simple@ietf.org; Fri, 23 Apr 2004 13:34:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4YR-0001Wr-00 for simple@ietf.org; Fri, 23 Apr 2004 13:33:36 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BH4Xo-0001F8-00 for simple@ietf.org; Fri, 23 Apr 2004 13:32:56 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3NHWOh17859; Fri, 23 Apr 2004 12:32:24 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Mikko Lonnfors Cc: simple@ietf.org In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17301@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17301@esebe004.ntc.nokia.com> Content-Type: text/plain Message-Id: <1082741516.2183.60.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 12:31:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit That's more correct, but to emphasize the extent of the optimization being defined, maybe: "When any subset of the tuples change, even a just a single tuple, a new document containing the full set of tuples is delivered." RjS On Fri, 2004-04-23 at 12:23, mikko.lonnfors@nokia.com wrote: > Hi, > > Your proposal sounds good. Probably the sentence "When one tuple > changes, a new document containing the full set of tuples is delivered." > should read something like -> "When any number of tuples change, a new > document containing the full set of tuples is delivered" > > - Mikko > > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On > > Behalf Of ext Robert Sparks > > Sent: Friday, April 23, 2004 6:33 PM > > To: simple@ietf.org > > Subject: Re: [Simple] WGLC: partial notification > > > > > > The abstract for -partial-notification needs to focus > > more on what the document is defining. I suggest this > > as a replacement for the current text: > > > > Abstract > > > > By default, presence delivered using the Presence Event > > Package for the Session Initiation Protocol is represented > > in the Presence Information Data Format (PIDF). A PIDF > > document contains a set of tuples, each representing > > a different aspect of the presence being reported. When > > one tuple changes, a new document containing the full set > > of tuples is delivered. This memo defines an extension > > allowing delivery of a new document type that contains > > information about only those tuples that have actually > > changed. > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > This is a Working Group Last call on the following drafts: > > > > > > > > http://www.ietf.org/internet-drafts/draft-> > ietf-simple-partial-notify-0 > > > 2.txt > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > pidf-format-01.txt > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > > These drafts went through a previous last call at the beginning of > > March. These versions reflect changes due to comments received during > > that period. See > > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > > > > Please send comments to the list, copying the editor. If you reviewed > > the draft and found no issues, please indicate so on the list. > > > > RjS > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 15:41:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04271 for ; Fri, 23 Apr 2004 15:41:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6Xv-0006MR-V2 for simple-archive@ietf.org; Fri, 23 Apr 2004 15:41:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6V6-0005QZ-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 15:38:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH6RI-0004Yj-00; Fri, 23 Apr 2004 15:34:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6GN-0004AZ-PK; Fri, 23 Apr 2004 15:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH69B-00077F-OJ for simple@optimus.ietf.org; Fri, 23 Apr 2004 15:15:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01616 for ; Fri, 23 Apr 2004 15:15:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH69A-0006Qr-HN for simple@ietf.org; Fri, 23 Apr 2004 15:15:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH683-00064H-00 for simple@ietf.org; Fri, 23 Apr 2004 15:14:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BH666-0005Lb-00 for simple@ietf.org; Fri, 23 Apr 2004 15:12:26 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3NJBnSu016991; Fri, 23 Apr 2004 12:11:49 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHV34194; Fri, 23 Apr 2004 15:11:48 -0400 (EDT) Message-ID: <40896A73.2030409@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Dave Oran , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 15:11:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 4/22/04 7:24 AM, "Paul Kyzivat" wrote: > >>Note that this is less of a problem with MSRP because it imposes an >>ordering on messages within the session. One might argue that >>isComposing is only appropriate with session oriented messaging and >>shouldn't be used with page mode. > > Once we allow both small and large message to go over MSRP, We loose this > ordering of messages property. This should be in the next draft. Hmm. Good point. Its not really large and small that is the issue - its fragmentation, right? There might still be well defined ordering even when there is fragmentation, if we make clear whether the ordering is based on receipt of the first fragment or the last. (I think the last makes most sense.) So if the ordering of fragments was preserved end to end then it wouldn't be a problem. BUT, given that we intend to permit fragmentation and reassembly by servers along the path, I think it would be difficult, and possibly undesirable, to preserve ordering. This is an issue that goes far beyond isComposing. If A sends a number of messages to B, I think we must at least arrange so that both A and B agree on the order that those messages are to be displayed. (That is a much weaker condition than having them both agree on the order in which the messages from A to B *and* the messages from B to A are interleaved.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 15:48:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05081 for ; Fri, 23 Apr 2004 15:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6aN-0003k2-5x for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 15:43:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJhhqc014377 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 15:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6Xy-0002hd-1V for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:41:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04280 for ; Fri, 23 Apr 2004 15:41:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6Xw-0006N7-K5 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 15:41:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6V7-0005Qt-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 15:38:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH6RI-0004Yj-00; Fri, 23 Apr 2004 15:34:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6GN-0004AZ-PK; Fri, 23 Apr 2004 15:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH69B-00077F-OJ for simple@optimus.ietf.org; Fri, 23 Apr 2004 15:15:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01616 for ; Fri, 23 Apr 2004 15:15:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH69A-0006Qr-HN for simple@ietf.org; Fri, 23 Apr 2004 15:15:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH683-00064H-00 for simple@ietf.org; Fri, 23 Apr 2004 15:14:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BH666-0005Lb-00 for simple@ietf.org; Fri, 23 Apr 2004 15:12:26 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3NJBnSu016991; Fri, 23 Apr 2004 12:11:49 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHV34194; Fri, 23 Apr 2004 15:11:48 -0400 (EDT) Message-ID: <40896A73.2030409@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Dave Oran , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 15:11:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 4/22/04 7:24 AM, "Paul Kyzivat" wrote: > >>Note that this is less of a problem with MSRP because it imposes an >>ordering on messages within the session. One might argue that >>isComposing is only appropriate with session oriented messaging and >>shouldn't be used with page mode. > > Once we allow both small and large message to go over MSRP, We loose this > ordering of messages property. This should be in the next draft. Hmm. Good point. Its not really large and small that is the issue - its fragmentation, right? There might still be well defined ordering even when there is fragmentation, if we make clear whether the ordering is based on receipt of the first fragment or the last. (I think the last makes most sense.) So if the ordering of fragments was preserved end to end then it wouldn't be a problem. BUT, given that we intend to permit fragmentation and reassembly by servers along the path, I think it would be difficult, and possibly undesirable, to preserve ordering. This is an issue that goes far beyond isComposing. If A sends a number of messages to B, I think we must at least arrange so that both A and B agree on the order that those messages are to be displayed. (That is a much weaker condition than having them both agree on the order in which the messages from A to B *and* the messages from B to A are interleaved.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 17:08:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11941 for ; Fri, 23 Apr 2004 17:08:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7uN-0001jc-0f for simple-archive@ietf.org; Fri, 23 Apr 2004 17:08:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7tH-0001Gh-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 17:07:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7rs-0000j5-00; Fri, 23 Apr 2004 17:05:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7T2-0004Ip-Pc; Fri, 23 Apr 2004 16:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6n6-0007Vr-Ne for simple@optimus.ietf.org; Fri, 23 Apr 2004 15:56:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05560 for ; Fri, 23 Apr 2004 15:56:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6n5-00030N-34 for simple@ietf.org; Fri, 23 Apr 2004 15:56:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6lm-0002Sz-00 for simple@ietf.org; Fri, 23 Apr 2004 15:55:31 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BH6k2-0001wq-00 for simple@ietf.org; Fri, 23 Apr 2004 15:53:42 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3NJqe6r007872; Fri, 23 Apr 2004 14:52:40 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: simple@ietf.org Cc: Mikko Lonnfors In-Reply-To: <1082559342.2204.52.camel@localhost.localdomain> References: <1082559342.2204.52.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1082749964.2183.91.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 14:52:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I was going to wait until I could "send text" for this, but the weekend is looming and I want people to start thinking about this earlier rather than later: The current security considerations section in partial-notify will draw "Did you really think about this?" scrutiny. The bare "there are no new problems here" assertions dominate the "We thought about this, but its not a problem because" discussions. A global statement justifying the bare assertions would help. I think that's what the first sentence was trying to do, but its not correct (this _does_ introduce protocol functionality or we wouldn't need a PS document). More text exploring attacks against the partial notification mechanism itself is warranted (yes, we've thought through this, and we've convinced ourselves there are no new problems. We need to leave tracks making it easier for the rest of the IETF to convince themselves there are no problems. Some things we could discuss: A third party can inject a partial notify that will cause the watcher to think it missed a partial document and request a new full state document. This is no worse than what we have without this extension since a party that could pull that off could also simply send a Subscription-State: terminated NOTIFY and achieve the same effect without knowing about the extension. We've made the situation no worse, and the protection mechanisms form the existing system apply to preventing this attack against the partial notification mechanism. Its probably worth explicitly discussing what happens when you replay a partial-notify document in a new SIP NOTIFY (as opposed to replaying the whole NOTIFY). (What happens will depend on the answer to one of the questions I asked in a different thread.) Its also worth explicitly calling out how to protect against this kind of replay. Hopefully the rest of the group can help capture the other things we've talked about (send text). RjS On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > This is a Working Group Last call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt > > This abbreviated WGLC will end on Wednesday, April 28. > > These drafts went through a previous last call at the beginning of > March. These versions reflect changes due to comments received during > that period. See > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html > for details. > > Please send comments to the list, copying the editor. If you reviewed > the draft and found no issues, please indicate so on the list. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 17:39:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14863 for ; Fri, 23 Apr 2004 17:39:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8Dg-0000JR-IR for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 17:28:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLSO1C001193 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 17:28:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7uP-0001cx-Np for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11959 for ; Fri, 23 Apr 2004 17:08:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7uN-0001jh-K4 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 17:08:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7tI-0001Gu-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 17:07:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7rs-0000j5-00; Fri, 23 Apr 2004 17:05:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7T2-0004Ip-Pc; Fri, 23 Apr 2004 16:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6n6-0007Vr-Ne for simple@optimus.ietf.org; Fri, 23 Apr 2004 15:56:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05560 for ; Fri, 23 Apr 2004 15:56:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6n5-00030N-34 for simple@ietf.org; Fri, 23 Apr 2004 15:56:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6lm-0002Sz-00 for simple@ietf.org; Fri, 23 Apr 2004 15:55:31 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BH6k2-0001wq-00 for simple@ietf.org; Fri, 23 Apr 2004 15:53:42 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3NJqe6r007872; Fri, 23 Apr 2004 14:52:40 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: simple@ietf.org Cc: Mikko Lonnfors In-Reply-To: <1082559342.2204.52.camel@localhost.localdomain> References: <1082559342.2204.52.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1082749964.2183.91.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 14:52:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was going to wait until I could "send text" for this, but the weekend is looming and I want people to start thinking about this earlier rather than later: The current security considerations section in partial-notify will draw "Did you really think about this?" scrutiny. The bare "there are no new problems here" assertions dominate the "We thought about this, but its not a problem because" discussions. A global statement justifying the bare assertions would help. I think that's what the first sentence was trying to do, but its not correct (this _does_ introduce protocol functionality or we wouldn't need a PS document). More text exploring attacks against the partial notification mechanism itself is warranted (yes, we've thought through this, and we've convinced ourselves there are no new problems. We need to leave tracks making it easier for the rest of the IETF to convince themselves there are no problems. Some things we could discuss: A third party can inject a partial notify that will cause the watcher to think it missed a partial document and request a new full state document. This is no worse than what we have without this extension since a party that could pull that off could also simply send a Subscription-State: terminated NOTIFY and achieve the same effect without knowing about the extension. We've made the situation no worse, and the protection mechanisms form the existing system apply to preventing this attack against the partial notification mechanism. Its probably worth explicitly discussing what happens when you replay a partial-notify document in a new SIP NOTIFY (as opposed to replaying the whole NOTIFY). (What happens will depend on the answer to one of the questions I asked in a different thread.) Its also worth explicitly calling out how to protect against this kind of replay. Hopefully the rest of the group can help capture the other things we've talked about (send text). RjS On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > This is a Working Group Last call on the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt > > This abbreviated WGLC will end on Wednesday, April 28. > > These drafts went through a previous last call at the beginning of > March. These versions reflect changes due to comments received during > that period. See > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html > for details. > > Please send comments to the list, copying the editor. If you reviewed > the draft and found no issues, please indicate so on the list. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 18:11:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17294 for ; Fri, 23 Apr 2004 18:11:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8tB-0002vE-E0 for simple-archive@ietf.org; Fri, 23 Apr 2004 18:11:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8sD-0002eC-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 18:10:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH8rA-0002Gc-00; Fri, 23 Apr 2004 18:09:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8dU-0002u0-Dm; Fri, 23 Apr 2004 17:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8WH-0008G2-1b for simple@optimus.ietf.org; Fri, 23 Apr 2004 17:47:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15448 for ; Fri, 23 Apr 2004 17:47:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8WE-0004N7-GE for simple@ietf.org; Fri, 23 Apr 2004 17:47:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8VM-00044j-00 for simple@ietf.org; Fri, 23 Apr 2004 17:46:40 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH8UP-0003Tv-00 for simple@ietf.org; Fri, 23 Apr 2004 17:45:41 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NLj2W9028662; Fri, 23 Apr 2004 14:45:03 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHV47183; Fri, 23 Apr 2004 17:45:01 -0400 (EDT) Message-ID: <40898E5D.1020802@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Cullen Jennings , Dave Oran , simple@ietf.org References: <40896A73.2030409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Deterministic message ordering in MSRP? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 17:45:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Replying to myself. :-( I thought about this a bit more, and now I think it is ok to require that a fragmentation algorithm preserve the ordering of the last fragment of messages. This in turn means that ordering of messages can be defined by the order in which their last fragment is sent/received. This means that the sender of a long message can chose to fragment it, and insert a short message in the middle if it likes, with the understanding, by both parties, that it logically preceeds the large message. A server in the middle can fragment and reassemble messages. It can even buffer a partial message that it is trying to reassemble while letting a smaller one that is interspersed flow thru. It can also hold a large message and trickle it out in fragments in order to share bandwidth with other streams. The only constraint is that when the last fragment of a message is received, it must be passed on before the last fragment of another message from the same source stream. This incurs no particular extra inefficiency that I can see. Given a rule like this I think we can assume that an MSRP stream defines a total ordering on the messages that traverse it. Paul Paul Kyzivat wrote: > > > Cullen Jennings wrote: > >> On 4/22/04 7:24 AM, "Paul Kyzivat" wrote: >> >>> Note that this is less of a problem with MSRP because it imposes an >>> ordering on messages within the session. One might argue that >>> isComposing is only appropriate with session oriented messaging and >>> shouldn't be used with page mode. >> >> >> Once we allow both small and large message to go over MSRP, We loose this >> ordering of messages property. This should be in the next draft. > > > Hmm. Good point. > > Its not really large and small that is the issue - its fragmentation, > right? > > There might still be well defined ordering even when there is > fragmentation, if we make clear whether the ordering is based on receipt > of the first fragment or the last. (I think the last makes most sense.) > > So if the ordering of fragments was preserved end to end then it > wouldn't be a problem. > > BUT, given that we intend to permit fragmentation and reassembly by > servers along the path, I think it would be difficult, and possibly > undesirable, to preserve ordering. > > This is an issue that goes far beyond isComposing. If A sends a number > of messages to B, I think we must at least arrange so that both A and B > agree on the order that those messages are to be displayed. > > (That is a much weaker condition than having them both agree on the > order in which the messages from A to B *and* the messages from B to A > are interleaved.) > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 18:23:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18471 for ; Fri, 23 Apr 2004 18:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH90j-0000RA-Qb for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 18:19:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NMJ5Wn001671 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 18:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8tE-0003mG-W6 for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 18:11:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17310 for ; Fri, 23 Apr 2004 18:11:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8tC-0002vK-3k for simple-web-archive@ietf.org; Fri, 23 Apr 2004 18:11:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8sE-0002eJ-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 18:10:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH8rA-0002Gc-00; Fri, 23 Apr 2004 18:09:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8dU-0002u0-Dm; Fri, 23 Apr 2004 17:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8WH-0008G2-1b for simple@optimus.ietf.org; Fri, 23 Apr 2004 17:47:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15448 for ; Fri, 23 Apr 2004 17:47:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8WE-0004N7-GE for simple@ietf.org; Fri, 23 Apr 2004 17:47:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8VM-00044j-00 for simple@ietf.org; Fri, 23 Apr 2004 17:46:40 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH8UP-0003Tv-00 for simple@ietf.org; Fri, 23 Apr 2004 17:45:41 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NLj2W9028662; Fri, 23 Apr 2004 14:45:03 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHV47183; Fri, 23 Apr 2004 17:45:01 -0400 (EDT) Message-ID: <40898E5D.1020802@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Cullen Jennings , Dave Oran , simple@ietf.org References: <40896A73.2030409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Deterministic message ordering in MSRP? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 17:45:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Replying to myself. :-( I thought about this a bit more, and now I think it is ok to require that a fragmentation algorithm preserve the ordering of the last fragment of messages. This in turn means that ordering of messages can be defined by the order in which their last fragment is sent/received. This means that the sender of a long message can chose to fragment it, and insert a short message in the middle if it likes, with the understanding, by both parties, that it logically preceeds the large message. A server in the middle can fragment and reassemble messages. It can even buffer a partial message that it is trying to reassemble while letting a smaller one that is interspersed flow thru. It can also hold a large message and trickle it out in fragments in order to share bandwidth with other streams. The only constraint is that when the last fragment of a message is received, it must be passed on before the last fragment of another message from the same source stream. This incurs no particular extra inefficiency that I can see. Given a rule like this I think we can assume that an MSRP stream defines a total ordering on the messages that traverse it. Paul Paul Kyzivat wrote: > > > Cullen Jennings wrote: > >> On 4/22/04 7:24 AM, "Paul Kyzivat" wrote: >> >>> Note that this is less of a problem with MSRP because it imposes an >>> ordering on messages within the session. One might argue that >>> isComposing is only appropriate with session oriented messaging and >>> shouldn't be used with page mode. >> >> >> Once we allow both small and large message to go over MSRP, We loose this >> ordering of messages property. This should be in the next draft. > > > Hmm. Good point. > > Its not really large and small that is the issue - its fragmentation, > right? > > There might still be well defined ordering even when there is > fragmentation, if we make clear whether the ordering is based on receipt > of the first fragment or the last. (I think the last makes most sense.) > > So if the ordering of fragments was preserved end to end then it > wouldn't be a problem. > > BUT, given that we intend to permit fragmentation and reassembly by > servers along the path, I think it would be difficult, and possibly > undesirable, to preserve ordering. > > This is an issue that goes far beyond isComposing. If A sends a number > of messages to B, I think we must at least arrange so that both A and B > agree on the order that those messages are to be displayed. > > (That is a much weaker condition than having them both agree on the > order in which the messages from A to B *and* the messages from B to A > are interleaved.) > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 19:15:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21344 for ; Fri, 23 Apr 2004 19:15:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9tF-0004b1-86 for simple-archive@ietf.org; Fri, 23 Apr 2004 19:15:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9sL-0004Lk-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 19:14:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH9rm-00046r-00; Fri, 23 Apr 2004 19:13:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9kD-00086U-Ab; Fri, 23 Apr 2004 19:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9aA-0004x5-B5 for simple@optimus.ietf.org; Fri, 23 Apr 2004 18:55:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20677 for ; Fri, 23 Apr 2004 18:55:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9a7-0007Mf-3N for simple@ietf.org; Fri, 23 Apr 2004 18:55:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9ZJ-000763-00 for simple@ietf.org; Fri, 23 Apr 2004 18:54:49 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BH9YT-0006nx-00 for simple@ietf.org; Fri, 23 Apr 2004 18:53:57 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3NMroC3016745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Apr 2004 18:53:50 -0400 (EDT) Message-ID: <40899E7E.3060400@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <40896A73.2030409@cisco.com> In-Reply-To: <40896A73.2030409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 18:53:50 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > This is an issue that goes far beyond isComposing. If A sends a number > of messages to B, I think we must at least arrange so that both A and B > agree on the order that those messages are to be displayed. > > (That is a much weaker condition than having them both agree on the > order in which the messages from A to B *and* the messages from B to A > are interleaved.) Would CSeq in MESSAGE allow this to happen without much fuss? (As I said before, the practical likelihood of reordering seems extremely low, even without such measures, given the NOTIFY window-size=1 constraint.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 19:31:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22057 for ; Fri, 23 Apr 2004 19:31:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9v8-0003JJ-PB for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 19:17:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NNHMq8012720 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 19:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9tH-0002li-LP for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 19:15:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21360 for ; Fri, 23 Apr 2004 19:15:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9tF-0004b6-Tb for simple-web-archive@ietf.org; Fri, 23 Apr 2004 19:15:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9sM-0004Lr-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 19:14:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH9rm-00046r-00; Fri, 23 Apr 2004 19:13:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9kD-00086U-Ab; Fri, 23 Apr 2004 19:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9aA-0004x5-B5 for simple@optimus.ietf.org; Fri, 23 Apr 2004 18:55:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20677 for ; Fri, 23 Apr 2004 18:55:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9a7-0007Mf-3N for simple@ietf.org; Fri, 23 Apr 2004 18:55:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9ZJ-000763-00 for simple@ietf.org; Fri, 23 Apr 2004 18:54:49 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BH9YT-0006nx-00 for simple@ietf.org; Fri, 23 Apr 2004 18:53:57 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i3NMroC3016745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Apr 2004 18:53:50 -0400 (EDT) Message-ID: <40899E7E.3060400@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <40896A73.2030409@cisco.com> In-Reply-To: <40896A73.2030409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 18:53:50 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This is an issue that goes far beyond isComposing. If A sends a number > of messages to B, I think we must at least arrange so that both A and B > agree on the order that those messages are to be displayed. > > (That is a much weaker condition than having them both agree on the > order in which the messages from A to B *and* the messages from B to A > are interleaved.) Would CSeq in MESSAGE allow this to happen without much fuss? (As I said before, the practical likelihood of reordering seems extremely low, even without such measures, given the NOTIFY window-size=1 constraint.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 23 23:00:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01023 for ; Fri, 23 Apr 2004 23:00:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHDPH-0000xL-8v for simple-archive@ietf.org; Fri, 23 Apr 2004 23:00:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHDOG-0000gT-00 for simple-archive@ietf.org; Fri, 23 Apr 2004 22:59:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHDNa-0000Qr-00; Fri, 23 Apr 2004 22:58:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHDJk-0003vN-Sv; Fri, 23 Apr 2004 22:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHDER-0002Oq-V9 for simple@optimus.ietf.org; Fri, 23 Apr 2004 22:49:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00616 for ; Fri, 23 Apr 2004 22:49:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHDEO-0005r5-HG for simple@ietf.org; Fri, 23 Apr 2004 22:49:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHDDP-0005bT-00 for simple@ietf.org; Fri, 23 Apr 2004 22:48:28 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BHDCO-00057W-00 for simple@ietf.org; Fri, 23 Apr 2004 22:47:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 18:57:56 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3O2kmC1020673; Fri, 23 Apr 2004 19:46:49 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-1-140.cisco.com [10.86.240.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHV59798; Fri, 23 Apr 2004 22:46:47 -0400 (EDT) Message-ID: <4089D517.1030509@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <40896A73.2030409@cisco.com> <40899E7E.3060400@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 22:46:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> This is an issue that goes far beyond isComposing. If A sends a number >> of messages to B, I think we must at least arrange so that both A and >> B agree on the order that those messages are to be displayed. >> >> (That is a much weaker condition than having them both agree on the >> order in which the messages from A to B *and* the messages from B to A >> are interleaved.) > > > Would CSeq in MESSAGE allow this to happen without much fuss? CSeq is only relevant within a dialog, and we aren't supposed to be sending MESSAGEs within dialogs. In any case, I was more concerned with Cullen's suggestion that messages might get reordered within an MSRP stream. Paul > (As I said before, the practical likelihood of reordering seems > extremely low, even without such measures, given the NOTIFY > window-size=1 constraint.) > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 23 23:07:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01318 for ; Fri, 23 Apr 2004 23:07:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHDTP-0006W6-LX for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 23:04:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O34xtd025046 for simple-archive@odin.ietf.org; Fri, 23 Apr 2004 23:04:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHDPL-0005Um-Qv for simple-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 23:00:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01045 for ; Fri, 23 Apr 2004 23:00:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHDPH-0000xR-UV for simple-web-archive@ietf.org; Fri, 23 Apr 2004 23:00:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHDOH-0000ga-00 for simple-web-archive@ietf.org; Fri, 23 Apr 2004 22:59:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHDNa-0000Qr-00; Fri, 23 Apr 2004 22:58:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHDJk-0003vN-Sv; Fri, 23 Apr 2004 22:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHDER-0002Oq-V9 for simple@optimus.ietf.org; Fri, 23 Apr 2004 22:49:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00616 for ; Fri, 23 Apr 2004 22:49:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHDEO-0005r5-HG for simple@ietf.org; Fri, 23 Apr 2004 22:49:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHDDP-0005bT-00 for simple@ietf.org; Fri, 23 Apr 2004 22:48:28 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BHDCO-00057W-00 for simple@ietf.org; Fri, 23 Apr 2004 22:47:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 18:57:56 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3O2kmC1020673; Fri, 23 Apr 2004 19:46:49 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-1-140.cisco.com [10.86.240.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHV59798; Fri, 23 Apr 2004 22:46:47 -0400 (EDT) Message-ID: <4089D517.1030509@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <40896A73.2030409@cisco.com> <40899E7E.3060400@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 22:46:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> This is an issue that goes far beyond isComposing. If A sends a number >> of messages to B, I think we must at least arrange so that both A and >> B agree on the order that those messages are to be displayed. >> >> (That is a much weaker condition than having them both agree on the >> order in which the messages from A to B *and* the messages from B to A >> are interleaved.) > > > Would CSeq in MESSAGE allow this to happen without much fuss? CSeq is only relevant within a dialog, and we aren't supposed to be sending MESSAGEs within dialogs. In any case, I was more concerned with Cullen's suggestion that messages might get reordered within an MSRP stream. Paul > (As I said before, the practical likelihood of reordering seems > extremely low, even without such measures, given the NOTIFY > window-size=1 constraint.) > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 26 04:36:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03234 for ; Mon, 26 Apr 2004 04:36:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1ar-0005pt-VT for simple-archive@ietf.org; Mon, 26 Apr 2004 04:36:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1Zx-0005a2-00 for simple-archive@ietf.org; Mon, 26 Apr 2004 04:35:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI1Yv-0005LT-00; Mon, 26 Apr 2004 04:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1VA-0004us-DO; Mon, 26 Apr 2004 04:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1Sy-000478-0O for simple@optimus.ietf.org; Mon, 26 Apr 2004 04:27:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02652 for ; Mon, 26 Apr 2004 04:27:48 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1Sv-0003y5-3B for simple@ietf.org; Mon, 26 Apr 2004 04:27:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1Rv-0003mY-00 for simple@ietf.org; Mon, 26 Apr 2004 04:26:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BI1RA-0003b2-00 for simple@ietf.org; Mon, 26 Apr 2004 04:26:00 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q8Pls26162; Mon, 26 Apr 2004 11:25:47 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 11:25:16 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3Q8PGD9019523; Mon, 26 Apr 2004 11:25:16 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00vfuJiv; Mon, 26 Apr 2004 10:44:23 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7iCF11603; Mon, 26 Apr 2004 10:44:12 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:44:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Updating the XCAP PIDF manipulation draft Message-ID: Thread-Topic: [Simple] Updating the XCAP PIDF manipulation draft Thread-Index: AcQpTQYCfMQAS6ooR6q2foTqyuxr6gCEr0kQ To: Cc: , , , X-OriginalArrivalTime: 26 Apr 2004 07:44:15.0563 (UTC) FILETIME=[461299B0:01C42B62] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 10:44:15 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Alex, There are two separate things that XCAP is (can be) used for: 1. Setting authorization policies, which at least to some extent also = define policies how the event state compositor should handle the = different presence inputs wrt. different watchers. (The current draft is = here: = http://www.ietf.org/internet-drafts/draft-rosenberg-simple-rules-00.txt) 2. Setting the "hard-state" device-independent default presence status. I think you are referring to case 1. It's true that some policy settings = are typically done before actually publishing presence information, or = manipulating the default presence document with XCAP. It is obviously = possible to change them at any point as you want your policy to change.=20 >From protocol point of view the XCAP operations done to manipulate the = PIDF document are independent from the XCAP operations done to set the = policies. Also, there is nothing which mandates in which temporal order = SIP PUBLISH and XCAP PIDF manipulation are used. Markus > -----Original Message----- > From: ext Alex Audu [mailto:alex.audu@alcatel.com] > Sent: 23 April, 2004 19:04 > To: Isomaki Markus (Nokia-NRC/Helsinki) > Cc: simple@ietf.org; Leppanen Eva-Maria (Nokia-NET/Tampere); > jdrosen@dynamicsoft.com; george.foti@ericsson.com > Subject: Re: [Simple] Updating the XCAP PIDF manipulation draft >=20 >=20 >=20 > Would it add more clarity to also state that XCAP state manipulation=20 > should be done > before SIP PUBLISH, since the XCAP process sets the policy rules that=20 > determine > which watcher gets what published information? =20 >=20 > Regards, > Alex. >=20 > Markus.Isomaki@nokia.com wrote: >=20 > >Hi, > > > >Me and Eva are working on an update to the XCAP PIDF=20 > manipulation usage. Based on the earlier version there was=20 > some confusion on the relationship of the presence state set=20 > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with=20 > the text below. I would like to get some feedback whether you=20 > think it is clear enough. At least George and Jonathan have=20 > commented the previous version, so I would especially like=20 > your comments. > > > >Chapter 1 contains the motivation, I think no changes are=20 > needed for that. This is for Chapter 3 (the figure is unmodified): > > > >--- > > > >The framework for publishing presence state is introduced in=20 > . A central part of the=20 > framework is the event state compositor element whose=20 > function is to compose presence information received from=20 > serveral sources into a single coherent presence document. > > > >The presence state manipulated with XCAP can be seen as one=20 > of the information sources for the compositor to be combined=20 > with the soft state information published using SIP PUBLISH.=20 > This is illustrated in Figure 1. It is expected that in the=20 > normal case there can be several PUAs publishing their=20 > separate views with SIP PUBLISH, but only single XCAP=20 > manipulated presence document. As shown in the figure, there=20 > can be multiple XCAP clients (for instance in different=20 > physical devices) manipulating the same document on the XCAP=20 > server, but this still creates only one input to the event=20 > state compositor. > > > >As individual inputs the presence states set by XCAP and SIP=20 > PUBLISH are completely separated and it is not possible to=20 > directly manipulate the state set by one mechanism with the=20 > other. How the compositor treats XCAP based inputs with=20 > respect to SIP PUBLISH based inputs is a matter of compositor=20 > policy, which is beyond the scope of this specification.=20 > Since the SIP PUBLISH specification already mandates the=20 > compositor to be able to deal with multiple inputs, this XCAP=20 > usage does not impose any new requirements on the compositor=20 > functionality. =20 > > > >--- > > > >Regards, > > Markus > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > =20 > > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 26 04:47:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04255 for ; Mon, 26 Apr 2004 04:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1it-0000js-VS for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 04:44:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q8iJ5e002833 for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 04:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1av-0006dg-Rp for simple-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 04:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03254 for ; Mon, 26 Apr 2004 04:36:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1as-0005py-Ti for simple-web-archive@ietf.org; Mon, 26 Apr 2004 04:36:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1Zy-0005a9-00 for simple-web-archive@ietf.org; Mon, 26 Apr 2004 04:35:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI1Yv-0005LT-00; Mon, 26 Apr 2004 04:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1VA-0004us-DO; Mon, 26 Apr 2004 04:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1Sy-000478-0O for simple@optimus.ietf.org; Mon, 26 Apr 2004 04:27:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02652 for ; Mon, 26 Apr 2004 04:27:48 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1Sv-0003y5-3B for simple@ietf.org; Mon, 26 Apr 2004 04:27:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1Rv-0003mY-00 for simple@ietf.org; Mon, 26 Apr 2004 04:26:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BI1RA-0003b2-00 for simple@ietf.org; Mon, 26 Apr 2004 04:26:00 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q8Pls26162; Mon, 26 Apr 2004 11:25:47 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 11:25:16 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3Q8PGD9019523; Mon, 26 Apr 2004 11:25:16 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00vfuJiv; Mon, 26 Apr 2004 10:44:23 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7iCF11603; Mon, 26 Apr 2004 10:44:12 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:44:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Updating the XCAP PIDF manipulation draft Message-ID: Thread-Topic: [Simple] Updating the XCAP PIDF manipulation draft Thread-Index: AcQpTQYCfMQAS6ooR6q2foTqyuxr6gCEr0kQ To: Cc: , , , X-OriginalArrivalTime: 26 Apr 2004 07:44:15.0563 (UTC) FILETIME=[461299B0:01C42B62] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 10:44:15 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alex, There are two separate things that XCAP is (can be) used for: 1. Setting authorization policies, which at least to some extent also = define policies how the event state compositor should handle the = different presence inputs wrt. different watchers. (The current draft is = here: = http://www.ietf.org/internet-drafts/draft-rosenberg-simple-rules-00.txt) 2. Setting the "hard-state" device-independent default presence status. I think you are referring to case 1. It's true that some policy settings = are typically done before actually publishing presence information, or = manipulating the default presence document with XCAP. It is obviously = possible to change them at any point as you want your policy to change.=20 >From protocol point of view the XCAP operations done to manipulate the = PIDF document are independent from the XCAP operations done to set the = policies. Also, there is nothing which mandates in which temporal order = SIP PUBLISH and XCAP PIDF manipulation are used. Markus > -----Original Message----- > From: ext Alex Audu [mailto:alex.audu@alcatel.com] > Sent: 23 April, 2004 19:04 > To: Isomaki Markus (Nokia-NRC/Helsinki) > Cc: simple@ietf.org; Leppanen Eva-Maria (Nokia-NET/Tampere); > jdrosen@dynamicsoft.com; george.foti@ericsson.com > Subject: Re: [Simple] Updating the XCAP PIDF manipulation draft >=20 >=20 >=20 > Would it add more clarity to also state that XCAP state manipulation=20 > should be done > before SIP PUBLISH, since the XCAP process sets the policy rules that=20 > determine > which watcher gets what published information? =20 >=20 > Regards, > Alex. >=20 > Markus.Isomaki@nokia.com wrote: >=20 > >Hi, > > > >Me and Eva are working on an update to the XCAP PIDF=20 > manipulation usage. Based on the earlier version there was=20 > some confusion on the relationship of the presence state set=20 > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with=20 > the text below. I would like to get some feedback whether you=20 > think it is clear enough. At least George and Jonathan have=20 > commented the previous version, so I would especially like=20 > your comments. > > > >Chapter 1 contains the motivation, I think no changes are=20 > needed for that. This is for Chapter 3 (the figure is unmodified): > > > >--- > > > >The framework for publishing presence state is introduced in=20 > . A central part of the=20 > framework is the event state compositor element whose=20 > function is to compose presence information received from=20 > serveral sources into a single coherent presence document. > > > >The presence state manipulated with XCAP can be seen as one=20 > of the information sources for the compositor to be combined=20 > with the soft state information published using SIP PUBLISH.=20 > This is illustrated in Figure 1. It is expected that in the=20 > normal case there can be several PUAs publishing their=20 > separate views with SIP PUBLISH, but only single XCAP=20 > manipulated presence document. As shown in the figure, there=20 > can be multiple XCAP clients (for instance in different=20 > physical devices) manipulating the same document on the XCAP=20 > server, but this still creates only one input to the event=20 > state compositor. > > > >As individual inputs the presence states set by XCAP and SIP=20 > PUBLISH are completely separated and it is not possible to=20 > directly manipulate the state set by one mechanism with the=20 > other. How the compositor treats XCAP based inputs with=20 > respect to SIP PUBLISH based inputs is a matter of compositor=20 > policy, which is beyond the scope of this specification.=20 > Since the SIP PUBLISH specification already mandates the=20 > compositor to be able to deal with multiple inputs, this XCAP=20 > usage does not impose any new requirements on the compositor=20 > functionality. =20 > > > >--- > > > >Regards, > > Markus > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > =20 > > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 26 09:05:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17852 for ; Mon, 26 Apr 2004 09:05:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5nJ-00059K-ND for simple-archive@ietf.org; Mon, 26 Apr 2004 09:05:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5m8-000545-00 for simple-archive@ietf.org; Mon, 26 Apr 2004 09:03:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI5lj-00051w-00; Mon, 26 Apr 2004 09:03:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5ac-0006bX-Cn; Mon, 26 Apr 2004 08:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5Wf-00060T-BR for simple@optimus.ietf.org; Mon, 26 Apr 2004 08:47:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15863 for ; Mon, 26 Apr 2004 08:47:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5We-00039O-3t for simple@ietf.org; Mon, 26 Apr 2004 08:47:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5Vk-00037w-00 for simple@ietf.org; Mon, 26 Apr 2004 08:47:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BI5VU-00036C-00 for simple@ietf.org; Mon, 26 Apr 2004 08:46:44 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCkCB26904; Mon, 26 Apr 2004 15:46:16 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 15:45:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3QCjtcv030215; Mon, 26 Apr 2004 15:45:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00nwMUUy; Mon, 26 Apr 2004 15:45:53 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCjdJ03234; Mon, 26 Apr 2004 15:45:39 +0300 (EET DST) Received: from nokia.com ([10.162.252.84]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 15:42:36 +0300 Message-ID: <408D03BB.3000802@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Henning Schulzrinne CC: Ben Campbell , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> <40888107.7080207@cs.columbia.edu> In-Reply-To: <40888107.7080207@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2004 12:42:36.0992 (UTC) FILETIME=[F427E400:01C42B8B] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 15:42:35 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. ext Henning Schulzrinne wrote: >> As I commented in a separate thread, endpoints using page-mode may >> still have a local idea of a "virtual confersation". isComposing may >> be useful in that context. But I think we may need more guidelines for >> using it in page-mode, if we support that at all. > > > I suppose this comes back to how much user interface guidance we want to > provide. None of this is necessary for interoperability - if I want to > send isComposing before the first bit of text, this will work just fine > and there may even be scenarios where this makes sense. For example, for > audio and video messages, a bit of warning before the message comes out > of the speaker wouldn't hurt. I guess my main concern is the potential information leak involved in a forward notice isComposing indication. Otherwise, I'm happy to use this also for page-mode. As long as we're clear that in page-mode it is to avoid users from talking past each other, and not to set up "pseudo-sessions". Having said that though, I think the current draft is clear as it is already. I'd propose a couple of sentences in Security Considerations explaining the potential privacy issues in an isComposing being received before/without the actual "first" message of a conversation being received. Perhaps something like: "There are potential privacy issues in sending isComposing indications before an actual conversation has been established between the communicating users. It is RECOMMENDED that isComposing indications in page-mode are only sent when a message is being composed as a reply to an earlier message." Additionally, you could say that implementations are free to use whatever mechanisms to determine when a message is in-reply-to a previous received message. > I think we should not assume that MSRP sessions correspond to human > conversations. IM conversations seem to come in brief spurts, with > pauses in between, but no formal farewell or 'ringing' (beyond, maybe, > an initial Hi!). Similarly we should not assume MSRP sesions don't correspond to human conversations. For example, in conferencing the MSRP session very often would correspond to a human conversation, namely participation in a chat room. > I would imagine that the lower-layer sessions will often stay up > indefinitely between co-workers, so that a sudden isComposing after two > days of silence is not substantially different, from a user experience > and privacy perspective, just because there is an on-going SIP session > underneath that is largely invisible to the user. If a session has to be > manually 'picked up' at the receiver, users aren't likely to tear them > down. If they wanted a phone call experience, they would place a call. > If the session is automatically accepted, the user experience doesn't > differ from page mode. I agree that session-mode with auto-answer isn't that different (from user's point of view) from page-mode. But I don't think it's a good idea to build the IM application assuming there is always auto-answer. The caller/callee must also handle a case where a session mode call requires the same interaction from the user (perhaps something similar to talk in Unix), as a normal voice call. This is as reasonable an implementation of session-mode as is the auto-answer one. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 26 09:19:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18973 for ; Mon, 26 Apr 2004 09:19:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5vr-0004C5-Dk for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 09:13:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDDx2K016115 for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 09:13:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5nM-0000vW-4K for simple-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:05:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17870 for ; Mon, 26 Apr 2004 09:05:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5nK-00059S-Jy for simple-web-archive@ietf.org; Mon, 26 Apr 2004 09:05:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5m9-00054D-00 for simple-web-archive@ietf.org; Mon, 26 Apr 2004 09:03:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI5lj-00051w-00; Mon, 26 Apr 2004 09:03:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5ac-0006bX-Cn; Mon, 26 Apr 2004 08:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5Wf-00060T-BR for simple@optimus.ietf.org; Mon, 26 Apr 2004 08:47:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15863 for ; Mon, 26 Apr 2004 08:47:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5We-00039O-3t for simple@ietf.org; Mon, 26 Apr 2004 08:47:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5Vk-00037w-00 for simple@ietf.org; Mon, 26 Apr 2004 08:47:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BI5VU-00036C-00 for simple@ietf.org; Mon, 26 Apr 2004 08:46:44 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCkCB26904; Mon, 26 Apr 2004 15:46:16 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 15:45:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3QCjtcv030215; Mon, 26 Apr 2004 15:45:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00nwMUUy; Mon, 26 Apr 2004 15:45:53 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCjdJ03234; Mon, 26 Apr 2004 15:45:39 +0300 (EET DST) Received: from nokia.com ([10.162.252.84]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 15:42:36 +0300 Message-ID: <408D03BB.3000802@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Henning Schulzrinne CC: Ben Campbell , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> <40888107.7080207@cs.columbia.edu> In-Reply-To: <40888107.7080207@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2004 12:42:36.0992 (UTC) FILETIME=[F427E400:01C42B8B] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 15:42:35 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. ext Henning Schulzrinne wrote: >> As I commented in a separate thread, endpoints using page-mode may >> still have a local idea of a "virtual confersation". isComposing may >> be useful in that context. But I think we may need more guidelines for >> using it in page-mode, if we support that at all. > > > I suppose this comes back to how much user interface guidance we want to > provide. None of this is necessary for interoperability - if I want to > send isComposing before the first bit of text, this will work just fine > and there may even be scenarios where this makes sense. For example, for > audio and video messages, a bit of warning before the message comes out > of the speaker wouldn't hurt. I guess my main concern is the potential information leak involved in a forward notice isComposing indication. Otherwise, I'm happy to use this also for page-mode. As long as we're clear that in page-mode it is to avoid users from talking past each other, and not to set up "pseudo-sessions". Having said that though, I think the current draft is clear as it is already. I'd propose a couple of sentences in Security Considerations explaining the potential privacy issues in an isComposing being received before/without the actual "first" message of a conversation being received. Perhaps something like: "There are potential privacy issues in sending isComposing indications before an actual conversation has been established between the communicating users. It is RECOMMENDED that isComposing indications in page-mode are only sent when a message is being composed as a reply to an earlier message." Additionally, you could say that implementations are free to use whatever mechanisms to determine when a message is in-reply-to a previous received message. > I think we should not assume that MSRP sessions correspond to human > conversations. IM conversations seem to come in brief spurts, with > pauses in between, but no formal farewell or 'ringing' (beyond, maybe, > an initial Hi!). Similarly we should not assume MSRP sesions don't correspond to human conversations. For example, in conferencing the MSRP session very often would correspond to a human conversation, namely participation in a chat room. > I would imagine that the lower-layer sessions will often stay up > indefinitely between co-workers, so that a sudden isComposing after two > days of silence is not substantially different, from a user experience > and privacy perspective, just because there is an on-going SIP session > underneath that is largely invisible to the user. If a session has to be > manually 'picked up' at the receiver, users aren't likely to tear them > down. If they wanted a phone call experience, they would place a call. > If the session is automatically accepted, the user experience doesn't > differ from page mode. I agree that session-mode with auto-answer isn't that different (from user's point of view) from page-mode. But I don't think it's a good idea to build the IM application assuming there is always auto-answer. The caller/callee must also handle a case where a session mode call requires the same interaction from the user (perhaps something similar to talk in Unix), as a normal voice call. This is as reasonable an implementation of session-mode as is the auto-answer one. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 26 09:45:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20067 for ; Mon, 26 Apr 2004 09:45:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6Qk-0007Zw-1i for simple-archive@ietf.org; Mon, 26 Apr 2004 09:45:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6Pq-0007WT-00 for simple-archive@ietf.org; Mon, 26 Apr 2004 09:44:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI6Ow-0007Ud-00; Mon, 26 Apr 2004 09:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6GO-0002bw-O5; Mon, 26 Apr 2004 09:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6BN-0000Ph-6P for simple@optimus.ietf.org; Mon, 26 Apr 2004 09:30:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19404 for ; Mon, 26 Apr 2004 09:29:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6BL-0006pP-1X for simple@ietf.org; Mon, 26 Apr 2004 09:29:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6AS-0006mI-00 for simple@ietf.org; Mon, 26 Apr 2004 09:29:04 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BI69r-0006hs-00 for simple@ietf.org; Mon, 26 Apr 2004 09:28:27 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3QDQMh20265; Mon, 26 Apr 2004 08:26:22 -0500 Message-ID: <408D0DF0.8030801@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Espoo)" CC: ext Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> <40888107.7080207@cs.columbia.edu> <408D03BB.3000802@nokia.com> In-Reply-To: <408D03BB.3000802@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 08:26:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Niemi Aki (Nokia-M/Espoo) wrote: > inline. > > ext Henning Schulzrinne wrote: > >>> As I commented in a separate thread, endpoints using page-mode may >>> still have a local idea of a "virtual confersation". isComposing may >>> be useful in that context. But I think we may need more guidelines >>> for using it in page-mode, if we support that at all. >> >> >> >> I suppose this comes back to how much user interface guidance we want >> to provide. None of this is necessary for interoperability - if I want >> to send isComposing before the first bit of text, this will work just >> fine and there may even be scenarios where this makes sense. For >> example, for audio and video messages, a bit of warning before the >> message comes out of the speaker wouldn't hurt. > > > I guess my main concern is the potential information leak involved in a > forward notice isComposing indication. Otherwise, I'm happy to use this > also for page-mode. As long as we're clear that in page-mode it is to > avoid users from talking past each other, and not to set up > "pseudo-sessions". I agree here. I did not mean to imply that isComposing would set up such a pseudo-session, only that if you used this sort of user metaphor, isComposing could be useful. > > Having said that though, I think the current draft is clear as it is > already. I'd propose a couple of sentences in Security Considerations > explaining the potential privacy issues in an isComposing being received > before/without the actual "first" message of a conversation being received. > > Perhaps something like: > > "There are potential privacy issues in sending isComposing indications > before an actual conversation has been established between the > communicating users. It is RECOMMENDED that isComposing indications in > page-mode are only sent when a message is being composed as a reply to > an earlier message." > I agree. > Additionally, you could say that implementations are free to use > whatever mechanisms to determine when a message is in-reply-to a > previous received message. > >> I think we should not assume that MSRP sessions correspond to human >> conversations. IM conversations seem to come in brief spurts, with >> pauses in between, but no formal farewell or 'ringing' (beyond, maybe, >> an initial Hi!). > > > Similarly we should not assume MSRP sesions don't correspond to human > conversations. For example, in conferencing the MSRP session very often > would correspond to a human conversation, namely participation in a chat > room. > >> I would imagine that the lower-layer sessions will often stay up >> indefinitely between co-workers, so that a sudden isComposing after >> two days of silence is not substantially different, from a user >> experience and privacy perspective, just because there is an on-going >> SIP session underneath that is largely invisible to the user. If a >> session has to be manually 'picked up' at the receiver, users aren't >> likely to tear them down. If they wanted a phone call experience, they >> would place a call. If the session is automatically accepted, the user >> experience doesn't differ from page mode. > > > I agree that session-mode with auto-answer isn't that different (from > user's point of view) from page-mode. But I don't think it's a good idea > to build the IM application assuming there is always auto-answer. > > The caller/callee must also handle a case where a session mode call > requires the same interaction from the user (perhaps something similar > to talk in Unix), as a normal voice call. This is as reasonable an > implementation of session-mode as is the auto-answer one. > > Cheers, > Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 26 09:59:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20972 for ; Mon, 26 Apr 2004 09:59:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Uq-0007GE-MR for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 09:50:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDo8Vo027905 for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 09:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Qm-0005tQ-TW for simple-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20070 for ; Mon, 26 Apr 2004 09:45:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6Qk-0007a1-N2 for simple-web-archive@ietf.org; Mon, 26 Apr 2004 09:45:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6Pr-0007Wa-00 for simple-web-archive@ietf.org; Mon, 26 Apr 2004 09:44:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI6Ow-0007Ud-00; Mon, 26 Apr 2004 09:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6GO-0002bw-O5; Mon, 26 Apr 2004 09:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6BN-0000Ph-6P for simple@optimus.ietf.org; Mon, 26 Apr 2004 09:30:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19404 for ; Mon, 26 Apr 2004 09:29:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6BL-0006pP-1X for simple@ietf.org; Mon, 26 Apr 2004 09:29:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6AS-0006mI-00 for simple@ietf.org; Mon, 26 Apr 2004 09:29:04 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BI69r-0006hs-00 for simple@ietf.org; Mon, 26 Apr 2004 09:28:27 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3QDQMh20265; Mon, 26 Apr 2004 08:26:22 -0500 Message-ID: <408D0DF0.8030801@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Espoo)" CC: ext Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] WGLC on isComposing draft References: <2038BCC78B1AD641891A0D1AE133DBB70179795F@esebe019.ntc.nokia.com> <4087EE4C.8060608@cisco.com> <4087FFF2.2090509@nokia.com> <408830AC.8080409@dynamicsoft.com> <40888107.7080207@cs.columbia.edu> <408D03BB.3000802@nokia.com> In-Reply-To: <408D03BB.3000802@nokia.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 08:26:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Niemi Aki (Nokia-M/Espoo) wrote: > inline. > > ext Henning Schulzrinne wrote: > >>> As I commented in a separate thread, endpoints using page-mode may >>> still have a local idea of a "virtual confersation". isComposing may >>> be useful in that context. But I think we may need more guidelines >>> for using it in page-mode, if we support that at all. >> >> >> >> I suppose this comes back to how much user interface guidance we want >> to provide. None of this is necessary for interoperability - if I want >> to send isComposing before the first bit of text, this will work just >> fine and there may even be scenarios where this makes sense. For >> example, for audio and video messages, a bit of warning before the >> message comes out of the speaker wouldn't hurt. > > > I guess my main concern is the potential information leak involved in a > forward notice isComposing indication. Otherwise, I'm happy to use this > also for page-mode. As long as we're clear that in page-mode it is to > avoid users from talking past each other, and not to set up > "pseudo-sessions". I agree here. I did not mean to imply that isComposing would set up such a pseudo-session, only that if you used this sort of user metaphor, isComposing could be useful. > > Having said that though, I think the current draft is clear as it is > already. I'd propose a couple of sentences in Security Considerations > explaining the potential privacy issues in an isComposing being received > before/without the actual "first" message of a conversation being received. > > Perhaps something like: > > "There are potential privacy issues in sending isComposing indications > before an actual conversation has been established between the > communicating users. It is RECOMMENDED that isComposing indications in > page-mode are only sent when a message is being composed as a reply to > an earlier message." > I agree. > Additionally, you could say that implementations are free to use > whatever mechanisms to determine when a message is in-reply-to a > previous received message. > >> I think we should not assume that MSRP sessions correspond to human >> conversations. IM conversations seem to come in brief spurts, with >> pauses in between, but no formal farewell or 'ringing' (beyond, maybe, >> an initial Hi!). > > > Similarly we should not assume MSRP sesions don't correspond to human > conversations. For example, in conferencing the MSRP session very often > would correspond to a human conversation, namely participation in a chat > room. > >> I would imagine that the lower-layer sessions will often stay up >> indefinitely between co-workers, so that a sudden isComposing after >> two days of silence is not substantially different, from a user >> experience and privacy perspective, just because there is an on-going >> SIP session underneath that is largely invisible to the user. If a >> session has to be manually 'picked up' at the receiver, users aren't >> likely to tear them down. If they wanted a phone call experience, they >> would place a call. If the session is automatically accepted, the user >> experience doesn't differ from page mode. > > > I agree that session-mode with auto-answer isn't that different (from > user's point of view) from page-mode. But I don't think it's a good idea > to build the IM application assuming there is always auto-answer. > > The caller/callee must also handle a case where a session mode call > requires the same interaction from the user (perhaps something similar > to talk in Unix), as a normal voice call. This is as reasonable an > implementation of session-mode as is the auto-answer one. > > Cheers, > Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 26 15:36:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13971 for ; Mon, 26 Apr 2004 15:36:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBtd-0001a4-1X for simple-archive@ietf.org; Mon, 26 Apr 2004 15:36:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBsi-0001X5-00 for simple-archive@ietf.org; Mon, 26 Apr 2004 15:35:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBrr-0001UA-00; Mon, 26 Apr 2004 15:34:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBlq-0008QL-6e; Mon, 26 Apr 2004 15:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBdJ-0006jY-66 for simple@optimus.ietf.org; Mon, 26 Apr 2004 15:19:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12712 for ; Mon, 26 Apr 2004 15:19:10 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBdH-0000eR-UF for simple@ietf.org; Mon, 26 Apr 2004 15:19:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBcP-0000c9-00 for simple@ietf.org; Mon, 26 Apr 2004 15:18:18 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BIBc2-0000Zd-00 for simple@ietf.org; Mon, 26 Apr 2004 15:17:54 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QJHpH11384; Mon, 26 Apr 2004 22:17:51 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 22:17:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3QJHJs6004740; Mon, 26 Apr 2004 22:17:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00cRYGnA; Mon, 26 Apr 2004 22:17:17 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QJH7J16061; Mon, 26 Apr 2004 22:17:07 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 22:16:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE94@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4Q To: , X-OriginalArrivalTime: 26 Apr 2004 19:16:48.0535 (UTC) FILETIME=[0592F270:01C42BC3] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 22:16:48 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Thanks for comments. Responses inline: > Writing as a WG member - not as chair - >=20 > I've sent a list of typo level nits in these drafts to Mikko privately > - >=20 > While doing a nit review, I found some things that should have=20 > received list attention earlier. >=20 > In section 4.4 of -partial-notify it says "The PA SHOULD construct the > partial presence document according to the following logic:" followed=20 > by a bunch of MUST level statements. Why is that SHOULD there? What=20 > would it mean to violate it? I suggest striking it and simply saying=20 > "The PA constructs" Yes, SHOULD is probably useless and confusing here. I will remove it. > Why do we have both "state" and "version"? As defined in these drafts, > state=3Dfull if and only if version=3D0. You could delete the state=20 > parameter with no loss of information, so why is it there? I believe the original need for the "state" was that the "version" could be initialized to some random value. Now, if "version" is always initialized to 0 there is no need for the "state" attribute. Both solutions should work and if nobody else comments otherwise I will remove the "state" attribute. > 3261 currently allows overlapping non-INVITE transactions inside a=20 > dialog (there's an open issue suggesting this might be a bad thing,=20 > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > full state documents, having multiple outstanding NOTIFYs is=20 > probably manageable. For partial state documents, at least as=20 > they are specified here, it could be disastrous. Consider=20 > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > If the recipient receives only N1 and N4 (something prevents=20 > N2 and N3 from being delivered or simply delays them=20 > (packetloss over UDP for example)), it will apply the delta=20 > in N4 to the wrong full state document (N1 instead of N3).=20 Actually it wouldn't because of "version" handling. Section 4.5 applies here. But in any case this kind of behavior is quite bad as it might result in frequent subscription refreshes to obtain full presence state. More below. > We > can preserve the properties of the existing system is we > forbid sending a NOTIFY with a document with state=3D"partial"=20 > when any other NOTIFY transaction is still in progress on this dialog. This is a good point. Your proposed solution should work. This may cause some extra implementation effort for PA but I cannot see any way around this. If no other comments are received I will add text forbidding sending a NOTIFY with a document with state=3D"partial" (version=3D0) = when any other NOTIFY transaction is still in progress on this dialog.=20 > Section 4.5 of partial-notify says "If the watcher receives a > presence document whose "version" attribute value (is) higher=20 > by more than one with the locally stored value, the watcher=20 > assumes that one or more NOTIFYs were lost. The watcher=20 > SHOULD either refresh the subscription=20 > in order to receive a full presence document or terminate the=20 > subscription." Why is that SHOULD? In what scenario is any=20 > other course of action reasonable? (The only one I can think=20 > of is _if_ we allow overlapping partial NOTIFYs, then the=20 > watcher can wait around for awhile for the gaps to fill in -=20 > if we allow this, then we need to explicitly state this as=20 > why the above is SHOULD, not MUST. However, I think this=20 > should be a MUST.) Well, there probably isn't any good cases where watcher wouldn't terminate or refresh subscription. Changing SHOULD to MUST should provide more consistent behavior. =20 > Just below that, there's a "SHOULD discard the document" if=20 > it gets a partial notification with a lower version number. I=20 > don't see how this is right at all, and suggest that this=20 > MUST trigger a refresh or termination instead. (We wouldn't=20 > get to this logic if a NOTIFY was reordered and arrived late=20 > - the CSeq processing logic would=20 > have caught it). Right, and if we don't allow sending new NOTIFYs if there is a pending transaction then I believe reordering should never happen. But if in this situation watcher receives a presence document with lower version number there should be no harm in discarding it because it already has a consistent presence state. This is more or less an error case which probably should never happen but I think there is no need to refresh or terminate the subscription. - Mikko > I'll send a separate message on the Security Considerations=20 > section for -partial-notify. >=20 > RjS >=20 >=20 > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > This is a Working Group Last call on the following drafts: > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-> ietf-simple-partial-notify-0 > > 2.txt > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- pidf-format-01.txt >=20 > This abbreviated WGLC will end on Wednesday, April 28. >=20 > These drafts went through a previous last call at the beginning of=20 > March. These versions reflect changes due to comments received during=20 > that period. See=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > 519.html > for details. >=20 > Please send comments to the list, copying the editor. If you reviewed=20 > the draft and found no issues, please indicate so on the list. >=20 > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 26 16:49:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19450 for ; Mon, 26 Apr 2004 16:49:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BICso-0004HW-4L for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 16:39:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QKdI6g016452 for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 16:39:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBtf-00019n-2Y for simple-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 15:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13985 for ; Mon, 26 Apr 2004 15:36:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBtd-0001aB-Nw for simple-web-archive@ietf.org; Mon, 26 Apr 2004 15:36:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBsj-0001XC-00 for simple-web-archive@ietf.org; Mon, 26 Apr 2004 15:35:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIBrr-0001UA-00; Mon, 26 Apr 2004 15:34:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBlq-0008QL-6e; Mon, 26 Apr 2004 15:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBdJ-0006jY-66 for simple@optimus.ietf.org; Mon, 26 Apr 2004 15:19:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12712 for ; Mon, 26 Apr 2004 15:19:10 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBdH-0000eR-UF for simple@ietf.org; Mon, 26 Apr 2004 15:19:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBcP-0000c9-00 for simple@ietf.org; Mon, 26 Apr 2004 15:18:18 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BIBc2-0000Zd-00 for simple@ietf.org; Mon, 26 Apr 2004 15:17:54 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QJHpH11384; Mon, 26 Apr 2004 22:17:51 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 22:17:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3QJHJs6004740; Mon, 26 Apr 2004 22:17:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00cRYGnA; Mon, 26 Apr 2004 22:17:17 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QJH7J16061; Mon, 26 Apr 2004 22:17:07 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 22:16:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE94@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4Q To: , X-OriginalArrivalTime: 26 Apr 2004 19:16:48.0535 (UTC) FILETIME=[0592F270:01C42BC3] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 22:16:48 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Thanks for comments. Responses inline: > Writing as a WG member - not as chair - >=20 > I've sent a list of typo level nits in these drafts to Mikko privately > - >=20 > While doing a nit review, I found some things that should have=20 > received list attention earlier. >=20 > In section 4.4 of -partial-notify it says "The PA SHOULD construct the > partial presence document according to the following logic:" followed=20 > by a bunch of MUST level statements. Why is that SHOULD there? What=20 > would it mean to violate it? I suggest striking it and simply saying=20 > "The PA constructs" Yes, SHOULD is probably useless and confusing here. I will remove it. > Why do we have both "state" and "version"? As defined in these drafts, > state=3Dfull if and only if version=3D0. You could delete the state=20 > parameter with no loss of information, so why is it there? I believe the original need for the "state" was that the "version" could be initialized to some random value. Now, if "version" is always initialized to 0 there is no need for the "state" attribute. Both solutions should work and if nobody else comments otherwise I will remove the "state" attribute. > 3261 currently allows overlapping non-INVITE transactions inside a=20 > dialog (there's an open issue suggesting this might be a bad thing,=20 > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > full state documents, having multiple outstanding NOTIFYs is=20 > probably manageable. For partial state documents, at least as=20 > they are specified here, it could be disastrous. Consider=20 > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > If the recipient receives only N1 and N4 (something prevents=20 > N2 and N3 from being delivered or simply delays them=20 > (packetloss over UDP for example)), it will apply the delta=20 > in N4 to the wrong full state document (N1 instead of N3).=20 Actually it wouldn't because of "version" handling. Section 4.5 applies here. But in any case this kind of behavior is quite bad as it might result in frequent subscription refreshes to obtain full presence state. More below. > We > can preserve the properties of the existing system is we > forbid sending a NOTIFY with a document with state=3D"partial"=20 > when any other NOTIFY transaction is still in progress on this dialog. This is a good point. Your proposed solution should work. This may cause some extra implementation effort for PA but I cannot see any way around this. If no other comments are received I will add text forbidding sending a NOTIFY with a document with state=3D"partial" (version=3D0) = when any other NOTIFY transaction is still in progress on this dialog.=20 > Section 4.5 of partial-notify says "If the watcher receives a > presence document whose "version" attribute value (is) higher=20 > by more than one with the locally stored value, the watcher=20 > assumes that one or more NOTIFYs were lost. The watcher=20 > SHOULD either refresh the subscription=20 > in order to receive a full presence document or terminate the=20 > subscription." Why is that SHOULD? In what scenario is any=20 > other course of action reasonable? (The only one I can think=20 > of is _if_ we allow overlapping partial NOTIFYs, then the=20 > watcher can wait around for awhile for the gaps to fill in -=20 > if we allow this, then we need to explicitly state this as=20 > why the above is SHOULD, not MUST. However, I think this=20 > should be a MUST.) Well, there probably isn't any good cases where watcher wouldn't terminate or refresh subscription. Changing SHOULD to MUST should provide more consistent behavior. =20 > Just below that, there's a "SHOULD discard the document" if=20 > it gets a partial notification with a lower version number. I=20 > don't see how this is right at all, and suggest that this=20 > MUST trigger a refresh or termination instead. (We wouldn't=20 > get to this logic if a NOTIFY was reordered and arrived late=20 > - the CSeq processing logic would=20 > have caught it). Right, and if we don't allow sending new NOTIFYs if there is a pending transaction then I believe reordering should never happen. But if in this situation watcher receives a presence document with lower version number there should be no harm in discarding it because it already has a consistent presence state. This is more or less an error case which probably should never happen but I think there is no need to refresh or terminate the subscription. - Mikko > I'll send a separate message on the Security Considerations=20 > section for -partial-notify. >=20 > RjS >=20 >=20 > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > This is a Working Group Last call on the following drafts: > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-> ietf-simple-partial-notify-0 > > 2.txt > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- pidf-format-01.txt >=20 > This abbreviated WGLC will end on Wednesday, April 28. >=20 > These drafts went through a previous last call at the beginning of=20 > March. These versions reflect changes due to comments received during=20 > that period. See=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > 519.html > for details. >=20 > Please send comments to the list, copying the editor. If you reviewed=20 > the draft and found no issues, please indicate so on the list. >=20 > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 26 16:59:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21108 for ; Mon, 26 Apr 2004 16:59:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDC5-0002K9-IN for simple-archive@ietf.org; Mon, 26 Apr 2004 16:59:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID3f-0000pb-00 for simple-archive@ietf.org; Mon, 26 Apr 2004 16:50:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BICsk-0006Uw-00; Mon, 26 Apr 2004 16:39:14 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BICsl-0001VV-4h; Mon, 26 Apr 2004 16:39:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBte-00019j-4x; Mon, 26 Apr 2004 15:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBoq-0000HL-9z for simple@optimus.ietf.org; Mon, 26 Apr 2004 15:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13600 for ; Mon, 26 Apr 2004 15:31:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBoo-0001GW-VO for simple@ietf.org; Mon, 26 Apr 2004 15:31:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBnv-0001Ey-00 for simple@ietf.org; Mon, 26 Apr 2004 15:30:12 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BIBnj-0001DC-00 for simple@ietf.org; Mon, 26 Apr 2004 15:30:00 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3QJSj6r017207; Mon, 26 Apr 2004 14:28:45 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Mikko Lonnfors , simple@ietf.org In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE94@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE94@esebe004.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083007734.10451.80.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 14:28:54 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit (private reply to avoid confusion on the list - we'll go back there after we get closer on this question) > > 3261 currently allows overlapping non-INVITE transactions inside a > > dialog (there's an open issue suggesting this might be a bad thing, > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither > > 3265 or simple-presence prohibit overlapping NOTIFYs. For > > full state documents, having multiple outstanding NOTIFYs is > > probably manageable. For partial state documents, at least as > > they are specified here, it could be disastrous. Consider > > four notifies N1(full), N2(partial), N3(full), N4(partial). > > If the recipient receives only N1 and N4 (something prevents > > N2 and N3 from being delivered or simply delays them > > (packetloss over UDP for example)), it will apply the delta > > in N4 to the wrong full state document (N1 instead of N3). > > Actually it wouldn't because of "version" handling. Section 4.5 applies > here. But in any case this kind of behavior is quite bad as it might > result in frequent subscription refreshes to obtain full presence state. How does version help here? The recipient has seen exactly two documents, the first with version=0 (which happens to be N1) and the second has version=1 (which happens to be N4). The recipient has no way to know it missed N2 and N3. I don't see how version as it's defined helps you at all in this case. We'll need something like the proposal to forbid the possibility of overlaps to prevent it. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 26 17:25:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24574 for ; Mon, 26 Apr 2004 17:25:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDTi-0006pc-VW for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 17:17:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLHQGf026249 for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 17:17:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDC8-0002RI-DT for simple-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 16:59:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21127 for ; Mon, 26 Apr 2004 16:59:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDC6-0002KP-BZ for simple-web-archive@ietf.org; Mon, 26 Apr 2004 16:59:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID3g-0000po-00 for simple-web-archive@ietf.org; Mon, 26 Apr 2004 16:50:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BICsk-0006Uw-00; Mon, 26 Apr 2004 16:39:14 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BICsl-0001VV-4h; Mon, 26 Apr 2004 16:39:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBte-00019j-4x; Mon, 26 Apr 2004 15:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBoq-0000HL-9z for simple@optimus.ietf.org; Mon, 26 Apr 2004 15:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13600 for ; Mon, 26 Apr 2004 15:31:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBoo-0001GW-VO for simple@ietf.org; Mon, 26 Apr 2004 15:31:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBnv-0001Ey-00 for simple@ietf.org; Mon, 26 Apr 2004 15:30:12 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BIBnj-0001DC-00 for simple@ietf.org; Mon, 26 Apr 2004 15:30:00 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3QJSj6r017207; Mon, 26 Apr 2004 14:28:45 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Mikko Lonnfors , simple@ietf.org In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE94@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE94@esebe004.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083007734.10451.80.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 14:28:54 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (private reply to avoid confusion on the list - we'll go back there after we get closer on this question) > > 3261 currently allows overlapping non-INVITE transactions inside a > > dialog (there's an open issue suggesting this might be a bad thing, > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither > > 3265 or simple-presence prohibit overlapping NOTIFYs. For > > full state documents, having multiple outstanding NOTIFYs is > > probably manageable. For partial state documents, at least as > > they are specified here, it could be disastrous. Consider > > four notifies N1(full), N2(partial), N3(full), N4(partial). > > If the recipient receives only N1 and N4 (something prevents > > N2 and N3 from being delivered or simply delays them > > (packetloss over UDP for example)), it will apply the delta > > in N4 to the wrong full state document (N1 instead of N3). > > Actually it wouldn't because of "version" handling. Section 4.5 applies > here. But in any case this kind of behavior is quite bad as it might > result in frequent subscription refreshes to obtain full presence state. How does version help here? The recipient has seen exactly two documents, the first with version=0 (which happens to be N1) and the second has version=1 (which happens to be N4). The recipient has no way to know it missed N2 and N3. I don't see how version as it's defined helps you at all in this case. We'll need something like the proposal to forbid the possibility of overlaps to prevent it. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Apr 26 17:32:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25312 for ; Mon, 26 Apr 2004 17:32:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDi7-0006La-KY for simple-archive@ietf.org; Mon, 26 Apr 2004 17:32:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDhD-0006IA-00 for simple-archive@ietf.org; Mon, 26 Apr 2004 17:31:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDgf-0006FF-00; Mon, 26 Apr 2004 17:30:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDYg-0000o0-7W; Mon, 26 Apr 2004 17:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDGx-0003i7-Iy for simple@optimus.ietf.org; Mon, 26 Apr 2004 17:04:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22181 for ; Mon, 26 Apr 2004 17:04:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDGv-0003BH-DQ for simple@ietf.org; Mon, 26 Apr 2004 17:04:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDBA-00027t-00 for simple@ietf.org; Mon, 26 Apr 2004 16:58:17 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BID2J-0000Ui-00 for simple@ietf.org; Mon, 26 Apr 2004 16:49:07 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3QKlq6r017345; Mon, 26 Apr 2004 15:47:52 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Mikko Lonnfors Cc: simple@ietf.org In-Reply-To: <1083007734.10451.80.camel@localhost.localdomain> References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE94@esebe004.ntc.nokia.com> <1083007734.10451.80.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1083012481.10451.116.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 15:48:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Well - I had _intended_ that to go to just Mikko. Sorry for the extra noise on the list. RjS On Mon, 2004-04-26 at 14:28, Robert Sparks wrote: > (private reply to avoid confusion on the list - we'll go > back there after we get closer on this question) > > > > 3261 currently allows overlapping non-INVITE transactions inside a > > > dialog (there's an open issue suggesting this might be a bad thing, > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For > > > full state documents, having multiple outstanding NOTIFYs is > > > probably manageable. For partial state documents, at least as > > > they are specified here, it could be disastrous. Consider > > > four notifies N1(full), N2(partial), N3(full), N4(partial). > > > If the recipient receives only N1 and N4 (something prevents > > > N2 and N3 from being delivered or simply delays them > > > (packetloss over UDP for example)), it will apply the delta > > > in N4 to the wrong full state document (N1 instead of N3). > > > > Actually it wouldn't because of "version" handling. Section 4.5 applies > > here. But in any case this kind of behavior is quite bad as it might > > result in frequent subscription refreshes to obtain full presence state. > > How does version help here? The recipient has seen exactly > two documents, the first with version=0 (which happens to > be N1) and the second has version=1 (which happens to be > N4). The recipient has no way to know it missed N2 and > N3. > > I don't see how version as it's defined helps you at all in this > case. We'll need something like the proposal to forbid the > possibility of overlaps to prevent it. > > RjS > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Apr 26 17:58:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26806 for ; Mon, 26 Apr 2004 17:58:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDus-0006Jn-77 for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 17:45:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLjUM4024279 for simple-archive@odin.ietf.org; Mon, 26 Apr 2004 17:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDiA-00034h-L4 for simple-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:32:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25331 for ; Mon, 26 Apr 2004 17:32:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDi8-0006Lg-9W for simple-web-archive@ietf.org; Mon, 26 Apr 2004 17:32:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDhE-0006IH-00 for simple-web-archive@ietf.org; Mon, 26 Apr 2004 17:31:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDgf-0006FF-00; Mon, 26 Apr 2004 17:30:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDYg-0000o0-7W; Mon, 26 Apr 2004 17:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDGx-0003i7-Iy for simple@optimus.ietf.org; Mon, 26 Apr 2004 17:04:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22181 for ; Mon, 26 Apr 2004 17:04:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDGv-0003BH-DQ for simple@ietf.org; Mon, 26 Apr 2004 17:04:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDBA-00027t-00 for simple@ietf.org; Mon, 26 Apr 2004 16:58:17 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BID2J-0000Ui-00 for simple@ietf.org; Mon, 26 Apr 2004 16:49:07 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3QKlq6r017345; Mon, 26 Apr 2004 15:47:52 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Mikko Lonnfors Cc: simple@ietf.org In-Reply-To: <1083007734.10451.80.camel@localhost.localdomain> References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE94@esebe004.ntc.nokia.com> <1083007734.10451.80.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1083012481.10451.116.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 15:48:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well - I had _intended_ that to go to just Mikko. Sorry for the extra noise on the list. RjS On Mon, 2004-04-26 at 14:28, Robert Sparks wrote: > (private reply to avoid confusion on the list - we'll go > back there after we get closer on this question) > > > > 3261 currently allows overlapping non-INVITE transactions inside a > > > dialog (there's an open issue suggesting this might be a bad thing, > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For > > > full state documents, having multiple outstanding NOTIFYs is > > > probably manageable. For partial state documents, at least as > > > they are specified here, it could be disastrous. Consider > > > four notifies N1(full), N2(partial), N3(full), N4(partial). > > > If the recipient receives only N1 and N4 (something prevents > > > N2 and N3 from being delivered or simply delays them > > > (packetloss over UDP for example)), it will apply the delta > > > in N4 to the wrong full state document (N1 instead of N3). > > > > Actually it wouldn't because of "version" handling. Section 4.5 applies > > here. But in any case this kind of behavior is quite bad as it might > > result in frequent subscription refreshes to obtain full presence state. > > How does version help here? The recipient has seen exactly > two documents, the first with version=0 (which happens to > be N1) and the second has version=1 (which happens to be > N4). The recipient has no way to know it missed N2 and > N3. > > I don't see how version as it's defined helps you at all in this > case. We'll need something like the proposal to forbid the > possibility of overlaps to prevent it. > > RjS > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 02:40:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07855 for ; Tue, 27 Apr 2004 02:40:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMGk-00079J-1w for simple-archive@ietf.org; Tue, 27 Apr 2004 02:40:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMFp-00070G-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 02:39:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIMF9-0006rG-00; Tue, 27 Apr 2004 02:38:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIM9N-0008Jg-I1; Tue, 27 Apr 2004 02:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIM59-0007rH-4Z for simple@optimus.ietf.org; Tue, 27 Apr 2004 02:28:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07092 for ; Tue, 27 Apr 2004 02:28:35 -0400 (EDT) From: mikko.lonnfors@Nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIM55-0004uK-Ea for simple@ietf.org; Tue, 27 Apr 2004 02:28:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIM48-0004m1-00 for simple@ietf.org; Tue, 27 Apr 2004 02:27:36 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIM3E-0004eD-00 for simple@ietf.org; Tue, 27 Apr 2004 02:26:40 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R6QeG06667 for ; Tue, 27 Apr 2004 09:26:40 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 09:26:20 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3R6QKt8019103 for ; Tue, 27 Apr 2004 09:26:20 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00P2mK7A; Tue, 27 Apr 2004 09:26:19 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R6QCF13668 for ; Tue, 27 Apr 2004 09:26:12 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 09:26:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Open issues and changes to prescaps Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17303@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Open issues and changes to prescaps Thread-Index: AcQnhl6CB6fHHHY+SBy4y+j88Sx6CgEmastA To: X-OriginalArrivalTime: 27 Apr 2004 06:26:09.0994 (UTC) FILETIME=[87AB42A0:01C42C20] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 09:26:09 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > Hi, >=20 > Here is a list of open issues and changes that were agreed in=20 > Seoul. If I have missed something please let me know. We=20 > should get consensus on open issue(s) quite soon (hopefully=20 > within a week or so).=20 >=20 > Open issues: > - Extension mechanism. Currently draft contains two extension=20 > mechanisms. One is XML extension mechanism (mechanism 1) and=20 > the other one is based on XML elements token, string,=20 > boolean, and numeric which allow usage of other tags that are=20 > not specified in callee caps (mechanism 2). We have had some=20 > list discussion about this topic and below I try summarize=20 > discussion so far: Arguments for having mechanism 2 have been=20 > that for some applications it might be easier to use. Using=20 > this mechanism applications would not need to define new XML=20 > namespaces for every new attribute. For applications which=20 > can 'dynamically' use or come up with new attributes this=20 > mechanism would be good. Argument for having only XML=20 > extension mechanism have been that for having two extension=20 > mechanisms may lead to some inconsistencies like same=20 > extension attribute could be applied using both mechanisms=20 > simultaneously. It has also being argued that applications=20 > cannot or should not use new attributes unless their=20 > semantics has been clearly defined. Also mechanism 1 may have=20 > some problems with presence authorization and filtering.=20 So far I have received no comments about this. If somebody wants to keep the XML element (token, string, boolean, numeric) based extension mechanism please indicate that promptly. Otherwise it will be removed from the next revision.=20 - Mikko > Personally I think we can live with only XML extension=20 > mechanism (mechanism 1). For applications that would like to=20 > use extension tag this means defining a new XML schema.=20 > However, this may be a good thing because applications must=20 > in any case define some kind of semantics for new attributes=20 > and as far as I know this doesn't need to involve any standardization. >=20 > Changes: > - remove elements from all media type tags (voice,=20 > video, application, data, control, text) and change these to=20 > be of boolean type >=20 > - Add separate element into XML schema >=20 > - Remove text from section 5 which talks about adding=20 > Accept-Contact header based on prescaps into SIP requests. >=20 >=20 > - Mikko >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 02:52:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08807 for ; Tue, 27 Apr 2004 02:52:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMKt-0001xe-8D for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 02:44:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R6it9d007534 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 02:44:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMGo-0001Ad-JF for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 02:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07873 for ; Tue, 27 Apr 2004 02:40:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMGk-00079P-OU for simple-web-archive@ietf.org; Tue, 27 Apr 2004 02:40:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMFq-00070O-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 02:39:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIMF9-0006rG-00; Tue, 27 Apr 2004 02:38:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIM9N-0008Jg-I1; Tue, 27 Apr 2004 02:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIM59-0007rH-4Z for simple@optimus.ietf.org; Tue, 27 Apr 2004 02:28:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07092 for ; Tue, 27 Apr 2004 02:28:35 -0400 (EDT) From: mikko.lonnfors@Nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIM55-0004uK-Ea for simple@ietf.org; Tue, 27 Apr 2004 02:28:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIM48-0004m1-00 for simple@ietf.org; Tue, 27 Apr 2004 02:27:36 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIM3E-0004eD-00 for simple@ietf.org; Tue, 27 Apr 2004 02:26:40 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R6QeG06667 for ; Tue, 27 Apr 2004 09:26:40 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 09:26:20 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3R6QKt8019103 for ; Tue, 27 Apr 2004 09:26:20 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00P2mK7A; Tue, 27 Apr 2004 09:26:19 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R6QCF13668 for ; Tue, 27 Apr 2004 09:26:12 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 09:26:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Open issues and changes to prescaps Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17303@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Open issues and changes to prescaps Thread-Index: AcQnhl6CB6fHHHY+SBy4y+j88Sx6CgEmastA To: X-OriginalArrivalTime: 27 Apr 2004 06:26:09.0994 (UTC) FILETIME=[87AB42A0:01C42C20] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 09:26:09 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Hi, >=20 > Here is a list of open issues and changes that were agreed in=20 > Seoul. If I have missed something please let me know. We=20 > should get consensus on open issue(s) quite soon (hopefully=20 > within a week or so).=20 >=20 > Open issues: > - Extension mechanism. Currently draft contains two extension=20 > mechanisms. One is XML extension mechanism (mechanism 1) and=20 > the other one is based on XML elements token, string,=20 > boolean, and numeric which allow usage of other tags that are=20 > not specified in callee caps (mechanism 2). We have had some=20 > list discussion about this topic and below I try summarize=20 > discussion so far: Arguments for having mechanism 2 have been=20 > that for some applications it might be easier to use. Using=20 > this mechanism applications would not need to define new XML=20 > namespaces for every new attribute. For applications which=20 > can 'dynamically' use or come up with new attributes this=20 > mechanism would be good. Argument for having only XML=20 > extension mechanism have been that for having two extension=20 > mechanisms may lead to some inconsistencies like same=20 > extension attribute could be applied using both mechanisms=20 > simultaneously. It has also being argued that applications=20 > cannot or should not use new attributes unless their=20 > semantics has been clearly defined. Also mechanism 1 may have=20 > some problems with presence authorization and filtering.=20 So far I have received no comments about this. If somebody wants to keep the XML element (token, string, boolean, numeric) based extension mechanism please indicate that promptly. Otherwise it will be removed from the next revision.=20 - Mikko > Personally I think we can live with only XML extension=20 > mechanism (mechanism 1). For applications that would like to=20 > use extension tag this means defining a new XML schema.=20 > However, this may be a good thing because applications must=20 > in any case define some kind of semantics for new attributes=20 > and as far as I know this doesn't need to involve any standardization. >=20 > Changes: > - remove elements from all media type tags (voice,=20 > video, application, data, control, text) and change these to=20 > be of boolean type >=20 > - Add separate element into XML schema >=20 > - Remove text from section 5 which talks about adding=20 > Accept-Contact header based on prescaps into SIP requests. >=20 >=20 > - Mikko >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 05:53:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17577 for ; Tue, 27 Apr 2004 05:53:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPHm-0004uM-NN for simple-archive@ietf.org; Tue, 27 Apr 2004 05:53:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPGj-0004fs-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 05:52:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPFm-0004Ty-00; Tue, 27 Apr 2004 05:51:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP7H-0000E2-JK; Tue, 27 Apr 2004 05:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP1G-0007Im-MN for simple@optimus.ietf.org; Tue, 27 Apr 2004 05:36:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16790 for ; Tue, 27 Apr 2004 05:36:46 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIP1D-0001WY-1Y for simple@ietf.org; Tue, 27 Apr 2004 05:36:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIP0K-0001La-00 for simple@ietf.org; Tue, 27 Apr 2004 05:35:53 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIP03-0001AZ-00 for simple@ietf.org; Tue, 27 Apr 2004 05:35:35 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9ZVG12365; Tue, 27 Apr 2004 12:35:31 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 12:34:16 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3R9YGe7022827; Tue, 27 Apr 2004 12:34:16 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00RSTjsD; Tue, 27 Apr 2004 12:33:44 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9XeH11681; Tue, 27 Apr 2004 12:33:41 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 12:33:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979A8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNA= To: , , X-OriginalArrivalTime: 27 Apr 2004 09:33:40.0972 (UTC) FILETIME=[B9C642C0:01C42C3A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 12:33:40 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Here is an example where both state and version are needed: PA sends N1(full), N2(full), N3(partial). If the version is set to 0 everytime there is full state, and N2 was = never received, the subscriber would then think that N3 is a partial of = N1. To solve this, you need the version to continuously increase by 1, even = when a full state is being sent. You would then also need the state = attribute to indicate full/partial. The version is used by the = subscriber to learn that a NOTIFY was not received (N2). /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext mikko.lonnfors@nokia.com > Sent: 26.April.2004 22:17 > To: rsparks@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Hi, >=20 > Thanks for comments. Responses inline: >=20 > > Writing as a WG member - not as chair - > >=20 > > I've sent a list of typo level nits in these drafts to=20 > Mikko privately >=20 > > - > >=20 > > While doing a nit review, I found some things that should have=20 > > received list attention earlier. > >=20 > > In section 4.4 of -partial-notify it says "The PA SHOULD=20 > construct the >=20 > > partial presence document according to the following=20 > logic:" followed=20 > > by a bunch of MUST level statements. Why is that SHOULD there? What=20 > > would it mean to violate it? I suggest striking it and=20 > simply saying=20 > > "The PA constructs" >=20 > Yes, SHOULD is probably useless and confusing here. I will remove it. >=20 > > Why do we have both "state" and "version"? As defined in=20 > these drafts, >=20 > > state=3Dfull if and only if version=3D0. You could delete the state=20 > > parameter with no loss of information, so why is it there? >=20 > I believe the original need for the "state" was that the=20 > "version" could > be initialized to some random value. Now, if "version" is always > initialized to 0 there is no need for the "state" attribute. Both > solutions should work and if nobody else comments otherwise I will > remove the "state" attribute. >=20 > > 3261 currently allows overlapping non-INVITE transactions inside a=20 > > dialog (there's an open issue suggesting this might be a bad thing,=20 > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > full state documents, having multiple outstanding NOTIFYs is=20 > > probably manageable. For partial state documents, at least as=20 > > they are specified here, it could be disastrous. Consider=20 > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > If the recipient receives only N1 and N4 (something prevents=20 > > N2 and N3 from being delivered or simply delays them=20 > > (packetloss over UDP for example)), it will apply the delta=20 > > in N4 to the wrong full state document (N1 instead of N3).=20 >=20 > Actually it wouldn't because of "version" handling. Section=20 > 4.5 applies > here. But in any case this kind of behavior is quite bad as it might > result in frequent subscription refreshes to obtain full=20 > presence state. > More below. >=20 > > We > > can preserve the properties of the existing system is we > > forbid sending a NOTIFY with a document with state=3D"partial"=20 > > when any other NOTIFY transaction is still in progress on=20 > this dialog. >=20 > This is a good point. Your proposed solution should work.=20 > This may cause > some extra implementation effort for PA but I cannot see any=20 > way around > this. If no other comments are received I will add text forbidding > sending a NOTIFY with a document with state=3D"partial" (version=3D0) = when > any other NOTIFY transaction is still in progress on this dialog.=20 >=20 > > Section 4.5 of partial-notify says "If the watcher receives a > > presence document whose "version" attribute value (is) higher=20 > > by more than one with the locally stored value, the watcher=20 > > assumes that one or more NOTIFYs were lost. The watcher=20 > > SHOULD either refresh the subscription=20 > > in order to receive a full presence document or terminate the=20 > > subscription." Why is that SHOULD? In what scenario is any=20 > > other course of action reasonable? (The only one I can think=20 > > of is _if_ we allow overlapping partial NOTIFYs, then the=20 > > watcher can wait around for awhile for the gaps to fill in -=20 > > if we allow this, then we need to explicitly state this as=20 > > why the above is SHOULD, not MUST. However, I think this=20 > > should be a MUST.) >=20 > Well, there probably isn't any good cases where watcher wouldn't > terminate or refresh subscription. Changing SHOULD to MUST should > provide more consistent behavior. > =20 > > Just below that, there's a "SHOULD discard the document" if=20 > > it gets a partial notification with a lower version number. I=20 > > don't see how this is right at all, and suggest that this=20 > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > get to this logic if a NOTIFY was reordered and arrived late=20 > > - the CSeq processing logic would=20 > > have caught it). >=20 > Right, and if we don't allow sending new NOTIFYs if there is a pending > transaction then I believe reordering should never happen. But if in > this situation watcher receives a presence document with lower version > number there should be no harm in discarding it because it=20 > already has a > consistent presence state. This is more or less an error case which > probably should never happen but I think there is no need to=20 > refresh or > terminate the subscription. >=20 > - Mikko >=20 > > I'll send a separate message on the Security Considerations=20 > > section for -partial-notify. > >=20 > > RjS > >=20 > >=20 > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > This is a Working Group Last call on the following drafts: > > >=20 > > >=20 > > http://www.ietf.org/internet-drafts/draft-> > ietf-simple-partial-notify-0 > > > 2.txt > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > pidf-format-01.txt > >=20 > > This abbreviated WGLC will end on Wednesday, April 28. > >=20 > > These drafts went through a previous last call at the beginning of=20 > > March. These versions reflect changes due to comments=20 > received during=20 > > that period. See=20 > >=20 https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > 519.html > for details. >=20 > Please send comments to the list, copying the editor. If you reviewed=20 > the draft and found no issues, please indicate so on the list. >=20 > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 05:55:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17725 for ; Tue, 27 Apr 2004 05:55:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPJ9-0005Bn-Qq for simple-archive@ietf.org; Tue, 27 Apr 2004 05:55:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPI6-0004xC-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 05:54:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPHP-0004il-00; Tue, 27 Apr 2004 05:53:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP9D-0000W9-4P; Tue, 27 Apr 2004 05:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP4J-0008CC-99 for simple@optimus.ietf.org; Tue, 27 Apr 2004 05:39:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16957 for ; Tue, 27 Apr 2004 05:39:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIP4F-00027Q-Pw for simple@ietf.org; Tue, 27 Apr 2004 05:39:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIP3G-0001vZ-00 for simple@ietf.org; Tue, 27 Apr 2004 05:38:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIP2t-0001k2-00 for simple@ietf.org; Tue, 27 Apr 2004 05:38:31 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9cRv16015; Tue, 27 Apr 2004 12:38:27 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 12:37:13 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3R9bDUc006967; Tue, 27 Apr 2004 12:37:13 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00yHSnAL; Tue, 27 Apr 2004 12:36:50 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9aoH07311; Tue, 27 Apr 2004 12:36:50 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 12:36:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979A9@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQrzqaK+ttVAQtERBOvC6cZWCT1/wAbBTfw To: , , X-OriginalArrivalTime: 27 Apr 2004 09:36:43.0400 (UTC) FILETIME=[26829080:01C42C3B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 12:36:42 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable If the version handling goes as I described in my other email, then it = should solve this problem. N1(full, v=3D0), N4(partial, v=3D4). The subscriber realises that there = are 2 notifications missing and does not accept N4. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Robert Sparks > Sent: 26.April.2004 22:29 > To: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > (private reply to avoid confusion on the list - we'll go > back there after we get closer on this question) >=20 > > > 3261 currently allows overlapping non-INVITE transactions=20 > inside a=20 > > > dialog (there's an open issue suggesting this might be a=20 > bad thing,=20 > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > probably manageable. For partial state documents, at least as=20 > > > they are specified here, it could be disastrous. Consider=20 > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > If the recipient receives only N1 and N4 (something prevents=20 > > > N2 and N3 from being delivered or simply delays them=20 > > > (packetloss over UDP for example)), it will apply the delta=20 > > > in N4 to the wrong full state document (N1 instead of N3).=20 > >=20 > > Actually it wouldn't because of "version" handling. Section=20 > 4.5 applies > > here. But in any case this kind of behavior is quite bad as it might > > result in frequent subscription refreshes to obtain full=20 > presence state. >=20 > How does version help here? The recipient has seen exactly > two documents, the first with version=3D0 (which happens to > be N1) and the second has version=3D1 (which happens to be > N4). The recipient has no way to know it missed N2 and > N3.=20 >=20 > I don't see how version as it's defined helps you at all in this=20 > case. We'll need something like the proposal to forbid the > possibility of overlaps to prevent it. >=20 > RjS >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 06:11:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19344 for ; Tue, 27 Apr 2004 06:11:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPNt-0002xT-TH for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 06:00:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RA0DlM011354 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 06:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPHq-0001qa-VO for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 05:53:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17597 for ; Tue, 27 Apr 2004 05:53:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPHn-0004uR-Fo for simple-web-archive@ietf.org; Tue, 27 Apr 2004 05:53:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPGk-0004fz-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 05:52:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPFm-0004Ty-00; Tue, 27 Apr 2004 05:51:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP7H-0000E2-JK; Tue, 27 Apr 2004 05:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP1G-0007Im-MN for simple@optimus.ietf.org; Tue, 27 Apr 2004 05:36:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16790 for ; Tue, 27 Apr 2004 05:36:46 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIP1D-0001WY-1Y for simple@ietf.org; Tue, 27 Apr 2004 05:36:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIP0K-0001La-00 for simple@ietf.org; Tue, 27 Apr 2004 05:35:53 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIP03-0001AZ-00 for simple@ietf.org; Tue, 27 Apr 2004 05:35:35 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9ZVG12365; Tue, 27 Apr 2004 12:35:31 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 12:34:16 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3R9YGe7022827; Tue, 27 Apr 2004 12:34:16 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00RSTjsD; Tue, 27 Apr 2004 12:33:44 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9XeH11681; Tue, 27 Apr 2004 12:33:41 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 12:33:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979A8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNA= To: , , X-OriginalArrivalTime: 27 Apr 2004 09:33:40.0972 (UTC) FILETIME=[B9C642C0:01C42C3A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 12:33:40 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is an example where both state and version are needed: PA sends N1(full), N2(full), N3(partial). If the version is set to 0 everytime there is full state, and N2 was = never received, the subscriber would then think that N3 is a partial of = N1. To solve this, you need the version to continuously increase by 1, even = when a full state is being sent. You would then also need the state = attribute to indicate full/partial. The version is used by the = subscriber to learn that a NOTIFY was not received (N2). /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext mikko.lonnfors@nokia.com > Sent: 26.April.2004 22:17 > To: rsparks@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Hi, >=20 > Thanks for comments. Responses inline: >=20 > > Writing as a WG member - not as chair - > >=20 > > I've sent a list of typo level nits in these drafts to=20 > Mikko privately >=20 > > - > >=20 > > While doing a nit review, I found some things that should have=20 > > received list attention earlier. > >=20 > > In section 4.4 of -partial-notify it says "The PA SHOULD=20 > construct the >=20 > > partial presence document according to the following=20 > logic:" followed=20 > > by a bunch of MUST level statements. Why is that SHOULD there? What=20 > > would it mean to violate it? I suggest striking it and=20 > simply saying=20 > > "The PA constructs" >=20 > Yes, SHOULD is probably useless and confusing here. I will remove it. >=20 > > Why do we have both "state" and "version"? As defined in=20 > these drafts, >=20 > > state=3Dfull if and only if version=3D0. You could delete the state=20 > > parameter with no loss of information, so why is it there? >=20 > I believe the original need for the "state" was that the=20 > "version" could > be initialized to some random value. Now, if "version" is always > initialized to 0 there is no need for the "state" attribute. Both > solutions should work and if nobody else comments otherwise I will > remove the "state" attribute. >=20 > > 3261 currently allows overlapping non-INVITE transactions inside a=20 > > dialog (there's an open issue suggesting this might be a bad thing,=20 > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > full state documents, having multiple outstanding NOTIFYs is=20 > > probably manageable. For partial state documents, at least as=20 > > they are specified here, it could be disastrous. Consider=20 > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > If the recipient receives only N1 and N4 (something prevents=20 > > N2 and N3 from being delivered or simply delays them=20 > > (packetloss over UDP for example)), it will apply the delta=20 > > in N4 to the wrong full state document (N1 instead of N3).=20 >=20 > Actually it wouldn't because of "version" handling. Section=20 > 4.5 applies > here. But in any case this kind of behavior is quite bad as it might > result in frequent subscription refreshes to obtain full=20 > presence state. > More below. >=20 > > We > > can preserve the properties of the existing system is we > > forbid sending a NOTIFY with a document with state=3D"partial"=20 > > when any other NOTIFY transaction is still in progress on=20 > this dialog. >=20 > This is a good point. Your proposed solution should work.=20 > This may cause > some extra implementation effort for PA but I cannot see any=20 > way around > this. If no other comments are received I will add text forbidding > sending a NOTIFY with a document with state=3D"partial" (version=3D0) = when > any other NOTIFY transaction is still in progress on this dialog.=20 >=20 > > Section 4.5 of partial-notify says "If the watcher receives a > > presence document whose "version" attribute value (is) higher=20 > > by more than one with the locally stored value, the watcher=20 > > assumes that one or more NOTIFYs were lost. The watcher=20 > > SHOULD either refresh the subscription=20 > > in order to receive a full presence document or terminate the=20 > > subscription." Why is that SHOULD? In what scenario is any=20 > > other course of action reasonable? (The only one I can think=20 > > of is _if_ we allow overlapping partial NOTIFYs, then the=20 > > watcher can wait around for awhile for the gaps to fill in -=20 > > if we allow this, then we need to explicitly state this as=20 > > why the above is SHOULD, not MUST. However, I think this=20 > > should be a MUST.) >=20 > Well, there probably isn't any good cases where watcher wouldn't > terminate or refresh subscription. Changing SHOULD to MUST should > provide more consistent behavior. > =20 > > Just below that, there's a "SHOULD discard the document" if=20 > > it gets a partial notification with a lower version number. I=20 > > don't see how this is right at all, and suggest that this=20 > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > get to this logic if a NOTIFY was reordered and arrived late=20 > > - the CSeq processing logic would=20 > > have caught it). >=20 > Right, and if we don't allow sending new NOTIFYs if there is a pending > transaction then I believe reordering should never happen. But if in > this situation watcher receives a presence document with lower version > number there should be no harm in discarding it because it=20 > already has a > consistent presence state. This is more or less an error case which > probably should never happen but I think there is no need to=20 > refresh or > terminate the subscription. >=20 > - Mikko >=20 > > I'll send a separate message on the Security Considerations=20 > > section for -partial-notify. > >=20 > > RjS > >=20 > >=20 > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > This is a Working Group Last call on the following drafts: > > >=20 > > >=20 > > http://www.ietf.org/internet-drafts/draft-> > ietf-simple-partial-notify-0 > > > 2.txt > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > pidf-format-01.txt > >=20 > > This abbreviated WGLC will end on Wednesday, April 28. > >=20 > > These drafts went through a previous last call at the beginning of=20 > > March. These versions reflect changes due to comments=20 > received during=20 > > that period. See=20 > >=20 https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > 519.html > for details. >=20 > Please send comments to the list, copying the editor. If you reviewed=20 > the draft and found no issues, please indicate so on the list. >=20 > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 06:13:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19404 for ; Tue, 27 Apr 2004 06:13:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPaO-0001Oh-UQ for simple-archive@ietf.org; Tue, 27 Apr 2004 06:13:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPZI-00018d-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 06:12:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPYQ-0000vG-00; Tue, 27 Apr 2004 06:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPNn-0002v8-0P; Tue, 27 Apr 2004 06:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPFi-0001Ux-8n for simple@optimus.ietf.org; Tue, 27 Apr 2004 05:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17465 for ; Tue, 27 Apr 2004 05:51:42 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPFe-0004Sg-Mf for simple@ietf.org; Tue, 27 Apr 2004 05:51:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPEh-0004HF-00 for simple@ietf.org; Tue, 27 Apr 2004 05:50:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BIPDp-00045h-00 for simple@ietf.org; Tue, 27 Apr 2004 05:49:54 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9niJ01328; Tue, 27 Apr 2004 12:49:44 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 12:48:48 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3R9mm2o009560; Tue, 27 Apr 2004 12:48:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00YsWwUN; Tue, 27 Apr 2004 12:45:52 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9joH19181; Tue, 27 Apr 2004 12:45:50 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 12:45:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17307@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYA== To: , , X-OriginalArrivalTime: 27 Apr 2004 09:45:39.0604 (UTC) FILETIME=[661CCD40:01C42C3C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 12:45:38 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, > Here is an example where both state and version are needed: >=20 > PA sends N1(full), N2(full), N3(partial). >=20 > If the version is set to 0 everytime there is full state, and=20 > N2 was never received, the subscriber would then think that=20 > N3 is a partial of N1. >=20 > To solve this, you need the version to continuously increase=20 > by 1, even when a full state is being sent. You would then=20 > also need the state attribute to indicate full/partial. The=20 > version is used by the subscriber to learn that a NOTIFY was=20 > not received (N2). Ok, so your proposal is that "version" should be scoped with the subscription i.e. first NOTIFY within a subscription would have version=3D"0" and then it would be continuously increased by one for = every notifications (regardless if it contains full or partial state)? How should subscription refreshes be handled? If we have PA sends N1(full), N2(full), N3(partial) And N2 is lost watcher would refresh the subscription when it receives N3. Now Would the PA send N1(full, version=3D"0") or N4(full, version=3D"3")? - Mikko=20 > /Hisham >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > ext mikko.lonnfors@nokia.com > > Sent: 26.April.2004 22:17 > > To: rsparks@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Hi, > >=20 > > Thanks for comments. Responses inline: > >=20 > > > Writing as a WG member - not as chair - > > >=20 > > > I've sent a list of typo level nits in these drafts to > > Mikko privately > >=20 > > > - > > >=20 > > > While doing a nit review, I found some things that should have > > > received list attention earlier. > > >=20 > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > construct the > >=20 > > > partial presence document according to the following > > logic:" followed > > > by a bunch of MUST level statements. Why is that SHOULD=20 > there? What > > > would it mean to violate it? I suggest striking it and=20 > > simply saying > > > "The PA constructs" > >=20 > > Yes, SHOULD is probably useless and confusing here. I will=20 > remove it. > >=20 > > > Why do we have both "state" and "version"? As defined in > > these drafts, > >=20 > > > state=3Dfull if and only if version=3D0. You could delete the = state > > > parameter with no loss of information, so why is it there? > >=20 > > I believe the original need for the "state" was that the > > "version" could > > be initialized to some random value. Now, if "version" is always > > initialized to 0 there is no need for the "state" attribute. Both > > solutions should work and if nobody else comments otherwise I will > > remove the "state" attribute. > >=20 > > > 3261 currently allows overlapping non-INVITE transactions inside a > > > dialog (there's an open issue suggesting this might be a=20 > bad thing,=20 > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > probably manageable. For partial state documents, at least as=20 > > > they are specified here, it could be disastrous. Consider=20 > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > If the recipient receives only N1 and N4 (something prevents=20 > > > N2 and N3 from being delivered or simply delays them=20 > > > (packetloss over UDP for example)), it will apply the delta=20 > > > in N4 to the wrong full state document (N1 instead of N3).=20 > >=20 > > Actually it wouldn't because of "version" handling. Section > > 4.5 applies > > here. But in any case this kind of behavior is quite bad as it might > > result in frequent subscription refreshes to obtain full=20 > > presence state. > > More below. > >=20 > > > We > > > can preserve the properties of the existing system is we forbid=20 > > > sending a NOTIFY with a document with state=3D"partial"=20 > when any other=20 > > > NOTIFY transaction is still in progress on > > this dialog. > >=20 > > This is a good point. Your proposed solution should work. > > This may cause > > some extra implementation effort for PA but I cannot see any=20 > > way around > > this. If no other comments are received I will add text forbidding > > sending a NOTIFY with a document with state=3D"partial"=20 > (version=3D0) when > > any other NOTIFY transaction is still in progress on this dialog.=20 > >=20 > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > presence document whose "version" attribute value (is) higher by=20 > > > more than one with the locally stored value, the watcher assumes=20 > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > refresh the subscription in order to receive a full presence=20 > > > document or terminate the subscription." Why is that SHOULD? In=20 > > > what scenario is any other course of action reasonable? (The only=20 > > > one I can think of is _if_ we allow overlapping partial NOTIFYs,=20 > > > then the watcher can wait around for awhile for the gaps=20 > to fill in=20 > > > - if we allow this, then we need to explicitly state this as > > > why the above is SHOULD, not MUST. However, I think this=20 > > > should be a MUST.) > >=20 > > Well, there probably isn't any good cases where watcher wouldn't=20 > > terminate or refresh subscription. Changing SHOULD to MUST should=20 > > provide more consistent behavior. > > =20 > > > Just below that, there's a "SHOULD discard the document" if > > > it gets a partial notification with a lower version number. I=20 > > > don't see how this is right at all, and suggest that this=20 > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > - the CSeq processing logic would=20 > > > have caught it). > >=20 > > Right, and if we don't allow sending new NOTIFYs if there=20 > is a pending=20 > > transaction then I believe reordering should never happen.=20 > But if in=20 > > this situation watcher receives a presence document with=20 > lower version=20 > > number there should be no harm in discarding it because it=20 > already has=20 > > a consistent presence state. This is more or less an error=20 > case which > > probably should never happen but I think there is no need to=20 > > refresh or > > terminate the subscription. > >=20 > > - Mikko > >=20 > > > I'll send a separate message on the Security Considerations > > > section for -partial-notify. > > >=20 > > > RjS > > >=20 > > >=20 > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > This is a Working Group Last call on the following drafts: > > > >=20 > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-> > > ietf-simple-partial-notify-0 > > > > 2.txt > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > pidf-format-01.txt > > >=20 > > > This abbreviated WGLC will end on Wednesday, April 28. > > >=20 > > > These drafts went through a previous last call at the beginning of > > > March. These versions reflect changes due to comments=20 > > received during > > > that period. See > > >=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > >=20 > > Please send comments to the list, copying the editor. If=20 > you reviewed > > the draft and found no issues, please indicate so on the list. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 06:27:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20424 for ; Tue, 27 Apr 2004 06:27:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPdV-0006rK-Oz for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 06:16:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RAGLDV026362 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 06:16:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPaU-0005kB-TZ for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 06:13:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19422 for ; Tue, 27 Apr 2004 06:13:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPaR-0001P3-2r for simple-web-archive@ietf.org; Tue, 27 Apr 2004 06:13:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPZJ-00018o-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 06:12:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPYQ-0000vG-00; Tue, 27 Apr 2004 06:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPNn-0002v8-0P; Tue, 27 Apr 2004 06:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPFi-0001Ux-8n for simple@optimus.ietf.org; Tue, 27 Apr 2004 05:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17465 for ; Tue, 27 Apr 2004 05:51:42 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPFe-0004Sg-Mf for simple@ietf.org; Tue, 27 Apr 2004 05:51:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPEh-0004HF-00 for simple@ietf.org; Tue, 27 Apr 2004 05:50:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BIPDp-00045h-00 for simple@ietf.org; Tue, 27 Apr 2004 05:49:54 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9niJ01328; Tue, 27 Apr 2004 12:49:44 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 12:48:48 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3R9mm2o009560; Tue, 27 Apr 2004 12:48:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00YsWwUN; Tue, 27 Apr 2004 12:45:52 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9joH19181; Tue, 27 Apr 2004 12:45:50 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 12:45:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17307@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYA== To: , , X-OriginalArrivalTime: 27 Apr 2004 09:45:39.0604 (UTC) FILETIME=[661CCD40:01C42C3C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 12:45:38 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, > Here is an example where both state and version are needed: >=20 > PA sends N1(full), N2(full), N3(partial). >=20 > If the version is set to 0 everytime there is full state, and=20 > N2 was never received, the subscriber would then think that=20 > N3 is a partial of N1. >=20 > To solve this, you need the version to continuously increase=20 > by 1, even when a full state is being sent. You would then=20 > also need the state attribute to indicate full/partial. The=20 > version is used by the subscriber to learn that a NOTIFY was=20 > not received (N2). Ok, so your proposal is that "version" should be scoped with the subscription i.e. first NOTIFY within a subscription would have version=3D"0" and then it would be continuously increased by one for = every notifications (regardless if it contains full or partial state)? How should subscription refreshes be handled? If we have PA sends N1(full), N2(full), N3(partial) And N2 is lost watcher would refresh the subscription when it receives N3. Now Would the PA send N1(full, version=3D"0") or N4(full, version=3D"3")? - Mikko=20 > /Hisham >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > ext mikko.lonnfors@nokia.com > > Sent: 26.April.2004 22:17 > > To: rsparks@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Hi, > >=20 > > Thanks for comments. Responses inline: > >=20 > > > Writing as a WG member - not as chair - > > >=20 > > > I've sent a list of typo level nits in these drafts to > > Mikko privately > >=20 > > > - > > >=20 > > > While doing a nit review, I found some things that should have > > > received list attention earlier. > > >=20 > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > construct the > >=20 > > > partial presence document according to the following > > logic:" followed > > > by a bunch of MUST level statements. Why is that SHOULD=20 > there? What > > > would it mean to violate it? I suggest striking it and=20 > > simply saying > > > "The PA constructs" > >=20 > > Yes, SHOULD is probably useless and confusing here. I will=20 > remove it. > >=20 > > > Why do we have both "state" and "version"? As defined in > > these drafts, > >=20 > > > state=3Dfull if and only if version=3D0. You could delete the = state > > > parameter with no loss of information, so why is it there? > >=20 > > I believe the original need for the "state" was that the > > "version" could > > be initialized to some random value. Now, if "version" is always > > initialized to 0 there is no need for the "state" attribute. Both > > solutions should work and if nobody else comments otherwise I will > > remove the "state" attribute. > >=20 > > > 3261 currently allows overlapping non-INVITE transactions inside a > > > dialog (there's an open issue suggesting this might be a=20 > bad thing,=20 > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > probably manageable. For partial state documents, at least as=20 > > > they are specified here, it could be disastrous. Consider=20 > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > If the recipient receives only N1 and N4 (something prevents=20 > > > N2 and N3 from being delivered or simply delays them=20 > > > (packetloss over UDP for example)), it will apply the delta=20 > > > in N4 to the wrong full state document (N1 instead of N3).=20 > >=20 > > Actually it wouldn't because of "version" handling. Section > > 4.5 applies > > here. But in any case this kind of behavior is quite bad as it might > > result in frequent subscription refreshes to obtain full=20 > > presence state. > > More below. > >=20 > > > We > > > can preserve the properties of the existing system is we forbid=20 > > > sending a NOTIFY with a document with state=3D"partial"=20 > when any other=20 > > > NOTIFY transaction is still in progress on > > this dialog. > >=20 > > This is a good point. Your proposed solution should work. > > This may cause > > some extra implementation effort for PA but I cannot see any=20 > > way around > > this. If no other comments are received I will add text forbidding > > sending a NOTIFY with a document with state=3D"partial"=20 > (version=3D0) when > > any other NOTIFY transaction is still in progress on this dialog.=20 > >=20 > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > presence document whose "version" attribute value (is) higher by=20 > > > more than one with the locally stored value, the watcher assumes=20 > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > refresh the subscription in order to receive a full presence=20 > > > document or terminate the subscription." Why is that SHOULD? In=20 > > > what scenario is any other course of action reasonable? (The only=20 > > > one I can think of is _if_ we allow overlapping partial NOTIFYs,=20 > > > then the watcher can wait around for awhile for the gaps=20 > to fill in=20 > > > - if we allow this, then we need to explicitly state this as > > > why the above is SHOULD, not MUST. However, I think this=20 > > > should be a MUST.) > >=20 > > Well, there probably isn't any good cases where watcher wouldn't=20 > > terminate or refresh subscription. Changing SHOULD to MUST should=20 > > provide more consistent behavior. > > =20 > > > Just below that, there's a "SHOULD discard the document" if > > > it gets a partial notification with a lower version number. I=20 > > > don't see how this is right at all, and suggest that this=20 > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > - the CSeq processing logic would=20 > > > have caught it). > >=20 > > Right, and if we don't allow sending new NOTIFYs if there=20 > is a pending=20 > > transaction then I believe reordering should never happen.=20 > But if in=20 > > this situation watcher receives a presence document with=20 > lower version=20 > > number there should be no harm in discarding it because it=20 > already has=20 > > a consistent presence state. This is more or less an error=20 > case which > > probably should never happen but I think there is no need to=20 > > refresh or > > terminate the subscription. > >=20 > > - Mikko > >=20 > > > I'll send a separate message on the Security Considerations > > > section for -partial-notify. > > >=20 > > > RjS > > >=20 > > >=20 > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > This is a Working Group Last call on the following drafts: > > > >=20 > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-> > > ietf-simple-partial-notify-0 > > > > 2.txt > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > pidf-format-01.txt > > >=20 > > > This abbreviated WGLC will end on Wednesday, April 28. > > >=20 > > > These drafts went through a previous last call at the beginning of > > > March. These versions reflect changes due to comments=20 > > received during > > > that period. See > > >=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > >=20 > > Please send comments to the list, copying the editor. If=20 > you reviewed > > the draft and found no issues, please indicate so on the list. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 06:27:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20493 for ; Tue, 27 Apr 2004 06:27:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPog-0004lF-M6 for simple-archive@ietf.org; Tue, 27 Apr 2004 06:27:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPnp-0004XW-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 06:27:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPmm-0004Im-00; Tue, 27 Apr 2004 06:25:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPdF-0006n4-70; Tue, 27 Apr 2004 06:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPXE-0004XN-2N for simple@optimus.ietf.org; Tue, 27 Apr 2004 06:09:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19227 for ; Tue, 27 Apr 2004 06:09:47 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPXA-0000fv-3A for simple@ietf.org; Tue, 27 Apr 2004 06:09:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPWA-0000Sr-00 for simple@ietf.org; Tue, 27 Apr 2004 06:08:47 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIPVI-0000G1-00 for simple@ietf.org; Tue, 27 Apr 2004 06:07:52 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RA7pv21257; Tue, 27 Apr 2004 13:07:51 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 13:06:26 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3RA6QoD019199; Tue, 27 Apr 2004 13:06:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 002YBgqK; Tue, 27 Apr 2004 13:04:58 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RA4vH01066; Tue, 27 Apr 2004 13:04:57 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 13:04:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979AA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYAAA+oJw To: , , X-OriginalArrivalTime: 27 Apr 2004 10:04:57.0823 (UTC) FILETIME=[1876FEF0:01C42C3F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 13:04:57 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Lonnfors Mikko (Nokia-NRC/Helsinki)=20 > Sent: 27.April.2004 12:46 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki);=20 > 'rsparks@dynamicsoft.com'; > 'simple@ietf.org' > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Hi, >=20 > > Here is an example where both state and version are needed: > >=20 > > PA sends N1(full), N2(full), N3(partial). > >=20 > > If the version is set to 0 everytime there is full state, and=20 > > N2 was never received, the subscriber would then think that=20 > > N3 is a partial of N1. > >=20 > > To solve this, you need the version to continuously increase=20 > > by 1, even when a full state is being sent. You would then=20 > > also need the state attribute to indicate full/partial. The=20 > > version is used by the subscriber to learn that a NOTIFY was=20 > > not received (N2). >=20 > Ok, so your proposal is that "version" should be scoped with=20 > the subscription i.e. first NOTIFY within a subscription=20 > would have version=3D"0" and then it would be continuously=20 > increased by one for every notifications (regardless if it=20 > contains full or partial state)? >=20 > How should subscription refreshes be handled? If we have > PA sends N1(full), N2(full), N3(partial) > And N2 is lost watcher would refresh the subscription when it=20 > receives N3. Now > Would the PA send N1(full, version=3D"0") or N4(full, version=3D"3")? version gets reset to 0 when a SUBSCRIBE refresh is received. /Hisham >=20 > - Mikko=20 >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org=20 > > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > > ext mikko.lonnfors@nokia.com > > > Sent: 26.April.2004 22:17 > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > Subject: RE: [Simple] WGLC: partial notification > > >=20 > > >=20 > > > Hi, > > >=20 > > > Thanks for comments. Responses inline: > > >=20 > > > > Writing as a WG member - not as chair - > > > >=20 > > > > I've sent a list of typo level nits in these drafts to > > > Mikko privately > > >=20 > > > > - > > > >=20 > > > > While doing a nit review, I found some things that should have > > > > received list attention earlier. > > > >=20 > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > construct the > > >=20 > > > > partial presence document according to the following > > > logic:" followed > > > > by a bunch of MUST level statements. Why is that SHOULD=20 > > there? What > > > > would it mean to violate it? I suggest striking it and=20 > > > simply saying > > > > "The PA constructs" > > >=20 > > > Yes, SHOULD is probably useless and confusing here. I will=20 > > remove it. > > >=20 > > > > Why do we have both "state" and "version"? As defined in > > > these drafts, > > >=20 > > > > state=3Dfull if and only if version=3D0. You could delete the = state > > > > parameter with no loss of information, so why is it there? > > >=20 > > > I believe the original need for the "state" was that the > > > "version" could > > > be initialized to some random value. Now, if "version" is always > > > initialized to 0 there is no need for the "state" attribute. Both > > > solutions should work and if nobody else comments otherwise I will > > > remove the "state" attribute. > > >=20 > > > > 3261 currently allows overlapping non-INVITE=20 > transactions inside a > > > > dialog (there's an open issue suggesting this might be a=20 > > bad thing,=20 > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > > probably manageable. For partial state documents, at least as=20 > > > > they are specified here, it could be disastrous. Consider=20 > > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > > If the recipient receives only N1 and N4 (something prevents=20 > > > > N2 and N3 from being delivered or simply delays them=20 > > > > (packetloss over UDP for example)), it will apply the delta=20 > > > > in N4 to the wrong full state document (N1 instead of N3).=20 > > >=20 > > > Actually it wouldn't because of "version" handling. Section > > > 4.5 applies > > > here. But in any case this kind of behavior is quite bad=20 > as it might > > > result in frequent subscription refreshes to obtain full=20 > > > presence state. > > > More below. > > >=20 > > > > We > > > > can preserve the properties of the existing system is we forbid=20 > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > when any other=20 > > > > NOTIFY transaction is still in progress on > > > this dialog. > > >=20 > > > This is a good point. Your proposed solution should work. > > > This may cause > > > some extra implementation effort for PA but I cannot see any=20 > > > way around > > > this. If no other comments are received I will add text forbidding > > > sending a NOTIFY with a document with state=3D"partial"=20 > > (version=3D0) when > > > any other NOTIFY transaction is still in progress on this dialog.=20 > > >=20 > > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > > presence document whose "version" attribute value (is)=20 > higher by=20 > > > > more than one with the locally stored value, the=20 > watcher assumes=20 > > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > > refresh the subscription in order to receive a full presence=20 > > > > document or terminate the subscription." Why is that=20 > SHOULD? In=20 > > > > what scenario is any other course of action reasonable?=20 > (The only=20 > > > > one I can think of is _if_ we allow overlapping partial=20 > NOTIFYs,=20 > > > > then the watcher can wait around for awhile for the gaps=20 > > to fill in=20 > > > > - if we allow this, then we need to explicitly state this as > > > > why the above is SHOULD, not MUST. However, I think this=20 > > > > should be a MUST.) > > >=20 > > > Well, there probably isn't any good cases where watcher wouldn't=20 > > > terminate or refresh subscription. Changing SHOULD to MUST should=20 > > > provide more consistent behavior. > > > =20 > > > > Just below that, there's a "SHOULD discard the document" if > > > > it gets a partial notification with a lower version number. I=20 > > > > don't see how this is right at all, and suggest that this=20 > > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > > - the CSeq processing logic would=20 > > > > have caught it). > > >=20 > > > Right, and if we don't allow sending new NOTIFYs if there=20 > > is a pending=20 > > > transaction then I believe reordering should never happen.=20 > > But if in=20 > > > this situation watcher receives a presence document with=20 > > lower version=20 > > > number there should be no harm in discarding it because it=20 > > already has=20 > > > a consistent presence state. This is more or less an error=20 > > case which > > > probably should never happen but I think there is no need to=20 > > > refresh or > > > terminate the subscription. > > >=20 > > > - Mikko > > >=20 > > > > I'll send a separate message on the Security Considerations > > > > section for -partial-notify. > > > >=20 > > > > RjS > > > >=20 > > > >=20 > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > This is a Working Group Last call on the following drafts: > > > > >=20 > > > > >=20 > > > > http://www.ietf.org/internet-drafts/draft-> > > > ietf-simple-partial-notify-0 > > > > > 2.txt > > > > >=20 > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > pidf-format-01.txt > > > >=20 > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > >=20 > > > > These drafts went through a previous last call at the=20 > beginning of > > > > March. These versions reflect changes due to comments=20 > > > received during > > > > that period. See > > > >=20 > >=20 https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > >=20 > > Please send comments to the list, copying the editor. If=20 > you reviewed > > the draft and found no issues, please indicate so on the list. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 06:45:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21343 for ; Tue, 27 Apr 2004 06:45:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPws-00016C-SD for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 06:36:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RAaMBp004222 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 06:36:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPol-0008VP-Ba for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 06:27:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20511 for ; Tue, 27 Apr 2004 06:27:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPoh-0004lK-Cf for simple-web-archive@ietf.org; Tue, 27 Apr 2004 06:27:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPnq-0004Xd-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 06:27:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPmm-0004Im-00; Tue, 27 Apr 2004 06:25:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPdF-0006n4-70; Tue, 27 Apr 2004 06:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPXE-0004XN-2N for simple@optimus.ietf.org; Tue, 27 Apr 2004 06:09:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19227 for ; Tue, 27 Apr 2004 06:09:47 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPXA-0000fv-3A for simple@ietf.org; Tue, 27 Apr 2004 06:09:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPWA-0000Sr-00 for simple@ietf.org; Tue, 27 Apr 2004 06:08:47 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIPVI-0000G1-00 for simple@ietf.org; Tue, 27 Apr 2004 06:07:52 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RA7pv21257; Tue, 27 Apr 2004 13:07:51 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 13:06:26 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3RA6QoD019199; Tue, 27 Apr 2004 13:06:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 002YBgqK; Tue, 27 Apr 2004 13:04:58 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RA4vH01066; Tue, 27 Apr 2004 13:04:57 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 13:04:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979AA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYAAA+oJw To: , , X-OriginalArrivalTime: 27 Apr 2004 10:04:57.0823 (UTC) FILETIME=[1876FEF0:01C42C3F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 13:04:57 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Lonnfors Mikko (Nokia-NRC/Helsinki)=20 > Sent: 27.April.2004 12:46 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki);=20 > 'rsparks@dynamicsoft.com'; > 'simple@ietf.org' > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Hi, >=20 > > Here is an example where both state and version are needed: > >=20 > > PA sends N1(full), N2(full), N3(partial). > >=20 > > If the version is set to 0 everytime there is full state, and=20 > > N2 was never received, the subscriber would then think that=20 > > N3 is a partial of N1. > >=20 > > To solve this, you need the version to continuously increase=20 > > by 1, even when a full state is being sent. You would then=20 > > also need the state attribute to indicate full/partial. The=20 > > version is used by the subscriber to learn that a NOTIFY was=20 > > not received (N2). >=20 > Ok, so your proposal is that "version" should be scoped with=20 > the subscription i.e. first NOTIFY within a subscription=20 > would have version=3D"0" and then it would be continuously=20 > increased by one for every notifications (regardless if it=20 > contains full or partial state)? >=20 > How should subscription refreshes be handled? If we have > PA sends N1(full), N2(full), N3(partial) > And N2 is lost watcher would refresh the subscription when it=20 > receives N3. Now > Would the PA send N1(full, version=3D"0") or N4(full, version=3D"3")? version gets reset to 0 when a SUBSCRIBE refresh is received. /Hisham >=20 > - Mikko=20 >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org=20 > > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > > ext mikko.lonnfors@nokia.com > > > Sent: 26.April.2004 22:17 > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > Subject: RE: [Simple] WGLC: partial notification > > >=20 > > >=20 > > > Hi, > > >=20 > > > Thanks for comments. Responses inline: > > >=20 > > > > Writing as a WG member - not as chair - > > > >=20 > > > > I've sent a list of typo level nits in these drafts to > > > Mikko privately > > >=20 > > > > - > > > >=20 > > > > While doing a nit review, I found some things that should have > > > > received list attention earlier. > > > >=20 > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > construct the > > >=20 > > > > partial presence document according to the following > > > logic:" followed > > > > by a bunch of MUST level statements. Why is that SHOULD=20 > > there? What > > > > would it mean to violate it? I suggest striking it and=20 > > > simply saying > > > > "The PA constructs" > > >=20 > > > Yes, SHOULD is probably useless and confusing here. I will=20 > > remove it. > > >=20 > > > > Why do we have both "state" and "version"? As defined in > > > these drafts, > > >=20 > > > > state=3Dfull if and only if version=3D0. You could delete the = state > > > > parameter with no loss of information, so why is it there? > > >=20 > > > I believe the original need for the "state" was that the > > > "version" could > > > be initialized to some random value. Now, if "version" is always > > > initialized to 0 there is no need for the "state" attribute. Both > > > solutions should work and if nobody else comments otherwise I will > > > remove the "state" attribute. > > >=20 > > > > 3261 currently allows overlapping non-INVITE=20 > transactions inside a > > > > dialog (there's an open issue suggesting this might be a=20 > > bad thing,=20 > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > > probably manageable. For partial state documents, at least as=20 > > > > they are specified here, it could be disastrous. Consider=20 > > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > > If the recipient receives only N1 and N4 (something prevents=20 > > > > N2 and N3 from being delivered or simply delays them=20 > > > > (packetloss over UDP for example)), it will apply the delta=20 > > > > in N4 to the wrong full state document (N1 instead of N3).=20 > > >=20 > > > Actually it wouldn't because of "version" handling. Section > > > 4.5 applies > > > here. But in any case this kind of behavior is quite bad=20 > as it might > > > result in frequent subscription refreshes to obtain full=20 > > > presence state. > > > More below. > > >=20 > > > > We > > > > can preserve the properties of the existing system is we forbid=20 > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > when any other=20 > > > > NOTIFY transaction is still in progress on > > > this dialog. > > >=20 > > > This is a good point. Your proposed solution should work. > > > This may cause > > > some extra implementation effort for PA but I cannot see any=20 > > > way around > > > this. If no other comments are received I will add text forbidding > > > sending a NOTIFY with a document with state=3D"partial"=20 > > (version=3D0) when > > > any other NOTIFY transaction is still in progress on this dialog.=20 > > >=20 > > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > > presence document whose "version" attribute value (is)=20 > higher by=20 > > > > more than one with the locally stored value, the=20 > watcher assumes=20 > > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > > refresh the subscription in order to receive a full presence=20 > > > > document or terminate the subscription." Why is that=20 > SHOULD? In=20 > > > > what scenario is any other course of action reasonable?=20 > (The only=20 > > > > one I can think of is _if_ we allow overlapping partial=20 > NOTIFYs,=20 > > > > then the watcher can wait around for awhile for the gaps=20 > > to fill in=20 > > > > - if we allow this, then we need to explicitly state this as > > > > why the above is SHOULD, not MUST. However, I think this=20 > > > > should be a MUST.) > > >=20 > > > Well, there probably isn't any good cases where watcher wouldn't=20 > > > terminate or refresh subscription. Changing SHOULD to MUST should=20 > > > provide more consistent behavior. > > > =20 > > > > Just below that, there's a "SHOULD discard the document" if > > > > it gets a partial notification with a lower version number. I=20 > > > > don't see how this is right at all, and suggest that this=20 > > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > > - the CSeq processing logic would=20 > > > > have caught it). > > >=20 > > > Right, and if we don't allow sending new NOTIFYs if there=20 > > is a pending=20 > > > transaction then I believe reordering should never happen.=20 > > But if in=20 > > > this situation watcher receives a presence document with=20 > > lower version=20 > > > number there should be no harm in discarding it because it=20 > > already has=20 > > > a consistent presence state. This is more or less an error=20 > > case which > > > probably should never happen but I think there is no need to=20 > > > refresh or > > > terminate the subscription. > > >=20 > > > - Mikko > > >=20 > > > > I'll send a separate message on the Security Considerations > > > > section for -partial-notify. > > > >=20 > > > > RjS > > > >=20 > > > >=20 > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > This is a Working Group Last call on the following drafts: > > > > >=20 > > > > >=20 > > > > http://www.ietf.org/internet-drafts/draft-> > > > ietf-simple-partial-notify-0 > > > > > 2.txt > > > > >=20 > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > pidf-format-01.txt > > > >=20 > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > >=20 > > > > These drafts went through a previous last call at the=20 > beginning of > > > > March. These versions reflect changes due to comments=20 > > > received during > > > > that period. See > > > >=20 > >=20 https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > >=20 > > Please send comments to the list, copying the editor. If=20 > you reviewed > > the draft and found no issues, please indicate so on the list. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 06:51:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21745 for ; Tue, 27 Apr 2004 06:51:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIQBs-0002C1-2t for simple-archive@ietf.org; Tue, 27 Apr 2004 06:51:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQAv-0001zx-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 06:50:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIQAI-0001o4-00; Tue, 27 Apr 2004 06:50:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQ7B-0003WW-SM; Tue, 27 Apr 2004 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQ2K-0002IL-DE for simple@optimus.ietf.org; Tue, 27 Apr 2004 06:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21148 for ; Tue, 27 Apr 2004 06:41:55 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIQ2G-0007ew-21 for simple@ietf.org; Tue, 27 Apr 2004 06:41:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQ1M-0007SN-00 for simple@ietf.org; Tue, 27 Apr 2004 06:41:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIQ0v-0007Fi-00 for simple@ietf.org; Tue, 27 Apr 2004 06:40:33 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RAeUv29897; Tue, 27 Apr 2004 13:40:31 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 13:39:41 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3RAdfmK027031; Tue, 27 Apr 2004 13:39:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00nwudsP; Tue, 27 Apr 2004 13:30:01 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RAU0H17485; Tue, 27 Apr 2004 13:30:00 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 13:29:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE9F@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQrzqaK+ttVAQtERBOvC6cZWCT1/wAbBTfwAAHi89A= To: , , X-OriginalArrivalTime: 27 Apr 2004 10:29:47.0470 (UTC) FILETIME=[905D16E0:01C42C42] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 13:29:46 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Correct. Your proposal for "version" handling seems quite nice and it also solves this problem. - Mikko > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: Tuesday, April 27, 2004 12:37 PM > To: 'ext Robert Sparks'; Lonnfors Mikko (Nokia-NRC/Helsinki);=20 > simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > If the version handling goes as I described in my other=20 > email, then it should solve this problem. >=20 > N1(full, v=3D0), N4(partial, v=3D4). The subscriber realises that=20 > there are 2 notifications missing and does not accept N4. >=20 > /Hisham >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > ext Robert Sparks > > Sent: 26.April.2004 22:29 > > To: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > (private reply to avoid confusion on the list - we'll go > > back there after we get closer on this question) > >=20 > > > > 3261 currently allows overlapping non-INVITE transactions > > inside a > > > > dialog (there's an open issue suggesting this might be a > > bad thing, > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686).=20 > Neither 3265=20 > > > > or simple-presence prohibit overlapping NOTIFYs. For full state=20 > > > > documents, having multiple outstanding NOTIFYs is probably=20 > > > > manageable. For partial state documents, at least as they are=20 > > > > specified here, it could be disastrous. Consider four notifies=20 > > > > N1(full), N2(partial), N3(full), N4(partial). If the recipient=20 > > > > receives only N1 and N4 (something prevents N2 and N3=20 > from being=20 > > > > delivered or simply delays them (packetloss over UDP for=20 > > > > example)), it will apply the delta in N4 to the wrong=20 > full state=20 > > > > document (N1 instead of N3). > > >=20 > > > Actually it wouldn't because of "version" handling. Section > > 4.5 applies > > > here. But in any case this kind of behavior is quite bad=20 > as it might=20 > > > result in frequent subscription refreshes to obtain full > > presence state. > >=20 > > How does version help here? The recipient has seen exactly two=20 > > documents, the first with version=3D0 (which happens to be=20 > N1) and the=20 > > second has version=3D1 (which happens to be N4). The recipient has = no=20 > > way to know it missed N2 and N3. > >=20 > > I don't see how version as it's defined helps you at all in this > > case. We'll need something like the proposal to forbid the > > possibility of overlaps to prevent it. > >=20 > > RjS > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 06:58:53 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19347 for ; Tue, 27 Apr 2004 06:11:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPO1-0002zY-DN for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 06:00:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RA0L9b011496 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 06:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPJE-0001ta-4b for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 05:55:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17743 for ; Tue, 27 Apr 2004 05:55:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPJA-0005Bs-GZ for simple-web-archive@ietf.org; Tue, 27 Apr 2004 05:55:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPI7-0004xJ-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 05:54:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPHP-0004il-00; Tue, 27 Apr 2004 05:53:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP9D-0000W9-4P; Tue, 27 Apr 2004 05:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP4J-0008CC-99 for simple@optimus.ietf.org; Tue, 27 Apr 2004 05:39:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16957 for ; Tue, 27 Apr 2004 05:39:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIP4F-00027Q-Pw for simple@ietf.org; Tue, 27 Apr 2004 05:39:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIP3G-0001vZ-00 for simple@ietf.org; Tue, 27 Apr 2004 05:38:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIP2t-0001k2-00 for simple@ietf.org; Tue, 27 Apr 2004 05:38:31 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9cRv16015; Tue, 27 Apr 2004 12:38:27 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 12:37:13 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3R9bDUc006967; Tue, 27 Apr 2004 12:37:13 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00yHSnAL; Tue, 27 Apr 2004 12:36:50 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R9aoH07311; Tue, 27 Apr 2004 12:36:50 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 12:36:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979A9@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQrzqaK+ttVAQtERBOvC6cZWCT1/wAbBTfw To: , , X-OriginalArrivalTime: 27 Apr 2004 09:36:43.0400 (UTC) FILETIME=[26829080:01C42C3B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 12:36:42 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If the version handling goes as I described in my other email, then it = should solve this problem. N1(full, v=3D0), N4(partial, v=3D4). The subscriber realises that there = are 2 notifications missing and does not accept N4. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Robert Sparks > Sent: 26.April.2004 22:29 > To: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > (private reply to avoid confusion on the list - we'll go > back there after we get closer on this question) >=20 > > > 3261 currently allows overlapping non-INVITE transactions=20 > inside a=20 > > > dialog (there's an open issue suggesting this might be a=20 > bad thing,=20 > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > probably manageable. For partial state documents, at least as=20 > > > they are specified here, it could be disastrous. Consider=20 > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > If the recipient receives only N1 and N4 (something prevents=20 > > > N2 and N3 from being delivered or simply delays them=20 > > > (packetloss over UDP for example)), it will apply the delta=20 > > > in N4 to the wrong full state document (N1 instead of N3).=20 > >=20 > > Actually it wouldn't because of "version" handling. Section=20 > 4.5 applies > > here. But in any case this kind of behavior is quite bad as it might > > result in frequent subscription refreshes to obtain full=20 > presence state. >=20 > How does version help here? The recipient has seen exactly > two documents, the first with version=3D0 (which happens to > be N1) and the second has version=3D1 (which happens to be > N4). The recipient has no way to know it missed N2 and > N3.=20 >=20 > I don't see how version as it's defined helps you at all in this=20 > case. We'll need something like the proposal to forbid the > possibility of overlaps to prevent it. >=20 > RjS >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 07:11:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22572 for ; Tue, 27 Apr 2004 07:11:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQNY-0005id-W2 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 07:03:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RB3ufX021977 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 07:03:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQBw-0004Ec-Tf for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 06:51:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21763 for ; Tue, 27 Apr 2004 06:51:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIQBs-0002C6-PI for simple-web-archive@ietf.org; Tue, 27 Apr 2004 06:51:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQAv-000204-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 06:50:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIQAI-0001o4-00; Tue, 27 Apr 2004 06:50:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQ7B-0003WW-SM; Tue, 27 Apr 2004 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQ2K-0002IL-DE for simple@optimus.ietf.org; Tue, 27 Apr 2004 06:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21148 for ; Tue, 27 Apr 2004 06:41:55 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIQ2G-0007ew-21 for simple@ietf.org; Tue, 27 Apr 2004 06:41:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQ1M-0007SN-00 for simple@ietf.org; Tue, 27 Apr 2004 06:41:01 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIQ0v-0007Fi-00 for simple@ietf.org; Tue, 27 Apr 2004 06:40:33 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RAeUv29897; Tue, 27 Apr 2004 13:40:31 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 13:39:41 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3RAdfmK027031; Tue, 27 Apr 2004 13:39:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00nwudsP; Tue, 27 Apr 2004 13:30:01 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RAU0H17485; Tue, 27 Apr 2004 13:30:00 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 13:29:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DE9F@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQrzqaK+ttVAQtERBOvC6cZWCT1/wAbBTfwAAHi89A= To: , , X-OriginalArrivalTime: 27 Apr 2004 10:29:47.0470 (UTC) FILETIME=[905D16E0:01C42C42] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 13:29:46 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Correct. Your proposal for "version" handling seems quite nice and it also solves this problem. - Mikko > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: Tuesday, April 27, 2004 12:37 PM > To: 'ext Robert Sparks'; Lonnfors Mikko (Nokia-NRC/Helsinki);=20 > simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > If the version handling goes as I described in my other=20 > email, then it should solve this problem. >=20 > N1(full, v=3D0), N4(partial, v=3D4). The subscriber realises that=20 > there are 2 notifications missing and does not accept N4. >=20 > /Hisham >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > ext Robert Sparks > > Sent: 26.April.2004 22:29 > > To: Lonnfors Mikko (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > (private reply to avoid confusion on the list - we'll go > > back there after we get closer on this question) > >=20 > > > > 3261 currently allows overlapping non-INVITE transactions > > inside a > > > > dialog (there's an open issue suggesting this might be a > > bad thing, > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686).=20 > Neither 3265=20 > > > > or simple-presence prohibit overlapping NOTIFYs. For full state=20 > > > > documents, having multiple outstanding NOTIFYs is probably=20 > > > > manageable. For partial state documents, at least as they are=20 > > > > specified here, it could be disastrous. Consider four notifies=20 > > > > N1(full), N2(partial), N3(full), N4(partial). If the recipient=20 > > > > receives only N1 and N4 (something prevents N2 and N3=20 > from being=20 > > > > delivered or simply delays them (packetloss over UDP for=20 > > > > example)), it will apply the delta in N4 to the wrong=20 > full state=20 > > > > document (N1 instead of N3). > > >=20 > > > Actually it wouldn't because of "version" handling. Section > > 4.5 applies > > > here. But in any case this kind of behavior is quite bad=20 > as it might=20 > > > result in frequent subscription refreshes to obtain full > > presence state. > >=20 > > How does version help here? The recipient has seen exactly two=20 > > documents, the first with version=3D0 (which happens to be=20 > N1) and the=20 > > second has version=3D1 (which happens to be N4). The recipient has = no=20 > > way to know it missed N2 and N3. > >=20 > > I don't see how version as it's defined helps you at all in this > > case. We'll need something like the proposal to forbid the > > possibility of overlaps to prevent it. > >=20 > > RjS > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 12:01:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09086 for ; Tue, 27 Apr 2004 12:01:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIV1A-0000Rp-Rr for simple-archive@ietf.org; Tue, 27 Apr 2004 12:01:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIV0I-0000NC-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 12:00:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIUzk-0000IT-00; Tue, 27 Apr 2004 11:59:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUqS-0000jP-7a; Tue, 27 Apr 2004 11:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUkK-0007xo-Rs for simple@optimus.ietf.org; Tue, 27 Apr 2004 11:43:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07889 for ; Tue, 27 Apr 2004 11:43:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUkH-0006oU-J8 for simple@ietf.org; Tue, 27 Apr 2004 11:43:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUiQ-0006a5-00 for simple@ietf.org; Tue, 27 Apr 2004 11:41:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUfO-0006Na-00 for simple@ietf.org; Tue, 27 Apr 2004 11:38:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIUf5-0002vL-NH for simple@ietf.org; Tue, 27 Apr 2004 11:38:19 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2004 08:38:32 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3RFbL0Q001424; Tue, 27 Apr 2004 08:37:21 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX14710; Tue, 27 Apr 2004 11:37:19 -0400 (EDT) Message-ID: <408E7E2F.5030706@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: mikko.lonnfors@nokia.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979A8@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 11:37:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sounds like what is needed is: 1, 1.1, 1.2, ..., 1.x, 2, 2.1, 2.2, ... 2.y, 3, 3.1, 3.2, ..., 3.z, ... Namely, version number and revision number. If there is no revision number, then it is full, otherwise partial. If you get Version a, Revision b, then you had better have already received Version a, Revision b-1, or else there is a problem. Paul hisham.khartabil@nokia.com wrote: > Here is an example where both state and version are needed: > > PA sends N1(full), N2(full), N3(partial). > > If the version is set to 0 everytime there is full state, and N2 was never received, the subscriber would then think that N3 is a partial of N1. > > To solve this, you need the version to continuously increase by 1, even when a full state is being sent. You would then also need the state attribute to indicate full/partial. The version is used by the subscriber to learn that a NOTIFY was not received (N2). > > /Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext mikko.lonnfors@nokia.com >>Sent: 26.April.2004 22:17 >>To: rsparks@dynamicsoft.com; simple@ietf.org >>Subject: RE: [Simple] WGLC: partial notification >> >> >>Hi, >> >>Thanks for comments. Responses inline: >> >> >>>Writing as a WG member - not as chair - >>> >>>I've sent a list of typo level nits in these drafts to >> >>Mikko privately >> >> >>>- >>> >>>While doing a nit review, I found some things that should have >>>received list attention earlier. >>> >>>In section 4.4 of -partial-notify it says "The PA SHOULD >> >>construct the >> >> >>>partial presence document according to the following >> >>logic:" followed >> >>>by a bunch of MUST level statements. Why is that SHOULD there? What >>>would it mean to violate it? I suggest striking it and >> >>simply saying >> >>>"The PA constructs" >> >>Yes, SHOULD is probably useless and confusing here. I will remove it. >> >> >>>Why do we have both "state" and "version"? As defined in >> >>these drafts, >> >> >>>state=full if and only if version=0. You could delete the state >>>parameter with no loss of information, so why is it there? >> >>I believe the original need for the "state" was that the >>"version" could >>be initialized to some random value. Now, if "version" is always >>initialized to 0 there is no need for the "state" attribute. Both >>solutions should work and if nobody else comments otherwise I will >>remove the "state" attribute. >> >> >>>3261 currently allows overlapping non-INVITE transactions inside a >>>dialog (there's an open issue suggesting this might be a bad thing, >>>see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither >>>3265 or simple-presence prohibit overlapping NOTIFYs. For >>>full state documents, having multiple outstanding NOTIFYs is >>>probably manageable. For partial state documents, at least as >>>they are specified here, it could be disastrous. Consider >>>four notifies N1(full), N2(partial), N3(full), N4(partial). >>>If the recipient receives only N1 and N4 (something prevents >>>N2 and N3 from being delivered or simply delays them >>>(packetloss over UDP for example)), it will apply the delta >>>in N4 to the wrong full state document (N1 instead of N3). >> >>Actually it wouldn't because of "version" handling. Section >>4.5 applies >>here. But in any case this kind of behavior is quite bad as it might >>result in frequent subscription refreshes to obtain full >>presence state. >>More below. >> >> >>>We >>>can preserve the properties of the existing system is we >>>forbid sending a NOTIFY with a document with state="partial" >>>when any other NOTIFY transaction is still in progress on >> >>this dialog. >> >>This is a good point. Your proposed solution should work. >>This may cause >>some extra implementation effort for PA but I cannot see any >>way around >>this. If no other comments are received I will add text forbidding >>sending a NOTIFY with a document with state="partial" (version=0) when >>any other NOTIFY transaction is still in progress on this dialog. >> >> >>>Section 4.5 of partial-notify says "If the watcher receives a >>>presence document whose "version" attribute value (is) higher >>>by more than one with the locally stored value, the watcher >>>assumes that one or more NOTIFYs were lost. The watcher >>>SHOULD either refresh the subscription >>>in order to receive a full presence document or terminate the >>>subscription." Why is that SHOULD? In what scenario is any >>>other course of action reasonable? (The only one I can think >>>of is _if_ we allow overlapping partial NOTIFYs, then the >>>watcher can wait around for awhile for the gaps to fill in - >>>if we allow this, then we need to explicitly state this as >>>why the above is SHOULD, not MUST. However, I think this >>>should be a MUST.) >> >>Well, there probably isn't any good cases where watcher wouldn't >>terminate or refresh subscription. Changing SHOULD to MUST should >>provide more consistent behavior. >> >> >>>Just below that, there's a "SHOULD discard the document" if >>>it gets a partial notification with a lower version number. I >>>don't see how this is right at all, and suggest that this >>>MUST trigger a refresh or termination instead. (We wouldn't >>>get to this logic if a NOTIFY was reordered and arrived late >>>- the CSeq processing logic would >>>have caught it). >> >>Right, and if we don't allow sending new NOTIFYs if there is a pending >>transaction then I believe reordering should never happen. But if in >>this situation watcher receives a presence document with lower version >>number there should be no harm in discarding it because it >>already has a >>consistent presence state. This is more or less an error case which >>probably should never happen but I think there is no need to >>refresh or >>terminate the subscription. >> >>- Mikko >> >> >>>I'll send a separate message on the Security Considerations >>>section for -partial-notify. >>> >>>RjS >>> >>> >>>On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: >>> >>>>This is a Working Group Last call on the following drafts: >>>> >>>> >>> >>>http://www.ietf.org/internet-drafts/draft-> >> >>ietf-simple-partial-notify-0 >> >>>>2.txt >>>> >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- >> >>pidf-format-01.txt >> >>>This abbreviated WGLC will end on Wednesday, April 28. >>> >>>These drafts went through a previous last call at the beginning of >>>March. These versions reflect changes due to comments >> >>received during >> >>>that period. See >>> >> > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > >>519.html >>for details. >> >>Please send comments to the list, copying the editor. If you reviewed >>the draft and found no issues, please indicate so on the list. >> >>RjS >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 12:27:50 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10405 for ; Tue, 27 Apr 2004 12:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVLe-0000VG-Ad for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 12:22:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGMIt3001934 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 12:22:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV1E-0003mS-T4 for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:01:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09090 for ; Tue, 27 Apr 2004 12:01:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIV1B-0000Ru-FG for simple-web-archive@ietf.org; Tue, 27 Apr 2004 12:01:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIV0K-0000NJ-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 12:00:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIUzk-0000IT-00; Tue, 27 Apr 2004 11:59:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUqS-0000jP-7a; Tue, 27 Apr 2004 11:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUkK-0007xo-Rs for simple@optimus.ietf.org; Tue, 27 Apr 2004 11:43:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07889 for ; Tue, 27 Apr 2004 11:43:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUkH-0006oU-J8 for simple@ietf.org; Tue, 27 Apr 2004 11:43:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUiQ-0006a5-00 for simple@ietf.org; Tue, 27 Apr 2004 11:41:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUfO-0006Na-00 for simple@ietf.org; Tue, 27 Apr 2004 11:38:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIUf5-0002vL-NH for simple@ietf.org; Tue, 27 Apr 2004 11:38:19 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2004 08:38:32 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3RFbL0Q001424; Tue, 27 Apr 2004 08:37:21 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX14710; Tue, 27 Apr 2004 11:37:19 -0400 (EDT) Message-ID: <408E7E2F.5030706@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: mikko.lonnfors@nokia.com, rsparks@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979A8@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 11:37:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sounds like what is needed is: 1, 1.1, 1.2, ..., 1.x, 2, 2.1, 2.2, ... 2.y, 3, 3.1, 3.2, ..., 3.z, ... Namely, version number and revision number. If there is no revision number, then it is full, otherwise partial. If you get Version a, Revision b, then you had better have already received Version a, Revision b-1, or else there is a problem. Paul hisham.khartabil@nokia.com wrote: > Here is an example where both state and version are needed: > > PA sends N1(full), N2(full), N3(partial). > > If the version is set to 0 everytime there is full state, and N2 was never received, the subscriber would then think that N3 is a partial of N1. > > To solve this, you need the version to continuously increase by 1, even when a full state is being sent. You would then also need the state attribute to indicate full/partial. The version is used by the subscriber to learn that a NOTIFY was not received (N2). > > /Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext mikko.lonnfors@nokia.com >>Sent: 26.April.2004 22:17 >>To: rsparks@dynamicsoft.com; simple@ietf.org >>Subject: RE: [Simple] WGLC: partial notification >> >> >>Hi, >> >>Thanks for comments. Responses inline: >> >> >>>Writing as a WG member - not as chair - >>> >>>I've sent a list of typo level nits in these drafts to >> >>Mikko privately >> >> >>>- >>> >>>While doing a nit review, I found some things that should have >>>received list attention earlier. >>> >>>In section 4.4 of -partial-notify it says "The PA SHOULD >> >>construct the >> >> >>>partial presence document according to the following >> >>logic:" followed >> >>>by a bunch of MUST level statements. Why is that SHOULD there? What >>>would it mean to violate it? I suggest striking it and >> >>simply saying >> >>>"The PA constructs" >> >>Yes, SHOULD is probably useless and confusing here. I will remove it. >> >> >>>Why do we have both "state" and "version"? As defined in >> >>these drafts, >> >> >>>state=full if and only if version=0. You could delete the state >>>parameter with no loss of information, so why is it there? >> >>I believe the original need for the "state" was that the >>"version" could >>be initialized to some random value. Now, if "version" is always >>initialized to 0 there is no need for the "state" attribute. Both >>solutions should work and if nobody else comments otherwise I will >>remove the "state" attribute. >> >> >>>3261 currently allows overlapping non-INVITE transactions inside a >>>dialog (there's an open issue suggesting this might be a bad thing, >>>see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither >>>3265 or simple-presence prohibit overlapping NOTIFYs. For >>>full state documents, having multiple outstanding NOTIFYs is >>>probably manageable. For partial state documents, at least as >>>they are specified here, it could be disastrous. Consider >>>four notifies N1(full), N2(partial), N3(full), N4(partial). >>>If the recipient receives only N1 and N4 (something prevents >>>N2 and N3 from being delivered or simply delays them >>>(packetloss over UDP for example)), it will apply the delta >>>in N4 to the wrong full state document (N1 instead of N3). >> >>Actually it wouldn't because of "version" handling. Section >>4.5 applies >>here. But in any case this kind of behavior is quite bad as it might >>result in frequent subscription refreshes to obtain full >>presence state. >>More below. >> >> >>>We >>>can preserve the properties of the existing system is we >>>forbid sending a NOTIFY with a document with state="partial" >>>when any other NOTIFY transaction is still in progress on >> >>this dialog. >> >>This is a good point. Your proposed solution should work. >>This may cause >>some extra implementation effort for PA but I cannot see any >>way around >>this. If no other comments are received I will add text forbidding >>sending a NOTIFY with a document with state="partial" (version=0) when >>any other NOTIFY transaction is still in progress on this dialog. >> >> >>>Section 4.5 of partial-notify says "If the watcher receives a >>>presence document whose "version" attribute value (is) higher >>>by more than one with the locally stored value, the watcher >>>assumes that one or more NOTIFYs were lost. The watcher >>>SHOULD either refresh the subscription >>>in order to receive a full presence document or terminate the >>>subscription." Why is that SHOULD? In what scenario is any >>>other course of action reasonable? (The only one I can think >>>of is _if_ we allow overlapping partial NOTIFYs, then the >>>watcher can wait around for awhile for the gaps to fill in - >>>if we allow this, then we need to explicitly state this as >>>why the above is SHOULD, not MUST. However, I think this >>>should be a MUST.) >> >>Well, there probably isn't any good cases where watcher wouldn't >>terminate or refresh subscription. Changing SHOULD to MUST should >>provide more consistent behavior. >> >> >>>Just below that, there's a "SHOULD discard the document" if >>>it gets a partial notification with a lower version number. I >>>don't see how this is right at all, and suggest that this >>>MUST trigger a refresh or termination instead. (We wouldn't >>>get to this logic if a NOTIFY was reordered and arrived late >>>- the CSeq processing logic would >>>have caught it). >> >>Right, and if we don't allow sending new NOTIFYs if there is a pending >>transaction then I believe reordering should never happen. But if in >>this situation watcher receives a presence document with lower version >>number there should be no harm in discarding it because it >>already has a >>consistent presence state. This is more or less an error case which >>probably should never happen but I think there is no need to >>refresh or >>terminate the subscription. >> >>- Mikko >> >> >>>I'll send a separate message on the Security Considerations >>>section for -partial-notify. >>> >>>RjS >>> >>> >>>On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: >>> >>>>This is a Working Group Last call on the following drafts: >>>> >>>> >>> >>>http://www.ietf.org/internet-drafts/draft-> >> >>ietf-simple-partial-notify-0 >> >>>>2.txt >>>> >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- >> >>pidf-format-01.txt >> >>>This abbreviated WGLC will end on Wednesday, April 28. >>> >>>These drafts went through a previous last call at the beginning of >>>March. These versions reflect changes due to comments >> >>received during >> >>>that period. See >>> >> > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > >>519.html >>for details. >> >>Please send comments to the list, copying the editor. If you reviewed >>the draft and found no issues, please indicate so on the list. >> >>RjS >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 12:43:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11293 for ; Tue, 27 Apr 2004 12:43:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVg1-0003OQ-4C for simple-archive@ietf.org; Tue, 27 Apr 2004 12:43:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVdj-0002x9-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 12:41:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVbo-0002a7-02; Tue, 27 Apr 2004 12:39:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIVMw-00047q-Jw; Tue, 27 Apr 2004 12:23:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV22-0003wf-IW; Tue, 27 Apr 2004 12:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUtJ-00012y-4k for simple@optimus.ietf.org; Tue, 27 Apr 2004 11:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08455 for ; Tue, 27 Apr 2004 11:52:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUtF-0007Qe-Pl for simple@ietf.org; Tue, 27 Apr 2004 11:52:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUsG-0007OK-00 for simple@ietf.org; Tue, 27 Apr 2004 11:51:57 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUrY-0007K0-00 for simple@ietf.org; Tue, 27 Apr 2004 11:51:12 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3RFnl6r018391; Tue, 27 Apr 2004 10:49:47 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: Paul Kyzivat Cc: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org In-Reply-To: <408E7E2F.5030706@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979A8@esebe019.ntc.nokia.com> <408E7E2F.5030706@cisco.com> Content-Type: text/plain Message-Id: <1083080999.2163.47.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 10:49:59 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This introduce a new attack - if I inject a message with version = , you are not likely to recover even with a reSUBSCRIBE. RjS On Tue, 2004-04-27 at 10:37, Paul Kyzivat wrote: > Sounds like what is needed is: > > 1, 1.1, 1.2, ..., 1.x, 2, 2.1, 2.2, ... 2.y, 3, 3.1, 3.2, ..., 3.z, ... > > Namely, version number and revision number. If there is no revision > number, then it is full, otherwise partial. If you get Version a, > Revision b, then you had better have already received Version a, > Revision b-1, or else there is a problem. > > Paul > > hisham.khartabil@nokia.com wrote: > > Here is an example where both state and version are needed: > > > > PA sends N1(full), N2(full), N3(partial). > > > > If the version is set to 0 everytime there is full state, and N2 was never received, the subscriber would then think that N3 is a partial of N1. > > > > To solve this, you need the version to continuously increase by 1, even when a full state is being sent. You would then also need the state attribute to indicate full/partial. The version is used by the subscriber to learn that a NOTIFY was not received (N2). > > > > /Hisham > > > > > >>-----Original Message----- > >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > >>ext mikko.lonnfors@nokia.com > >>Sent: 26.April.2004 22:17 > >>To: rsparks@dynamicsoft.com; simple@ietf.org > >>Subject: RE: [Simple] WGLC: partial notification > >> > >> > >>Hi, > >> > >>Thanks for comments. Responses inline: > >> > >> > >>>Writing as a WG member - not as chair - > >>> > >>>I've sent a list of typo level nits in these drafts to > >> > >>Mikko privately > >> > >> > >>>- > >>> > >>>While doing a nit review, I found some things that should have > >>>received list attention earlier. > >>> > >>>In section 4.4 of -partial-notify it says "The PA SHOULD > >> > >>construct the > >> > >> > >>>partial presence document according to the following > >> > >>logic:" followed > >> > >>>by a bunch of MUST level statements. Why is that SHOULD there? What > >>>would it mean to violate it? I suggest striking it and > >> > >>simply saying > >> > >>>"The PA constructs" > >> > >>Yes, SHOULD is probably useless and confusing here. I will remove it. > >> > >> > >>>Why do we have both "state" and "version"? As defined in > >> > >>these drafts, > >> > >> > >>>state=full if and only if version=0. You could delete the state > >>>parameter with no loss of information, so why is it there? > >> > >>I believe the original need for the "state" was that the > >>"version" could > >>be initialized to some random value. Now, if "version" is always > >>initialized to 0 there is no need for the "state" attribute. Both > >>solutions should work and if nobody else comments otherwise I will > >>remove the "state" attribute. > >> > >> > >>>3261 currently allows overlapping non-INVITE transactions inside a > >>>dialog (there's an open issue suggesting this might be a bad thing, > >>>see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither > >>>3265 or simple-presence prohibit overlapping NOTIFYs. For > >>>full state documents, having multiple outstanding NOTIFYs is > >>>probably manageable. For partial state documents, at least as > >>>they are specified here, it could be disastrous. Consider > >>>four notifies N1(full), N2(partial), N3(full), N4(partial). > >>>If the recipient receives only N1 and N4 (something prevents > >>>N2 and N3 from being delivered or simply delays them > >>>(packetloss over UDP for example)), it will apply the delta > >>>in N4 to the wrong full state document (N1 instead of N3). > >> > >>Actually it wouldn't because of "version" handling. Section > >>4.5 applies > >>here. But in any case this kind of behavior is quite bad as it might > >>result in frequent subscription refreshes to obtain full > >>presence state. > >>More below. > >> > >> > >>>We > >>>can preserve the properties of the existing system is we > >>>forbid sending a NOTIFY with a document with state="partial" > >>>when any other NOTIFY transaction is still in progress on > >> > >>this dialog. > >> > >>This is a good point. Your proposed solution should work. > >>This may cause > >>some extra implementation effort for PA but I cannot see any > >>way around > >>this. If no other comments are received I will add text forbidding > >>sending a NOTIFY with a document with state="partial" (version=0) when > >>any other NOTIFY transaction is still in progress on this dialog. > >> > >> > >>>Section 4.5 of partial-notify says "If the watcher receives a > >>>presence document whose "version" attribute value (is) higher > >>>by more than one with the locally stored value, the watcher > >>>assumes that one or more NOTIFYs were lost. The watcher > >>>SHOULD either refresh the subscription > >>>in order to receive a full presence document or terminate the > >>>subscription." Why is that SHOULD? In what scenario is any > >>>other course of action reasonable? (The only one I can think > >>>of is _if_ we allow overlapping partial NOTIFYs, then the > >>>watcher can wait around for awhile for the gaps to fill in - > >>>if we allow this, then we need to explicitly state this as > >>>why the above is SHOULD, not MUST. However, I think this > >>>should be a MUST.) > >> > >>Well, there probably isn't any good cases where watcher wouldn't > >>terminate or refresh subscription. Changing SHOULD to MUST should > >>provide more consistent behavior. > >> > >> > >>>Just below that, there's a "SHOULD discard the document" if > >>>it gets a partial notification with a lower version number. I > >>>don't see how this is right at all, and suggest that this > >>>MUST trigger a refresh or termination instead. (We wouldn't > >>>get to this logic if a NOTIFY was reordered and arrived late > >>>- the CSeq processing logic would > >>>have caught it). > >> > >>Right, and if we don't allow sending new NOTIFYs if there is a pending > >>transaction then I believe reordering should never happen. But if in > >>this situation watcher receives a presence document with lower version > >>number there should be no harm in discarding it because it > >>already has a > >>consistent presence state. This is more or less an error case which > >>probably should never happen but I think there is no need to > >>refresh or > >>terminate the subscription. > >> > >>- Mikko > >> > >> > >>>I'll send a separate message on the Security Considerations > >>>section for -partial-notify. > >>> > >>>RjS > >>> > >>> > >>>On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > >>> > >>>>This is a Working Group Last call on the following drafts: > >>>> > >>>> > >>> > >>>http://www.ietf.org/internet-drafts/draft-> > >> > >>ietf-simple-partial-notify-0 > >> > >>>>2.txt > >>>> > >>> > >>>http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > >> > >>pidf-format-01.txt > >> > >>>This abbreviated WGLC will end on Wednesday, April 28. > >>> > >>>These drafts went through a previous last call at the beginning of > >>>March. These versions reflect changes due to comments > >> > >>received during > >> > >>>that period. See > >>> > >> > > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > > >>519.html > >>for details. > >> > >>Please send comments to the list, copying the editor. If you reviewed > >>the draft and found no issues, please indicate so on the list. > >> > >>RjS > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 12:58:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12847 for ; Tue, 27 Apr 2004 12:58:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVor-0000YU-0M for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGqS81002127 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVg5-0005ho-Hl for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:43:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11308 for ; Tue, 27 Apr 2004 12:43:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVg1-0003OW-QC for simple-web-archive@ietf.org; Tue, 27 Apr 2004 12:43:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVdk-0002xQ-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 12:41:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVbo-0002a7-02; Tue, 27 Apr 2004 12:39:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIVMw-00047q-Jw; Tue, 27 Apr 2004 12:23:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV22-0003wf-IW; Tue, 27 Apr 2004 12:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUtJ-00012y-4k for simple@optimus.ietf.org; Tue, 27 Apr 2004 11:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08455 for ; Tue, 27 Apr 2004 11:52:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUtF-0007Qe-Pl for simple@ietf.org; Tue, 27 Apr 2004 11:52:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUsG-0007OK-00 for simple@ietf.org; Tue, 27 Apr 2004 11:51:57 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUrY-0007K0-00 for simple@ietf.org; Tue, 27 Apr 2004 11:51:12 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3RFnl6r018391; Tue, 27 Apr 2004 10:49:47 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: Paul Kyzivat Cc: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org In-Reply-To: <408E7E2F.5030706@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979A8@esebe019.ntc.nokia.com> <408E7E2F.5030706@cisco.com> Content-Type: text/plain Message-Id: <1083080999.2163.47.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 10:49:59 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This introduce a new attack - if I inject a message with version = , you are not likely to recover even with a reSUBSCRIBE. RjS On Tue, 2004-04-27 at 10:37, Paul Kyzivat wrote: > Sounds like what is needed is: > > 1, 1.1, 1.2, ..., 1.x, 2, 2.1, 2.2, ... 2.y, 3, 3.1, 3.2, ..., 3.z, ... > > Namely, version number and revision number. If there is no revision > number, then it is full, otherwise partial. If you get Version a, > Revision b, then you had better have already received Version a, > Revision b-1, or else there is a problem. > > Paul > > hisham.khartabil@nokia.com wrote: > > Here is an example where both state and version are needed: > > > > PA sends N1(full), N2(full), N3(partial). > > > > If the version is set to 0 everytime there is full state, and N2 was never received, the subscriber would then think that N3 is a partial of N1. > > > > To solve this, you need the version to continuously increase by 1, even when a full state is being sent. You would then also need the state attribute to indicate full/partial. The version is used by the subscriber to learn that a NOTIFY was not received (N2). > > > > /Hisham > > > > > >>-----Original Message----- > >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > >>ext mikko.lonnfors@nokia.com > >>Sent: 26.April.2004 22:17 > >>To: rsparks@dynamicsoft.com; simple@ietf.org > >>Subject: RE: [Simple] WGLC: partial notification > >> > >> > >>Hi, > >> > >>Thanks for comments. Responses inline: > >> > >> > >>>Writing as a WG member - not as chair - > >>> > >>>I've sent a list of typo level nits in these drafts to > >> > >>Mikko privately > >> > >> > >>>- > >>> > >>>While doing a nit review, I found some things that should have > >>>received list attention earlier. > >>> > >>>In section 4.4 of -partial-notify it says "The PA SHOULD > >> > >>construct the > >> > >> > >>>partial presence document according to the following > >> > >>logic:" followed > >> > >>>by a bunch of MUST level statements. Why is that SHOULD there? What > >>>would it mean to violate it? I suggest striking it and > >> > >>simply saying > >> > >>>"The PA constructs" > >> > >>Yes, SHOULD is probably useless and confusing here. I will remove it. > >> > >> > >>>Why do we have both "state" and "version"? As defined in > >> > >>these drafts, > >> > >> > >>>state=full if and only if version=0. You could delete the state > >>>parameter with no loss of information, so why is it there? > >> > >>I believe the original need for the "state" was that the > >>"version" could > >>be initialized to some random value. Now, if "version" is always > >>initialized to 0 there is no need for the "state" attribute. Both > >>solutions should work and if nobody else comments otherwise I will > >>remove the "state" attribute. > >> > >> > >>>3261 currently allows overlapping non-INVITE transactions inside a > >>>dialog (there's an open issue suggesting this might be a bad thing, > >>>see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither > >>>3265 or simple-presence prohibit overlapping NOTIFYs. For > >>>full state documents, having multiple outstanding NOTIFYs is > >>>probably manageable. For partial state documents, at least as > >>>they are specified here, it could be disastrous. Consider > >>>four notifies N1(full), N2(partial), N3(full), N4(partial). > >>>If the recipient receives only N1 and N4 (something prevents > >>>N2 and N3 from being delivered or simply delays them > >>>(packetloss over UDP for example)), it will apply the delta > >>>in N4 to the wrong full state document (N1 instead of N3). > >> > >>Actually it wouldn't because of "version" handling. Section > >>4.5 applies > >>here. But in any case this kind of behavior is quite bad as it might > >>result in frequent subscription refreshes to obtain full > >>presence state. > >>More below. > >> > >> > >>>We > >>>can preserve the properties of the existing system is we > >>>forbid sending a NOTIFY with a document with state="partial" > >>>when any other NOTIFY transaction is still in progress on > >> > >>this dialog. > >> > >>This is a good point. Your proposed solution should work. > >>This may cause > >>some extra implementation effort for PA but I cannot see any > >>way around > >>this. If no other comments are received I will add text forbidding > >>sending a NOTIFY with a document with state="partial" (version=0) when > >>any other NOTIFY transaction is still in progress on this dialog. > >> > >> > >>>Section 4.5 of partial-notify says "If the watcher receives a > >>>presence document whose "version" attribute value (is) higher > >>>by more than one with the locally stored value, the watcher > >>>assumes that one or more NOTIFYs were lost. The watcher > >>>SHOULD either refresh the subscription > >>>in order to receive a full presence document or terminate the > >>>subscription." Why is that SHOULD? In what scenario is any > >>>other course of action reasonable? (The only one I can think > >>>of is _if_ we allow overlapping partial NOTIFYs, then the > >>>watcher can wait around for awhile for the gaps to fill in - > >>>if we allow this, then we need to explicitly state this as > >>>why the above is SHOULD, not MUST. However, I think this > >>>should be a MUST.) > >> > >>Well, there probably isn't any good cases where watcher wouldn't > >>terminate or refresh subscription. Changing SHOULD to MUST should > >>provide more consistent behavior. > >> > >> > >>>Just below that, there's a "SHOULD discard the document" if > >>>it gets a partial notification with a lower version number. I > >>>don't see how this is right at all, and suggest that this > >>>MUST trigger a refresh or termination instead. (We wouldn't > >>>get to this logic if a NOTIFY was reordered and arrived late > >>>- the CSeq processing logic would > >>>have caught it). > >> > >>Right, and if we don't allow sending new NOTIFYs if there is a pending > >>transaction then I believe reordering should never happen. But if in > >>this situation watcher receives a presence document with lower version > >>number there should be no harm in discarding it because it > >>already has a > >>consistent presence state. This is more or less an error case which > >>probably should never happen but I think there is no need to > >>refresh or > >>terminate the subscription. > >> > >>- Mikko > >> > >> > >>>I'll send a separate message on the Security Considerations > >>>section for -partial-notify. > >>> > >>>RjS > >>> > >>> > >>>On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > >>> > >>>>This is a Working Group Last call on the following drafts: > >>>> > >>>> > >>> > >>>http://www.ietf.org/internet-drafts/draft-> > >> > >>ietf-simple-partial-notify-0 > >> > >>>>2.txt > >>>> > >>> > >>>http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > >> > >>pidf-format-01.txt > >> > >>>This abbreviated WGLC will end on Wednesday, April 28. > >>> > >>>These drafts went through a previous last call at the beginning of > >>>March. These versions reflect changes due to comments > >> > >>received during > >> > >>>that period. See > >>> > >> > > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > > >>519.html > >>for details. > >> > >>Please send comments to the list, copying the editor. If you reviewed > >>the draft and found no issues, please indicate so on the list. > >> > >>RjS > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Apr 27 19:22:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09932 for ; Tue, 27 Apr 2004 19:22:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbu6-0002Zp-84 for simple-archive@ietf.org; Tue, 27 Apr 2004 19:22:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbsr-0002HL-00 for simple-archive@ietf.org; Tue, 27 Apr 2004 19:21:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIbrK-00023D-03; Tue, 27 Apr 2004 19:19:27 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIbf4-00038K-Fv; Tue, 27 Apr 2004 19:06:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbZW-0003hR-Gp; Tue, 27 Apr 2004 19:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbW8-0003F7-SI for simple@optimus.ietf.org; Tue, 27 Apr 2004 18:57:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08909 for ; Tue, 27 Apr 2004 18:57:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbW3-0007lc-M0 for simple@ietf.org; Tue, 27 Apr 2004 18:57:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbVE-0007dk-00 for simple@ietf.org; Tue, 27 Apr 2004 18:56:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BIbTz-0007OJ-00 for simple@ietf.org; Tue, 27 Apr 2004 18:55:19 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2004 15:54:14 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3RMsnYu027139; Tue, 27 Apr 2004 18:54:49 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX55147; Tue, 27 Apr 2004 18:54:46 -0400 (EDT) Message-ID: <408EE4B7.2050504@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@Nokia.com CC: simple@ietf.org Subject: Re: [Simple] Open issues and changes to prescaps References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17303@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 18:54:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Mikko, I still would like to see it there, but I have the feeling it is a lost cause. The particular applications I have for this require cooperation between the publisher and the watcher, so I guess they can be handled by a proprietary pidf extension. So I guess I will give up. Paul mikko.lonnfors@Nokia.com wrote: >>Hi, >> >>Here is a list of open issues and changes that were agreed in >>Seoul. If I have missed something please let me know. We >>should get consensus on open issue(s) quite soon (hopefully >>within a week or so). >> >>Open issues: >>- Extension mechanism. Currently draft contains two extension >>mechanisms. One is XML extension mechanism (mechanism 1) and >>the other one is based on XML elements token, string, >>boolean, and numeric which allow usage of other tags that are >>not specified in callee caps (mechanism 2). We have had some >>list discussion about this topic and below I try summarize >>discussion so far: Arguments for having mechanism 2 have been >>that for some applications it might be easier to use. Using >>this mechanism applications would not need to define new XML >>namespaces for every new attribute. For applications which >>can 'dynamically' use or come up with new attributes this >>mechanism would be good. Argument for having only XML >>extension mechanism have been that for having two extension >>mechanisms may lead to some inconsistencies like same >>extension attribute could be applied using both mechanisms >>simultaneously. It has also being argued that applications >>cannot or should not use new attributes unless their >>semantics has been clearly defined. Also mechanism 1 may have >>some problems with presence authorization and filtering. > > > So far I have received no comments about this. If somebody wants to keep > the XML element (token, string, boolean, numeric) based extension > mechanism please indicate that promptly. Otherwise it will be removed > from the next revision. > > - Mikko > > >>Personally I think we can live with only XML extension >>mechanism (mechanism 1). For applications that would like to >>use extension tag this means defining a new XML schema. >>However, this may be a good thing because applications must >>in any case define some kind of semantics for new attributes >>and as far as I know this doesn't need to involve any standardization. >> >>Changes: >>- remove elements from all media type tags (voice, >>video, application, data, control, text) and change these to >>be of boolean type >> >>- Add separate element into XML schema >> >>- Remove text from section 5 which talks about adding >>Accept-Contact header based on prescaps into SIP requests. >> >> >>- Mikko >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Apr 27 19:31:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10341 for ; Tue, 27 Apr 2004 19:31:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbyY-00076e-6f for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 19:26:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RNQs6N027312 for simple-archive@odin.ietf.org; Tue, 27 Apr 2004 19:26:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbuA-0006MU-7T for simple-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 19:22:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09931 for ; Tue, 27 Apr 2004 19:22:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbu6-0002Zv-8c for simple-web-archive@ietf.org; Tue, 27 Apr 2004 19:22:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbss-0002HS-00 for simple-web-archive@ietf.org; Tue, 27 Apr 2004 19:21:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIbrK-00023D-03; Tue, 27 Apr 2004 19:19:27 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIbf4-00038K-Fv; Tue, 27 Apr 2004 19:06:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbZW-0003hR-Gp; Tue, 27 Apr 2004 19:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbW8-0003F7-SI for simple@optimus.ietf.org; Tue, 27 Apr 2004 18:57:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08909 for ; Tue, 27 Apr 2004 18:57:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbW3-0007lc-M0 for simple@ietf.org; Tue, 27 Apr 2004 18:57:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbVE-0007dk-00 for simple@ietf.org; Tue, 27 Apr 2004 18:56:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BIbTz-0007OJ-00 for simple@ietf.org; Tue, 27 Apr 2004 18:55:19 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2004 15:54:14 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3RMsnYu027139; Tue, 27 Apr 2004 18:54:49 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX55147; Tue, 27 Apr 2004 18:54:46 -0400 (EDT) Message-ID: <408EE4B7.2050504@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@Nokia.com CC: simple@ietf.org Subject: Re: [Simple] Open issues and changes to prescaps References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17303@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 18:54:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mikko, I still would like to see it there, but I have the feeling it is a lost cause. The particular applications I have for this require cooperation between the publisher and the watcher, so I guess they can be handled by a proprietary pidf extension. So I guess I will give up. Paul mikko.lonnfors@Nokia.com wrote: >>Hi, >> >>Here is a list of open issues and changes that were agreed in >>Seoul. If I have missed something please let me know. We >>should get consensus on open issue(s) quite soon (hopefully >>within a week or so). >> >>Open issues: >>- Extension mechanism. Currently draft contains two extension >>mechanisms. One is XML extension mechanism (mechanism 1) and >>the other one is based on XML elements token, string, >>boolean, and numeric which allow usage of other tags that are >>not specified in callee caps (mechanism 2). We have had some >>list discussion about this topic and below I try summarize >>discussion so far: Arguments for having mechanism 2 have been >>that for some applications it might be easier to use. Using >>this mechanism applications would not need to define new XML >>namespaces for every new attribute. For applications which >>can 'dynamically' use or come up with new attributes this >>mechanism would be good. Argument for having only XML >>extension mechanism have been that for having two extension >>mechanisms may lead to some inconsistencies like same >>extension attribute could be applied using both mechanisms >>simultaneously. It has also being argued that applications >>cannot or should not use new attributes unless their >>semantics has been clearly defined. Also mechanism 1 may have >>some problems with presence authorization and filtering. > > > So far I have received no comments about this. If somebody wants to keep > the XML element (token, string, boolean, numeric) based extension > mechanism please indicate that promptly. Otherwise it will be removed > from the next revision. > > - Mikko > > >>Personally I think we can live with only XML extension >>mechanism (mechanism 1). For applications that would like to >>use extension tag this means defining a new XML schema. >>However, this may be a good thing because applications must >>in any case define some kind of semantics for new attributes >>and as far as I know this doesn't need to involve any standardization. >> >>Changes: >>- remove elements from all media type tags (voice, >>video, application, data, control, text) and change these to >>be of boolean type >> >>- Add separate element into XML schema >> >>- Remove text from section 5 which talks about adding >>Accept-Contact header based on prescaps into SIP requests. >> >> >>- Mikko >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 28 07:55:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08700 for ; Wed, 28 Apr 2004 07:55:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInen-0000ux-5B for simple-archive@ietf.org; Wed, 28 Apr 2004 07:55:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIndl-0000bG-00 for simple-archive@ietf.org; Wed, 28 Apr 2004 07:54:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInd0-0000J7-00; Wed, 28 Apr 2004 07:53:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMY-0007i5-1i; Wed, 28 Apr 2004 07:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIj8j-0005KZ-09 for simple@optimus.ietf.org; Wed, 28 Apr 2004 03:05:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28193 for ; Wed, 28 Apr 2004 03:05:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIj8c-00018U-TQ for simple@ietf.org; Wed, 28 Apr 2004 03:05:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIj7j-0000us-00 for simple@ietf.org; Wed, 28 Apr 2004 03:04:51 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BIj7C-0000gF-00 for simple@ietf.org; Wed, 28 Apr 2004 03:04:18 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3S74FJ28986 for ; Wed, 28 Apr 2004 10:04:16 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 10:03:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3S73was011732 for ; Wed, 28 Apr 2004 10:03:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 000rod4L; Wed, 28 Apr 2004 10:00:34 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3S70QH29379 for ; Wed, 28 Apr 2004 10:00:26 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 10:00:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979B5@esebe019.ntc.nokia.com> Thread-Topic: WGLC on RPID, CIPID and future status Thread-Index: AcQs7nuIRm2/mALrSE+wzKo/hIbYJg== To: X-OriginalArrivalTime: 28 Apr 2004 07:00:25.0951 (UTC) FILETIME=[7B8726F0:01C42CEE] Content-Transfer-Encoding: quoted-printable Subject: [Simple] WGLC on RPID, CIPID and future status Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 10:00:25 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The WG chairs would like to start a Working Group Last Call on the = following drafts as part of the SIMPLE PIDF profile to be submitted to = IESG: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-03.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-01.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt This WGLC will end on May 11th. Please send your comments to this mailing list and to the authors.=20 If you reviewed the draft and found no issues, please indicate so on the = mailing list. This will help us evaluate the level of review and group = consensus. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 28 08:04:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09550 for ; Wed, 28 Apr 2004 08:04:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInnX-0003xI-Nn for simple-archive@ietf.org; Wed, 28 Apr 2004 08:04:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInmW-0003bH-00 for simple-archive@ietf.org; Wed, 28 Apr 2004 08:03:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInll-0003GQ-00; Wed, 28 Apr 2004 08:02:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInNF-0007yT-GB; Wed, 28 Apr 2004 07:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIkt6-0000Ow-Ku for simple@optimus.ietf.org; Wed, 28 Apr 2004 04:57:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01489 for ; Wed, 28 Apr 2004 04:57:49 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIkt1-0002lS-El for simple@ietf.org; Wed, 28 Apr 2004 04:57:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIks0-0002Wu-00 for simple@ietf.org; Wed, 28 Apr 2004 04:56:45 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIkrE-0002Gq-00 for simple@ietf.org; Wed, 28 Apr 2004 04:55:56 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3S8tlG23602; Wed, 28 Apr 2004 11:55:47 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 11:55:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3S8tJJJ006497; Wed, 28 Apr 2004 11:55:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 006fc1js; Wed, 28 Apr 2004 11:55:17 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3S8tGH27272; Wed, 28 Apr 2004 11:55:16 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 11:55:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Updating the XCAP PIDF manipulation draft Thread-Index: AcQpRXSJfaeMdj8oREOi+W0KDt6nlgDsJ0yg To: , Cc: , X-OriginalArrivalTime: 28 Apr 2004 08:55:15.0830 (UTC) FILETIME=[86374160:01C42CFE] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 11:55:16 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi George, Thanks for the comments. See inline: > -----Original Message----- > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > Sent: 23 April, 2004 18:09 > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); jdrosen@dynamicsoft.com > Subject: RE: Updating the XCAP PIDF manipulation draft >=20 >=20 > Hi Markus, >=20 > Here are my comments: >=20 > Second paragraph: >=20 > Replace: "but only single XCAP manipulated presence document", by > "but only single XCAP publishing source" >=20 I think this is strictly a terminology issue, and with respect to this = spec, people have preferred to use "XCAP manipulated presence document" = instead of "XCAP publishing" to avoid even further confusion with SIP = PUBLISH.=20 > Third paragraph: replace the following section=20 > "As individual inputs ................one mechanism with the other" >=20 > by the following: >=20 > "Although presence states set by XCAP, on behalf of XCAP=20 > clients, and SIP PUBLISH, on behalf of PUAs, are completely=20 > separated, conflicting information may occur within the=20 > composer for a presence state" >=20 The definition of "conflicting" information is quite vague and can be = different depending on what the actual composition scheme is. So I = believe the current text already captures the main idea, that there can = be multiple inputs, and the ESC needs to be able to deal with that. This = is pretty much what SIP PUBLISH spec says too. (Note that the support for XCAP based presence state setting is = obviously completely optional in presence systems. In some cases it = could be useful, in some others it may not be needed at all. Some use = cases are presented in the introdution chapter, but they are just = informational. So if someone thinks that XCAP based manipulation causes = more problems than what the benefits are in his particular presence = system, it can be left out. The spec just gives an opportunity to use it = for those vendors/presence providers who have good ideas how to use it = and see that SIP PUBLISH does not solve the needs properly.) Markus=20 > Rgds/gf=20 >=20 > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, April 23, 2004 10:07 AM > > To: simple@ietf.org > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com;=20 > George Foti > > (QA/EMC) > > Subject: Updating the XCAP PIDF manipulation draft > >=20 > >=20 > > Hi, > >=20 > > Me and Eva are working on an update to the XCAP PIDF=20 > > manipulation usage. Based on the earlier version there was=20 > > some confusion on the relationship of the presence state set=20 > > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with=20 > > the text below. I would like to get some feedback whether you=20 > > think it is clear enough. At least George and Jonathan have=20 > > commented the previous version, so I would especially like=20 > > your comments. > >=20 > > Chapter 1 contains the motivation, I think no changes are=20 > > needed for that. This is for Chapter 3 (the figure is unmodified): > >=20 > > --- > >=20 > > The framework for publishing presence state is introduced in=20 > > . A central part of the=20 > > framework is the event state compositor element whose=20 > > function is to compose presence information received from=20 > > serveral sources into a single coherent presence document. > >=20 > > The presence state manipulated with XCAP can be seen as one=20 > > of the information sources for the compositor to be combined=20 > > with the soft state information published using SIP PUBLISH.=20 > > This is illustrated in Figure 1. It is expected that in the=20 > > normal case there can be several PUAs publishing their=20 > > separate views with SIP PUBLISH, but only single XCAP=20 > > manipulated presence document. As shown in the figure, there > > can be multiple XCAP clients (for instance in different=20 > > physical devices) manipulating the same document on the XCAP=20 > > server, but this still creates only one input to the event=20 > > state compositor. > >=20 > > As individual inputs the presence states set by XCAP and SIP=20 > > PUBLISH are completely separated and it is not possible to=20 > > directly manipulate the state set by one mechanism with the=20 > > other. How the compositor treats XCAP based inputs with=20 > > respect to SIP PUBLISH based inputs is a matter of compositor=20 > > policy, which is beyond the scope of this specification.=20 > > Since the SIP PUBLISH specification already mandates the=20 > > compositor to be able to deal with multiple inputs, this XCAP=20 > > usage does not impose any new requirements on the compositor=20 > > functionality. =20 > >=20 > > --- > >=20 > > Regards, > > Markus > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 28 08:21:14 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11662 for ; Wed, 28 Apr 2004 08:21:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInwf-0008Dr-0S for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCDivF031602 for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIneo-000390-TY for simple-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:55:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08720 for ; Wed, 28 Apr 2004 07:55:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIneo-0000v2-3O for simple-web-archive@ietf.org; Wed, 28 Apr 2004 07:55:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIndl-0000bN-00 for simple-web-archive@ietf.org; Wed, 28 Apr 2004 07:54:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInd0-0000J7-00; Wed, 28 Apr 2004 07:53:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMY-0007i5-1i; Wed, 28 Apr 2004 07:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIj8j-0005KZ-09 for simple@optimus.ietf.org; Wed, 28 Apr 2004 03:05:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28193 for ; Wed, 28 Apr 2004 03:05:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIj8c-00018U-TQ for simple@ietf.org; Wed, 28 Apr 2004 03:05:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIj7j-0000us-00 for simple@ietf.org; Wed, 28 Apr 2004 03:04:51 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BIj7C-0000gF-00 for simple@ietf.org; Wed, 28 Apr 2004 03:04:18 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3S74FJ28986 for ; Wed, 28 Apr 2004 10:04:16 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 10:03:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3S73was011732 for ; Wed, 28 Apr 2004 10:03:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 000rod4L; Wed, 28 Apr 2004 10:00:34 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3S70QH29379 for ; Wed, 28 Apr 2004 10:00:26 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 10:00:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979B5@esebe019.ntc.nokia.com> Thread-Topic: WGLC on RPID, CIPID and future status Thread-Index: AcQs7nuIRm2/mALrSE+wzKo/hIbYJg== To: X-OriginalArrivalTime: 28 Apr 2004 07:00:25.0951 (UTC) FILETIME=[7B8726F0:01C42CEE] Content-Transfer-Encoding: quoted-printable Subject: [Simple] WGLC on RPID, CIPID and future status Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 10:00:25 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The WG chairs would like to start a Working Group Last Call on the = following drafts as part of the SIMPLE PIDF profile to be submitted to = IESG: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-03.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-01.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt This WGLC will end on May 11th. Please send your comments to this mailing list and to the authors.=20 If you reviewed the draft and found no issues, please indicate so on the = mailing list. This will help us evaluate the level of review and group = consensus. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 28 08:22:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11829 for ; Wed, 28 Apr 2004 08:22:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInxY-0000Mg-KM for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 08:14:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCEdht001359 for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 08:14:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInnZ-0005FJ-Dr for simple-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 08:04:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09568 for ; Wed, 28 Apr 2004 08:04:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInnY-0003xO-Gj for simple-web-archive@ietf.org; Wed, 28 Apr 2004 08:04:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInmX-0003bQ-00 for simple-web-archive@ietf.org; Wed, 28 Apr 2004 08:03:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInll-0003GQ-00; Wed, 28 Apr 2004 08:02:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInNF-0007yT-GB; Wed, 28 Apr 2004 07:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIkt6-0000Ow-Ku for simple@optimus.ietf.org; Wed, 28 Apr 2004 04:57:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01489 for ; Wed, 28 Apr 2004 04:57:49 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIkt1-0002lS-El for simple@ietf.org; Wed, 28 Apr 2004 04:57:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIks0-0002Wu-00 for simple@ietf.org; Wed, 28 Apr 2004 04:56:45 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIkrE-0002Gq-00 for simple@ietf.org; Wed, 28 Apr 2004 04:55:56 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3S8tlG23602; Wed, 28 Apr 2004 11:55:47 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 11:55:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3S8tJJJ006497; Wed, 28 Apr 2004 11:55:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 006fc1js; Wed, 28 Apr 2004 11:55:17 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3S8tGH27272; Wed, 28 Apr 2004 11:55:16 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 11:55:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Updating the XCAP PIDF manipulation draft Thread-Index: AcQpRXSJfaeMdj8oREOi+W0KDt6nlgDsJ0yg To: , Cc: , X-OriginalArrivalTime: 28 Apr 2004 08:55:15.0830 (UTC) FILETIME=[86374160:01C42CFE] Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 11:55:16 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi George, Thanks for the comments. See inline: > -----Original Message----- > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > Sent: 23 April, 2004 18:09 > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); jdrosen@dynamicsoft.com > Subject: RE: Updating the XCAP PIDF manipulation draft >=20 >=20 > Hi Markus, >=20 > Here are my comments: >=20 > Second paragraph: >=20 > Replace: "but only single XCAP manipulated presence document", by > "but only single XCAP publishing source" >=20 I think this is strictly a terminology issue, and with respect to this = spec, people have preferred to use "XCAP manipulated presence document" = instead of "XCAP publishing" to avoid even further confusion with SIP = PUBLISH.=20 > Third paragraph: replace the following section=20 > "As individual inputs ................one mechanism with the other" >=20 > by the following: >=20 > "Although presence states set by XCAP, on behalf of XCAP=20 > clients, and SIP PUBLISH, on behalf of PUAs, are completely=20 > separated, conflicting information may occur within the=20 > composer for a presence state" >=20 The definition of "conflicting" information is quite vague and can be = different depending on what the actual composition scheme is. So I = believe the current text already captures the main idea, that there can = be multiple inputs, and the ESC needs to be able to deal with that. This = is pretty much what SIP PUBLISH spec says too. (Note that the support for XCAP based presence state setting is = obviously completely optional in presence systems. In some cases it = could be useful, in some others it may not be needed at all. Some use = cases are presented in the introdution chapter, but they are just = informational. So if someone thinks that XCAP based manipulation causes = more problems than what the benefits are in his particular presence = system, it can be left out. The spec just gives an opportunity to use it = for those vendors/presence providers who have good ideas how to use it = and see that SIP PUBLISH does not solve the needs properly.) Markus=20 > Rgds/gf=20 >=20 > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, April 23, 2004 10:07 AM > > To: simple@ietf.org > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com;=20 > George Foti > > (QA/EMC) > > Subject: Updating the XCAP PIDF manipulation draft > >=20 > >=20 > > Hi, > >=20 > > Me and Eva are working on an update to the XCAP PIDF=20 > > manipulation usage. Based on the earlier version there was=20 > > some confusion on the relationship of the presence state set=20 > > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with=20 > > the text below. I would like to get some feedback whether you=20 > > think it is clear enough. At least George and Jonathan have=20 > > commented the previous version, so I would especially like=20 > > your comments. > >=20 > > Chapter 1 contains the motivation, I think no changes are=20 > > needed for that. This is for Chapter 3 (the figure is unmodified): > >=20 > > --- > >=20 > > The framework for publishing presence state is introduced in=20 > > . A central part of the=20 > > framework is the event state compositor element whose=20 > > function is to compose presence information received from=20 > > serveral sources into a single coherent presence document. > >=20 > > The presence state manipulated with XCAP can be seen as one=20 > > of the information sources for the compositor to be combined=20 > > with the soft state information published using SIP PUBLISH.=20 > > This is illustrated in Figure 1. It is expected that in the=20 > > normal case there can be several PUAs publishing their=20 > > separate views with SIP PUBLISH, but only single XCAP=20 > > manipulated presence document. As shown in the figure, there > > can be multiple XCAP clients (for instance in different=20 > > physical devices) manipulating the same document on the XCAP=20 > > server, but this still creates only one input to the event=20 > > state compositor. > >=20 > > As individual inputs the presence states set by XCAP and SIP=20 > > PUBLISH are completely separated and it is not possible to=20 > > directly manipulate the state set by one mechanism with the=20 > > other. How the compositor treats XCAP based inputs with=20 > > respect to SIP PUBLISH based inputs is a matter of compositor=20 > > policy, which is beyond the scope of this specification.=20 > > Since the SIP PUBLISH specification already mandates the=20 > > compositor to be able to deal with multiple inputs, this XCAP=20 > > usage does not impose any new requirements on the compositor=20 > > functionality. =20 > >=20 > > --- > >=20 > > Regards, > > Markus > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 28 09:15:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13910 for ; Wed, 28 Apr 2004 09:15:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIoui-0003Gf-DA for simple-archive@ietf.org; Wed, 28 Apr 2004 09:15:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIoti-0003CF-00 for simple-archive@ietf.org; Wed, 28 Apr 2004 09:14:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIosj-00038G-00; Wed, 28 Apr 2004 09:13:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIocC-00075h-2w; Wed, 28 Apr 2004 08:56:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIo2t-0001Z0-EG for simple@optimus.ietf.org; Wed, 28 Apr 2004 08:20:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11419 for ; Wed, 28 Apr 2004 08:20:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIo2s-0001aN-Bt for simple@ietf.org; Wed, 28 Apr 2004 08:20:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIo0u-0000xh-00 for simple@ietf.org; Wed, 28 Apr 2004 08:18:09 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BInyN-0007lB-00 for simple@ietf.org; Wed, 28 Apr 2004 08:15:31 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i3SCElLc003752; Wed, 28 Apr 2004 07:14:47 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Apr 2004 07:14:45 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C974A@lmc37.lmc.ericsson.se> From: "George Foti (QA/EMC)" To: "'Markus.Isomaki@nokia.com'" , simple@ietf.org Cc: eva-maria.leppanen@nokia.com, jdrosen@dynamicsoft.com Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 07:13:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Comments in line Markus/gf > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Markus.Isomaki@nokia.com > Sent: Wednesday, April 28, 2004 4:55 AM > To: George Foti (QA/EMC); simple@ietf.org > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com > Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft > > > Hi George, > > Thanks for the comments. See inline: > > > -----Original Message----- > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > Sent: 23 April, 2004 18:09 > > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); jdrosen@dynamicsoft.com > > Subject: RE: Updating the XCAP PIDF manipulation draft > > > > > > Hi Markus, > > > > Here are my comments: > > > > Second paragraph: > > > > Replace: "but only single XCAP manipulated presence document", by > > "but only single XCAP publishing source" > > > > I think this is strictly a terminology issue, and with > respect to this spec, people have preferred to use "XCAP > manipulated presence document" instead of "XCAP publishing" > to avoid even further confusion with SIP PUBLISH. > What is the confusion created here. The XCAP manipulated presence document will have to be published to the composer. I am merely reflecting that. If you are not happy with the wording, can you add your own words to *explicitly* reflect in the text the publishing aspects from the XCAP source for the XCAP manipulated presence document. > > Third paragraph: replace the following section > > "As individual inputs ................one mechanism with the other" > > > > by the following: > > > > "Although presence states set by XCAP, on behalf of XCAP > > clients, and SIP PUBLISH, on behalf of PUAs, are completely > > separated, conflicting information may occur within the > > composer for a presence state" > > > > The definition of "conflicting" information is quite vague > and can be different depending on what the actual composition > scheme is. So I believe the current text already captures the > main idea, that there can be multiple inputs, and the ESC > needs to be able to deal with that. This is pretty much what > SIP PUBLISH spec says too. I find the statement "ESC needs to be able to deal with that" even more vague in a spec. I was merely trying to give some examples on the potential things the ESC must deal with, rather than leaving it as is. If you are not happy with my wording, can you expand the text to give some examples of what the ESC have to deal with, given the multiple source of publishing information using SIP publisg or XCAP. I beleive this needs some more description/clarification. > > (Note that the support for XCAP based presence state setting > is obviously completely optional in presence systems. In some > cases it could be useful, in some others it may not be needed > at all. Some use cases are presented in the introdution > chapter, but they are just informational. So if someone > thinks that XCAP based manipulation causes more problems than > what the benefits are in his particular presence system, it > can be left out. The spec just gives an opportunity to use it > for those vendors/presence providers who have good ideas how > to use it and see that SIP PUBLISH does not solve the needs properly.) > > Markus > > > Rgds/gf > > > > > -----Original Message----- > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > Sent: Friday, April 23, 2004 10:07 AM > > > To: simple@ietf.org > > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com; > > George Foti > > > (QA/EMC) > > > Subject: Updating the XCAP PIDF manipulation draft > > > > > > > > > Hi, > > > > > > Me and Eva are working on an update to the XCAP PIDF > > > manipulation usage. Based on the earlier version there was > > > some confusion on the relationship of the presence state set > > > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with > > > the text below. I would like to get some feedback whether you > > > think it is clear enough. At least George and Jonathan have > > > commented the previous version, so I would especially like > > > your comments. > > > > > > Chapter 1 contains the motivation, I think no changes are > > > needed for that. This is for Chapter 3 (the figure is unmodified): > > > > > > --- > > > > > > The framework for publishing presence state is introduced in > > > . A central part of the > > > framework is the event state compositor element whose > > > function is to compose presence information received from > > > serveral sources into a single coherent presence document. > > > > > > The presence state manipulated with XCAP can be seen as one > > > of the information sources for the compositor to be combined > > > with the soft state information published using SIP PUBLISH. > > > This is illustrated in Figure 1. It is expected that in the > > > normal case there can be several PUAs publishing their > > > separate views with SIP PUBLISH, but only single XCAP > > > manipulated presence document. As shown in the figure, there > > > can be multiple XCAP clients (for instance in different > > > physical devices) manipulating the same document on the XCAP > > > server, but this still creates only one input to the event > > > state compositor. > > > > > > As individual inputs the presence states set by XCAP and SIP > > > PUBLISH are completely separated and it is not possible to > > > directly manipulate the state set by one mechanism with the > > > other. How the compositor treats XCAP based inputs with > > > respect to SIP PUBLISH based inputs is a matter of compositor > > > policy, which is beyond the scope of this specification. > > > Since the SIP PUBLISH specification already mandates the > > > compositor to be able to deal with multiple inputs, this XCAP > > > usage does not impose any new requirements on the compositor > > > functionality. > > > > > > --- > > > > > > Regards, > > > Markus > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 28 09:31:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15088 for ; Wed, 28 Apr 2004 09:31:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoye-0003nD-4T for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 09:19:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SDJqFB014575 for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 09:19:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIouk-000217-Lc for simple-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 09:15:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13928 for ; Wed, 28 Apr 2004 09:15:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIouj-0003Gl-4J for simple-web-archive@ietf.org; Wed, 28 Apr 2004 09:15:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIotj-0003CN-00 for simple-web-archive@ietf.org; Wed, 28 Apr 2004 09:14:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIosj-00038G-00; Wed, 28 Apr 2004 09:13:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIocC-00075h-2w; Wed, 28 Apr 2004 08:56:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIo2t-0001Z0-EG for simple@optimus.ietf.org; Wed, 28 Apr 2004 08:20:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11419 for ; Wed, 28 Apr 2004 08:20:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIo2s-0001aN-Bt for simple@ietf.org; Wed, 28 Apr 2004 08:20:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIo0u-0000xh-00 for simple@ietf.org; Wed, 28 Apr 2004 08:18:09 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BInyN-0007lB-00 for simple@ietf.org; Wed, 28 Apr 2004 08:15:31 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i3SCElLc003752; Wed, 28 Apr 2004 07:14:47 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Apr 2004 07:14:45 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C974A@lmc37.lmc.ericsson.se> From: "George Foti (QA/EMC)" To: "'Markus.Isomaki@nokia.com'" , simple@ietf.org Cc: eva-maria.leppanen@nokia.com, jdrosen@dynamicsoft.com Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 07:13:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Comments in line Markus/gf > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Markus.Isomaki@nokia.com > Sent: Wednesday, April 28, 2004 4:55 AM > To: George Foti (QA/EMC); simple@ietf.org > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com > Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft > > > Hi George, > > Thanks for the comments. See inline: > > > -----Original Message----- > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > Sent: 23 April, 2004 18:09 > > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); jdrosen@dynamicsoft.com > > Subject: RE: Updating the XCAP PIDF manipulation draft > > > > > > Hi Markus, > > > > Here are my comments: > > > > Second paragraph: > > > > Replace: "but only single XCAP manipulated presence document", by > > "but only single XCAP publishing source" > > > > I think this is strictly a terminology issue, and with > respect to this spec, people have preferred to use "XCAP > manipulated presence document" instead of "XCAP publishing" > to avoid even further confusion with SIP PUBLISH. > What is the confusion created here. The XCAP manipulated presence document will have to be published to the composer. I am merely reflecting that. If you are not happy with the wording, can you add your own words to *explicitly* reflect in the text the publishing aspects from the XCAP source for the XCAP manipulated presence document. > > Third paragraph: replace the following section > > "As individual inputs ................one mechanism with the other" > > > > by the following: > > > > "Although presence states set by XCAP, on behalf of XCAP > > clients, and SIP PUBLISH, on behalf of PUAs, are completely > > separated, conflicting information may occur within the > > composer for a presence state" > > > > The definition of "conflicting" information is quite vague > and can be different depending on what the actual composition > scheme is. So I believe the current text already captures the > main idea, that there can be multiple inputs, and the ESC > needs to be able to deal with that. This is pretty much what > SIP PUBLISH spec says too. I find the statement "ESC needs to be able to deal with that" even more vague in a spec. I was merely trying to give some examples on the potential things the ESC must deal with, rather than leaving it as is. If you are not happy with my wording, can you expand the text to give some examples of what the ESC have to deal with, given the multiple source of publishing information using SIP publisg or XCAP. I beleive this needs some more description/clarification. > > (Note that the support for XCAP based presence state setting > is obviously completely optional in presence systems. In some > cases it could be useful, in some others it may not be needed > at all. Some use cases are presented in the introdution > chapter, but they are just informational. So if someone > thinks that XCAP based manipulation causes more problems than > what the benefits are in his particular presence system, it > can be left out. The spec just gives an opportunity to use it > for those vendors/presence providers who have good ideas how > to use it and see that SIP PUBLISH does not solve the needs properly.) > > Markus > > > Rgds/gf > > > > > -----Original Message----- > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > Sent: Friday, April 23, 2004 10:07 AM > > > To: simple@ietf.org > > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com; > > George Foti > > > (QA/EMC) > > > Subject: Updating the XCAP PIDF manipulation draft > > > > > > > > > Hi, > > > > > > Me and Eva are working on an update to the XCAP PIDF > > > manipulation usage. Based on the earlier version there was > > > some confusion on the relationship of the presence state set > > > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with > > > the text below. I would like to get some feedback whether you > > > think it is clear enough. At least George and Jonathan have > > > commented the previous version, so I would especially like > > > your comments. > > > > > > Chapter 1 contains the motivation, I think no changes are > > > needed for that. This is for Chapter 3 (the figure is unmodified): > > > > > > --- > > > > > > The framework for publishing presence state is introduced in > > > . A central part of the > > > framework is the event state compositor element whose > > > function is to compose presence information received from > > > serveral sources into a single coherent presence document. > > > > > > The presence state manipulated with XCAP can be seen as one > > > of the information sources for the compositor to be combined > > > with the soft state information published using SIP PUBLISH. > > > This is illustrated in Figure 1. It is expected that in the > > > normal case there can be several PUAs publishing their > > > separate views with SIP PUBLISH, but only single XCAP > > > manipulated presence document. As shown in the figure, there > > > can be multiple XCAP clients (for instance in different > > > physical devices) manipulating the same document on the XCAP > > > server, but this still creates only one input to the event > > > state compositor. > > > > > > As individual inputs the presence states set by XCAP and SIP > > > PUBLISH are completely separated and it is not possible to > > > directly manipulate the state set by one mechanism with the > > > other. How the compositor treats XCAP based inputs with > > > respect to SIP PUBLISH based inputs is a matter of compositor > > > policy, which is beyond the scope of this specification. > > > Since the SIP PUBLISH specification already mandates the > > > compositor to be able to deal with multiple inputs, this XCAP > > > usage does not impose any new requirements on the compositor > > > functionality. > > > > > > --- > > > > > > Regards, > > > Markus > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 28 13:01:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28763 for ; Wed, 28 Apr 2004 13:01:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsR3-0006v9-Vw for simple-archive@ietf.org; Wed, 28 Apr 2004 13:01:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsQ6-0006rw-00 for simple-archive@ietf.org; Wed, 28 Apr 2004 13:00:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsPK-0006pZ-00; Wed, 28 Apr 2004 12:59:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsCD-0005J2-7a; Wed, 28 Apr 2004 12:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs3I-0002v4-9W for simple@optimus.ietf.org; Wed, 28 Apr 2004 12:36:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27137 for ; Wed, 28 Apr 2004 12:36:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIs3F-0005T1-44 for simple@ietf.org; Wed, 28 Apr 2004 12:36:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs2J-0005Re-00 for simple@ietf.org; Wed, 28 Apr 2004 12:35:52 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1BIs1s-0005Ps-00 for simple@ietf.org; Wed, 28 Apr 2004 12:35:24 -0400 Received: from softarmor.com (port-213-160-6-4.reverse.qsc.de [213.160.6.4]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i3SGaEu4003671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2004 11:36:16 -0500 Message-ID: <408FDD2F.8070405@softarmor.com> From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com, jose.costa-requena@nokia.com CC: simple@ietf.org, Robert Sparks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-partial-notify-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 11:34:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I have a couple of non-fundamental observations on the partial notify draft. Obs 1: Overall style challenge: Overuse of requirements language in descriptive passages. People tend to use RFC 2119 requirements language when describing how things work, rather than when describing actual requirements. This is subtle, and many (most?) people don't understand the difference. You can probably get away with ignoring me here, but it might be worth thinking about. It has big implications on the establishment of formal compatibility documents -- when people say "MUST" everytime they mean "does", it makes the real requirements hard to identify. As an example, the text in this draft: 4.4 Presence agent generation of partial notifications If the presence agent decides to send notifications according to this specification that include a presence document, the presence agent MUST build a presence document according to the PIDF extension for Partial Presence [2] and MUST set the Content-Type header field to the value 'application/pidf-partial+xml'. Tuple ids are used to match tuples across subsequent notifications. Presence agent MUST use the same tuple ids for tuples which are identical between subsequent notifications and MUST allocate different tuple ids for tuples which are different from previously sent tuples. Presence agents MUST keep tuple ids consistent until the next full state presence documentis delivered. The decision on whether tuple ids are the same or different is left up to PA's local policy. Would perhaps be more clearly written as: 4.4 Presence agent generation of partial notifications If the presence agent decides to send partial notifications in response to this subscription, it constructs the partial presence documents as specified in the PIDF extension for Partial Presence [2]. As required by [2], the presence agent sets the Content-Type header field of each partial presence document to the value 'application/pidf-partial+xml'. Further requirements apply to partial presence documents, as follow: Tuple ids are used by clients to match tuples across subsequent notifications. For this matching to succeed, the Presence Agent MUST not vary the tuple ids for tuples that have not changed since they were previously sent on this subscription and and MUST allocate different tuple ids for tuples that are different from previously sent tuples. Presence agents MUST keep tuple ids consistent until the next full-state presence document has been sent and acknowledged. The decision on whether tuple ids are the same or different in the next full-state presence document is left up to PA's local policy. In the first paragraph, we are describing how the presence agent does something by way of example. In the second and third, we are stating requirements that vary from the general way of building presence documents, i.e, "new requirements". I've also polished the English slightly. Obs 2: Section 5: ... The PA accepts the subscription and, based on the "q" parameter value, selects to send ... The phrase "selects to send" is a bit awkward as English construction. "Selects" has the connotation of choosing from a menu, which is not quite what we want here. "Decides to send" might work better. Whatever you choose should align with the wording you've decided to use in the (elsewhere discussed) discussion of how the server decided whether or not it was going to provide partial notifications for this subscription. Obs 3: Use of domain names in examples: Some examples use domain names in "somewhere.com". This probably needs to be changed to a domain reserved in RFC 2606. Perhaps ".test"? After all, "somewhere.com" is a real domain: Somewhere.Com, LLC 25 Forest Circle Winchester, MA 01890 US -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 28 13:22:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00512 for ; Wed, 28 Apr 2004 13:22:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsWE-0001Xt-JA for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 13:06:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SH6khV005934 for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 13:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsR8-00008P-0A for simple-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:01:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28778 for ; Wed, 28 Apr 2004 13:01:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsR4-0006vF-R4 for simple-web-archive@ietf.org; Wed, 28 Apr 2004 13:01:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsQ7-0006s3-00 for simple-web-archive@ietf.org; Wed, 28 Apr 2004 13:00:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsPK-0006pZ-00; Wed, 28 Apr 2004 12:59:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsCD-0005J2-7a; Wed, 28 Apr 2004 12:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs3I-0002v4-9W for simple@optimus.ietf.org; Wed, 28 Apr 2004 12:36:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27137 for ; Wed, 28 Apr 2004 12:36:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIs3F-0005T1-44 for simple@ietf.org; Wed, 28 Apr 2004 12:36:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs2J-0005Re-00 for simple@ietf.org; Wed, 28 Apr 2004 12:35:52 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1BIs1s-0005Ps-00 for simple@ietf.org; Wed, 28 Apr 2004 12:35:24 -0400 Received: from softarmor.com (port-213-160-6-4.reverse.qsc.de [213.160.6.4]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i3SGaEu4003671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2004 11:36:16 -0500 Message-ID: <408FDD2F.8070405@softarmor.com> From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com, jose.costa-requena@nokia.com CC: simple@ietf.org, Robert Sparks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-partial-notify-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 11:34:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have a couple of non-fundamental observations on the partial notify draft. Obs 1: Overall style challenge: Overuse of requirements language in descriptive passages. People tend to use RFC 2119 requirements language when describing how things work, rather than when describing actual requirements. This is subtle, and many (most?) people don't understand the difference. You can probably get away with ignoring me here, but it might be worth thinking about. It has big implications on the establishment of formal compatibility documents -- when people say "MUST" everytime they mean "does", it makes the real requirements hard to identify. As an example, the text in this draft: 4.4 Presence agent generation of partial notifications If the presence agent decides to send notifications according to this specification that include a presence document, the presence agent MUST build a presence document according to the PIDF extension for Partial Presence [2] and MUST set the Content-Type header field to the value 'application/pidf-partial+xml'. Tuple ids are used to match tuples across subsequent notifications. Presence agent MUST use the same tuple ids for tuples which are identical between subsequent notifications and MUST allocate different tuple ids for tuples which are different from previously sent tuples. Presence agents MUST keep tuple ids consistent until the next full state presence documentis delivered. The decision on whether tuple ids are the same or different is left up to PA's local policy. Would perhaps be more clearly written as: 4.4 Presence agent generation of partial notifications If the presence agent decides to send partial notifications in response to this subscription, it constructs the partial presence documents as specified in the PIDF extension for Partial Presence [2]. As required by [2], the presence agent sets the Content-Type header field of each partial presence document to the value 'application/pidf-partial+xml'. Further requirements apply to partial presence documents, as follow: Tuple ids are used by clients to match tuples across subsequent notifications. For this matching to succeed, the Presence Agent MUST not vary the tuple ids for tuples that have not changed since they were previously sent on this subscription and and MUST allocate different tuple ids for tuples that are different from previously sent tuples. Presence agents MUST keep tuple ids consistent until the next full-state presence document has been sent and acknowledged. The decision on whether tuple ids are the same or different in the next full-state presence document is left up to PA's local policy. In the first paragraph, we are describing how the presence agent does something by way of example. In the second and third, we are stating requirements that vary from the general way of building presence documents, i.e, "new requirements". I've also polished the English slightly. Obs 2: Section 5: ... The PA accepts the subscription and, based on the "q" parameter value, selects to send ... The phrase "selects to send" is a bit awkward as English construction. "Selects" has the connotation of choosing from a menu, which is not quite what we want here. "Decides to send" might work better. Whatever you choose should align with the wording you've decided to use in the (elsewhere discussed) discussion of how the server decided whether or not it was going to provide partial notifications for this subscription. Obs 3: Use of domain names in examples: Some examples use domain names in "somewhere.com". This probably needs to be changed to a domain reserved in RFC 2606. Perhaps ".test"? After all, "somewhere.com" is a real domain: Somewhere.Com, LLC 25 Forest Circle Winchester, MA 01890 US -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Apr 28 17:55:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26132 for ; Wed, 28 Apr 2004 17:55:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIx1L-0003V2-Hg for simple-archive@ietf.org; Wed, 28 Apr 2004 17:55:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwz2-000343-00 for simple-archive@ietf.org; Wed, 28 Apr 2004 17:52:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwx3-0002dE-01; Wed, 28 Apr 2004 17:50:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIwoa-0001tM-87; Wed, 28 Apr 2004 17:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwSW-0000os-Bg; Wed, 28 Apr 2004 17:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISUJ-0000C3-Rb for simple@optimus.ietf.org; Tue, 27 Apr 2004 09:19:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29359 for ; Tue, 27 Apr 2004 09:18:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISUE-0004nw-8s for simple@ietf.org; Tue, 27 Apr 2004 09:18:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISTK-0004a6-00 for simple@ietf.org; Tue, 27 Apr 2004 09:18:02 -0400 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1BISSt-0004Lp-00 for simple@ietf.org; Tue, 27 Apr 2004 09:17:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on isComposing draft Message-ID: Thread-Topic: [Simple] WGLC on isComposing draft Thread-Index: AcQnn8nsMEVcsGTYTZeoEy+h9hyXwQEtY/2Q From: "Christian Jansson" To: , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 15:17:06 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable - The text refers to the element, but the schema defines the element name to "lastactive". - There is a XX in "2. Terminology and Conventions" which should probably be something else. / Christian Jansson, Hotsip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Apr 28 18:18:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28914 for ; Wed, 28 Apr 2004 18:18:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxJV-0002bv-Em for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 18:13:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMDvBA010029 for simple-archive@odin.ietf.org; Wed, 28 Apr 2004 18:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIx1Q-0008Eb-1T for simple-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 17:55:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26150 for ; Wed, 28 Apr 2004 17:55:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIx1M-0003V7-6y for simple-web-archive@ietf.org; Wed, 28 Apr 2004 17:55:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwz3-00034B-00 for simple-web-archive@ietf.org; Wed, 28 Apr 2004 17:52:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwx3-0002dE-01; Wed, 28 Apr 2004 17:50:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIwoa-0001tM-87; Wed, 28 Apr 2004 17:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwSW-0000os-Bg; Wed, 28 Apr 2004 17:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISUJ-0000C3-Rb for simple@optimus.ietf.org; Tue, 27 Apr 2004 09:19:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29359 for ; Tue, 27 Apr 2004 09:18:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISUE-0004nw-8s for simple@ietf.org; Tue, 27 Apr 2004 09:18:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISTK-0004a6-00 for simple@ietf.org; Tue, 27 Apr 2004 09:18:02 -0400 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 1BISSt-0004Lp-00 for simple@ietf.org; Tue, 27 Apr 2004 09:17:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC on isComposing draft Message-ID: Thread-Topic: [Simple] WGLC on isComposing draft Thread-Index: AcQnn8nsMEVcsGTYTZeoEy+h9hyXwQEtY/2Q From: "Christian Jansson" To: , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 15:17:06 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable - The text refers to the element, but the schema defines the element name to "lastactive". - There is a XX in "2. Terminology and Conventions" which should probably be something else. / Christian Jansson, Hotsip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 08:23:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23781 for ; Thu, 29 Apr 2004 08:23:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAZN-0003WM-5w for simple-archive@ietf.org; Thu, 29 Apr 2004 08:23:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAYQ-0003Jg-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 08:22:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJAXY-000385-00; Thu, 29 Apr 2004 08:21:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAQT-0000Rp-Pv; Thu, 29 Apr 2004 08:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAI8-00076x-Bv for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:05:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23071 for ; Thu, 29 Apr 2004 08:05:17 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAHy-0007Ze-LB for simple@ietf.org; Thu, 29 Apr 2004 08:05:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAGv-0007NY-00 for simple@ietf.org; Thu, 29 Apr 2004 08:04:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJAG4-0007C0-00 for simple@ietf.org; Thu, 29 Apr 2004 08:03:16 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TC3Fv01608; Thu, 29 Apr 2004 15:03:15 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:02:59 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TC2xIL016996; Thu, 29 Apr 2004 15:02:59 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00tOJq0l; Thu, 29 Apr 2004 15:02:58 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TC2vH14412; Thu, 29 Apr 2004 15:02:57 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:02:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DEBB@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAadfZ4A== To: , , X-OriginalArrivalTime: 29 Apr 2004 12:02:51.0231 (UTC) FILETIME=[E55EE6F0:01C42DE1] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:02:51 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I would like to hear what others think about this proposal. Especially, if you think it will not work in some situations. If this works and we choose to adopt the proposed solution where are probably some other consequences. At a moment PA MUST keep tuple ids consistent between two "full" state documents. Now, if the version cycle will be tied to the subscription PA/UA must apply a bit different logic how tuple ids and "version" numbers are generated. My proposal in this case would be to also keep tuple ids consistent within a subscription. - Mikko=20 >=20 > Here is an example where both state and version are needed: >=20 > PA sends N1(full), N2(full), N3(partial). >=20 > If the version is set to 0 everytime there is full state, and=20 > N2 was never received, the subscriber would then think that=20 > N3 is a partial of N1. >=20 > To solve this, you need the version to continuously increase=20 > by 1, even when a full state is being sent. You would then=20 > also need the state attribute to indicate full/partial. The=20 > version is used by the subscriber to learn that a NOTIFY was=20 > not received (N2). >=20 > /Hisham >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > ext mikko.lonnfors@nokia.com > > Sent: 26.April.2004 22:17 > > To: rsparks@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Hi, > >=20 > > Thanks for comments. Responses inline: > >=20 > > > Writing as a WG member - not as chair - > > >=20 > > > I've sent a list of typo level nits in these drafts to > > Mikko privately > >=20 > > > - > > >=20 > > > While doing a nit review, I found some things that should have > > > received list attention earlier. > > >=20 > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > construct the > >=20 > > > partial presence document according to the following > > logic:" followed > > > by a bunch of MUST level statements. Why is that SHOULD=20 > there? What > > > would it mean to violate it? I suggest striking it and=20 > > simply saying > > > "The PA constructs" > >=20 > > Yes, SHOULD is probably useless and confusing here. I will=20 > remove it. > >=20 > > > Why do we have both "state" and "version"? As defined in > > these drafts, > >=20 > > > state=3Dfull if and only if version=3D0. You could delete the = state > > > parameter with no loss of information, so why is it there? > >=20 > > I believe the original need for the "state" was that the > > "version" could > > be initialized to some random value. Now, if "version" is always > > initialized to 0 there is no need for the "state" attribute. Both > > solutions should work and if nobody else comments otherwise I will > > remove the "state" attribute. > >=20 > > > 3261 currently allows overlapping non-INVITE transactions inside a > > > dialog (there's an open issue suggesting this might be a=20 > bad thing,=20 > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > probably manageable. For partial state documents, at least as=20 > > > they are specified here, it could be disastrous. Consider=20 > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > If the recipient receives only N1 and N4 (something prevents=20 > > > N2 and N3 from being delivered or simply delays them=20 > > > (packetloss over UDP for example)), it will apply the delta=20 > > > in N4 to the wrong full state document (N1 instead of N3).=20 > >=20 > > Actually it wouldn't because of "version" handling. Section > > 4.5 applies > > here. But in any case this kind of behavior is quite bad as it might > > result in frequent subscription refreshes to obtain full=20 > > presence state. > > More below. > >=20 > > > We > > > can preserve the properties of the existing system is we forbid=20 > > > sending a NOTIFY with a document with state=3D"partial"=20 > when any other=20 > > > NOTIFY transaction is still in progress on > > this dialog. > >=20 > > This is a good point. Your proposed solution should work. > > This may cause > > some extra implementation effort for PA but I cannot see any=20 > > way around > > this. If no other comments are received I will add text forbidding > > sending a NOTIFY with a document with state=3D"partial"=20 > (version=3D0) when > > any other NOTIFY transaction is still in progress on this dialog.=20 > >=20 > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > presence document whose "version" attribute value (is) higher by=20 > > > more than one with the locally stored value, the watcher assumes=20 > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > refresh the subscription in order to receive a full presence=20 > > > document or terminate the subscription." Why is that SHOULD? In=20 > > > what scenario is any other course of action reasonable? (The only=20 > > > one I can think of is _if_ we allow overlapping partial NOTIFYs,=20 > > > then the watcher can wait around for awhile for the gaps=20 > to fill in=20 > > > - if we allow this, then we need to explicitly state this as > > > why the above is SHOULD, not MUST. However, I think this=20 > > > should be a MUST.) > >=20 > > Well, there probably isn't any good cases where watcher wouldn't=20 > > terminate or refresh subscription. Changing SHOULD to MUST should=20 > > provide more consistent behavior. > > =20 > > > Just below that, there's a "SHOULD discard the document" if > > > it gets a partial notification with a lower version number. I=20 > > > don't see how this is right at all, and suggest that this=20 > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > - the CSeq processing logic would=20 > > > have caught it). > >=20 > > Right, and if we don't allow sending new NOTIFYs if there=20 > is a pending=20 > > transaction then I believe reordering should never happen.=20 > But if in=20 > > this situation watcher receives a presence document with=20 > lower version=20 > > number there should be no harm in discarding it because it=20 > already has=20 > > a consistent presence state. This is more or less an error=20 > case which > > probably should never happen but I think there is no need to=20 > > refresh or > > terminate the subscription. > >=20 > > - Mikko > >=20 > > > I'll send a separate message on the Security Considerations > > > section for -partial-notify. > > >=20 > > > RjS > > >=20 > > >=20 > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > This is a Working Group Last call on the following drafts: > > > >=20 > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-> > > ietf-simple-partial-notify-0 > > > > 2.txt > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > pidf-format-01.txt > > >=20 > > > This abbreviated WGLC will end on Wednesday, April 28. > > >=20 > > > These drafts went through a previous last call at the beginning of > > > March. These versions reflect changes due to comments=20 > > received during > > > that period. See > > >=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > >=20 > > Please send comments to the list, copying the editor. If=20 > you reviewed > > the draft and found no issues, please indicate so on the list. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 08:32:53 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24858 for ; Thu, 29 Apr 2004 08:32:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAcJ-0003Cu-Op for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 08:26:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TCQFAp012328 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 08:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAZZ-0002PS-QL for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 08:23:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23799 for ; Thu, 29 Apr 2004 08:23:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAZP-0003Wr-QV for simple-web-archive@ietf.org; Thu, 29 Apr 2004 08:23:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAYR-0003Jp-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 08:22:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJAXY-000385-00; Thu, 29 Apr 2004 08:21:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAQT-0000Rp-Pv; Thu, 29 Apr 2004 08:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAI8-00076x-Bv for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:05:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23071 for ; Thu, 29 Apr 2004 08:05:17 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAHy-0007Ze-LB for simple@ietf.org; Thu, 29 Apr 2004 08:05:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAGv-0007NY-00 for simple@ietf.org; Thu, 29 Apr 2004 08:04:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJAG4-0007C0-00 for simple@ietf.org; Thu, 29 Apr 2004 08:03:16 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TC3Fv01608; Thu, 29 Apr 2004 15:03:15 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:02:59 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TC2xIL016996; Thu, 29 Apr 2004 15:02:59 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00tOJq0l; Thu, 29 Apr 2004 15:02:58 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TC2vH14412; Thu, 29 Apr 2004 15:02:57 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:02:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DEBB@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAadfZ4A== To: , , X-OriginalArrivalTime: 29 Apr 2004 12:02:51.0231 (UTC) FILETIME=[E55EE6F0:01C42DE1] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:02:51 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I would like to hear what others think about this proposal. Especially, if you think it will not work in some situations. If this works and we choose to adopt the proposed solution where are probably some other consequences. At a moment PA MUST keep tuple ids consistent between two "full" state documents. Now, if the version cycle will be tied to the subscription PA/UA must apply a bit different logic how tuple ids and "version" numbers are generated. My proposal in this case would be to also keep tuple ids consistent within a subscription. - Mikko=20 >=20 > Here is an example where both state and version are needed: >=20 > PA sends N1(full), N2(full), N3(partial). >=20 > If the version is set to 0 everytime there is full state, and=20 > N2 was never received, the subscriber would then think that=20 > N3 is a partial of N1. >=20 > To solve this, you need the version to continuously increase=20 > by 1, even when a full state is being sent. You would then=20 > also need the state attribute to indicate full/partial. The=20 > version is used by the subscriber to learn that a NOTIFY was=20 > not received (N2). >=20 > /Hisham >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > ext mikko.lonnfors@nokia.com > > Sent: 26.April.2004 22:17 > > To: rsparks@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Hi, > >=20 > > Thanks for comments. Responses inline: > >=20 > > > Writing as a WG member - not as chair - > > >=20 > > > I've sent a list of typo level nits in these drafts to > > Mikko privately > >=20 > > > - > > >=20 > > > While doing a nit review, I found some things that should have > > > received list attention earlier. > > >=20 > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > construct the > >=20 > > > partial presence document according to the following > > logic:" followed > > > by a bunch of MUST level statements. Why is that SHOULD=20 > there? What > > > would it mean to violate it? I suggest striking it and=20 > > simply saying > > > "The PA constructs" > >=20 > > Yes, SHOULD is probably useless and confusing here. I will=20 > remove it. > >=20 > > > Why do we have both "state" and "version"? As defined in > > these drafts, > >=20 > > > state=3Dfull if and only if version=3D0. You could delete the = state > > > parameter with no loss of information, so why is it there? > >=20 > > I believe the original need for the "state" was that the > > "version" could > > be initialized to some random value. Now, if "version" is always > > initialized to 0 there is no need for the "state" attribute. Both > > solutions should work and if nobody else comments otherwise I will > > remove the "state" attribute. > >=20 > > > 3261 currently allows overlapping non-INVITE transactions inside a > > > dialog (there's an open issue suggesting this might be a=20 > bad thing,=20 > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > probably manageable. For partial state documents, at least as=20 > > > they are specified here, it could be disastrous. Consider=20 > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > If the recipient receives only N1 and N4 (something prevents=20 > > > N2 and N3 from being delivered or simply delays them=20 > > > (packetloss over UDP for example)), it will apply the delta=20 > > > in N4 to the wrong full state document (N1 instead of N3).=20 > >=20 > > Actually it wouldn't because of "version" handling. Section > > 4.5 applies > > here. But in any case this kind of behavior is quite bad as it might > > result in frequent subscription refreshes to obtain full=20 > > presence state. > > More below. > >=20 > > > We > > > can preserve the properties of the existing system is we forbid=20 > > > sending a NOTIFY with a document with state=3D"partial"=20 > when any other=20 > > > NOTIFY transaction is still in progress on > > this dialog. > >=20 > > This is a good point. Your proposed solution should work. > > This may cause > > some extra implementation effort for PA but I cannot see any=20 > > way around > > this. If no other comments are received I will add text forbidding > > sending a NOTIFY with a document with state=3D"partial"=20 > (version=3D0) when > > any other NOTIFY transaction is still in progress on this dialog.=20 > >=20 > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > presence document whose "version" attribute value (is) higher by=20 > > > more than one with the locally stored value, the watcher assumes=20 > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > refresh the subscription in order to receive a full presence=20 > > > document or terminate the subscription." Why is that SHOULD? In=20 > > > what scenario is any other course of action reasonable? (The only=20 > > > one I can think of is _if_ we allow overlapping partial NOTIFYs,=20 > > > then the watcher can wait around for awhile for the gaps=20 > to fill in=20 > > > - if we allow this, then we need to explicitly state this as > > > why the above is SHOULD, not MUST. However, I think this=20 > > > should be a MUST.) > >=20 > > Well, there probably isn't any good cases where watcher wouldn't=20 > > terminate or refresh subscription. Changing SHOULD to MUST should=20 > > provide more consistent behavior. > > =20 > > > Just below that, there's a "SHOULD discard the document" if > > > it gets a partial notification with a lower version number. I=20 > > > don't see how this is right at all, and suggest that this=20 > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > - the CSeq processing logic would=20 > > > have caught it). > >=20 > > Right, and if we don't allow sending new NOTIFYs if there=20 > is a pending=20 > > transaction then I believe reordering should never happen.=20 > But if in=20 > > this situation watcher receives a presence document with=20 > lower version=20 > > number there should be no harm in discarding it because it=20 > already has=20 > > a consistent presence state. This is more or less an error=20 > case which > > probably should never happen but I think there is no need to=20 > > refresh or > > terminate the subscription. > >=20 > > - Mikko > >=20 > > > I'll send a separate message on the Security Considerations > > > section for -partial-notify. > > >=20 > > > RjS > > >=20 > > >=20 > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > This is a Working Group Last call on the following drafts: > > > >=20 > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-> > > ietf-simple-partial-notify-0 > > > > 2.txt > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > pidf-format-01.txt > > >=20 > > > This abbreviated WGLC will end on Wednesday, April 28. > > >=20 > > > These drafts went through a previous last call at the beginning of > > > March. These versions reflect changes due to comments=20 > > received during > > > that period. See > > >=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > >=20 > > Please send comments to the list, copying the editor. If=20 > you reviewed > > the draft and found no issues, please indicate so on the list. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 09:20:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29764 for ; Thu, 29 Apr 2004 09:20:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBSZ-0004AE-Tv for simple-archive@ietf.org; Thu, 29 Apr 2004 09:20:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBQj-0003fS-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 09:18:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBOu-0003Co-00; Thu, 29 Apr 2004 09:16:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBEp-00017P-N8; Thu, 29 Apr 2004 09:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAlg-0005lt-VE for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:35:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25093 for ; Thu, 29 Apr 2004 08:35:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAlW-0006r4-Qd for simple@ietf.org; Thu, 29 Apr 2004 08:35:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAkJ-0006WP-00 for simple@ietf.org; Thu, 29 Apr 2004 08:34:32 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BJAjK-0006DJ-00 for simple@ietf.org; Thu, 29 Apr 2004 08:33:30 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCXUG29006; Thu, 29 Apr 2004 15:33:30 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:33:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCXRiQ032423; Thu, 29 Apr 2004 15:33:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00CY02XV; Thu, 29 Apr 2004 15:33:26 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCXCH08730; Thu, 29 Apr 2004 15:33:12 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:33:12 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979E3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAadfZ4AAAYYMg To: , , X-OriginalArrivalTime: 29 Apr 2004 12:33:12.0251 (UTC) FILETIME=[22C880B0:01C42DE6] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:33:12 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Why does that matter? If it is full state, the tuple ids can remain the same or be different. A full state NOTIFY replaces the whole state at the subscriber side anyway. The only requirement now is that the subscriber must ensure the next NOTIFY (carrying partial or full state) only has the version increased by 1. If it is increased by more than 1, then something was lost. /Hisham > -----Original Message----- > From: Lonnfors Mikko (Nokia-NRC/Helsinki)=20 > Sent: 29.April.2004 15:03 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Hi, >=20 > I would like to hear what others think about this proposal.=20 > Especially, if you think it will not work in some situations. > If this works and we choose to adopt the proposed solution=20 > where are probably some other consequences. At a moment PA=20 > MUST keep tuple ids consistent between two "full" state=20 > documents. Now, if the version cycle will be tied to the=20 > subscription PA/UA must apply a bit different logic how tuple=20 > ids and "version" numbers are generated. My proposal in this=20 > case would be to also keep tuple ids consistent within a subscription. >=20 > - Mikko=20 >=20 > >=20 > > Here is an example where both state and version are needed: > >=20 > > PA sends N1(full), N2(full), N3(partial). > >=20 > > If the version is set to 0 everytime there is full state, and=20 > > N2 was never received, the subscriber would then think that=20 > > N3 is a partial of N1. > >=20 > > To solve this, you need the version to continuously increase=20 > > by 1, even when a full state is being sent. You would then=20 > > also need the state attribute to indicate full/partial. The=20 > > version is used by the subscriber to learn that a NOTIFY was=20 > > not received (N2). > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org=20 > > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > > ext mikko.lonnfors@nokia.com > > > Sent: 26.April.2004 22:17 > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > Subject: RE: [Simple] WGLC: partial notification > > >=20 > > >=20 > > > Hi, > > >=20 > > > Thanks for comments. Responses inline: > > >=20 > > > > Writing as a WG member - not as chair - > > > >=20 > > > > I've sent a list of typo level nits in these drafts to > > > Mikko privately > > >=20 > > > > - > > > >=20 > > > > While doing a nit review, I found some things that should have > > > > received list attention earlier. > > > >=20 > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > construct the > > >=20 > > > > partial presence document according to the following > > > logic:" followed > > > > by a bunch of MUST level statements. Why is that SHOULD=20 > > there? What > > > > would it mean to violate it? I suggest striking it and=20 > > > simply saying > > > > "The PA constructs" > > >=20 > > > Yes, SHOULD is probably useless and confusing here. I will=20 > > remove it. > > >=20 > > > > Why do we have both "state" and "version"? As defined in > > > these drafts, > > >=20 > > > > state=3Dfull if and only if version=3D0. You could delete the = state > > > > parameter with no loss of information, so why is it there? > > >=20 > > > I believe the original need for the "state" was that the > > > "version" could > > > be initialized to some random value. Now, if "version" is always > > > initialized to 0 there is no need for the "state" attribute. Both > > > solutions should work and if nobody else comments otherwise I will > > > remove the "state" attribute. > > >=20 > > > > 3261 currently allows overlapping non-INVITE=20 > transactions inside a > > > > dialog (there's an open issue suggesting this might be a=20 > > bad thing,=20 > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > > probably manageable. For partial state documents, at least as=20 > > > > they are specified here, it could be disastrous. Consider=20 > > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > > If the recipient receives only N1 and N4 (something prevents=20 > > > > N2 and N3 from being delivered or simply delays them=20 > > > > (packetloss over UDP for example)), it will apply the delta=20 > > > > in N4 to the wrong full state document (N1 instead of N3).=20 > > >=20 > > > Actually it wouldn't because of "version" handling. Section > > > 4.5 applies > > > here. But in any case this kind of behavior is quite bad=20 > as it might > > > result in frequent subscription refreshes to obtain full=20 > > > presence state. > > > More below. > > >=20 > > > > We > > > > can preserve the properties of the existing system is we forbid=20 > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > when any other=20 > > > > NOTIFY transaction is still in progress on > > > this dialog. > > >=20 > > > This is a good point. Your proposed solution should work. > > > This may cause > > > some extra implementation effort for PA but I cannot see any=20 > > > way around > > > this. If no other comments are received I will add text forbidding > > > sending a NOTIFY with a document with state=3D"partial"=20 > > (version=3D0) when > > > any other NOTIFY transaction is still in progress on this dialog.=20 > > >=20 > > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > > presence document whose "version" attribute value (is)=20 > higher by=20 > > > > more than one with the locally stored value, the=20 > watcher assumes=20 > > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > > refresh the subscription in order to receive a full presence=20 > > > > document or terminate the subscription." Why is that=20 > SHOULD? In=20 > > > > what scenario is any other course of action reasonable?=20 > (The only=20 > > > > one I can think of is _if_ we allow overlapping partial=20 > NOTIFYs,=20 > > > > then the watcher can wait around for awhile for the gaps=20 > > to fill in=20 > > > > - if we allow this, then we need to explicitly state this as > > > > why the above is SHOULD, not MUST. However, I think this=20 > > > > should be a MUST.) > > >=20 > > > Well, there probably isn't any good cases where watcher wouldn't=20 > > > terminate or refresh subscription. Changing SHOULD to MUST should=20 > > > provide more consistent behavior. > > > =20 > > > > Just below that, there's a "SHOULD discard the document" if > > > > it gets a partial notification with a lower version number. I=20 > > > > don't see how this is right at all, and suggest that this=20 > > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > > - the CSeq processing logic would=20 > > > > have caught it). > > >=20 > > > Right, and if we don't allow sending new NOTIFYs if there=20 > > is a pending=20 > > > transaction then I believe reordering should never happen.=20 > > But if in=20 > > > this situation watcher receives a presence document with=20 > > lower version=20 > > > number there should be no harm in discarding it because it=20 > > already has=20 > > > a consistent presence state. This is more or less an error=20 > > case which > > > probably should never happen but I think there is no need to=20 > > > refresh or > > > terminate the subscription. > > >=20 > > > - Mikko > > >=20 > > > > I'll send a separate message on the Security Considerations > > > > section for -partial-notify. > > > >=20 > > > > RjS > > > >=20 > > > >=20 > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > This is a Working Group Last call on the following drafts: > > > > >=20 > > > > >=20 > > > > http://www.ietf.org/internet-drafts/draft-> > > > ietf-simple-partial-notify-0 > > > > > 2.txt > > > > >=20 > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > pidf-format-01.txt > > > >=20 > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > >=20 > > > > These drafts went through a previous last call at the=20 > beginning of > > > > March. These versions reflect changes due to comments=20 > > > received during > > > > that period. See > > > >=20 > >=20 https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > >=20 > > Please send comments to the list, copying the editor. If=20 > you reviewed > > the draft and found no issues, please indicate so on the list. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 09:22:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00025 for ; Thu, 29 Apr 2004 09:22:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBUr-0004ux-W6 for simple-archive@ietf.org; Thu, 29 Apr 2004 09:22:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBTR-0004My-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 09:21:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBRh-0003wR-00; Thu, 29 Apr 2004 09:19:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBF5-0001J0-UP; Thu, 29 Apr 2004 09:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJApw-0006hX-2h for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25586 for ; Thu, 29 Apr 2004 08:40:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJApl-0000UT-T7 for simple@ietf.org; Thu, 29 Apr 2004 08:40:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAoQ-0007ln-00 for simple@ietf.org; Thu, 29 Apr 2004 08:38:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJAml-0007EC-00 for simple@ietf.org; Thu, 29 Apr 2004 08:37:03 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCb3v16334; Thu, 29 Apr 2004 15:37:03 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:36:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCau2q012258; Thu, 29 Apr 2004 15:36:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00VfWuWT; Thu, 29 Apr 2004 15:36:55 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCasH11822; Thu, 29 Apr 2004 15:36:54 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:36:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979E4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYAAA+oJwAGnV0bA= To: , , X-OriginalArrivalTime: 29 Apr 2004 12:36:53.0669 (UTC) FILETIME=[A6C23550:01C42DE6] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:36:54 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 27.April.2004 13:05 > To: Lonnfors Mikko (Nokia-NRC/Helsinki); rsparks@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Lonnfors Mikko (Nokia-NRC/Helsinki)=20 > > Sent: 27.April.2004 12:46 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki);=20 > > 'rsparks@dynamicsoft.com'; > > 'simple@ietf.org' > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Hi, > >=20 > > > Here is an example where both state and version are needed: > > >=20 > > > PA sends N1(full), N2(full), N3(partial). > > >=20 > > > If the version is set to 0 everytime there is full state, and=20 > > > N2 was never received, the subscriber would then think that=20 > > > N3 is a partial of N1. > > >=20 > > > To solve this, you need the version to continuously increase=20 > > > by 1, even when a full state is being sent. You would then=20 > > > also need the state attribute to indicate full/partial. The=20 > > > version is used by the subscriber to learn that a NOTIFY was=20 > > > not received (N2). > >=20 > > Ok, so your proposal is that "version" should be scoped with=20 > > the subscription i.e. first NOTIFY within a subscription=20 > > would have version=3D"0" and then it would be continuously=20 > > increased by one for every notifications (regardless if it=20 > > contains full or partial state)? > >=20 > > How should subscription refreshes be handled? If we have > > PA sends N1(full), N2(full), N3(partial) > > And N2 is lost watcher would refresh the subscription when it=20 > > receives N3. Now > > Would the PA send N1(full, version=3D"0") or N4(full, = version=3D"3")? >=20 > version gets reset to 0 when a SUBSCRIBE refresh is received. Now that I think about this a little more, I think the version should = forever increase for the whole duration of the subscription, including = refreshes. Imagine this scenario: ----> SUBSCRIBE <---- 200 <---- NOTIFY1 (full, version 0) ----> 200 X-- NOTIFY2 (full, version 1) <---- NOTIFY3 (partial, version 3) ----> 200 ----> SUBSCRIBE <---- 200 <---- NOTIFY4 (full, version 0) ----> 200 <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives How does the subscribe know that the last NOTIFY (NOTIFY2) was sent = after the subscribe refresh? If NOTIFY 4 had version 4 instead of 0, = then it would. /Hisham >=20 > /Hisham > >=20 > > - Mikko=20 > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: simple-admin@ietf.org=20 > > > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > > > ext mikko.lonnfors@nokia.com > > > > Sent: 26.April.2004 22:17 > > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > > Subject: RE: [Simple] WGLC: partial notification > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > Thanks for comments. Responses inline: > > > >=20 > > > > > Writing as a WG member - not as chair - > > > > >=20 > > > > > I've sent a list of typo level nits in these drafts to > > > > Mikko privately > > > >=20 > > > > > - > > > > >=20 > > > > > While doing a nit review, I found some things that should have > > > > > received list attention earlier. > > > > >=20 > > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > > construct the > > > >=20 > > > > > partial presence document according to the following > > > > logic:" followed > > > > > by a bunch of MUST level statements. Why is that SHOULD=20 > > > there? What > > > > > would it mean to violate it? I suggest striking it and=20 > > > > simply saying > > > > > "The PA constructs" > > > >=20 > > > > Yes, SHOULD is probably useless and confusing here. I will=20 > > > remove it. > > > >=20 > > > > > Why do we have both "state" and "version"? As defined in > > > > these drafts, > > > >=20 > > > > > state=3Dfull if and only if version=3D0. You could delete=20 > the state > > > > > parameter with no loss of information, so why is it there? > > > >=20 > > > > I believe the original need for the "state" was that the > > > > "version" could > > > > be initialized to some random value. Now, if "version" is always > > > > initialized to 0 there is no need for the "state"=20 > attribute. Both > > > > solutions should work and if nobody else comments=20 > otherwise I will > > > > remove the "state" attribute. > > > >=20 > > > > > 3261 currently allows overlapping non-INVITE=20 > > transactions inside a > > > > > dialog (there's an open issue suggesting this might be a=20 > > > bad thing,=20 > > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). = Neither > > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > > > probably manageable. For partial state documents, at least as=20 > > > > > they are specified here, it could be disastrous. Consider=20 > > > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > > > If the recipient receives only N1 and N4 (something prevents=20 > > > > > N2 and N3 from being delivered or simply delays them=20 > > > > > (packetloss over UDP for example)), it will apply the delta=20 > > > > > in N4 to the wrong full state document (N1 instead of N3).=20 > > > >=20 > > > > Actually it wouldn't because of "version" handling. Section > > > > 4.5 applies > > > > here. But in any case this kind of behavior is quite bad=20 > > as it might > > > > result in frequent subscription refreshes to obtain full=20 > > > > presence state. > > > > More below. > > > >=20 > > > > > We > > > > > can preserve the properties of the existing system is=20 > we forbid=20 > > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > > when any other=20 > > > > > NOTIFY transaction is still in progress on > > > > this dialog. > > > >=20 > > > > This is a good point. Your proposed solution should work. > > > > This may cause > > > > some extra implementation effort for PA but I cannot see any=20 > > > > way around > > > > this. If no other comments are received I will add text=20 > forbidding > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > > (version=3D0) when > > > > any other NOTIFY transaction is still in progress on=20 > this dialog.=20 > > > >=20 > > > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > > > presence document whose "version" attribute value (is)=20 > > higher by=20 > > > > > more than one with the locally stored value, the=20 > > watcher assumes=20 > > > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > > > refresh the subscription in order to receive a full presence=20 > > > > > document or terminate the subscription." Why is that=20 > > SHOULD? In=20 > > > > > what scenario is any other course of action reasonable?=20 > > (The only=20 > > > > > one I can think of is _if_ we allow overlapping partial=20 > > NOTIFYs,=20 > > > > > then the watcher can wait around for awhile for the gaps=20 > > > to fill in=20 > > > > > - if we allow this, then we need to explicitly state this as > > > > > why the above is SHOULD, not MUST. However, I think this=20 > > > > > should be a MUST.) > > > >=20 > > > > Well, there probably isn't any good cases where watcher=20 > wouldn't=20 > > > > terminate or refresh subscription. Changing SHOULD to=20 > MUST should=20 > > > > provide more consistent behavior. > > > > =20 > > > > > Just below that, there's a "SHOULD discard the document" if > > > > > it gets a partial notification with a lower version number. I=20 > > > > > don't see how this is right at all, and suggest that this=20 > > > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > > > - the CSeq processing logic would=20 > > > > > have caught it). > > > >=20 > > > > Right, and if we don't allow sending new NOTIFYs if there=20 > > > is a pending=20 > > > > transaction then I believe reordering should never happen.=20 > > > But if in=20 > > > > this situation watcher receives a presence document with=20 > > > lower version=20 > > > > number there should be no harm in discarding it because it=20 > > > already has=20 > > > > a consistent presence state. This is more or less an error=20 > > > case which > > > > probably should never happen but I think there is no need to=20 > > > > refresh or > > > > terminate the subscription. > > > >=20 > > > > - Mikko > > > >=20 > > > > > I'll send a separate message on the Security Considerations > > > > > section for -partial-notify. > > > > >=20 > > > > > RjS > > > > >=20 > > > > >=20 > > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > > This is a Working Group Last call on the following drafts: > > > > > >=20 > > > > > >=20 > > > > > http://www.ietf.org/internet-drafts/draft-> > > > > ietf-simple-partial-notify-0 > > > > > > 2.txt > > > > > >=20 > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > > pidf-format-01.txt > > > > >=20 > > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > > >=20 > > > > > These drafts went through a previous last call at the=20 > > beginning of > > > > > March. These versions reflect changes due to comments=20 > > > > received during > > > > > that period. See > > > > >=20 > > >=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > > 519.html > > > for details. > > >=20 > > > Please send comments to the list, copying the editor. If=20 > > you reviewed > > > the draft and found no issues, please indicate so on the list. > > >=20 > > > RjS > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 09:26:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00408 for ; Thu, 29 Apr 2004 09:26:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBYc-00061Q-6o for simple-archive@ietf.org; Thu, 29 Apr 2004 09:26:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBXh-0005kN-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 09:25:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBWp-0005Ta-00; Thu, 29 Apr 2004 09:24:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBFE-0001N2-Rz; Thu, 29 Apr 2004 09:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAs4-0007S2-V4 for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:42:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25849 for ; Thu, 29 Apr 2004 08:42:25 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAru-000165-Re for simple@ietf.org; Thu, 29 Apr 2004 08:42:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAr5-0000pF-00 for simple@ietf.org; Thu, 29 Apr 2004 08:41:31 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJAq6-0000XX-00 for simple@ietf.org; Thu, 29 Apr 2004 08:40:30 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCeVH24834; Thu, 29 Apr 2004 15:40:31 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:40:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCeE6P022704; Thu, 29 Apr 2004 15:40:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 008oRem1; Thu, 29 Apr 2004 15:40:13 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCeCH14399; Thu, 29 Apr 2004 15:40:12 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:40:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DEBC@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYAAA+oJwAGnV0bAAACnfIA== To: , , X-OriginalArrivalTime: 29 Apr 2004 12:40:10.0103 (UTC) FILETIME=[1BD7A870:01C42DE7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:40:11 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > > > Ok, so your proposal is that "version" should be scoped with > > > the subscription i.e. first NOTIFY within a subscription=20 > > > would have version=3D"0" and then it would be continuously=20 > > > increased by one for every notifications (regardless if it=20 > > > contains full or partial state)? > > >=20 > > > How should subscription refreshes be handled? If we have > > > PA sends N1(full), N2(full), N3(partial) > > > And N2 is lost watcher would refresh the subscription when it > > > receives N3. Now > > > Would the PA send N1(full, version=3D"0") or N4(full, = version=3D"3")? > >=20 > > version gets reset to 0 when a SUBSCRIBE refresh is received. >=20 > Now that I think about this a little more, I think the=20 > version should forever increase for the whole duration of the=20 > subscription, including refreshes. Imagine this scenario: >=20 > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full, version 0) > ----> 200 > X-- NOTIFY2 (full, version 1) > <---- NOTIFY3 (partial, version 3) > ----> 200 > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY4 (full, version 0) > ----> 200 > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives >=20 > How does the subscribe know that the last NOTIFY (NOTIFY2)=20 > was sent after the subscribe refresh? If NOTIFY 4 had version=20 > 4 instead of 0, then it would. >=20 > /Hisham If we don't allow new NOTIFY messages if there is a pending NOTIFY is this still a problem? - Mikko =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 09:29:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00706 for ; Thu, 29 Apr 2004 09:29:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBbK-0006nC-9c for simple-archive@ietf.org; Thu, 29 Apr 2004 09:29:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBaO-0006Wh-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 09:28:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBZX-0006I5-00; Thu, 29 Apr 2004 09:27:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBFT-0001UH-Da; Thu, 29 Apr 2004 09:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAw8-0000CZ-I6 for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:46:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26213 for ; Thu, 29 Apr 2004 08:46:36 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAvy-0002Dj-Cg for simple@ietf.org; Thu, 29 Apr 2004 08:46:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAv9-0001xH-00 for simple@ietf.org; Thu, 29 Apr 2004 08:45:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BJAu7-0001eY-00 for simple@ietf.org; Thu, 29 Apr 2004 08:44:40 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCiZJ18198; Thu, 29 Apr 2004 15:44:35 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:44:29 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCiTSI003420; Thu, 29 Apr 2004 15:44:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00QKkGUW; Thu, 29 Apr 2004 15:44:27 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCiQH17631; Thu, 29 Apr 2004 15:44:26 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:44:24 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYAAA+oJwAGnV0bAAACnfIAAAI49g To: , , X-OriginalArrivalTime: 29 Apr 2004 12:44:24.0935 (UTC) FILETIME=[B3BBEF70:01C42DE7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:44:25 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Lonnfors Mikko (Nokia-NRC/Helsinki)=20 > Sent: 29.April.2004 15:40 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 >=20 > >=20 > > > > Ok, so your proposal is that "version" should be scoped with > > > > the subscription i.e. first NOTIFY within a subscription=20 > > > > would have version=3D"0" and then it would be continuously=20 > > > > increased by one for every notifications (regardless if it=20 > > > > contains full or partial state)? > > > >=20 > > > > How should subscription refreshes be handled? If we have > > > > PA sends N1(full), N2(full), N3(partial) > > > > And N2 is lost watcher would refresh the subscription when it > > > > receives N3. Now > > > > Would the PA send N1(full, version=3D"0") or N4(full,=20 > version=3D"3")? > > >=20 > > > version gets reset to 0 when a SUBSCRIBE refresh is received. > >=20 > > Now that I think about this a little more, I think the=20 > > version should forever increase for the whole duration of the=20 > > subscription, including refreshes. Imagine this scenario: > >=20 > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full, version 0) > > ----> 200 > > X-- NOTIFY2 (full, version 1) > > <---- NOTIFY3 (partial, version 3) > > ----> 200 > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY4 (full, version 0) > > ----> 200 > > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives > >=20 > > How does the subscribe know that the last NOTIFY (NOTIFY2)=20 > > was sent after the subscribe refresh? If NOTIFY 4 had version=20 > > 4 instead of 0, then it would. > >=20 > > /Hisham >=20 > If we don't allow new NOTIFY messages if there is a pending=20 > NOTIFY is this still a problem? This would fix the problem, but I prefer not to disallow it since RFC3265 does not disallow it nor presence-07. I believe increasing the version for the duration of the subscription would fix this. /Hisham >=20 > - Mikko > =20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 09:30:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00813 for ; Thu, 29 Apr 2004 09:30:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBcU-00074Y-JZ for simple-archive@ietf.org; Thu, 29 Apr 2004 09:30:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBbW-0006om-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 09:29:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBav-0006Z9-00; Thu, 29 Apr 2004 09:28:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBFp-0001Y6-0e; Thu, 29 Apr 2004 09:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAxq-00012C-2l for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:48:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26356 for ; Thu, 29 Apr 2004 08:48:22 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAxf-0002iI-Jl for simple@ietf.org; Thu, 29 Apr 2004 08:48:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAwl-0002TL-00 for simple@ietf.org; Thu, 29 Apr 2004 08:47:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BJAwB-0002Ek-00 for simple@ietf.org; Thu, 29 Apr 2004 08:46:47 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCkhJ20763; Thu, 29 Apr 2004 15:46:43 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:46:42 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCkg4R010698; Thu, 29 Apr 2004 15:46:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 0008kXrn; Thu, 29 Apr 2004 15:46:39 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCkXH19345; Thu, 29 Apr 2004 15:46:34 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:46:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1730E@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAadfZ4AAAYYMgAAD1mRA= To: , , X-OriginalArrivalTime: 29 Apr 2004 12:46:31.0002 (UTC) FILETIME=[FEE03BA0:01C42DE7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:46:30 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable >=20 >=20 > Why does that matter? If it is full state, the tuple ids can=20 > remain the same or be different. A full state NOTIFY replaces=20 > the whole state at the subscriber side anyway. The only=20 > requirement now is that the subscriber must ensure the next=20 > NOTIFY (carrying partial or full state) only has the version=20 > increased by 1. If it is increased by more than 1, then=20 > something was lost. > > /Hisham Well, its not that big thing but you end up having two separate 'lifecycles' for different elements within a single document. I was think that from implementation perspective it might be easier to have just one. But in any case I think you are right that these are two separate things. - Mikko=20 =20 > > -----Original Message----- > > From: Lonnfors Mikko (Nokia-NRC/Helsinki) > > Sent: 29.April.2004 15:03 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki);=20 > rsparks@dynamicsoft.com; > > simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Hi, > >=20 > > I would like to hear what others think about this proposal. > > Especially, if you think it will not work in some situations. > > If this works and we choose to adopt the proposed solution=20 > > where are probably some other consequences. At a moment PA=20 > > MUST keep tuple ids consistent between two "full" state=20 > > documents. Now, if the version cycle will be tied to the=20 > > subscription PA/UA must apply a bit different logic how tuple=20 > > ids and "version" numbers are generated. My proposal in this=20 > > case would be to also keep tuple ids consistent within a=20 > subscription. > >=20 > > - Mikko > >=20 > > >=20 > > > Here is an example where both state and version are needed: > > >=20 > > > PA sends N1(full), N2(full), N3(partial). > > >=20 > > > If the version is set to 0 everytime there is full state, and > > > N2 was never received, the subscriber would then think that=20 > > > N3 is a partial of N1. > > >=20 > > > To solve this, you need the version to continuously increase > > > by 1, even when a full state is being sent. You would then=20 > > > also need the state attribute to indicate full/partial. The=20 > > > version is used by the subscriber to learn that a NOTIFY was=20 > > > not received (N2). > > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: simple-admin@ietf.org > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > ext mikko.lonnfors@nokia.com > > > > Sent: 26.April.2004 22:17 > > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > > Subject: RE: [Simple] WGLC: partial notification > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > Thanks for comments. Responses inline: > > > >=20 > > > > > Writing as a WG member - not as chair - > > > > >=20 > > > > > I've sent a list of typo level nits in these drafts to > > > > Mikko privately > > > >=20 > > > > > - > > > > >=20 > > > > > While doing a nit review, I found some things that=20 > should have=20 > > > > > received list attention earlier. > > > > >=20 > > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > > construct the > > > >=20 > > > > > partial presence document according to the following > > > > logic:" followed > > > > > by a bunch of MUST level statements. Why is that SHOULD > > > there? What > > > > > would it mean to violate it? I suggest striking it and > > > > simply saying > > > > > "The PA constructs" > > > >=20 > > > > Yes, SHOULD is probably useless and confusing here. I will > > > remove it. > > > >=20 > > > > > Why do we have both "state" and "version"? As defined in > > > > these drafts, > > > >=20 > > > > > state=3Dfull if and only if version=3D0. You could delete=20 > the state=20 > > > > > parameter with no loss of information, so why is it there? > > > >=20 > > > > I believe the original need for the "state" was that=20 > the "version"=20 > > > > could be initialized to some random value. Now, if "version" is=20 > > > > always initialized to 0 there is no need for the "state"=20 > > > > attribute. Both solutions should work and if nobody=20 > else comments=20 > > > > otherwise I will remove the "state" attribute. > > > >=20 > > > > > 3261 currently allows overlapping non-INVITE > > transactions inside a > > > > > dialog (there's an open issue suggesting this might be a > > > bad thing, > > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). = Neither=20 > > > > > 3265 or simple-presence prohibit overlapping NOTIFYs.=20 > For full=20 > > > > > state documents, having multiple outstanding NOTIFYs=20 > is probably=20 > > > > > manageable. For partial state documents, at least as they are=20 > > > > > specified here, it could be disastrous. Consider four=20 > notifies=20 > > > > > N1(full), N2(partial), N3(full), N4(partial). If the=20 > recipient=20 > > > > > receives only N1 and N4 (something prevents N2 and N3=20 > from being=20 > > > > > delivered or simply delays them (packetloss over UDP for=20 > > > > > example)), it will apply the delta in N4 to the wrong=20 > full state=20 > > > > > document (N1 instead of N3). > > > >=20 > > > > Actually it wouldn't because of "version" handling. Section 4.5=20 > > > > applies here. But in any case this kind of behavior is quite bad > > as it might > > > > result in frequent subscription refreshes to obtain full > > > > presence state. > > > > More below. > > > >=20 > > > > > We > > > > > can preserve the properties of the existing system is=20 > we forbid > > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > > when any other > > > > > NOTIFY transaction is still in progress on > > > > this dialog. > > > >=20 > > > > This is a good point. Your proposed solution should=20 > work. This may=20 > > > > cause some extra implementation effort for PA but I=20 > cannot see any > > > > way around > > > > this. If no other comments are received I will add text=20 > forbidding > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > > (version=3D0) when > > > > any other NOTIFY transaction is still in progress on=20 > this dialog. > > > >=20 > > > > > Section 4.5 of partial-notify says "If the watcher receives a > > > > > presence document whose "version" attribute value (is)=20 > > higher by > > > > > more than one with the locally stored value, the > > watcher assumes > > > > > that one or more NOTIFYs were lost. The watcher SHOULD either > > > > > refresh the subscription in order to receive a full presence=20 > > > > > document or terminate the subscription." Why is that=20 > > SHOULD? In > > > > > what scenario is any other course of action reasonable? > > (The only > > > > > one I can think of is _if_ we allow overlapping partial > > NOTIFYs, > > > > > then the watcher can wait around for awhile for the gaps > > > to fill in > > > > > - if we allow this, then we need to explicitly state=20 > this as why=20 > > > > > the above is SHOULD, not MUST. However, I think this=20 > should be a=20 > > > > > MUST.) > > > >=20 > > > > Well, there probably isn't any good cases where watcher wouldn't > > > > terminate or refresh subscription. Changing SHOULD to=20 > MUST should=20 > > > > provide more consistent behavior. > > > > =20 > > > > > Just below that, there's a "SHOULD discard the=20 > document" if it=20 > > > > > gets a partial notification with a lower version=20 > number. I don't=20 > > > > > see how this is right at all, and suggest that this=20 > MUST trigger=20 > > > > > a refresh or termination instead. (We wouldn't get to=20 > this logic=20 > > > > > if a NOTIFY was reordered and arrived late > > > > > - the CSeq processing logic would > > > > > have caught it). > > > >=20 > > > > Right, and if we don't allow sending new NOTIFYs if there > > > is a pending > > > > transaction then I believe reordering should never happen. > > > But if in > > > > this situation watcher receives a presence document with > > > lower version > > > > number there should be no harm in discarding it because it > > > already has > > > > a consistent presence state. This is more or less an error > > > case which > > > > probably should never happen but I think there is no need to > > > > refresh or > > > > terminate the subscription. > > > >=20 > > > > - Mikko > > > >=20 > > > > > I'll send a separate message on the Security Considerations=20 > > > > > section for -partial-notify. > > > > >=20 > > > > > RjS > > > > >=20 > > > > >=20 > > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > > This is a Working Group Last call on the following drafts: > > > > > >=20 > > > > > >=20 > > > > > http://www.ietf.org/internet-drafts/draft-> > > > > ietf-simple-partial-notify-0 > > > > > > 2.txt > > > > > >=20 > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > > pidf-format-01.txt > > > > >=20 > > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > > >=20 > > > > > These drafts went through a previous last call at the > > beginning of > > > > > March. These versions reflect changes due to comments > > > > received during > > > > > that period. See > > > > >=20 > > >=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > > 519.html > > > for details. > > >=20 > > > Please send comments to the list, copying the editor. If > > you reviewed > > > the draft and found no issues, please indicate so on the list. > > >=20 > > > RjS > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 09:46:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01668 for ; Thu, 29 Apr 2004 09:46:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBeW-0003JH-61 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDWamD012721 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBSm-0005sC-0a for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:20:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29782 for ; Thu, 29 Apr 2004 09:20:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBSb-0004B1-BJ for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:20:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBQk-0003fa-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:18:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBOu-0003Co-00; Thu, 29 Apr 2004 09:16:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBEp-00017P-N8; Thu, 29 Apr 2004 09:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAlg-0005lt-VE for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:35:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25093 for ; Thu, 29 Apr 2004 08:35:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAlW-0006r4-Qd for simple@ietf.org; Thu, 29 Apr 2004 08:35:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAkJ-0006WP-00 for simple@ietf.org; Thu, 29 Apr 2004 08:34:32 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BJAjK-0006DJ-00 for simple@ietf.org; Thu, 29 Apr 2004 08:33:30 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCXUG29006; Thu, 29 Apr 2004 15:33:30 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:33:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCXRiQ032423; Thu, 29 Apr 2004 15:33:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00CY02XV; Thu, 29 Apr 2004 15:33:26 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCXCH08730; Thu, 29 Apr 2004 15:33:12 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:33:12 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979E3@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAadfZ4AAAYYMg To: , , X-OriginalArrivalTime: 29 Apr 2004 12:33:12.0251 (UTC) FILETIME=[22C880B0:01C42DE6] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:33:12 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Why does that matter? If it is full state, the tuple ids can remain the same or be different. A full state NOTIFY replaces the whole state at the subscriber side anyway. The only requirement now is that the subscriber must ensure the next NOTIFY (carrying partial or full state) only has the version increased by 1. If it is increased by more than 1, then something was lost. /Hisham > -----Original Message----- > From: Lonnfors Mikko (Nokia-NRC/Helsinki)=20 > Sent: 29.April.2004 15:03 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 > Hi, >=20 > I would like to hear what others think about this proposal.=20 > Especially, if you think it will not work in some situations. > If this works and we choose to adopt the proposed solution=20 > where are probably some other consequences. At a moment PA=20 > MUST keep tuple ids consistent between two "full" state=20 > documents. Now, if the version cycle will be tied to the=20 > subscription PA/UA must apply a bit different logic how tuple=20 > ids and "version" numbers are generated. My proposal in this=20 > case would be to also keep tuple ids consistent within a subscription. >=20 > - Mikko=20 >=20 > >=20 > > Here is an example where both state and version are needed: > >=20 > > PA sends N1(full), N2(full), N3(partial). > >=20 > > If the version is set to 0 everytime there is full state, and=20 > > N2 was never received, the subscriber would then think that=20 > > N3 is a partial of N1. > >=20 > > To solve this, you need the version to continuously increase=20 > > by 1, even when a full state is being sent. You would then=20 > > also need the state attribute to indicate full/partial. The=20 > > version is used by the subscriber to learn that a NOTIFY was=20 > > not received (N2). > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org=20 > > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > > ext mikko.lonnfors@nokia.com > > > Sent: 26.April.2004 22:17 > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > Subject: RE: [Simple] WGLC: partial notification > > >=20 > > >=20 > > > Hi, > > >=20 > > > Thanks for comments. Responses inline: > > >=20 > > > > Writing as a WG member - not as chair - > > > >=20 > > > > I've sent a list of typo level nits in these drafts to > > > Mikko privately > > >=20 > > > > - > > > >=20 > > > > While doing a nit review, I found some things that should have > > > > received list attention earlier. > > > >=20 > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > construct the > > >=20 > > > > partial presence document according to the following > > > logic:" followed > > > > by a bunch of MUST level statements. Why is that SHOULD=20 > > there? What > > > > would it mean to violate it? I suggest striking it and=20 > > > simply saying > > > > "The PA constructs" > > >=20 > > > Yes, SHOULD is probably useless and confusing here. I will=20 > > remove it. > > >=20 > > > > Why do we have both "state" and "version"? As defined in > > > these drafts, > > >=20 > > > > state=3Dfull if and only if version=3D0. You could delete the = state > > > > parameter with no loss of information, so why is it there? > > >=20 > > > I believe the original need for the "state" was that the > > > "version" could > > > be initialized to some random value. Now, if "version" is always > > > initialized to 0 there is no need for the "state" attribute. Both > > > solutions should work and if nobody else comments otherwise I will > > > remove the "state" attribute. > > >=20 > > > > 3261 currently allows overlapping non-INVITE=20 > transactions inside a > > > > dialog (there's an open issue suggesting this might be a=20 > > bad thing,=20 > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). Neither > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > > probably manageable. For partial state documents, at least as=20 > > > > they are specified here, it could be disastrous. Consider=20 > > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > > If the recipient receives only N1 and N4 (something prevents=20 > > > > N2 and N3 from being delivered or simply delays them=20 > > > > (packetloss over UDP for example)), it will apply the delta=20 > > > > in N4 to the wrong full state document (N1 instead of N3).=20 > > >=20 > > > Actually it wouldn't because of "version" handling. Section > > > 4.5 applies > > > here. But in any case this kind of behavior is quite bad=20 > as it might > > > result in frequent subscription refreshes to obtain full=20 > > > presence state. > > > More below. > > >=20 > > > > We > > > > can preserve the properties of the existing system is we forbid=20 > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > when any other=20 > > > > NOTIFY transaction is still in progress on > > > this dialog. > > >=20 > > > This is a good point. Your proposed solution should work. > > > This may cause > > > some extra implementation effort for PA but I cannot see any=20 > > > way around > > > this. If no other comments are received I will add text forbidding > > > sending a NOTIFY with a document with state=3D"partial"=20 > > (version=3D0) when > > > any other NOTIFY transaction is still in progress on this dialog.=20 > > >=20 > > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > > presence document whose "version" attribute value (is)=20 > higher by=20 > > > > more than one with the locally stored value, the=20 > watcher assumes=20 > > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > > refresh the subscription in order to receive a full presence=20 > > > > document or terminate the subscription." Why is that=20 > SHOULD? In=20 > > > > what scenario is any other course of action reasonable?=20 > (The only=20 > > > > one I can think of is _if_ we allow overlapping partial=20 > NOTIFYs,=20 > > > > then the watcher can wait around for awhile for the gaps=20 > > to fill in=20 > > > > - if we allow this, then we need to explicitly state this as > > > > why the above is SHOULD, not MUST. However, I think this=20 > > > > should be a MUST.) > > >=20 > > > Well, there probably isn't any good cases where watcher wouldn't=20 > > > terminate or refresh subscription. Changing SHOULD to MUST should=20 > > > provide more consistent behavior. > > > =20 > > > > Just below that, there's a "SHOULD discard the document" if > > > > it gets a partial notification with a lower version number. I=20 > > > > don't see how this is right at all, and suggest that this=20 > > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > > - the CSeq processing logic would=20 > > > > have caught it). > > >=20 > > > Right, and if we don't allow sending new NOTIFYs if there=20 > > is a pending=20 > > > transaction then I believe reordering should never happen.=20 > > But if in=20 > > > this situation watcher receives a presence document with=20 > > lower version=20 > > > number there should be no harm in discarding it because it=20 > > already has=20 > > > a consistent presence state. This is more or less an error=20 > > case which > > > probably should never happen but I think there is no need to=20 > > > refresh or > > > terminate the subscription. > > >=20 > > > - Mikko > > >=20 > > > > I'll send a separate message on the Security Considerations > > > > section for -partial-notify. > > > >=20 > > > > RjS > > > >=20 > > > >=20 > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > This is a Working Group Last call on the following drafts: > > > > >=20 > > > > >=20 > > > > http://www.ietf.org/internet-drafts/draft-> > > > ietf-simple-partial-notify-0 > > > > > 2.txt > > > > >=20 > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > pidf-format-01.txt > > > >=20 > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > >=20 > > > > These drafts went through a previous last call at the=20 > beginning of > > > > March. These versions reflect changes due to comments=20 > > > received during > > > > that period. See > > > >=20 > >=20 https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > 519.html > > for details. > >=20 > > Please send comments to the list, copying the editor. If=20 > you reviewed > > the draft and found no issues, please indicate so on the list. > >=20 > > RjS > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 09:47:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01718 for ; Thu, 29 Apr 2004 09:47:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBed-0003Ps-C4 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDWh4W013127 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBV3-0006Yb-71 for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:22:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00043 for ; Thu, 29 Apr 2004 09:22:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBUs-0004v2-N9 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:22:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBTT-0004NH-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:21:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBRh-0003wR-00; Thu, 29 Apr 2004 09:19:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBF5-0001J0-UP; Thu, 29 Apr 2004 09:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJApw-0006hX-2h for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25586 for ; Thu, 29 Apr 2004 08:40:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJApl-0000UT-T7 for simple@ietf.org; Thu, 29 Apr 2004 08:40:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAoQ-0007ln-00 for simple@ietf.org; Thu, 29 Apr 2004 08:38:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJAml-0007EC-00 for simple@ietf.org; Thu, 29 Apr 2004 08:37:03 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCb3v16334; Thu, 29 Apr 2004 15:37:03 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:36:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCau2q012258; Thu, 29 Apr 2004 15:36:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00VfWuWT; Thu, 29 Apr 2004 15:36:55 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCasH11822; Thu, 29 Apr 2004 15:36:54 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:36:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979E4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYAAA+oJwAGnV0bA= To: , , X-OriginalArrivalTime: 29 Apr 2004 12:36:53.0669 (UTC) FILETIME=[A6C23550:01C42DE6] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:36:54 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 27.April.2004 13:05 > To: Lonnfors Mikko (Nokia-NRC/Helsinki); rsparks@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Lonnfors Mikko (Nokia-NRC/Helsinki)=20 > > Sent: 27.April.2004 12:46 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki);=20 > > 'rsparks@dynamicsoft.com'; > > 'simple@ietf.org' > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Hi, > >=20 > > > Here is an example where both state and version are needed: > > >=20 > > > PA sends N1(full), N2(full), N3(partial). > > >=20 > > > If the version is set to 0 everytime there is full state, and=20 > > > N2 was never received, the subscriber would then think that=20 > > > N3 is a partial of N1. > > >=20 > > > To solve this, you need the version to continuously increase=20 > > > by 1, even when a full state is being sent. You would then=20 > > > also need the state attribute to indicate full/partial. The=20 > > > version is used by the subscriber to learn that a NOTIFY was=20 > > > not received (N2). > >=20 > > Ok, so your proposal is that "version" should be scoped with=20 > > the subscription i.e. first NOTIFY within a subscription=20 > > would have version=3D"0" and then it would be continuously=20 > > increased by one for every notifications (regardless if it=20 > > contains full or partial state)? > >=20 > > How should subscription refreshes be handled? If we have > > PA sends N1(full), N2(full), N3(partial) > > And N2 is lost watcher would refresh the subscription when it=20 > > receives N3. Now > > Would the PA send N1(full, version=3D"0") or N4(full, = version=3D"3")? >=20 > version gets reset to 0 when a SUBSCRIBE refresh is received. Now that I think about this a little more, I think the version should = forever increase for the whole duration of the subscription, including = refreshes. Imagine this scenario: ----> SUBSCRIBE <---- 200 <---- NOTIFY1 (full, version 0) ----> 200 X-- NOTIFY2 (full, version 1) <---- NOTIFY3 (partial, version 3) ----> 200 ----> SUBSCRIBE <---- 200 <---- NOTIFY4 (full, version 0) ----> 200 <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives How does the subscribe know that the last NOTIFY (NOTIFY2) was sent = after the subscribe refresh? If NOTIFY 4 had version 4 instead of 0, = then it would. /Hisham >=20 > /Hisham > >=20 > > - Mikko=20 > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: simple-admin@ietf.org=20 > > > [mailto:simple-admin@ietf.org]On Behalf Of=20 > > > > ext mikko.lonnfors@nokia.com > > > > Sent: 26.April.2004 22:17 > > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > > Subject: RE: [Simple] WGLC: partial notification > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > Thanks for comments. Responses inline: > > > >=20 > > > > > Writing as a WG member - not as chair - > > > > >=20 > > > > > I've sent a list of typo level nits in these drafts to > > > > Mikko privately > > > >=20 > > > > > - > > > > >=20 > > > > > While doing a nit review, I found some things that should have > > > > > received list attention earlier. > > > > >=20 > > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > > construct the > > > >=20 > > > > > partial presence document according to the following > > > > logic:" followed > > > > > by a bunch of MUST level statements. Why is that SHOULD=20 > > > there? What > > > > > would it mean to violate it? I suggest striking it and=20 > > > > simply saying > > > > > "The PA constructs" > > > >=20 > > > > Yes, SHOULD is probably useless and confusing here. I will=20 > > > remove it. > > > >=20 > > > > > Why do we have both "state" and "version"? As defined in > > > > these drafts, > > > >=20 > > > > > state=3Dfull if and only if version=3D0. You could delete=20 > the state > > > > > parameter with no loss of information, so why is it there? > > > >=20 > > > > I believe the original need for the "state" was that the > > > > "version" could > > > > be initialized to some random value. Now, if "version" is always > > > > initialized to 0 there is no need for the "state"=20 > attribute. Both > > > > solutions should work and if nobody else comments=20 > otherwise I will > > > > remove the "state" attribute. > > > >=20 > > > > > 3261 currently allows overlapping non-INVITE=20 > > transactions inside a > > > > > dialog (there's an open issue suggesting this might be a=20 > > > bad thing,=20 > > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). = Neither > > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For=20 > > > > > full state documents, having multiple outstanding NOTIFYs is=20 > > > > > probably manageable. For partial state documents, at least as=20 > > > > > they are specified here, it could be disastrous. Consider=20 > > > > > four notifies N1(full), N2(partial), N3(full), N4(partial).=20 > > > > > If the recipient receives only N1 and N4 (something prevents=20 > > > > > N2 and N3 from being delivered or simply delays them=20 > > > > > (packetloss over UDP for example)), it will apply the delta=20 > > > > > in N4 to the wrong full state document (N1 instead of N3).=20 > > > >=20 > > > > Actually it wouldn't because of "version" handling. Section > > > > 4.5 applies > > > > here. But in any case this kind of behavior is quite bad=20 > > as it might > > > > result in frequent subscription refreshes to obtain full=20 > > > > presence state. > > > > More below. > > > >=20 > > > > > We > > > > > can preserve the properties of the existing system is=20 > we forbid=20 > > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > > when any other=20 > > > > > NOTIFY transaction is still in progress on > > > > this dialog. > > > >=20 > > > > This is a good point. Your proposed solution should work. > > > > This may cause > > > > some extra implementation effort for PA but I cannot see any=20 > > > > way around > > > > this. If no other comments are received I will add text=20 > forbidding > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > > (version=3D0) when > > > > any other NOTIFY transaction is still in progress on=20 > this dialog.=20 > > > >=20 > > > > > Section 4.5 of partial-notify says "If the watcher receives a=20 > > > > > presence document whose "version" attribute value (is)=20 > > higher by=20 > > > > > more than one with the locally stored value, the=20 > > watcher assumes=20 > > > > > that one or more NOTIFYs were lost. The watcher SHOULD either=20 > > > > > refresh the subscription in order to receive a full presence=20 > > > > > document or terminate the subscription." Why is that=20 > > SHOULD? In=20 > > > > > what scenario is any other course of action reasonable?=20 > > (The only=20 > > > > > one I can think of is _if_ we allow overlapping partial=20 > > NOTIFYs,=20 > > > > > then the watcher can wait around for awhile for the gaps=20 > > > to fill in=20 > > > > > - if we allow this, then we need to explicitly state this as > > > > > why the above is SHOULD, not MUST. However, I think this=20 > > > > > should be a MUST.) > > > >=20 > > > > Well, there probably isn't any good cases where watcher=20 > wouldn't=20 > > > > terminate or refresh subscription. Changing SHOULD to=20 > MUST should=20 > > > > provide more consistent behavior. > > > > =20 > > > > > Just below that, there's a "SHOULD discard the document" if > > > > > it gets a partial notification with a lower version number. I=20 > > > > > don't see how this is right at all, and suggest that this=20 > > > > > MUST trigger a refresh or termination instead. (We wouldn't=20 > > > > > get to this logic if a NOTIFY was reordered and arrived late=20 > > > > > - the CSeq processing logic would=20 > > > > > have caught it). > > > >=20 > > > > Right, and if we don't allow sending new NOTIFYs if there=20 > > > is a pending=20 > > > > transaction then I believe reordering should never happen.=20 > > > But if in=20 > > > > this situation watcher receives a presence document with=20 > > > lower version=20 > > > > number there should be no harm in discarding it because it=20 > > > already has=20 > > > > a consistent presence state. This is more or less an error=20 > > > case which > > > > probably should never happen but I think there is no need to=20 > > > > refresh or > > > > terminate the subscription. > > > >=20 > > > > - Mikko > > > >=20 > > > > > I'll send a separate message on the Security Considerations > > > > > section for -partial-notify. > > > > >=20 > > > > > RjS > > > > >=20 > > > > >=20 > > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > > This is a Working Group Last call on the following drafts: > > > > > >=20 > > > > > >=20 > > > > > http://www.ietf.org/internet-drafts/draft-> > > > > ietf-simple-partial-notify-0 > > > > > > 2.txt > > > > > >=20 > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > > pidf-format-01.txt > > > > >=20 > > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > > >=20 > > > > > These drafts went through a previous last call at the=20 > > beginning of > > > > > March. These versions reflect changes due to comments=20 > > > > received during > > > > > that period. See > > > > >=20 > > >=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > > 519.html > > > for details. > > >=20 > > > Please send comments to the list, copying the editor. If=20 > > you reviewed > > > the draft and found no issues, please indicate so on the list. > > >=20 > > > RjS > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 09:47:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01777 for ; Thu, 29 Apr 2004 09:47:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBes-0003VC-0P for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDWvQO013457 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBYn-0007l9-6s for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00427 for ; Thu, 29 Apr 2004 09:26:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBYc-00061W-Qi for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:26:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBXi-0005kU-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:25:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBWp-0005Ta-00; Thu, 29 Apr 2004 09:24:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBFE-0001N2-Rz; Thu, 29 Apr 2004 09:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAs4-0007S2-V4 for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:42:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25849 for ; Thu, 29 Apr 2004 08:42:25 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAru-000165-Re for simple@ietf.org; Thu, 29 Apr 2004 08:42:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAr5-0000pF-00 for simple@ietf.org; Thu, 29 Apr 2004 08:41:31 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJAq6-0000XX-00 for simple@ietf.org; Thu, 29 Apr 2004 08:40:30 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCeVH24834; Thu, 29 Apr 2004 15:40:31 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:40:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCeE6P022704; Thu, 29 Apr 2004 15:40:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 008oRem1; Thu, 29 Apr 2004 15:40:13 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCeCH14399; Thu, 29 Apr 2004 15:40:12 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:40:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DEBC@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYAAA+oJwAGnV0bAAACnfIA== To: , , X-OriginalArrivalTime: 29 Apr 2004 12:40:10.0103 (UTC) FILETIME=[1BD7A870:01C42DE7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:40:11 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > > Ok, so your proposal is that "version" should be scoped with > > > the subscription i.e. first NOTIFY within a subscription=20 > > > would have version=3D"0" and then it would be continuously=20 > > > increased by one for every notifications (regardless if it=20 > > > contains full or partial state)? > > >=20 > > > How should subscription refreshes be handled? If we have > > > PA sends N1(full), N2(full), N3(partial) > > > And N2 is lost watcher would refresh the subscription when it > > > receives N3. Now > > > Would the PA send N1(full, version=3D"0") or N4(full, = version=3D"3")? > >=20 > > version gets reset to 0 when a SUBSCRIBE refresh is received. >=20 > Now that I think about this a little more, I think the=20 > version should forever increase for the whole duration of the=20 > subscription, including refreshes. Imagine this scenario: >=20 > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full, version 0) > ----> 200 > X-- NOTIFY2 (full, version 1) > <---- NOTIFY3 (partial, version 3) > ----> 200 > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY4 (full, version 0) > ----> 200 > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives >=20 > How does the subscribe know that the last NOTIFY (NOTIFY2)=20 > was sent after the subscribe refresh? If NOTIFY 4 had version=20 > 4 instead of 0, then it would. >=20 > /Hisham If we don't allow new NOTIFY messages if there is a pending NOTIFY is this still a problem? - Mikko =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 09:48:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01886 for ; Thu, 29 Apr 2004 09:48:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBex-0003f1-4b for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:33:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDX3XG014050 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBbV-0008Rm-BL for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:29:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00732 for ; Thu, 29 Apr 2004 09:29:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBbK-0006nI-Sz for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:29:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBaP-0006Wo-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:28:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBZX-0006I5-00; Thu, 29 Apr 2004 09:27:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBFT-0001UH-Da; Thu, 29 Apr 2004 09:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAw8-0000CZ-I6 for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:46:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26213 for ; Thu, 29 Apr 2004 08:46:36 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAvy-0002Dj-Cg for simple@ietf.org; Thu, 29 Apr 2004 08:46:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAv9-0001xH-00 for simple@ietf.org; Thu, 29 Apr 2004 08:45:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BJAu7-0001eY-00 for simple@ietf.org; Thu, 29 Apr 2004 08:44:40 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCiZJ18198; Thu, 29 Apr 2004 15:44:35 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:44:29 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCiTSI003420; Thu, 29 Apr 2004 15:44:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00QKkGUW; Thu, 29 Apr 2004 15:44:27 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCiQH17631; Thu, 29 Apr 2004 15:44:26 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:44:24 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAAFBdYAAA+oJwAGnV0bAAACnfIAAAI49g To: , , X-OriginalArrivalTime: 29 Apr 2004 12:44:24.0935 (UTC) FILETIME=[B3BBEF70:01C42DE7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:44:25 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Lonnfors Mikko (Nokia-NRC/Helsinki)=20 > Sent: 29.April.2004 15:40 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] WGLC: partial notification >=20 >=20 >=20 > >=20 > > > > Ok, so your proposal is that "version" should be scoped with > > > > the subscription i.e. first NOTIFY within a subscription=20 > > > > would have version=3D"0" and then it would be continuously=20 > > > > increased by one for every notifications (regardless if it=20 > > > > contains full or partial state)? > > > >=20 > > > > How should subscription refreshes be handled? If we have > > > > PA sends N1(full), N2(full), N3(partial) > > > > And N2 is lost watcher would refresh the subscription when it > > > > receives N3. Now > > > > Would the PA send N1(full, version=3D"0") or N4(full,=20 > version=3D"3")? > > >=20 > > > version gets reset to 0 when a SUBSCRIBE refresh is received. > >=20 > > Now that I think about this a little more, I think the=20 > > version should forever increase for the whole duration of the=20 > > subscription, including refreshes. Imagine this scenario: > >=20 > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY1 (full, version 0) > > ----> 200 > > X-- NOTIFY2 (full, version 1) > > <---- NOTIFY3 (partial, version 3) > > ----> 200 > > ----> SUBSCRIBE > > <---- 200 > > <---- NOTIFY4 (full, version 0) > > ----> 200 > > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives > >=20 > > How does the subscribe know that the last NOTIFY (NOTIFY2)=20 > > was sent after the subscribe refresh? If NOTIFY 4 had version=20 > > 4 instead of 0, then it would. > >=20 > > /Hisham >=20 > If we don't allow new NOTIFY messages if there is a pending=20 > NOTIFY is this still a problem? This would fix the problem, but I prefer not to disallow it since RFC3265 does not disallow it nor presence-07. I believe increasing the version for the duration of the subscription would fix this. /Hisham >=20 > - Mikko > =20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 09:48:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01924 for ; Thu, 29 Apr 2004 09:48:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBf1-0003s2-Uq for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:33:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDX7RK014868 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 09:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBcf-0001zz-UJ for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:30:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00831 for ; Thu, 29 Apr 2004 09:30:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBcV-00074f-Dk for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:30:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBbY-0006ot-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 09:29:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBav-0006Z9-00; Thu, 29 Apr 2004 09:28:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBFp-0001Y6-0e; Thu, 29 Apr 2004 09:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAxq-00012C-2l for simple@optimus.ietf.org; Thu, 29 Apr 2004 08:48:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26356 for ; Thu, 29 Apr 2004 08:48:22 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAxf-0002iI-Jl for simple@ietf.org; Thu, 29 Apr 2004 08:48:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAwl-0002TL-00 for simple@ietf.org; Thu, 29 Apr 2004 08:47:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BJAwB-0002Ek-00 for simple@ietf.org; Thu, 29 Apr 2004 08:46:47 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCkhJ20763; Thu, 29 Apr 2004 15:46:43 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:46:42 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCkg4R010698; Thu, 29 Apr 2004 15:46:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 0008kXrn; Thu, 29 Apr 2004 15:46:39 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCkXH19345; Thu, 29 Apr 2004 15:46:34 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:46:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1730E@esebe004.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQoviLJpieiPn+fROWqUpXGAKqptgAPFj4QAM/SCNAAadfZ4AAAYYMgAAD1mRA= To: , , X-OriginalArrivalTime: 29 Apr 2004 12:46:31.0002 (UTC) FILETIME=[FEE03BA0:01C42DE7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 15:46:30 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 >=20 > Why does that matter? If it is full state, the tuple ids can=20 > remain the same or be different. A full state NOTIFY replaces=20 > the whole state at the subscriber side anyway. The only=20 > requirement now is that the subscriber must ensure the next=20 > NOTIFY (carrying partial or full state) only has the version=20 > increased by 1. If it is increased by more than 1, then=20 > something was lost. > > /Hisham Well, its not that big thing but you end up having two separate 'lifecycles' for different elements within a single document. I was think that from implementation perspective it might be easier to have just one. But in any case I think you are right that these are two separate things. - Mikko=20 =20 > > -----Original Message----- > > From: Lonnfors Mikko (Nokia-NRC/Helsinki) > > Sent: 29.April.2004 15:03 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki);=20 > rsparks@dynamicsoft.com; > > simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > >=20 > >=20 > > Hi, > >=20 > > I would like to hear what others think about this proposal. > > Especially, if you think it will not work in some situations. > > If this works and we choose to adopt the proposed solution=20 > > where are probably some other consequences. At a moment PA=20 > > MUST keep tuple ids consistent between two "full" state=20 > > documents. Now, if the version cycle will be tied to the=20 > > subscription PA/UA must apply a bit different logic how tuple=20 > > ids and "version" numbers are generated. My proposal in this=20 > > case would be to also keep tuple ids consistent within a=20 > subscription. > >=20 > > - Mikko > >=20 > > >=20 > > > Here is an example where both state and version are needed: > > >=20 > > > PA sends N1(full), N2(full), N3(partial). > > >=20 > > > If the version is set to 0 everytime there is full state, and > > > N2 was never received, the subscriber would then think that=20 > > > N3 is a partial of N1. > > >=20 > > > To solve this, you need the version to continuously increase > > > by 1, even when a full state is being sent. You would then=20 > > > also need the state attribute to indicate full/partial. The=20 > > > version is used by the subscriber to learn that a NOTIFY was=20 > > > not received (N2). > > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: simple-admin@ietf.org > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > ext mikko.lonnfors@nokia.com > > > > Sent: 26.April.2004 22:17 > > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > > Subject: RE: [Simple] WGLC: partial notification > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > Thanks for comments. Responses inline: > > > >=20 > > > > > Writing as a WG member - not as chair - > > > > >=20 > > > > > I've sent a list of typo level nits in these drafts to > > > > Mikko privately > > > >=20 > > > > > - > > > > >=20 > > > > > While doing a nit review, I found some things that=20 > should have=20 > > > > > received list attention earlier. > > > > >=20 > > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > > construct the > > > >=20 > > > > > partial presence document according to the following > > > > logic:" followed > > > > > by a bunch of MUST level statements. Why is that SHOULD > > > there? What > > > > > would it mean to violate it? I suggest striking it and > > > > simply saying > > > > > "The PA constructs" > > > >=20 > > > > Yes, SHOULD is probably useless and confusing here. I will > > > remove it. > > > >=20 > > > > > Why do we have both "state" and "version"? As defined in > > > > these drafts, > > > >=20 > > > > > state=3Dfull if and only if version=3D0. You could delete=20 > the state=20 > > > > > parameter with no loss of information, so why is it there? > > > >=20 > > > > I believe the original need for the "state" was that=20 > the "version"=20 > > > > could be initialized to some random value. Now, if "version" is=20 > > > > always initialized to 0 there is no need for the "state"=20 > > > > attribute. Both solutions should work and if nobody=20 > else comments=20 > > > > otherwise I will remove the "state" attribute. > > > >=20 > > > > > 3261 currently allows overlapping non-INVITE > > transactions inside a > > > > > dialog (there's an open issue suggesting this might be a > > > bad thing, > > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D686). = Neither=20 > > > > > 3265 or simple-presence prohibit overlapping NOTIFYs.=20 > For full=20 > > > > > state documents, having multiple outstanding NOTIFYs=20 > is probably=20 > > > > > manageable. For partial state documents, at least as they are=20 > > > > > specified here, it could be disastrous. Consider four=20 > notifies=20 > > > > > N1(full), N2(partial), N3(full), N4(partial). If the=20 > recipient=20 > > > > > receives only N1 and N4 (something prevents N2 and N3=20 > from being=20 > > > > > delivered or simply delays them (packetloss over UDP for=20 > > > > > example)), it will apply the delta in N4 to the wrong=20 > full state=20 > > > > > document (N1 instead of N3). > > > >=20 > > > > Actually it wouldn't because of "version" handling. Section 4.5=20 > > > > applies here. But in any case this kind of behavior is quite bad > > as it might > > > > result in frequent subscription refreshes to obtain full > > > > presence state. > > > > More below. > > > >=20 > > > > > We > > > > > can preserve the properties of the existing system is=20 > we forbid > > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > > when any other > > > > > NOTIFY transaction is still in progress on > > > > this dialog. > > > >=20 > > > > This is a good point. Your proposed solution should=20 > work. This may=20 > > > > cause some extra implementation effort for PA but I=20 > cannot see any > > > > way around > > > > this. If no other comments are received I will add text=20 > forbidding > > > > sending a NOTIFY with a document with state=3D"partial"=20 > > > (version=3D0) when > > > > any other NOTIFY transaction is still in progress on=20 > this dialog. > > > >=20 > > > > > Section 4.5 of partial-notify says "If the watcher receives a > > > > > presence document whose "version" attribute value (is)=20 > > higher by > > > > > more than one with the locally stored value, the > > watcher assumes > > > > > that one or more NOTIFYs were lost. The watcher SHOULD either > > > > > refresh the subscription in order to receive a full presence=20 > > > > > document or terminate the subscription." Why is that=20 > > SHOULD? In > > > > > what scenario is any other course of action reasonable? > > (The only > > > > > one I can think of is _if_ we allow overlapping partial > > NOTIFYs, > > > > > then the watcher can wait around for awhile for the gaps > > > to fill in > > > > > - if we allow this, then we need to explicitly state=20 > this as why=20 > > > > > the above is SHOULD, not MUST. However, I think this=20 > should be a=20 > > > > > MUST.) > > > >=20 > > > > Well, there probably isn't any good cases where watcher wouldn't > > > > terminate or refresh subscription. Changing SHOULD to=20 > MUST should=20 > > > > provide more consistent behavior. > > > > =20 > > > > > Just below that, there's a "SHOULD discard the=20 > document" if it=20 > > > > > gets a partial notification with a lower version=20 > number. I don't=20 > > > > > see how this is right at all, and suggest that this=20 > MUST trigger=20 > > > > > a refresh or termination instead. (We wouldn't get to=20 > this logic=20 > > > > > if a NOTIFY was reordered and arrived late > > > > > - the CSeq processing logic would > > > > > have caught it). > > > >=20 > > > > Right, and if we don't allow sending new NOTIFYs if there > > > is a pending > > > > transaction then I believe reordering should never happen. > > > But if in > > > > this situation watcher receives a presence document with > > > lower version > > > > number there should be no harm in discarding it because it > > > already has > > > > a consistent presence state. This is more or less an error > > > case which > > > > probably should never happen but I think there is no need to > > > > refresh or > > > > terminate the subscription. > > > >=20 > > > > - Mikko > > > >=20 > > > > > I'll send a separate message on the Security Considerations=20 > > > > > section for -partial-notify. > > > > >=20 > > > > > RjS > > > > >=20 > > > > >=20 > > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > > This is a Working Group Last call on the following drafts: > > > > > >=20 > > > > > >=20 > > > > > http://www.ietf.org/internet-drafts/draft-> > > > > ietf-simple-partial-notify-0 > > > > > > 2.txt > > > > > >=20 > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > > pidf-format-01.txt > > > > >=20 > > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > > >=20 > > > > > These drafts went through a previous last call at the > > beginning of > > > > > March. These versions reflect changes due to comments > > > > received during > > > > > that period. See > > > > >=20 > > >=20 > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > > 519.html > > > for details. > > >=20 > > > Please send comments to the list, copying the editor. If > > you reviewed > > > the draft and found no issues, please indicate so on the list. > > >=20 > > > RjS > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 10:09:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03454 for ; Thu, 29 Apr 2004 10:09:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCDt-0001I5-Bx for simple-archive@ietf.org; Thu, 29 Apr 2004 10:09:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCCu-00012I-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 10:08:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCBr-0000eM-00; Thu, 29 Apr 2004 10:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2F-0001su-Or; Thu, 29 Apr 2004 09:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBnx-0006Sj-5j for simple@optimus.ietf.org; Thu, 29 Apr 2004 09:42:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01565 for ; Thu, 29 Apr 2004 09:42:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBnm-0002No-EA for simple@ietf.org; Thu, 29 Apr 2004 09:42:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBmp-0002An-00 for simple@ietf.org; Thu, 29 Apr 2004 09:41:13 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJBmJ-0001wU-00 for simple@ietf.org; Thu, 29 Apr 2004 09:40:39 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3TDdE6r020987; Thu, 29 Apr 2004 08:39:15 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Mikko Lonnfors , simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017979E4@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E4@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083245971.2167.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 08:39:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Thu, 2004-04-29 at 07:36, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > > ext hisham.khartabil@nokia.com > > Sent: 27.April.2004 13:05 > > To: Lonnfors Mikko (Nokia-NRC/Helsinki); rsparks@dynamicsoft.com; > > simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > > > > > > > > > > > -----Original Message----- > > > From: Lonnfors Mikko (Nokia-NRC/Helsinki) > > > Sent: 27.April.2004 12:46 > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); > > > 'rsparks@dynamicsoft.com'; > > > 'simple@ietf.org' > > > Subject: RE: [Simple] WGLC: partial notification > > > > > > > > > Hi, > > > > > > > Here is an example where both state and version are needed: > > > > > > > > PA sends N1(full), N2(full), N3(partial). > > > > > > > > If the version is set to 0 everytime there is full state, and > > > > N2 was never received, the subscriber would then think that > > > > N3 is a partial of N1. > > > > > > > > To solve this, you need the version to continuously increase > > > > by 1, even when a full state is being sent. You would then > > > > also need the state attribute to indicate full/partial. The > > > > version is used by the subscriber to learn that a NOTIFY was > > > > not received (N2). > > > > > > Ok, so your proposal is that "version" should be scoped with > > > the subscription i.e. first NOTIFY within a subscription > > > would have version="0" and then it would be continuously > > > increased by one for every notifications (regardless if it > > > contains full or partial state)? > > > > > > How should subscription refreshes be handled? If we have > > > PA sends N1(full), N2(full), N3(partial) > > > And N2 is lost watcher would refresh the subscription when it > > > receives N3. Now > > > Would the PA send N1(full, version="0") or N4(full, version="3")? > > > > version gets reset to 0 when a SUBSCRIBE refresh is received. > > Now that I think about this a little more, I think the version should forever increase for the whole duration of the subscription, including refreshes. Imagine this scenario: > > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full, version 0) > ----> 200 > X-- NOTIFY2 (full, version 1) If you didn't allow overlapping NOTIFYs (which is still how I think you should solve this), then the subscription would be terminated at this point. > <---- NOTIFY3 (partial, version 3) > ----> 200 > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY4 (full, version 0) > ----> 200 > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives > > How does the subscribe know that the last NOTIFY (NOTIFY2) was sent after the subscribe refresh? If NOTIFY 4 had version 4 instead of 0, then it would. > > /Hisham > > > > > /Hisham > > > > > > - Mikko > > > > > > > /Hisham > > > > > > > > > -----Original Message----- > > > > > From: simple-admin@ietf.org > > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > > ext mikko.lonnfors@nokia.com > > > > > Sent: 26.April.2004 22:17 > > > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > > > Subject: RE: [Simple] WGLC: partial notification > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Thanks for comments. Responses inline: > > > > > > > > > > > Writing as a WG member - not as chair - > > > > > > > > > > > > I've sent a list of typo level nits in these drafts to > > > > > Mikko privately > > > > > > > > > > > - > > > > > > > > > > > > While doing a nit review, I found some things that should have > > > > > > received list attention earlier. > > > > > > > > > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > > > construct the > > > > > > > > > > > partial presence document according to the following > > > > > logic:" followed > > > > > > by a bunch of MUST level statements. Why is that SHOULD > > > > there? What > > > > > > would it mean to violate it? I suggest striking it and > > > > > simply saying > > > > > > "The PA constructs" > > > > > > > > > > Yes, SHOULD is probably useless and confusing here. I will > > > > remove it. > > > > > > > > > > > Why do we have both "state" and "version"? As defined in > > > > > these drafts, > > > > > > > > > > > state=full if and only if version=0. You could delete > > the state > > > > > > parameter with no loss of information, so why is it there? > > > > > > > > > > I believe the original need for the "state" was that the > > > > > "version" could > > > > > be initialized to some random value. Now, if "version" is always > > > > > initialized to 0 there is no need for the "state" > > attribute. Both > > > > > solutions should work and if nobody else comments > > otherwise I will > > > > > remove the "state" attribute. > > > > > > > > > > > 3261 currently allows overlapping non-INVITE > > > transactions inside a > > > > > > dialog (there's an open issue suggesting this might be a > > > > bad thing, > > > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither > > > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For > > > > > > full state documents, having multiple outstanding NOTIFYs is > > > > > > probably manageable. For partial state documents, at least as > > > > > > they are specified here, it could be disastrous. Consider > > > > > > four notifies N1(full), N2(partial), N3(full), N4(partial). > > > > > > If the recipient receives only N1 and N4 (something prevents > > > > > > N2 and N3 from being delivered or simply delays them > > > > > > (packetloss over UDP for example)), it will apply the delta > > > > > > in N4 to the wrong full state document (N1 instead of N3). > > > > > > > > > > Actually it wouldn't because of "version" handling. Section > > > > > 4.5 applies > > > > > here. But in any case this kind of behavior is quite bad > > > as it might > > > > > result in frequent subscription refreshes to obtain full > > > > > presence state. > > > > > More below. > > > > > > > > > > > We > > > > > > can preserve the properties of the existing system is > > we forbid > > > > > > sending a NOTIFY with a document with state="partial" > > > > when any other > > > > > > NOTIFY transaction is still in progress on > > > > > this dialog. > > > > > > > > > > This is a good point. Your proposed solution should work. > > > > > This may cause > > > > > some extra implementation effort for PA but I cannot see any > > > > > way around > > > > > this. If no other comments are received I will add text > > forbidding > > > > > sending a NOTIFY with a document with state="partial" > > > > (version=0) when > > > > > any other NOTIFY transaction is still in progress on > > this dialog. > > > > > > > > > > > Section 4.5 of partial-notify says "If the watcher receives a > > > > > > presence document whose "version" attribute value (is) > > > higher by > > > > > > more than one with the locally stored value, the > > > watcher assumes > > > > > > that one or more NOTIFYs were lost. The watcher SHOULD either > > > > > > refresh the subscription in order to receive a full presence > > > > > > document or terminate the subscription." Why is that > > > SHOULD? In > > > > > > what scenario is any other course of action reasonable? > > > (The only > > > > > > one I can think of is _if_ we allow overlapping partial > > > NOTIFYs, > > > > > > then the watcher can wait around for awhile for the gaps > > > > to fill in > > > > > > - if we allow this, then we need to explicitly state this as > > > > > > why the above is SHOULD, not MUST. However, I think this > > > > > > should be a MUST.) > > > > > > > > > > Well, there probably isn't any good cases where watcher > > wouldn't > > > > > terminate or refresh subscription. Changing SHOULD to > > MUST should > > > > > provide more consistent behavior. > > > > > > > > > > > Just below that, there's a "SHOULD discard the document" if > > > > > > it gets a partial notification with a lower version number. I > > > > > > don't see how this is right at all, and suggest that this > > > > > > MUST trigger a refresh or termination instead. (We wouldn't > > > > > > get to this logic if a NOTIFY was reordered and arrived late > > > > > > - the CSeq processing logic would > > > > > > have caught it). > > > > > > > > > > Right, and if we don't allow sending new NOTIFYs if there > > > > is a pending > > > > > transaction then I believe reordering should never happen. > > > > But if in > > > > > this situation watcher receives a presence document with > > > > lower version > > > > > number there should be no harm in discarding it because it > > > > already has > > > > > a consistent presence state. This is more or less an error > > > > case which > > > > > probably should never happen but I think there is no need to > > > > > refresh or > > > > > terminate the subscription. > > > > > > > > > > - Mikko > > > > > > > > > > > I'll send a separate message on the Security Considerations > > > > > > section for -partial-notify. > > > > > > > > > > > > RjS > > > > > > > > > > > > > > > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > > > This is a Working Group Last call on the following drafts: > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-> > > > > > ietf-simple-partial-notify-0 > > > > > > > 2.txt > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > > > pidf-format-01.txt > > > > > > > > > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > > > > > > > > > > These drafts went through a previous last call at the > > > beginning of > > > > > > March. These versions reflect changes due to comments > > > > > received during > > > > > > that period. See > > > > > > > > > > > > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > > > 519.html > > > > for details. > > > > > > > > Please send comments to the list, copying the editor. If > > > you reviewed > > > > the draft and found no issues, please indicate so on the list. > > > > > > > > RjS > > > > > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 10:13:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03962 for ; Thu, 29 Apr 2004 10:13:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCHv-0002L0-NR for simple-archive@ietf.org; Thu, 29 Apr 2004 10:13:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCGy-00025e-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 10:12:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCGD-0001qW-00; Thu, 29 Apr 2004 10:11:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2J-0001uC-Vk; Thu, 29 Apr 2004 09:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBrq-0007QN-2z for simple@optimus.ietf.org; Thu, 29 Apr 2004 09:46:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01639 for ; Thu, 29 Apr 2004 09:46:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBrf-0003Hh-Bm for simple@ietf.org; Thu, 29 Apr 2004 09:46:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBqh-00033J-00 for simple@ietf.org; Thu, 29 Apr 2004 09:45:12 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJBpl-0002bw-00 for simple@ietf.org; Thu, 29 Apr 2004 09:44:13 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3TDgn6r020990; Thu, 29 Apr 2004 08:42:49 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Mikko Lonnfors , simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083246185.2167.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 08:43:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline On Thu, 2004-04-29 at 07:44, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: Lonnfors Mikko (Nokia-NRC/Helsinki) > > Sent: 29.April.2004 15:40 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > > simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > > > > > > > > > > > > > > > Ok, so your proposal is that "version" should be scoped with > > > > > the subscription i.e. first NOTIFY within a subscription > > > > > would have version="0" and then it would be continuously > > > > > increased by one for every notifications (regardless if it > > > > > contains full or partial state)? > > > > > > > > > > How should subscription refreshes be handled? If we have > > > > > PA sends N1(full), N2(full), N3(partial) > > > > > And N2 is lost watcher would refresh the subscription when it > > > > > receives N3. Now > > > > > Would the PA send N1(full, version="0") or N4(full, > > version="3")? > > > > > > > > version gets reset to 0 when a SUBSCRIBE refresh is received. > > > > > > Now that I think about this a little more, I think the > > > version should forever increase for the whole duration of the > > > subscription, including refreshes. Imagine this scenario: > > > > > > ----> SUBSCRIBE > > > <---- 200 > > > <---- NOTIFY1 (full, version 0) > > > ----> 200 > > > X-- NOTIFY2 (full, version 1) > > > <---- NOTIFY3 (partial, version 3) > > > ----> 200 > > > ----> SUBSCRIBE > > > <---- 200 > > > <---- NOTIFY4 (full, version 0) > > > ----> 200 > > > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives > > > > > > How does the subscribe know that the last NOTIFY (NOTIFY2) > > > was sent after the subscribe refresh? If NOTIFY 4 had version > > > 4 instead of 0, then it would. > > > > > > /Hisham > > > > If we don't allow new NOTIFY messages if there is a pending > > NOTIFY is this still a problem? > > This would fix the problem, but I prefer not to disallow it since > RFC3265 does not disallow it nor presence-07. > > I believe increasing the version for the duration of the subscription > would fix this. See my response to Paul's variation of this suggestion. If you do this, you open a new attack against this mechanism. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 10:20:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04686 for ; Thu, 29 Apr 2004 10:20:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCOY-00049Q-7f for simple-archive@ietf.org; Thu, 29 Apr 2004 10:20:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCNY-0003rh-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 10:19:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCMa-0003bG-00; Thu, 29 Apr 2004 10:18:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC3C-0002Bv-HL; Thu, 29 Apr 2004 09:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBut-00088v-FY for simple@optimus.ietf.org; Thu, 29 Apr 2004 09:49:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01965 for ; Thu, 29 Apr 2004 09:49:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBui-00044u-P3 for simple@ietf.org; Thu, 29 Apr 2004 09:49:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBtr-0003qd-00 for simple@ietf.org; Thu, 29 Apr 2004 09:48:27 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJBtH-0003ZL-00 for simple@ietf.org; Thu, 29 Apr 2004 09:47:51 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3TDkR6r020995; Thu, 29 Apr 2004 08:46:27 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Mikko Lonnfors , simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083246403.2167.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 08:46:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > > > > If we don't allow new NOTIFY messages if there is a pending > > NOTIFY is this still a problem? > > This would fix the problem, but I prefer not to disallow it since > RFC3265 does not disallow it nor presence-07. It's still an open question whether leaving the possibility of overlapping NOTIFYs in a subscription was a good idea. In this case, we've identified a place where it isn't, and where disallowing them is a simpler solution than putting in the machinery to deal with them ->for no gain in functionality<-. So, I don't understand your sentiment. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 10:30:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05429 for ; Thu, 29 Apr 2004 10:30:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCOj-0005z8-Qg for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEKLFZ023002 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCE4-0000CH-WB for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:09:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03469 for ; Thu, 29 Apr 2004 10:09:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCDu-0001IA-2S for simple-web-archive@ietf.org; Thu, 29 Apr 2004 10:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCCv-00012P-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 10:08:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCBr-0000eM-00; Thu, 29 Apr 2004 10:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2F-0001su-Or; Thu, 29 Apr 2004 09:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBnx-0006Sj-5j for simple@optimus.ietf.org; Thu, 29 Apr 2004 09:42:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01565 for ; Thu, 29 Apr 2004 09:42:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBnm-0002No-EA for simple@ietf.org; Thu, 29 Apr 2004 09:42:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBmp-0002An-00 for simple@ietf.org; Thu, 29 Apr 2004 09:41:13 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJBmJ-0001wU-00 for simple@ietf.org; Thu, 29 Apr 2004 09:40:39 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3TDdE6r020987; Thu, 29 Apr 2004 08:39:15 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Mikko Lonnfors , simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017979E4@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E4@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083245971.2167.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 08:39:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-04-29 at 07:36, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > > ext hisham.khartabil@nokia.com > > Sent: 27.April.2004 13:05 > > To: Lonnfors Mikko (Nokia-NRC/Helsinki); rsparks@dynamicsoft.com; > > simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > > > > > > > > > > > -----Original Message----- > > > From: Lonnfors Mikko (Nokia-NRC/Helsinki) > > > Sent: 27.April.2004 12:46 > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); > > > 'rsparks@dynamicsoft.com'; > > > 'simple@ietf.org' > > > Subject: RE: [Simple] WGLC: partial notification > > > > > > > > > Hi, > > > > > > > Here is an example where both state and version are needed: > > > > > > > > PA sends N1(full), N2(full), N3(partial). > > > > > > > > If the version is set to 0 everytime there is full state, and > > > > N2 was never received, the subscriber would then think that > > > > N3 is a partial of N1. > > > > > > > > To solve this, you need the version to continuously increase > > > > by 1, even when a full state is being sent. You would then > > > > also need the state attribute to indicate full/partial. The > > > > version is used by the subscriber to learn that a NOTIFY was > > > > not received (N2). > > > > > > Ok, so your proposal is that "version" should be scoped with > > > the subscription i.e. first NOTIFY within a subscription > > > would have version="0" and then it would be continuously > > > increased by one for every notifications (regardless if it > > > contains full or partial state)? > > > > > > How should subscription refreshes be handled? If we have > > > PA sends N1(full), N2(full), N3(partial) > > > And N2 is lost watcher would refresh the subscription when it > > > receives N3. Now > > > Would the PA send N1(full, version="0") or N4(full, version="3")? > > > > version gets reset to 0 when a SUBSCRIBE refresh is received. > > Now that I think about this a little more, I think the version should forever increase for the whole duration of the subscription, including refreshes. Imagine this scenario: > > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY1 (full, version 0) > ----> 200 > X-- NOTIFY2 (full, version 1) If you didn't allow overlapping NOTIFYs (which is still how I think you should solve this), then the subscription would be terminated at this point. > <---- NOTIFY3 (partial, version 3) > ----> 200 > ----> SUBSCRIBE > <---- 200 > <---- NOTIFY4 (full, version 0) > ----> 200 > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives > > How does the subscribe know that the last NOTIFY (NOTIFY2) was sent after the subscribe refresh? If NOTIFY 4 had version 4 instead of 0, then it would. > > /Hisham > > > > > /Hisham > > > > > > - Mikko > > > > > > > /Hisham > > > > > > > > > -----Original Message----- > > > > > From: simple-admin@ietf.org > > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > > > ext mikko.lonnfors@nokia.com > > > > > Sent: 26.April.2004 22:17 > > > > > To: rsparks@dynamicsoft.com; simple@ietf.org > > > > > Subject: RE: [Simple] WGLC: partial notification > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Thanks for comments. Responses inline: > > > > > > > > > > > Writing as a WG member - not as chair - > > > > > > > > > > > > I've sent a list of typo level nits in these drafts to > > > > > Mikko privately > > > > > > > > > > > - > > > > > > > > > > > > While doing a nit review, I found some things that should have > > > > > > received list attention earlier. > > > > > > > > > > > > In section 4.4 of -partial-notify it says "The PA SHOULD > > > > > construct the > > > > > > > > > > > partial presence document according to the following > > > > > logic:" followed > > > > > > by a bunch of MUST level statements. Why is that SHOULD > > > > there? What > > > > > > would it mean to violate it? I suggest striking it and > > > > > simply saying > > > > > > "The PA constructs" > > > > > > > > > > Yes, SHOULD is probably useless and confusing here. I will > > > > remove it. > > > > > > > > > > > Why do we have both "state" and "version"? As defined in > > > > > these drafts, > > > > > > > > > > > state=full if and only if version=0. You could delete > > the state > > > > > > parameter with no loss of information, so why is it there? > > > > > > > > > > I believe the original need for the "state" was that the > > > > > "version" could > > > > > be initialized to some random value. Now, if "version" is always > > > > > initialized to 0 there is no need for the "state" > > attribute. Both > > > > > solutions should work and if nobody else comments > > otherwise I will > > > > > remove the "state" attribute. > > > > > > > > > > > 3261 currently allows overlapping non-INVITE > > > transactions inside a > > > > > > dialog (there's an open issue suggesting this might be a > > > > bad thing, > > > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither > > > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For > > > > > > full state documents, having multiple outstanding NOTIFYs is > > > > > > probably manageable. For partial state documents, at least as > > > > > > they are specified here, it could be disastrous. Consider > > > > > > four notifies N1(full), N2(partial), N3(full), N4(partial). > > > > > > If the recipient receives only N1 and N4 (something prevents > > > > > > N2 and N3 from being delivered or simply delays them > > > > > > (packetloss over UDP for example)), it will apply the delta > > > > > > in N4 to the wrong full state document (N1 instead of N3). > > > > > > > > > > Actually it wouldn't because of "version" handling. Section > > > > > 4.5 applies > > > > > here. But in any case this kind of behavior is quite bad > > > as it might > > > > > result in frequent subscription refreshes to obtain full > > > > > presence state. > > > > > More below. > > > > > > > > > > > We > > > > > > can preserve the properties of the existing system is > > we forbid > > > > > > sending a NOTIFY with a document with state="partial" > > > > when any other > > > > > > NOTIFY transaction is still in progress on > > > > > this dialog. > > > > > > > > > > This is a good point. Your proposed solution should work. > > > > > This may cause > > > > > some extra implementation effort for PA but I cannot see any > > > > > way around > > > > > this. If no other comments are received I will add text > > forbidding > > > > > sending a NOTIFY with a document with state="partial" > > > > (version=0) when > > > > > any other NOTIFY transaction is still in progress on > > this dialog. > > > > > > > > > > > Section 4.5 of partial-notify says "If the watcher receives a > > > > > > presence document whose "version" attribute value (is) > > > higher by > > > > > > more than one with the locally stored value, the > > > watcher assumes > > > > > > that one or more NOTIFYs were lost. The watcher SHOULD either > > > > > > refresh the subscription in order to receive a full presence > > > > > > document or terminate the subscription." Why is that > > > SHOULD? In > > > > > > what scenario is any other course of action reasonable? > > > (The only > > > > > > one I can think of is _if_ we allow overlapping partial > > > NOTIFYs, > > > > > > then the watcher can wait around for awhile for the gaps > > > > to fill in > > > > > > - if we allow this, then we need to explicitly state this as > > > > > > why the above is SHOULD, not MUST. However, I think this > > > > > > should be a MUST.) > > > > > > > > > > Well, there probably isn't any good cases where watcher > > wouldn't > > > > > terminate or refresh subscription. Changing SHOULD to > > MUST should > > > > > provide more consistent behavior. > > > > > > > > > > > Just below that, there's a "SHOULD discard the document" if > > > > > > it gets a partial notification with a lower version number. I > > > > > > don't see how this is right at all, and suggest that this > > > > > > MUST trigger a refresh or termination instead. (We wouldn't > > > > > > get to this logic if a NOTIFY was reordered and arrived late > > > > > > - the CSeq processing logic would > > > > > > have caught it). > > > > > > > > > > Right, and if we don't allow sending new NOTIFYs if there > > > > is a pending > > > > > transaction then I believe reordering should never happen. > > > > But if in > > > > > this situation watcher receives a presence document with > > > > lower version > > > > > number there should be no harm in discarding it because it > > > > already has > > > > > a consistent presence state. This is more or less an error > > > > case which > > > > > probably should never happen but I think there is no need to > > > > > refresh or > > > > > terminate the subscription. > > > > > > > > > > - Mikko > > > > > > > > > > > I'll send a separate message on the Security Considerations > > > > > > section for -partial-notify. > > > > > > > > > > > > RjS > > > > > > > > > > > > > > > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote: > > > > > > > This is a Working Group Last call on the following drafts: > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-> > > > > > ietf-simple-partial-notify-0 > > > > > > > 2.txt > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- > > > > > pidf-format-01.txt > > > > > > > > > > > > This abbreviated WGLC will end on Wednesday, April 28. > > > > > > > > > > > > These drafts went through a previous last call at the > > > beginning of > > > > > > March. These versions reflect changes due to comments > > > > > received during > > > > > > that period. See > > > > > > > > > > > > https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02 > > > > 519.html > > > > for details. > > > > > > > > Please send comments to the list, copying the editor. If > > > you reviewed > > > > the draft and found no issues, please indicate so on the list. > > > > > > > > RjS > > > > > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 10:30:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05507 for ; Thu, 29 Apr 2004 10:30:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCOw-00062e-1M for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEKYt8023218 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCI7-0001zz-DP for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:13:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03976 for ; Thu, 29 Apr 2004 10:13:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCHw-0002L6-B9 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 10:13:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCGz-00025l-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 10:12:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCGD-0001qW-00; Thu, 29 Apr 2004 10:11:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2J-0001uC-Vk; Thu, 29 Apr 2004 09:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBrq-0007QN-2z for simple@optimus.ietf.org; Thu, 29 Apr 2004 09:46:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01639 for ; Thu, 29 Apr 2004 09:46:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBrf-0003Hh-Bm for simple@ietf.org; Thu, 29 Apr 2004 09:46:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBqh-00033J-00 for simple@ietf.org; Thu, 29 Apr 2004 09:45:12 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJBpl-0002bw-00 for simple@ietf.org; Thu, 29 Apr 2004 09:44:13 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3TDgn6r020990; Thu, 29 Apr 2004 08:42:49 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Mikko Lonnfors , simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083246185.2167.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 08:43:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline On Thu, 2004-04-29 at 07:44, hisham.khartabil@nokia.com wrote: > > -----Original Message----- > > From: Lonnfors Mikko (Nokia-NRC/Helsinki) > > Sent: 29.April.2004 15:40 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; > > simple@ietf.org > > Subject: RE: [Simple] WGLC: partial notification > > > > > > > > > > > > > > > Ok, so your proposal is that "version" should be scoped with > > > > > the subscription i.e. first NOTIFY within a subscription > > > > > would have version="0" and then it would be continuously > > > > > increased by one for every notifications (regardless if it > > > > > contains full or partial state)? > > > > > > > > > > How should subscription refreshes be handled? If we have > > > > > PA sends N1(full), N2(full), N3(partial) > > > > > And N2 is lost watcher would refresh the subscription when it > > > > > receives N3. Now > > > > > Would the PA send N1(full, version="0") or N4(full, > > version="3")? > > > > > > > > version gets reset to 0 when a SUBSCRIBE refresh is received. > > > > > > Now that I think about this a little more, I think the > > > version should forever increase for the whole duration of the > > > subscription, including refreshes. Imagine this scenario: > > > > > > ----> SUBSCRIBE > > > <---- 200 > > > <---- NOTIFY1 (full, version 0) > > > ----> 200 > > > X-- NOTIFY2 (full, version 1) > > > <---- NOTIFY3 (partial, version 3) > > > ----> 200 > > > ----> SUBSCRIBE > > > <---- 200 > > > <---- NOTIFY4 (full, version 0) > > > ----> 200 > > > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives > > > > > > How does the subscribe know that the last NOTIFY (NOTIFY2) > > > was sent after the subscribe refresh? If NOTIFY 4 had version > > > 4 instead of 0, then it would. > > > > > > /Hisham > > > > If we don't allow new NOTIFY messages if there is a pending > > NOTIFY is this still a problem? > > This would fix the problem, but I prefer not to disallow it since > RFC3265 does not disallow it nor presence-07. > > I believe increasing the version for the duration of the subscription > would fix this. See my response to Paul's variation of this suggestion. If you do this, you open a new attack against this mechanism. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 10:46:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06506 for ; Thu, 29 Apr 2004 10:46:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCYP-0008N1-Bv for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 10:30:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEUKhq032156 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 10:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCOj-0005zL-Uq for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:20:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04703 for ; Thu, 29 Apr 2004 10:20:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCOY-00049V-Sn for simple-web-archive@ietf.org; Thu, 29 Apr 2004 10:20:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCNZ-0003rp-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 10:19:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCMa-0003bG-00; Thu, 29 Apr 2004 10:18:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC3C-0002Bv-HL; Thu, 29 Apr 2004 09:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBut-00088v-FY for simple@optimus.ietf.org; Thu, 29 Apr 2004 09:49:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01965 for ; Thu, 29 Apr 2004 09:49:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBui-00044u-P3 for simple@ietf.org; Thu, 29 Apr 2004 09:49:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBtr-0003qd-00 for simple@ietf.org; Thu, 29 Apr 2004 09:48:27 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJBtH-0003ZL-00 for simple@ietf.org; Thu, 29 Apr 2004 09:47:51 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3TDkR6r020995; Thu, 29 Apr 2004 08:46:27 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Mikko Lonnfors , simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083246403.2167.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 08:46:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > If we don't allow new NOTIFY messages if there is a pending > > NOTIFY is this still a problem? > > This would fix the problem, but I prefer not to disallow it since > RFC3265 does not disallow it nor presence-07. It's still an open question whether leaving the possibility of overlapping NOTIFYs in a subscription was a good idea. In this case, we've identified a place where it isn't, and where disallowing them is a simpler solution than putting in the machinery to deal with them ->for no gain in functionality<-. So, I don't understand your sentiment. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 12:11:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11438 for ; Thu, 29 Apr 2004 12:11:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJE85-0002ut-Q7 for simple-archive@ietf.org; Thu, 29 Apr 2004 12:11:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJE7C-0002f3-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 12:10:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJE6T-0002PX-00; Thu, 29 Apr 2004 12:09:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDqg-00060N-PN; Thu, 29 Apr 2004 11:53:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDi1-0003me-Hk for simple@optimus.ietf.org; Thu, 29 Apr 2004 11:44:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10009 for ; Thu, 29 Apr 2004 11:44:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDhx-0003SU-50 for simple@ietf.org; Thu, 29 Apr 2004 11:44:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDh3-0003DP-00 for simple@ietf.org; Thu, 29 Apr 2004 11:43:22 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJDgJ-0002i0-00 for simple@ietf.org; Thu, 29 Apr 2004 11:42:35 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TFg5W9017566; Thu, 29 Apr 2004 08:42:06 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA59451; Thu, 29 Apr 2004 11:42:05 -0400 (EDT) Message-ID: <4091224D.3060303@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 11:42:05 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > >>I believe increasing the version for the duration of the subscription >>would fix this. > > > See my response to Paul's variation of this suggestion. > If you do this, you open a new attack against this mechanism. If someone is in a position to mount that kind of attack, how do any of these approaches improve the attackee's experience? Apparently the attacker can inject arbitrary bogus notifications at any time. If the recipient can "recover" when it receives a notification with good data, then it will have no way of knowing when it has good data and when it has bad data. How is that better than having the attack crash the subscription altogether? At least then it will know it is under attack. The only real defense here is a secure session. Paul Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 12:43:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13301 for ; Thu, 29 Apr 2004 12:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJETR-00030a-Fz for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TGXLov011565 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJE8B-0003L4-8Y for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 12:11:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11456 for ; Thu, 29 Apr 2004 12:11:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJE86-0002uy-Fd for simple-web-archive@ietf.org; Thu, 29 Apr 2004 12:11:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJE7D-0002fA-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 12:10:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJE6T-0002PX-00; Thu, 29 Apr 2004 12:09:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDqg-00060N-PN; Thu, 29 Apr 2004 11:53:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDi1-0003me-Hk for simple@optimus.ietf.org; Thu, 29 Apr 2004 11:44:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10009 for ; Thu, 29 Apr 2004 11:44:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDhx-0003SU-50 for simple@ietf.org; Thu, 29 Apr 2004 11:44:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDh3-0003DP-00 for simple@ietf.org; Thu, 29 Apr 2004 11:43:22 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJDgJ-0002i0-00 for simple@ietf.org; Thu, 29 Apr 2004 11:42:35 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TFg5W9017566; Thu, 29 Apr 2004 08:42:06 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA59451; Thu, 29 Apr 2004 11:42:05 -0400 (EDT) Message-ID: <4091224D.3060303@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 11:42:05 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Sparks wrote: > >>I believe increasing the version for the duration of the subscription >>would fix this. > > > See my response to Paul's variation of this suggestion. > If you do this, you open a new attack against this mechanism. If someone is in a position to mount that kind of attack, how do any of these approaches improve the attackee's experience? Apparently the attacker can inject arbitrary bogus notifications at any time. If the recipient can "recover" when it receives a notification with good data, then it will have no way of knowing when it has good data and when it has bad data. How is that better than having the attack crash the subscription altogether? At least then it will know it is under attack. The only real defense here is a secure session. Paul Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 15:13:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21004 for ; Thu, 29 Apr 2004 15:13:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGyJ-0003QH-JK for simple-archive@ietf.org; Thu, 29 Apr 2004 15:13:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGxQ-0003NU-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 15:12:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJGx1-0003Kh-00; Thu, 29 Apr 2004 15:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhE-0003n8-49; Thu, 29 Apr 2004 14:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFeK-0006Ka-N8 for simple@optimus.ietf.org; Thu, 29 Apr 2004 13:48:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16375 for ; Thu, 29 Apr 2004 13:48:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFeF-0006ZM-60 for simple@ietf.org; Thu, 29 Apr 2004 13:48:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFdF-0006Dd-00 for simple@ietf.org; Thu, 29 Apr 2004 13:47:33 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJFcH-0005aS-00 for simple@ietf.org; Thu, 29 Apr 2004 13:46:33 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3THib6r021203; Thu, 29 Apr 2004 12:44:38 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: Paul Kyzivat Cc: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org In-Reply-To: <4091224D.3060303@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> Content-Type: text/plain Message-Id: <1083260693.2167.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 12:44:53 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Of course a secure session is the correct defense. Understanding the differences in the behavior of the proposed changes without that security is still a useful tool for comparing them. Those differences may have ramifications in scenarios other than the attack/security scenario I'm using to point at them. The current draft (almost) has the property that a client can reset all the partial-oriented state by issuing a subscription refresh. It can get back to a clean start-state wrt the extensions being defined here. If you change to increasing versions across full notifications, a client has to tear down the subscription and resubscribe to get back to that clean start-state. I think we want to preserve (and refine) the property the current draft has. RjS On Thu, 2004-04-29 at 10:42, Paul Kyzivat wrote: > Robert Sparks wrote: > > > >>I believe increasing the version for the duration of the subscription > >>would fix this. > > > > > > See my response to Paul's variation of this suggestion. > > If you do this, you open a new attack against this mechanism. > > If someone is in a position to mount that kind of attack, how do any of > these approaches improve the attackee's experience? > > Apparently the attacker can inject arbitrary bogus notifications at any > time. If the recipient can "recover" when it receives a notification > with good data, then it will have no way of knowing when it has good > data and when it has bad data. How is that better than having the attack > crash the subscription altogether? At least then it will know it is > under attack. > > The only real defense here is a secure session. > > Paul > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 15:17:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21534 for ; Thu, 29 Apr 2004 15:17:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH2B-0003eA-2Y for simple-archive@ietf.org; Thu, 29 Apr 2004 15:17:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH1F-0003aF-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 15:16:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH0g-0003Xw-00; Thu, 29 Apr 2004 15:15:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhH-0003oE-5Y; Thu, 29 Apr 2004 14:55:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFfk-0006tI-CI for simple@optimus.ietf.org; Thu, 29 Apr 2004 13:50:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16538 for ; Thu, 29 Apr 2004 13:50:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFfe-0006xi-PM for simple@ietf.org; Thu, 29 Apr 2004 13:50:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFeV-0006bm-00 for simple@ietf.org; Thu, 29 Apr 2004 13:48:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJFdo-0006EN-00 for simple@ietf.org; Thu, 29 Apr 2004 13:48:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Apr 2004 09:59:48 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3THlcW9022912; Thu, 29 Apr 2004 10:47:39 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AON42853; Thu, 29 Apr 2004 10:47:37 -0700 (PDT) From: David Oran To: Robert Sparks , Hisham Khartabil cc: Mikko Lonnfors , simple@ietf.org Subject: RE: [Simple] WGLC: partial notification Message-ID: <32153163E336A50578840380@[10.32.245.156]> In-Reply-To: <1083246185.2167.4.camel@localhost.localdomain> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:47:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit from left field...could this be solved by using the CSEQ of the subscription refreshes as the high order part of the version number? --On Thursday, April 29, 2004 8:43 AM -0500 Robert Sparks wrote: > inline > On Thu, 2004-04-29 at 07:44, hisham.khartabil@nokia.com wrote: >> > -----Original Message----- >> > From: Lonnfors Mikko (Nokia-NRC/Helsinki) >> > Sent: 29.April.2004 15:40 >> > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; >> > simple@ietf.org >> > Subject: RE: [Simple] WGLC: partial notification >> > >> > >> > >> > >> > >> > > > > Ok, so your proposal is that "version" should be scoped with >> > > > > the subscription i.e. first NOTIFY within a subscription >> > > > > would have version="0" and then it would be continuously >> > > > > increased by one for every notifications (regardless if it >> > > > > contains full or partial state)? >> > > > > >> > > > > How should subscription refreshes be handled? If we have >> > > > > PA sends N1(full), N2(full), N3(partial) >> > > > > And N2 is lost watcher would refresh the subscription when it >> > > > > receives N3. Now >> > > > > Would the PA send N1(full, version="0") or N4(full, >> > version="3")? >> > > > >> > > > version gets reset to 0 when a SUBSCRIBE refresh is received. >> > > >> > > Now that I think about this a little more, I think the >> > > version should forever increase for the whole duration of the >> > > subscription, including refreshes. Imagine this scenario: >> > > >> > > ----> SUBSCRIBE >> > > <---- 200 >> > > <---- NOTIFY1 (full, version 0) >> > > ----> 200 >> > > X-- NOTIFY2 (full, version 1) >> > > <---- NOTIFY3 (partial, version 3) >> > > ----> 200 >> > > ----> SUBSCRIBE >> > > <---- 200 >> > > <---- NOTIFY4 (full, version 0) >> > > ----> 200 >> > > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives >> > > >> > > How does the subscribe know that the last NOTIFY (NOTIFY2) >> > > was sent after the subscribe refresh? If NOTIFY 4 had version >> > > 4 instead of 0, then it would. >> > > >> > > /Hisham >> > >> > If we don't allow new NOTIFY messages if there is a pending >> > NOTIFY is this still a problem? >> >> This would fix the problem, but I prefer not to disallow it since >> RFC3265 does not disallow it nor presence-07. >> >> I believe increasing the version for the duration of the subscription >> would fix this. > > See my response to Paul's variation of this suggestion. > If you do this, you open a new attack against this mechanism. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 15:19:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21835 for ; Thu, 29 Apr 2004 15:19:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH4A-0003oC-QF for simple-archive@ietf.org; Thu, 29 Apr 2004 15:19:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH3I-0003kw-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 15:18:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH2e-0003hL-00; Thu, 29 Apr 2004 15:17:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhx-00049V-9O; Thu, 29 Apr 2004 14:56:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFtb-0001s2-Oc for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:04:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17483 for ; Thu, 29 Apr 2004 14:04:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFtW-0003Rt-0e for simple@ietf.org; Thu, 29 Apr 2004 14:04:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFsX-00039j-00 for simple@ietf.org; Thu, 29 Apr 2004 14:03:22 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJFrV-0002c9-00 for simple@ietf.org; Thu, 29 Apr 2004 14:02:17 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TI1lW9003945; Thu, 29 Apr 2004 11:01:48 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA73693; Thu, 29 Apr 2004 14:01:46 -0400 (EDT) Message-ID: <4091430A.8060505@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> <1083260693.2167.58.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 14:01:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > Of course a secure session is the correct defense. > > Understanding the differences in the behavior of the proposed > changes without that security is still a useful tool for > comparing them. Those differences may have ramifications in > scenarios other than the attack/security scenario I'm using > to point at them. > > The current draft (almost) has the property that a client > can reset all the partial-oriented state by issuing a > subscription refresh. It can get back to a clean start-state > wrt the extensions being defined here. This only comes up if somebody malicious is (successfully) hacking into the session. The client can attempt to reset, but can be hacked again after that. There is no reason for the client to assume that any results it gets are valid once it has been hacked. Nor does it know that it has been hacked. From the client's pov this is at least as likely to be assumed to be a malfunction of the server. > If you change to increasing versions across full notifications, > a client has to tear down the subscription and resubscribe to > get back to that clean start-state. > > I think we want to preserve (and refine) the property the current > draft has. Even tearing down the subscription and establishing a new one isn't likely to be helpful if you have an active attacker. If the hacker got in once, he can probably get in again. But if that is hard to do, then establishing a new session may give slightly better results. This is probably when you call for help to find and block the hacker. You may just have to give up on the subscription until then. I don't find any *useful* differences in resilience of the various alternatives to this kind of attack. Paul > RjS > > > On Thu, 2004-04-29 at 10:42, Paul Kyzivat wrote: > >>Robert Sparks wrote: >> >>>>I believe increasing the version for the duration of the subscription >>>>would fix this. >>> >>> >>>See my response to Paul's variation of this suggestion. >>>If you do this, you open a new attack against this mechanism. >> >>If someone is in a position to mount that kind of attack, how do any of >>these approaches improve the attackee's experience? >> >>Apparently the attacker can inject arbitrary bogus notifications at any >>time. If the recipient can "recover" when it receives a notification >>with good data, then it will have no way of knowing when it has good >>data and when it has bad data. How is that better than having the attack >>crash the subscription altogether? At least then it will know it is >>under attack. >> >>The only real defense here is a secure session. >> >> Paul >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 15:21:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22017 for ; Thu, 29 Apr 2004 15:21:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH6A-0003yb-2D for simple-archive@ietf.org; Thu, 29 Apr 2004 15:21:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH5R-0003uE-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 15:20:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH4O-0003pl-00; Thu, 29 Apr 2004 15:19:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGkP-00054T-06; Thu, 29 Apr 2004 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJG6E-0004b8-Hc for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18084 for ; Thu, 29 Apr 2004 14:17:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJG68-00072o-Ks for simple@ietf.org; Thu, 29 Apr 2004 14:17:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJG5L-0006mh-00 for simple@ietf.org; Thu, 29 Apr 2004 14:16:35 -0400 Received: from web21502.mail.yahoo.com ([66.163.169.13]) by ietf-mx with smtp (Exim 4.12) id 1BJG4h-0006Vl-00 for simple@ietf.org; Thu, 29 Apr 2004 14:15:55 -0400 Message-ID: <20040429181557.26996.qmail@web21502.mail.yahoo.com> Received: from [192.75.88.231] by web21502.mail.yahoo.com via HTTP; Thu, 29 Apr 2004 11:15:57 PDT From: Rajesh Karunamurthy To: simple@ietf.org Cc: hisham.khartabil@nokia.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-490555774-1083262557=:26673" Subject: [Simple] Problem with XML Schema for Filter Criteria Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 11:15:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE autolearn=no version=2.60 --0-490555774-1083262557=:26673 Content-Type: text/plain; charset=us-ascii Hi, I am working on filtering of the Presence Document and I found that there is a small problem in the XML schema used for filtering. I used a standard XSD schema validator, http://apps.gotdotnet.com/xmltools/xsdvalidator/ and I got this error Error :The content model must be deterministic. Wildcard declaration along with a local element declaration causes the content model to become ambiguous. An error occurred at , (70, 6). Can any one help me out? Thanks. Rajesh --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs --0-490555774-1083262557=:26673 Content-Type: text/html; charset=us-ascii
Hi,
 
I am working on  filtering of the Presence Document and I found that there is a small problem in the XML schema used for filtering. I used a standard XSD schema validator,
 
Error :The content model must be deterministic. Wildcard declaration along with a local element declaration causes the content model to become ambiguous. An error occurred at , (70, 6).
 
Can any one help me out?
 
Thanks.
Rajesh
 
 
 

Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs --0-490555774-1083262557=:26673-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 15:22:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22084 for ; Thu, 29 Apr 2004 15:22:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH73-00043d-Et for simple-archive@ietf.org; Thu, 29 Apr 2004 15:22:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH62-0003xZ-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 15:21:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH5H-0003si-00; Thu, 29 Apr 2004 15:20:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGkQ-000554-PR; Thu, 29 Apr 2004 14:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGE8-00067y-Be for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:25:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18380 for ; Thu, 29 Apr 2004 14:25:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGE2-0001Sd-IX for simple@ietf.org; Thu, 29 Apr 2004 14:25:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGD3-0001BE-00 for simple@ietf.org; Thu, 29 Apr 2004 14:24:33 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJGC3-0000dE-00 for simple@ietf.org; Thu, 29 Apr 2004 14:23:31 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3TIKL6r021235; Thu, 29 Apr 2004 13:20:21 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: Paul Kyzivat Cc: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org In-Reply-To: <4091430A.8060505@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> <1083260693.2167.58.camel@localhost.localdomain> <4091430A.8060505@cisco.com> Content-Type: text/plain Message-Id: <1083262837.2167.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:20:37 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Aside from that I'd like for you to think through this again from viewpoints besides active attack (use a transient malfunction of the application (above the layer that would screw up basic SIP)), I'm ready to let this go as long as we have _a_ solid solution to dealing with reordered/missing notifies. So, backing out a layer, lets look at my original question of whether or not we allow overlapping ->partial<- NOTIFYs at all in this case. Why would you want to? What value would doing that bring? 3261 and even presence-10 left sending full-state presence NOTIFYs open. We wouldn't be changing that. If an application for some reason decided it needed to send a new full-state notify while a partial-state notify was pending, it could. So any of the arguments for allowing it from the 3261/presence-10 are still satisfied. Can you see any use case where allowing a server to send overlapping partial NOTIFYs is a good idea? If not, disallowing it seems a powerful simplification. RjS On Thu, 2004-04-29 at 13:01, Paul Kyzivat wrote: > Robert Sparks wrote: > > Of course a secure session is the correct defense. > > > > Understanding the differences in the behavior of the proposed > > changes without that security is still a useful tool for > > comparing them. Those differences may have ramifications in > > scenarios other than the attack/security scenario I'm using > > to point at them. > > > > The current draft (almost) has the property that a client > > can reset all the partial-oriented state by issuing a > > subscription refresh. It can get back to a clean start-state > > wrt the extensions being defined here. > > This only comes up if somebody malicious is (successfully) hacking into > the session. The client can attempt to reset, but can be hacked again > after that. There is no reason for the client to assume that any results > it gets are valid once it has been hacked. Nor does it know that it has > been hacked. From the client's pov this is at least as likely to be > assumed to be a malfunction of the server. > > > If you change to increasing versions across full notifications, > > a client has to tear down the subscription and resubscribe to > > get back to that clean start-state. > > > > I think we want to preserve (and refine) the property the current > > draft has. > > Even tearing down the subscription and establishing a new one isn't > likely to be helpful if you have an active attacker. If the hacker got > in once, he can probably get in again. But if that is hard to do, then > establishing a new session may give slightly better results. > > This is probably when you call for help to find and block the hacker. > You may just have to give up on the subscription until then. > > I don't find any *useful* differences in resilience of the various > alternatives to this kind of attack. > > Paul > > > RjS > > > > > > On Thu, 2004-04-29 at 10:42, Paul Kyzivat wrote: > > > >>Robert Sparks wrote: > >> > >>>>I believe increasing the version for the duration of the subscription > >>>>would fix this. > >>> > >>> > >>>See my response to Paul's variation of this suggestion. > >>>If you do this, you open a new attack against this mechanism. > >> > >>If someone is in a position to mount that kind of attack, how do any of > >>these approaches improve the attackee's experience? > >> > >>Apparently the attacker can inject arbitrary bogus notifications at any > >>time. If the recipient can "recover" when it receives a notification > >>with good data, then it will have no way of knowing when it has good > >>data and when it has bad data. How is that better than having the attack > >>crash the subscription altogether? At least then it will know it is > >>under attack. > >> > >>The only real defense here is a secure session. > >> > >> Paul > >> > >> Paul > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 15:23:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22186 for ; Thu, 29 Apr 2004 15:23:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH82-0004Ag-RF for simple-archive@ietf.org; Thu, 29 Apr 2004 15:23:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH75-00043x-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 15:22:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH6A-0003yp-00; Thu, 29 Apr 2004 15:21:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGkp-00057Y-GA; Thu, 29 Apr 2004 14:59:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGJw-0007Pr-J6 for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:31:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18618 for ; Thu, 29 Apr 2004 14:31:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGJq-00038g-Ld for simple@ietf.org; Thu, 29 Apr 2004 14:31:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGIv-0002rc-00 for simple@ietf.org; Thu, 29 Apr 2004 14:30:38 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJGIP-0002Zk-00 for simple@ietf.org; Thu, 29 Apr 2004 14:30:05 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3TISjh14326; Thu, 29 Apr 2004 13:28:45 -0500 Message-ID: <40914954.8050905@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Robert Sparks , Hisham Khartabil , Mikko Lonnfors , simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> In-Reply-To: <4091224D.3060303@cisco.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:28:36 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Robert Sparks wrote: > >> >>> I believe increasing the version for the duration of the subscription >>> would fix this. >> >> >> >> See my response to Paul's variation of this suggestion. >> If you do this, you open a new attack against this mechanism. > > > If someone is in a position to mount that kind of attack, how do any of > these approaches improve the attackee's experience? > > Apparently the attacker can inject arbitrary bogus notifications at any > time. If the recipient can "recover" when it receives a notification > with good data, then it will have no way of knowing when it has good > data and when it has bad data. How is that better than having the attack > crash the subscription altogether? At least then it will know it is > under attack. Part of this depends on how much effort the attacker must go to. If version numbers increase forever for the life of the subscription, then a _single_ spoofed notify with a very high version causes a train wreck. There is no way to recover, short of tearing down the subscription and starting over. If, on the other hand, we reset the version to zero on a subscription refresh, then when the watcher notices an out-of-sequence NOTIFY, it refreshes the subscription, and re-syncs. Of course, if this forces a full state notify, it is not much cheaper than a new subscription, so maybe it is not worth the trouble. In either case, an attacker that _continues_ to attack will pretty much make the subscription useless. > > The only real defense here is a secure session. > That would certainly help, although if you mean TLS lever security, then a compromised proxy could still attack. (And who else is in a better position to know enough dialog state to pull this off, anyway?) And I know the sort of welcome that suggesting that the notifier s/mime sign everything would get. > Paul > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 15:24:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22340 for ; Thu, 29 Apr 2004 15:24:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH9N-0004KC-3X for simple-archive@ietf.org; Thu, 29 Apr 2004 15:24:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH8O-0004E0-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 15:23:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH7m-00047q-00; Thu, 29 Apr 2004 15:23:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGlD-0005I6-P6; Thu, 29 Apr 2004 14:59:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGaW-00023T-Ky for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19307 for ; Thu, 29 Apr 2004 14:48:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGaQ-0000B9-IR for simple@ietf.org; Thu, 29 Apr 2004 14:48:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGZK-0007gX-00 for simple@ietf.org; Thu, 29 Apr 2004 14:47:35 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJGYy-0007Oe-00 for simple@ietf.org; Thu, 29 Apr 2004 14:47:12 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TIkdWB028077; Thu, 29 Apr 2004 11:46:42 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA78586; Thu, 29 Apr 2004 14:46:38 -0400 (EDT) Message-ID: <40914D8E.6070506@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> <1083260693.2167.58.camel@localhost.localdomain> <4091430A.8060505@cisco.com> <1083262837.2167.71.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 14:46:38 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > Aside from that I'd like for you to think through this again > from viewpoints besides active attack (use a transient malfunction > of the application (above the layer that would screw up basic SIP)), > I'm ready to let this go as long as we have _a_ solid solution to > dealing with reordered/missing notifies. I'm not going to start down the path to speculation about how to recover from arbitrary malfunctions of an application. That is just plain impossible without some characterization of the kinds of malfunctions that are to be recovered from. > So, backing out a layer, lets look at my original question of > whether or not we allow overlapping ->partial<- NOTIFYs at all > in this case. I don't see any compelling need to support overlapping partial notifies. It is very difficult to see how to make them work. I can imagine a case where there might be some motivation: I sent one notification and have had no response. But I already have a bunch of additional changes that you should know about. It might be advantageous to start sending them as soon as possible. But until you know the prior one has been handled it isn't safe to send the new one. > Why would you want to? What value would doing that bring? > > 3261 and even presence-10 left sending full-state presence > NOTIFYs open. We wouldn't be changing that. If an application > for some reason decided it needed to send a new full-state > notify while a partial-state notify was pending, it could. > So any of the arguments for allowing it from the 3261/presence-10 > are still satisfied. Can you see any use case where allowing > a server to send overlapping partial NOTIFYs is a good idea? > If not, disallowing it seems a powerful simplification. > I agree. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 15:28:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22764 for ; Thu, 29 Apr 2004 15:28:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH8O-0005ZA-Rk for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:23:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJNmfb021396 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:23:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGyQ-0007Xi-Vh for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:13:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21025 for ; Thu, 29 Apr 2004 15:13:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGyK-0003QO-EO for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:13:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGxR-0003Nb-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:12:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJGx1-0003Kh-00; Thu, 29 Apr 2004 15:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhE-0003n8-49; Thu, 29 Apr 2004 14:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFeK-0006Ka-N8 for simple@optimus.ietf.org; Thu, 29 Apr 2004 13:48:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16375 for ; Thu, 29 Apr 2004 13:48:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFeF-0006ZM-60 for simple@ietf.org; Thu, 29 Apr 2004 13:48:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFdF-0006Dd-00 for simple@ietf.org; Thu, 29 Apr 2004 13:47:33 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJFcH-0005aS-00 for simple@ietf.org; Thu, 29 Apr 2004 13:46:33 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3THib6r021203; Thu, 29 Apr 2004 12:44:38 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: Paul Kyzivat Cc: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org In-Reply-To: <4091224D.3060303@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> Content-Type: text/plain Message-Id: <1083260693.2167.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 12:44:53 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Of course a secure session is the correct defense. Understanding the differences in the behavior of the proposed changes without that security is still a useful tool for comparing them. Those differences may have ramifications in scenarios other than the attack/security scenario I'm using to point at them. The current draft (almost) has the property that a client can reset all the partial-oriented state by issuing a subscription refresh. It can get back to a clean start-state wrt the extensions being defined here. If you change to increasing versions across full notifications, a client has to tear down the subscription and resubscribe to get back to that clean start-state. I think we want to preserve (and refine) the property the current draft has. RjS On Thu, 2004-04-29 at 10:42, Paul Kyzivat wrote: > Robert Sparks wrote: > > > >>I believe increasing the version for the duration of the subscription > >>would fix this. > > > > > > See my response to Paul's variation of this suggestion. > > If you do this, you open a new attack against this mechanism. > > If someone is in a position to mount that kind of attack, how do any of > these approaches improve the attackee's experience? > > Apparently the attacker can inject arbitrary bogus notifications at any > time. If the recipient can "recover" when it receives a notification > with good data, then it will have no way of knowing when it has good > data and when it has bad data. How is that better than having the attack > crash the subscription altogether? At least then it will know it is > under attack. > > The only real defense here is a secure session. > > Paul > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 15:36:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23304 for ; Thu, 29 Apr 2004 15:36:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH9W-0005px-GC for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:24:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJOwIK022432 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH2I-00019E-5z for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21542 for ; Thu, 29 Apr 2004 15:17:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH2B-0003eF-O7 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:17:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH1G-0003aN-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:16:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH0g-0003Xw-00; Thu, 29 Apr 2004 15:15:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhH-0003oE-5Y; Thu, 29 Apr 2004 14:55:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFfk-0006tI-CI for simple@optimus.ietf.org; Thu, 29 Apr 2004 13:50:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16538 for ; Thu, 29 Apr 2004 13:50:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFfe-0006xi-PM for simple@ietf.org; Thu, 29 Apr 2004 13:50:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFeV-0006bm-00 for simple@ietf.org; Thu, 29 Apr 2004 13:48:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJFdo-0006EN-00 for simple@ietf.org; Thu, 29 Apr 2004 13:48:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Apr 2004 09:59:48 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3THlcW9022912; Thu, 29 Apr 2004 10:47:39 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AON42853; Thu, 29 Apr 2004 10:47:37 -0700 (PDT) From: David Oran To: Robert Sparks , Hisham Khartabil cc: Mikko Lonnfors , simple@ietf.org Subject: RE: [Simple] WGLC: partial notification Message-ID: <32153163E336A50578840380@[10.32.245.156]> In-Reply-To: <1083246185.2167.4.camel@localhost.localdomain> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> X-Mailer: Mulberry/3.1.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:47:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit from left field...could this be solved by using the CSEQ of the subscription refreshes as the high order part of the version number? --On Thursday, April 29, 2004 8:43 AM -0500 Robert Sparks wrote: > inline > On Thu, 2004-04-29 at 07:44, hisham.khartabil@nokia.com wrote: >> > -----Original Message----- >> > From: Lonnfors Mikko (Nokia-NRC/Helsinki) >> > Sent: 29.April.2004 15:40 >> > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks@dynamicsoft.com; >> > simple@ietf.org >> > Subject: RE: [Simple] WGLC: partial notification >> > >> > >> > >> > >> > >> > > > > Ok, so your proposal is that "version" should be scoped with >> > > > > the subscription i.e. first NOTIFY within a subscription >> > > > > would have version="0" and then it would be continuously >> > > > > increased by one for every notifications (regardless if it >> > > > > contains full or partial state)? >> > > > > >> > > > > How should subscription refreshes be handled? If we have >> > > > > PA sends N1(full), N2(full), N3(partial) >> > > > > And N2 is lost watcher would refresh the subscription when it >> > > > > receives N3. Now >> > > > > Would the PA send N1(full, version="0") or N4(full, >> > version="3")? >> > > > >> > > > version gets reset to 0 when a SUBSCRIBE refresh is received. >> > > >> > > Now that I think about this a little more, I think the >> > > version should forever increase for the whole duration of the >> > > subscription, including refreshes. Imagine this scenario: >> > > >> > > ----> SUBSCRIBE >> > > <---- 200 >> > > <---- NOTIFY1 (full, version 0) >> > > ----> 200 >> > > X-- NOTIFY2 (full, version 1) >> > > <---- NOTIFY3 (partial, version 3) >> > > ----> 200 >> > > ----> SUBSCRIBE >> > > <---- 200 >> > > <---- NOTIFY4 (full, version 0) >> > > ----> 200 >> > > <--x NOTIFY2 (full, version 1) Now NOTIFY2 arrives >> > > >> > > How does the subscribe know that the last NOTIFY (NOTIFY2) >> > > was sent after the subscribe refresh? If NOTIFY 4 had version >> > > 4 instead of 0, then it would. >> > > >> > > /Hisham >> > >> > If we don't allow new NOTIFY messages if there is a pending >> > NOTIFY is this still a problem? >> >> This would fix the problem, but I prefer not to disallow it since >> RFC3265 does not disallow it nor presence-07. >> >> I believe increasing the version for the duration of the subscription >> would fix this. > > See my response to Paul's variation of this suggestion. > If you do this, you open a new attack against this mechanism. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 15:42:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23720 for ; Thu, 29 Apr 2004 15:42:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHA5-0005vP-P2 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:25:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJPXvt022769 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH4I-0002V0-2o for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:19:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21852 for ; Thu, 29 Apr 2004 15:19:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH4B-0003oH-Io for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:19:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH3J-0003l3-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:18:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH2e-0003hL-00; Thu, 29 Apr 2004 15:17:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhx-00049V-9O; Thu, 29 Apr 2004 14:56:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFtb-0001s2-Oc for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:04:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17483 for ; Thu, 29 Apr 2004 14:04:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFtW-0003Rt-0e for simple@ietf.org; Thu, 29 Apr 2004 14:04:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFsX-00039j-00 for simple@ietf.org; Thu, 29 Apr 2004 14:03:22 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJFrV-0002c9-00 for simple@ietf.org; Thu, 29 Apr 2004 14:02:17 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TI1lW9003945; Thu, 29 Apr 2004 11:01:48 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA73693; Thu, 29 Apr 2004 14:01:46 -0400 (EDT) Message-ID: <4091430A.8060505@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> <1083260693.2167.58.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 14:01:46 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Sparks wrote: > Of course a secure session is the correct defense. > > Understanding the differences in the behavior of the proposed > changes without that security is still a useful tool for > comparing them. Those differences may have ramifications in > scenarios other than the attack/security scenario I'm using > to point at them. > > The current draft (almost) has the property that a client > can reset all the partial-oriented state by issuing a > subscription refresh. It can get back to a clean start-state > wrt the extensions being defined here. This only comes up if somebody malicious is (successfully) hacking into the session. The client can attempt to reset, but can be hacked again after that. There is no reason for the client to assume that any results it gets are valid once it has been hacked. Nor does it know that it has been hacked. From the client's pov this is at least as likely to be assumed to be a malfunction of the server. > If you change to increasing versions across full notifications, > a client has to tear down the subscription and resubscribe to > get back to that clean start-state. > > I think we want to preserve (and refine) the property the current > draft has. Even tearing down the subscription and establishing a new one isn't likely to be helpful if you have an active attacker. If the hacker got in once, he can probably get in again. But if that is hard to do, then establishing a new session may give slightly better results. This is probably when you call for help to find and block the hacker. You may just have to give up on the subscription until then. I don't find any *useful* differences in resilience of the various alternatives to this kind of attack. Paul > RjS > > > On Thu, 2004-04-29 at 10:42, Paul Kyzivat wrote: > >>Robert Sparks wrote: >> >>>>I believe increasing the version for the duration of the subscription >>>>would fix this. >>> >>> >>>See my response to Paul's variation of this suggestion. >>>If you do this, you open a new attack against this mechanism. >> >>If someone is in a position to mount that kind of attack, how do any of >>these approaches improve the attackee's experience? >> >>Apparently the attacker can inject arbitrary bogus notifications at any >>time. If the recipient can "recover" when it receives a notification >>with good data, then it will have no way of knowing when it has good >>data and when it has bad data. How is that better than having the attack >>crash the subscription altogether? At least then it will know it is >>under attack. >> >>The only real defense here is a secure session. >> >> Paul >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 15:42:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23849 for ; Thu, 29 Apr 2004 15:42:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHAm-0006AC-89 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:26:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJQGKa023687 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH6I-0004U0-BC for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:21:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22037 for ; Thu, 29 Apr 2004 15:21:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH6B-0003z3-VP for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:21:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH5S-0003uQ-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:20:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH4O-0003pl-00; Thu, 29 Apr 2004 15:19:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGkP-00054T-06; Thu, 29 Apr 2004 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJG6E-0004b8-Hc for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18084 for ; Thu, 29 Apr 2004 14:17:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJG68-00072o-Ks for simple@ietf.org; Thu, 29 Apr 2004 14:17:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJG5L-0006mh-00 for simple@ietf.org; Thu, 29 Apr 2004 14:16:35 -0400 Received: from web21502.mail.yahoo.com ([66.163.169.13]) by ietf-mx with smtp (Exim 4.12) id 1BJG4h-0006Vl-00 for simple@ietf.org; Thu, 29 Apr 2004 14:15:55 -0400 Message-ID: <20040429181557.26996.qmail@web21502.mail.yahoo.com> Received: from [192.75.88.231] by web21502.mail.yahoo.com via HTTP; Thu, 29 Apr 2004 11:15:57 PDT From: Rajesh Karunamurthy To: simple@ietf.org Cc: hisham.khartabil@nokia.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-490555774-1083262557=:26673" Subject: [Simple] Problem with XML Schema for Filter Criteria Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 11:15:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE autolearn=no version=2.60 --0-490555774-1083262557=:26673 Content-Type: text/plain; charset=us-ascii Hi, I am working on filtering of the Presence Document and I found that there is a small problem in the XML schema used for filtering. I used a standard XSD schema validator, http://apps.gotdotnet.com/xmltools/xsdvalidator/ and I got this error Error :The content model must be deterministic. Wildcard declaration along with a local element declaration causes the content model to become ambiguous. An error occurred at , (70, 6). Can any one help me out? Thanks. Rajesh --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs --0-490555774-1083262557=:26673 Content-Type: text/html; charset=us-ascii
Hi,
 
I am working on  filtering of the Presence Document and I found that there is a small problem in the XML schema used for filtering. I used a standard XSD schema validator,
 
Error :The content model must be deterministic. Wildcard declaration along with a local element declaration causes the content model to become ambiguous. An error occurred at , (70, 6).
 
Can any one help me out?
 
Thanks.
Rajesh
 
 
 

Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs --0-490555774-1083262557=:26673-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 15:43:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23866 for ; Thu, 29 Apr 2004 15:43:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHBD-0006Fg-Am for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:26:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJQhk6024027 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH7A-0004qJ-Hs for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:22:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22101 for ; Thu, 29 Apr 2004 15:22:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH74-00043i-4A for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:22:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH63-0003xh-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:21:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH5H-0003si-00; Thu, 29 Apr 2004 15:20:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGkQ-000554-PR; Thu, 29 Apr 2004 14:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGE8-00067y-Be for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:25:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18380 for ; Thu, 29 Apr 2004 14:25:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGE2-0001Sd-IX for simple@ietf.org; Thu, 29 Apr 2004 14:25:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGD3-0001BE-00 for simple@ietf.org; Thu, 29 Apr 2004 14:24:33 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJGC3-0000dE-00 for simple@ietf.org; Thu, 29 Apr 2004 14:23:31 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3TIKL6r021235; Thu, 29 Apr 2004 13:20:21 -0500 Subject: Re: [Simple] WGLC: partial notification From: Robert Sparks To: Paul Kyzivat Cc: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org In-Reply-To: <4091430A.8060505@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> <1083260693.2167.58.camel@localhost.localdomain> <4091430A.8060505@cisco.com> Content-Type: text/plain Message-Id: <1083262837.2167.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:20:37 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aside from that I'd like for you to think through this again from viewpoints besides active attack (use a transient malfunction of the application (above the layer that would screw up basic SIP)), I'm ready to let this go as long as we have _a_ solid solution to dealing with reordered/missing notifies. So, backing out a layer, lets look at my original question of whether or not we allow overlapping ->partial<- NOTIFYs at all in this case. Why would you want to? What value would doing that bring? 3261 and even presence-10 left sending full-state presence NOTIFYs open. We wouldn't be changing that. If an application for some reason decided it needed to send a new full-state notify while a partial-state notify was pending, it could. So any of the arguments for allowing it from the 3261/presence-10 are still satisfied. Can you see any use case where allowing a server to send overlapping partial NOTIFYs is a good idea? If not, disallowing it seems a powerful simplification. RjS On Thu, 2004-04-29 at 13:01, Paul Kyzivat wrote: > Robert Sparks wrote: > > Of course a secure session is the correct defense. > > > > Understanding the differences in the behavior of the proposed > > changes without that security is still a useful tool for > > comparing them. Those differences may have ramifications in > > scenarios other than the attack/security scenario I'm using > > to point at them. > > > > The current draft (almost) has the property that a client > > can reset all the partial-oriented state by issuing a > > subscription refresh. It can get back to a clean start-state > > wrt the extensions being defined here. > > This only comes up if somebody malicious is (successfully) hacking into > the session. The client can attempt to reset, but can be hacked again > after that. There is no reason for the client to assume that any results > it gets are valid once it has been hacked. Nor does it know that it has > been hacked. From the client's pov this is at least as likely to be > assumed to be a malfunction of the server. > > > If you change to increasing versions across full notifications, > > a client has to tear down the subscription and resubscribe to > > get back to that clean start-state. > > > > I think we want to preserve (and refine) the property the current > > draft has. > > Even tearing down the subscription and establishing a new one isn't > likely to be helpful if you have an active attacker. If the hacker got > in once, he can probably get in again. But if that is hard to do, then > establishing a new session may give slightly better results. > > This is probably when you call for help to find and block the hacker. > You may just have to give up on the subscription until then. > > I don't find any *useful* differences in resilience of the various > alternatives to this kind of attack. > > Paul > > > RjS > > > > > > On Thu, 2004-04-29 at 10:42, Paul Kyzivat wrote: > > > >>Robert Sparks wrote: > >> > >>>>I believe increasing the version for the duration of the subscription > >>>>would fix this. > >>> > >>> > >>>See my response to Paul's variation of this suggestion. > >>>If you do this, you open a new attack against this mechanism. > >> > >>If someone is in a position to mount that kind of attack, how do any of > >>these approaches improve the attackee's experience? > >> > >>Apparently the attacker can inject arbitrary bogus notifications at any > >>time. If the recipient can "recover" when it receives a notification > >>with good data, then it will have no way of knowing when it has good > >>data and when it has bad data. How is that better than having the attack > >>crash the subscription altogether? At least then it will know it is > >>under attack. > >> > >>The only real defense here is a secure session. > >> > >> Paul > >> > >> Paul > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 15:43:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23900 for ; Thu, 29 Apr 2004 15:43:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHBz-0006VE-0Q for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:27:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJRUXr024991 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:27:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH89-0005Mq-P4 for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:23:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22201 for ; Thu, 29 Apr 2004 15:23:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH83-0004Al-Fl for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:23:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH76-000444-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:22:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH6A-0003yp-00; Thu, 29 Apr 2004 15:21:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGkp-00057Y-GA; Thu, 29 Apr 2004 14:59:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGJw-0007Pr-J6 for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:31:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18618 for ; Thu, 29 Apr 2004 14:31:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGJq-00038g-Ld for simple@ietf.org; Thu, 29 Apr 2004 14:31:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGIv-0002rc-00 for simple@ietf.org; Thu, 29 Apr 2004 14:30:38 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJGIP-0002Zk-00 for simple@ietf.org; Thu, 29 Apr 2004 14:30:05 -0400 Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i3TISjh14326; Thu, 29 Apr 2004 13:28:45 -0500 Message-ID: <40914954.8050905@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Robert Sparks , Hisham Khartabil , Mikko Lonnfors , simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> In-Reply-To: <4091224D.3060303@cisco.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:28:36 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Robert Sparks wrote: > >> >>> I believe increasing the version for the duration of the subscription >>> would fix this. >> >> >> >> See my response to Paul's variation of this suggestion. >> If you do this, you open a new attack against this mechanism. > > > If someone is in a position to mount that kind of attack, how do any of > these approaches improve the attackee's experience? > > Apparently the attacker can inject arbitrary bogus notifications at any > time. If the recipient can "recover" when it receives a notification > with good data, then it will have no way of knowing when it has good > data and when it has bad data. How is that better than having the attack > crash the subscription altogether? At least then it will know it is > under attack. Part of this depends on how much effort the attacker must go to. If version numbers increase forever for the life of the subscription, then a _single_ spoofed notify with a very high version causes a train wreck. There is no way to recover, short of tearing down the subscription and starting over. If, on the other hand, we reset the version to zero on a subscription refresh, then when the watcher notices an out-of-sequence NOTIFY, it refreshes the subscription, and re-syncs. Of course, if this forces a full state notify, it is not much cheaper than a new subscription, so maybe it is not worth the trouble. In either case, an attacker that _continues_ to attack will pretty much make the subscription useless. > > The only real defense here is a secure session. > That would certainly help, although if you mean TLS lever security, then a compromised proxy could still attack. (And who else is in a better position to know enough dialog state to pull this off, anyway?) And I know the sort of welcome that suggesting that the notifier s/mime sign everything would get. > Paul > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 15:52:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24501 for ; Thu, 29 Apr 2004 15:52:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHKE-00087b-EF for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJa2Lc031215 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 15:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH9U-0005ou-2W for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:24:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22357 for ; Thu, 29 Apr 2004 15:24:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH9N-0004KK-Mf for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:24:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH8P-0004E7-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 15:23:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJH7m-00047q-00; Thu, 29 Apr 2004 15:23:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGlD-0005I6-P6; Thu, 29 Apr 2004 14:59:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGaW-00023T-Ky for simple@optimus.ietf.org; Thu, 29 Apr 2004 14:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19307 for ; Thu, 29 Apr 2004 14:48:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGaQ-0000B9-IR for simple@ietf.org; Thu, 29 Apr 2004 14:48:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGZK-0007gX-00 for simple@ietf.org; Thu, 29 Apr 2004 14:47:35 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJGYy-0007Oe-00 for simple@ietf.org; Thu, 29 Apr 2004 14:47:12 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TIkdWB028077; Thu, 29 Apr 2004 11:46:42 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA78586; Thu, 29 Apr 2004 14:46:38 -0400 (EDT) Message-ID: <40914D8E.6070506@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , Mikko Lonnfors , simple@ietf.org Subject: Re: [Simple] WGLC: partial notification References: <2038BCC78B1AD641891A0D1AE133DBB7017979E6@esebe019.ntc.nokia.com> <1083246185.2167.4.camel@localhost.localdomain> <4091224D.3060303@cisco.com> <1083260693.2167.58.camel@localhost.localdomain> <4091430A.8060505@cisco.com> <1083262837.2167.71.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 14:46:38 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Sparks wrote: > Aside from that I'd like for you to think through this again > from viewpoints besides active attack (use a transient malfunction > of the application (above the layer that would screw up basic SIP)), > I'm ready to let this go as long as we have _a_ solid solution to > dealing with reordered/missing notifies. I'm not going to start down the path to speculation about how to recover from arbitrary malfunctions of an application. That is just plain impossible without some characterization of the kinds of malfunctions that are to be recovered from. > So, backing out a layer, lets look at my original question of > whether or not we allow overlapping ->partial<- NOTIFYs at all > in this case. I don't see any compelling need to support overlapping partial notifies. It is very difficult to see how to make them work. I can imagine a case where there might be some motivation: I sent one notification and have had no response. But I already have a bunch of additional changes that you should know about. It might be advantageous to start sending them as soon as possible. But until you know the prior one has been handled it isn't safe to send the new one. > Why would you want to? What value would doing that bring? > > 3261 and even presence-10 left sending full-state presence > NOTIFYs open. We wouldn't be changing that. If an application > for some reason decided it needed to send a new full-state > notify while a partial-state notify was pending, it could. > So any of the arguments for allowing it from the 3261/presence-10 > are still satisfied. Can you see any use case where allowing > a server to send overlapping partial NOTIFYs is a good idea? > If not, disallowing it seems a powerful simplification. > I agree. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 19:18:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10131 for ; Thu, 29 Apr 2004 19:18:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKnm-0007Te-UZ for simple-archive@ietf.org; Thu, 29 Apr 2004 19:18:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKmq-0007Ok-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 19:17:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKm6-0007JU-00; Thu, 29 Apr 2004 19:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKeN-0005yZ-06; Thu, 29 Apr 2004 19:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKSI-0003ke-VV for simple@optimus.ietf.org; Thu, 29 Apr 2004 18:56:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08977 for ; Thu, 29 Apr 2004 18:56:28 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKSA-0005iN-HB for simple@ietf.org; Thu, 29 Apr 2004 18:56:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKRH-0005fb-00 for simple@ietf.org; Thu, 29 Apr 2004 18:55:32 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BJKQZ-0005cr-00 for simple@ietf.org; Thu, 29 Apr 2004 18:54:48 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TMseG14394; Fri, 30 Apr 2004 01:54:40 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 01:54:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3TMsZXj021516; Fri, 30 Apr 2004 01:54:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00eX6PEv; Fri, 30 Apr 2004 01:54:34 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TMsYH12299; Fri, 30 Apr 2004 01:54:34 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 01:54:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft Message-ID: Thread-Topic: [Simple] RE: Updating the XCAP PIDF manipulation draft Thread-Index: AcQtGuvvCBTmqFMFT8OvjN6aaZL/5QBIXiyQ To: , Cc: , X-OriginalArrivalTime: 29 Apr 2004 22:54:34.0039 (UTC) FILETIME=[F075E470:01C42E3C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 01:54:32 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi George, OK, I'll add short text that says that the information coming from the = different sources can be "non-orthogonal (and in some ways even = conflicting)" and I'll add as an example one compositor policy, whereby = the XCAP manipulated presence state is the default state used in absence = of any soft state inputs based on SIP PUBLISH, and that the soft state = inputs then augment or override the default state. I've also rewritten the security considerations section, updated the = references and fixed some typos. Otherwise there won't be any changes = compared to the previous version. Markus > -----Original Message----- > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > Sent: 28 April, 2004 15:13 > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); jdrosen@dynamicsoft.com > Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft >=20 >=20 > Comments in line Markus/gf >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > > Markus.Isomaki@nokia.com > > Sent: Wednesday, April 28, 2004 4:55 AM > > To: George Foti (QA/EMC); simple@ietf.org > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com > > Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft > >=20 > >=20 > > Hi George, > >=20 > > Thanks for the comments. See inline: > >=20 > > > -----Original Message----- > > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > > Sent: 23 April, 2004 18:09 > > > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > > > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere);=20 > jdrosen@dynamicsoft.com > > > Subject: RE: Updating the XCAP PIDF manipulation draft > > >=20 > > >=20 > > > Hi Markus, > > >=20 > > > Here are my comments: > > >=20 > > > Second paragraph: > > >=20 > > > Replace: "but only single XCAP manipulated presence document", by > > > "but only single XCAP publishing source" > > >=20 > >=20 > > I think this is strictly a terminology issue, and with=20 > > respect to this spec, people have preferred to use "XCAP=20 > > manipulated presence document" instead of "XCAP publishing"=20 > > to avoid even further confusion with SIP PUBLISH.=20 > >=20 >=20 > What is the confusion created here. > The XCAP manipulated presence document will have to be=20 > published to the composer. > I am merely reflecting that. > If you are not happy with the wording, can you add your own=20 > words to *explicitly* reflect in the text the publishing=20 > aspects from the XCAP source for the XCAP manipulated=20 > presence document. >=20 > > > Third paragraph: replace the following section=20 > > > "As individual inputs ................one mechanism with=20 > the other" > > >=20 > > > by the following: > > >=20 > > > "Although presence states set by XCAP, on behalf of XCAP=20 > > > clients, and SIP PUBLISH, on behalf of PUAs, are completely=20 > > > separated, conflicting information may occur within the=20 > > > composer for a presence state" > > >=20 > >=20 > > The definition of "conflicting" information is quite vague=20 > > and can be different depending on what the actual composition=20 > > scheme is. So I believe the current text already captures the=20 > > main idea, that there can be multiple inputs, and the ESC=20 > > needs to be able to deal with that. This is pretty much what=20 > > SIP PUBLISH spec says too. >=20 > I find the statement "ESC needs to be able to deal with that"=20 > even more vague in a spec. > I was merely trying to give some examples on the potential=20 > things the ESC must deal with, rather than leaving it as is. >=20 > If you are not happy with my wording, can you expand the text=20 > to give some examples of what the ESC have to deal with,=20 > given the multiple source of publishing information using SIP=20 > publisg or XCAP. >=20 > I beleive this needs some more description/clarification. >=20 > >=20 > > (Note that the support for XCAP based presence state setting=20 > > is obviously completely optional in presence systems. In some=20 > > cases it could be useful, in some others it may not be needed=20 > > at all. Some use cases are presented in the introdution=20 > > chapter, but they are just informational. So if someone=20 > > thinks that XCAP based manipulation causes more problems than=20 > > what the benefits are in his particular presence system, it=20 > > can be left out. The spec just gives an opportunity to use it=20 > > for those vendors/presence providers who have good ideas how=20 > > to use it and see that SIP PUBLISH does not solve the needs=20 > properly.) > >=20 > > Markus=20 > >=20 > > > Rgds/gf=20 > > >=20 > > > > -----Original Message----- > > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > > Sent: Friday, April 23, 2004 10:07 AM > > > > To: simple@ietf.org > > > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com;=20 > > > George Foti > > > > (QA/EMC) > > > > Subject: Updating the XCAP PIDF manipulation draft > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > Me and Eva are working on an update to the XCAP PIDF=20 > > > > manipulation usage. Based on the earlier version there was=20 > > > > some confusion on the relationship of the presence state set=20 > > > > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with=20 > > > > the text below. I would like to get some feedback whether you=20 > > > > think it is clear enough. At least George and Jonathan have=20 > > > > commented the previous version, so I would especially like=20 > > > > your comments. > > > >=20 > > > > Chapter 1 contains the motivation, I think no changes are=20 > > > > needed for that. This is for Chapter 3 (the figure is=20 > unmodified): > > > >=20 > > > > --- > > > >=20 > > > > The framework for publishing presence state is introduced in=20 > > > > . A central part of the=20 > > > > framework is the event state compositor element whose=20 > > > > function is to compose presence information received from=20 > > > > serveral sources into a single coherent presence document. > > > >=20 > > > > The presence state manipulated with XCAP can be seen as one=20 > > > > of the information sources for the compositor to be combined=20 > > > > with the soft state information published using SIP PUBLISH.=20 > > > > This is illustrated in Figure 1. It is expected that in the=20 > > > > normal case there can be several PUAs publishing their=20 > > > > separate views with SIP PUBLISH, but only single XCAP=20 > > > > manipulated presence document. As shown in the figure, there > > > > can be multiple XCAP clients (for instance in different=20 > > > > physical devices) manipulating the same document on the XCAP=20 > > > > server, but this still creates only one input to the event=20 > > > > state compositor. > > > >=20 > > > > As individual inputs the presence states set by XCAP and SIP=20 > > > > PUBLISH are completely separated and it is not possible to=20 > > > > directly manipulate the state set by one mechanism with the=20 > > > > other. How the compositor treats XCAP based inputs with=20 > > > > respect to SIP PUBLISH based inputs is a matter of compositor=20 > > > > policy, which is beyond the scope of this specification.=20 > > > > Since the SIP PUBLISH specification already mandates the=20 > > > > compositor to be able to deal with multiple inputs, this XCAP=20 > > > > usage does not impose any new requirements on the compositor=20 > > > > functionality. =20 > > > >=20 > > > > --- > > > >=20 > > > > Regards, > > > > Markus > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Apr 29 19:24:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10486 for ; Thu, 29 Apr 2004 19:24:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKtG-00008o-C3 for simple-archive@ietf.org; Thu, 29 Apr 2004 19:24:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKsH-00005A-00 for simple-archive@ietf.org; Thu, 29 Apr 2004 19:23:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKrY-000027-00; Thu, 29 Apr 2004 19:22:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKfJ-00068G-VQ; Thu, 29 Apr 2004 19:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKb1-00051a-T2 for simple@optimus.ietf.org; Thu, 29 Apr 2004 19:05:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09415 for ; Thu, 29 Apr 2004 19:05:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKat-0006MM-FJ for simple@ietf.org; Thu, 29 Apr 2004 19:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKZx-0006Ji-00 for simple@ietf.org; Thu, 29 Apr 2004 19:04:30 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJKZ0-0006E6-00 for simple@ietf.org; Thu, 29 Apr 2004 19:03:30 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i3TN2qLc028882; Thu, 29 Apr 2004 18:02:52 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Apr 2004 18:02:47 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9768@lmc37.lmc.ericsson.se> From: "George Foti (QA/EMC)" To: "'Markus.Isomaki@nokia.com'" , simple@ietf.org Cc: eva-maria.leppanen@nokia.com, jdrosen@dynamicsoft.com Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 18:01:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Thanks Markus. That should be fine. Rgds/gf > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Thursday, April 29, 2004 6:55 PM > To: George Foti (QA/EMC); simple@ietf.org > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com > Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft > > > Hi George, > > OK, I'll add short text that says that the information coming > from the different sources can be "non-orthogonal (and in > some ways even conflicting)" and I'll add as an example one > compositor policy, whereby the XCAP manipulated presence > state is the default state used in absence of any soft state > inputs based on SIP PUBLISH, and that the soft state inputs > then augment or override the default state. > > I've also rewritten the security considerations section, > updated the references and fixed some typos. Otherwise there > won't be any changes compared to the previous version. > > Markus > > > -----Original Message----- > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > Sent: 28 April, 2004 15:13 > > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); jdrosen@dynamicsoft.com > > Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft > > > > > > Comments in line Markus/gf > > > > > -----Original Message----- > > > From: simple-admin@ietf.org > > [mailto:simple-admin@ietf.org]On Behalf Of > > > Markus.Isomaki@nokia.com > > > Sent: Wednesday, April 28, 2004 4:55 AM > > > To: George Foti (QA/EMC); simple@ietf.org > > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com > > > Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft > > > > > > > > > Hi George, > > > > > > Thanks for the comments. See inline: > > > > > > > -----Original Message----- > > > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > > > Sent: 23 April, 2004 18:09 > > > > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > > > > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); > > jdrosen@dynamicsoft.com > > > > Subject: RE: Updating the XCAP PIDF manipulation draft > > > > > > > > > > > > Hi Markus, > > > > > > > > Here are my comments: > > > > > > > > Second paragraph: > > > > > > > > Replace: "but only single XCAP manipulated presence > document", by > > > > "but only single XCAP publishing source" > > > > > > > > > > I think this is strictly a terminology issue, and with > > > respect to this spec, people have preferred to use "XCAP > > > manipulated presence document" instead of "XCAP publishing" > > > to avoid even further confusion with SIP PUBLISH. > > > > > > > What is the confusion created here. > > The XCAP manipulated presence document will have to be > > published to the composer. > > I am merely reflecting that. > > If you are not happy with the wording, can you add your own > > words to *explicitly* reflect in the text the publishing > > aspects from the XCAP source for the XCAP manipulated > > presence document. > > > > > > Third paragraph: replace the following section > > > > "As individual inputs ................one mechanism with > > the other" > > > > > > > > by the following: > > > > > > > > "Although presence states set by XCAP, on behalf of XCAP > > > > clients, and SIP PUBLISH, on behalf of PUAs, are completely > > > > separated, conflicting information may occur within the > > > > composer for a presence state" > > > > > > > > > > The definition of "conflicting" information is quite vague > > > and can be different depending on what the actual composition > > > scheme is. So I believe the current text already captures the > > > main idea, that there can be multiple inputs, and the ESC > > > needs to be able to deal with that. This is pretty much what > > > SIP PUBLISH spec says too. > > > > I find the statement "ESC needs to be able to deal with that" > > even more vague in a spec. > > I was merely trying to give some examples on the potential > > things the ESC must deal with, rather than leaving it as is. > > > > If you are not happy with my wording, can you expand the text > > to give some examples of what the ESC have to deal with, > > given the multiple source of publishing information using SIP > > publisg or XCAP. > > > > I beleive this needs some more description/clarification. > > > > > > > > (Note that the support for XCAP based presence state setting > > > is obviously completely optional in presence systems. In some > > > cases it could be useful, in some others it may not be needed > > > at all. Some use cases are presented in the introdution > > > chapter, but they are just informational. So if someone > > > thinks that XCAP based manipulation causes more problems than > > > what the benefits are in his particular presence system, it > > > can be left out. The spec just gives an opportunity to use it > > > for those vendors/presence providers who have good ideas how > > > to use it and see that SIP PUBLISH does not solve the needs > > properly.) > > > > > > Markus > > > > > > > Rgds/gf > > > > > > > > > -----Original Message----- > > > > > From: Markus.Isomaki@nokia.com > [mailto:Markus.Isomaki@nokia.com] > > > > > Sent: Friday, April 23, 2004 10:07 AM > > > > > To: simple@ietf.org > > > > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com; > > > > George Foti > > > > > (QA/EMC) > > > > > Subject: Updating the XCAP PIDF manipulation draft > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Me and Eva are working on an update to the XCAP PIDF > > > > > manipulation usage. Based on the earlier version there was > > > > > some confusion on the relationship of the presence state set > > > > > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with > > > > > the text below. I would like to get some feedback whether you > > > > > think it is clear enough. At least George and Jonathan have > > > > > commented the previous version, so I would especially like > > > > > your comments. > > > > > > > > > > Chapter 1 contains the motivation, I think no changes are > > > > > needed for that. This is for Chapter 3 (the figure is > > unmodified): > > > > > > > > > > --- > > > > > > > > > > The framework for publishing presence state is introduced in > > > > > . A central part of the > > > > > framework is the event state compositor element whose > > > > > function is to compose presence information received from > > > > > serveral sources into a single coherent presence document. > > > > > > > > > > The presence state manipulated with XCAP can be seen as one > > > > > of the information sources for the compositor to be combined > > > > > with the soft state information published using SIP PUBLISH. > > > > > This is illustrated in Figure 1. It is expected that in the > > > > > normal case there can be several PUAs publishing their > > > > > separate views with SIP PUBLISH, but only single XCAP > > > > > manipulated presence document. As shown in the figure, there > > > > > can be multiple XCAP clients (for instance in different > > > > > physical devices) manipulating the same document on the XCAP > > > > > server, but this still creates only one input to the event > > > > > state compositor. > > > > > > > > > > As individual inputs the presence states set by XCAP and SIP > > > > > PUBLISH are completely separated and it is not possible to > > > > > directly manipulate the state set by one mechanism with the > > > > > other. How the compositor treats XCAP based inputs with > > > > > respect to SIP PUBLISH based inputs is a matter of compositor > > > > > policy, which is beyond the scope of this specification. > > > > > Since the SIP PUBLISH specification already mandates the > > > > > compositor to be able to deal with multiple inputs, this XCAP > > > > > usage does not impose any new requirements on the compositor > > > > > functionality. > > > > > > > > > > --- > > > > > > > > > > Regards, > > > > > Markus > > > > > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 19:34:53 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10868 for ; Thu, 29 Apr 2004 19:34:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKvU-0000iw-T5 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 19:26:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TNQiNJ002782 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 19:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKns-0007HV-HZ for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 19:18:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10149 for ; Thu, 29 Apr 2004 19:18:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKnn-0007To-Ml for simple-web-archive@ietf.org; Thu, 29 Apr 2004 19:18:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKmr-0007Or-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 19:17:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKm6-0007JU-00; Thu, 29 Apr 2004 19:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKeN-0005yZ-06; Thu, 29 Apr 2004 19:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKSI-0003ke-VV for simple@optimus.ietf.org; Thu, 29 Apr 2004 18:56:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08977 for ; Thu, 29 Apr 2004 18:56:28 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKSA-0005iN-HB for simple@ietf.org; Thu, 29 Apr 2004 18:56:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKRH-0005fb-00 for simple@ietf.org; Thu, 29 Apr 2004 18:55:32 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BJKQZ-0005cr-00 for simple@ietf.org; Thu, 29 Apr 2004 18:54:48 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TMseG14394; Fri, 30 Apr 2004 01:54:40 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 01:54:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3TMsZXj021516; Fri, 30 Apr 2004 01:54:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00eX6PEv; Fri, 30 Apr 2004 01:54:34 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TMsYH12299; Fri, 30 Apr 2004 01:54:34 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 01:54:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft Message-ID: Thread-Topic: [Simple] RE: Updating the XCAP PIDF manipulation draft Thread-Index: AcQtGuvvCBTmqFMFT8OvjN6aaZL/5QBIXiyQ To: , Cc: , X-OriginalArrivalTime: 29 Apr 2004 22:54:34.0039 (UTC) FILETIME=[F075E470:01C42E3C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 01:54:32 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi George, OK, I'll add short text that says that the information coming from the = different sources can be "non-orthogonal (and in some ways even = conflicting)" and I'll add as an example one compositor policy, whereby = the XCAP manipulated presence state is the default state used in absence = of any soft state inputs based on SIP PUBLISH, and that the soft state = inputs then augment or override the default state. I've also rewritten the security considerations section, updated the = references and fixed some typos. Otherwise there won't be any changes = compared to the previous version. Markus > -----Original Message----- > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > Sent: 28 April, 2004 15:13 > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); jdrosen@dynamicsoft.com > Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft >=20 >=20 > Comments in line Markus/gf >=20 > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > > Markus.Isomaki@nokia.com > > Sent: Wednesday, April 28, 2004 4:55 AM > > To: George Foti (QA/EMC); simple@ietf.org > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com > > Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft > >=20 > >=20 > > Hi George, > >=20 > > Thanks for the comments. See inline: > >=20 > > > -----Original Message----- > > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > > Sent: 23 April, 2004 18:09 > > > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > > > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere);=20 > jdrosen@dynamicsoft.com > > > Subject: RE: Updating the XCAP PIDF manipulation draft > > >=20 > > >=20 > > > Hi Markus, > > >=20 > > > Here are my comments: > > >=20 > > > Second paragraph: > > >=20 > > > Replace: "but only single XCAP manipulated presence document", by > > > "but only single XCAP publishing source" > > >=20 > >=20 > > I think this is strictly a terminology issue, and with=20 > > respect to this spec, people have preferred to use "XCAP=20 > > manipulated presence document" instead of "XCAP publishing"=20 > > to avoid even further confusion with SIP PUBLISH.=20 > >=20 >=20 > What is the confusion created here. > The XCAP manipulated presence document will have to be=20 > published to the composer. > I am merely reflecting that. > If you are not happy with the wording, can you add your own=20 > words to *explicitly* reflect in the text the publishing=20 > aspects from the XCAP source for the XCAP manipulated=20 > presence document. >=20 > > > Third paragraph: replace the following section=20 > > > "As individual inputs ................one mechanism with=20 > the other" > > >=20 > > > by the following: > > >=20 > > > "Although presence states set by XCAP, on behalf of XCAP=20 > > > clients, and SIP PUBLISH, on behalf of PUAs, are completely=20 > > > separated, conflicting information may occur within the=20 > > > composer for a presence state" > > >=20 > >=20 > > The definition of "conflicting" information is quite vague=20 > > and can be different depending on what the actual composition=20 > > scheme is. So I believe the current text already captures the=20 > > main idea, that there can be multiple inputs, and the ESC=20 > > needs to be able to deal with that. This is pretty much what=20 > > SIP PUBLISH spec says too. >=20 > I find the statement "ESC needs to be able to deal with that"=20 > even more vague in a spec. > I was merely trying to give some examples on the potential=20 > things the ESC must deal with, rather than leaving it as is. >=20 > If you are not happy with my wording, can you expand the text=20 > to give some examples of what the ESC have to deal with,=20 > given the multiple source of publishing information using SIP=20 > publisg or XCAP. >=20 > I beleive this needs some more description/clarification. >=20 > >=20 > > (Note that the support for XCAP based presence state setting=20 > > is obviously completely optional in presence systems. In some=20 > > cases it could be useful, in some others it may not be needed=20 > > at all. Some use cases are presented in the introdution=20 > > chapter, but they are just informational. So if someone=20 > > thinks that XCAP based manipulation causes more problems than=20 > > what the benefits are in his particular presence system, it=20 > > can be left out. The spec just gives an opportunity to use it=20 > > for those vendors/presence providers who have good ideas how=20 > > to use it and see that SIP PUBLISH does not solve the needs=20 > properly.) > >=20 > > Markus=20 > >=20 > > > Rgds/gf=20 > > >=20 > > > > -----Original Message----- > > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > > Sent: Friday, April 23, 2004 10:07 AM > > > > To: simple@ietf.org > > > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com;=20 > > > George Foti > > > > (QA/EMC) > > > > Subject: Updating the XCAP PIDF manipulation draft > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > Me and Eva are working on an update to the XCAP PIDF=20 > > > > manipulation usage. Based on the earlier version there was=20 > > > > some confusion on the relationship of the presence state set=20 > > > > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with=20 > > > > the text below. I would like to get some feedback whether you=20 > > > > think it is clear enough. At least George and Jonathan have=20 > > > > commented the previous version, so I would especially like=20 > > > > your comments. > > > >=20 > > > > Chapter 1 contains the motivation, I think no changes are=20 > > > > needed for that. This is for Chapter 3 (the figure is=20 > unmodified): > > > >=20 > > > > --- > > > >=20 > > > > The framework for publishing presence state is introduced in=20 > > > > . A central part of the=20 > > > > framework is the event state compositor element whose=20 > > > > function is to compose presence information received from=20 > > > > serveral sources into a single coherent presence document. > > > >=20 > > > > The presence state manipulated with XCAP can be seen as one=20 > > > > of the information sources for the compositor to be combined=20 > > > > with the soft state information published using SIP PUBLISH.=20 > > > > This is illustrated in Figure 1. It is expected that in the=20 > > > > normal case there can be several PUAs publishing their=20 > > > > separate views with SIP PUBLISH, but only single XCAP=20 > > > > manipulated presence document. As shown in the figure, there > > > > can be multiple XCAP clients (for instance in different=20 > > > > physical devices) manipulating the same document on the XCAP=20 > > > > server, but this still creates only one input to the event=20 > > > > state compositor. > > > >=20 > > > > As individual inputs the presence states set by XCAP and SIP=20 > > > > PUBLISH are completely separated and it is not possible to=20 > > > > directly manipulate the state set by one mechanism with the=20 > > > > other. How the compositor treats XCAP based inputs with=20 > > > > respect to SIP PUBLISH based inputs is a matter of compositor=20 > > > > policy, which is beyond the scope of this specification.=20 > > > > Since the SIP PUBLISH specification already mandates the=20 > > > > compositor to be able to deal with multiple inputs, this XCAP=20 > > > > usage does not impose any new requirements on the compositor=20 > > > > functionality. =20 > > > >=20 > > > > --- > > > >=20 > > > > Regards, > > > > Markus > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Apr 29 19:40:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11203 for ; Thu, 29 Apr 2004 19:40:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJL2c-0001Yw-Oo for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 19:34:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TNY6K7006001 for simple-archive@odin.ietf.org; Thu, 29 Apr 2004 19:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKtO-00005a-3U for simple-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 19:24:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10504 for ; Thu, 29 Apr 2004 19:24:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKtJ-00009B-76 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 19:24:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKsI-00005J-00 for simple-web-archive@ietf.org; Thu, 29 Apr 2004 19:23:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKrY-000027-00; Thu, 29 Apr 2004 19:22:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKfJ-00068G-VQ; Thu, 29 Apr 2004 19:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKb1-00051a-T2 for simple@optimus.ietf.org; Thu, 29 Apr 2004 19:05:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09415 for ; Thu, 29 Apr 2004 19:05:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKat-0006MM-FJ for simple@ietf.org; Thu, 29 Apr 2004 19:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKZx-0006Ji-00 for simple@ietf.org; Thu, 29 Apr 2004 19:04:30 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJKZ0-0006E6-00 for simple@ietf.org; Thu, 29 Apr 2004 19:03:30 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i3TN2qLc028882; Thu, 29 Apr 2004 18:02:52 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Apr 2004 18:02:47 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9768@lmc37.lmc.ericsson.se> From: "George Foti (QA/EMC)" To: "'Markus.Isomaki@nokia.com'" , simple@ietf.org Cc: eva-maria.leppanen@nokia.com, jdrosen@dynamicsoft.com Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 18:01:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Thanks Markus. That should be fine. Rgds/gf > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Thursday, April 29, 2004 6:55 PM > To: George Foti (QA/EMC); simple@ietf.org > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com > Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft > > > Hi George, > > OK, I'll add short text that says that the information coming > from the different sources can be "non-orthogonal (and in > some ways even conflicting)" and I'll add as an example one > compositor policy, whereby the XCAP manipulated presence > state is the default state used in absence of any soft state > inputs based on SIP PUBLISH, and that the soft state inputs > then augment or override the default state. > > I've also rewritten the security considerations section, > updated the references and fixed some typos. Otherwise there > won't be any changes compared to the previous version. > > Markus > > > -----Original Message----- > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > Sent: 28 April, 2004 15:13 > > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); jdrosen@dynamicsoft.com > > Subject: RE: [Simple] RE: Updating the XCAP PIDF manipulation draft > > > > > > Comments in line Markus/gf > > > > > -----Original Message----- > > > From: simple-admin@ietf.org > > [mailto:simple-admin@ietf.org]On Behalf Of > > > Markus.Isomaki@nokia.com > > > Sent: Wednesday, April 28, 2004 4:55 AM > > > To: George Foti (QA/EMC); simple@ietf.org > > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com > > > Subject: [Simple] RE: Updating the XCAP PIDF manipulation draft > > > > > > > > > Hi George, > > > > > > Thanks for the comments. See inline: > > > > > > > -----Original Message----- > > > > From: ext George Foti (QA/EMC) [mailto:george.foti@ericsson.com] > > > > Sent: 23 April, 2004 18:09 > > > > To: Isomaki Markus (Nokia-NRC/Helsinki); simple@ietf.org > > > > Cc: Leppanen Eva-Maria (Nokia-NET/Tampere); > > jdrosen@dynamicsoft.com > > > > Subject: RE: Updating the XCAP PIDF manipulation draft > > > > > > > > > > > > Hi Markus, > > > > > > > > Here are my comments: > > > > > > > > Second paragraph: > > > > > > > > Replace: "but only single XCAP manipulated presence > document", by > > > > "but only single XCAP publishing source" > > > > > > > > > > I think this is strictly a terminology issue, and with > > > respect to this spec, people have preferred to use "XCAP > > > manipulated presence document" instead of "XCAP publishing" > > > to avoid even further confusion with SIP PUBLISH. > > > > > > > What is the confusion created here. > > The XCAP manipulated presence document will have to be > > published to the composer. > > I am merely reflecting that. > > If you are not happy with the wording, can you add your own > > words to *explicitly* reflect in the text the publishing > > aspects from the XCAP source for the XCAP manipulated > > presence document. > > > > > > Third paragraph: replace the following section > > > > "As individual inputs ................one mechanism with > > the other" > > > > > > > > by the following: > > > > > > > > "Although presence states set by XCAP, on behalf of XCAP > > > > clients, and SIP PUBLISH, on behalf of PUAs, are completely > > > > separated, conflicting information may occur within the > > > > composer for a presence state" > > > > > > > > > > The definition of "conflicting" information is quite vague > > > and can be different depending on what the actual composition > > > scheme is. So I believe the current text already captures the > > > main idea, that there can be multiple inputs, and the ESC > > > needs to be able to deal with that. This is pretty much what > > > SIP PUBLISH spec says too. > > > > I find the statement "ESC needs to be able to deal with that" > > even more vague in a spec. > > I was merely trying to give some examples on the potential > > things the ESC must deal with, rather than leaving it as is. > > > > If you are not happy with my wording, can you expand the text > > to give some examples of what the ESC have to deal with, > > given the multiple source of publishing information using SIP > > publisg or XCAP. > > > > I beleive this needs some more description/clarification. > > > > > > > > (Note that the support for XCAP based presence state setting > > > is obviously completely optional in presence systems. In some > > > cases it could be useful, in some others it may not be needed > > > at all. Some use cases are presented in the introdution > > > chapter, but they are just informational. So if someone > > > thinks that XCAP based manipulation causes more problems than > > > what the benefits are in his particular presence system, it > > > can be left out. The spec just gives an opportunity to use it > > > for those vendors/presence providers who have good ideas how > > > to use it and see that SIP PUBLISH does not solve the needs > > properly.) > > > > > > Markus > > > > > > > Rgds/gf > > > > > > > > > -----Original Message----- > > > > > From: Markus.Isomaki@nokia.com > [mailto:Markus.Isomaki@nokia.com] > > > > > Sent: Friday, April 23, 2004 10:07 AM > > > > > To: simple@ietf.org > > > > > Cc: eva-maria.leppanen@nokia.com; jdrosen@dynamicsoft.com; > > > > George Foti > > > > > (QA/EMC) > > > > > Subject: Updating the XCAP PIDF manipulation draft > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Me and Eva are working on an update to the XCAP PIDF > > > > > manipulation usage. Based on the earlier version there was > > > > > some confusion on the relationship of the presence state set > > > > > by SIP PUBLISH and XCAP PIDF manipulation. I've come up with > > > > > the text below. I would like to get some feedback whether you > > > > > think it is clear enough. At least George and Jonathan have > > > > > commented the previous version, so I would especially like > > > > > your comments. > > > > > > > > > > Chapter 1 contains the motivation, I think no changes are > > > > > needed for that. This is for Chapter 3 (the figure is > > unmodified): > > > > > > > > > > --- > > > > > > > > > > The framework for publishing presence state is introduced in > > > > > . A central part of the > > > > > framework is the event state compositor element whose > > > > > function is to compose presence information received from > > > > > serveral sources into a single coherent presence document. > > > > > > > > > > The presence state manipulated with XCAP can be seen as one > > > > > of the information sources for the compositor to be combined > > > > > with the soft state information published using SIP PUBLISH. > > > > > This is illustrated in Figure 1. It is expected that in the > > > > > normal case there can be several PUAs publishing their > > > > > separate views with SIP PUBLISH, but only single XCAP > > > > > manipulated presence document. As shown in the figure, there > > > > > can be multiple XCAP clients (for instance in different > > > > > physical devices) manipulating the same document on the XCAP > > > > > server, but this still creates only one input to the event > > > > > state compositor. > > > > > > > > > > As individual inputs the presence states set by XCAP and SIP > > > > > PUBLISH are completely separated and it is not possible to > > > > > directly manipulate the state set by one mechanism with the > > > > > other. How the compositor treats XCAP based inputs with > > > > > respect to SIP PUBLISH based inputs is a matter of compositor > > > > > policy, which is beyond the scope of this specification. > > > > > Since the SIP PUBLISH specification already mandates the > > > > > compositor to be able to deal with multiple inputs, this XCAP > > > > > usage does not impose any new requirements on the compositor > > > > > functionality. > > > > > > > > > > --- > > > > > > > > > > Regards, > > > > > Markus > > > > > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 02:23:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28319 for ; Fri, 30 Apr 2004 02:23:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRR2-0006R1-Gr for simple-archive@ietf.org; Fri, 30 Apr 2004 02:23:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRQ2-0006KQ-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 02:22:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJRPV-0006Es-00; Fri, 30 Apr 2004 02:22:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRMV-0007Wy-FU; Fri, 30 Apr 2004 02:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRHO-0006EY-Fm for simple@optimus.ietf.org; Fri, 30 Apr 2004 02:13:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28113 for ; Fri, 30 Apr 2004 02:13:43 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRHH-0005Oe-2f for simple@ietf.org; Fri, 30 Apr 2004 02:13:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRGK-0005JP-00 for simple@ietf.org; Fri, 30 Apr 2004 02:12:41 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJRFj-0005EN-00 for simple@ietf.org; Fri, 30 Apr 2004 02:12:03 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U6C6H04120 for ; Fri, 30 Apr 2004 09:12:06 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 09:11:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3U6BwT3019395 for ; Fri, 30 Apr 2004 09:11:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00feFEKo; Fri, 30 Apr 2004 09:11:56 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U6BpH22546 for ; Fri, 30 Apr 2004 09:11:51 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 09:11:50 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42E7A.06C5AFF8" Subject: RE: [Simple] Problem with XML Schema for Filter Criteria Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979F1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Problem with XML Schema for Filter Criteria Thread-Index: AcQuHyVmdn8axu6tS+SL661aeYDWuQAWrh3Q To: , X-OriginalArrivalTime: 30 Apr 2004 06:11:50.0722 (UTC) FILETIME=[06BE0220:01C42E7A] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:11:50 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42E7A.06C5AFF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rajesh, =20 Please provide more information. Which internet draft are you referring = to? What exactly in the schema caused the error? =20 Thanks, Hisham -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of = ext Rajesh Karunamurthy Sent: 29.April.2004 21:16 To: simple@ietf.org Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki) Subject: [Simple] Problem with XML Schema for Filter Criteria Hi, =20 I am working on filtering of the Presence Document and I found that = there is a small problem in the XML schema used for filtering. I used a = standard XSD schema validator,=20 http://apps.gotdotnet.com/xmltools/xsdvalidator/ and I got this error=20 =20 Error :The content model must be deterministic. Wildcard declaration = along with a local element declaration causes the content model to = become ambiguous. An error occurred at , (70, 6). =20 Can any one help me out? =20 Thanks. Rajesh =20 =20 =20 _____ =20 Do you Yahoo!? Win = a $20,000 Career Makeover at Yahoo! HotJobs=20 ------_=_NextPart_001_01C42E7A.06C5AFF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rajesh,
 
Please=20 provide more information. Which internet draft are you referring to? = What=20 exactly in the schema caused the error?
 
Thanks,
Hisham
-----Original Message-----
From: = simple-admin@ietf.org=20 [mailto:simple-admin@ietf.org]On Behalf Of ext Rajesh=20 Karunamurthy
Sent: 29.April.2004 21:16
To:=20 simple@ietf.org
Cc: Khartabil Hisham=20 (Nokia-TP-MSW/Helsinki)
Subject: [Simple] Problem with XML = Schema=20 for Filter Criteria

Hi,
 
I am working on  filtering of the Presence Document and I = found that=20 there is a small problem in the XML schema used for filtering. I used = a=20 standard XSD schema validator,
http://apps.got= dotnet.com/xmltools/xsdvalidator/ and=20 I got this error
 
Error :The content model = must be=20 deterministic. Wildcard declaration along with a local element = declaration=20 causes the content model to become ambiguous. An error occurred at , = (70,=20 6).
 
Can any one help me out?
 
Thanks.
Rajesh
 
 
 

Do you Yahoo!?
Win=20 a $20,000 Career Makeover at Yahoo! HotJobs=20 ------_=_NextPart_001_01C42E7A.06C5AFF8-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 02:27:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28513 for ; Fri, 30 Apr 2004 02:27:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRS5-0008TC-8y for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 02:24:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U6OnqJ032558 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 02:24:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRRB-0008K5-Hc for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 02:23:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28337 for ; Fri, 30 Apr 2004 02:23:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRR4-0006RE-JS for simple-web-archive@ietf.org; Fri, 30 Apr 2004 02:23:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRQ3-0006Ka-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 02:22:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJRPV-0006Es-00; Fri, 30 Apr 2004 02:22:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRMV-0007Wy-FU; Fri, 30 Apr 2004 02:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRHO-0006EY-Fm for simple@optimus.ietf.org; Fri, 30 Apr 2004 02:13:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28113 for ; Fri, 30 Apr 2004 02:13:43 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRHH-0005Oe-2f for simple@ietf.org; Fri, 30 Apr 2004 02:13:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRGK-0005JP-00 for simple@ietf.org; Fri, 30 Apr 2004 02:12:41 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJRFj-0005EN-00 for simple@ietf.org; Fri, 30 Apr 2004 02:12:03 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U6C6H04120 for ; Fri, 30 Apr 2004 09:12:06 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 09:11:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3U6BwT3019395 for ; Fri, 30 Apr 2004 09:11:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00feFEKo; Fri, 30 Apr 2004 09:11:56 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U6BpH22546 for ; Fri, 30 Apr 2004 09:11:51 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 09:11:50 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42E7A.06C5AFF8" Subject: RE: [Simple] Problem with XML Schema for Filter Criteria Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979F1@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Problem with XML Schema for Filter Criteria Thread-Index: AcQuHyVmdn8axu6tS+SL661aeYDWuQAWrh3Q To: , X-OriginalArrivalTime: 30 Apr 2004 06:11:50.0722 (UTC) FILETIME=[06BE0220:01C42E7A] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:11:50 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42E7A.06C5AFF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rajesh, =20 Please provide more information. Which internet draft are you referring = to? What exactly in the schema caused the error? =20 Thanks, Hisham -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of = ext Rajesh Karunamurthy Sent: 29.April.2004 21:16 To: simple@ietf.org Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki) Subject: [Simple] Problem with XML Schema for Filter Criteria Hi, =20 I am working on filtering of the Presence Document and I found that = there is a small problem in the XML schema used for filtering. I used a = standard XSD schema validator,=20 http://apps.gotdotnet.com/xmltools/xsdvalidator/ and I got this error=20 =20 Error :The content model must be deterministic. Wildcard declaration = along with a local element declaration causes the content model to = become ambiguous. An error occurred at , (70, 6). =20 Can any one help me out? =20 Thanks. Rajesh =20 =20 =20 _____ =20 Do you Yahoo!? Win = a $20,000 Career Makeover at Yahoo! HotJobs=20 ------_=_NextPart_001_01C42E7A.06C5AFF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rajesh,
 
Please=20 provide more information. Which internet draft are you referring to? = What=20 exactly in the schema caused the error?
 
Thanks,
Hisham
-----Original Message-----
From: = simple-admin@ietf.org=20 [mailto:simple-admin@ietf.org]On Behalf Of ext Rajesh=20 Karunamurthy
Sent: 29.April.2004 21:16
To:=20 simple@ietf.org
Cc: Khartabil Hisham=20 (Nokia-TP-MSW/Helsinki)
Subject: [Simple] Problem with XML = Schema=20 for Filter Criteria

Hi,
 
I am working on  filtering of the Presence Document and I = found that=20 there is a small problem in the XML schema used for filtering. I used = a=20 standard XSD schema validator,
http://apps.got= dotnet.com/xmltools/xsdvalidator/ and=20 I got this error
 
Error :The content model = must be=20 deterministic. Wildcard declaration along with a local element = declaration=20 causes the content model to become ambiguous. An error occurred at , = (70,=20 6).
 
Can any one help me out?
 
Thanks.
Rajesh
 
 
 

Do you Yahoo!?
Win=20 a $20,000 Career Makeover at Yahoo! HotJobs=20 ------_=_NextPart_001_01C42E7A.06C5AFF8-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 02:41:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29019 for ; Fri, 30 Apr 2004 02:41:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRib-0000nl-Qe for simple-archive@ietf.org; Fri, 30 Apr 2004 02:41:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRhg-0000fh-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 02:40:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJRgv-0000Y8-00; Fri, 30 Apr 2004 02:40:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRb0-0001V3-Nw; Fri, 30 Apr 2004 02:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRWr-0000vm-4e for simple@optimus.ietf.org; Fri, 30 Apr 2004 02:29:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28619 for ; Fri, 30 Apr 2004 02:29:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRWk-00078b-9F for simple@ietf.org; Fri, 30 Apr 2004 02:29:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRVm-00072D-00 for simple@ietf.org; Fri, 30 Apr 2004 02:28:39 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJRUs-0006vw-00 for simple@ietf.org; Fri, 30 Apr 2004 02:27:42 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U6RZv11582; Fri, 30 Apr 2004 09:27:35 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 09:27:20 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3U6RKtO024340; Fri, 30 Apr 2004 09:27:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00hpiJ82; Fri, 30 Apr 2004 09:27:20 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U6RJH05449; Fri, 30 Apr 2004 09:27:19 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 09:27:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 09:27:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979F2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQuGno+S8hkiNZPTmuNIx+A90HBigAYOHCg To: , Cc: , X-OriginalArrivalTime: 30 Apr 2004 06:27:18.0754 (UTC) FILETIME=[2FE47420:01C42E7C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:27:19 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ok, I also agree that overlapping partial NOTIFYs complicate things = without benefit. I also would like to propose explicitly disallowing = overlapping full state and partial. I.e. A notifier must not issue a = partial state NOTIFY without first receiving the 200 for a full state = NOTIFY. I believe the converse is also required: the notifier must not = issue a full state NOTIFY before it receives a 200 for a partial state = NOTIFY. With all there restrictions, we can do without the version attribute. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 29.April.2004 21:47 > To: Robert Sparks > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > (Nokia-NRC/Helsinki); simple@ietf.org > Subject: Re: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > Robert Sparks wrote: > > Aside from that I'd like for you to think through this again > > from viewpoints besides active attack (use a transient malfunction > > of the application (above the layer that would screw up basic SIP)), > > I'm ready to let this go as long as we have _a_ solid solution to > > dealing with reordered/missing notifies. >=20 > I'm not going to start down the path to speculation about how=20 > to recover=20 > from arbitrary malfunctions of an application. That is just plain=20 > impossible without some characterization of the kinds of malfunctions=20 > that are to be recovered from. >=20 > > So, backing out a layer, lets look at my original question of > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > in this case. >=20 > I don't see any compelling need to support overlapping=20 > partial notifies.=20 > It is very difficult to see how to make them work. >=20 > I can imagine a case where there might be some motivation: I sent one=20 > notification and have had no response. But I already have a bunch of=20 > additional changes that you should know about. It might be=20 > advantageous=20 > to start sending them as soon as possible. But until you know=20 > the prior=20 > one has been handled it isn't safe to send the new one. >=20 > > Why would you want to? What value would doing that bring?=20 > >=20 > > 3261 and even presence-10 left sending full-state presence > > NOTIFYs open. We wouldn't be changing that. If an application > > for some reason decided it needed to send a new full-state > > notify while a partial-state notify was pending, it could. > > So any of the arguments for allowing it from the 3261/presence-10 > > are still satisfied. Can you see any use case where allowing > > a server to send overlapping partial NOTIFYs is a good idea? > > If not, disallowing it seems a powerful simplification. > > >=20 > I agree. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 02:44:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29146 for ; Fri, 30 Apr 2004 02:44:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRjj-0003OU-U8 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 02:43:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U6h397013041 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 02:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRij-0003Dt-IF for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 02:42:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29037 for ; Fri, 30 Apr 2004 02:41:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRic-0000nq-HF for simple-web-archive@ietf.org; Fri, 30 Apr 2004 02:41:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRhh-0000fo-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 02:40:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJRgv-0000Y8-00; Fri, 30 Apr 2004 02:40:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRb0-0001V3-Nw; Fri, 30 Apr 2004 02:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRWr-0000vm-4e for simple@optimus.ietf.org; Fri, 30 Apr 2004 02:29:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28619 for ; Fri, 30 Apr 2004 02:29:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRWk-00078b-9F for simple@ietf.org; Fri, 30 Apr 2004 02:29:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRVm-00072D-00 for simple@ietf.org; Fri, 30 Apr 2004 02:28:39 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJRUs-0006vw-00 for simple@ietf.org; Fri, 30 Apr 2004 02:27:42 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U6RZv11582; Fri, 30 Apr 2004 09:27:35 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 09:27:20 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3U6RKtO024340; Fri, 30 Apr 2004 09:27:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00hpiJ82; Fri, 30 Apr 2004 09:27:20 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U6RJH05449; Fri, 30 Apr 2004 09:27:19 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 09:27:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 09:27:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: partial notification Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979F2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] WGLC: partial notification Thread-Index: AcQuGno+S8hkiNZPTmuNIx+A90HBigAYOHCg To: , Cc: , X-OriginalArrivalTime: 30 Apr 2004 06:27:18.0754 (UTC) FILETIME=[2FE47420:01C42E7C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:27:19 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ok, I also agree that overlapping partial NOTIFYs complicate things = without benefit. I also would like to propose explicitly disallowing = overlapping full state and partial. I.e. A notifier must not issue a = partial state NOTIFY without first receiving the 200 for a full state = NOTIFY. I believe the converse is also required: the notifier must not = issue a full state NOTIFY before it receives a 200 for a partial state = NOTIFY. With all there restrictions, we can do without the version attribute. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 29.April.2004 21:47 > To: Robert Sparks > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > (Nokia-NRC/Helsinki); simple@ietf.org > Subject: Re: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > Robert Sparks wrote: > > Aside from that I'd like for you to think through this again > > from viewpoints besides active attack (use a transient malfunction > > of the application (above the layer that would screw up basic SIP)), > > I'm ready to let this go as long as we have _a_ solid solution to > > dealing with reordered/missing notifies. >=20 > I'm not going to start down the path to speculation about how=20 > to recover=20 > from arbitrary malfunctions of an application. That is just plain=20 > impossible without some characterization of the kinds of malfunctions=20 > that are to be recovered from. >=20 > > So, backing out a layer, lets look at my original question of > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > in this case. >=20 > I don't see any compelling need to support overlapping=20 > partial notifies.=20 > It is very difficult to see how to make them work. >=20 > I can imagine a case where there might be some motivation: I sent one=20 > notification and have had no response. But I already have a bunch of=20 > additional changes that you should know about. It might be=20 > advantageous=20 > to start sending them as soon as possible. But until you know=20 > the prior=20 > one has been handled it isn't safe to send the new one. >=20 > > Why would you want to? What value would doing that bring?=20 > >=20 > > 3261 and even presence-10 left sending full-state presence > > NOTIFYs open. We wouldn't be changing that. If an application > > for some reason decided it needed to send a new full-state > > notify while a partial-state notify was pending, it could. > > So any of the arguments for allowing it from the 3261/presence-10 > > are still satisfied. Can you see any use case where allowing > > a server to send overlapping partial NOTIFYs is a good idea? > > If not, disallowing it seems a powerful simplification. > > >=20 > I agree. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 04:32:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03098 for ; Fri, 30 Apr 2004 04:32:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJTRw-000653-2o for simple-archive@ietf.org; Fri, 30 Apr 2004 04:32:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJTR6-0005yA-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 04:31:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJTQL-0005qa-00; Fri, 30 Apr 2004 04:31:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTLP-0003vL-FH; Fri, 30 Apr 2004 04:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTGi-0003RD-HP for simple@optimus.ietf.org; Fri, 30 Apr 2004 04:21:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02671 for ; Fri, 30 Apr 2004 04:21:10 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJTGc-0004Xx-AP for simple@ietf.org; Fri, 30 Apr 2004 04:21:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJTFW-0004P3-00 for simple@ietf.org; Fri, 30 Apr 2004 04:19:59 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJTF7-0004Gp-00 for simple@ietf.org; Fri, 30 Apr 2004 04:19:33 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U8JKH00539; Fri, 30 Apr 2004 11:19:20 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 11:18:59 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3U8IxTw030227; Fri, 30 Apr 2004 11:18:59 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ULUDzm; Fri, 30 Apr 2004 11:18:58 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U8IvH03344; Fri, 30 Apr 2004 11:18:57 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 11:18:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979F5@esebe019.ntc.nokia.com> Thread-Topic: Comments on isComposing Thread-Index: AcQui8YqIa0hEqynQnS4nWuCLuKX2g== To: Cc: X-OriginalArrivalTime: 30 Apr 2004 08:18:54.0284 (UTC) FILETIME=[C6BD40C0:01C42E8B] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on isComposing Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 11:18:54 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable [Not as a WG chair] Hi, I sent some NITs to Henning privately. Below are some comments that = might be classified more than just NITs (or maybe not:) Title -------- - The title mesions that this is for IM using SIP. Is this true? Can't = this be used with any other IM protocol, including MSRP? I suggest = removing SIP from the title and also changing the mime type to = application/im-iscomposing+xml and the XML namespace to im-iscomposing Description ------------ - "The composing user MAY specify a time-out interval measured in seconds, using the element, after which the isComposing message is resent to refresh the state. The refresh period SHOULD be no shorter than 60 seconds" . Should this text be normative? It probably is, but then some text is = needed describing the behaviour when this SHOULD is violated. I.e. What = should the recipient do if it receives a refresh after less than 60 = seconds? Some text needs to be added describing what the recipient does when a = state times out. Does the recipient assume that the originator is = instate idle? If so, then should the time-out be limited to active state = (if a result of time out means that the originator is now idle, then = there is no point of timing out on idle)? - "When the user starts composing again while in Idle state, the state transitions to Active, with the corresponding message." What does "with the corresponding message" mean? Are you saying the a = corresponding status message is sent? If so, please clarify. - "The idle timeout SHOULD be ten seconds." I agree this is normative = text, but some more text needs to be added describing the consequences = of the originator not sending an idle state message. I.e. The recipient = would have false info that the originator is now composing when he is = not. - "If an instant message is sent before the idle threshold expires, no idle state indication is needed" Should some text be added stating that the idle timer is started/reset = when composing a message ends and the message has been sent, and is = disabled when composing a message begins? . Should the sentence continue to state that "The recipient should, = after receiving the instant message, assume the sender is now in idle = state"? - "Thus, in most cases, only one message is needed. The message rate is limited to one message per idle threshold interval." Is this talking about a status message? If so, please indicate so. If = not, then the question is why is there a limit to how many messages per = idle threshold is specified? Please clarify this sentence. - "The isComposing indicator MAY be carried in CPIM messages [I-D.ietf-impp-cpim-msgfmt]." Why is this method of carrying the isComposing indicator singled out and = mentioned here when all other possibilities are not mentioned? Using the Indicator --------------------- - " First, it ensures proper sequencing and synchronization with the actual messages being composed" Can some more text or flows be added to emphasise the point more? Security Considerations ------------------------ You might want to mention that since the status messages are carried = using the IM protocol itself, all security protection mechanisms for = that IM protocol apply wen also carrying the status in a message. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 04:39:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03328 for ; Fri, 30 Apr 2004 04:39:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTWh-0005Fl-Iv for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 04:37:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U8bhgV020187 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 04:37:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTS4-0004fZ-8c for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 04:32:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03116 for ; Fri, 30 Apr 2004 04:32:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJTRx-00065G-Hg for simple-web-archive@ietf.org; Fri, 30 Apr 2004 04:32:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJTR7-0005yJ-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 04:31:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJTQL-0005qa-00; Fri, 30 Apr 2004 04:31:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTLP-0003vL-FH; Fri, 30 Apr 2004 04:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTGi-0003RD-HP for simple@optimus.ietf.org; Fri, 30 Apr 2004 04:21:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02671 for ; Fri, 30 Apr 2004 04:21:10 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJTGc-0004Xx-AP for simple@ietf.org; Fri, 30 Apr 2004 04:21:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJTFW-0004P3-00 for simple@ietf.org; Fri, 30 Apr 2004 04:19:59 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJTF7-0004Gp-00 for simple@ietf.org; Fri, 30 Apr 2004 04:19:33 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U8JKH00539; Fri, 30 Apr 2004 11:19:20 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 11:18:59 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3U8IxTw030227; Fri, 30 Apr 2004 11:18:59 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ULUDzm; Fri, 30 Apr 2004 11:18:58 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U8IvH03344; Fri, 30 Apr 2004 11:18:57 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 11:18:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017979F5@esebe019.ntc.nokia.com> Thread-Topic: Comments on isComposing Thread-Index: AcQui8YqIa0hEqynQnS4nWuCLuKX2g== To: Cc: X-OriginalArrivalTime: 30 Apr 2004 08:18:54.0284 (UTC) FILETIME=[C6BD40C0:01C42E8B] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on isComposing Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 11:18:54 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable [Not as a WG chair] Hi, I sent some NITs to Henning privately. Below are some comments that = might be classified more than just NITs (or maybe not:) Title -------- - The title mesions that this is for IM using SIP. Is this true? Can't = this be used with any other IM protocol, including MSRP? I suggest = removing SIP from the title and also changing the mime type to = application/im-iscomposing+xml and the XML namespace to im-iscomposing Description ------------ - "The composing user MAY specify a time-out interval measured in seconds, using the element, after which the isComposing message is resent to refresh the state. The refresh period SHOULD be no shorter than 60 seconds" . Should this text be normative? It probably is, but then some text is = needed describing the behaviour when this SHOULD is violated. I.e. What = should the recipient do if it receives a refresh after less than 60 = seconds? Some text needs to be added describing what the recipient does when a = state times out. Does the recipient assume that the originator is = instate idle? If so, then should the time-out be limited to active state = (if a result of time out means that the originator is now idle, then = there is no point of timing out on idle)? - "When the user starts composing again while in Idle state, the state transitions to Active, with the corresponding message." What does "with the corresponding message" mean? Are you saying the a = corresponding status message is sent? If so, please clarify. - "The idle timeout SHOULD be ten seconds." I agree this is normative = text, but some more text needs to be added describing the consequences = of the originator not sending an idle state message. I.e. The recipient = would have false info that the originator is now composing when he is = not. - "If an instant message is sent before the idle threshold expires, no idle state indication is needed" Should some text be added stating that the idle timer is started/reset = when composing a message ends and the message has been sent, and is = disabled when composing a message begins? . Should the sentence continue to state that "The recipient should, = after receiving the instant message, assume the sender is now in idle = state"? - "Thus, in most cases, only one message is needed. The message rate is limited to one message per idle threshold interval." Is this talking about a status message? If so, please indicate so. If = not, then the question is why is there a limit to how many messages per = idle threshold is specified? Please clarify this sentence. - "The isComposing indicator MAY be carried in CPIM messages [I-D.ietf-impp-cpim-msgfmt]." Why is this method of carrying the isComposing indicator singled out and = mentioned here when all other possibilities are not mentioned? Using the Indicator --------------------- - " First, it ensures proper sequencing and synchronization with the actual messages being composed" Can some more text or flows be added to emphasise the point more? Security Considerations ------------------------ You might want to mention that since the status messages are carried = using the IM protocol itself, all security protection mechanisms for = that IM protocol apply wen also carrying the status in a message. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 07:41:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11410 for ; Fri, 30 Apr 2004 07:41:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWO7-0004pQ-NW for simple-archive@ietf.org; Fri, 30 Apr 2004 07:41:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWNI-0004fL-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 07:40:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJWMt-0004VE-00; Fri, 30 Apr 2004 07:39:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWJF-0003yr-5r; Fri, 30 Apr 2004 07:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWDV-0003LX-GZ for simple@optimus.ietf.org; Fri, 30 Apr 2004 07:30:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10994 for ; Fri, 30 Apr 2004 07:30:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWDU-0002x4-OQ for simple@ietf.org; Fri, 30 Apr 2004 07:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWCc-0002nc-00 for simple@ietf.org; Fri, 30 Apr 2004 07:29:11 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BJWCD-0002dg-00 for simple@ietf.org; Fri, 30 Apr 2004 07:28:45 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3UBSHM16724; Fri, 30 Apr 2004 13:28:17 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i3UBSGM24776; Fri, 30 Apr 2004 13:28:16 +0200 (MEST) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA01521; Fri, 30 Apr 2004 13:28:16 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 13:27:44 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 13:27:42 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Hisham, this proposal would not solve the problem with a missing NOTIFY (full = or partial).=20 What=B4s about the following proposal: The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should send a full NOTIFY. This would also work without version number and would cover reordering = and packet loss cases. Regards, Christian -----Urspr=FCngliche Nachricht----- Von: simple-admin@ietf.org [mailto:simple-admin@ietf.org] Im Auftrag = von hisham.khartabil@nokia.com Gesendet: Freitag, 30. April 2004 08:27 An: pkyzivat@cisco.com; rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com; simple@ietf.org Betreff: RE: [Simple] WGLC: partial notification Ok, I also agree that overlapping partial NOTIFYs complicate things = without benefit. I also would like to propose explicitly disallowing = overlapping full state and partial. I.e. A notifier must not issue a = partial state NOTIFY without first receiving the 200 for a full state = NOTIFY. I believe the converse is also required: the notifier must not = issue a full state NOTIFY before it receives a 200 for a partial state = NOTIFY. With all there restrictions, we can do without the version attribute. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 29.April.2004 21:47 > To: Robert Sparks > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > (Nokia-NRC/Helsinki); simple@ietf.org > Subject: Re: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > Robert Sparks wrote: > > Aside from that I'd like for you to think through this again > > from viewpoints besides active attack (use a transient malfunction > > of the application (above the layer that would screw up basic = SIP)), > > I'm ready to let this go as long as we have _a_ solid solution to > > dealing with reordered/missing notifies. >=20 > I'm not going to start down the path to speculation about how=20 > to recover=20 > from arbitrary malfunctions of an application. That is just plain=20 > impossible without some characterization of the kinds of malfunctions = > that are to be recovered from. >=20 > > So, backing out a layer, lets look at my original question of > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > in this case. >=20 > I don't see any compelling need to support overlapping=20 > partial notifies.=20 > It is very difficult to see how to make them work. >=20 > I can imagine a case where there might be some motivation: I sent one = > notification and have had no response. But I already have a bunch of=20 > additional changes that you should know about. It might be=20 > advantageous=20 > to start sending them as soon as possible. But until you know=20 > the prior=20 > one has been handled it isn't safe to send the new one. >=20 > > Why would you want to? What value would doing that bring?=20 > >=20 > > 3261 and even presence-10 left sending full-state presence > > NOTIFYs open. We wouldn't be changing that. If an application > > for some reason decided it needed to send a new full-state > > notify while a partial-state notify was pending, it could. > > So any of the arguments for allowing it from the 3261/presence-10 > > are still satisfied. Can you see any use case where allowing > > a server to send overlapping partial NOTIFYs is a good idea? > > If not, disallowing it seems a powerful simplification. > > >=20 > I agree. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 07:45:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11628 for ; Fri, 30 Apr 2004 07:45:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWQz-0005NV-E0 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 07:44:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UBi1rF020671 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 07:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWOA-0004x6-3G for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 07:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11430 for ; Fri, 30 Apr 2004 07:41:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWO9-0004pd-1S for simple-web-archive@ietf.org; Fri, 30 Apr 2004 07:41:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWNJ-0004fT-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 07:40:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJWMt-0004VE-00; Fri, 30 Apr 2004 07:39:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWJF-0003yr-5r; Fri, 30 Apr 2004 07:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWDV-0003LX-GZ for simple@optimus.ietf.org; Fri, 30 Apr 2004 07:30:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10994 for ; Fri, 30 Apr 2004 07:30:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWDU-0002x4-OQ for simple@ietf.org; Fri, 30 Apr 2004 07:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWCc-0002nc-00 for simple@ietf.org; Fri, 30 Apr 2004 07:29:11 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BJWCD-0002dg-00 for simple@ietf.org; Fri, 30 Apr 2004 07:28:45 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3UBSHM16724; Fri, 30 Apr 2004 13:28:17 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i3UBSGM24776; Fri, 30 Apr 2004 13:28:16 +0200 (MEST) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA01521; Fri, 30 Apr 2004 13:28:16 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 13:27:44 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 13:27:42 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Hisham, this proposal would not solve the problem with a missing NOTIFY (full = or partial).=20 What=B4s about the following proposal: The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should send a full NOTIFY. This would also work without version number and would cover reordering = and packet loss cases. Regards, Christian -----Urspr=FCngliche Nachricht----- Von: simple-admin@ietf.org [mailto:simple-admin@ietf.org] Im Auftrag = von hisham.khartabil@nokia.com Gesendet: Freitag, 30. April 2004 08:27 An: pkyzivat@cisco.com; rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com; simple@ietf.org Betreff: RE: [Simple] WGLC: partial notification Ok, I also agree that overlapping partial NOTIFYs complicate things = without benefit. I also would like to propose explicitly disallowing = overlapping full state and partial. I.e. A notifier must not issue a = partial state NOTIFY without first receiving the 200 for a full state = NOTIFY. I believe the converse is also required: the notifier must not = issue a full state NOTIFY before it receives a 200 for a partial state = NOTIFY. With all there restrictions, we can do without the version attribute. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 29.April.2004 21:47 > To: Robert Sparks > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > (Nokia-NRC/Helsinki); simple@ietf.org > Subject: Re: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > Robert Sparks wrote: > > Aside from that I'd like for you to think through this again > > from viewpoints besides active attack (use a transient malfunction > > of the application (above the layer that would screw up basic = SIP)), > > I'm ready to let this go as long as we have _a_ solid solution to > > dealing with reordered/missing notifies. >=20 > I'm not going to start down the path to speculation about how=20 > to recover=20 > from arbitrary malfunctions of an application. That is just plain=20 > impossible without some characterization of the kinds of malfunctions = > that are to be recovered from. >=20 > > So, backing out a layer, lets look at my original question of > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > in this case. >=20 > I don't see any compelling need to support overlapping=20 > partial notifies.=20 > It is very difficult to see how to make them work. >=20 > I can imagine a case where there might be some motivation: I sent one = > notification and have had no response. But I already have a bunch of=20 > additional changes that you should know about. It might be=20 > advantageous=20 > to start sending them as soon as possible. But until you know=20 > the prior=20 > one has been handled it isn't safe to send the new one. >=20 > > Why would you want to? What value would doing that bring?=20 > >=20 > > 3261 and even presence-10 left sending full-state presence > > NOTIFYs open. We wouldn't be changing that. If an application > > for some reason decided it needed to send a new full-state > > notify while a partial-state notify was pending, it could. > > So any of the arguments for allowing it from the 3261/presence-10 > > are still satisfied. Can you see any use case where allowing > > a server to send overlapping partial NOTIFYs is a good idea? > > If not, disallowing it seems a powerful simplification. > > >=20 > I agree. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 08:04:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12185 for ; Fri, 30 Apr 2004 08:04:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWlB-0000qi-AC for simple-archive@ietf.org; Fri, 30 Apr 2004 08:04:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWjt-0000aa-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 08:03:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJWj2-0000MO-00; Fri, 30 Apr 2004 08:02:41 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJWUV-0007nJ-Ek; Fri, 30 Apr 2004 07:47:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWRx-0005VV-DT; Fri, 30 Apr 2004 07:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWNH-0004qq-4I for simple@optimus.ietf.org; Fri, 30 Apr 2004 07:40:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11360 for ; Fri, 30 Apr 2004 07:40:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWNG-0004ev-Bn for simple@ietf.org; Fri, 30 Apr 2004 07:40:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWMZ-0004Ut-00 for simple@ietf.org; Fri, 30 Apr 2004 07:39:27 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BJWLq-0004JB-00 for simple@ietf.org; Fri, 30 Apr 2004 07:38:43 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3UBcWj18895; Fri, 30 Apr 2004 13:38:33 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3UBcUl04301; Fri, 30 Apr 2004 13:38:30 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA03200; Fri, 30 Apr 2004 13:38:30 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 13:37:58 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 13:37:56 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Redundancy: (1) In draft-ietf-simple-partial-pidf-format-01.txt, section 3.3 there is a statement: " element MUST NOT be included if "state" attribute has value "full". (2) In draft-ietf-simple-partial-notify-02.txt, section 4.5, there is a description, how a watcher has to react on a full NOTIFY with a element included. because of (1), case (2) never can happen. For simplicity, I propose to delete (2). Regards, Christian Schmidt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 08:12:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12545 for ; Fri, 30 Apr 2004 08:12:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWnw-0007z5-N0 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 08:07:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UC7ic5030691 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 08:07:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWlC-0007XR-Va for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 08:04:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12203 for ; Fri, 30 Apr 2004 08:04:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWlC-0000qn-0F for simple-web-archive@ietf.org; Fri, 30 Apr 2004 08:04:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWju-0000ah-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 08:03:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJWj2-0000MO-00; Fri, 30 Apr 2004 08:02:41 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJWUV-0007nJ-Ek; Fri, 30 Apr 2004 07:47:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWRx-0005VV-DT; Fri, 30 Apr 2004 07:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWNH-0004qq-4I for simple@optimus.ietf.org; Fri, 30 Apr 2004 07:40:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11360 for ; Fri, 30 Apr 2004 07:40:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWNG-0004ev-Bn for simple@ietf.org; Fri, 30 Apr 2004 07:40:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWMZ-0004Ut-00 for simple@ietf.org; Fri, 30 Apr 2004 07:39:27 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BJWLq-0004JB-00 for simple@ietf.org; Fri, 30 Apr 2004 07:38:43 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i3UBcWj18895; Fri, 30 Apr 2004 13:38:33 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3UBcUl04301; Fri, 30 Apr 2004 13:38:30 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA03200; Fri, 30 Apr 2004 13:38:30 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 13:37:58 +0200 Message-ID: From: Schmidt Christian To: "'hisham.khartabil@nokia.com'" , pkyzivat@cisco.com, rsparks@dynamicsoft.com Cc: mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: [Simple] WGLC: partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 13:37:56 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Redundancy: (1) In draft-ietf-simple-partial-pidf-format-01.txt, section 3.3 there is a statement: " element MUST NOT be included if "state" attribute has value "full". (2) In draft-ietf-simple-partial-notify-02.txt, section 4.5, there is a description, how a watcher has to react on a full NOTIFY with a element included. because of (1), case (2) never can happen. For simplicity, I propose to delete (2). Regards, Christian Schmidt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 09:10:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29730 for ; Fri, 30 Apr 2004 09:10:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXmL-0005Do-78 for simple-archive@ietf.org; Fri, 30 Apr 2004 09:10:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXlO-00053S-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 09:09:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJXkr-0004tD-00; Fri, 30 Apr 2004 09:08:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXYj-0001vb-4u; Fri, 30 Apr 2004 08:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXWt-0001I8-IM for simple@optimus.ietf.org; Fri, 30 Apr 2004 08:54:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28177 for ; Fri, 30 Apr 2004 08:54:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXT5-0001VY-2o for simple@ietf.org; Fri, 30 Apr 2004 08:50:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXSF-0001LP-00 for simple@ietf.org; Fri, 30 Apr 2004 08:49:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BJXRl-0001AA-00 for simple@ietf.org; Fri, 30 Apr 2004 08:48:54 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 30 Apr 2004 05:48:27 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3UCmJjO026685; Fri, 30 Apr 2004 05:48:19 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIB25267; Fri, 30 Apr 2004 08:48:18 -0400 (EDT) Message-ID: <40924B12.6060000@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Schmidt Christian CC: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: AW: [Simple] WGLC: partial notification References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA28179 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 08:48:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Schmidt Christian wrote: > Hi Hisham, >=20 > this proposal would not solve the problem with a missing NOTIFY (full o= r partial).=20 >=20 > What=B4s about the following proposal: > The notifier must not issue a NOTIFY (full or partial), before it recei= ves a 200 for the last issued NOTIFY (full or partial). After experation = of a timer t, the notifier should send a full NOTIFY. >=20 > This would also work without version number and would cover reordering = and packet loss cases. This would work. I guess it is obvious that if the full notify also=20 times out then further retries, if any, should also send full state. And=20 that this should continue until there is success. A notify with partial=20 state could only happen after receiving a 2xx for the prior notify. OTOH, this might be a bad choice for a bandwidth constrained device,=20 like a cell phone. If you are driving thru a tunnel and can't receive=20 for a few minutes, are going to be happy to get a full update when you=20 emerge? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 09:17:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00017 for ; Fri, 30 Apr 2004 09:17:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXt5-0006Ub-LB for simple-archive@ietf.org; Fri, 30 Apr 2004 09:17:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXsB-0006K8-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 09:16:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJXrd-00069m-00; Fri, 30 Apr 2004 09:15:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXoB-0005xH-6r; Fri, 30 Apr 2004 09:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXdr-0003kI-GR for simple@optimus.ietf.org; Fri, 30 Apr 2004 09:01:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29204 for ; Fri, 30 Apr 2004 09:01:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXdp-0003Zb-Tv for simple@ietf.org; Fri, 30 Apr 2004 09:01:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXcs-0003N6-00 for simple@ietf.org; Fri, 30 Apr 2004 09:00:23 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BJXcG-0003BF-00 for simple@ietf.org; Fri, 30 Apr 2004 08:59:44 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i3UCwxS11785; Fri, 30 Apr 2004 14:58:59 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3UCwvl01424; Fri, 30 Apr 2004 14:58:58 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA18336; Fri, 30 Apr 2004 14:58:55 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 14:58:23 +0200 Message-ID: From: Schmidt Christian To: "'Paul Kyzivat'" , Schmidt Christian Cc: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: AW: [Simple] WGLC: partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 14:58:22 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Paul, thank you for the comment. Concerning the tunnel case, it is a = question, how often this would happen. If it is a rare case, perhaps we can ignore it. If not, we can = add a repetition option. Modified proposal: The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should repeat the last message = and if the timer t expires a second time, send a full NOTIFY. Regards, Christian -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Freitag, 30. April 2004 14:48 An: Schmidt Christian Cc: 'hisham.khartabil@nokia.com'; rsparks@dynamicsoft.com; = mikko.lonnfors@nokia.com; simple@ietf.org Betreff: Re: AW: [Simple] WGLC: partial notification Schmidt Christian wrote: > Hi Hisham, >=20 > this proposal would not solve the problem with a missing NOTIFY (full = or partial).=20 >=20 > What=B4s about the following proposal: > The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should send a full NOTIFY. >=20 > This would also work without version number and would cover = reordering and packet loss cases. This would work. I guess it is obvious that if the full notify also=20 times out then further retries, if any, should also send full state. = And=20 that this should continue until there is success. A notify with partial = state could only happen after receiving a 2xx for the prior notify. OTOH, this might be a bad choice for a bandwidth constrained device,=20 like a cell phone. If you are driving thru a tunnel and can't receive=20 for a few minutes, are going to be happy to get a full update when you=20 emerge? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 09:17:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00060 for ; Fri, 30 Apr 2004 09:17:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXoQ-000681-9P for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 09:12:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UDCIpA023551 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 09:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXmN-0005ZH-PC for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:10:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29749 for ; Fri, 30 Apr 2004 09:10:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXmL-0005Dv-TZ for simple-web-archive@ietf.org; Fri, 30 Apr 2004 09:10:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXlP-00053Z-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 09:09:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJXkr-0004tD-00; Fri, 30 Apr 2004 09:08:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXYj-0001vb-4u; Fri, 30 Apr 2004 08:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXWt-0001I8-IM for simple@optimus.ietf.org; Fri, 30 Apr 2004 08:54:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28177 for ; Fri, 30 Apr 2004 08:54:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXT5-0001VY-2o for simple@ietf.org; Fri, 30 Apr 2004 08:50:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXSF-0001LP-00 for simple@ietf.org; Fri, 30 Apr 2004 08:49:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BJXRl-0001AA-00 for simple@ietf.org; Fri, 30 Apr 2004 08:48:54 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 30 Apr 2004 05:48:27 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3UCmJjO026685; Fri, 30 Apr 2004 05:48:19 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIB25267; Fri, 30 Apr 2004 08:48:18 -0400 (EDT) Message-ID: <40924B12.6060000@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Schmidt Christian CC: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: AW: [Simple] WGLC: partial notification References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA28179 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 08:48:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Schmidt Christian wrote: > Hi Hisham, >=20 > this proposal would not solve the problem with a missing NOTIFY (full o= r partial).=20 >=20 > What=B4s about the following proposal: > The notifier must not issue a NOTIFY (full or partial), before it recei= ves a 200 for the last issued NOTIFY (full or partial). After experation = of a timer t, the notifier should send a full NOTIFY. >=20 > This would also work without version number and would cover reordering = and packet loss cases. This would work. I guess it is obvious that if the full notify also=20 times out then further retries, if any, should also send full state. And=20 that this should continue until there is success. A notify with partial=20 state could only happen after receiving a 2xx for the prior notify. OTOH, this might be a bad choice for a bandwidth constrained device,=20 like a cell phone. If you are driving thru a tunnel and can't receive=20 for a few minutes, are going to be happy to get a full update when you=20 emerge? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 09:31:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00965 for ; Fri, 30 Apr 2004 09:31:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJY0c-0000ZL-2F for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 09:24:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UDOsHs002187 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 09:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXt7-0006vC-Qa for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00035 for ; Fri, 30 Apr 2004 09:17:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXt6-0006Ug-9F for simple-web-archive@ietf.org; Fri, 30 Apr 2004 09:17:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXsC-0006KG-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 09:16:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJXrd-00069m-00; Fri, 30 Apr 2004 09:15:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXoB-0005xH-6r; Fri, 30 Apr 2004 09:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXdr-0003kI-GR for simple@optimus.ietf.org; Fri, 30 Apr 2004 09:01:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29204 for ; Fri, 30 Apr 2004 09:01:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXdp-0003Zb-Tv for simple@ietf.org; Fri, 30 Apr 2004 09:01:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXcs-0003N6-00 for simple@ietf.org; Fri, 30 Apr 2004 09:00:23 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BJXcG-0003BF-00 for simple@ietf.org; Fri, 30 Apr 2004 08:59:44 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i3UCwxS11785; Fri, 30 Apr 2004 14:58:59 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i3UCwvl01424; Fri, 30 Apr 2004 14:58:58 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA18336; Fri, 30 Apr 2004 14:58:55 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 14:58:23 +0200 Message-ID: From: Schmidt Christian To: "'Paul Kyzivat'" , Schmidt Christian Cc: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: AW: [Simple] WGLC: partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 14:58:22 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Paul, thank you for the comment. Concerning the tunnel case, it is a = question, how often this would happen. If it is a rare case, perhaps we can ignore it. If not, we can = add a repetition option. Modified proposal: The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should repeat the last message = and if the timer t expires a second time, send a full NOTIFY. Regards, Christian -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Freitag, 30. April 2004 14:48 An: Schmidt Christian Cc: 'hisham.khartabil@nokia.com'; rsparks@dynamicsoft.com; = mikko.lonnfors@nokia.com; simple@ietf.org Betreff: Re: AW: [Simple] WGLC: partial notification Schmidt Christian wrote: > Hi Hisham, >=20 > this proposal would not solve the problem with a missing NOTIFY (full = or partial).=20 >=20 > What=B4s about the following proposal: > The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should send a full NOTIFY. >=20 > This would also work without version number and would cover = reordering and packet loss cases. This would work. I guess it is obvious that if the full notify also=20 times out then further retries, if any, should also send full state. = And=20 that this should continue until there is success. A notify with partial = state could only happen after receiving a 2xx for the prior notify. OTOH, this might be a bad choice for a bandwidth constrained device,=20 like a cell phone. If you are driving thru a tunnel and can't receive=20 for a few minutes, are going to be happy to get a full update when you=20 emerge? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 09:42:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01368 for ; Fri, 30 Apr 2004 09:42:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYHN-0003Fr-NJ for simple-archive@ietf.org; Fri, 30 Apr 2004 09:42:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYGP-00033a-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 09:41:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJYFX-0002sM-00; Fri, 30 Apr 2004 09:40:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJY8V-0001oO-9V; Fri, 30 Apr 2004 09:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJY2o-0000za-Kp for simple@optimus.ietf.org; Fri, 30 Apr 2004 09:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00740 for ; Fri, 30 Apr 2004 09:27:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJY2m-0000Yu-Ua for simple@ietf.org; Fri, 30 Apr 2004 09:27:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJY1r-0000Md-00 for simple@ietf.org; Fri, 30 Apr 2004 09:26:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BJY0x-0007nF-00 for simple@ietf.org; Fri, 30 Apr 2004 09:25:15 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2004 06:26:05 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3UDOgYu022795; Fri, 30 Apr 2004 09:24:42 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIB27471; Fri, 30 Apr 2004 09:24:41 -0400 (EDT) Message-ID: <40925399.8090805@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Schmidt Christian CC: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: AW: AW: [Simple] WGLC: partial notification References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA00741 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:24:41 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I'd like to hear what the cellular guys think of this. (Are you one of=20 them?) Paul Schmidt Christian wrote: > Hi Paul, >=20 > thank you for the comment. Concerning the tunnel case, it is a question= , how often this would > happen. If it is a rare case, perhaps we can ignore it. If not, we can = add a repetition option. >=20 > Modified proposal: > The notifier must not issue a NOTIFY (full or partial), before it recei= ves a 200 for the last issued NOTIFY (full or partial). After experation = of a timer t, the notifier should repeat the last message and if the time= r t expires a second time, send a full NOTIFY. >=20 > Regards, > Christian >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Freitag, 30. April 2004 14:48 > An: Schmidt Christian > Cc: 'hisham.khartabil@nokia.com'; rsparks@dynamicsoft.com; mikko.lonnfo= rs@nokia.com; simple@ietf.org > Betreff: Re: AW: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > Schmidt Christian wrote: >=20 >>Hi Hisham, >> >>this proposal would not solve the problem with a missing NOTIFY (full o= r partial).=20 >> >>What=B4s about the following proposal: >>The notifier must not issue a NOTIFY (full or partial), before it recei= ves a 200 for the last issued NOTIFY (full or partial). After experation = of a timer t, the notifier should send a full NOTIFY. >> >>This would also work without version number and would cover reordering = and packet loss cases. >=20 >=20 > This would work. I guess it is obvious that if the full notify also=20 > times out then further retries, if any, should also send full state. An= d=20 > that this should continue until there is success. A notify with partial= =20 > state could only happen after receiving a 2xx for the prior notify. >=20 > OTOH, this might be a bad choice for a bandwidth constrained device,=20 > like a cell phone. If you are driving thru a tunnel and can't receive=20 > for a few minutes, are going to be happy to get a full update when you=20 > emerge? >=20 > Paul >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 09:53:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01767 for ; Fri, 30 Apr 2004 09:53:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYMb-0004BI-Ef for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 09:47:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UDlbMn016067 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 09:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYHQ-0003Z3-9e for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01380 for ; Fri, 30 Apr 2004 09:42:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYHO-0003Fw-AZ for simple-web-archive@ietf.org; Fri, 30 Apr 2004 09:42:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYGQ-00033h-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 09:41:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJYFX-0002sM-00; Fri, 30 Apr 2004 09:40:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJY8V-0001oO-9V; Fri, 30 Apr 2004 09:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJY2o-0000za-Kp for simple@optimus.ietf.org; Fri, 30 Apr 2004 09:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00740 for ; Fri, 30 Apr 2004 09:27:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJY2m-0000Yu-Ua for simple@ietf.org; Fri, 30 Apr 2004 09:27:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJY1r-0000Md-00 for simple@ietf.org; Fri, 30 Apr 2004 09:26:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BJY0x-0007nF-00 for simple@ietf.org; Fri, 30 Apr 2004 09:25:15 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2004 06:26:05 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3UDOgYu022795; Fri, 30 Apr 2004 09:24:42 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIB27471; Fri, 30 Apr 2004 09:24:41 -0400 (EDT) Message-ID: <40925399.8090805@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Schmidt Christian CC: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: AW: AW: [Simple] WGLC: partial notification References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA00741 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:24:41 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'd like to hear what the cellular guys think of this. (Are you one of=20 them?) Paul Schmidt Christian wrote: > Hi Paul, >=20 > thank you for the comment. Concerning the tunnel case, it is a question= , how often this would > happen. If it is a rare case, perhaps we can ignore it. If not, we can = add a repetition option. >=20 > Modified proposal: > The notifier must not issue a NOTIFY (full or partial), before it recei= ves a 200 for the last issued NOTIFY (full or partial). After experation = of a timer t, the notifier should repeat the last message and if the time= r t expires a second time, send a full NOTIFY. >=20 > Regards, > Christian >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Freitag, 30. April 2004 14:48 > An: Schmidt Christian > Cc: 'hisham.khartabil@nokia.com'; rsparks@dynamicsoft.com; mikko.lonnfo= rs@nokia.com; simple@ietf.org > Betreff: Re: AW: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > Schmidt Christian wrote: >=20 >>Hi Hisham, >> >>this proposal would not solve the problem with a missing NOTIFY (full o= r partial).=20 >> >>What=B4s about the following proposal: >>The notifier must not issue a NOTIFY (full or partial), before it recei= ves a 200 for the last issued NOTIFY (full or partial). After experation = of a timer t, the notifier should send a full NOTIFY. >> >>This would also work without version number and would cover reordering = and packet loss cases. >=20 >=20 > This would work. I guess it is obvious that if the full notify also=20 > times out then further retries, if any, should also send full state. An= d=20 > that this should continue until there is success. A notify with partial= =20 > state could only happen after receiving a 2xx for the prior notify. >=20 > OTOH, this might be a bad choice for a bandwidth constrained device,=20 > like a cell phone. If you are driving thru a tunnel and can't receive=20 > for a few minutes, are going to be happy to get a full update when you=20 > emerge? >=20 > Paul >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 09:55:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01898 for ; Fri, 30 Apr 2004 09:55:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYTt-0003vj-Ur for simple-archive@ietf.org; Fri, 30 Apr 2004 09:55:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYT4-0003tW-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 09:54:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJYSO-0003qT-00; Fri, 30 Apr 2004 09:53:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYNw-0004N2-GU; Fri, 30 Apr 2004 09:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYJI-0003jc-Hx for simple@optimus.ietf.org; Fri, 30 Apr 2004 09:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01466 for ; Fri, 30 Apr 2004 09:44:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYJG-0003V0-LL for simple@ietf.org; Fri, 30 Apr 2004 09:44:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYIR-0003SY-00 for simple@ietf.org; Fri, 30 Apr 2004 09:43:20 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BJYI4-0003Ha-00 for simple@ietf.org; Fri, 30 Apr 2004 09:42:57 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3UDgCM01123; Fri, 30 Apr 2004 15:42:12 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i3UDgCZ21065; Fri, 30 Apr 2004 15:42:12 +0200 (MEST) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA25131; Fri, 30 Apr 2004 15:42:11 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 15:41:39 +0200 Message-ID: From: Schmidt Christian To: "'Paul Kyzivat'" Cc: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: AW: AW: [Simple] WGLC: partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 15:41:38 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Paul, I=B4m working on mobile networks and contacted some of our radio = experts. Traffic models in this area are quite difficult to get. But = here some ideas: - Situations, where connections are lost for several minutes are very = rare (Some tunnels in Austria). - Tunnel situations are usually more in a few 10s of seconds. - For a lost INVITE, INVITE and connection lost situation have to be in = the same period and seams to be at least rare. Perhaps that could help. Regards, Christian -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Freitag, 30. April 2004 15:25 An: Schmidt Christian Cc: 'hisham.khartabil@nokia.com'; rsparks@dynamicsoft.com; = mikko.lonnfors@nokia.com; simple@ietf.org Betreff: Re: AW: AW: [Simple] WGLC: partial notification I'd like to hear what the cellular guys think of this. (Are you one of=20 them?) Paul Schmidt Christian wrote: > Hi Paul, >=20 > thank you for the comment. Concerning the tunnel case, it is a = question, how often this would > happen. If it is a rare case, perhaps we can ignore it. If not, we = can add a repetition option. >=20 > Modified proposal: > The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should repeat the last message = and if the timer t expires a second time, send a full NOTIFY. >=20 > Regards, > Christian >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Freitag, 30. April 2004 14:48 > An: Schmidt Christian > Cc: 'hisham.khartabil@nokia.com'; rsparks@dynamicsoft.com; = mikko.lonnfors@nokia.com; simple@ietf.org > Betreff: Re: AW: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > Schmidt Christian wrote: >=20 >>Hi Hisham, >> >>this proposal would not solve the problem with a missing NOTIFY (full = or partial).=20 >> >>What=B4s about the following proposal: >>The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should send a full NOTIFY. >> >>This would also work without version number and would cover = reordering and packet loss cases. >=20 >=20 > This would work. I guess it is obvious that if the full notify also=20 > times out then further retries, if any, should also send full state. = And=20 > that this should continue until there is success. A notify with = partial=20 > state could only happen after receiving a 2xx for the prior notify. >=20 > OTOH, this might be a bad choice for a bandwidth constrained device,=20 > like a cell phone. If you are driving thru a tunnel and can't receive = > for a few minutes, are going to be happy to get a full update when = you=20 > emerge? >=20 > Paul >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 10:02:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02194 for ; Fri, 30 Apr 2004 10:02:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYZw-0006sT-Ff for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 10:01:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UE1OSu026431 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 10:01:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYTy-0005B5-2J for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01916 for ; Fri, 30 Apr 2004 09:55:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYTw-0003vw-5g for simple-web-archive@ietf.org; Fri, 30 Apr 2004 09:55:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYT5-0003te-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 09:54:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJYSO-0003qT-00; Fri, 30 Apr 2004 09:53:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYNw-0004N2-GU; Fri, 30 Apr 2004 09:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYJI-0003jc-Hx for simple@optimus.ietf.org; Fri, 30 Apr 2004 09:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01466 for ; Fri, 30 Apr 2004 09:44:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYJG-0003V0-LL for simple@ietf.org; Fri, 30 Apr 2004 09:44:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYIR-0003SY-00 for simple@ietf.org; Fri, 30 Apr 2004 09:43:20 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1BJYI4-0003Ha-00 for simple@ietf.org; Fri, 30 Apr 2004 09:42:57 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i3UDgCM01123; Fri, 30 Apr 2004 15:42:12 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i3UDgCZ21065; Fri, 30 Apr 2004 15:42:12 +0200 (MEST) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA25131; Fri, 30 Apr 2004 15:42:11 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 15:41:39 +0200 Message-ID: From: Schmidt Christian To: "'Paul Kyzivat'" Cc: "'hisham.khartabil@nokia.com'" , rsparks@dynamicsoft.com, mikko.lonnfors@nokia.com, simple@ietf.org Subject: AW: AW: AW: [Simple] WGLC: partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 15:41:38 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Paul, I=B4m working on mobile networks and contacted some of our radio = experts. Traffic models in this area are quite difficult to get. But = here some ideas: - Situations, where connections are lost for several minutes are very = rare (Some tunnels in Austria). - Tunnel situations are usually more in a few 10s of seconds. - For a lost INVITE, INVITE and connection lost situation have to be in = the same period and seams to be at least rare. Perhaps that could help. Regards, Christian -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Freitag, 30. April 2004 15:25 An: Schmidt Christian Cc: 'hisham.khartabil@nokia.com'; rsparks@dynamicsoft.com; = mikko.lonnfors@nokia.com; simple@ietf.org Betreff: Re: AW: AW: [Simple] WGLC: partial notification I'd like to hear what the cellular guys think of this. (Are you one of=20 them?) Paul Schmidt Christian wrote: > Hi Paul, >=20 > thank you for the comment. Concerning the tunnel case, it is a = question, how often this would > happen. If it is a rare case, perhaps we can ignore it. If not, we = can add a repetition option. >=20 > Modified proposal: > The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should repeat the last message = and if the timer t expires a second time, send a full NOTIFY. >=20 > Regards, > Christian >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Freitag, 30. April 2004 14:48 > An: Schmidt Christian > Cc: 'hisham.khartabil@nokia.com'; rsparks@dynamicsoft.com; = mikko.lonnfors@nokia.com; simple@ietf.org > Betreff: Re: AW: [Simple] WGLC: partial notification >=20 >=20 >=20 >=20 > Schmidt Christian wrote: >=20 >>Hi Hisham, >> >>this proposal would not solve the problem with a missing NOTIFY (full = or partial).=20 >> >>What=B4s about the following proposal: >>The notifier must not issue a NOTIFY (full or partial), before it = receives a 200 for the last issued NOTIFY (full or partial). After = experation of a timer t, the notifier should send a full NOTIFY. >> >>This would also work without version number and would cover = reordering and packet loss cases. >=20 >=20 > This would work. I guess it is obvious that if the full notify also=20 > times out then further retries, if any, should also send full state. = And=20 > that this should continue until there is success. A notify with = partial=20 > state could only happen after receiving a 2xx for the prior notify. >=20 > OTOH, this might be a bad choice for a bandwidth constrained device,=20 > like a cell phone. If you are driving thru a tunnel and can't receive = > for a few minutes, are going to be happy to get a full update when = you=20 > emerge? >=20 > Paul >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 10:22:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04121 for ; Fri, 30 Apr 2004 10:22:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYtu-00053p-VE for simple-archive@ietf.org; Fri, 30 Apr 2004 10:22:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYsx-0004x3-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 10:21:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJYsg-0004vy-00; Fri, 30 Apr 2004 10:20:46 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJYsh-0001ue-2a; Fri, 30 Apr 2004 10:20:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYo6-0005YG-4j; Fri, 30 Apr 2004 10:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYgU-0002Qn-In for simple@optimus.ietf.org; Fri, 30 Apr 2004 10:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02886 for ; Fri, 30 Apr 2004 10:08:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYgS-0004WT-Fw for simple@ietf.org; Fri, 30 Apr 2004 10:08:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYfT-0004TM-00 for simple@ietf.org; Fri, 30 Apr 2004 10:07:08 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJYez-0004Qz-00 for simple@ietf.org; Fri, 30 Apr 2004 10:06:37 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3UE4v6r024931; Fri, 30 Apr 2004 09:04:58 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Paul Kyzivat , Mikko Lonnfors , simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017979F2@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979F2@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083333916.2164.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:05:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit We need to have a call about this I guess. Are you still in today? I'm available for the next hour, then out until Tuesday. Assuming we don't get to talk until then: Chair comment: This is in danger of going off the rails. The comments (Christians) are of a nature you'd expect for the first or second drop of an individual submission - fundamental assumptions are being questioned. RjS On Fri, 2004-04-30 at 01:27, hisham.khartabil@nokia.com wrote: > Ok, I also agree that overlapping partial NOTIFYs complicate things without benefit. I also would like to propose explicitly disallowing overlapping full state and partial. I.e. A notifier must not issue a partial state NOTIFY without first receiving the 200 for a full state NOTIFY. I believe the converse is also required: the notifier must not issue a full state NOTIFY before it receives a 200 for a partial state NOTIFY. > > With all there restrictions, we can do without the version attribute. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 29.April.2004 21:47 > > To: Robert Sparks > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > > (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: Re: [Simple] WGLC: partial notification > > > > > > > > > > Robert Sparks wrote: > > > Aside from that I'd like for you to think through this again > > > from viewpoints besides active attack (use a transient malfunction > > > of the application (above the layer that would screw up basic SIP)), > > > I'm ready to let this go as long as we have _a_ solid solution to > > > dealing with reordered/missing notifies. > > > > I'm not going to start down the path to speculation about how > > to recover > > from arbitrary malfunctions of an application. That is just plain > > impossible without some characterization of the kinds of malfunctions > > that are to be recovered from. > > > > > So, backing out a layer, lets look at my original question of > > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > > in this case. > > > > I don't see any compelling need to support overlapping > > partial notifies. > > It is very difficult to see how to make them work. > > > > I can imagine a case where there might be some motivation: I sent one > > notification and have had no response. But I already have a bunch of > > additional changes that you should know about. It might be > > advantageous > > to start sending them as soon as possible. But until you know > > the prior > > one has been handled it isn't safe to send the new one. > > > > > Why would you want to? What value would doing that bring? > > > > > > 3261 and even presence-10 left sending full-state presence > > > NOTIFYs open. We wouldn't be changing that. If an application > > > for some reason decided it needed to send a new full-state > > > notify while a partial-state notify was pending, it could. > > > So any of the arguments for allowing it from the 3261/presence-10 > > > are still satisfied. Can you see any use case where allowing > > > a server to send overlapping partial NOTIFYs is a good idea? > > > If not, disallowing it seems a powerful simplification. > > > > > > > I agree. > > > > Paul > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 10:38:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04877 for ; Fri, 30 Apr 2004 10:38:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYzo-0008Dn-RB for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 10:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UES8kb031603 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 10:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYty-0007E9-34 for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 10:22:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04129 for ; Fri, 30 Apr 2004 10:22:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYtv-00053w-LN for simple-web-archive@ietf.org; Fri, 30 Apr 2004 10:22:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYsy-0004xA-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 10:21:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJYsg-0004vy-00; Fri, 30 Apr 2004 10:20:46 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJYsh-0001ue-2a; Fri, 30 Apr 2004 10:20:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYo6-0005YG-4j; Fri, 30 Apr 2004 10:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYgU-0002Qn-In for simple@optimus.ietf.org; Fri, 30 Apr 2004 10:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02886 for ; Fri, 30 Apr 2004 10:08:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYgS-0004WT-Fw for simple@ietf.org; Fri, 30 Apr 2004 10:08:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYfT-0004TM-00 for simple@ietf.org; Fri, 30 Apr 2004 10:07:08 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJYez-0004Qz-00 for simple@ietf.org; Fri, 30 Apr 2004 10:06:37 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3UE4v6r024931; Fri, 30 Apr 2004 09:04:58 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Paul Kyzivat , Mikko Lonnfors , simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017979F2@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017979F2@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1083333916.2164.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:05:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We need to have a call about this I guess. Are you still in today? I'm available for the next hour, then out until Tuesday. Assuming we don't get to talk until then: Chair comment: This is in danger of going off the rails. The comments (Christians) are of a nature you'd expect for the first or second drop of an individual submission - fundamental assumptions are being questioned. RjS On Fri, 2004-04-30 at 01:27, hisham.khartabil@nokia.com wrote: > Ok, I also agree that overlapping partial NOTIFYs complicate things without benefit. I also would like to propose explicitly disallowing overlapping full state and partial. I.e. A notifier must not issue a partial state NOTIFY without first receiving the 200 for a full state NOTIFY. I believe the converse is also required: the notifier must not issue a full state NOTIFY before it receives a 200 for a partial state NOTIFY. > > With all there restrictions, we can do without the version attribute. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 29.April.2004 21:47 > > To: Robert Sparks > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > > (Nokia-NRC/Helsinki); simple@ietf.org > > Subject: Re: [Simple] WGLC: partial notification > > > > > > > > > > Robert Sparks wrote: > > > Aside from that I'd like for you to think through this again > > > from viewpoints besides active attack (use a transient malfunction > > > of the application (above the layer that would screw up basic SIP)), > > > I'm ready to let this go as long as we have _a_ solid solution to > > > dealing with reordered/missing notifies. > > > > I'm not going to start down the path to speculation about how > > to recover > > from arbitrary malfunctions of an application. That is just plain > > impossible without some characterization of the kinds of malfunctions > > that are to be recovered from. > > > > > So, backing out a layer, lets look at my original question of > > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > > in this case. > > > > I don't see any compelling need to support overlapping > > partial notifies. > > It is very difficult to see how to make them work. > > > > I can imagine a case where there might be some motivation: I sent one > > notification and have had no response. But I already have a bunch of > > additional changes that you should know about. It might be > > advantageous > > to start sending them as soon as possible. But until you know > > the prior > > one has been handled it isn't safe to send the new one. > > > > > Why would you want to? What value would doing that bring? > > > > > > 3261 and even presence-10 left sending full-state presence > > > NOTIFYs open. We wouldn't be changing that. If an application > > > for some reason decided it needed to send a new full-state > > > notify while a partial-state notify was pending, it could. > > > So any of the arguments for allowing it from the 3261/presence-10 > > > are still satisfied. Can you see any use case where allowing > > > a server to send overlapping partial NOTIFYs is a good idea? > > > If not, disallowing it seems a powerful simplification. > > > > > > > I agree. > > > > Paul > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 10:41:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05158 for ; Fri, 30 Apr 2004 10:41:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZCs-0005zr-PB for simple-archive@ietf.org; Fri, 30 Apr 2004 10:41:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZBq-0005s9-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 10:40:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJZAf-0005ja-00; Fri, 30 Apr 2004 10:39:21 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJYw3-00021R-C8; Fri, 30 Apr 2004 10:24:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYo9-0005ZT-O1; Fri, 30 Apr 2004 10:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYlC-0004JF-Ni for simple@optimus.ietf.org; Fri, 30 Apr 2004 10:13:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03375 for ; Fri, 30 Apr 2004 10:12:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYlA-0004gM-F5 for simple@ietf.org; Fri, 30 Apr 2004 10:13:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYkI-0004f1-00 for simple@ietf.org; Fri, 30 Apr 2004 10:12:07 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJYji-0004cG-00 for simple@ietf.org; Fri, 30 Apr 2004 10:11:30 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3UE9O6r024934; Fri, 30 Apr 2004 09:09:24 -0500 Subject: Re: AW: [Simple] WGLC: partial notification From: Robert Sparks To: Paul Kyzivat Cc: Schmidt Christian , "'hisham.khartabil@nokia.com'" , Mikko Lonnfors , simple@ietf.org In-Reply-To: <40924B12.6060000@cisco.com> References: <40924B12.6060000@cisco.com> Content-Type: text/plain; charset= Message-Id: <1083334183.2164.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dhcp177.dfw.dynamicsoft.com id i3UE9O6r024934 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:09:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I don't see what purpose an additional timer serves. If a NOTIFY transaction times out, the subscription is over. RjS On Fri, 2004-04-30 at 07:48, Paul Kyzivat wrote: > Schmidt Christian wrote: > > Hi Hisham, > >=20 > > this proposal would not solve the problem with a missing NOTIFY (full= or partial).=20 > >=20 > > What=C2=B4s about the following proposal: > > The notifier must not issue a NOTIFY (full or partial), before it rec= eives a 200 for the last issued NOTIFY (full or partial). After experatio= n of a timer t, the notifier should send a full NOTIFY. > >=20 > > This would also work without version number and would cover reorderin= g and packet loss cases. >=20 > This would work. I guess it is obvious that if the full notify also=20 > times out then further retries, if any, should also send full state. An= d=20 > that this should continue until there is success. A notify with partial= =20 > state could only happen after receiving a 2xx for the prior notify. >=20 > OTOH, this might be a bad choice for a bandwidth constrained device,=20 > like a cell phone. If you are driving thru a tunnel and can't receive=20 > for a few minutes, are going to be happy to get a full update when you=20 > emerge? >=20 > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 11:01:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06125 for ; Fri, 30 Apr 2004 11:01:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZVs-00072P-OE for simple-archive@ietf.org; Fri, 30 Apr 2004 11:01:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZUu-0006zW-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 11:00:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJZUW-0006wX-00; Fri, 30 Apr 2004 10:59:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZK1-0003E7-DD; Fri, 30 Apr 2004 10:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZ9R-0001Es-4I for simple@optimus.ietf.org; Fri, 30 Apr 2004 10:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04854 for ; Fri, 30 Apr 2004 10:38:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZ9O-0005f5-Hq for simple@ietf.org; Fri, 30 Apr 2004 10:38:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZ8Q-0005ch-00 for simple@ietf.org; Fri, 30 Apr 2004 10:37:03 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJZ7p-0005al-00 for simple@ietf.org; Fri, 30 Apr 2004 10:36:25 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3UEYS6r024950; Fri, 30 Apr 2004 09:34:29 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Paul Kyzivat , Mikko Lonnfors , simple@ietf.org In-Reply-To: <1083333916.2164.5.camel@localhost.localdomain> References: <2038BCC78B1AD641891A0D1AE133DBB7017979F2@esebe019.ntc.nokia.com> <1083333916.2164.5.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1083335687.2164.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:34:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit well - twice in one week - Guess its time to change email programs. My deep apologies to the list contributors, and particularly to Mikko and Christian. My statement below was to my co-chair. Treat it as if you overheard me speaking with him in the hallway. I was _NOT_ making an administrative statement to the group, and am chagrined to have sent it such that it could be misinterpreted as such. RjS On Fri, 2004-04-30 at 09:05, Robert Sparks wrote: > We need to have a call about this I guess. Are you still in today? > I'm available for the next hour, then out until Tuesday. > > Assuming we don't get to talk until then: > > Chair comment: This is in danger of going off the rails. The comments > (Christians) are of a nature you'd expect for the first or second > drop of an individual submission - fundamental assumptions are > being questioned. > > RjS > > On Fri, 2004-04-30 at 01:27, hisham.khartabil@nokia.com wrote: > > Ok, I also agree that overlapping partial NOTIFYs complicate things without benefit. I also would like to propose explicitly disallowing overlapping full state and partial. I.e. A notifier must not issue a partial state NOTIFY without first receiving the 200 for a full state NOTIFY. I believe the converse is also required: the notifier must not issue a full state NOTIFY before it receives a 200 for a partial state NOTIFY. > > > > With all there restrictions, we can do without the version attribute. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 29.April.2004 21:47 > > > To: Robert Sparks > > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > > > (Nokia-NRC/Helsinki); simple@ietf.org > > > Subject: Re: [Simple] WGLC: partial notification > > > > > > > > > > > > > > > Robert Sparks wrote: > > > > Aside from that I'd like for you to think through this again > > > > from viewpoints besides active attack (use a transient malfunction > > > > of the application (above the layer that would screw up basic SIP)), > > > > I'm ready to let this go as long as we have _a_ solid solution to > > > > dealing with reordered/missing notifies. > > > > > > I'm not going to start down the path to speculation about how > > > to recover > > > from arbitrary malfunctions of an application. That is just plain > > > impossible without some characterization of the kinds of malfunctions > > > that are to be recovered from. > > > > > > > So, backing out a layer, lets look at my original question of > > > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > > > in this case. > > > > > > I don't see any compelling need to support overlapping > > > partial notifies. > > > It is very difficult to see how to make them work. > > > > > > I can imagine a case where there might be some motivation: I sent one > > > notification and have had no response. But I already have a bunch of > > > additional changes that you should know about. It might be > > > advantageous > > > to start sending them as soon as possible. But until you know > > > the prior > > > one has been handled it isn't safe to send the new one. > > > > > > > Why would you want to? What value would doing that bring? > > > > > > > > 3261 and even presence-10 left sending full-state presence > > > > NOTIFYs open. We wouldn't be changing that. If an application > > > > for some reason decided it needed to send a new full-state > > > > notify while a partial-state notify was pending, it could. > > > > So any of the arguments for allowing it from the 3261/presence-10 > > > > are still satisfied. Can you see any use case where allowing > > > > a server to send overlapping partial NOTIFYs is a good idea? > > > > If not, disallowing it seems a powerful simplification. > > > > > > > > > > I agree. > > > > > > Paul > > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 11:01:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06150 for ; Fri, 30 Apr 2004 11:01:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZMz-0003Rf-Ra for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 10:52:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UEq5en013243 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 10:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZCv-0001gh-Ol for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 10:41:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05176 for ; Fri, 30 Apr 2004 10:41:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZCt-0005zx-Er for simple-web-archive@ietf.org; Fri, 30 Apr 2004 10:41:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZBq-0005sG-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 10:40:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJZAf-0005ja-00; Fri, 30 Apr 2004 10:39:21 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJYw3-00021R-C8; Fri, 30 Apr 2004 10:24:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYo9-0005ZT-O1; Fri, 30 Apr 2004 10:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYlC-0004JF-Ni for simple@optimus.ietf.org; Fri, 30 Apr 2004 10:13:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03375 for ; Fri, 30 Apr 2004 10:12:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYlA-0004gM-F5 for simple@ietf.org; Fri, 30 Apr 2004 10:13:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYkI-0004f1-00 for simple@ietf.org; Fri, 30 Apr 2004 10:12:07 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJYji-0004cG-00 for simple@ietf.org; Fri, 30 Apr 2004 10:11:30 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3UE9O6r024934; Fri, 30 Apr 2004 09:09:24 -0500 Subject: Re: AW: [Simple] WGLC: partial notification From: Robert Sparks To: Paul Kyzivat Cc: Schmidt Christian , "'hisham.khartabil@nokia.com'" , Mikko Lonnfors , simple@ietf.org In-Reply-To: <40924B12.6060000@cisco.com> References: <40924B12.6060000@cisco.com> Content-Type: text/plain; charset= Message-Id: <1083334183.2164.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dhcp177.dfw.dynamicsoft.com id i3UE9O6r024934 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:09:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I don't see what purpose an additional timer serves. If a NOTIFY transaction times out, the subscription is over. RjS On Fri, 2004-04-30 at 07:48, Paul Kyzivat wrote: > Schmidt Christian wrote: > > Hi Hisham, > >=20 > > this proposal would not solve the problem with a missing NOTIFY (full= or partial).=20 > >=20 > > What=C2=B4s about the following proposal: > > The notifier must not issue a NOTIFY (full or partial), before it rec= eives a 200 for the last issued NOTIFY (full or partial). After experatio= n of a timer t, the notifier should send a full NOTIFY. > >=20 > > This would also work without version number and would cover reorderin= g and packet loss cases. >=20 > This would work. I guess it is obvious that if the full notify also=20 > times out then further retries, if any, should also send full state. An= d=20 > that this should continue until there is success. A notify with partial= =20 > state could only happen after receiving a 2xx for the prior notify. >=20 > OTOH, this might be a bad choice for a bandwidth constrained device,=20 > like a cell phone. If you are driving thru a tunnel and can't receive=20 > for a few minutes, are going to be happy to get a full update when you=20 > emerge? >=20 > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 11:22:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08046 for ; Fri, 30 Apr 2004 11:22:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZdQ-0006ww-JE for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 11:09:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UF94v0026709 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 11:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZVw-0005LS-0C for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:01:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06143 for ; Fri, 30 Apr 2004 11:01:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZVt-00072U-DV for simple-web-archive@ietf.org; Fri, 30 Apr 2004 11:01:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZUv-0006zd-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 11:00:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJZUW-0006wX-00; Fri, 30 Apr 2004 10:59:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZK1-0003E7-DD; Fri, 30 Apr 2004 10:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZ9R-0001Es-4I for simple@optimus.ietf.org; Fri, 30 Apr 2004 10:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04854 for ; Fri, 30 Apr 2004 10:38:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZ9O-0005f5-Hq for simple@ietf.org; Fri, 30 Apr 2004 10:38:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZ8Q-0005ch-00 for simple@ietf.org; Fri, 30 Apr 2004 10:37:03 -0400 Received: from [63.110.3.177] (helo=dhcp177.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJZ7p-0005al-00 for simple@ietf.org; Fri, 30 Apr 2004 10:36:25 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dhcp177.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i3UEYS6r024950; Fri, 30 Apr 2004 09:34:29 -0500 Subject: RE: [Simple] WGLC: partial notification From: Robert Sparks To: Hisham Khartabil Cc: Paul Kyzivat , Mikko Lonnfors , simple@ietf.org In-Reply-To: <1083333916.2164.5.camel@localhost.localdomain> References: <2038BCC78B1AD641891A0D1AE133DBB7017979F2@esebe019.ntc.nokia.com> <1083333916.2164.5.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1083335687.2164.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 09:34:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit well - twice in one week - Guess its time to change email programs. My deep apologies to the list contributors, and particularly to Mikko and Christian. My statement below was to my co-chair. Treat it as if you overheard me speaking with him in the hallway. I was _NOT_ making an administrative statement to the group, and am chagrined to have sent it such that it could be misinterpreted as such. RjS On Fri, 2004-04-30 at 09:05, Robert Sparks wrote: > We need to have a call about this I guess. Are you still in today? > I'm available for the next hour, then out until Tuesday. > > Assuming we don't get to talk until then: > > Chair comment: This is in danger of going off the rails. The comments > (Christians) are of a nature you'd expect for the first or second > drop of an individual submission - fundamental assumptions are > being questioned. > > RjS > > On Fri, 2004-04-30 at 01:27, hisham.khartabil@nokia.com wrote: > > Ok, I also agree that overlapping partial NOTIFYs complicate things without benefit. I also would like to propose explicitly disallowing overlapping full state and partial. I.e. A notifier must not issue a partial state NOTIFY without first receiving the 200 for a full state NOTIFY. I believe the converse is also required: the notifier must not issue a full state NOTIFY before it receives a 200 for a partial state NOTIFY. > > > > With all there restrictions, we can do without the version attribute. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 29.April.2004 21:47 > > > To: Robert Sparks > > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko > > > (Nokia-NRC/Helsinki); simple@ietf.org > > > Subject: Re: [Simple] WGLC: partial notification > > > > > > > > > > > > > > > Robert Sparks wrote: > > > > Aside from that I'd like for you to think through this again > > > > from viewpoints besides active attack (use a transient malfunction > > > > of the application (above the layer that would screw up basic SIP)), > > > > I'm ready to let this go as long as we have _a_ solid solution to > > > > dealing with reordered/missing notifies. > > > > > > I'm not going to start down the path to speculation about how > > > to recover > > > from arbitrary malfunctions of an application. That is just plain > > > impossible without some characterization of the kinds of malfunctions > > > that are to be recovered from. > > > > > > > So, backing out a layer, lets look at my original question of > > > > whether or not we allow overlapping ->partial<- NOTIFYs at all > > > > in this case. > > > > > > I don't see any compelling need to support overlapping > > > partial notifies. > > > It is very difficult to see how to make them work. > > > > > > I can imagine a case where there might be some motivation: I sent one > > > notification and have had no response. But I already have a bunch of > > > additional changes that you should know about. It might be > > > advantageous > > > to start sending them as soon as possible. But until you know > > > the prior > > > one has been handled it isn't safe to send the new one. > > > > > > > Why would you want to? What value would doing that bring? > > > > > > > > 3261 and even presence-10 left sending full-state presence > > > > NOTIFYs open. We wouldn't be changing that. If an application > > > > for some reason decided it needed to send a new full-state > > > > notify while a partial-state notify was pending, it could. > > > > So any of the arguments for allowing it from the 3261/presence-10 > > > > are still satisfied. Can you see any use case where allowing > > > > a server to send overlapping partial NOTIFYs is a good idea? > > > > If not, disallowing it seems a powerful simplification. > > > > > > > > > > I agree. > > > > > > Paul > > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 15:47:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26638 for ; Fri, 30 Apr 2004 15:47:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdym-0006lW-FQ for simple-archive@ietf.org; Fri, 30 Apr 2004 15:47:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdxp-0006cs-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 15:46:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJdwk-0006TI-00; Fri, 30 Apr 2004 15:45:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdnn-0004Xd-DT; Fri, 30 Apr 2004 15:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdcO-00028F-Q6 for simple@optimus.ietf.org; Fri, 30 Apr 2004 15:24:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24763 for ; Fri, 30 Apr 2004 15:24:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdcN-0004UX-Fu for simple@ietf.org; Fri, 30 Apr 2004 15:24:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdbT-0004Qd-00 for simple@ietf.org; Fri, 30 Apr 2004 15:23:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJdai-0004Ht-00 for simple@ietf.org; Fri, 30 Apr 2004 15:22:32 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3UJMLus021750 for ; Fri, 30 Apr 2004 15:22:21 -0400 (EDT) Message-ID: <4092A750.3080501@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Update to xcap authorization rules Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 15:21:52 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to the presence authorization policies specification. Until it appears in the archives, you can grab a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-00.txt There are a number of changes, based primarily on list discussions on this document. If you have comments on any of these, please do each in a separate thread and change the subject: * The new semantic based transformations I had proposed on the list, and which were discussed, are now in the document and replace the previous syntactic based transformations. I believe we had good consensus to do this, but there were open issues around several points; see below. * Markus had raised some issues about how "view" transformation would work (recall that this transformation allowed the presentity to say whether or not the document that is produced provides a presentity view, service view, or device view). The issue was whether there was really a strict privacy order; could I possibly have permissions that allow more than one of these? I think that Markus is right, that there is not really a strict privacy ordering here. Given that, and given that we still have work to do in order to agree on what these views mean, I've removed this feature entirely for now. I'd like to try to do something here, and will send a separate note on this issue. * The names of the permissions were changed to "provide-X" where X is the corresponding RPID element whose permission is granted. Its not strictly needed, since the namespace qualifier will differentiate, but it helps during the discussions in the text. * Formerly, each of the permissions granted access to an rpid type, and allowed you to indicate which tuple, identified by class, it was included in. There were several problems here. One, identified by Markus, is the lack of a short-hand for saying "tuples of all classes". Another problem is that it only allowed usage of the "class" attribute as a means for selecting which tuples to include it in. I have figured out how to extend this to a bunch of different selectors, and have included ones for class, placetype, privacy, relationship, sphere and contact-type. This is done by defining all of the provide-foo elements as sets, rather than boolean, and the set members identify the tuple-selector criteria by RIPD element name/value. So, for example, to include the placetype attribute in all tuples where placetype has a value of home OR the class is friend: home friend Since, according to the common-policy rules, composition of sets is done by union, the above is identical to: friend home which could appear in the same or separate permission documents. Its also possible to explicitly say "all-tuples". I don't have qualifiers for things like "all tuples that include any class", but these can easily be added under the set definition. If folks want to explicitly see something added, please comment. * A big concern raised by Markus and others was on supporting unknown presence attributes in the semantic model. The problem with doing that was overlap and intersection with other rules. I've addressed that. The spec now includes an "provide-unknown-status" element that has, as an attirbute, the qualified name of the unknown element for whom permissions are being defined. The spec explicitly says that these permissions apply only to elements for whom there is not otherwise a schema understood by the server which defines permissions. That eliminates the overlap problem, and allows us to define better authorization permissions for such things down the road, as needed. * I combined the various presence actions into one action - sub-handling, with values of allow, block, confirm and polite-block, as I proposed on the list. The default is "block". The spec is clear that this is always the lowest value, and the default, so inclusion of an action with the value of block is not needed in a document - its assumed. Its included only for completeness, since people like to see a formal "NO" I think. * Markus had raised an open issue around external lists as a means for identifying a group of users that would be referenced in an identity element. We concluded, I believe, to do this as a follow-on specification. I have not written that up right now, I'm focusing on getting the main document done. * Markus had raised an open issue around blacklisting, and the desired to say things like "allow everyone but Joe". We came to agreement that what Markus really meant was "allow subscriptions from domains in my trusted group of domains except for Joe". I had pointed out that you could achieve this by enumerating those domains. Given the ill-defined notion of "trusted group of domains" and the potential for information leakage that this entails, for now, I'd rather stick with what we have, which allows enumerated domains. * Markus had raised an open issue about providing different information to different groups of watchers, and how would that be supported. We had some interesting discussions on the fundamental model we were working with. I believe consensus was to not change the model, and as a result, you can provide different infomration to different watchers by having the "raw" presence document include both sets of information, and defining permissions that grant access to different parts of that document for different watchers. If you should mess up, it is possible that a user gets conflicting information. I have argued that this can happen in many cases, and there is not much we can do about it. As such, I have not changed anything to address this issue. Please comment if there are still concerns. * Added a section on schema extensibility, and how that is done. This has come up as an IESG concern on other XML drafts I'm involved in, so I figure we should address it up front. Please take a look. * removed usage and references to draft-ietf-sip-identiy and aib-body; replaced with some generic text on extracting username and host parts in future specifications. I'm concerned about the normative dependency that more specific text would introduce. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 15:55:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27076 for ; Fri, 30 Apr 2004 15:55:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJe6K-0007Ta-HG for simple-archive@ietf.org; Fri, 30 Apr 2004 15:55:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJe5N-0007OV-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 15:54:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJe4Z-0007JA-00; Fri, 30 Apr 2004 15:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdpl-0005CD-Mw; Fri, 30 Apr 2004 15:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdkI-0003cU-QI for simple@optimus.ietf.org; Fri, 30 Apr 2004 15:32:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25140 for ; Fri, 30 Apr 2004 15:32:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdkH-00054J-DK for simple@ietf.org; Fri, 30 Apr 2004 15:32:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdjR-0004zG-00 for simple@ietf.org; Fri, 30 Apr 2004 15:31:33 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJdir-0004tN-00 for simple@ietf.org; Fri, 30 Apr 2004 15:30:57 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3UJUlus021760 for ; Fri, 30 Apr 2004 15:30:47 -0400 (EDT) Message-ID: <4092A94B.5000302@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Presence Rules Issue 1: Provide Contact URI defaults Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 15:30:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit There is currently a permission called provide-contact-uri that specifies which tuples the contact-uri should be provided in. Like many of the other permissions, you can specify which tuples to include it in based on the values of a few other rpid parameters. The problem is that, for privacy safety, the default of all of these sets needs to be the empty set. As a result, the default will be that you never include a contact URI. If you want one in every tuple, you'd have to add this: in every permission statement. Or, you could turn it on "globally" by specifying a rule that applied to everyone (i.e., all domains you communicate with), which granted just this specific permission. There is also no way to say that the contact URI is to be provided in "barebones" tuples that have no other RPID information in them. My concern is that I think that, in practice, it will be expected that contact is nearly always provided, and so you'll have to have this permission pretty much all the time. The "real" default - in terms of what a user might expect - is not the same as the default of the permission itself. Our options are: 1. who cares, its fine, just add the permission 2. remove the provide-contact-uri permission, and always include a contact uri My proposal is (1). Thoughts? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 16:07:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27613 for ; Fri, 30 Apr 2004 16:07:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe6X-0003DX-RT for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 15:55:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UJtPC9012368 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 15:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdyp-00085A-2b for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 15:47:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26655 for ; Fri, 30 Apr 2004 15:47:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdyn-0006lb-Eq for simple-web-archive@ietf.org; Fri, 30 Apr 2004 15:47:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdxq-0006cz-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 15:46:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJdwk-0006TI-00; Fri, 30 Apr 2004 15:45:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdnn-0004Xd-DT; Fri, 30 Apr 2004 15:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdcO-00028F-Q6 for simple@optimus.ietf.org; Fri, 30 Apr 2004 15:24:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24763 for ; Fri, 30 Apr 2004 15:24:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdcN-0004UX-Fu for simple@ietf.org; Fri, 30 Apr 2004 15:24:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdbT-0004Qd-00 for simple@ietf.org; Fri, 30 Apr 2004 15:23:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJdai-0004Ht-00 for simple@ietf.org; Fri, 30 Apr 2004 15:22:32 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3UJMLus021750 for ; Fri, 30 Apr 2004 15:22:21 -0400 (EDT) Message-ID: <4092A750.3080501@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Update to xcap authorization rules Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 15:21:52 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to the presence authorization policies specification. Until it appears in the archives, you can grab a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-00.txt There are a number of changes, based primarily on list discussions on this document. If you have comments on any of these, please do each in a separate thread and change the subject: * The new semantic based transformations I had proposed on the list, and which were discussed, are now in the document and replace the previous syntactic based transformations. I believe we had good consensus to do this, but there were open issues around several points; see below. * Markus had raised some issues about how "view" transformation would work (recall that this transformation allowed the presentity to say whether or not the document that is produced provides a presentity view, service view, or device view). The issue was whether there was really a strict privacy order; could I possibly have permissions that allow more than one of these? I think that Markus is right, that there is not really a strict privacy ordering here. Given that, and given that we still have work to do in order to agree on what these views mean, I've removed this feature entirely for now. I'd like to try to do something here, and will send a separate note on this issue. * The names of the permissions were changed to "provide-X" where X is the corresponding RPID element whose permission is granted. Its not strictly needed, since the namespace qualifier will differentiate, but it helps during the discussions in the text. * Formerly, each of the permissions granted access to an rpid type, and allowed you to indicate which tuple, identified by class, it was included in. There were several problems here. One, identified by Markus, is the lack of a short-hand for saying "tuples of all classes". Another problem is that it only allowed usage of the "class" attribute as a means for selecting which tuples to include it in. I have figured out how to extend this to a bunch of different selectors, and have included ones for class, placetype, privacy, relationship, sphere and contact-type. This is done by defining all of the provide-foo elements as sets, rather than boolean, and the set members identify the tuple-selector criteria by RIPD element name/value. So, for example, to include the placetype attribute in all tuples where placetype has a value of home OR the class is friend: home friend Since, according to the common-policy rules, composition of sets is done by union, the above is identical to: friend home which could appear in the same or separate permission documents. Its also possible to explicitly say "all-tuples". I don't have qualifiers for things like "all tuples that include any class", but these can easily be added under the set definition. If folks want to explicitly see something added, please comment. * A big concern raised by Markus and others was on supporting unknown presence attributes in the semantic model. The problem with doing that was overlap and intersection with other rules. I've addressed that. The spec now includes an "provide-unknown-status" element that has, as an attirbute, the qualified name of the unknown element for whom permissions are being defined. The spec explicitly says that these permissions apply only to elements for whom there is not otherwise a schema understood by the server which defines permissions. That eliminates the overlap problem, and allows us to define better authorization permissions for such things down the road, as needed. * I combined the various presence actions into one action - sub-handling, with values of allow, block, confirm and polite-block, as I proposed on the list. The default is "block". The spec is clear that this is always the lowest value, and the default, so inclusion of an action with the value of block is not needed in a document - its assumed. Its included only for completeness, since people like to see a formal "NO" I think. * Markus had raised an open issue around external lists as a means for identifying a group of users that would be referenced in an identity element. We concluded, I believe, to do this as a follow-on specification. I have not written that up right now, I'm focusing on getting the main document done. * Markus had raised an open issue around blacklisting, and the desired to say things like "allow everyone but Joe". We came to agreement that what Markus really meant was "allow subscriptions from domains in my trusted group of domains except for Joe". I had pointed out that you could achieve this by enumerating those domains. Given the ill-defined notion of "trusted group of domains" and the potential for information leakage that this entails, for now, I'd rather stick with what we have, which allows enumerated domains. * Markus had raised an open issue about providing different information to different groups of watchers, and how would that be supported. We had some interesting discussions on the fundamental model we were working with. I believe consensus was to not change the model, and as a result, you can provide different infomration to different watchers by having the "raw" presence document include both sets of information, and defining permissions that grant access to different parts of that document for different watchers. If you should mess up, it is possible that a user gets conflicting information. I have argued that this can happen in many cases, and there is not much we can do about it. As such, I have not changed anything to address this issue. Please comment if there are still concerns. * Added a section on schema extensibility, and how that is done. This has come up as an IESG concern on other XML drafts I'm involved in, so I figure we should address it up front. Please take a look. * removed usage and references to draft-ietf-sip-identiy and aib-body; replaced with some generic text on extracting username and host parts in future specifications. I'm concerned about the normative dependency that more specific text would introduce. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 17:01:15 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02797 for ; Fri, 30 Apr 2004 17:01:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeI0-0004qL-0Y for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 16:07:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UK7FBJ018595 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 16:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe6M-0003Aq-Nj for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 15:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27094 for ; Fri, 30 Apr 2004 15:55:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJe6L-0007Tf-7X for simple-web-archive@ietf.org; Fri, 30 Apr 2004 15:55:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJe5N-0007Oc-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 15:54:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJe4Z-0007JA-00; Fri, 30 Apr 2004 15:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdpl-0005CD-Mw; Fri, 30 Apr 2004 15:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdkI-0003cU-QI for simple@optimus.ietf.org; Fri, 30 Apr 2004 15:32:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25140 for ; Fri, 30 Apr 2004 15:32:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdkH-00054J-DK for simple@ietf.org; Fri, 30 Apr 2004 15:32:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdjR-0004zG-00 for simple@ietf.org; Fri, 30 Apr 2004 15:31:33 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJdir-0004tN-00 for simple@ietf.org; Fri, 30 Apr 2004 15:30:57 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3UJUlus021760 for ; Fri, 30 Apr 2004 15:30:47 -0400 (EDT) Message-ID: <4092A94B.5000302@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Presence Rules Issue 1: Provide Contact URI defaults Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 15:30:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is currently a permission called provide-contact-uri that specifies which tuples the contact-uri should be provided in. Like many of the other permissions, you can specify which tuples to include it in based on the values of a few other rpid parameters. The problem is that, for privacy safety, the default of all of these sets needs to be the empty set. As a result, the default will be that you never include a contact URI. If you want one in every tuple, you'd have to add this: in every permission statement. Or, you could turn it on "globally" by specifying a rule that applied to everyone (i.e., all domains you communicate with), which granted just this specific permission. There is also no way to say that the contact URI is to be provided in "barebones" tuples that have no other RPID information in them. My concern is that I think that, in practice, it will be expected that contact is nearly always provided, and so you'll have to have this permission pretty much all the time. The "real" default - in terms of what a user might expect - is not the same as the default of the permission itself. Our options are: 1. who cares, its fine, just add the permission 2. remove the provide-contact-uri permission, and always include a contact uri My proposal is (1). Thoughts? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 17:22:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04579 for ; Fri, 30 Apr 2004 17:22:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfST-0003St-Ho for simple-archive@ietf.org; Fri, 30 Apr 2004 17:22:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfQi-00039v-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 17:20:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfNJ-0002hl-00; Fri, 30 Apr 2004 17:16:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf83-0004pX-M3; Fri, 30 Apr 2004 17:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeG6-0004cq-0y for simple@optimus.ietf.org; Fri, 30 Apr 2004 16:05:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27537 for ; Fri, 30 Apr 2004 16:05:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJeG4-0000TG-AP for simple@ietf.org; Fri, 30 Apr 2004 16:05:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJeF6-0000PI-00 for simple@ietf.org; Fri, 30 Apr 2004 16:04:17 -0400 Received: from web21502.mail.yahoo.com ([66.163.169.13]) by ietf-mx with smtp (Exim 4.12) id 1BJeES-0000LZ-00 for simple@ietf.org; Fri, 30 Apr 2004 16:03:36 -0400 Message-ID: <20040430200336.71828.qmail@web21502.mail.yahoo.com> Received: from [192.75.88.231] by web21502.mail.yahoo.com via HTTP; Fri, 30 Apr 2004 13:03:36 PDT From: Rajesh Karunamurthy To: simple@ietf.org Cc: hisham.khartabil@nokia.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1991554186-1083355416=:71325" Subject: [Simple] Filtering XSD Document Problem Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 13:03:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, REMOVE_IN_QUOTES autolearn=no version=2.60 --0-1991554186-1083355416=:71325 Content-Type: text/plain; charset=us-ascii Hi, I am using the latest draft " draft-ietf-simple-filter-format-00" for XML filtering. I took the XML Schema from the document and tried to validate it, which gave the error I specified in the last mail. For your reference I have copied the XML Schema in this mail. Please have a look and advice me if I am missing something. Thanks, Rajesh XML Schema for Filter Criteria: XML Schema Definition for Filter Criteria. --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs --0-1991554186-1083355416=:71325 Content-Type: text/html; charset=us-ascii
Hi,
 
I am using the latest draft " draft-ietf-simple-filter-format-00" for XML filtering.
 
I took the XML Schema from the document and tried to validate it, which gave the error I specified in the last mail.
 
For your reference I have copied the XML Schema in this mail.
 
Please have a look and advice me if I am missing something.
 
Thanks,
 
Rajesh
 
 XML Schema for Filter Criteria:
 
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
    xmlns="urn:ietf:params:xml:ns:simple-filter"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
       schemaLocation="http://www.w3.org/2001/xml.xsd"/>
    <xs:annotation>
      <xs:documentation xml:lang="en">
        XML Schema Definition for Filter Criteria.
      </xs:documentation>
    </xs:annotation>
    <xs:element name="filter-set" type="FilterSetType"/>
    <xs:complexType name="FilterSetType">
      <xs:sequence>
        <xs:element name="filter" type="FilterType"
                     minOccurs="1"    maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="package" type="xs:string" use="optional"/>
    </xs:complexType>
    <xs:complexType name="FilterType">
       <xs:sequence>
           <xs:element name="what" type="WhatType" minOccurs="0" maxOccurs="1"/>
           <xs:element name="trigger" type="TriggerType" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="id"  type="xs:string" use="required"/>
       <xs:attribute name="uri" type="xs:anyURI" use="optional"/>
       <xs:attribute name="remove" type="xs:boolean" default="false" use="optional"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
    </xs:complexType>
      <xs:complexType name="WhatType">
         <xs:sequence>
             <xs:element name="include" type="InclType" minOccurs="1" maxOccurs="unbounded"/>
             <xs:element name="exclude" type="ExclType" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
      </xs:complexType>
      <xs:complexType name="InclType">
         <xs:simpleContent>
          <xs:extension base="xs:string">
           <xs:attribute name="type" type="TypeType" default="xml-element" use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
          </xs:extension>
         </xs:simpleContent>
</xs:complexType>
      <xs:complexType name="ExclType">
         <xs:simpleContent>
          <xs:extension base="xs:string">
           <xs:attribute name="type" type="TypeType" default="xml-element" use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
          </xs:extension>
         </xs:simpleContent>
      </xs:complexType>
      <xs:simpleType name="TypeType">
         <xs:restriction base="xs:string">
     <xs:enumeration value="xml-element"/>
     <xs:enumeration value="namespace"/>
     <xs:enumeration value="token"/>
         </xs:restriction>
      </xs:simpleType>

    <xs:complexType name="TriggerType">
       <xs:sequence>
           <xs:element name="changed" type="ChangedType" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element name="added" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element name="removed" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
     <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
    </xs:complexType>
     <xs:complexType name="ChangedType">
        <xs:simpleContent>
            <xs:extension base="xs:string">
               <xs:attribute name="changed-from" type="xs:anySimpleType" use="optional"/>
               <xs:attribute name="changed-to" type="xs:anySimpleType" use="optional"/>
               <xs:attribute name="changed-by" type="xs:decimal" use="optional"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
            </xs:extension>
        </xs:simpleContent>
 !     </xs:complexType>
   </xs:schema>

Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs --0-1991554186-1083355416=:71325-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 17:37:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05881 for ; Fri, 30 Apr 2004 17:37:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfZL-0006D7-Px for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULTFdF023873 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfSX-0003bc-CQ for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:22:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04597 for ; Fri, 30 Apr 2004 17:22:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfSV-0003T3-1M for simple-web-archive@ietf.org; Fri, 30 Apr 2004 17:22:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfQk-0003AE-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 17:20:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfNJ-0002hl-00; Fri, 30 Apr 2004 17:16:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf83-0004pX-M3; Fri, 30 Apr 2004 17:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeG6-0004cq-0y for simple@optimus.ietf.org; Fri, 30 Apr 2004 16:05:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27537 for ; Fri, 30 Apr 2004 16:05:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJeG4-0000TG-AP for simple@ietf.org; Fri, 30 Apr 2004 16:05:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJeF6-0000PI-00 for simple@ietf.org; Fri, 30 Apr 2004 16:04:17 -0400 Received: from web21502.mail.yahoo.com ([66.163.169.13]) by ietf-mx with smtp (Exim 4.12) id 1BJeES-0000LZ-00 for simple@ietf.org; Fri, 30 Apr 2004 16:03:36 -0400 Message-ID: <20040430200336.71828.qmail@web21502.mail.yahoo.com> Received: from [192.75.88.231] by web21502.mail.yahoo.com via HTTP; Fri, 30 Apr 2004 13:03:36 PDT From: Rajesh Karunamurthy To: simple@ietf.org Cc: hisham.khartabil@nokia.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1991554186-1083355416=:71325" Subject: [Simple] Filtering XSD Document Problem Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 13:03:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, REMOVE_IN_QUOTES autolearn=no version=2.60 --0-1991554186-1083355416=:71325 Content-Type: text/plain; charset=us-ascii Hi, I am using the latest draft " draft-ietf-simple-filter-format-00" for XML filtering. I took the XML Schema from the document and tried to validate it, which gave the error I specified in the last mail. For your reference I have copied the XML Schema in this mail. Please have a look and advice me if I am missing something. Thanks, Rajesh XML Schema for Filter Criteria: XML Schema Definition for Filter Criteria. --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs --0-1991554186-1083355416=:71325 Content-Type: text/html; charset=us-ascii
Hi,
 
I am using the latest draft " draft-ietf-simple-filter-format-00" for XML filtering.
 
I took the XML Schema from the document and tried to validate it, which gave the error I specified in the last mail.
 
For your reference I have copied the XML Schema in this mail.
 
Please have a look and advice me if I am missing something.
 
Thanks,
 
Rajesh
 
 XML Schema for Filter Criteria:
 
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
    xmlns="urn:ietf:params:xml:ns:simple-filter"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
       schemaLocation="http://www.w3.org/2001/xml.xsd"/>
    <xs:annotation>
      <xs:documentation xml:lang="en">
        XML Schema Definition for Filter Criteria.
      </xs:documentation>
    </xs:annotation>
    <xs:element name="filter-set" type="FilterSetType"/>
    <xs:complexType name="FilterSetType">
      <xs:sequence>
        <xs:element name="filter" type="FilterType"
                     minOccurs="1"    maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="package" type="xs:string" use="optional"/>
    </xs:complexType>
    <xs:complexType name="FilterType">
       <xs:sequence>
           <xs:element name="what" type="WhatType" minOccurs="0" maxOccurs="1"/>
           <xs:element name="trigger" type="TriggerType" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="id"  type="xs:string" use="required"/>
       <xs:attribute name="uri" type="xs:anyURI" use="optional"/>
       <xs:attribute name="remove" type="xs:boolean" default="false" use="optional"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
    </xs:complexType>
      <xs:complexType name="WhatType">
         <xs:sequence>
             <xs:element name="include" type="InclType" minOccurs="1" maxOccurs="unbounded"/>
             <xs:element name="exclude" type="ExclType" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
      </xs:complexType>
      <xs:complexType name="InclType">
         <xs:simpleContent>
          <xs:extension base="xs:string">
           <xs:attribute name="type" type="TypeType" default="xml-element" use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
          </xs:extension>
         </xs:simpleContent>
</xs:complexType>
      <xs:complexType name="ExclType">
         <xs:simpleContent>
          <xs:extension base="xs:string">
           <xs:attribute name="type" type="TypeType" default="xml-element" use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
          </xs:extension>
         </xs:simpleContent>
      </xs:complexType>
      <xs:simpleType name="TypeType">
         <xs:restriction base="xs:string">
     <xs:enumeration value="xml-element"/>
     <xs:enumeration value="namespace"/>
     <xs:enumeration value="token"/>
         </xs:restriction>
      </xs:simpleType>

    <xs:complexType name="TriggerType">
       <xs:sequence>
           <xs:element name="changed" type="ChangedType" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element name="added" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element name="removed" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
     <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
    </xs:complexType>
     <xs:complexType name="ChangedType">
        <xs:simpleContent>
            <xs:extension base="xs:string">
               <xs:attribute name="changed-from" type="xs:anySimpleType" use="optional"/>
               <xs:attribute name="changed-to" type="xs:anySimpleType" use="optional"/>
               <xs:attribute name="changed-by" type="xs:decimal" use="optional"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
            </xs:extension>
        </xs:simpleContent>
 !     </xs:complexType>
   </xs:schema>

Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs --0-1991554186-1083355416=:71325-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Apr 30 17:48:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06816 for ; Fri, 30 Apr 2004 17:48:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfrp-0006ep-GP for simple-archive@ietf.org; Fri, 30 Apr 2004 17:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfr0-0006Zf-00 for simple-archive@ietf.org; Fri, 30 Apr 2004 17:47:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfqI-0006UY-00; Fri, 30 Apr 2004 17:46:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfmh-00026o-Hp; Fri, 30 Apr 2004 17:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfdH-0006vr-J7 for simple@optimus.ietf.org; Fri, 30 Apr 2004 17:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05464 for ; Fri, 30 Apr 2004 17:33:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfdF-0004uK-1F for simple@ietf.org; Fri, 30 Apr 2004 17:33:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfcI-0004pz-00 for simple@ietf.org; Fri, 30 Apr 2004 17:32:20 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1BJfbQ-0004ld-00 for simple@ietf.org; Fri, 30 Apr 2004 17:31:25 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i3ULQQrw019449 for ; Fri, 30 Apr 2004 16:26:26 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i3ULQOrw019418 for ; Fri, 30 Apr 2004 16:26:25 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42EFA.7BF6C2CC" Subject: RE: [Simple] Filtering XSD Document Problem Message-ID: <122C500C0A99244C831988096A4F0D5502A6C354@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] Filtering XSD Document Problem Thread-Index: AcQu+I8zv9sQ4tCfQja9kGrRYzqe9gAAbq5Q From: "Goud, Venkat Ramana (Venkat) ** CTR **" To: "Rajesh Karunamurthy" , Cc: Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 17:31:22 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,REMOVE_IN_QUOTES autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42EFA.7BF6C2CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is nothing wrong with the XSD. Your validator is not liking the = xsd:any element.=20 -Venkat -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of = Rajesh Karunamurthy Sent: Friday, April 30, 2004 4:04 PM To: simple@ietf.org Cc: hisham.khartabil@nokia.com Subject: [Simple] Filtering XSD Document Problem Hi, =20 I am using the latest draft " draft-ietf-simple-filter-format-00" for = XML filtering. =20 I took the XML Schema from the document and tried to validate it, which = gave the error I specified in the last mail. =20 For your reference I have copied the XML Schema in this mail. =20 Please have a look and advice me if I am missing something. =20 Thanks, =20 Rajesh =20 XML Schema for Filter Criteria: =20 > XML Schema Definition for Filter Criteria. ! _____ =20 Do you Yahoo!? Win = a $20,000 Career Makeover at Yahoo! HotJobs=20 ------_=_NextPart_001_01C42EFA.7BF6C2CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There=20 is nothing wrong with the XSD. Your validator is not liking the xsd:any = element.=20
-Venkat
-----Original Message-----
From: = simple-admin@ietf.org=20 [mailto:simple-admin@ietf.org]On Behalf Of Rajesh=20 Karunamurthy
Sent: Friday, April 30, 2004 4:04 = PM
To:=20 simple@ietf.org
Cc: = hisham.khartabil@nokia.com
Subject:=20 [Simple] Filtering XSD Document Problem

Hi,
 
I am using the latest draft " draft-ietf-simple-filter-format-00" = for XML=20 filtering.
 
I took the XML Schema from the document and tried to validate it, = which=20 gave the error I specified in the last mail.
 
For your reference I have copied the XML Schema in this = mail.
 
Please have a look and advice me if I am missing something.
 
Thanks,
 
Rajesh
 
 XML Schema for Filter Criteria:
 
<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<xs:schema = = targetNamespace=3D"urn:ietf:params:xml:ns:simple-filter"
   =  xmlns=3D"urn:ietf:params:xml:ns:simple-filter"
  =20  xmlns:xs=3D"http://www.w3.org/2001/XMLSchem= a">
    <xs:import namespace=3D"http://www.w3.org/XML/1998/= namespace"
  =20     schemaLocation=3D"http://www.w3.org/2001/xml.xsd"= />
    <xs:annotation>
   =   =20 <xs:documentation xml:lang=3D"en">
  =20      XML Schema Definition for Filter=20 Criteria.
     =20 </xs:documentation>
   =  </xs:annotation>
    <xs:element name=3D"filter-set"=20 type=3D"FilterSetType"/>
    <xs:complexType=20 name=3D"FilterSetType">
     =20 <xs:sequence>
        = <xs:element=20 name=3D"filter" type=3D"FilterType"
  =20 =             &= nbsp;    =20 minOccurs=3D"1"    = maxOccurs=3D"unbounded"/>
  =20    </xs:sequence>
     =20 <xs:attribute name=3D"package" type=3D"xs:string"=20 use=3D"optional"/>
   =  </xs:complexType>
    <xs:complexType=20 name=3D"FilterType">
      =20 <xs:sequence>
   =        =20 <xs:element name=3D"what" type=3D"WhatType" minOccurs=3D"0"=20 maxOccurs=3D"1"/>
   =        =20 <xs:element name=3D"trigger" type=3D"TriggerType" minOccurs=3D"0"=20 maxOccurs=3D"unbounded"/>
      =20 </xs:sequence>
       = <xs:attribute=20 name=3D"id"  type=3D"xs:string" = use=3D"required"/>
  =20     <xs:attribute name=3D"uri" type=3D"xs:anyURI"=20 use=3D"optional"/>
       = <xs:attribute=20 name=3D"remove" type=3D"xs:boolean" default=3D"false"=20 use=3D"optional"/>
       = <xs:anyAttribute=20 namespace=3D"##other" processContents=3D"lax"/>
  =20  </xs:complexType>
      <xs:complexType=20 = name=3D"WhatType">
        = =20 = <xs:sequence>
        &n= bsp;   =20 <xs:element name=3D"include" type=3D"InclType" minOccurs=3D"1"=20 = maxOccurs=3D"unbounded"/>
       = ;     =20 <xs:element name=3D"exclude" type=3D"ExclType" minOccurs=3D"0"=20 = maxOccurs=3D"unbounded"/>
       = ; =20 </xs:sequence>
     =20 </xs:complexType>
      <xs:complexType=20 = name=3D"InclType">
        = =20 = <xs:simpleContent>
       &nb= sp; =20 <xs:extension base=3D"xs:string">
  =20         <xs:attribute = name=3D"type"=20 type=3D"TypeType" default=3D"xml-element" = use=3D"optional"/>
  =20         <xs:anyAttribute=20 namespace=3D"##other"=20 = processContents=3D"lax"/>
       = ;  =20 = </xs:extension>
        = =20 </xs:simpleContent>
</xs:complexType>
      <xs:complexType=20 = name=3D"ExclType">
        = =20 = <xs:simpleContent>
       &nb= sp; =20 <xs:extension base=3D"xs:string">
  =20         <xs:attribute = name=3D"type"=20 type=3D"TypeType" default=3D"xml-element" = use=3D"optional"/>
  =20         <xs:anyAttribute=20 namespace=3D"##other"=20 = processContents=3D"lax"/>
       = ;  =20 = </xs:extension>
        = =20 </xs:simpleContent>
     =20 </xs:complexType>
      <xs:simpleType=20 = name=3D"TypeType">
        = =20 <xs:restriction base=3D"xs:string">
  =20   <xs:enumeration = value=3D"xml-element"/>
  =20   <xs:enumeration = value=3D"namespace"/>
  =20   <xs:enumeration=20 = value=3D"token"/>
         = </xs:restriction>
     =20 </xs:simpleType>

    <xs:complexType=20 name=3D"TriggerType">
      =20 <xs:sequence>
   =        =20 <xs:element name=3D"changed" type=3D"ChangedType" minOccurs=3D"0"=20 maxOccurs=3D"unbounded"/>
  =20         <xs:element = name=3D"added"=20 type=3D"xs:string" minOccurs=3D"0" = maxOccurs=3D"unbounded"/>
  =20         <xs:element = name=3D"removed"=20 type=3D"xs:string" minOccurs=3D"0" = maxOccurs=3D"unbounded"/>
  =20   <xs:any namespace=3D"##other" processContents=3D"lax" = minOccurs=3D"0"=20 maxOccurs=3D"unbounded"/>
      =20 </xs:sequence>
   =  </xs:complexType>
     <xs:complexType=20 name=3D"ChangedType">
       =20 <xs:simpleContent>
  =20          <xs:extension=20 base=3D"xs:string">
  =20            =20 <xs:attribute name=3D"changed-from" type=3D"xs:anySimpleType"=20 use=3D"optional"/>
  =20            =20 <xs:attribute name=3D"changed-to" type=3D"xs:anySimpleType"=20 use=3D"optional"/>
  =20            =20 <xs:attribute name=3D"changed-by" type=3D"xs:decimal"=20 use=3D"optional"/>
       =20 <xs:anyAttribute namespace=3D"##other"=20 processContents=3D"lax"/>
  =20         =20 </xs:extension>
       =20 </xs:simpleContent>
 !    =20 </xs:complexType>
   </xs:schema>

Do you Yahoo!?
Win=20 a $20,000 Career Makeover at Yahoo! HotJobs=20
------_=_NextPart_001_01C42EFA.7BF6C2CC-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Apr 30 18:03:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07549 for ; Fri, 30 Apr 2004 18:03:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJg2n-0005Yg-Dj for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 17:59:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULxfxd021344 for simple-archive@odin.ietf.org; Fri, 30 Apr 2004 17:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfru-0003Gd-2L for simple-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:48:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06834 for ; Fri, 30 Apr 2004 17:48:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfrr-0006fD-Gl for simple-web-archive@ietf.org; Fri, 30 Apr 2004 17:48:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfr1-0006Zs-00 for simple-web-archive@ietf.org; Fri, 30 Apr 2004 17:47:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfqI-0006UY-00; Fri, 30 Apr 2004 17:46:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfmh-00026o-Hp; Fri, 30 Apr 2004 17:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfdH-0006vr-J7 for simple@optimus.ietf.org; Fri, 30 Apr 2004 17:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05464 for ; Fri, 30 Apr 2004 17:33:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfdF-0004uK-1F for simple@ietf.org; Fri, 30 Apr 2004 17:33:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfcI-0004pz-00 for simple@ietf.org; Fri, 30 Apr 2004 17:32:20 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1BJfbQ-0004ld-00 for simple@ietf.org; Fri, 30 Apr 2004 17:31:25 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i3ULQQrw019449 for ; Fri, 30 Apr 2004 16:26:26 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i3ULQOrw019418 for ; Fri, 30 Apr 2004 16:26:25 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42EFA.7BF6C2CC" Subject: RE: [Simple] Filtering XSD Document Problem Message-ID: <122C500C0A99244C831988096A4F0D5502A6C354@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] Filtering XSD Document Problem Thread-Index: AcQu+I8zv9sQ4tCfQja9kGrRYzqe9gAAbq5Q From: "Goud, Venkat Ramana (Venkat) ** CTR **" To: "Rajesh Karunamurthy" , Cc: Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 17:31:22 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,REMOVE_IN_QUOTES autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42EFA.7BF6C2CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is nothing wrong with the XSD. Your validator is not liking the = xsd:any element.=20 -Venkat -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of = Rajesh Karunamurthy Sent: Friday, April 30, 2004 4:04 PM To: simple@ietf.org Cc: hisham.khartabil@nokia.com Subject: [Simple] Filtering XSD Document Problem Hi, =20 I am using the latest draft " draft-ietf-simple-filter-format-00" for = XML filtering. =20 I took the XML Schema from the document and tried to validate it, which = gave the error I specified in the last mail. =20 For your reference I have copied the XML Schema in this mail. =20 Please have a look and advice me if I am missing something. =20 Thanks, =20 Rajesh =20 XML Schema for Filter Criteria: =20 > XML Schema Definition for Filter Criteria. ! _____ =20 Do you Yahoo!? Win = a $20,000 Career Makeover at Yahoo! HotJobs=20 ------_=_NextPart_001_01C42EFA.7BF6C2CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There=20 is nothing wrong with the XSD. Your validator is not liking the xsd:any = element.=20
-Venkat
-----Original Message-----
From: = simple-admin@ietf.org=20 [mailto:simple-admin@ietf.org]On Behalf Of Rajesh=20 Karunamurthy
Sent: Friday, April 30, 2004 4:04 = PM
To:=20 simple@ietf.org
Cc: = hisham.khartabil@nokia.com
Subject:=20 [Simple] Filtering XSD Document Problem

Hi,
 
I am using the latest draft " draft-ietf-simple-filter-format-00" = for XML=20 filtering.
 
I took the XML Schema from the document and tried to validate it, = which=20 gave the error I specified in the last mail.
 
For your reference I have copied the XML Schema in this = mail.
 
Please have a look and advice me if I am missing something.
 
Thanks,
 
Rajesh
 
 XML Schema for Filter Criteria:
 
<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<xs:schema = = targetNamespace=3D"urn:ietf:params:xml:ns:simple-filter"
   =  xmlns=3D"urn:ietf:params:xml:ns:simple-filter"
  =20  xmlns:xs=3D"http://www.w3.org/2001/XMLSchem= a">
    <xs:import namespace=3D"http://www.w3.org/XML/1998/= namespace"
  =20     schemaLocation=3D"http://www.w3.org/2001/xml.xsd"= />
    <xs:annotation>
   =   =20 <xs:documentation xml:lang=3D"en">
  =20      XML Schema Definition for Filter=20 Criteria.
     =20 </xs:documentation>
   =  </xs:annotation>
    <xs:element name=3D"filter-set"=20 type=3D"FilterSetType"/>
    <xs:complexType=20 name=3D"FilterSetType">
     =20 <xs:sequence>
        = <xs:element=20 name=3D"filter" type=3D"FilterType"
  =20 =             &= nbsp;    =20 minOccurs=3D"1"    = maxOccurs=3D"unbounded"/>
  =20    </xs:sequence>
     =20 <xs:attribute name=3D"package" type=3D"xs:string"=20 use=3D"optional"/>
   =  </xs:complexType>
    <xs:complexType=20 name=3D"FilterType">
      =20 <xs:sequence>
   =        =20 <xs:element name=3D"what" type=3D"WhatType" minOccurs=3D"0"=20 maxOccurs=3D"1"/>
   =        =20 <xs:element name=3D"trigger" type=3D"TriggerType" minOccurs=3D"0"=20 maxOccurs=3D"unbounded"/>
      =20 </xs:sequence>
       = <xs:attribute=20 name=3D"id"  type=3D"xs:string" = use=3D"required"/>
  =20     <xs:attribute name=3D"uri" type=3D"xs:anyURI"=20 use=3D"optional"/>
       = <xs:attribute=20 name=3D"remove" type=3D"xs:boolean" default=3D"false"=20 use=3D"optional"/>
       = <xs:anyAttribute=20 namespace=3D"##other" processContents=3D"lax"/>
  =20  </xs:complexType>
      <xs:complexType=20 = name=3D"WhatType">
        = =20 = <xs:sequence>
        &n= bsp;   =20 <xs:element name=3D"include" type=3D"InclType" minOccurs=3D"1"=20 = maxOccurs=3D"unbounded"/>
       = ;     =20 <xs:element name=3D"exclude" type=3D"ExclType" minOccurs=3D"0"=20 = maxOccurs=3D"unbounded"/>
       = ; =20 </xs:sequence>
     =20 </xs:complexType>
      <xs:complexType=20 = name=3D"InclType">
        = =20 = <xs:simpleContent>
       &nb= sp; =20 <xs:extension base=3D"xs:string">
  =20         <xs:attribute = name=3D"type"=20 type=3D"TypeType" default=3D"xml-element" = use=3D"optional"/>
  =20         <xs:anyAttribute=20 namespace=3D"##other"=20 = processContents=3D"lax"/>
       = ;  =20 = </xs:extension>
        = =20 </xs:simpleContent>
</xs:complexType>
      <xs:complexType=20 = name=3D"ExclType">
        = =20 = <xs:simpleContent>
       &nb= sp; =20 <xs:extension base=3D"xs:string">
  =20         <xs:attribute = name=3D"type"=20 type=3D"TypeType" default=3D"xml-element" = use=3D"optional"/>
  =20         <xs:anyAttribute=20 namespace=3D"##other"=20 = processContents=3D"lax"/>
       = ;  =20 = </xs:extension>
        = =20 </xs:simpleContent>
     =20 </xs:complexType>
      <xs:simpleType=20 = name=3D"TypeType">
        = =20 <xs:restriction base=3D"xs:string">
  =20   <xs:enumeration = value=3D"xml-element"/>
  =20   <xs:enumeration = value=3D"namespace"/>
  =20   <xs:enumeration=20 = value=3D"token"/>
         = </xs:restriction>
     =20 </xs:simpleType>

    <xs:complexType=20 name=3D"TriggerType">
      =20 <xs:sequence>
   =        =20 <xs:element name=3D"changed" type=3D"ChangedType" minOccurs=3D"0"=20 maxOccurs=3D"unbounded"/>
  =20         <xs:element = name=3D"added"=20 type=3D"xs:string" minOccurs=3D"0" = maxOccurs=3D"unbounded"/>
  =20         <xs:element = name=3D"removed"=20 type=3D"xs:string" minOccurs=3D"0" = maxOccurs=3D"unbounded"/>
  =20   <xs:any namespace=3D"##other" processContents=3D"lax" = minOccurs=3D"0"=20 maxOccurs=3D"unbounded"/>
      =20 </xs:sequence>
   =  </xs:complexType>
     <xs:complexType=20 name=3D"ChangedType">
       =20 <xs:simpleContent>
  =20          <xs:extension=20 base=3D"xs:string">
  =20            =20 <xs:attribute name=3D"changed-from" type=3D"xs:anySimpleType"=20 use=3D"optional"/>
  =20            =20 <xs:attribute name=3D"changed-to" type=3D"xs:anySimpleType"=20 use=3D"optional"/>
  =20            =20 <xs:attribute name=3D"changed-by" type=3D"xs:decimal"=20 use=3D"optional"/>
       =20 <xs:anyAttribute namespace=3D"##other"=20 processContents=3D"lax"/>
  =20         =20 </xs:extension>
       =20 </xs:simpleContent>
 !    =20 </xs:complexType>
   </xs:schema>

Do you Yahoo!?
Win=20 a $20,000 Career Makeover at Yahoo! HotJobs=20
------_=_NextPart_001_01C42EFA.7BF6C2CC-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple