From simple-admin@mailman.dynamicsoft.com Sun Sep 1 05:04:26 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10365 for ; Sun, 1 Sep 2002 05:04:25 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8194sQm023713 for ; Sun, 1 Sep 2002 05:04:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26300 for ; Sun, 1 Sep 2002 05:05:28 -0400 (EDT) Date: Sun, 1 Sep 2002 05:05:28 -0400 (EDT) Message-Id: <200209010905.FAA26300@mailman.dynamicsoft.com> Subject: mailman.dynamicsoft.com mailing list memberships reminder From: mailman-owner@mailman.dynamicsoft.com To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk This is a reminder, sent out once a month, about your mailman.dynamicsoft.com 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@mailman.dynamicsoft.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.dynamicsoft.com. Thanks! Passwords for simple-archive@lists.ietf.org: List Password // URL ---- -------- simple@mailman.dynamicsoft.com ifheto http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org From simple-admin@mailman.dynamicsoft.com Mon Sep 2 04:17:40 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16549 for ; Mon, 2 Sep 2002 04:17:39 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g828HgKX000290; Mon, 2 Sep 2002 04:17:42 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00253; Mon, 2 Sep 2002 04:18:14 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00242 for ; Mon, 2 Sep 2002 04:17:39 -0400 (EDT) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/07/30/02) with ESMTP id RAA08542 for ; Mon, 2 Sep 2002 17:17:37 +0900 (JST) (envelope-from kawasaki.ayako@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g828HbRp015483 for ; Mon, 2 Sep 2002 17:17:37 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g828HaxH014414 for ; Mon, 2 Sep 2002 17:17:36 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA26685 for ; Mon, 2 Sep 2002 17:17:36 +0900 (JST) Received: from kawasaki by imh.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA13774 for ; Mon, 2 Sep 2002 17:17:35 +0900 (JST) From: Ayako Kawasaki To: simple@mailman.dynamicsoft.com Reply-To: kawasaki.ayako@lab.ntt.co.jp Message-Id: <20020902171020.6C2C.KAWASAKI.AYAKO@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.11 Subject: [Simple] question on winfo-package draft Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 02 Sep 2002 17:17:34 +0900 Content-Transfer-Encoding: 7bit Hi, I am now reading simple-winfo-package-02.txt draft. I have one very little question. On section 4.7, there is an abbreviation word "FSM". I couldn't figure out what this "FSM" stands for. Would anyone give me some comments on this? Thanks in advance. Ayako -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ayako Kawasaki NTT Network Service Systems Laboratories e-mail: kawasaki.ayako@lab.ntt.co.jp -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 2 04:31:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16727 for ; Mon, 2 Sep 2002 04:31:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g828VSKX000368; Mon, 2 Sep 2002 04:31:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00319; Mon, 2 Sep 2002 04:32:02 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00308 for ; Mon, 2 Sep 2002 04:31:13 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g828THA23151 for ; Mon, 2 Sep 2002 11:29:17 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Sep 2002 11:30:02 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Sep 2002 11:30:01 +0300 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" Subject: RE: [Simple] question on winfo-package draft Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2056F@esebe019.ntc.nokia.com> Thread-Topic: [Simple] question on winfo-package draft Thread-Index: AcJSWblZgKUXZkKLR0GEFjx01ElSXQAAScuQ To: , X-OriginalArrivalTime: 02 Sep 2002 08:30:01.0374 (UTC) FILETIME=[EE069BE0:01C2525A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA00308 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 2 Sep 2002 11:29:57 +0300 Content-Transfer-Encoding: 8bit Finite State Machine > -----Original Message----- > From: ext Ayako Kawasaki [mailto:kawasaki.ayako@lab.ntt.co.jp] > Sent: Monday, September 02, 2002 11:18 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] question on winfo-package draft > > > Hi, > > I am now reading simple-winfo-package-02.txt draft. > > I have one very little question. > On section 4.7, there is an abbreviation word "FSM". > I couldn't figure out what this "FSM" stands for. > > Would anyone give me some comments on this? > > > Thanks in advance. > Ayako > > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Ayako Kawasaki > NTT Network Service Systems Laboratories > e-mail: kawasaki.ayako@lab.ntt.co.jp > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 2 04:53:10 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17079 for ; Mon, 2 Sep 2002 04:53:09 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g828rTKX000466; Mon, 2 Sep 2002 04:53:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00413; Mon, 2 Sep 2002 04:54:03 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00402 for ; Mon, 2 Sep 2002 04:53:07 -0400 (EDT) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/07/30/02) with ESMTP id RAA15064 for ; Mon, 2 Sep 2002 17:53:06 +0900 (JST) (envelope-from kawasaki.ayako@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g828r5Rp017970 for ; Mon, 2 Sep 2002 17:53:05 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g828r5xH020312 for ; Mon, 2 Sep 2002 17:53:05 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA29400 for ; Mon, 2 Sep 2002 17:53:04 +0900 (JST) Received: from kawasaki by imh.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA17040 for ; Mon, 2 Sep 2002 17:53:04 +0900 (JST) From: Ayako Kawasaki To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] question on winfo-package draft Reply-To: kawasaki.ayako@lab.ntt.co.jp In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7C2056F@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7C2056F@esebe019.ntc.nokia.com> Message-Id: <20020902175231.6C32.KAWASAKI.AYAKO@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.11 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 02 Sep 2002 17:53:02 +0900 Content-Transfer-Encoding: 7bit Thanks :-) On Mon, 2 Sep 2002 11:29:57 +0300 hisham.khartabil@nokia.com wrote: > Finite State Machine > > > -----Original Message----- > > From: ext Ayako Kawasaki [mailto:kawasaki.ayako@lab.ntt.co.jp] > > Sent: Monday, September 02, 2002 11:18 AM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] question on winfo-package draft > > > > > > Hi, > > > > I am now reading simple-winfo-package-02.txt draft. > > > > I have one very little question. > > On section 4.7, there is an abbreviation word "FSM". > > I couldn't figure out what this "FSM" stands for. > > > > Would anyone give me some comments on this? > > > > > > Thanks in advance. > > Ayako > > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ayako Kawasaki NTT Network Service Systems Laboratories e-mail: kawasaki.ayako@lab.ntt.co.jp -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 08:49:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17406 for ; Thu, 5 Sep 2002 08:49:35 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g85CmpKX012156; Thu, 5 Sep 2002 08:48:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13362; Thu, 5 Sep 2002 08:49:08 -0400 (EDT) Received: from david.sae.siemens.com.sg (david.sae.siemens.com.sg [194.138.243.252]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13351 for ; Thu, 5 Sep 2002 08:48:21 -0400 (EDT) X-Envelope-Sender-Is: kokjeng.loh@siemens.com (at relayer david.sae.siemens.com.sg) Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14]) by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g85Cjvl07340 for ; Thu, 5 Sep 2002 20:45:57 +0800 (SGT) Received: from sgpk001a.sae.siemens.com.sg (sgpk001a.sae.siemens.com.sg [140.231.107.1]) by mail.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g85ClAX01696 for ; Thu, 5 Sep 2002 20:47:10 +0800 (SGT) Received: by sgpk001a.sae.siemens.com.sg with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Sep 2002 20:43:59 +0800 Message-ID: <7319EDDDE0CD7C458023FF64886CB17701DEFD82@sgpk001a.sae.siemens.com.sg> From: Loh Kok Jeng To: simple@mailman.dynamicsoft.com X-Mailer: Internet Mail Service (5.5.2655.55) Subject: [Simple] Overlapped MESSAGE transactions in chatting Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 5 Sep 2002 20:43:58 +0800 Dear all, In a chatting scenario where the UA sends MESSAGEs with the same Call-ID but with increasing CSeq in quick succession, how should a stateful proxy handle these MESSAGEs? The diagram below is an illustration of the scenario mentioned above: +----+ +-------+ | UA | | Proxy | +----+ +-------+ | | | MESSAGE 1 | |------------------>| | MESSAGE 2 | |------------------>| | MESSAGE 3 | |------------------>| | | In draft-ietf-sip-message-06.txt, Section 9., it is stated that: 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. UACs SHOULD NOT set the T1 timer value to less than 500 ms for MESSAGE transactions. UACs may use smaller T1 values if they know that that the next hop latency warrants it. The prohibition againt overlapping MESSAGE request provides some degree of congestion-safe behavior. A request and its associated response must each cross the full path between the UAC and the UAS. The time required for this will increase as networks become congested. This provides an adaptive mechanism to slow the introduction of new MESSAGE requests to the same destination. Does it mean that the UA must wait for a final response before sending the next MESSAGE? If so, should a stateful proxy drop the subsequent MESSAGEs before it receives a final response for the first MESSAGE? regards, KJ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 10:43:08 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21398 for ; Thu, 5 Sep 2002 10:43:08 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g85EhWKX012616; Thu, 5 Sep 2002 10:43:32 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13737; Thu, 5 Sep 2002 10:44:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13726 for ; Thu, 5 Sep 2002 10:43:43 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g85EhcYH016703; Thu, 5 Sep 2002 10:43:38 -0400 (EDT) Message-ID: <3D776D99.9060709@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loh Kok Jeng CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Overlapped MESSAGE transactions in chatting References: <7319EDDDE0CD7C458023FF64886CB17701DEFD82@sgpk001a.sae.siemens.com.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 05 Sep 2002 10:43:37 -0400 Content-Transfer-Encoding: 7bit inline. Loh Kok Jeng wrote: > Dear all, > > In a chatting scenario where the UA sends MESSAGEs with the same Call-ID but > with increasing CSeq in quick succession, how should a stateful proxy handle > these MESSAGEs? The proxy shouldn't provide any special handling. It should properly proxy all messages. This is the case for stateless and stateful proxies alike. It is not the role of the proxy to police the client to ensure they are consistent with the congestion control requirements in the specification. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 10:56:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21762 for ; Thu, 5 Sep 2002 10:56:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g85EuSKX012725; Thu, 5 Sep 2002 10:56:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13801; Thu, 5 Sep 2002 10:57:02 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13790 for ; Thu, 5 Sep 2002 10:56:52 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g85EulS5024031; Thu, 5 Sep 2002 10:56:47 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAQ29531; Thu, 5 Sep 2002 11:01:21 -0400 (EDT) Message-ID: <3D7770A3.73F04FEB@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "'hisham.khartabil@nokia.com'" , bateman@acm.org, simple@mailman.dynamicsoft.com References: <15A2739B7DAA624D8091C65981D7DA815EB151@stntexch2.va.neustar.com> <3D771E79.4010809@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Communication means in draft-ietf-impp-cpim-pidf-05 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 05 Sep 2002 10:56:35 -0400 Content-Transfer-Encoding: 7bit Moving discussion to the simple list... Jonathan Rosenberg wrote: > > I agree that, in the case of > SIP (although it really is more general), having extension attributes > that convey the information gleaned from things like caller preferences > (media types supported, for example) is a worthwhile goal. Indeed, such > an item is ALREADY on the charter of SIMPLE, and appears to be due this > month.... Hmm - is it: Goals and Milestones: ... SEP 02 Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard that you are referring to? Its good if the SIMPLE charter already covers this work. But as far as I know there hasn't yet been any work on this has there? Considering the amount of heat this subject has generated on the impp list, do we need to first develop a set of requirements for PIDF extensions in SIMPLE? My feeling is that a good start (and maybe finish) would be to reflect the callee capabilities, as defined in callerprefs, in PIDF. It has been discussed ad nauseum on impp why at least media capabilities are important. I don't know if we need to repeat that discussion here, or if we need to do it for each pref type in callerprefs. One advantage to agreeing on callerprefs is that maybe we can make a decision on the whole thing rather than considering each piece separately. Paul Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 11:42:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23147 for ; Thu, 5 Sep 2002 11:42:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g85FgVKX012977; Thu, 5 Sep 2002 11:42:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13953; Thu, 5 Sep 2002 11:43:04 -0400 (EDT) Received: from cmailm3.svr.pol.co.uk (cmailm3.svr.pol.co.uk [195.92.193.19]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13942 for ; Thu, 5 Sep 2002 11:42:46 -0400 (EDT) Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by cmailm3.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17mym5-0006P3-00; Thu, 05 Sep 2002 16:42:29 +0100 Received: from modem-2314.wolf.dialup.pol.co.uk ([81.76.137.10] helo=ADRIANXP) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17mylz-0001Ke-00; Thu, 05 Sep 2002 16:42:24 +0100 Reply-To: From: "Adrian Bateman" To: "'Paul Kyzivat'" , "'Jonathan Rosenberg'" Cc: "'Peterson, Jon'" , , Organization: VisionTech Limited MIME-Version: 1.0 Message-ID: <003d01c254f2$cbbee7a0$6405010a@ADRIANXP> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0038_01C254FB.29943B20" Importance: Normal In-Reply-To: <3D7770A3.73F04FEB@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 5 Sep 2002 16:42:03 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C254FB.29943B20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On 05 September 2002 15:56, Paul Kyzivat wrote: > Moving discussion to the simple list... > > Jonathan Rosenberg wrote: > > > > I agree that, in the case of > > SIP (although it really is more general), having extension > > attributes > > that convey the information gleaned from things like caller > > preferences (media types supported, for example) is a worthwhile goal. > > Indeed, such an item is ALREADY on the charter of SIMPLE, and appears > > to be due this month.... > > Hmm - is it: > > Goals and Milestones: > ... > SEP 02 Submission of SIMPLE PIDF profile to IESG for > publication as Proposed Standard > > that you are referring to? Its good if the SIMPLE charter already > covers this work. But as far as I know there hasn't yet been any work > on this has there? > > Considering the amount of heat this subject has generated on the impp > list, do we need to first develop a set of requirements for PIDF > extensions in SIMPLE? I seem to remember it having been discussed at length without conclusion here too, but for different reasons. In the past (and as result of passing on it for now in IMPP), there has been a desire to have a set of 'IM' status values beyond OPEN and CLOSED for things that people have been used to such as away, busy, etc. To my mind, the debate in the past always degenerated into a general discussion where people either tried to argue about the openness or closedness of particular states or they expanded the scope to start talking about SIP media types too. 'Degenerated' may be a bit harsh since some of those arguments are valid but didn't, I think, contribute to the particular discussion at hand: IM status values. I've tried to move that discussion along in the past by trying to talk about why IM status values are important and what purpose they will serve so now might be a good time to try to raise that again. For interop, PIDF says that for status value ranges that extend (i.e. they imply some OPEN or CLOSED value), the value must also be present. My suggestion for IM status values is to have a dictionary of values without necessitating an inherent OPEN/CLOSED property to avoid endless debate. As far as possible, values with the same semantics should be reduced to one word (e.g. if there is a consensus that 'away' and 'idle' are the same, then we only need one). But if there are objections, I see no major disadvantage with having a larger dictionary within reason (e.g. if there is no consensus that 'dnd' and 'busy' are the same, say, then they could both be included and some people will interpret them as the same and others as different). My reasoning for this is as follows. I believe that: * People will largely use the values for presentational purposes. * It is unlikely that there will be consensus about precise semantics for certain values and so people building automata to interpret the values will have to use some local policy logic anyway. * The ultimate fallback is the OPEN/CLOSED value that MUST be present. > My feeling is that a good start (and maybe finish) would be to reflect > the callee capabilities, as defined in callerprefs, in PIDF. It has > been discussed ad nauseum on impp why at least media capabilities are > important. I don't know if we need to repeat that discussion here, or > if we need to do it for each pref type in callerprefs. One advantage > to agreeing on callerprefs is that maybe we can make a decision on the > whole thing rather than considering each piece separately. I'm afraid I don't know enough to contribute meaningfully to the discussion regarding capabilities. However, I think these two cases can be done in parallel, and I hope that part of this work may help towards the documentation we'd like in IMPP for defining an extension to PIDF. Adrian. ------=_NextPart_000_0038_01C254FB.29943B20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAngw ggHhoAMCAQICAwfOcTANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAyMDcwMTIwMTI0M1oXDTAzMDcwMTIwMTI0M1owQTEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEeMBwGCSqGSIb3DQEJARYPYmF0ZW1hbkBhY20ub3JnMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDCBKe8lwUCrhtKabcZh1lrG7ZSeNf3JXcVr6kLZtkNmYUfLouB /sz5RaLkoiLaKXGMj0bXaPDo5XKJG+RydduRwvMvDl9CeU8IRRfCM68ECOTcFMQdf3JMxXtujXf9 Pkq5otwVpjIePufMkNqvT257Z+w2S9WisYxIkwXteyc4dwIDAQABoywwKjAaBgNVHREEEzARgQ9i YXRlbWFuQGFjbS5vcmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCw9gtsDshcl4Hb vu5P7VhTSsLpofXY3oyyDKYMynjM9RMWr250Cz3X38Y+5e3idgNvvfaQgvVEotdM5WCX9DqXO7VF TQHFXlDE1K0ZNtpTw954jWYOYX3WLkJjg/SNCO0WBdZYu4hSsMsgQwj7atYWmdjGILk4iJ7M3Hds 8M0tjDCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj 3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZKX+emibV ars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcN AQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umSc F6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLm nC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM4MIICoaADAgECAhBmRXK3zHT1z2N2RYTQLpEBMA0G CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKX DuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu 2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04w TDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgw BgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjA JhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiNMUIJ EWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggNp MIIDZQIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHznEwCQYFKw4D AhoFAKCCAiQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwOTA1 MTU0MjAzWjAjBgkqhkiG9w0BCQQxFgQURWNMg4k2tTHXNicIegG3rDUgaicwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwgasGCSsGAQQBgjcQBDGBnTCBmjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHznEwga0GCyqGSIb3DQEJEAILMYGd oIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl IFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAm BgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwfOcTANBgkqhkiG9w0BAQEF AASBgEOA8Yq6zBGKRR610Kev7Z1oRXHu4sFZYxNXYQFJonk29+GVQwDBKV/e0eKpkblV4dW8jHnT biy6tOr93MMfz6nbdEJ2xc6tEOTqlloplvBSrIpvqOFxb6M6qJ8CvRg9i14ZJQ2/jd7xQYWEJ7fg DTMzB1NvhT5V9g4iXUjkTq5uAAAAAAAA ------=_NextPart_000_0038_01C254FB.29943B20-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 12:32:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24688 for ; Thu, 5 Sep 2002 12:32:06 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g85GWTKX013264; Thu, 5 Sep 2002 12:32:30 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14177; Thu, 5 Sep 2002 12:33:04 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14162 for ; Thu, 5 Sep 2002 12:32:55 -0400 (EDT) From: krisztian.kiss@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g85GWu702207 for ; Thu, 5 Sep 2002 19:32:56 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Sep 2002 19:31:12 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Sep 2002 19:31:12 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Sep 2002 19:31:12 +0300 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" Subject: RE: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 Message-ID: Thread-Topic: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 Thread-Index: AcJU9DP3Aff9iBBKT/+4C5kZxh52PAAAM1Xg To: , , Cc: , , X-OriginalArrivalTime: 05 Sep 2002 16:31:12.0122 (UTC) FILETIME=[A59265A0:01C254F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA14162 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 5 Sep 2002 19:31:11 +0300 Content-Transfer-Encoding: 8bit Hi, > For interop, PIDF says that for status value ranges that > extend > (i.e. they imply some OPEN or CLOSED value), the > value must also > be present. My suggestion for IM status values is to have a dictionary > of values without necessitating an inherent OPEN/CLOSED property to > avoid endless debate. As far as possible, values with the > same semantics > should be reduced to one word (e.g. if there is a consensus > that 'away' > and 'idle' are the same, then we only need one). But if there are > objections, I see no major disadvantage with having a larger > dictionary > within reason (e.g. if there is no consensus that 'dnd' and 'busy' are > the same, say, then they could both be included and some people will > interpret them as the same and others as different). The reason why I initiated this thread on IMPP list was not to define 'away', 'idle', 'busy', etc. It was rather adding exact communication means to tuples (like 'voice', 'video', 'game', etc.), which goes beyond the contact's URI scheme. Currently if a tuple contains a contact, like: sip:someone@example.com its communication mean is 'sip:' which does not tell too much about the presentity's capabilities & willingness whether he/she wants to use this sip: contact for voice, video or chat. This might be a specific issue of SIP URIs, therefore it was proposed to move the discussion to this list. Paul also wrote a good summary about the issue on IMPP: > The sip uri explicitly does not say anything about the media > it supports. That is negotiated via the exchange of SDP. > > There is an ability when registering a contact address with a > sip registrar to specify capabilities of the addressed > endpoint, including the types of media it supports. But this > is represented as header parameters on the contact header > rather than as parameters of the sip url itself. > > In pidf, the equivalent functionality could be achieved by > either adding extra parameters to the element, or > by adding new values to the element. > > Of course one possibility is to simply say it is up to the > presence client to use the sip address from the contact, > together with some sip messaging to discover the current > capabilities of the endpoint. But that sounds like a very bad > idea to me - you are essentially back to polling all buddies > for presence information. I think it is important for the > presence document to be able to represent what media the > contact is prepared to use, so that can be displayed for the > end user. (I want to be able to see at a glance whether you > are present for IM or Voice, or both. Regards, Krisztian _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 13:30:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27541 for ; Thu, 5 Sep 2002 13:30:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g85HUTKX013622; Thu, 5 Sep 2002 13:30:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14377; Thu, 5 Sep 2002 13:31:03 -0400 (EDT) Received: from cmailm4.svr.pol.co.uk (cmailm4.svr.pol.co.uk [195.92.193.211]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14366 for ; Thu, 5 Sep 2002 13:30:54 -0400 (EDT) Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by cmailm4.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17n0Sr-0003ek-00; Thu, 05 Sep 2002 18:30:45 +0100 Received: from modem-1554.zebra.dialup.pol.co.uk ([81.76.150.18] helo=ADRIANXP) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17n0Sn-0000zp-00; Thu, 05 Sep 2002 18:30:42 +0100 Reply-To: From: "Adrian Bateman" To: , , Cc: Subject: RE: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 Organization: VisionTech Limited MIME-Version: 1.0 Message-ID: <005001c25501$ec399480$6405010a@ADRIANXP> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004B_01C2550A.4A59D3B0" Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 5 Sep 2002 18:30:20 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C2550A.4A59D3B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On 05 September 2002 17:31, krisztian.kiss@nokia.com wrote: > The reason why I initiated this thread on IMPP list was not to define > 'away', 'idle', 'busy', etc. It was rather adding exact communication > means to tuples (like 'voice', 'video', 'game', etc.), which goes beyond > the contact's URI scheme. Currently if a tuple contains a contact, like: > sip:someone@example.com > its communication mean is 'sip:' which does not tell too much about the > presentity's capabilities & willingness whether he/she wants to use this > sip: contact for voice, video or chat. This might be a specific issue of > SIP URIs, therefore it was proposed to move the discussion to this list. I appreciate that but my interpretation of SEP 02 Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard from past discussions was with the application of PIDF to IM (SIMPLE is also about IM over SIP is it not?). If media type is also a SIMPLE work item then I see no reason why the two very similar efforts can't be handled at the same time to help us move along. Adrian. ------=_NextPart_000_004B_01C2550A.4A59D3B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAngw ggHhoAMCAQICAwfOcTANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAyMDcwMTIwMTI0M1oXDTAzMDcwMTIwMTI0M1owQTEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEeMBwGCSqGSIb3DQEJARYPYmF0ZW1hbkBhY20ub3JnMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDCBKe8lwUCrhtKabcZh1lrG7ZSeNf3JXcVr6kLZtkNmYUfLouB /sz5RaLkoiLaKXGMj0bXaPDo5XKJG+RydduRwvMvDl9CeU8IRRfCM68ECOTcFMQdf3JMxXtujXf9 Pkq5otwVpjIePufMkNqvT257Z+w2S9WisYxIkwXteyc4dwIDAQABoywwKjAaBgNVHREEEzARgQ9i YXRlbWFuQGFjbS5vcmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCw9gtsDshcl4Hb vu5P7VhTSsLpofXY3oyyDKYMynjM9RMWr250Cz3X38Y+5e3idgNvvfaQgvVEotdM5WCX9DqXO7VF TQHFXlDE1K0ZNtpTw954jWYOYX3WLkJjg/SNCO0WBdZYu4hSsMsgQwj7atYWmdjGILk4iJ7M3Hds 8M0tjDCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj 3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZKX+emibV ars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcN AQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umSc F6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLm nC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM4MIICoaADAgECAhBmRXK3zHT1z2N2RYTQLpEBMA0G CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKX DuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu 2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04w TDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgw BgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjA JhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiNMUIJ EWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggNp MIIDZQIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHznEwCQYFKw4D AhoFAKCCAiQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwOTA1 MTczMDIwWjAjBgkqhkiG9w0BCQQxFgQU2V+uYYOkQFRZqtGirOyUdQbHwvowZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwgasGCSsGAQQBgjcQBDGBnTCBmjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHznEwga0GCyqGSIb3DQEJEAILMYGd oIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl IFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAm BgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwfOcTANBgkqhkiG9w0BAQEF AASBgE7LcK86Im4FHxNDl5cNrP9rhiRHrGs61ZppqXNEmrYOCIeIzP3Hex4fHPlPkdZ9FqhuVFzD Co8oi0SuagKcOrhET/7BcK9sgkMIqJcochCyu5qp3tPjTKbwLe32TCCPQLLoKLhA9R0xemsbcSYa h4Ou7tkKmcsNdReU4ALYFhPPAAAAAAAA ------=_NextPart_000_004B_01C2550A.4A59D3B0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 14:06:16 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29954 for ; Thu, 5 Sep 2002 14:06:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g85I6SKX013861; Thu, 5 Sep 2002 14:06:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14536; Thu, 5 Sep 2002 14:07:02 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14525 for ; Thu, 5 Sep 2002 14:06:05 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g85I5sip000630; Thu, 5 Sep 2002 14:05:55 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAQ31660; Thu, 5 Sep 2002 14:10:12 -0400 (EDT) Message-ID: <3D779CE5.AC475583@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bateman@acm.org CC: krisztian.kiss@nokia.com, jdrosen@dynamicsoft.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 References: <005001c25501$ec399480$6405010a@ADRIANXP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 05 Sep 2002 14:05:25 -0400 Content-Transfer-Encoding: 7bit Adrian Bateman wrote: > > I appreciate that but my interpretation of > > SEP 02 Submission of SIMPLE PIDF profile to IESG for > publication as Proposed Standard > > from past discussions was with the application of PIDF to IM (SIMPLE is > also about IM over SIP is it not?). If media type is also a SIMPLE work > item then I see no reason why the two very similar efforts can't be > handled at the same time to help us move along. I don't know if addressing media type, or perhaps more generally addressing the application of PIDF to SIP in all its glory, is covered by this or any other work item of SIMPLE. Based on the feedback in impp, this is deemed the appropriate place to address it. I defer a decision on whether this requires a new work item to those with more understanding of IETF procedures. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 14:20:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00603 for ; Thu, 5 Sep 2002 14:20:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g85IKRKX013995; Thu, 5 Sep 2002 14:20:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14607; Thu, 5 Sep 2002 14:21:02 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14596 for ; Thu, 5 Sep 2002 14:20:49 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g85IKnYH016922; Thu, 5 Sep 2002 14:20:49 -0400 (EDT) Message-ID: <3D77A080.4020906@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: bateman@acm.org, krisztian.kiss@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 05 Sep 2002 14:20:48 -0400 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > Adrian Bateman wrote: > >> I appreciate that but my interpretation of >> >> SEP 02 Submission of SIMPLE PIDF profile to IESG for publication >> as Proposed Standard >> >> from past discussions was with the application of PIDF to IM >> (SIMPLE is also about IM over SIP is it not?). If media type is >> also a SIMPLE work item then I see no reason why the two very >> similar efforts can't be handled at the same time to help us move >> along. > > > I don't know if addressing media type, or perhaps more generally > addressing the application of PIDF to SIP in all its glory, is > covered by this or any other work item of SIMPLE. Based on the > feedback in impp, this is deemed the appropriate place to address it. I think its reasonable to include it in the scope of the current work item. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 20:36:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12632 for ; Thu, 5 Sep 2002 20:36:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g860aVKX015439; Thu, 5 Sep 2002 20:36:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15678; Thu, 5 Sep 2002 20:37:03 -0400 (EDT) Received: from mailserver.sylantro.com ([65.200.90.207]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id UAA15667 for ; Thu, 5 Sep 2002 20:36:09 -0400 (EDT) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Thu, 05 Sep 2002 17:34:59 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1Y4A01XV>; Thu, 5 Sep 2002 17:34:59 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD014B477D@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'Sean Olson'" , "Fred O'Leary" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] draft-ietf-sipping-dialog-package-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 116927B950846-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 5 Sep 2002 17:34:58 -0700 Content-Transfer-Encoding: 7bit Wouldn't it be appropriate to add the "media" states to the dialog package as well? It could be thought of as the state of the dialog after all? For starters adding states like "Held", "Parked" ? Venkatesh -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: Friday, August 16, 2002 3:10 PM To: Fred O'Leary; simple@mailman.dynamicsoft.com Subject: Re: [Simple] draft-ietf-sipping-dialog-package-00.txt It sounds like there are at least three types of things you might be interested in: 1) The signaling state of SIP dialogs at an endpoint (the dialog package) 2) The signaling state of a conference composed of these dialogs (the conference package) 3) The state of the media associated with a particular session at a particular endpoint (also the conference package?) The last thing is the least defined of the three. You might also be interested in the draft on markup (wrt feature keys): http://search.ietf.org/internet-drafts/draft-rosenberg-sipping-markup-00.txt Sean Olson Microsoft --- Fred O'Leary wrote: > Hi, > draft-ietf-sipping-dialog-package-00.txt outlines > SIP events regards to call > dialogs. Does it make sense to include other call > states such as: > HOLD - Call is being held > CONFERENCING - Call is being conferenced > CONFERENCED - Call is now conferenced > PARKED - Call has been parked. > > Additionally would anyone know if any drafts cover > non-call related phone > states such as Feature key requests, Do-No-Disturb, > Off-hook etc? > > The reason I ask is that we have applications that > wish to monitor end-point > state as well as call state. > Thanks in advance. > > > > Fred O'Leary > MTS Sylantro Systems Corp. > (408)626-3040 > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 22:20:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14273 for ; Thu, 5 Sep 2002 22:20:11 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g862KSKX015686; Thu, 5 Sep 2002 22:20:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16008; Thu, 5 Sep 2002 22:21:02 -0400 (EDT) Received: from mta0 ([61.144.161.2]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15997 for ; Thu, 5 Sep 2002 22:20:45 -0400 (EDT) Received: from himanshoo (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H1Z00IWNVRHTZ@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Fri, 06 Sep 2002 10:18:55 +0800 (CST) From: Himanshoo Kumar Saxena To: Jonathan Rosenberg , Paul Kyzivat Cc: simple@mailman.dynamicsoft.com Reply-to: Himanshoo Kumar Saxena Message-id: <000c01c2554c$444a7140$7f984c0a@himanshoo> Organization: Hua Wei, LongGang , China MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_iD+O2+y+JzyOzd/GMoK5Ew)" X-Priority: 3 X-MSMail-priority: Normal References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com> Subject: [Simple] ungraceful shutdwon of presence clients Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 06 Sep 2002 10:22:36 +0800 This is a multi-part message in MIME format. --Boundary_(ID_iD+O2+y+JzyOzd/GMoK5Ew) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, A simple question to confirm my understanding... Consider subscriber A having REGISTERED via. REGISTER.. Now another subscriber B subscribes for A's presence information. Based on the duration in expires header field of A's subscription, till that time, A is considered online. In the meantime, A goes down ( I mean ungraceful shutdwon e.g. machine shutdown) But for presence server A is still online since the expires period hasn't yet ended. So if B tries to send a message to A , then presence server will send a SIP MESSAGE to A . Only upon expiry of response timeout to this MESSAGE request , the presence server will know that A is offline.... Is this understanding correct ? Regards ---------------------------------------------------------- Himanshoo Kumar Saxena IN service department Huawei Technologies Company Limited Shenzhen - 518000 P.R.China --Boundary_(ID_iD+O2+y+JzyOzd/GMoK5Ew) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
A simple question to confirm my understanding...
 
Consider subscriber A having REGISTERED via. REGISTER.. Now another subscriber B subscribes for A's presence information.
Based on the duration in expires header field of A's subscription, till that time, A is considered online. In the meantime, A goes down ( I mean ungraceful shutdwon e.g. machine shutdown) But for presence server A is still online since the expires period hasn't yet ended. So if B tries to send a message to A , then presence server will send a SIP MESSAGE to A . Only upon expiry of response timeout to this MESSAGE request , the presence server will know that A is offline....
Is this understanding correct ?
 
Regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Shenzhen - 518000
P.R.China
--Boundary_(ID_iD+O2+y+JzyOzd/GMoK5Ew)-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 22:36:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14800 for ; Thu, 5 Sep 2002 22:36:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g862aSKX015763; Thu, 5 Sep 2002 22:36:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16083; Thu, 5 Sep 2002 22:37:04 -0400 (EDT) Received: from mta0 ([61.144.161.2]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16072 for ; Thu, 5 Sep 2002 22:36:59 -0400 (EDT) Received: from himanshoo (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H1Z00JJWWIP65@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Fri, 06 Sep 2002 10:35:14 +0800 (CST) From: Himanshoo Kumar Saxena To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Reply-to: Himanshoo Kumar Saxena Message-id: <001301c2554e$8be2c5a0$7f984c0a@himanshoo> Organization: Hua Wei, LongGang , China MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_K0ogOK+byE1u8yVmm2y+EA)" X-Priority: 3 X-MSMail-priority: Normal References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com> Subject: [Simple] draft-rosenberg-impp-qauth-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 06 Sep 2002 10:38:55 +0800 This is a multi-part message in MIME format. --Boundary_(ID_K0ogOK+byE1u8yVmm2y+EA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, THis draft was supposed to expire on December 2000. Has it been updated or included in soem RFC. Is somebody updating this draft ? regards ---------------------------------------------------------- Himanshoo Kumar Saxena IN service department Huawei Technologies Company Limited Hua Dian R&D Center 4th floor, Long Gang District Shenzhen - 518000 P.R.China Ph: +86-755-28788478(Off) +86-755-28767187(Res) ----- Original Message ----- From: Jonathan Rosenberg To: Paul Kyzivat Cc: bateman@acm.org ; krisztian.kiss@nokia.com ; simple@mailman.dynamicsoft.com Sent: Friday, September 06, 2002 2:20 AM Subject: Re: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 Paul Kyzivat wrote: > > Adrian Bateman wrote: > >> I appreciate that but my interpretation of >> >> SEP 02 Submission of SIMPLE PIDF profile to IESG for publication >> as Proposed Standard >> >> from past discussions was with the application of PIDF to IM >> (SIMPLE is also about IM over SIP is it not?). If media type is >> also a SIMPLE work item then I see no reason why the two very >> similar efforts can't be handled at the same time to help us move >> along. > > > I don't know if addressing media type, or perhaps more generally > addressing the application of PIDF to SIP in all its glory, is > covered by this or any other work item of SIMPLE. Based on the > feedback in impp, this is deemed the appropriate place to address it. I think its reasonable to include it in the scope of the current work item. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple --Boundary_(ID_K0ogOK+byE1u8yVmm2y+EA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
THis draft was supposed to expire on December 2000. Has it been updated or included in soem RFC. Is somebody updating this draft ?
 
regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Hua Dian R&D Center
4th floor,
Long Gang District
Shenzhen - 518000
P.R.China
Ph: +86-755-28788478(Off)
       +86-755-28767187(Res)
----- Original Message -----
Sent: Friday, September 06, 2002 2:20 AM
Subject: Re: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05



Paul Kyzivat wrote:
 >
 > Adrian Bateman wrote:
 >
 >> I appreciate that but my interpretation of
 >>
 >> SEP 02  Submission of SIMPLE PIDF profile to IESG for publication
 >> as Proposed Standard
 >>
 >> from past discussions was with the application of PIDF to IM
 >> (SIMPLE is also about IM over SIP is it not?). If media type is
 >> also a SIMPLE work item then I see no reason why the two very
 >> similar efforts can't be handled at the same time to help us move
 >> along.
 >
 >
 > I don't know if addressing media type, or perhaps more generally
 > addressing the application of PIDF to SIP in all its glory, is
 > covered by this or any other work item of SIMPLE. Based on the
 > feedback in impp, this is deemed the appropriate place to address it.

I think its reasonable to include it in the scope of the current work item.

-Jonathan R.


--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple
--Boundary_(ID_K0ogOK+byE1u8yVmm2y+EA)-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 5 23:15:15 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15227 for ; Thu, 5 Sep 2002 23:15:15 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g863FRKX015927; Thu, 5 Sep 2002 23:15:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16241; Thu, 5 Sep 2002 23:16:03 -0400 (EDT) Received: from mta0 ([61.144.161.2]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16230 for ; Thu, 5 Sep 2002 23:15:49 -0400 (EDT) Received: from himanshoo (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H1Z00JN0YBE65@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Fri, 06 Sep 2002 11:14:04 +0800 (CST) From: Himanshoo Kumar Saxena To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Reply-to: Himanshoo Kumar Saxena Message-id: <001f01c25553$f8a080b0$7f984c0a@himanshoo> Organization: Hua Wei, LongGang , China MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_CYijeDd4YhDR2zrIBHlb8g)" X-Priority: 3 X-MSMail-priority: Normal References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com> <001301c2554e$8be2c5a0$7f984c0a@himanshoo> Subject: [Simple] (no subject) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 06 Sep 2002 11:17:45 +0800 This is a multi-part message in MIME format. --Boundary_(ID_CYijeDd4YhDR2zrIBHlb8g) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, If a user client wants to REGISTER but also wants to provide some additional information like user Nick Name etc. then how can it be done ? regards ---------------------------------------------------------- Himanshoo Kumar Saxena IN service department Huawei Technologies Company Limited Shenzhen - 518000 P.R.China --Boundary_(ID_CYijeDd4YhDR2zrIBHlb8g) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
If a user client wants to REGISTER but also wants to provide some additional information like user Nick Name etc. then how can it be done ?
 
regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Shenzhen - 518000
P.R.China
--Boundary_(ID_CYijeDd4YhDR2zrIBHlb8g)-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 6 02:40:08 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26879 for ; Fri, 6 Sep 2002 02:40:08 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g866eVKX016402; Fri, 6 Sep 2002 02:40:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16851; Fri, 6 Sep 2002 02:41:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16840 for ; Fri, 6 Sep 2002 02:40:22 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.47]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g866eEYH017382; Fri, 6 Sep 2002 02:40:17 -0400 (EDT) Message-ID: <3D784DCC.5030106@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Himanshoo Kumar Saxena CC: simple@mailman.dynamicsoft.com References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com> <001301c2554e$8be2c5a0$7f984c0a@himanshoo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-impp-qauth-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 06 Sep 2002 02:40:12 -0400 Content-Transfer-Encoding: 7bit This draft was abandoned long ago. The process of handling interactive authorization is through the watcherinfo specifications to inform the user that they need to make a decision: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-02.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-02.txt followed by a setting of authorization policy for them. That can be done through wap/web. An explicit protocol for manipulating authorization is now on our charter; the requirements for it are documented in: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt -Jonathan R. Himanshoo Kumar Saxena wrote: > Hi, > > THis draft was supposed to expire on December 2000. Has it been updated > or included in soem RFC. Is somebody updating this draft ? > > regards > ---------------------------------------------------------- > Himanshoo Kumar Saxena > IN service department > Huawei Technologies Company Limited > Hua Dian R&D Center > 4th floor, > Long Gang District > Shenzhen - 518000 > P.R.China > Ph: +86-755-28788478(Off) > +86-755-28767187(Res) > > ----- Original Message ----- > *From:* Jonathan Rosenberg > *To:* Paul Kyzivat > *Cc:* bateman@acm.org ; > krisztian.kiss@nokia.com ; > simple@mailman.dynamicsoft.com > *Sent:* Friday, September 06, 2002 2:20 AM > *Subject:* Re: [Simple] RE: Communication means in > draft-ietf-impp-cpim-pidf-05 > > > > Paul Kyzivat wrote: > > > > Adrian Bateman wrote: > > > >> I appreciate that but my interpretation of > >> > >> SEP 02 Submission of SIMPLE PIDF profile to IESG for publication > >> as Proposed Standard > >> > >> from past discussions was with the application of PIDF to IM > >> (SIMPLE is also about IM over SIP is it not?). If media type is > >> also a SIMPLE work item then I see no reason why the two very > >> similar efforts can't be handled at the same time to help us move > >> along. > > > > > > I don't know if addressing media type, or perhaps more generally > > addressing the application of PIDF to SIP in all its glory, is > > covered by this or any other work item of SIMPLE. Based on the > > feedback in impp, this is deemed the appropriate place to address it. > > I think its reasonable to include it in the scope of the current > work item. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com > FAX: (973) > 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 6 03:27:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27245 for ; Fri, 6 Sep 2002 03:27:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g867RTKX016558; Fri, 6 Sep 2002 03:27:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17028; Fri, 6 Sep 2002 03:28:02 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17017 for ; Fri, 6 Sep 2002 03:27:03 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g867R5714770 for ; Fri, 6 Sep 2002 10:27:06 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Sep 2002 10:27:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Sep 2002 10:27:01 +0300 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" Subject: RE: [Simple] ungraceful shutdwon of presence clients Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF10410E@esebe004.ntc.nokia.com> Thread-Topic: [Simple] ungraceful shutdwon of presence clients Thread-Index: AcJVTDtgEUuVC0amSI6RARHgSQu98wAJC8AA To: , , Cc: X-OriginalArrivalTime: 06 Sep 2002 07:27:01.0519 (UTC) FILETIME=[CAB581F0:01C25576] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA17017 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 6 Sep 2002 10:25:50 +0300 Content-Transfer-Encoding: 8bit Hi, Inline: -----Original Message----- From: ext Himanshoo Kumar Saxena [mailto:himanshooks@huawei.com] Sent: 06 September, 2002 05:23 To: Jonathan Rosenberg; Paul Kyzivat Cc: simple@mailman.dynamicsoft.com Subject: [Simple] ungraceful shutdwon of presence clients Hi, A simple question to confirm my understanding... Consider subscriber A having REGISTERED via. REGISTER.. Now another subscriber B subscribes for A's presence information. Based on the duration in expires header field of A's subscription, till that time, A is considered online. Yes, this can be done but it is presence system implementation issue. In the meantime, A goes down ( I mean ungraceful shutdwon e.g. machine shutdown) But for presence server A is still online since the expires period hasn't yet ended. SIP or SIMPLE do not in this case provide PS any means to detect that A has shutdown. You system might for example use some layer 2 mechanisms to detect that user A's device is not active anymore but that is again implementation issue. So if B tries to send a message to A , then presence server will send a SIP MESSAGE to A . Only upon expiry of response timeout to this MESSAGE request , the presence server will know that A is offline.... Probably the PS has nothing to do with the MESSAGE request (request is not routed through it). User B would send message straight to user A and would then notice that request times out. best regards - Mikko Is this understanding correct ? Regards ---------------------------------------------------------- Himanshoo Kumar Saxena IN service department Huawei Technologies Company Limited Shenzhen - 518000 P.R.China _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 6 10:05:19 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04439 for ; Fri, 6 Sep 2002 10:05:19 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g86E5cKX017460; Fri, 6 Sep 2002 10:05:38 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18201; Fri, 6 Sep 2002 10:06:07 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18189 for ; Fri, 6 Sep 2002 10:05:06 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g86E4J7p023385; Fri, 6 Sep 2002 10:04:21 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Sep 2002 09:04:53 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A640EC@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Himanshoo Kumar Saxena'" , Jonathan Rosenberg , Paul Kyzivat Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] ungraceful shutdwon of presence clients MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 6 Sep 2002 09:04:50 -0500 Yes. -----Original Message----- From: Himanshoo Kumar Saxena [mailto:himanshooks@huawei.com] Consider subscriber A having REGISTERED via. REGISTER.. Now another subscriber B subscribes for A's presence information. Based on the duration in expires header field of A's subscription, till that time, A is considered online. In the meantime, A goes down ( I mean ungraceful shutdwon e.g. machine shutdown) But for presence server A is still online since the expires period hasn't yet ended. So if B tries to send a message to A , then presence server will send a SIP MESSAGE to A . Only upon expiry of response timeout to this MESSAGE request , the presence server will know that A is offline.... Is this understanding correct ? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 6 10:41:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05580 for ; Fri, 6 Sep 2002 10:41:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g86EfSKX017660; Fri, 6 Sep 2002 10:41:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18336; Fri, 6 Sep 2002 10:42:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18325 for ; Fri, 6 Sep 2002 10:41:08 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.47]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g86Ef1YH017537; Fri, 6 Sep 2002 10:41:02 -0400 (EDT) Message-ID: <3D78BE7C.5020305@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: himanshooks@huawei.com, pkyzivat@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] ungraceful shutdwon of presence clients References: <0C1353ABB1DEB74DB067ADFF749C4EEF10410E@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 06 Sep 2002 10:41:00 -0400 Content-Transfer-Encoding: 7bit comments inline. mikko.lonnfors@nokia.com wrote: > Hi, > > Inline: > > -----Original Message----- From: ext Himanshoo Kumar Saxena > [mailto:himanshooks@huawei.com] Sent: 06 September, 2002 05:23 To: > Jonathan Rosenberg; Paul Kyzivat Cc: simple@mailman.dynamicsoft.com > Subject: [Simple] ungraceful shutdwon of presence clients > > > > In the meantime, A goes down ( I mean ungraceful shutdwon e.g. > machine shutdown) But for presence server A is still online since the > expires period hasn't yet ended. > > SIP or SIMPLE do not in this case provide PS any means to detect that > A has shutdown. You system might for example use some layer 2 > mechanisms to detect that user A's device is not active anymore but > that is again implementation issue. There are several answers here. The first, and most important statement, is that the presence server can use any techniques at its disposal to determine the presence state of the users it represents. So, what can a presence server do to handle failures of the hosts the users are connected to? 1. Use a lower registration refresh interval, so that the failure is detected faster (this is possible when the presence server and registrar are colocated) 2. The presence server can "ping" the client with periodic OPTIONS requests to check for liveness. 3. The presence server, if its also the proxy, can look for timeouts in messages which are sent to that client, as you suggest below. I am sure there are other possibilities. The spec doesn't say what you can or cannot do. Any of the above three will interoperate with any SIMPLE compliant endpoint. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 6 10:43:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05711 for ; Fri, 6 Sep 2002 10:43:01 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g86EhQKX017711; Fri, 6 Sep 2002 10:43:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18376; Fri, 6 Sep 2002 10:44:02 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18360 for ; Fri, 6 Sep 2002 10:43:11 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.47]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g86Eh6YH017546; Fri, 6 Sep 2002 10:43:08 -0400 (EDT) Message-ID: <3D78BEF5.4060809@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Himanshoo Kumar Saxena CC: simple@mailman.dynamicsoft.com References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com> <001301c2554e$8be2c5a0$7f984c0a@himanshoo> <001f01c25553$f8a080b0$7f984c0a@himanshoo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 06 Sep 2002 10:43:01 -0400 Content-Transfer-Encoding: 7bit REGISTER is for establishing an address binding so that a client can be reached for incoming requests. It is not a tool for provisioning information like name, nickname, street address, and so on. You will need to use provisioning techniques for that (web page, for example). -Jonathan R. Himanshoo Kumar Saxena wrote: > Hi, > > If a user client wants to REGISTER but also wants to provide some > additional information like user Nick Name etc. then how can it be done ? > > regards > ---------------------------------------------------------- > Himanshoo Kumar Saxena > IN service department > Huawei Technologies Company Limited > Shenzhen - 518000 > P.R.China -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 10 16:21:21 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25861 for ; Tue, 10 Sep 2002 16:21:21 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8AKKbc6007173; Tue, 10 Sep 2002 16:20:38 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06404; Tue, 10 Sep 2002 16:21:05 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06393 for ; Tue, 10 Sep 2002 16:20:20 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g8AEV7115730 for ; Tue, 10 Sep 2002 09:31:07 -0500 From: Robert Sparks To: simple@mailman.dynamicsoft.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Message-Id: <1031688929.2674.92.camel@dhcp151.dfw.dynamicsoft.com> Mime-Version: 1.0 Subject: [Simple] list keepalive test message Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 10 Sep 2002 15:15:29 -0500 Content-Transfer-Encoding: 7bit 4 days with no traffic - making sure the reflector is not broken. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 10 17:38:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27301 for ; Tue, 10 Sep 2002 17:38:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8ALcRc6007581; Tue, 10 Sep 2002 17:38:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06646; Tue, 10 Sep 2002 17:39:03 -0400 (EDT) Received: from mta.azera.net ([207.8.113.141]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06635 for ; Tue, 10 Sep 2002 17:38:53 -0400 (EDT) Received: from mail.unboundtech.com (lvs-1.azera.net [207.8.113.133]) by mta.azera.net (Postfix) with ESMTP id 69C8C33D02 for ; Tue, 10 Sep 2002 17:33:14 -0400 (EDT) Received: from chimobile2 (ool-18bfa1e3.dyn.optonline.net [24.191.161.227]) by mail.unboundtech.com (Postfix) with SMTP id AD2C15E69C for ; Tue, 10 Sep 2002 16:46:48 -0500 (CDT) Message-ID: <00f801c25912$717e9640$e3a1bf18@chimobile2> From: "shanti" To: References: <1031688929.2674.92.camel@dhcp151.dfw.dynamicsoft.com> Subject: Re: [Simple] list keepalive test message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 10 Sep 2002 17:38:44 -0400 Content-Transfer-Encoding: 7bit This is a question regarding CPIM-SIMPLE gateway. I do agree that when CPIM-SIMPLE gateway receives SIP Presence or IM, It should not involve itself converting the SIP content body to the CPIM complaint protocol's payload , for many obvious reasons. But before there is a independent standard for presence and IM exchange that all the CPIM complaint end points understand , is it a good idea for the gateway to convert the SIP body to that of the CPIM complaint protocol ? or should it be left to the endpoints to do so ? -viswashanti ----- Original Message ----- From: "Robert Sparks" To: Sent: Tuesday, September 10, 2002 4:15 PM Subject: [Simple] list keepalive test message > 4 days with no traffic - making sure the reflector is not broken. > RjS > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 12 02:17:15 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14057 for ; Thu, 12 Sep 2002 02:17:14 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8C6HYc6012454; Thu, 12 Sep 2002 02:17:34 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12025; Thu, 12 Sep 2002 02:18:05 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12014 for ; Thu, 12 Sep 2002 02:17:25 -0400 (EDT) From: lauri.niskanen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8C6Hb725353 for ; Thu, 12 Sep 2002 09:17:37 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 12 Sep 2002 09:17:25 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 09:17:25 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 09:17:24 +0300 Received: from ouebe010.NOE.Nokia.com ([172.23.70.43]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 09:17:23 +0300 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" Message-ID: Thread-Topic: simple digest, Vol 1 #518 - 2 msgs Thread-Index: AcJZrJTJkrsFRQrRSJSLdTLjdywpoAAdzeMw To: X-OriginalArrivalTime: 12 Sep 2002 06:17:23.0198 (UTC) FILETIME=[0EB6D1E0:01C25A24] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id CAA12014 Subject: [Simple] Help to Unsubscribe Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 12 Sep 2002 09:17:22 +0300 Content-Transfer-Encoding: 8bit UNSUBSCRIBE Hi, I'd like to unsubscribe this mailing list. Thanks in advance. Cheers, -Lauri -----Original Message----- From: ext simple-request@mailman.dynamicsoft.com [mailto:simple-request@mailman.dynamicsoft.com] Sent: 11 September, 2002 19:01 To: simple@mailman.dynamicsoft.com Subject: simple digest, Vol 1 #518 - 2 msgs Send simple mailing list submissions to simple@mailman.dynamicsoft.com To subscribe or unsubscribe via the World Wide Web, visit http://mailman.dynamicsoft.com/mailman/listinfo/simple or, via email, send a message with subject or body 'help' to simple-request@mailman.dynamicsoft.com You can reach the person managing the list at simple-admin@mailman.dynamicsoft.com When replying, please edit your Subject line so it is more specific than "Re: Contents of simple digest..." Today's Topics: 1. list keepalive test message (Robert Sparks) 2. Re: list keepalive test message (shanti) --__--__-- Message: 1 From: Robert Sparks To: simple@mailman.dynamicsoft.com Date: 10 Sep 2002 15:15:29 -0500 Subject: [Simple] list keepalive test message 4 days with no traffic - making sure the reflector is not broken. RjS --__--__-- Message: 2 From: "shanti" To: Subject: Re: [Simple] list keepalive test message Date: Tue, 10 Sep 2002 17:38:44 -0400 This is a question regarding CPIM-SIMPLE gateway. I do agree that when CPIM-SIMPLE gateway receives SIP Presence or IM, It should not involve itself converting the SIP content body to the CPIM complaint protocol's payload , for many obvious reasons. But before there is a independent standard for presence and IM exchange that all the CPIM complaint end points understand , is it a good idea for the gateway to convert the SIP body to that of the CPIM complaint protocol ? or should it be left to the endpoints to do so ? -viswashanti ----- Original Message ----- From: "Robert Sparks" To: Sent: Tuesday, September 10, 2002 4:15 PM Subject: [Simple] list keepalive test message > 4 days with no traffic - making sure the reflector is not broken. > RjS > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > --__--__-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple End of simple Digest _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 12 05:44:19 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17882 for ; Thu, 12 Sep 2002 05:44:18 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8C9iYc6012941; Thu, 12 Sep 2002 05:44:36 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12698; Thu, 12 Sep 2002 05:45:04 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12685 for ; Thu, 12 Sep 2002 05:44:24 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8C9iSU21149 for ; Thu, 12 Sep 2002 12:44:28 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Sep 2002 12:44:23 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Sep 2002 12:44:22 +0300 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" Subject: RE: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 Message-ID: Thread-Topic: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05 Thread-Index: AcJVCUKxblcMAuD1Ss+Ew5VsQCsGowFNhTmA To: , Cc: , , X-OriginalArrivalTime: 12 Sep 2002 09:44:22.0219 (UTC) FILETIME=[F90709B0:01C25A40] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA12685 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 12 Sep 2002 12:44:21 +0300 Content-Transfer-Encoding: 8bit Hi, I think SIP caller preferences and callee capabilities has many nice and useful features, and that's why that draft was very interesting when it first came out. Since then there has been very little happening around that draft. The reason is that many people, including myself, have understood that SIMPLE Presence is going to address many of those issues in an even better way. For example you can see what communication means the other person is willing to use right now by subscribing to her presence. At least for me that is one of the key things as I understand what "presence" should contain in communication networks. In recent IMPP discussions I noticed that some people think that this kind of information should not be part of presence, which made me quite confused. My proposal is to design the SIMPLE PIDF profile in such a way that most of the callee capabilities information can be represented in the presence document in a standard and unambiguous way. Otherwise I don't see this work very useful. That of course leads me to the question that if SIMPLE does an own profile for PIDF, what that means for interoperability with other systems, and what it means for the feasibility of PIDF for that purpose in the first place... Personally I would't worry about this, but I would still like to hear the motivation from someone who knows the origins and goals of PIDF better than me. Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 05 September, 2002 21:21 > To: Paul Kyzivat > Cc: bateman@acm.org; Kiss Krisztian (NRC/Tampere); > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] RE: Communication means in > draft-ietf-impp-cpim-pidf-05 > > > > > Paul Kyzivat wrote: > > > > Adrian Bateman wrote: > > > >> I appreciate that but my interpretation of > >> > >> SEP 02 Submission of SIMPLE PIDF profile to IESG for publication > >> as Proposed Standard > >> > >> from past discussions was with the application of PIDF to IM > >> (SIMPLE is also about IM over SIP is it not?). If media type is > >> also a SIMPLE work item then I see no reason why the two very > >> similar efforts can't be handled at the same time to help us move > >> along. > > > > > > I don't know if addressing media type, or perhaps more generally > > addressing the application of PIDF to SIP in all its glory, is > > covered by this or any other work item of SIMPLE. Based on the > > feedback in impp, this is deemed the appropriate place to > address it. > > I think its reasonable to include it in the scope of the > current work item. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 12 16:59:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08026 for ; Thu, 12 Sep 2002 16:59:50 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8CKxrc6015936; Thu, 12 Sep 2002 16:59:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14826; Thu, 12 Sep 2002 17:00:08 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14806 for ; Thu, 12 Sep 2002 16:59:59 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8CKxxYH022042 for ; Thu, 12 Sep 2002 17:00:00 -0400 (EDT) Message-ID: <3D81004C.70606@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] moving forward on data requirements draft Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 12 Sep 2002 16:59:56 -0400 Content-Transfer-Encoding: 7bit Folks, I am working on an update to the data-requirements draft: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt I'd like to make a proposal for a change in direction. Right now, the draft discusses requirements for buddy list manipulation, and more or less states that the requirements for authorizations are similar. It spends the rest of the doc motivating a framework where there is a generic data manipulation requirement, and it tries to enumerate those requirements generally. In Yokohama, this discussion of generalized data manipulation led us to a discussion on the relationship to protocols in this area, such as SyncML, acap, XPath (for naming components of a data object), and so on. Having thought about this some more, I think that this discussion of generic data manipulation confuses requirements with solution. The use of a general data manipulation protocol, like acap or syncml, is a potential solution. We are best spending our time enumerating requirements for the specific problems we have to solve. Thus, I would propose dropping the entire generic data manipulation section, and go into much more detail on the specifics of the operations we need for buddy list manipulation and, more importantly, authorization. Then, when evaluating solutions, we can decide on a protocol that does more generic data manipulation. Are people OK with this? I think this will help us quickly wrap up this effort so we can get to the protocol selection/design work, which is really needed badly. I will send a separate note on some proposed additions to the authorization functions. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 12 17:11:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08263 for ; Thu, 12 Sep 2002 17:11:17 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8CLBWc6016063; Thu, 12 Sep 2002 17:11:32 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14880; Thu, 12 Sep 2002 17:12:02 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14869 for ; Thu, 12 Sep 2002 17:11:31 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8CLBQYH022079 for ; Thu, 12 Sep 2002 17:11:31 -0400 (EDT) Message-ID: <3D8102FA.9020706@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] some additions to the authorization requirements Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 12 Sep 2002 17:11:22 -0400 Content-Transfer-Encoding: 7bit Folks, I'd like to seriously beef up the authorization requirements section of http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt to discuss a lot more of the specifics we want to accomplish. The key thing is details on the level of permissions that are being granted by the presentity. Some additional requirements to consider: * the user should be able to specify that the subscriber will only receive notifications containing a specific contact address (i.e., only my work phone) * the user should be able to specify that the subscriber will only receive notifications containing a specific status type (basic, for example, which is the only status type defined so far). * the user should be able to specify that the subscriber will only receive notifications containing specific values of a specific status type (for example, only report when my status goes to OPEN, not CLOSED) * the user should be able to specify that the subscriber will or will not receive a contact address in the notifications. Effectively, the above rules all specify filters or triggers on the presence documents that should be sent to a particular presentity. We could specify rate-based filters (i.e., specify that a subscriber cannot receive documents more frequently than X per minute), but this doesn't seem awfully useful. Related to that, if the SUBSCRIBE contained a filter of some sort, the authorization should allow the user to approve or reject their filter, and possibly impose further filtering as above. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 12 17:25:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08466 for ; Thu, 12 Sep 2002 17:25:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8CLPQc6016181; Thu, 12 Sep 2002 17:25:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14936; Thu, 12 Sep 2002 17:26:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14925 for ; Thu, 12 Sep 2002 17:25:45 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8CLPkYH022095 for ; Thu, 12 Sep 2002 17:25:46 -0400 (EDT) Message-ID: <3D810652.2090805@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] collection template Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 12 Sep 2002 17:25:38 -0400 Content-Transfer-Encoding: 7bit Folks, The current version of the old "buddy list" package now defines a collection template that can allow a user to subscribe to a list of URIs for a particular package, such as presence. It has occurred to me since the meeting that we can take this one step farther for a really generally useful tool. The idea is to make this a collection PACKAGE, not a template. The URI that you subscribe to represents a list of URIs, each of which can be for a different package. The list would also include information on the package that URI is associated with. The idea here is that a UA could send a single subscribe to a server which would, in turn, fan out subscriptions to each of the events/URIs the user was interested in. Heres an example. Lets say a UA is interested in a subscription to two message waiting indicators and two buddy lists: sip:mwi1@serviceprovider1.com, mwi package sip:mwi2@serviceprovider2.com, mwi package sip:buddylist1@serviceprovider1.com, collection package sip:buddylist2@serviceprovider2.com, collection package the two buddy lists are themselves lists, each of which is a URI that represents a presentity. We could assign a single URI to the two MWIs and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would then do this: SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0 Event: collection Accept: text/collection-info, application/cpim-pidf+xml, application/simple-message-summary The server would fan out a subscription to each element in the list within the package for that element, copying the Accept headers from the collection SUBSCRIBE. The collection server would be responsible for refreshing those fanned out subscriptions, and passing the content of notifications towards the UAC. The collection server could be ignorant of the detailed operation of any of the packages, and could generate subscriptions for packages it doesnt even understand. If we envision that UAs will frequently have lots of long-lived subscriptions to a number of things, this mechanism can save a lot of overhead for wireless or other access constrained devices. It increases the administrative burden overall, since each collection URI needs to specify a modereately complex data structure - a list of elements, each of which is a URI/event pair. But, I think this is a worthwhile tradeoff. Do people think this is a worthwhile approach? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 12 17:44:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08984 for ; Thu, 12 Sep 2002 17:44:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8CLiSc6016343; Thu, 12 Sep 2002 17:44:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15004; Thu, 12 Sep 2002 17:45:04 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14991 for ; Thu, 12 Sep 2002 17:44:34 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g8CLiVpA062988; Thu, 12 Sep 2002 16:44:31 -0500 (CDT) Message-ID: <3D810A83.80303@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <3D810652.2090805@dynamicsoft.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 12 Sep 2002 16:43:31 -0500 Content-Transfer-Encoding: 7bit Interesting. I am concerned, however, that the event negotiation part would now get lost. The event is now "collection" rather than "presence.collection" or whatever. By subscribing to .collection, I am asserting that I care about and can do something useful with notifies with an event header of . If I susbscrbe to "collection" without an event scope, I now have to expect NOTIFY requests for arbitrary events. Jonathan Rosenberg wrote: > Folks, > > The current version of the old "buddy list" package now defines a > collection template that can allow a user to subscribe to a list of URIs > for a particular package, such as presence. > > It has occurred to me since the meeting that we can take this one step > farther for a really generally useful tool. > > The idea is to make this a collection PACKAGE, not a template. The URI > that you subscribe to represents a list of URIs, each of which can be > for a different package. The list would also include information on the > package that URI is associated with. > > The idea here is that a UA could send a single subscribe to a server > which would, in turn, fan out subscriptions to each of the events/URIs > the user was interested in. > > Heres an example. Lets say a UA is interested in a subscription to two > message waiting indicators and two buddy lists: > > sip:mwi1@serviceprovider1.com, mwi package > sip:mwi2@serviceprovider2.com, mwi package > sip:buddylist1@serviceprovider1.com, collection package > sip:buddylist2@serviceprovider2.com, collection package > > the two buddy lists are themselves lists, each of which is a URI that > represents a presentity. We could assign a single URI to the two MWIs > and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would > then do this: > > SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0 > Event: collection > Accept: text/collection-info, application/cpim-pidf+xml, > application/simple-message-summary > > > The server would fan out a subscription to each element in the list > within the package for that element, copying the Accept headers from the > collection SUBSCRIBE. The collection server would be responsible for > refreshing those fanned out subscriptions, and passing the content of > notifications towards the UAC. The collection server could be ignorant > of the detailed operation of any of the packages, and could generate > subscriptions for packages it doesnt even understand. > > If we envision that UAs will frequently have lots of long-lived > subscriptions to a number of things, this mechanism can save a lot of > overhead for wireless or other access constrained devices. It increases > the administrative burden overall, since each collection URI needs to > specify a modereately complex data structure - a list of elements, each > of which is a URI/event pair. But, I think this is a worthwhile tradeoff. > > Do people think this is a worthwhile approach? > > Thanks, > Jonathan R. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 12 19:15:04 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10629 for ; Thu, 12 Sep 2002 19:15:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8CNFVc6016665; Thu, 12 Sep 2002 19:15:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15250; Thu, 12 Sep 2002 19:16:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15239 for ; Thu, 12 Sep 2002 19:15:10 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8CNFAl7002179; Thu, 12 Sep 2002 19:15:11 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAQ77322; Thu, 12 Sep 2002 19:19:42 -0400 (EDT) Message-ID: <3D811FEE.FFAA9102@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] some additions to the authorization requirements References: <3D8102FA.9020706@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 12 Sep 2002 19:14:54 -0400 Content-Transfer-Encoding: 7bit below... Jonathan Rosenberg wrote: > > Folks, > > I'd like to seriously beef up the authorization requirements section of > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt > to discuss a lot more of the specifics we want to accomplish. > > The key thing is details on the level of permissions that are being > granted by the presentity. Some additional requirements to consider: Seems like a good direction in general. > > * the user should be able to specify that the subscriber will only > receive notifications containing a specific contact address (i.e., only > my work phone) Good, but may be hard to define. My work phone may not always have the same contact address (because of DHCP and lack of an assigned DNS name.) May need to identify in some other way - e.g. via the credential used to register it. (I don't like that alternative much, but I'm grasping for something other than the contact address itself.) (Unfortunately devices without DNS names are not especially unusual. Not just phones, but Microsoft devices that use WINS rather than DNS.) > > * the user should be able to specify that the subscriber will only > receive notifications containing a specific status type (basic, for > example, which is the only status type defined so far). fine. > > * the user should be able to specify that the subscriber will only > receive notifications containing specific values of a specific status > type (for example, only report when my status goes to OPEN, not CLOSED) This might be troublesome. What happens if, when I first subscribe, the status only contains values I am not permitted to receive? I have to receive a notification of some sort, and every tuple is required to carry some status. So I think the entire tuple must be suppressed if there are no status values that can be returned. When the status changes, I should get a notification again if the value I had previously received is different than what I would receive if I polled now. Perhaps this requirement could be reworded to solve this problem: * the user should be able to specify the specific values of a specific status type that the subscribe IS, or IS NOT, permitted to receive. Values not permitted must be omitted from the status in notifications. If all status is omitted, the tuple must be omitted as well. (for example, include tuples with OPEN status, but suppress those with only CLOSED status.) > > * the user should be able to specify that the subscriber will or will > not receive a contact address in the notifications. yes - good. > > Effectively, the above rules all specify filters or triggers on the > presence documents that should be sent to a particular presentity. > > We could specify rate-based filters (i.e., specify that a subscriber > cannot receive documents more frequently than X per minute), but this > doesn't seem awfully useful. > > Related to that, if the SUBSCRIBE contained a filter of some sort, the > authorization should allow the user to approve or reject their filter, > and possibly impose further filtering as above. Is there any reason to forbid filtering requests from the subscriber? Would make more sense to me to just require that if both sides supply filters than they must be composed - the document must be passed through both. As long as a filter only removes things it doesn't matter what order they are applied. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 12 23:15:02 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14558 for ; Thu, 12 Sep 2002 23:15:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8D3FSc6017275; Thu, 12 Sep 2002 23:15:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15881; Thu, 12 Sep 2002 23:16:05 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15870 for ; Thu, 12 Sep 2002 23:15:10 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8D3FAYH022284; Thu, 12 Sep 2002 23:15:10 -0400 (EDT) Message-ID: <3D81583D.2000904@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <3D810652.2090805@dynamicsoft.com> <3D810A83.80303@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 12 Sep 2002 23:15:09 -0400 Content-Transfer-Encoding: 7bit We could do something similar to what I had suggested for the Accept header. The SUBSCRIBE has Allow-Events which lists the event types supported. If one of the URI in the list is of a type not indicated in Allow-Events, the subscription is rejected. Not quite the intended use of Allow-Events, for sure.... -Jonathan R. Ben Campbell wrote: > Interesting. I am concerned, however, that the event negotiation part > would now get lost. The event is now "collection" rather than > "presence.collection" or whatever. By subscribing to .collection, > I am asserting that I care about and can do something useful with > notifies with an event header of . If I susbscrbe to "collection" > without an event scope, I now have to expect NOTIFY requests for > arbitrary events. > > > Jonathan Rosenberg wrote: > >> Folks, >> >> The current version of the old "buddy list" package now defines a >> collection template that can allow a user to subscribe to a list of >> URIs for a particular package, such as presence. >> >> It has occurred to me since the meeting that we can take this one step >> farther for a really generally useful tool. >> >> The idea is to make this a collection PACKAGE, not a template. The URI >> that you subscribe to represents a list of URIs, each of which can be >> for a different package. The list would also include information on >> the package that URI is associated with. >> >> The idea here is that a UA could send a single subscribe to a server >> which would, in turn, fan out subscriptions to each of the events/URIs >> the user was interested in. >> >> Heres an example. Lets say a UA is interested in a subscription to two >> message waiting indicators and two buddy lists: >> >> sip:mwi1@serviceprovider1.com, mwi package >> sip:mwi2@serviceprovider2.com, mwi package >> sip:buddylist1@serviceprovider1.com, collection package >> sip:buddylist2@serviceprovider2.com, collection package >> >> the two buddy lists are themselves lists, each of which is a URI that >> represents a presentity. We could assign a single URI to the two MWIs >> and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would >> then do this: >> >> SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0 >> Event: collection >> Accept: text/collection-info, application/cpim-pidf+xml, >> application/simple-message-summary >> >> >> The server would fan out a subscription to each element in the list >> within the package for that element, copying the Accept headers from >> the collection SUBSCRIBE. The collection server would be responsible >> for refreshing those fanned out subscriptions, and passing the content >> of notifications towards the UAC. The collection server could be >> ignorant of the detailed operation of any of the packages, and could >> generate subscriptions for packages it doesnt even understand. >> >> If we envision that UAs will frequently have lots of long-lived >> subscriptions to a number of things, this mechanism can save a lot of >> overhead for wireless or other access constrained devices. It >> increases the administrative burden overall, since each collection URI >> needs to specify a modereately complex data structure - a list of >> elements, each of which is a URI/event pair. But, I think this is a >> worthwhile tradeoff. >> >> Do people think this is a worthwhile approach? >> >> Thanks, >> Jonathan R. > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 13 07:30:10 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01082 for ; Fri, 13 Sep 2002 07:30:09 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8DBUUc6018375; Fri, 13 Sep 2002 07:30:30 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17218; Fri, 13 Sep 2002 07:31:05 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17207 for ; Fri, 13 Sep 2002 07:30:37 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8DBUTrU004657; Fri, 13 Sep 2002 13:30:29 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.18]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g8DBUTG3008313; Fri, 13 Sep 2002 14:30:29 +0300 (EET DST) Message-ID: <3D81CC54.C9773ACB@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Costa Requena CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] addressing scheme in Request-URI References: <200206261920.PAA23241@dynasty.cs.columbia.edu> <1030533613.3d6cb1ed50276@keskus.tct.hut.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 13 Sep 2002 14:30:28 +0300 Content-Transfer-Encoding: 7bit Jose, The request-URI can have other URI schemes, such as im: or pres:. However, it is recommended that they are converted to SIP or SIPS URIs as soon as possible. That is, if the UA could not do it by itself, the outbound proxy is the best place to do it. This ensures that SIP proxies that are not im or pres aware can route messages correctly. Regards, Gonzalo Costa Requena wrote: > > Hi, > > Just quick question! > I read in previous specs that SIP Request-URI SHOULD have sip: as address > scheme while To: header MAY have others than sip: schemes.In recent specs > it says that the content of To: header is copied in Request-URI. > Could someone ensure that the Request-URI MAY have other schemes than sip: or > sips: let's say im: pres: http:, etc. > > Thanks in advance! > BR > Jose > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple -- 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@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 13 10:54:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07932 for ; Fri, 13 Sep 2002 10:54:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8DEsTc6019147; Fri, 13 Sep 2002 10:54:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17872; Fri, 13 Sep 2002 10:55:04 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17859 for ; Fri, 13 Sep 2002 10:54:22 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DEsJT29459 for ; Fri, 13 Sep 2002 17:54:19 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 17:54:21 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 17:54:21 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 17:54:21 +0300 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" Subject: RE: [Simple] collection template Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2061C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] collection template Thread-Index: AcJa1DHqZhFtQi+IS5m1eri8/33PUwAXw3nQ To: , Cc: X-OriginalArrivalTime: 13 Sep 2002 14:54:21.0572 (UTC) FILETIME=[7184D440:01C25B35] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA17859 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 13 Sep 2002 17:54:20 +0300 Content-Transfer-Encoding: 8bit I think its much simpler if we have .collection. Can the subscriber rely on the content-type of NOTIFY to decide if this NOTIFY contains payload for mwi or buddylist? /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, September 13, 2002 6:15 AM > To: Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] collection template > > > We could do something similar to what I had suggested for the Accept > header. The SUBSCRIBE has Allow-Events which lists the event types > supported. If one of the URI in the list is of a type not > indicated in > Allow-Events, the subscription is rejected. > > Not quite the intended use of Allow-Events, for sure.... > > -Jonathan R. > > Ben Campbell wrote: > > Interesting. I am concerned, however, that the event > negotiation part > > would now get lost. The event is now "collection" rather than > > "presence.collection" or whatever. By subscribing to > .collection, > > I am asserting that I care about and can do something useful with > > notifies with an event header of . If I susbscrbe to > "collection" > > without an event scope, I now have to expect NOTIFY requests for > > arbitrary events. > > > > > > Jonathan Rosenberg wrote: > > > >> Folks, > >> > >> The current version of the old "buddy list" package now defines a > >> collection template that can allow a user to subscribe to > a list of > >> URIs for a particular package, such as presence. > >> > >> It has occurred to me since the meeting that we can take > this one step > >> farther for a really generally useful tool. > >> > >> The idea is to make this a collection PACKAGE, not a > template. The URI > >> that you subscribe to represents a list of URIs, each of > which can be > >> for a different package. The list would also include > information on > >> the package that URI is associated with. > >> > >> The idea here is that a UA could send a single subscribe > to a server > >> which would, in turn, fan out subscriptions to each of the > events/URIs > >> the user was interested in. > >> > >> Heres an example. Lets say a UA is interested in a > subscription to two > >> message waiting indicators and two buddy lists: > >> > >> sip:mwi1@serviceprovider1.com, mwi package > >> sip:mwi2@serviceprovider2.com, mwi package > >> sip:buddylist1@serviceprovider1.com, collection package > >> sip:buddylist2@serviceprovider2.com, collection package > >> > >> the two buddy lists are themselves lists, each of which is > a URI that > >> represents a presentity. We could assign a single URI to > the two MWIs > >> and two buddy lists - sip:mystuff@serviceprovider1.com. > The UA would > >> then do this: > >> > >> SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0 > >> Event: collection > >> Accept: text/collection-info, application/cpim-pidf+xml, > >> application/simple-message-summary > >> > >> > >> The server would fan out a subscription to each element in > the list > >> within the package for that element, copying the Accept > headers from > >> the collection SUBSCRIBE. The collection server would be > responsible > >> for refreshing those fanned out subscriptions, and passing > the content > >> of notifications towards the UAC. The collection server could be > >> ignorant of the detailed operation of any of the packages, > and could > >> generate subscriptions for packages it doesnt even understand. > >> > >> If we envision that UAs will frequently have lots of long-lived > >> subscriptions to a number of things, this mechanism can > save a lot of > >> overhead for wireless or other access constrained devices. It > >> increases the administrative burden overall, since each > collection URI > >> needs to specify a modereately complex data structure - a list of > >> elements, each of which is a URI/event pair. But, I think > this is a > >> worthwhile tradeoff. > >> > >> Do people think this is a worthwhile approach? > >> > >> Thanks, > >> Jonathan R. > > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 08:52:21 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03031 for ; Mon, 16 Sep 2002 08:52:20 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GCqdMN000813; Mon, 16 Sep 2002 08:52:41 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00999; Mon, 16 Sep 2002 08:53:04 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00988 for ; Mon, 16 Sep 2002 08:52:01 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8GCqFZ04322 for ; Mon, 16 Sep 2002 15:52:15 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Sep 2002 15:51:58 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Sep 2002 15:51:58 +0300 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" Subject: RE: [Simple] collection template Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901944FC3@esebe013.ntc.nokia.com> Thread-Topic: [Simple] collection template Thread-Index: AcJaoyEVv3rrRmJVTGqQGuTk59K+1gC2qs8g To: , X-OriginalArrivalTime: 16 Sep 2002 12:51:58.0579 (UTC) FILETIME=[D7FE4430:01C25D7F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA00988 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 15:51:57 +0300 Content-Transfer-Encoding: 8bit Hi Jonathan, It seems that this approach also makes the recursion of presence-list subscriptions easier. I had some doubts about the previous template package based proposal (especially the part about defaulting to presence from presence.collection), because of the fact that one could potentially have both presence *and* presence-collection events in the same SIP URI. So, I like this approach. Let's go for it. Cheers, Aki > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, September 13, 2002 12:26 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] collection template > > > Folks, > > The current version of the old "buddy list" package now defines a > collection template that can allow a user to subscribe to a > list of URIs > for a particular package, such as presence. > > It has occurred to me since the meeting that we can take this > one step > farther for a really generally useful tool. > > The idea is to make this a collection PACKAGE, not a > template. The URI > that you subscribe to represents a list of URIs, each of which can be > for a different package. The list would also include > information on the > package that URI is associated with. > > The idea here is that a UA could send a single subscribe to a server > which would, in turn, fan out subscriptions to each of the > events/URIs > the user was interested in. > > Heres an example. Lets say a UA is interested in a > subscription to two > message waiting indicators and two buddy lists: > > sip:mwi1@serviceprovider1.com, mwi package > sip:mwi2@serviceprovider2.com, mwi package > sip:buddylist1@serviceprovider1.com, collection package > sip:buddylist2@serviceprovider2.com, collection package > > the two buddy lists are themselves lists, each of which is a URI that > represents a presentity. We could assign a single URI to the two MWIs > and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would > then do this: > > SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0 > Event: collection > Accept: text/collection-info, application/cpim-pidf+xml, > application/simple-message-summary > > > The server would fan out a subscription to each element in the list > within the package for that element, copying the Accept > headers from the > collection SUBSCRIBE. The collection server would be responsible for > refreshing those fanned out subscriptions, and passing the content of > notifications towards the UAC. The collection server could be > ignorant > of the detailed operation of any of the packages, and could generate > subscriptions for packages it doesnt even understand. > > If we envision that UAs will frequently have lots of long-lived > subscriptions to a number of things, this mechanism can save a lot of > overhead for wireless or other access constrained devices. It > increases > the administrative burden overall, since each collection URI needs to > specify a modereately complex data structure - a list of > elements, each > of which is a URI/event pair. But, I think this is a > worthwhile tradeoff. > > Do people think this is a worthwhile approach? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 10:52:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07571 for ; Mon, 16 Sep 2002 10:52:31 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GEqRMN001311; Mon, 16 Sep 2002 10:52:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01404; Mon, 16 Sep 2002 10:53:04 -0400 (EDT) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA01393 for ; Mon, 16 Sep 2002 10:52:49 -0400 (EDT) Message-ID: <20020916145236.1705.qmail@web11604.mail.yahoo.com> Received: from [207.46.137.250] by web11604.mail.yahoo.com via HTTP; Mon, 16 Sep 2002 07:52:36 PDT From: Sean Olson Subject: RE: [Simple] collection template To: aki.niemi@nokia.com, jdrosen@dynamicsoft.com, simple@mailman.dynamicsoft.com In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901944FC3@esebe013.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 07:52:36 -0700 (PDT) I would like to reiterate Ben's concerns over negotiation of supported Event packages. I think turning the collection template into a package would go against the basic design of the SUB/NOT mechanism. Having a collection template would still be a big win in terms of bandwidth. Having to send multiple .collection SUBs is still a lot better than having to do the individual SUBs. At the very least, I would not rely on the Accept headers for a pseudo-negotiation. Instead, I would turn to an appropriate "filter" for the body of the SUBSCRIBE to create a meta-level of negotiation. This is already feeling too complex to me, but we should make this as clean a design as possible. Sean Olson Microsoft --- aki.niemi@nokia.com wrote: > Hi Jonathan, > > It seems that this approach also makes the recursion > of presence-list subscriptions easier. I had some > doubts about the previous template package based > proposal (especially the part about defaulting to > presence from presence.collection), because of the > fact that one could potentially have both presence > *and* presence-collection events in the same SIP > URI. > > So, I like this approach. Let's go for it. > > Cheers, > Aki > > > > -----Original Message----- > > From: ext Jonathan Rosenberg > [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, September 13, 2002 12:26 AM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] collection template > > > > > > Folks, > > > > The current version of the old "buddy list" > package now defines a > > collection template that can allow a user to > subscribe to a > > list of URIs > > for a particular package, such as presence. > > > > It has occurred to me since the meeting that we > can take this > > one step > > farther for a really generally useful tool. > > > > The idea is to make this a collection PACKAGE, not > a > > template. The URI > > that you subscribe to represents a list of URIs, > each of which can be > > for a different package. The list would also > include > > information on the > > package that URI is associated with. > > > > The idea here is that a UA could send a single > subscribe to a server > > which would, in turn, fan out subscriptions to > each of the > > events/URIs > > the user was interested in. > > > > Heres an example. Lets say a UA is interested in a > > > subscription to two > > message waiting indicators and two buddy lists: > > > > sip:mwi1@serviceprovider1.com, mwi package > > sip:mwi2@serviceprovider2.com, mwi package > > sip:buddylist1@serviceprovider1.com, collection > package > > sip:buddylist2@serviceprovider2.com, collection > package > > > > the two buddy lists are themselves lists, each of > which is a URI that > > represents a presentity. We could assign a single > URI to the two MWIs > > and two buddy lists - > sip:mystuff@serviceprovider1.com. The UA would > > then do this: > > > > SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0 > > Event: collection > > Accept: text/collection-info, > application/cpim-pidf+xml, > > application/simple-message-summary > > > > > > The server would fan out a subscription to each > element in the list > > within the package for that element, copying the > Accept > > headers from the > > collection SUBSCRIBE. The collection server would > be responsible for > > refreshing those fanned out subscriptions, and > passing the content of > > notifications towards the UAC. The collection > server could be > > ignorant > > of the detailed operation of any of the packages, > and could generate > > subscriptions for packages it doesnt even > understand. > > > > If we envision that UAs will frequently have lots > of long-lived > > subscriptions to a number of things, this > mechanism can save a lot of > > overhead for wireless or other access constrained > devices. It > > increases > > the administrative burden overall, since each > collection URI needs to > > specify a modereately complex data structure - a > list of > > elements, each > > of which is a URI/event pair. But, I think this is > a > > worthwhile tradeoff. > > > > Do people think this is a worthwhile approach? > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 > Eagle Rock Ave. > > Chief Scientist First > Floor > > dynamicsoft East > Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 14:02:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12736 for ; Mon, 16 Sep 2002 14:02:06 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GI2SMN002292; Mon, 16 Sep 2002 14:02:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01990; Mon, 16 Sep 2002 14:03:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01979 for ; Mon, 16 Sep 2002 14:02:49 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GI2ANo003189 for ; Mon, 16 Sep 2002 14:02:11 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Sep 2002 13:02:44 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64150@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 13:02:43 -0500 > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > If I susbscrbe to "collection" > without an event scope, I now have to expect NOTIFY requests for > arbitrary events. Unless the proposal is something of an overhaul of event processing (which I advise against), your NOTIFY messages would be NOTIFY for the event "collection" under Jonathan's proposal. I've got to admit, I share Ben and Sean's reservations about this approach. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 14:14:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13067 for ; Mon, 16 Sep 2002 14:13:59 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIEQMN002426; Mon, 16 Sep 2002 14:14:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02047; Mon, 16 Sep 2002 14:15:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02034 for ; Mon, 16 Sep 2002 14:14:37 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIE0No003264 for ; Mon, 16 Sep 2002 14:14:01 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Sep 2002 13:14:37 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64151@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 13:14:36 -0500 Inline. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > The idea here is that a UA could send a single subscribe to a server > which would, in turn, fan out subscriptions to each of the > events/URIs > the user was interested in. I had imagined that the template approach could do the same thing. > Heres an example. Lets say a UA is interested in a > subscription to two > message waiting indicators and two buddy lists: > > sip:mwi1@serviceprovider1.com, mwi package > sip:mwi2@serviceprovider2.com, mwi package > sip:buddylist1@serviceprovider1.com, collection package > sip:buddylist2@serviceprovider2.com, collection package > > the two buddy lists are themselves lists, each of which is a URI that > represents a presentity. We could assign a single URI to the two MWIs > and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would > then do this: > > SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0 > Event: collection > Accept: text/collection-info, application/cpim-pidf+xml, > application/simple-message-summary > > > The server would fan out a subscription to each element in the list > within the package for that element, copying the Accept > headers from the > collection SUBSCRIBE. The collection server would be responsible for > refreshing those fanned out subscriptions, and passing the content of > notifications towards the UAC. The collection server could be > ignorant > of the detailed operation of any of the packages, and could generate > subscriptions for packages it doesnt even understand. The template approach seems to have the same properties, except for the heterogeneity of event types. So, for example, you could send the following two messages: SUBSCRIBE sip:mymwis@serviceprovider1.com SIP/2.0 Event: mwi.collection Accept: text/collection-info SUBSCRIBE sip:mybuddylists@serviceprovider1.com SIP/2.0 Event: presence.collection.collection Accept: text/collection-info For both of these, the node processing the collection templates does not need to know anything about the underlying package (we defined templates this way on purpose!) and can still operate in a useful fashion. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 14:26:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13354 for ; Mon, 16 Sep 2002 14:26:00 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIQQMN002507; Mon, 16 Sep 2002 14:26:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02102; Mon, 16 Sep 2002 14:27:03 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02091 for ; Mon, 16 Sep 2002 14:26:51 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIQENo003320; Mon, 16 Sep 2002 14:26:15 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Sep 2002 13:26:51 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64152@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'aki.niemi@nokia.com'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 13:26:51 -0500 I appear to have missed the proposal you're referring to, and I can't find it in the i-d archives. The way 3265 is defined, if you subscribe to "presence.collection", you get notifies for "presence.collection". You *never* get notifies for "presence" because you did not subscribe to "presence". This is an important property of templates. It allows for generic implementation of them. For example, you can easily see how it might be useful to subscribe to "foo.winfo" without even necessarily knowing the semantics behind the "foo" package. /a > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Monday, September 16, 2002 7:52 > To: jdrosen@dynamicsoft.com; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] collection template > > > Hi Jonathan, > > It seems that this approach also makes the recursion of > presence-list subscriptions easier. I had some doubts about > the previous template package based proposal (especially the > part about defaulting to presence from presence.collection), > because of the fact that one could potentially have both > presence *and* presence-collection events in the same SIP URI. > > So, I like this approach. Let's go for it. > > Cheers, > Aki > > > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, September 13, 2002 12:26 AM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] collection template > > > > > > Folks, > > > > The current version of the old "buddy list" package now defines a > > collection template that can allow a user to subscribe to a > > list of URIs > > for a particular package, such as presence. > > > > It has occurred to me since the meeting that we can take this > > one step > > farther for a really generally useful tool. > > > > The idea is to make this a collection PACKAGE, not a > > template. The URI > > that you subscribe to represents a list of URIs, each of > which can be > > for a different package. The list would also include > > information on the > > package that URI is associated with. > > > > The idea here is that a UA could send a single subscribe to > a server > > which would, in turn, fan out subscriptions to each of the > > events/URIs > > the user was interested in. > > > > Heres an example. Lets say a UA is interested in a > > subscription to two > > message waiting indicators and two buddy lists: > > > > sip:mwi1@serviceprovider1.com, mwi package > > sip:mwi2@serviceprovider2.com, mwi package > > sip:buddylist1@serviceprovider1.com, collection package > > sip:buddylist2@serviceprovider2.com, collection package > > > > the two buddy lists are themselves lists, each of which is > a URI that > > represents a presentity. We could assign a single URI to > the two MWIs > > and two buddy lists - sip:mystuff@serviceprovider1.com. The > UA would > > then do this: > > > > SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0 > > Event: collection > > Accept: text/collection-info, application/cpim-pidf+xml, > > application/simple-message-summary > > > > > > The server would fan out a subscription to each element in the list > > within the package for that element, copying the Accept > > headers from the > > collection SUBSCRIBE. The collection server would be > responsible for > > refreshing those fanned out subscriptions, and passing the > content of > > notifications towards the UAC. The collection server could be > > ignorant > > of the detailed operation of any of the packages, and could > generate > > subscriptions for packages it doesnt even understand. > > > > If we envision that UAs will frequently have lots of long-lived > > subscriptions to a number of things, this mechanism can > save a lot of > > overhead for wireless or other access constrained devices. It > > increases > > the administrative burden overall, since each collection > URI needs to > > specify a modereately complex data structure - a list of > > elements, each > > of which is a URI/event pair. But, I think this is a > > worthwhile tradeoff. > > > > Do people think this is a worthwhile approach? > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 14:36:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13653 for ; Mon, 16 Sep 2002 14:36:22 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIaPMN002595; Mon, 16 Sep 2002 14:36:25 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02153; Mon, 16 Sep 2002 14:37:03 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02142 for ; Mon, 16 Sep 2002 14:36:45 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIa8No003378; Mon, 16 Sep 2002 14:36:08 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Sep 2002 13:36:45 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64153@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Sean Olson'" , aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 13:36:45 -0500 > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > > At the very least, I would not rely on the Accept > headers for a pseudo-negotiation. Instead, I would > turn to an appropriate "filter" for the body of > the SUBSCRIBE to create a meta-level of negotiation. > This is already feeling too complex to me, but we > should make this as clean a design as possible. I think Sean's hit on the thing that's bothering me here: we're overloading the semantics of headers here. We've made this mistake in the past, and should now recognize it as such. I agree that if we're to go down the path of making this a package, we need to define clean semantics for this negotiation, and that they need to be separate from the normal event negotiation. It appears to me that the cleanest approach will still be to use the template approach. This allows us to reduce the number of subscribes to match the number of event packages supported by the UA. This is still much smaller than the number of URIs being subscribed to, and appears to require far less standardization. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 14:47:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14082 for ; Mon, 16 Sep 2002 14:47:59 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GImQMN002698; Mon, 16 Sep 2002 14:48:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02202; Mon, 16 Sep 2002 14:49:03 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02191 for ; Mon, 16 Sep 2002 14:48:47 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GImANo003462 for ; Mon, 16 Sep 2002 14:48:11 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Sep 2002 13:48:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64154@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template: client vs server MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 13:48:47 -0500 While on the topic of the collection package, it has recently occured to me that there are two useful modes of collection that we might want to specify. 1) The UA sends a collection SUBSCRIBE to a server. The server uses the request URI to look up the list of resources that the collection contains. 2) The UA sends a collection SUBSCRIBE to a server. The SUBSCRIBE message itself contains sufficient information to identify the resources that the collection will represent (e.g. as a list of URIs). Mode 1 is very useful for, for example, requesting a subscription to the presence of everyone on a network-stored buddy list. However, there are times when the application will want to subscribe a collection of events based on some sort of list that is far more ephemeral than the sort of information stored in the network -- such as "the list of users in the current conference call," or "the group of people who are in the same city as I am right now." Does the group see enough value in the second mode of operation that we should make provisions for it? /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 16:20:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16347 for ; Mon, 16 Sep 2002 16:20:39 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GKGQMN003162; Mon, 16 Sep 2002 16:16:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02453; Mon, 16 Sep 2002 16:17:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02442 for ; Mon, 16 Sep 2002 16:16:37 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8GKGghf013053; Mon, 16 Sep 2002 16:16:42 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAQ93989; Mon, 16 Sep 2002 16:21:12 -0400 (EDT) Message-ID: <3D863C19.7925A42@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Sean Olson'" , aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64153@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 16:16:25 -0400 Content-Transfer-Encoding: 7bit Adam Roach wrote: > > It appears to me that the cleanest approach will still > be to use the template approach. This allows us to reduce > the number of subscribes to match the number of event > packages supported by the UA. This is still much smaller > than the number of URIs being subscribed to, and appears > to require far less standardization. This reduces the number of subscriptions issued by UACs. But it doesn't reduce the number of total subscriptions - it increases it. And it doesn't reduce the number of notifications received by the UAC (well, its actually a UAS for the notify, but you know what I mean.) It might even increase the number of notifications further - if the collection refreshes its subscription to each member of the collection before it expires, and also refreshes each subscription when the UAC refreshes its subscription to the collection. This situation could be improved if the collection can be set, via filters or whatever, to normally return only changes. It could be improved vastly in some cases if many collections have elements in common, and the server is permitted to multiplex one subscription to a collection element across many containing collections. Moreso if the lifetime of the subscriptions the collection server makes are independent of those to the collections it serves. Of course there is a problem with this. If you and I both subscribe to X, we may get different results based on who we are. If we both subscribe to collection CX, is the data delivered to the collection server on our behalf the same as we would have gotten directly? Or is the data delivered to the collection server by X based on the identity of the collection server? Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 16 19:05:56 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19685 for ; Mon, 16 Sep 2002 19:05:56 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GN5TMN003780; Mon, 16 Sep 2002 19:05:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02941; Mon, 16 Sep 2002 19:06:06 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02930 for ; Mon, 16 Sep 2002 19:05:21 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GN4fNo005051; Mon, 16 Sep 2002 19:04:42 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Sep 2002 18:05:20 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64158@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: "'Sean Olson'" , aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 18:05:19 -0500 > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Adam Roach wrote: > > > > It appears to me that the cleanest approach will still > > be to use the template approach. This allows us to reduce > > the number of subscribes to match the number of event > > packages supported by the UA. This is still much smaller > > than the number of URIs being subscribed to, and appears > > to require far less standardization. > > This reduces the number of subscriptions issued by UACs. But > it doesn't reduce the number of total subscriptions - it > increases it. And it doesn't reduce the number of > notifications received by the UAC (well, its actually a UAS > for the notify, but you know what I mean.) This is true for both the collection package and the collection template-package approach. This is a known architectural result of the approach being pursued. If operators don't want to support this, they can disable whatever collection mechanisms are available on their servers; this would force the clients to either not subscribe or to fall back to sending individual subscriptions instead of subscriptions to collections. > It might even increase the number of notifications further - > if the collection refreshes its subscription to each member > of the collection before it expires, and also refreshes each > subscription when the UAC refreshes its subscription to the > collection. This is true for both the collection package and the collection template-package approach. I would expect reasonable implementations of servers that aggregate these subscription collections to not pass along information unless it has actually been updated. This means that if it is using SUBSCRIBE on the back-end to learn about state, it won't send the resulting NOTIFY messages to the collection subscriber unless the NOTIFY actually represented a change in state. I would NOT expect the server that agregates these subscriptions to automatically refresh their subscription to the members of the subscription every time the the UAC refreshes its subscription to the collection. > This situation could be improved if the collection can be > set, via filters or whatever, to normally return only changes. This is true for both the collection package and the collection template-package approach. I would expect this to be the normal mode of operation, in fact. What I *would* hope to be able to do via filters is say something like "when you get a state change, hold off 30 seconds before sending it to me, in case you get additional changes that you might be able to send in the same message" or something like that. > It could be improved vastly in some cases if many collections > have elements in common, and the server is permitted to > multiplex one subscription to a collection element across > many containing collections. Moreso if the lifetime of the > subscriptions the collection server makes are independent of > those to the collections it serves. This is true for both the collection package and the collection template-package approach. > Of course there is a problem with this. If you and I both > subscribe to X, we may get different results based on who we > are. If we both subscribe to collection CX, is the data > delivered to the collection server on our behalf the same as > we would have gotten directly? Or is the data delivered to > the collection server by X based on the identity of the > collection server? This is true for both the collection package and the collection template-package approach. After studying this problem for an extended period of time, I have reached the conclusion that this sort of aggregation doesn't generally work. The permissions problems that arise from doing this are pretty much intractible unless you make some walled- garden type assumptions about how servers are going to protect the data they receive in this way. Was your letter trying to differentiate the package approach from the template-package approach? That is what context would imply, but the content doesn't seem to live up to that expectation. Or were you just trying to raise issues with the idea of subscription collections regardless of which approach is taken? /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 02:32:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05720 for ; Tue, 17 Sep 2002 02:32:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8H6WRMN004657; Tue, 17 Sep 2002 02:32:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04095; Tue, 17 Sep 2002 02:33:04 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04084 for ; Tue, 17 Sep 2002 02:32:51 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8H6WgRb012870; Tue, 17 Sep 2002 08:32:46 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g8H6WgG3023329; Tue, 17 Sep 2002 09:32:42 +0300 (EET DST) Message-ID: <3D86CC89.D1D6FFE8@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Paul Kyzivat'" , "'Sean Olson'" , aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64158@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 09:32:41 +0300 Content-Transfer-Encoding: 7bit I believe the collection template-package approach is a cleaner and simpler solution. Having a server fan out heterogeneous (i.e., different events) subscriptions seems to me like streeching too much the concept of a collention of events. Let's handle different events with different SUBSCRIBES. Gonzalo Adam Roach wrote: > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Adam Roach wrote: > > > > > > It appears to me that the cleanest approach will still > > > be to use the template approach. This allows us to reduce > > > the number of subscribes to match the number of event > > > packages supported by the UA. This is still much smaller > > > than the number of URIs being subscribed to, and appears > > > to require far less standardization. > > > > This reduces the number of subscriptions issued by UACs. But > > it doesn't reduce the number of total subscriptions - it > > increases it. And it doesn't reduce the number of > > notifications received by the UAC (well, its actually a UAS > > for the notify, but you know what I mean.) > > This is true for both the collection package and the collection > template-package approach. > > This is a known architectural result of the approach being > pursued. If operators don't want to support this, they can > disable whatever collection mechanisms are available on their > servers; this would force the clients to either not subscribe > or to fall back to sending individual subscriptions instead > of subscriptions to collections. > > > It might even increase the number of notifications further - > > if the collection refreshes its subscription to each member > > of the collection before it expires, and also refreshes each > > subscription when the UAC refreshes its subscription to the > > collection. > > This is true for both the collection package and the collection > template-package approach. > > I would expect reasonable implementations of servers that aggregate > these subscription collections to not pass along information unless > it has actually been updated. This means that if it is using > SUBSCRIBE on the back-end to learn about state, it won't send the > resulting NOTIFY messages to the collection subscriber unless the > NOTIFY actually represented a change in state. > > I would NOT expect the server that agregates these subscriptions > to automatically refresh their subscription to the members of > the subscription every time the the UAC refreshes its subscription > to the collection. > > > This situation could be improved if the collection can be > > set, via filters or whatever, to normally return only changes. > > This is true for both the collection package and the collection > template-package approach. > > I would expect this to be the normal mode of operation, in fact. > > What I *would* hope to be able to do via filters is say something > like "when you get a state change, hold off 30 seconds before > sending it to me, in case you get additional changes that you > might be able to send in the same message" or something like that. > > > It could be improved vastly in some cases if many collections > > have elements in common, and the server is permitted to > > multiplex one subscription to a collection element across > > many containing collections. Moreso if the lifetime of the > > subscriptions the collection server makes are independent of > > those to the collections it serves. > > This is true for both the collection package and the collection > template-package approach. > > > Of course there is a problem with this. If you and I both > > subscribe to X, we may get different results based on who we > > are. If we both subscribe to collection CX, is the data > > delivered to the collection server on our behalf the same as > > we would have gotten directly? Or is the data delivered to > > the collection server by X based on the identity of the > > collection server? > > This is true for both the collection package and the collection > template-package approach. > > After studying this problem for an extended period of time, I > have reached the conclusion that this sort of aggregation doesn't > generally work. The permissions problems that arise from doing > this are pretty much intractible unless you make some walled- > garden type assumptions about how servers are going to protect > the data they receive in this way. > > Was your letter trying to differentiate the package approach from > the template-package approach? That is what context would imply, > but the content doesn't seem to live up to that expectation. Or > were you just trying to raise issues with the idea of subscription > collections regardless of which approach is taken? > > /a > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple -- 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@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 02:54:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06000 for ; Tue, 17 Sep 2002 02:54:00 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8H6sQMN004756; Tue, 17 Sep 2002 02:54:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04183; Tue, 17 Sep 2002 02:55:04 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04170 for ; Tue, 17 Sep 2002 02:54:25 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8H6sLT18493 for ; Tue, 17 Sep 2002 09:54:21 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Sep 2002 09:54:09 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Sep 2002 09:54:09 +0300 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" Subject: RE: [Simple] collection template Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901944FC8@esebe013.ntc.nokia.com> Thread-Topic: [Simple] collection template Thread-Index: AcJdrqTQ3BxmWQmmRGqyXer4Ua2CeAAZwHQg To: , , X-OriginalArrivalTime: 17 Sep 2002 06:54:09.0389 (UTC) FILETIME=[05C599D0:01C25E17] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id CAA04170 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 09:54:08 +0300 Content-Transfer-Encoding: 8bit Hi Adam, > I appear to have missed the proposal you're referring to, and > I can't find it in the i-d archives. Yes, it's not in the draft, but the issue was discussed in Yokohama. > The way 3265 is defined, if you subscribe to "presence.collection", > you get notifies for "presence.collection". You *never* get > notifies for "presence" because you did not subscribe to "presence". The issue was with recursing of presence.collection subscriptions, i.e., if a URI in the buddy-list was itself a list of URIs, you could potentially recurse the subscription until it reached the "leaf" and defaulted to the presence event of that URI. However, the above looks like something destined not to work. Now I forget the other option that was presented as possible solution for this recursing problem... > This is an important property of templates. It allows for generic > implementation of them. For example, you can easily see how > it might be useful to subscribe to "foo.winfo" without even > necessarily knowing the semantics behind the "foo" package. Yes, this is very clear. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 04:26:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07493 for ; Tue, 17 Sep 2002 04:26:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8H8RRMN005065; Tue, 17 Sep 2002 04:27:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04542; Tue, 17 Sep 2002 04:28:04 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04531 for ; Tue, 17 Sep 2002 04:27:03 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8H8R4YH024723; Tue, 17 Sep 2002 04:27:04 -0400 (EDT) Message-ID: <3D86E757.4060208@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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: Adam Roach CC: "'Sean Olson'" , aki.niemi@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64153@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 04:27:03 -0400 Content-Transfer-Encoding: 7bit Adam Roach wrote: >> -----Original Message----- From: Sean Olson >> [mailto:seancolson@yahoo.com] >> >> At the very least, I would not rely on the Accept headers for a >> pseudo-negotiation. Instead, I would turn to an appropriate >> "filter" for the body of the SUBSCRIBE to create a meta-level of >> negotiation. This is already feeling too complex to me, but we >> should make this as clean a design as possible. > > > I think Sean's hit on the thing that's bothering me here: we're > overloading the semantics of headers here. We've made this mistake in > the past, and should now recognize it as such. I agree that we should not overload these things. I am really trying to flesh this idea out some more to see how much merit it does or doesn't have. It does have a clear benefit in reducing client to server traffic, as the only one advantage over the template approach. The right way to think about the collection package is to forget about fanout. The fanout of subscriptions represents one, but not the only, way in which the server can find out about the state of the thing thats being subscribed to. In this case, the thing is a list of resources, which is itself a resource, called a collection. What differentiates a collection as a resource from other resources is that its state is described by a variety of different document formats, rather than a small number that is bound to the package itself. Event package negotiation is per the spec; this resource could potentially support a variety of event packages beyond the collection package. Now, like any other resource, if you SUBSCRIBE to it, but don't list a document format in the Accept header thats needed to understand events generated by that resource, the subscription fails. Same here. If I list a set of document formats in my SUBSCRIBE that doesn't cover the full set of formats I need to understand events generated by that resource, the subscription fails. How the server determines whether that list is correct, is its own choice. It could copy the Accept header into fanned-out subscriptions as I suggested. Or, it could know the types for each package and reject the subscription outright if it finds one missing. So, in this way of thinking about a collection package, there is no such thing as negotiating packages for the fanned out subscriptions between the the UAC and the actual notifiers. Each leg negotiates its packages independently. A collection does appear to represent a well-defined package. It would define its own default subscription duration. It has a well-defined treatment for forked requests (not allowed). It would have its own notification rates; the entire point of the package is to buffer package-specific notification rates and have one independent one. State agents would make no sense in this package. Filters would allow you to specify what aspect of the resource you do or don't want to know about; this would provide the mechanism, for example, to request more frequent presence updates and less frequent MWI updates. So, I think its a reasonable package definition. However, there is no doubt that its somewhat of a hack. I would welcome thoughts on other specific problems that arise with it, to determine if it makes sense or not. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 08:02:04 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11396 for ; Tue, 17 Sep 2002 08:02:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HC2SMN005477; Tue, 17 Sep 2002 08:02:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05143; Tue, 17 Sep 2002 08:03:03 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05127 for ; Tue, 17 Sep 2002 08:02:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11334; Tue, 17 Sep 2002 08:00:31 -0400 (EDT) Message-Id: <200209171200.IAA11334@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-sip-message-07.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 08:00:31 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension for Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-sip-message-07.txt Pages : 22 Date : 2002-9-16 Instant Messageing (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The MESSAGE method is an extension to the Session Initation Protocol (SIP) that allows the transfer of Instant Messages. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. Since the MESSAGE request is an extension to SIP it inherits all the request routing and security features of that protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sip-message-07.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-sip-message-07.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: <2002-9-16152033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-16152033.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 09:34:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14357 for ; Tue, 17 Sep 2002 09:34:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HDXgMN005952; Tue, 17 Sep 2002 09:33:42 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05432; Tue, 17 Sep 2002 09:34:18 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05421 for ; Tue, 17 Sep 2002 09:33:00 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HDX5fW008097; Tue, 17 Sep 2002 09:33:06 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAQ97827; Tue, 17 Sep 2002 09:37:37 -0400 (EDT) Message-ID: <3D872F01.1E3CF514@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Sean Olson'" , aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64158@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 09:32:49 -0400 Content-Transfer-Encoding: 7bit below... Paul Adam Roach wrote: > > Was your letter trying to differentiate the package approach from > the template-package approach? That is what context would imply, > but the content doesn't seem to live up to that expectation. Or > were you just trying to raise issues with the idea of subscription > collections regardless of which approach is taken? The latter. > > It could be improved vastly in some cases if many collections > > have elements in common, and the server is permitted to > > multiplex one subscription to a collection element across > > many containing collections. Moreso if the lifetime of the > > subscriptions the collection server makes are independent of > > those to the collections it serves. > > This is true for both the collection package and the collection > template-package approach. > > After studying this problem for an extended period of time, I > have reached the conclusion that this sort of aggregation doesn't > generally work. The permissions problems that arise from doing > this are pretty much intractible unless you make some walled- > garden type assumptions about how servers are going to protect > the data they receive in this way. I'm inclined to agree, but I keep looking for a way to make it work, because otherwise there are significant scaling problems with highly interconnected collections of users - its something like O(n^2). There is a permissions problem even if you don't aggregate this way. In order for the permissions to be evaluated in a straightforward way, the server for a collection will need to represent itself as the user who subscribed to the collection, or as an agent that has been explicitly authorized to act on behalf of that user. I don't see an obvious way to do that other than for each user to provide the collection server with one of his secret keys, or else to have the end user sign a certificate for the collection server. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 10:06:08 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15377 for ; Tue, 17 Sep 2002 10:06:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HE6PMN006144; Tue, 17 Sep 2002 10:06:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05552; Tue, 17 Sep 2002 10:07:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05541 for ; Tue, 17 Sep 2002 10:06:48 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HE6s38014850; Tue, 17 Sep 2002 10:06:55 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAQ98277; Tue, 17 Sep 2002 10:11:26 -0400 (EDT) Message-ID: <3D8736EE.B4FA33FE@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Adam Roach , "'Sean Olson'" , aki.niemi@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64153@DYN-TX-EXCH-001.dynamicsoft.com> <3D86E757.4060208@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 10:06:38 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > A collection does appear to represent a well-defined package. It would > define its own default subscription duration. It has a well-defined > treatment for forked requests (not allowed). It would have its own > notification rates; the entire point of the package is to buffer > package-specific notification rates and have one independent one. State > agents would make no sense in this package. There is one way that it is not like a well-defined package: With a normal event package, when you send a subscription you get back an initial notification that is supposed to represent the full state of the subscribed resource, and if your subscription is a poll (Expires:0), then you expect to get only the one notification. With the collection package as I think you are proposing it (or even the collection template) this isn't really the case. The initial subscription might result in a bunch of notifications, each carrying part of the state of the collection as a whole. This could be fixed in various ways: - the collection server could buffer the responses from all the members of the collection and return everything in a single multipart response. - we could change rfc 3265 so that the first notify in response to a subscribe isn't necessarily obligated to report the full current resource state. - (are there other ways???) Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 10:23:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16593 for ; Tue, 17 Sep 2002 10:23:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HEORMN006308; Tue, 17 Sep 2002 10:24:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05628; Tue, 17 Sep 2002 10:25:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05615 for ; Tue, 17 Sep 2002 10:24:18 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HEOT7l018811 for ; Tue, 17 Sep 2002 10:24:29 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAQ98540; Tue, 17 Sep 2002 10:29:00 -0400 (EDT) Message-ID: <3D873B0C.48F6DD00@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-sip-message-07.txt References: <200209171200.IAA11334@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 10:24:12 -0400 Content-Transfer-Encoding: 7bit From Section 13.1 (Changes introduced in draft-ietf-sip-message-07): Prohibition against creating dialogs primarily to carry MESSAGE requests reduced to SHOULD strength. Why was this change made? This seems to be opening a can of worms. After lengthly discussion about IM sessions, it seems that IM sessions using SIP as a transport won't create a dialog for conveying the MESSAGEs. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 10:32:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16913 for ; Tue, 17 Sep 2002 10:32:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HEXOMN006401; Tue, 17 Sep 2002 10:33:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05680; Tue, 17 Sep 2002 10:34:04 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05668 for ; Tue, 17 Sep 2002 10:33:58 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8HEYGZ28177 for ; Tue, 17 Sep 2002 17:34:16 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Sep 2002 17:33:57 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Sep 2002 17:33:56 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Sep 2002 17:33:56 +0300 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" Subject: RE: [Simple] some additions to the authorization requirements Message-ID: Thread-Topic: [Simple] some additions to the authorization requirements Thread-Index: AcJaoU01necLEIpxQSCxMhXqHY9FSQDshkEQ To: , X-OriginalArrivalTime: 17 Sep 2002 14:33:56.0237 (UTC) FILETIME=[40D08BD0:01C25E57] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA05668 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 17:33:55 +0300 Content-Transfer-Encoding: 8bit Hi, I think the concrete authorization requirements also depend on the structure of the content being authorized. In my opinion it should be possible to decide which tuples the subscriber would be allowed to receive. (For example I don't want to show everybody that I'm right now available for voice calls.) The differentiation would need to happen based on contact address and in addition based on COMMUNICATION MEANS. As the SIMPLE PIDF profile is not yet defined, it is a bit difficult to give the exact wording but I would suggest something like this: * the user should be able to specify that the subscriber will only receive notifications containing a combination of a specific contact address and a specific related communication mean. (i.e. only instant messaging but not voice related information.) Regarding filtering, I think the end result that is delivered to the subscriber should be the combination of subscriber filter and the authorization decision. I'm not sure if accept/reject type of decision is needed for the filter at all, but the authorization could just set further filters/restrictions. Regards, Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 13 September, 2002 0:11 > To: simple@mailman.dynamicsoft.com > Subject: [Simple] some additions to the authorization requirements > > > Folks, > > I'd like to seriously beef up the authorization requirements > section of > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-dat > a-req-00.txt > to discuss a lot more of the specifics we want to accomplish. > > The key thing is details on the level of permissions that are being > granted by the presentity. Some additional requirements to consider: > > * the user should be able to specify that the subscriber will only > receive notifications containing a specific contact address > (i.e., only > my work phone) > > * the user should be able to specify that the subscriber will only > receive notifications containing a specific status type (basic, for > example, which is the only status type defined so far). > > * the user should be able to specify that the subscriber will only > receive notifications containing specific values of a specific status > type (for example, only report when my status goes to OPEN, > not CLOSED) > > * the user should be able to specify that the subscriber will or will > not receive a contact address in the notifications. > > > Effectively, the above rules all specify filters or triggers on the > presence documents that should be sent to a particular presentity. > > We could specify rate-based filters (i.e., specify that a subscriber > cannot receive documents more frequently than X per minute), but this > doesn't seem awfully useful. > > > Related to that, if the SUBSCRIBE contained a filter of some > sort, the > authorization should allow the user to approve or reject > their filter, > and possibly impose further filtering as above. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 11:36:04 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19348 for ; Tue, 17 Sep 2002 11:36:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HFaSMN006807; Tue, 17 Sep 2002 11:36:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05915; Tue, 17 Sep 2002 11:37:04 -0400 (EDT) Received: from smtp-relay (mail1.eivd.ch [193.134.216.148]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05900 for ; Tue, 17 Sep 2002 11:36:08 -0400 (EDT) Received: from edupc043 ([10.192.73.43]) by smtp-relay (1.0/YCOM SA SMTPGateway 1.31) with SMTP id g8HFa4k0017813 for ; Tue, 17 Sep 2002 17:36:05 +0200 Reply-To: From: "Schweizer" To: Message-ID: <000601c25e60$7ae5ff40$2b49c00a@edupc043> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C25E71.3E711930" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MS-TNEF-Correlator: 000000000B71C6C953B3F04CA29F422101B1C5AD644E6A00 Importance: Normal X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: [Simple] state of user in cpim ? Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 17:39:58 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C25E71.3E711930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, How can i indicate in CPIM the state of a user ? I see in the example 4.3.1 ( CPIM draft 05 ) in the "status" element busy , but this element "im" is not from this draft. Schweizer Laurent ------=_NextPart_000_0007_01C25E71.3E711930 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjsPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHCQARABEAJwAAAAIALQEB A5AGAIQFAAAmAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAGAAAAHN0YXRlIG9mIHVzZXIgaW4gY3BpbSA/AAIBcQABAAAAFgAAAAHCXmB6SEjo+6ixhUCl p0whisX1MUAAAAIBHQwBAAAAHwAAAFNNVFA6TEFVUkVOVC5TQ0hXRUlaRVJARUlWRC5DSAAACwAB DgAAAABAAAYOAIKjV2BewgECAQoOAQAAABgAAAAAAAAAC3HGyVOz8Eyin0IhAbHFrcKAAAADABQO AQAAAAsAHw4BAAAAAgEJEAEAAAAhAQAAHQEAAIABAABMWkZ1drXi/gMACgByY3BnMTI1FjIA+Atg bg4QMDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGAOYwBQCwMLtSBIZWyd CQAsCqIKhAqASG8H4DpjA5FpFWASgA3gYXQCZRWBIENQSU0gNHRoFgBzAZAV8W9msCBhIHURIAXA PwrjPRR2SRbQCeAWEhaiZXgMYW0LUBYANC4zLogxICgWRGRyYQGAoCAwNSApGRYiFuJ9F5AiGYAZ 4AeAAjAX9TxFB3A6B3A+IGIXkHnoIDwvHYQsHeEFQBagOwQAHIciB3AccB9Bbm+vBUADUh8UGuMu F/tTEOCQd2VpehexTGEIcC8c0RQ6FDQR4QAk8AAAAAMACVkDAAAACwAAgAggBgAAAAAAwAAAAAAA AEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAA AMAAAAAAAABGAAAAAFKFAAAnagEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAA OS4wAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAuACCAGAAAAAADA AAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEA AAABAAAAAAAAAAsAEYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwASgAggBgAAAAAAwAAA AAAAAEYAAAAAAYUAAAAAAAALABuACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAHIAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAegAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAC AfgPAQAAABAAAAALccbJU7PwTKKfQiEBscWtAgH6DwEAAAAQAAAAC3HGyVOz8Eyin0IhAbHFrQIB +w8BAAAAmwAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoA N9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5nc1xBZG1pbmlzdHJhdG9yXExvY2FsIFNldHRp bmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcbWFpbGJveC5wc3QAAAMA/g8F AAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDBCNzFDNkM5NTNCM0YwNENBMjlGNDIyMTAx QjFDNUFENjQ0RTZBMDAAAAAAAwAGEMPz8S4DAAcQpQAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAA AGUAAABIRUxMTyxIT1dDQU5JSU5ESUNBVEVJTkNQSU1USEVTVEFURU9GQVVTRVI/SVNFRUlOVEhF RVhBTVBMRTQzMShDUElNRFJBRlQwNSlJTlRIRSJTVEFUVVMiRUxFTUVOVDxJTTpJAAAAAKkY ------=_NextPart_000_0007_01C25E71.3E711930-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 11:46:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19655 for ; Tue, 17 Sep 2002 11:46:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HFkQMN006955; Tue, 17 Sep 2002 11:46:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05996; Tue, 17 Sep 2002 11:47:04 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05985 for ; Tue, 17 Sep 2002 11:46:05 -0400 (EDT) From: EXT-Hemish.Parikh@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8HFkTM07195 for ; Tue, 17 Sep 2002 10:46:29 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Sep 2002 10:46:02 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Sep 2002 10:45:11 -0500 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" Message-ID: Thread-Index: AcJeYTR0ykVEW/UIRLqhM6Mbq+l0VA== To: X-OriginalArrivalTime: 17 Sep 2002 15:45:11.0400 (UTC) FILETIME=[3502A680:01C25E61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA05985 Subject: [Simple] (no subject) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 11:45:10 -0400 Content-Transfer-Encoding: 8bit Hi I have a scenario here as described: SIP is being used in Tunneling mode for Instant messaging in a 3G system. As I understand form TS24.229 of 3GPP, SGSN/GGSN acting as SIP proxies change the outer header fields like 'Content Type'. If yes then, now the outer header fields are different from the inner header fields. How the receiving UAS deal with this. Appreciate suggestions. Hemish Parikh Nokia Research Center Tel: 781-993 5752 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 11:57:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19967 for ; Tue, 17 Sep 2002 11:57:58 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HFwRMN007104; Tue, 17 Sep 2002 11:58:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06070; Tue, 17 Sep 2002 11:59:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06059 for ; Tue, 17 Sep 2002 11:58:32 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HFvoNo008496; Tue, 17 Sep 2002 11:57:50 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 10:58:27 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64160@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: "'Sean Olson'" , aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 10:58:25 -0500 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > It could be improved vastly in some cases if many collections > > > have elements in common, and the server is permitted to > > > multiplex one subscription to a collection element across > > > many containing collections. Moreso if the lifetime of the > > > subscriptions the collection server makes are independent of > > > those to the collections it serves. > > > > After studying this problem for an extended period of time, I > > have reached the conclusion that this sort of aggregation doesn't > > generally work. The permissions problems that arise from doing > > this are pretty much intractible unless you make some walled- > > garden type assumptions about how servers are going to protect > > the data they receive in this way. > > I'm inclined to agree, but I keep looking for a way to make > it work, because otherwise there are significant scaling > problems with highly interconnected collections of users - > its something like O(n^2). That's true. It's a general truth that comes with any model of presence that allows users to set policy that is different for different sets of watchers, regardless of whether you use collections. Let's consider a system of two servers, each of which has three clients. Each client has a subscription to all five other clients. With collections, the number of subscriptions between each node is as follows: +----+ 18 +----+ | S1 |------------------| S2 | +----+ +----+ 2 / 2| 2\ 2/ 2| 2\ / | \ / | \ +----+ +----+ +----+ +----+ +----+ +----+ | C1 | | C2 | | C3 | | C4 | | C5 | | C6 | +----+ +----+ +----+ +----+ +----+ +----+ Each client has a collection subscription to its server; each server has either a non-collection subscription to each of its clients or a publication relationship. I'm going to consider them to be about as heavy as each other. I'm making an assumption that clients trust their own server to honor their privacy policies, instead of implementing all privacy at the peer level. Given these assumptions, we have a total of 30 subscriptions in the system. It should also be obvious, as you state, that the number of subscriptions in the system increases at the rate of about O(n^2). Now, let's look at the same system without collection subscriptions. (Sorry; the limitations of ASCII art show up here). ---------------------- /3 \ / +----+ +----+ +----+ / -------| C4 | | C5 | | C6 | / /3 +----+ +----+ +----+ / / 3\/ 3| 3/ / / 3 /\ | / +----+---------------- +----+ | S1 | ---------------| S2 | +----+ /3 --------+----+ 3/ 3| 3\/ /3 / / | /\ / / +----+ +----+ +----+ / | C1 | | C2 | | C3 | / +----+ +----+ +----+ / \ 3/ ------------------- Here, each client has two subscriptions to its local server (one for each other client attached to that server), and the server has either a subscription to or a publication relationship with each of its clients. Each client additionally has three subscriptions to the remote server (one for each of its clients), leading to 18 interdomain subscriptions (exactly like before). In total, then, this system -- the one without collections -- has 36 total subscriptions. It should also be obvious that this system will increase the total number of subscriptions at the rate of approximately O(n^2). So, yes, you've hit on the fundamental scaling problem inherent in presence systems. Collections neither worsen nor significantly improve this. What collections *do* accomplish is reduction of the traffic from the client to the server. If you go through the excercise of increasing the size of the systems I've diagrammed above, you'll notice that the system with collections keeps the relationship between the client and the server(s) to 2 subscriptions (or one subscription and one publication relationship), while the system without collections increases this realationship linearly as you add users. > There is a permissions problem even if you don't aggregate > this way. In order for the permissions to be evaluated in a > straightforward way, the server for a collection will need to > represent itself as the user who subscribed to the > collection, or as an agent that has been explicitly > authorized to act on behalf of that user. I don't see an > obvious way to do that other than for each user to provide > the collection server with one of his secret keys, or else to > have the end user sign a certificate for the collection server. Now this *is* an interesting problem. If this problem is tractible (and it feels like it should be), then we're home free. I'll leave it to the security guys to comment on whether this sort of limited delegation is something that's feasible. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 14:29:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25194 for ; Tue, 17 Sep 2002 14:29:11 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HITTMN007877; Tue, 17 Sep 2002 14:29:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06596; Tue, 17 Sep 2002 14:30:05 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06583 for ; Tue, 17 Sep 2002 14:29:54 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HITffJ010631; Tue, 17 Sep 2002 14:29:43 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAR01391; Tue, 17 Sep 2002 14:33:55 -0400 (EDT) Message-ID: <3D877473.FD1779B5@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Sean Olson'" , aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64160@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 14:29:07 -0400 Content-Transfer-Encoding: 7bit Adam, Nice ascii art! (It's too much work, so I avoid it when I can.) I've extracted portions of your message and commented on them below. Paul Adam Roach wrote: > > > There is a permissions problem even if you don't aggregate > > this way. In order for the permissions to be evaluated in a > > straightforward way, the server for a collection will need to > > represent itself as the user who subscribed to the > > collection, or as an agent that has been explicitly > > authorized to act on behalf of that user. I don't see an > > obvious way to do that other than for each user to provide > > the collection server with one of his secret keys, or else to > > have the end user sign a certificate for the collection server. > > Now this *is* an interesting problem. If this problem is > tractible (and it feels like it should be), then we're home > free. I'll leave it to the security guys to comment on whether > this sort of limited delegation is something that's feasible. I think you partially misunderstood me, or else I misunderstand you. I think there is a problem getting the setup from your first picture to work at all. > Let's consider a system of two servers, > each of which has three clients. Each client has a subscription > to all five other clients. > > With collections, the number of subscriptions between each > node is as follows: > > +----+ 18 +----+ > | S1 |------------------| S2 | > +----+ +----+ > 2 / 2| 2\ 2/ 2| 2\ > / | \ / | \ > +----+ +----+ +----+ +----+ +----+ +----+ > | C1 | | C2 | | C3 | | C4 | | C5 | | C6 | > +----+ +----+ +----+ +----+ +----+ +----+ If I understand your intent, S1 is both a presence server for C1..C3 and a server for the collections that C1..C3 use, and similarly for S2 and C4..C6. So lets pick one case out of this. C1 has a subscription to a collection hosted by S1 that references the presence of C2...C6. To honor this one of the things S1 does is make a subscription to S2 regarding C4. Now S2 is acting on behalf of C4 in this case, and needs to identify who the subscriber is in order to decide whether to accept it and what information to divulge. S1, acting on behalf of C1, needs to identify who is making the request, presumably using the From header and some credentials. So, what does S1 put in the From header, and what credentials does it use? For the From header there are two obvious possibilities: the URI of C1 or the URI of S1. The credentials could be unique to C1, or might only identify S1. There are then four possible combinations of these: From Credentials ---- ----------- 1) C1 C1 2) C1 S1 3) S1 C1 4) S1 S1 At least one of the two needs to identify C1, so the proper access decision can be made, which excludes (4). Case (2) is appealing because it doesn't require S1 to hold separate credentials for every client it serves. But it is pretty dicey too because it is difficult for S2 to know whether to accept it as a valid credential for C1. For either (1) or (3) S1 must hold credentials and the corresponding secret for each client serves. (This starts to get into the area that John Ramsdell has been concerned with.) If C1 is going to let S1 have such credentials, there probably must be limitations on them. C1 isn't going to want to let S1 do anything and everything on its behalf. It is going to want to restrict S1 to doing certain things - in this case simply subscribing to presence, possibly with further restrictions. Then of course S1 must obtain the credential it uses to act on behalf of C1 somewhow, and S2 must know how to recognize such a credential and decide whether to honor it. This all adds complexity to the use of collections. (Whether they are templates or not.) Do you see a reasonable way to approach this problem of credentials? An alternative is to simple have collection servers act on their own behalf. The server could use its own identity to subscribe to the members of a collection, and could make its own decisions about who to accept collection subscriptions from. Done this way, the members of all the collections it serves can be pooled, with a single subscription to each regardless of how many clients it serves. The major limitation of this approach is that all clients of the same collection server don't have their own identity exposed to and taken into account by the specific collection members. The main advantages are a simplification in the security model and possibly a large reduction in the total number of subscriptions and notifications in the system. Clearly this model wouldn't work for all applications. But it might work in some important cases. Whether these cases are important enough to pursue is questionable. Repeating your comment: > Now this *is* an interesting problem. If this problem is > tractible (and it feels like it should be), then we're home > free. I'll leave it to the security guys to comment on whether > this sort of limited delegation is something that's feasible. I'd like to hear from them too, because I am pretty naive about security. But I don't see what your plan of attack is if this *isn't* tractible. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 17 14:37:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25461 for ; Tue, 17 Sep 2002 14:37:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HIcPMN007981; Tue, 17 Sep 2002 14:38:25 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06643; Tue, 17 Sep 2002 14:39:03 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06632 for ; Tue, 17 Sep 2002 14:38:35 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g8HIcEpA058813; Tue, 17 Sep 2002 13:38:15 -0500 (CDT) Message-ID: <3D877652.2050601@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-sip-message-07.txt References: <200209171200.IAA11334@ietf.org> <3D873B0C.48F6DD00@cisco.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 13:37:06 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: >>From Section 13.1 (Changes introduced in draft-ietf-sip-message-07): > > Prohibition against creating dialogs primarily to carry MESSAGE > requests reduced to SHOULD strength. > > Why was this change made? This seems to be opening a can of worms. After lengthly discussion about IM sessions, it seems that IM sessions using SIP as a transport won't create a dialog for conveying the MESSAGEs. > Well, it still says you SHOULD NOT do it. People brought up possible legitimate applications of the concept for some very specific circumstances. Changing the language was a compromise. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 18 03:14:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04812 for ; Wed, 18 Sep 2002 03:14:06 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8I7EVMN010227; Wed, 18 Sep 2002 03:14:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08802; Wed, 18 Sep 2002 03:15:08 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08789 for ; Wed, 18 Sep 2002 03:14:45 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8I7EeT04751 for ; Wed, 18 Sep 2002 10:14:40 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Sep 2002 10:12:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 10:12:19 +0300 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" Subject: RE: [Simple] collection template Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20640@esebe019.ntc.nokia.com> Thread-Topic: [Simple] collection template Thread-Index: AcJeZGAiWDnZxfQ8Tz2OEUXDdece0QAee5OQ To: , Cc: , , , X-OriginalArrivalTime: 18 Sep 2002 07:12:19.0587 (UTC) FILETIME=[B9FE5D30:01C25EE2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA08789 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 18 Sep 2002 10:12:18 +0300 Content-Transfer-Encoding: 8bit You left out one scenario (the one we should really be comparing to collection as a package), which is the one that uses collection as a template. It very much looks like your first diagram, if its for one type of package like presence. The numbers increase slightly if there is more than one base package that need to use the collection template. Besides the security issues and who authenticates/authorises who, there is the issue of filtering. Each package like presence, mwi, winfo or whatever might have its own filtering that needs to be apply. A collection package does not help is this situation. Subscription duration: What is the behaviour when a SUBSCRIBE for collection package is used and the fanned out subsriptions resulted in lower expiration intervals than the interval sent in the original SUBSCRIBE to the collection package? This is probably a case for both types of collection packages, but I see much more complicated when the subscription is for 2 or more different types of services. Regards, Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Tuesday, September 17, 2002 6:58 PM > To: 'Paul Kyzivat'; Adam Roach > Cc: 'Sean Olson'; Niemi Aki (NET/Espoo); Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] collection template > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > > It could be improved vastly in some cases if many collections > > > > have elements in common, and the server is permitted to > > > > multiplex one subscription to a collection element across > > > > many containing collections. Moreso if the lifetime of the > > > > subscriptions the collection server makes are independent of > > > > those to the collections it serves. > > > > > > After studying this problem for an extended period of time, I > > > have reached the conclusion that this sort of aggregation doesn't > > > generally work. The permissions problems that arise from doing > > > this are pretty much intractible unless you make some walled- > > > garden type assumptions about how servers are going to protect > > > the data they receive in this way. > > > > I'm inclined to agree, but I keep looking for a way to make > > it work, because otherwise there are significant scaling > > problems with highly interconnected collections of users - > > its something like O(n^2). > > That's true. It's a general truth that comes with any model of > presence that allows users to set policy that is different > for different sets of watchers, regardless of whether you > use collections. Let's consider a system of two servers, > each of which has three clients. Each client has a subscription > to all five other clients. > > With collections, the number of subscriptions between each > node is as follows: > > +----+ 18 +----+ > | S1 |------------------| S2 | > +----+ +----+ > 2 / 2| 2\ 2/ 2| 2\ > / | \ / | \ > +----+ +----+ +----+ +----+ +----+ +----+ > | C1 | | C2 | | C3 | | C4 | | C5 | | C6 | > +----+ +----+ +----+ +----+ +----+ +----+ > > Each client has a collection subscription to its server; each > server has either a non-collection subscription to each of its > clients or a publication relationship. I'm going to consider them > to be about as heavy as each other. I'm making an assumption that > clients trust their own server to honor their privacy policies, > instead of implementing all privacy at the peer level. > > Given these assumptions, we have a total of 30 subscriptions > in the system. It should also be obvious, as you state, that > the number of subscriptions in the system increases at the rate > of about O(n^2). > > Now, let's look at the same system without collection subscriptions. > (Sorry; the limitations of ASCII art show up here). > > ---------------------- > /3 \ > / +----+ +----+ +----+ > / -------| C4 | | C5 | | C6 | > / /3 +----+ +----+ +----+ > / / 3\/ 3| 3/ > / / 3 /\ | / > +----+---------------- +----+ > | S1 | ---------------| S2 | > +----+ /3 --------+----+ > 3/ 3| 3\/ /3 / > / | /\ / / > +----+ +----+ +----+ / > | C1 | | C2 | | C3 | / > +----+ +----+ +----+ / > \ 3/ > ------------------- > > Here, each client has two subscriptions to its local server > (one for each other client attached to that server), and the > server has either a subscription to or a publication relationship > with each of its clients. Each client additionally has three > subscriptions to the remote server (one for each of its clients), > leading to 18 interdomain subscriptions (exactly like before). > In total, then, this system -- the one without collections -- > has 36 total subscriptions. It should also be obvious that this > system will increase the total number of subscriptions at the > rate of approximately O(n^2). > > So, yes, you've hit on the fundamental scaling problem inherent > in presence systems. Collections neither worsen nor significantly > improve this. What collections *do* accomplish is reduction of > the traffic from the client to the server. If you go through > the excercise of increasing the size of the systems I've diagrammed > above, you'll notice that the system with collections keeps the > relationship between the client and the server(s) to 2 > subscriptions (or one subscription and one publication relationship), > while the system without collections increases this realationship > linearly as you add users. > > > There is a permissions problem even if you don't aggregate > > this way. In order for the permissions to be evaluated in a > > straightforward way, the server for a collection will need to > > represent itself as the user who subscribed to the > > collection, or as an agent that has been explicitly > > authorized to act on behalf of that user. I don't see an > > obvious way to do that other than for each user to provide > > the collection server with one of his secret keys, or else to > > have the end user sign a certificate for the collection server. > > Now this *is* an interesting problem. If this problem is > tractible (and it feels like it should be), then we're home > free. I'll leave it to the security guys to comment on whether > this sort of limited delegation is something that's feasible. > > /a > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 18 06:22:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07635 for ; Wed, 18 Sep 2002 06:22:58 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8IANRMN010644; Wed, 18 Sep 2002 06:23:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09373; Wed, 18 Sep 2002 06:24:04 -0400 (EDT) Received: from m3102.hostcentric.net (m3102.hostcentric.net [216.157.79.140]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id GAA09362 for ; Wed, 18 Sep 2002 06:23:10 -0400 (EDT) Received: (qmail 7838 invoked by alias); 18 Sep 2002 10:23:11 -0000 Received: from unknown (HELO m3001.hostcentric.net) (216.157.79.237) by 0 with SMTP; 18 Sep 2002 10:23:11 -0000 Received: (qmail 27901 invoked by alias); 18 Sep 2002 10:23:11 -0000 Received: from unknown (HELO indigosw.com) (217.136.220.14) by 0 with SMTP; 18 Sep 2002 10:23:11 -0000 Message-ID: <3D8853BD.2080604@indigosw.com> From: Torrey Searle Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] collection template Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 18 Sep 2002 12:21:49 +0200 Content-Transfer-Encoding: 7bit For the inital subscribe to a Template, would it be possible to just send the list of people in the collection w/o the actuall state? IE a presence-list of presence elements w/o tuples. It would seem like an appropriate time to get the "collection list" from the server, w/o having to guess it from subsquent partial notifies. Torrey Searle Indigo Software _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 18 13:47:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23373 for ; Wed, 18 Sep 2002 13:47:29 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8IHlaMN012366; Wed, 18 Sep 2002 13:47:38 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10639; Wed, 18 Sep 2002 13:48:08 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10628 for ; Wed, 18 Sep 2002 13:47:37 -0400 (EDT) From: EXT-Hemish.Parikh@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8IHlvZ10568 for ; Wed, 18 Sep 2002 20:47:58 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Sep 2002 20:47:35 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 20:47:35 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 12:47:33 -0500 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" Message-ID: Thread-Index: AcJeYTR0ykVEW/UIRLqhM6Mbq+l0VAA2c8Nw To: X-OriginalArrivalTime: 18 Sep 2002 17:47:33.0418 (UTC) FILETIME=[779B70A0:01C25F3B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA10628 Subject: [Simple] FW: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 18 Sep 2002 13:47:32 -0400 Content-Transfer-Encoding: 8bit Please disregard the email below - the scenario was flawed. - Hemish > -----Original Message----- > From: Parikh Hemish (EXT-NRC/Boston) > Sent: Tuesday, September 17, 2002 11:45 AM > To: 'simple@mailman.dynamicsoft.com' > Subject: > > Hi > > I have a scenario here as described: SIP is being used in Tunneling mode for Instant messaging in a 3G system. As I understand form TS24.229 of 3GPP, SGSN/GGSN acting as SIP proxies change the outer header fields like 'Content Type'. If yes then, now the outer header fields are different from the inner header fields. How the receiving UAS deal with this. > > Appreciate suggestions. > > Hemish Parikh > Nokia Research Center > Tel: 781-993 5752 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 18 13:50:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23505 for ; Wed, 18 Sep 2002 13:50:59 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8IHpTMN012440; Wed, 18 Sep 2002 13:51:29 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10701; Wed, 18 Sep 2002 13:52:10 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10655 for ; Wed, 18 Sep 2002 13:50:09 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8IHnTNo015198; Wed, 18 Sep 2002 13:49:29 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 12:50:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64171@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Adam Roach , pkyzivat@cisco.com Cc: seancolson@yahoo.com, aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 18 Sep 2002 12:49:57 -0500 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > You left out one scenario (the one we should really be > comparing to collection as a package), which is the one that > uses collection as a template. No, my first scenario is covering "collection." It doesn't matter if it's "collection as a package" or "collection as a template." The purpose of the message to which you replied was to refute the implied assertion that collections (of any kind) increase the overall number subscriptions in a system. My message was *not* attempting to contrast the package approach with the template approach. Paul is addressing the more general question about whether collections (of any kind) are worth pursuing, and I'm trying to make the case that they are. I should have included the assumption that I was talking about only one kind of state (e.g. presence). The point I was attempting to demonstrate does not change as you vary this assumption, though: the number of subscriptions in the system still increases at approximately O(n^2) regardless of whether you use collections (of any kind). /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 18 13:52:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23580 for ; Wed, 18 Sep 2002 13:52:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8IHrOMN012530; Wed, 18 Sep 2002 13:53:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10736; Wed, 18 Sep 2002 13:54:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10720 for ; Wed, 18 Sep 2002 13:53:30 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8IHqnNo015213; Wed, 18 Sep 2002 13:52:49 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 12:53:27 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64172@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Torrey Searle'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 18 Sep 2002 12:53:26 -0500 I think that's a really good suggestion. Thanks. /a (nit: s/people/resources/) > -----Original Message----- > From: Torrey Searle [mailto:tsearle@indigosw.com] > Sent: Wednesday, September 18, 2002 5:22 > To: simple@mailman.dynamicsoft.com > Subject: [Simple] collection template > > > For the inital subscribe to a Template, would it be possible to just > send the list of people in the collection w/o the actuall > state? IE a > presence-list of presence elements w/o tuples. It would seem like an > appropriate time to get the "collection list" from the server, w/o > having to guess it from subsquent partial notifies. > > Torrey Searle > Indigo Software _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 18 20:50:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05494 for ; Wed, 18 Sep 2002 20:50:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8J0oRMN013952; Wed, 18 Sep 2002 20:50:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11896; Wed, 18 Sep 2002 20:51:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11885 for ; Wed, 18 Sep 2002 20:50:54 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8J0ourn021489; Wed, 18 Sep 2002 20:50:57 -0400 (EDT) Received: from cisco.com (rtp-vpn2-659.cisco.com [10.82.242.147]) by cannon.cisco.com (Mirapoint) with ESMTP id AAR12228; Wed, 18 Sep 2002 20:55:28 -0400 (EDT) Message-ID: <3D891F60.FDCBB2B1@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Torrey Searle'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64172@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 18 Sep 2002 20:50:40 -0400 Content-Transfer-Encoding: 7bit This suggestion might also address one issue I had. When you first establish the subscription, or refresh it, or do a one-time poll for status, the event mechanism requires that a single notification be returned immediately, containing the current state of the resource (in this case the contact list). This is hard to do if the only notifications are relays of notifications from individual members of the collection. This idea would begin to solve that problem. But other problems remain. For instance there is then still no way to poll for the current state of everything in the collection. Also, the kind of response you are describing doesn't seem to fit within the current definition of PIDF. PIDF only permits you to mention one presentity. You could get creative, and make a pidf document that uses the address of the collection as the presentity, and describes all of the collection members as separate tuples, with the address of the member as a contact address. Or you could consider extending pidf to permit inclusion of multiple presentities. I had some discussions about those kinds of approaches a few months ago, with Jonathan or Adam I think. But since then things seem to have gone a different direction. Without some kind of change I don't see how to make a collection conform to all the rules of an event package. Paul Adam Roach wrote: > > I think that's a really good suggestion. Thanks. > > /a > > (nit: s/people/resources/) > > > -----Original Message----- > > From: Torrey Searle [mailto:tsearle@indigosw.com] > > Sent: Wednesday, September 18, 2002 5:22 > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] collection template > > > > > > For the inital subscribe to a Template, would it be possible to just > > send the list of people in the collection w/o the actuall > > state? IE a > > presence-list of presence elements w/o tuples. It would seem like an > > appropriate time to get the "collection list" from the server, w/o > > having to guess it from subsquent partial notifies. > > > > Torrey Searle > > Indigo Software > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 19 04:20:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26729 for ; Thu, 19 Sep 2002 04:20:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8J8KUMN014841; Thu, 19 Sep 2002 04:20:30 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13210; Thu, 19 Sep 2002 04:21:06 -0400 (EDT) Received: from m3102.hostcentric.net (m3102.hostcentric.net [216.157.79.140]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA13199 for ; Thu, 19 Sep 2002 04:20:57 -0400 (EDT) Received: (qmail 25365 invoked by alias); 19 Sep 2002 08:17:59 -0000 Received: from unknown (HELO m3001.hostcentric.net) (216.157.79.237) by 0 with SMTP; 19 Sep 2002 08:17:59 -0000 Received: (qmail 4856 invoked by alias); 19 Sep 2002 08:17:55 -0000 Received: from unknown (HELO indigosw.com) (217.136.220.14) by 0 with SMTP; 19 Sep 2002 08:17:55 -0000 Message-ID: <3D8987DD.2050100@indigosw.com> From: Torrey Searle Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Kyzivat CC: Adam Roach , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64172@DYN-TX-EXCH-001.dynamicsoft.com> <3D891F60.FDCBB2B1@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 19 Sep 2002 10:16:29 +0200 Content-Transfer-Encoding: 7bit > > >Also, the kind of response you are describing doesn't seem to fit within the current definition of PIDF. PIDF only permits you to mention one presentity. You could get creative, and make a pidf document that uses the address of the collection as the presentity, and describes all of the collection members as separate tuples, with the address of the member as a contact address. Or you could consider extending pidf to permit inclusion of multiple presentities. I had some discussions about those kinds of approaches a few months ago, with Jonathan or Adam I think. But since then things seem to have gone a different direction. > > Section 4 of draft-ieft-simple-presencelist-package-00 describes a document format called PLIDF, which essentially is a list of PIDF documents. So using that format, it should be possible to list all the contact addresses without problems. Torrey Searle Indigo Software >Without some kind of change I don't see how to make a collection conform to all the rules of an event package. > > Paul > > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 19 08:05:30 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01287 for ; Thu, 19 Sep 2002 08:05:30 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8JC5QMN015322; Thu, 19 Sep 2002 08:05:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13899; Thu, 19 Sep 2002 08:06:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13888 for ; Thu, 19 Sep 2002 08:05:48 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8JC5trE015198; Thu, 19 Sep 2002 08:05:55 -0400 (EDT) Received: from cisco.com (rtp-vpn2-659.cisco.com [10.82.242.147]) by cannon.cisco.com (Mirapoint) with ESMTP id AAR13881; Thu, 19 Sep 2002 08:10:26 -0400 (EDT) Message-ID: <3D89BD92.30D4A885@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Torrey Searle CC: Adam Roach , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A64172@DYN-TX-EXCH-001.dynamicsoft.com> <3D891F60.FDCBB2B1@cisco.com> <3D8987DD.2050100@indigosw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 19 Sep 2002 08:05:38 -0400 Content-Transfer-Encoding: 7bit Torrey Searle wrote: > > > > > > >Also, the kind of response you are describing doesn't seem to fit within the current definition of PIDF. PIDF only permits you to mention one presentity. You could get creative, and make a pidf document that uses the address of the collection as the presentity, and describes all of the collection members as separate tuples, with the address of the member as a contact address. Or you could consider extending pidf to permit inclusion of multiple presentities. I had some discussions about those kinds of approaches a few months ago, with Jonathan or Adam I think. But since then things seem to have gone a different direction. > > > > > Section 4 of draft-ieft-simple-presencelist-package-00 describes a > document format called PLIDF, which essentially is a list of PIDF > documents. So using that format, it should be possible to list all the > contact addresses without problems. That draft is what started this discussion. The current discussion has drifted away from that proposal. That defined a new event package, different than presence, but related to presence. With that approach, every time you want to define a collection of some event type, you need to define another document format to go with it. People didn't seem very happy with that. So the talk has moved to more generalized ways of defining collections. But what I think has been lost in that discussion is the need to have some format that permits returning the immediate response to a subscription. One way to achieve that would be to define a document format for collections. Then subscribers to collections could expect to receive both that format, and the formats for elements of the collection. But the PLIDF format wouldn't be the right format for that. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 19 08:34:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01928 for ; Thu, 19 Sep 2002 08:34:59 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8JCZNMN015466; Thu, 19 Sep 2002 08:35:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14004; Thu, 19 Sep 2002 08:36:03 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13992 for ; Thu, 19 Sep 2002 08:35:06 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8JCZTZ26602 for ; Thu, 19 Sep 2002 15:35:29 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Sep 2002 15:35:02 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Sep 2002 15:35:04 +0300 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" Subject: RE: [Simple] collection template Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE481@esebe013.ntc.nokia.com> Thread-Topic: [Simple] collection template Thread-Index: AcJfduyMFSSNZl3iQyKaiJQvOAz2tgAYZhDQ To: , Cc: , X-OriginalArrivalTime: 19 Sep 2002 12:35:04.0505 (UTC) FILETIME=[FACC1A90:01C25FD8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA13992 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 19 Sep 2002 15:35:03 +0300 Content-Transfer-Encoding: 8bit Hi, I still feel uneasy with the template package approach. It should be possible to subscribe to presence.collection.collection and get some sort of notification back. It doesn't seem obvious to me that the collection can work as a template package. Cheers, Aki > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, September 19, 2002 3:51 AM > To: Adam Roach > Cc: 'Torrey Searle'; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] collection template > > > This suggestion might also address one issue I had. When you > first establish the subscription, or refresh it, or do a > one-time poll for status, the event mechanism requires that a > single notification be returned immediately, containing the > current state of the resource (in this case the contact > list). This is hard to do if the only notifications are > relays of notifications from individual members of the collection. > > This idea would begin to solve that problem. But other > problems remain. For instance there is then still no way to > poll for the current state of everything in the collection. > > Also, the kind of response you are describing doesn't seem to > fit within the current definition of PIDF. PIDF only permits > you to mention one presentity. You could get creative, and > make a pidf document that uses the address of the collection > as the presentity, and describes all of the collection > members as separate tuples, with the address of the member as > a contact address. Or you could consider extending pidf to > permit inclusion of multiple presentities. I had some > discussions about those kinds of approaches a few months ago, > with Jonathan or Adam I think. But since then things seem to > have gone a different direction. > > Without some kind of change I don't see how to make a > collection conform to all the rules of an event package. > > Paul > > Adam Roach wrote: > > > > I think that's a really good suggestion. Thanks. > > > > /a > > > > (nit: s/people/resources/) > > > > > -----Original Message----- > > > From: Torrey Searle [mailto:tsearle@indigosw.com] > > > Sent: Wednesday, September 18, 2002 5:22 > > > To: simple@mailman.dynamicsoft.com > > > Subject: [Simple] collection template > > > > > > > > > For the inital subscribe to a Template, would it be > possible to just > > > send the list of people in the collection w/o the actuall > > > state? IE a > > > presence-list of presence elements w/o tuples. It would > seem like an > > > appropriate time to get the "collection list" from the server, w/o > > > having to guess it from subsquent partial notifies. > > > > > > Torrey Searle > > > Indigo Software > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 19 08:41:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02150 for ; Thu, 19 Sep 2002 08:41:51 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8JCgNMN015542; Thu, 19 Sep 2002 08:42:23 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14046; Thu, 19 Sep 2002 08:43:04 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14035 for ; Thu, 19 Sep 2002 08:42:45 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8JCgdT03994 for ; Thu, 19 Sep 2002 15:42:39 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Sep 2002 15:41:46 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Sep 2002 15:41:45 +0300 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" Subject: RE: [Simple] collection template Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE482@esebe013.ntc.nokia.com> Thread-Topic: [Simple] collection template Thread-Index: AcJfduyMFSSNZl3iQyKaiJQvOAz2tgAYZhDQAABE7TA= To: , , Cc: , X-OriginalArrivalTime: 19 Sep 2002 12:41:45.0746 (UTC) FILETIME=[E9F49F20:01C25FD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA14035 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 19 Sep 2002 15:41:45 +0300 Content-Transfer-Encoding: 8bit ...Unless of course the fan out treats all events alike, i.e., subscription for presence.collection.collection results in a SUBSCRIBE for event presence.collection -- the initial notify could still have the same information regardless of the "depth" of the collection. Thanks, Aki ;) > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, September 19, 2002 3:35 PM > To: pkyzivat@cisco.com; adam@dynamicsoft.com > Cc: tsearle@indigosw.com; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] collection template > > > Hi, > > I still feel uneasy with the template package approach. It > should be possible to subscribe to > presence.collection.collection and get some sort of > notification back. It doesn't seem obvious to me that the > collection can work as a template package. > > Cheers, > Aki > > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, September 19, 2002 3:51 AM > > To: Adam Roach > > Cc: 'Torrey Searle'; simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] collection template > > > > > > This suggestion might also address one issue I had. When you > > first establish the subscription, or refresh it, or do a > > one-time poll for status, the event mechanism requires that a > > single notification be returned immediately, containing the > > current state of the resource (in this case the contact > > list). This is hard to do if the only notifications are > > relays of notifications from individual members of the collection. > > > > This idea would begin to solve that problem. But other > > problems remain. For instance there is then still no way to > > poll for the current state of everything in the collection. > > > > Also, the kind of response you are describing doesn't seem to > > fit within the current definition of PIDF. PIDF only permits > > you to mention one presentity. You could get creative, and > > make a pidf document that uses the address of the collection > > as the presentity, and describes all of the collection > > members as separate tuples, with the address of the member as > > a contact address. Or you could consider extending pidf to > > permit inclusion of multiple presentities. I had some > > discussions about those kinds of approaches a few months ago, > > with Jonathan or Adam I think. But since then things seem to > > have gone a different direction. > > > > Without some kind of change I don't see how to make a > > collection conform to all the rules of an event package. > > > > Paul > > > > Adam Roach wrote: > > > > > > I think that's a really good suggestion. Thanks. > > > > > > /a > > > > > > (nit: s/people/resources/) > > > > > > > -----Original Message----- > > > > From: Torrey Searle [mailto:tsearle@indigosw.com] > > > > Sent: Wednesday, September 18, 2002 5:22 > > > > To: simple@mailman.dynamicsoft.com > > > > Subject: [Simple] collection template > > > > > > > > > > > > For the inital subscribe to a Template, would it be > > possible to just > > > > send the list of people in the collection w/o the actuall > > > > state? IE a > > > > presence-list of presence elements w/o tuples. It would > > seem like an > > > > appropriate time to get the "collection list" from the > server, w/o > > > > having to guess it from subsquent partial notifies. > > > > > > > > Torrey Searle > > > > Indigo Software > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 19 08:57:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02751 for ; Thu, 19 Sep 2002 08:57:52 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8JCwNMN015661; Thu, 19 Sep 2002 08:58:23 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14144; Thu, 19 Sep 2002 08:59:03 -0400 (EDT) Received: from m3102.hostcentric.net (m3102.hostcentric.net [216.157.79.140]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id IAA14133 for ; Thu, 19 Sep 2002 08:58:18 -0400 (EDT) Received: (qmail 14577 invoked by alias); 19 Sep 2002 12:58:18 -0000 Received: from unknown (HELO m3001.hostcentric.net) (216.157.79.237) by 0 with SMTP; 19 Sep 2002 12:58:18 -0000 Received: (qmail 21213 invoked by alias); 19 Sep 2002 12:58:17 -0000 Received: from unknown (HELO indigosw.com) (217.136.220.14) by 0 with SMTP; 19 Sep 2002 12:58:17 -0000 Message-ID: <3D89C98A.2000009@indigosw.com> From: Torrey Searle Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us MIME-Version: 1.0 To: aki.niemi@nokia.com CC: pkyzivat@cisco.com, adam@dynamicsoft.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE481@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 19 Sep 2002 14:56:42 +0200 Content-Transfer-Encoding: 8bit Couldn't presence.collection.collection still be interesting? Suppose that I want to have a "presence list" organized into groups, I.E. so I have a collection that subscribse to the Collection of all the people who work at my company (with that list being maintained by the system administrator of the company) and a Family group, and maybe a Group for the members of Community Service I am a member of. Each collection could be updated w/o me needing to modifiy my collection. Any thoughts on this? Torrey Searle Indigo Software aki.niemi@nokia.com a écrit: >Hi, > >I still feel uneasy with the template package approach. It should be possible to subscribe to presence.collection.collection and get some sort of notification back. It doesn't seem obvious to me that the collection can work as a template package. > >Cheers, >Aki > > > >> >> _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 20 15:10:30 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04753 for ; Fri, 20 Sep 2002 15:10:29 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJAcMN021157; Fri, 20 Sep 2002 15:10:39 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19272; Fri, 20 Sep 2002 15:11:10 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19261 for ; Fri, 20 Sep 2002 15:10:54 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJABNo027104; Fri, 20 Sep 2002 15:10:12 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 14:10:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6418D@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: "'Torrey Searle'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 20 Sep 2002 14:10:47 -0500 > This suggestion might also address one issue I had. When you > first establish the subscription, or refresh it, or do a > one-time poll for status, the event mechanism requires that a > single notification be returned immediately, containing the > current state of the resource (in this case the contact > list). This is hard to do if the only notifications are > relays of notifications from individual members of the collection. RFC 3265 requires a NOTIFY. That NOTIFY isn't required to contain correct state information, just well-formatted state information. > This idea would begin to solve that problem. But other > problems remain. For instance there is then still no way to > poll for the current state of everything in the collection. I'm willing to accept that as a limitation of the mechanism. Polling is usually too heavy on network resources to warrant deployment. > Also, the kind of response you are describing doesn't seem to > fit within the current definition of PIDF. It wouldn't *be* PIDF. It would be whatever the collection {package,template} defines. My vote would be for mime multipart. > Without some kind of change I don't see how to make a > collection conform to all the rules of an event package. Odd. I don't see any barriers. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 20 15:16:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04995 for ; Fri, 20 Sep 2002 15:16:49 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJHMMN021268; Fri, 20 Sep 2002 15:17:22 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19314; Fri, 20 Sep 2002 15:18:03 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19303 for ; Fri, 20 Sep 2002 15:17:03 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJGINo027126; Fri, 20 Sep 2002 15:16:19 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 14:16:58 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6418E@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'aki.niemi@nokia.com'" , pkyzivat@cisco.com, Adam Roach Cc: tsearle@indigosw.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 20 Sep 2002 14:16:57 -0500 And that was precisely my intention. In fact, I implied as much very early in this discussion, with an example message that shows a subscription to presence.collection.collection. /a > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, September 19, 2002 7:42 > To: aki.niemi@nokia.com; pkyzivat@cisco.com; adam@dynamicsoft.com > Cc: tsearle@indigosw.com; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] collection template > > > ...Unless of course the fan out treats all events alike, > i.e., subscription for presence.collection.collection results > in a SUBSCRIBE for event presence.collection -- the initial > notify could still have the same information regardless of > the "depth" of the collection. > > Thanks, > Aki ;) > > > -----Original Message----- > > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Thursday, September 19, 2002 3:35 PM > > To: pkyzivat@cisco.com; adam@dynamicsoft.com > > Cc: tsearle@indigosw.com; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] collection template > > > > > > Hi, > > > > I still feel uneasy with the template package approach. It > > should be possible to subscribe to > > presence.collection.collection and get some sort of > > notification back. It doesn't seem obvious to me that the > > collection can work as a template package. > > > > Cheers, > > Aki > > > > > -----Original Message----- > > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Thursday, September 19, 2002 3:51 AM > > > To: Adam Roach > > > Cc: 'Torrey Searle'; simple@mailman.dynamicsoft.com > > > Subject: Re: [Simple] collection template > > > > > > > > > This suggestion might also address one issue I had. When you > > > first establish the subscription, or refresh it, or do a > > > one-time poll for status, the event mechanism requires that a > > > single notification be returned immediately, containing the > > > current state of the resource (in this case the contact > > > list). This is hard to do if the only notifications are > > > relays of notifications from individual members of the collection. > > > > > > This idea would begin to solve that problem. But other > > > problems remain. For instance there is then still no way to > > > poll for the current state of everything in the collection. > > > > > > Also, the kind of response you are describing doesn't seem to > > > fit within the current definition of PIDF. PIDF only permits > > > you to mention one presentity. You could get creative, and > > > make a pidf document that uses the address of the collection > > > as the presentity, and describes all of the collection > > > members as separate tuples, with the address of the member as > > > a contact address. Or you could consider extending pidf to > > > permit inclusion of multiple presentities. I had some > > > discussions about those kinds of approaches a few months ago, > > > with Jonathan or Adam I think. But since then things seem to > > > have gone a different direction. > > > > > > Without some kind of change I don't see how to make a > > > collection conform to all the rules of an event package. > > > > > > Paul > > > > > > Adam Roach wrote: > > > > > > > > I think that's a really good suggestion. Thanks. > > > > > > > > /a > > > > > > > > (nit: s/people/resources/) > > > > > > > > > -----Original Message----- > > > > > From: Torrey Searle [mailto:tsearle@indigosw.com] > > > > > Sent: Wednesday, September 18, 2002 5:22 > > > > > To: simple@mailman.dynamicsoft.com > > > > > Subject: [Simple] collection template > > > > > > > > > > > > > > > For the inital subscribe to a Template, would it be > > > possible to just > > > > > send the list of people in the collection w/o the actuall > > > > > state? IE a > > > > > presence-list of presence elements w/o tuples. It would > > > seem like an > > > > > appropriate time to get the "collection list" from the > > server, w/o > > > > > having to guess it from subsquent partial notifies. > > > > > > > > > > Torrey Searle > > > > > Indigo Software > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 20 15:19:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05064 for ; Fri, 20 Sep 2002 15:19:50 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJKMMN021366; Fri, 20 Sep 2002 15:20:22 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19349; Fri, 20 Sep 2002 15:21:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19337 for ; Fri, 20 Sep 2002 15:20:31 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJJlNo027178; Fri, 20 Sep 2002 15:19:47 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 14:20:27 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6418F@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Torrey Searle'" , aki.niemi@nokia.com Cc: pkyzivat@cisco.com, Adam Roach , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA19337 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 20 Sep 2002 14:20:27 -0500 Content-Transfer-Encoding: 8bit Of *course* it's interesting. In fact, I included it as an example in my very first response to this thread, based on the scenario that Jonathan laid out. It's a template. It works like a template. "presence.collection" and "presence.winfo.collection" and "presence.collection.collection" and "presence.collection.winfo" and "presence.winfo.collection.winfo" and "presence.collection.collection.winfo" and any other combination you can think of will all have well-defined semantics. Many of them will even be useful in some contexts. /a > -----Original Message----- > From: Torrey Searle [mailto:tsearle@indigosw.com] > Sent: Thursday, September 19, 2002 7:57 > To: aki.niemi@nokia.com > Cc: pkyzivat@cisco.com; adam@dynamicsoft.com; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] collection template > > > Couldn't presence.collection.collection still be interesting? Suppose > that I want to have a "presence list" organized into groups, > I.E. so I > have a collection that subscribse to the Collection of all the people > who work at my company (with that list being maintained by the system > administrator of the company) and a Family group, and maybe a > Group for > the members of Community Service I am a member of. Each collection > could be updated w/o me needing to modifiy my collection. > > Any thoughts on this? > > Torrey Searle > Indigo Software > > aki.niemi@nokia.com a écrit: > > >Hi, > > > >I still feel uneasy with the template package approach. It > should be possible to subscribe to > presence.collection.collection and get some sort of > notification back. It doesn't seem obvious to me that the > collection can work as a template package. > > > >Cheers, > >Aki > > > > > > > >> > >> > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 20 17:55:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10365 for ; Fri, 20 Sep 2002 17:55:58 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KLuQMN021999; Fri, 20 Sep 2002 17:56:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19823; Fri, 20 Sep 2002 17:57:06 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15445 for ; Thu, 19 Sep 2002 15:40:36 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20338; Thu, 19 Sep 2002 15:38:49 -0400 (EDT) Message-Id: <200209191938.PAA20338@ietf.org> To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com From: The IESG Reply-to: iesg@ietf.org Subject: [Simple] Last Call: A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 19 Sep 2002 15:38:48 -0400 The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions Working Group to consider publishing each of the following internet drafts as Proposed Standards: o A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information o An Extensible Markup Language (XML) Based Format for Watcher Information o Session Initiation Protocol (SIP) Extensions for Presence The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-10-3. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-02.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-02.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-07.txt _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Sep 20 19:22:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13739 for ; Fri, 20 Sep 2002 19:22:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KNNOMN022256; Fri, 20 Sep 2002 19:23:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20088; Fri, 20 Sep 2002 19:24:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20077 for ; Fri, 20 Sep 2002 19:23:48 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KNN7No028319; Fri, 20 Sep 2002 19:23:07 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 18:23:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64195@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: "'Sean Olson'" , aki.niemi@nokia.com, Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 20 Sep 2002 18:23:44 -0500 From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Then of course S1 must obtain the credential it uses to act > on behalf of C1 somewhow, and S2 must know how to recognize > such a credential and decide whether to honor it. This all > adds complexity to the use of collections. (Whether they are > templates or not.) The issue of S2 knowing which credentials to trust isn't inherent in the collections problem. It's something that arises whenever you use event agents. For presence, it's the norm. > Do you see a reasonable way to approach this problem of credentials? The permissions problems are congruent to the "Referred-By" problem -- and we already have people working on that. I expect to see some output on this topic -- that is, delegation of credentials for specific tasks -- sometime relatively soon. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 23 05:13:26 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02928 for ; Mon, 23 Sep 2002 05:13:25 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8N9DSjF000414; Mon, 23 Sep 2002 05:13:28 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00421; Mon, 23 Sep 2002 05:14:05 -0400 (EDT) Received: from relay2.clb.oleane.net (relay2.clb.oleane.net [213.56.31.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00410 for ; Mon, 23 Sep 2002 05:13:07 -0400 (EDT) Received: from chantal (upper-side.rain.fr [194.250.212.114]) by relay2.clb.oleane.net with SMTP id g8N9D63u031681 for ; Mon, 23 Sep 2002 11:13:06 +0200 Message-ID: <00ad01c262e1$dfc6b320$0701a8c0@upperside> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01C262F2.A2F26F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Simple] International SIP Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 23 Sep 2002 11:16:17 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C262F2.A2F26F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The fourth edition of International SIP will take place January 14 to 17, 2003 in Paris. The most eminent specialists in this technology will be on hand to discuss technological and implementation issues. Indeed, a greater importance is given this year to PSTN and wireless operators deployment scenarios. All details at : http://www.upperside.fr/intersip03/sip03intro.htm ------=_NextPart_000_00A9_01C262F2.A2F26F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The fourth edition of International SIP will take = place=20 January 14 to 17, 2003 in Paris. The most eminent = specialists=20 in this technology will be on hand to discuss technological and = implementation=20 issues. Indeed, a greater importance is given this year to PSTN and = wireless=20 operators deployment scenarios.

All details at : http://www.upp= erside.fr/intersip03/sip03intro.htm

 
 
------=_NextPart_000_00A9_01C262F2.A2F26F00-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 23 08:05:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05388 for ; Mon, 23 Sep 2002 08:05:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8NC5QjF000770; Mon, 23 Sep 2002 08:05:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00910; Mon, 23 Sep 2002 08:06:04 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00899 for ; Mon, 23 Sep 2002 08:05:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05308; Mon, 23 Sep 2002 08:03:58 -0400 (EDT) Message-Id: <200209231203.IAA05308@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-niemi-simple-publish-framework-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 23 Sep 2002 08:03:58 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Specific Data Publication Framework Author(s) : A. Niemi Filename : draft-niemi-simple-publish-framework-00.txt Pages : 11 Date : 2002-9-20 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework for publication of SIP specific data. This extension derives from the recent Internet Draft defining the PUBLISH method, but instead of using the SIP events framework, it introduces a specific publication framework for the publish mechanism. The main motivations for decoupling publications from events are that the event framework is not overloaded, and the applicability of the PUBLISH method to problem sets similar to those surfacing in the publication of event state is improved. The SIP publication framework is neither intended for general data manipulation, nor is it intended to foster any discussion on the issue of using SIP for everything. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-niemi-simple-publish-framework-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-niemi-simple-publish-framework-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: <2002-9-20142546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-simple-publish-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-simple-publish-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-20142546.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 23 08:46:56 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06730 for ; Mon, 23 Sep 2002 08:46:56 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8NClOjF000920; Mon, 23 Sep 2002 08:47:25 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01075; Mon, 23 Sep 2002 08:48:04 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01064 for ; Mon, 23 Sep 2002 08:47:33 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8NCm1Z11753 for ; Mon, 23 Sep 2002 15:48:01 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 23 Sep 2002 15:47:33 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Sep 2002 15:47:33 +0300 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" Subject: RE: [Simple] I-D ACTION:draft-niemi-simple-publish-framework-00.txt Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901944FD9@esebe013.ntc.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-niemi-simple-publish-framework-00.txt Thread-Index: AcJi+jTS8mY+9f2gTO+J53bEpRZRgAAArcIA To: X-OriginalArrivalTime: 23 Sep 2002 12:47:33.0341 (UTC) FILETIME=[62CA68D0:01C262FF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA01064 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 23 Sep 2002 15:47:33 +0300 Content-Transfer-Encoding: 8bit Hi All, This I-D proposes a slight change of direction for the PUBLISH work, draft-olson-simple-publish-00. It describes a publication framework, which is similar to the SIP events framework in many ways. Especially the overloading of events with PUBLISH is addressed by this draft, as well as the possiblity of widening the applicability of PUBLISH in a way that still preserves its currently defined properties. The intention was to present these ideas in a concrete way, and if deemed worthwhile, incorporate the contents of the draft to draft-olson-simple-publish-00. Comments are most welcome. Cheers, Aki > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, September 23, 2002 3:04 PM > Cc: simple@mailman.dynamicsoft.com > Subject: [Simple] I-D > ACTION:draft-niemi-simple-publish-framework-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : SIP Specific Data Publication Framework > Author(s) : A. Niemi > Filename : draft-niemi-simple-publish-framework-00.txt > Pages : 11 > Date : 2002-9-20 > > This document describes an extension to the Session Initiation > Protocol (SIP). The purpose of this extension is to provide an > extensible framework for publication of SIP specific data. This > extension derives from the recent Internet Draft defining the PUBLISH > method, but instead of using the SIP events framework, it introduces > a specific publication framework for the publish mechanism. The main > motivations for decoupling publications from events are that the > event framework is not overloaded, and the applicability of the > PUBLISH method to problem sets similar to those surfacing in the > publication of event state is improved. The SIP publication > framework is neither intended for general data manipulation, nor is > it intended to foster any discussion on the issue of using SIP for > everything. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-niemi-simple-publish-framework-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-niemi-simple-publish-framework-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. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Sep 24 09:48:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27246 for ; Tue, 24 Sep 2002 09:48:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8ODmXjF005748; Tue, 24 Sep 2002 09:48:33 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05293; Tue, 24 Sep 2002 09:49:06 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05282 for ; Tue, 24 Sep 2002 09:48:00 -0400 (EDT) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8ODkrnc027056 for ; Tue, 24 Sep 2002 15:46:54 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 24 Sep 2002 15:47:35 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 24 Sep 2002 15:47:35 +0200 Mime-Version: 1.0 (Apple Message framework v546) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: [Simple] Last Call: A Session Initiation Protocol (SIP)Event presence Package to Proposed Standard From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: simple@mailman.dynamicsoft.com Content-Transfer-Encoding: 7bit Message-Id: <2DB0F479-CFC4-11D6-B5A3-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.546) X-OriginalArrivalTime: 24 Sep 2002 13:47:35.0123 (UTC) FILETIME=[F0087A30:01C263D0] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 24 Sep 2002 15:47:34 +0200 Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Tan Ya-Ching ICM N PG U ID A 1 > Date: Tue Sep 24, 2002 1:21:17 PM Europe/Stockholm > To: "'iesg@ietf.org'" > Subject: RE: [Simple] Last Call: A Session Initiation Protocol > (SIP)Event presence Package to Proposed Standard > > Comments on draft-ietf-simple-presence-07.txt : > > Section 4 2nd paragraph > > o "The subcription is carried along SIP proxies as any other > request would be". > > "subscription" => "SUBSCRIBE request" > > o "...it eventually arrives at a presence server, which can > either terminate the subscription..." > > "terminate the subscription" => "serves as the > terminating point for the SUBSCRIBE request and > handles the subscription" > > Section 4 6th paragraph > > o "This (refresh) SUBSCRIBE is nearly identical to the > initial one, but contains the dialog identifier, different > sequence numbers, and a set of Route headers..." > => > "...but contains the To tag, a higher sequence number, > and possibly a set of Route headers..." > > Section 8 > > o The mandatory Contact header is missing in the NOTIFY messages in > the > example message flow of section 8. > > o 2nd paragraph of section 8 : "... th(r)ough some non-SIP means" > > > - Ya-Ching Tan > > > | -----Original Message----- > | From: The IESG [mailto:iesg-secretary@ietf.org] > | Sent: 19 September 2002 21:39 > | Cc: simple@mailman.dynamicsoft.com > | Subject: [Simple] Last Call: A Session Initiation Protocol (SIP)Event > | Template-Package for Watcher Information to Proposed Standard > | > | > | > | The IESG has received a request from the SIP for Instant Messaging > and > | Presence Leveraging Extensions Working Group to consider publishing > | each of the following internet drafts as Proposed Standards: > | > | o A Session Initiation Protocol (SIP)Event Template-Package > | for Watcher > | Information > | > | o An Extensible Markup Language (XML) Based Format for > | Watcher Information > | > | o Session Initiation Protocol (SIP) Extensions for Presence > | > | > | > | The IESG plans to make a decision in the next few weeks, and solicits > | final comments on this action. Please send any comments to the > | iesg@ietf.org or ietf@ietf.org mailing lists by 2002-10-3. > | > | Files can be obtained via > | http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-pa > | ckage-02.txt > | http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-fo > rmat-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-07.txt > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 25 09:52:14 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26203 for ; Wed, 25 Sep 2002 09:52:13 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8PDqVjF009829; Wed, 25 Sep 2002 09:52:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09375; Wed, 25 Sep 2002 09:53:08 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09364 for ; Wed, 25 Sep 2002 09:52:34 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8PDqK520954 for ; Wed, 25 Sep 2002 16:52:20 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 16:49:59 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 16:49:57 +0300 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" Message-ID: Thread-Topic: [Simple] Last Call: A Session Initiation Protocol (SIP)Event presence Package to Proposed Standard Thread-Index: AcJj0YzSxKGbfEEmSPSxSBM6Tc+15wArf8Xw To: X-OriginalArrivalTime: 25 Sep 2002 13:49:57.0147 (UTC) FILETIME=[6F195EB0:01C2649A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA09364 Subject: [Simple] The way forward in data manipulation work Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 25 Sep 2002 16:49:56 +0300 Content-Transfer-Encoding: 8bit Hi, I think this would be a good time to see how to go forward with the charter items related to data manipulation. I believe Jonathan is planning to update the Data Manipulation Requirements draft focusing on two issues: 1. List management, and 2. Authrozation policy management. In Yokohama the concensus was to take this draft as basis for WG requirements, so maybe the next version could be taken as a WG draft. It is also a good proposal to limit that draft to purely requirements, leaving the "model" in Chapter 4 out of scope. Maybe then it would be easiear to agree on the draft. However, some kind of model/framework draft (similar to what is being done in conferencing) is also needed, and eventually it is essential to agree on what protocols to use. Based on usage guidelines SIP does not seem to meet the requirements. The current PUBLISH proposal is too simplistic to be useful in many cases. Instead, some kind of more flexible RPC mechanism with some support to synchronization seems to be the best choise. My proposal is thus: 1. Use SOAP/WSDL for data manipulation. In the first phase a definition is needed only for list and auth. policy management, but the framework does not need to limit to this. 2. Use SIP Events in a same fashion as "Message Waiting Indicator" draft to convey notifications about state changes in the managed objects. A collection package could be used for optimization purposes. This spec could still leave the actual synchronization update mechanism open, but I can imagine SyncML and others could potentially be usable there. 3. Take SIP BIND as a default mechanism to make binding between sip: URIs and SOAP http: URIs. In my opinion the framework doc. should define the terminology, have a few nice ascii-drawings and describe the model and the actors within points 1-3 above. Also, it should tell how to specify management interfaces for specific objects, and how to achieve the synchronization. In addition more specific documents would be needed for "list management", "authorization policy management" and "synchronization event package". I think we could have the first version of such framework draft could be ready for the next IETF Atlanta meeting, and discussed there. Then it could be updated and work on more specific drafts could start. But before starting anything like this, I would like to get people's opinion about the technical part, and of course chairs' opinion about the process. I'm sure there are plenty of other approaches, but I haven't heard any proposals so far. In any case, some kind of design team around this matter might be a good idea. Regards, Markus _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 25 18:47:12 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12247 for ; Wed, 25 Sep 2002 18:47:11 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8PMlSjF012059; Wed, 25 Sep 2002 18:47:30 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10896; Wed, 25 Sep 2002 18:48:06 -0400 (EDT) Received: from hop.funtv.com (hop.funtv.com [206.19.100.98]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10885 for ; Wed, 25 Sep 2002 18:47:47 -0400 (EDT) Received: from skim (sns.funtv.com [206.19.96.100]) by hop.funtv.com (8.8.8+Sun/8.8.8) with SMTP id PAA11021; Wed, 25 Sep 2002 15:47:46 -0700 (PDT) Message-ID: <01eb01c264e5$aba9b730$400015ac@skim> From: "Seonman Kim" To: Cc: "Seonman Kim" MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Simple] Error when sending NOTIFY to MSN messenger (RTC) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 25 Sep 2002 15:48:30 -0700 Content-Transfer-Encoding: 7bit Hi, I am implementing SIMPLE protocol and testing with MSN messenger (Windows RTC). I successfully subscribed to a buddy (named "temin") with SUBSCRIBE request to our presence server. But when our presence servere notifies to the watcher using NOTIFY message, I got a "415 Unsupported Media Type" error. I guess I have wrong information in PIDF document in NOTIFY message, but I could not figure out the problem. Will anyone of you teach me what the problem is? I attached the SUBSCRIBE and NOTIFY message, and 415 error returned by MSN Messenger. And if someone knows the format of content body for NOTIFY message used Windows RTC, please let me know. ---- SUBSCRIBE sip:temin@206.xxx.xxx.203 SIP/2.0 Via: SIP/2.0/TCP 172.xxx.xxx.64:12559 From: "seonman" ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648 To: Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64 CSeq: 1 SUBSCRIBE Contact: User-Agent: Windows RTC/1.0 Expires: 1800 Content-Length: 0 NOTIFY sip:seonman@206.xxx.xxx.203 SIP/2.0 Via: SIP/2.0/UDP 206.xxx.xxx.205:5070 To: ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648 From: ;tag=90693859 Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64 CSeq: 1 NOTIFY Max-Forwards: 70 Route: Subscription-State: active;expires=1800 Content-Type: application/cpim-pidf+xml Content-Length: 273 open sip:temin@206.xxx.xxx.203 ---------------- SIP/2.0 415 Unsupported Media Type Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bKdba1f899bbbec7f2d301db4f58404563.2 Via: SIP/2.0/UDP 206.xxx.xxx.205:5070 From: ;tag=90693859 To: ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648 Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64 CSeq: 1 NOTIFY User-Agent: Windows RTC/1.0 Content-Length: 0 Thanks, Seonman _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Sep 25 21:16:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14584 for ; Wed, 25 Sep 2002 21:16:56 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8Q1HOjF012485; Wed, 25 Sep 2002 21:17:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11319; Wed, 25 Sep 2002 21:18:06 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11308 for ; Wed, 25 Sep 2002 21:17:07 -0400 (EDT) Received: from d23rh902.au.ibm.com (d23rh902.au.ibm.com [9.185.167.101]) by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id g8Q18hhh135900; Thu, 26 Sep 2002 11:08:43 +1000 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.181.2.75]) by d23rh902.au.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8Q1C8rd018174; Thu, 26 Sep 2002 11:12:09 +1000 Subject: Re: [Simple] Error when sending NOTIFY to MSN messenger (RTC) To: "Seonman Kim" Cc: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.9a |January 7, 2002) at 26/09/2002 09:17:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 26 Sep 2002 09:17:22 +0800 AFAIK, they use application/cpim-xpidf. It's not a mandatory format but several vendors support this. Best regards, Tang Lihua "Seonman Kim" To: Sent by: cc: "Seonman Kim" simple-admin@mailman.dyna Subject: [Simple] Error when sending NOTIFY to MSN messenger micsoft.com (RTC) 2002-09-26 06:48 Hi, I am implementing SIMPLE protocol and testing with MSN messenger (Windows RTC). I successfully subscribed to a buddy (named "temin") with SUBSCRIBE request to our presence server. But when our presence servere notifies to the watcher using NOTIFY message, I got a "415 Unsupported Media Type" error. I guess I have wrong information in PIDF document in NOTIFY message, but I could not figure out the problem. Will anyone of you teach me what the problem is? I attached the SUBSCRIBE and NOTIFY message, and 415 error returned by MSN Messenger. And if someone knows the format of content body for NOTIFY message used Windows RTC, please let me know. ---- SUBSCRIBE sip:temin@206.xxx.xxx.203 SIP/2.0 Via: SIP/2.0/TCP 172.xxx.xxx.64:12559 From: "seonman" ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648 To: Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64 CSeq: 1 SUBSCRIBE Contact: User-Agent: Windows RTC/1.0 Expires: 1800 Content-Length: 0 NOTIFY sip:seonman@206.xxx.xxx.203 SIP/2.0 Via: SIP/2.0/UDP 206.xxx.xxx.205:5070 To: ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648 From: ;tag=90693859 Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64 CSeq: 1 NOTIFY Max-Forwards: 70 Route: Subscription-State: active;expires=1800 Content-Type: application/cpim-pidf+xml Content-Length: 273 open sip:temin@206.xxx.xxx.203 ---------------- SIP/2.0 415 Unsupported Media Type Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bKdba1f899bbbec7f2d301db4f58404563.2 Via: SIP/2.0/UDP 206.xxx.xxx.205:5070 From: ;tag=90693859 To: ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648 Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64 CSeq: 1 NOTIFY User-Agent: Windows RTC/1.0 Content-Length: 0 Thanks, Seonman _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 26 14:11:17 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16847 for ; Thu, 26 Sep 2002 14:11:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8QIBcjF015231; Thu, 26 Sep 2002 14:11:38 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14194; Thu, 26 Sep 2002 14:12:14 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14183 for ; Thu, 26 Sep 2002 14:11:18 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.47]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8QIBIYH000398; Thu, 26 Sep 2002 14:11:18 -0400 (EDT) Message-ID: <3D934DC5.9050101@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: simple@mailman.dynamicsoft.com Subject: Re: Fwd: [Simple] Last Call: A Session Initiation Protocol (SIP)Event presence Package to Proposed Standard References: <2DB0F479-CFC4-11D6-B5A3-0003934B2128@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 26 Sep 2002 14:11:17 -0400 Content-Transfer-Encoding: 8bit responses inline. Patrik Fältström wrote: > > > Begin forwarded message: > >> From: Tan Ya-Ching ICM N PG U ID A 1 >> Date: Tue Sep 24, 2002 1:21:17 PM Europe/Stockholm >> To: "'iesg@ietf.org'" >> Subject: RE: [Simple] Last Call: A Session Initiation Protocol >> (SIP)Event presence Package to Proposed Standard >> >> Comments on draft-ietf-simple-presence-07.txt : >> >> Section 4 2nd paragraph >> >> o "The subcription is carried along SIP proxies as any other >> request would be". >> >> "subscription" => "SUBSCRIBE request" Fixed. >> >> o "...it eventually arrives at a presence server, which can >> either terminate the subscription..." >> >> "terminate the subscription" => "serves as the >> terminating point for the SUBSCRIBE request and >> handles the subscription" I think its even better worded as: In most cases, it eventually arrives at a presence server, which can either generate a response to the request (in which case it acts as the presence agent for the presentity), or proxy it on to an edge presence server. >> >> Section 4 6th paragraph >> >> o "This (refresh) SUBSCRIBE is nearly identical to the >> initial one, but contains the dialog identifier, different >> sequence numbers, and a set of Route headers..." >> => >> "...but contains the To tag, a higher sequence number, >> and possibly a set of Route headers..." Fixed. >> >> Section 8 >> >> o The mandatory Contact header is missing in the NOTIFY messages in >> the >> example message flow of section 8. Fixed. >> >> o 2nd paragraph of section 8 : "... th(r)ough some non-SIP means" Fixed. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Sep 26 19:08:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25061 for ; Thu, 26 Sep 2002 19:08:00 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8QN8RjF016457; Thu, 26 Sep 2002 19:08:27 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15177; Thu, 26 Sep 2002 19:09:06 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15166 for ; Thu, 26 Sep 2002 19:08:20 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8QN89ei000416; Thu, 26 Sep 2002 19:08:13 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAR61872; Thu, 26 Sep 2002 19:12:56 -0400 (EDT) Message-ID: <3D939357.FD5E0FA7@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Torrey Searle'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A6418D@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 26 Sep 2002 19:08:07 -0400 Content-Transfer-Encoding: 7bit Adam, I appologize - I have allowed a bit of confusion to creep into this discussion between collections in general, and presence collections. Torrey seems to be interested in presence collections, and so he is proposing a modification to PIDF, or a special use of PIDF, to represent the collection as a whole in the initial response to a subscription. But as currently being discussed, the collection needs to work for any kind of event. (But only one type of event at a time with templates.) This puts different constraints on the problem. There must be a way to define a valid form of initial response without knowing anything about the content type for the members of the collection. More below. Paul Adam Roach wrote: > > > This suggestion might also address one issue I had. When you > > first establish the subscription, or refresh it, or do a > > one-time poll for status, the event mechanism requires that a > > single notification be returned immediately, containing the > > current state of the resource (in this case the contact > > list). This is hard to do if the only notifications are > > relays of notifications from individual members of the collection. > > RFC 3265 requires a NOTIFY. That NOTIFY isn't required to contain > correct state information, just well-formatted state information. I read the requirement as a bit stronger than that. From 3.1.6.2: Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body. Here I think we have to assume the "resource" is the collection, and that "communicate the current resource state" means "communicate the FULL resource state". Sending the state of one, or a subset, of the members of the collection is not the same thing as communicating the current resource state. Nor is it an empty or neutral body. So far there isn't any neutral body that would apply to a collection, except an empty body. The above assumes that the subscribe is immediately accepted. It would also be possible to treat this case as falling under the following from 3.1.6.1: If the notifier cannot immediately create the subscription (e.g., it needs to wait for user input for authorization, or is acting for another node which is not currently reachable), or wishes to mask authorization policy, it will return a "202 Accepted" response. This response indicates that the request has been received and understood, but does not necessarily imply that the subscription has been authorized yet. This could be without a body I think, so it would technically comply. Subsequently, notifications with the state of individual members might be delivered. But this wouldn't be useful in a polling mode. So, the way I read the current proposal and 3256, the only real option for the initial response is an empty body. > > > This idea would begin to solve that problem. But other > > problems remain. For instance there is then still no way to > > poll for the current state of everything in the collection. > > I'm willing to accept that as a limitation of the mechanism. Polling > is usually too heavy on network resources to warrant deployment. Yes, if it is done repeatedly. But certainly there are cases where it is appropriate, such as single-shot use. Maybe this is an acceptable limitation for collections. I'm not sure. > > > Also, the kind of response you are describing doesn't seem to > > fit within the current definition of PIDF. > > It wouldn't *be* PIDF. It would be whatever the collection > {package,template} defines. My vote would be for mime multipart. That comment only made sense in the context of Torrey's message, which is specific to presence collections. In general, I thought the proposal under discussion used the same content type collection.foo at is used for foo. The trouble with that is that it can in general only represent the status of a single foo, not a collection of foo, and so doesn't fulfill the requirements of 3265. > > > Without some kind of change I don't see how to make a > > collection conform to all the rules of an event package. > > Odd. I don't see any barriers. Well, maybe only small barriers. Or maybe I misunderstand what the current proposal is. I think you can make this work in one of the following ways: 1) content type for collection.foo is same as for foo. The initial response for a subscription to content.foo is always without any body. (Assuming that is the same as an empty body.) Subsequently, status for members of the collection is returned in distinct notifications when it becomes available. 2) content type for collection.foo is always mime multipart plus the content type for foo. The initial response can be a multipart with exactly one part for every member if that can be returned promptly. If not it would have to be an empty body rather than returning state for a subset of members. If there happens to only be one member in the collection, it could be returned without the multipart wrapper. Subsequently, status for members of the collection can be returned independently, or grouped in a multipart wrapper. 3) Instead of returning empty bodies as above, return a body containing the definition of the collection. (This will probably need to be defined as a mime type so it can be defined anyway.) Subsequent notifications could conform to 1 or 2 depending on whether subscriber supports multipart. 4) change 3265, relaxing the requirement that the initial notification in response to a subscribe communicate the (full) current state of the resource. This could possibly take the form of a parameter to the subscription indicating that it is ok to omit the initial full status in favor of some kind of partial status. I personally have a preference for (4), because I see other cases where requiring full status (for instance in refreshes) is burdensome. But (3) is also appealing. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 30 08:47:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01420 for ; Mon, 30 Sep 2002 08:47:18 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8UClasr000740; Mon, 30 Sep 2002 08:47:36 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00992; Mon, 30 Sep 2002 08:48:12 -0400 (EDT) Received: from il-tlv-smtpout2.icomverse.com (ns4.comverse.com [192.118.49.3]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00981 for ; Mon, 30 Sep 2002 08:47:26 -0400 (EDT) Received: from il-tlv-mbdg1.comverse.com (il-tlv-mbdg1.comverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g8UCnjt30402 for ; Mon, 30 Sep 2002 15:49:45 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Mon, 30 Sep 2002 15:47:21 +0300 Message-ID: <32B823C1CD4FD5119C0D0002A560F78E079BC413@ismail3.comverse.com> From: Fuxbruner Amihay To: simple@mailman.dynamicsoft.com Cc: Isaac Dudy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2687F.83E0D862" Subject: [Simple] PUBLISH headers Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 30 Sep 2002 15:47:20 +0300 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2687F.83E0D862 Content-Type: text/plain; charset="windows-1255" Hi all, Is there any BNF for PUBLISH headers: PType, PStream & PState ? Thanks Amihay Fuxbruner System Engineering - Signaling R&D Comverse ------_=_NextPart_001_01C2687F.83E0D862 Content-Type: text/html; charset="windows-1255" PUBLISH headers

Hi all,

Is there any BNF for PUBLISH headers: PType, PStream & PState ?

Thanks

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse

------_=_NextPart_001_01C2687F.83E0D862-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 30 12:22:54 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10764 for ; Mon, 30 Sep 2002 12:22:53 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8UGNMsr001804; Mon, 30 Sep 2002 12:23:22 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01681; Mon, 30 Sep 2002 12:24:05 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01670 for ; Mon, 30 Sep 2002 12:23:22 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8UGNGaW029625; Mon, 30 Sep 2002 09:23:17 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABA10122; Mon, 30 Sep 2002 09:21:19 -0700 (PDT) Subject: Re: [Simple] The way forward in data manipulation work Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Markus.Isomaki@nokia.com From: Rohan Mahy In-Reply-To: Message-Id: <22997942-D491-11D6-8705-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 30 Sep 2002 09:24:46 -0700 Content-Transfer-Encoding: 7bit Hi Markus, Not everyone is going to immediately have the same conclusion about SOAP. In order to avoid the syntax wars, I suggest that we focus on the semantics of the kind of RPC mechanism we will need. Once we have debated the semantics, we can then have the syntax discussion. Folks can then propose alternate SOAP and non-SOAP syntax that conveys the agreed-upon semantics. Also, as I said at the mic in Yokohama, I'm not convinced that we need a SIP BIND method. Let's make sure we have a good semantic description of the binding relationship between SIP and data before we cast a mechanism on stone. thanks, -rohan On Wednesday, September 25, 2002, at 06:49 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > I think this would be a good time to see how to go forward with the > charter items related to data manipulation. > > I believe Jonathan is planning to update the Data Manipulation > Requirements draft focusing on two > issues: 1. List management, and 2. Authrozation policy management. In > Yokohama the concensus was to take this draft as basis for WG > requirements, so maybe the next version could be taken as a WG draft. > It is also a good proposal to limit that draft to purely requirements, > leaving the "model" in Chapter 4 out of scope. Maybe then it would be > easiear to agree on the draft. > > However, some kind of model/framework draft (similar to what is being > done in conferencing) is also needed, and eventually it is essential > to agree on what protocols to use. Based on usage guidelines SIP does > not seem to meet the requirements. The current PUBLISH proposal is too > simplistic to be useful in many cases. Instead, some kind of more > flexible RPC mechanism with some support to synchronization seems to > be the best choise. > > My proposal is thus: > 1. Use SOAP/WSDL for data manipulation. In the first phase a > definition is needed only for list and auth. policy management, but > the framework does not need to limit to this. > 2. Use SIP Events in a same fashion as "Message Waiting Indicator" > draft to convey notifications about state changes in the managed > objects. A collection package could be used for optimization purposes. > This spec could still leave the actual synchronization update > mechanism open, but I can imagine SyncML and others could potentially > be usable there. > 3. Take SIP BIND as a default mechanism to make binding between sip: > URIs and SOAP http: URIs. > > In my opinion the framework doc. should define the terminology, have a > few nice ascii-drawings and describe the model and the actors within > points 1-3 above. Also, it should tell how to specify management > interfaces for specific objects, and how to achieve the > synchronization. In addition more specific documents would be needed > for "list management", "authorization policy management" and > "synchronization event package". > > I think we could have the first version of such framework draft could > be ready for the next IETF Atlanta meeting, and discussed there. Then > it could be updated and work on more specific drafts could start. > > But before starting anything like this, I would like to get people's > opinion about the technical part, and of course chairs' opinion about > the process. I'm sure there are plenty of other approaches, but I > haven't heard any proposals so far. In any case, some kind of design > team around this matter might be a good idea. > > Regards, > Markus > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 30 13:42:54 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14321 for ; Mon, 30 Sep 2002 13:42:53 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8UHhQsr002183; Mon, 30 Sep 2002 13:43:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01924; Mon, 30 Sep 2002 13:44:04 -0400 (EDT) Received: from web20702.mail.yahoo.com (web20702.mail.yahoo.com [216.136.226.175]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01913 for ; Mon, 30 Sep 2002 13:43:14 -0400 (EDT) Message-ID: <20020930174312.46005.qmail@web20702.mail.yahoo.com> Received: from [207.46.137.9] by web20702.mail.yahoo.com via HTTP; Mon, 30 Sep 2002 10:43:12 PDT From: Sean Olson Subject: Re: [Simple] The way forward in data manipulation work To: Rohan Mahy , Markus.Isomaki@nokia.com Cc: simple@mailman.dynamicsoft.com In-Reply-To: <22997942-D491-11D6-8705-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 30 Sep 2002 10:43:12 -0700 (PDT) I would also like to see some consideration of the impacts of binding SIP to HTTP. I'm not at all convinced that BIND is the way to go for this. Assuming we want an RPC mechanism for this task (a big assumption), what is the requirement for correlating the data manipulation mechanism with SIP? Is this not implied by the data being manipulated? /sean --- Rohan Mahy wrote: > Hi Markus, > > Not everyone is going to immediately have the same > conclusion about > SOAP. In order to avoid the syntax wars, I suggest > that we focus on > the semantics of the kind of RPC mechanism we will > need. Once we have > debated the semantics, we can then have the syntax > discussion. Folks > can then propose alternate SOAP and non-SOAP syntax > that conveys the > agreed-upon semantics. > > Also, as I said at the mic in Yokohama, I'm not > convinced that we need > a SIP BIND method. Let's make sure we have a good > semantic description > of the binding relationship between SIP and data > before we cast a > mechanism on stone. > > thanks, > -rohan > > > On Wednesday, September 25, 2002, at 06:49 AM, > Markus.Isomaki@nokia.com > wrote: > > > Hi, > > > > I think this would be a good time to see how to go > forward with the > > charter items related to data manipulation. > > > > I believe Jonathan is planning to update the Data > Manipulation > > Requirements draft > focusing on two > > issues: 1. List management, and 2. Authrozation > policy management. In > > Yokohama the concensus was to take this draft as > basis for WG > > requirements, so maybe the next version could be > taken as a WG draft. > > It is also a good proposal to limit that draft to > purely requirements, > > leaving the "model" in Chapter 4 out of scope. > Maybe then it would be > > easiear to agree on the draft. > > > > However, some kind of model/framework draft > (similar to what is being > > done in conferencing) is also needed, and > eventually it is essential > > to agree on what protocols to use. Based on usage > guidelines SIP does > > not seem to meet the requirements. The current > PUBLISH proposal is too > > simplistic to be useful in many cases. Instead, > some kind of more > > flexible RPC mechanism with some support to > synchronization seems to > > be the best choise. > > > > My proposal is thus: > > 1. Use SOAP/WSDL for data manipulation. In the > first phase a > > definition is needed only for list and auth. > policy management, but > > the framework does not need to limit to this. > > 2. Use SIP Events in a same fashion as "Message > Waiting Indicator" > > draft to convey notifications about state changes > in the managed > > objects. A collection package could be used for > optimization purposes. > > This spec could still leave the actual > synchronization update > > mechanism open, but I can imagine SyncML and > others could potentially > > be usable there. > > 3. Take SIP BIND as a default mechanism to make > binding between sip: > > URIs and SOAP http: URIs. > > > > In my opinion the framework doc. should define the > terminology, have a > > few nice ascii-drawings and describe the model and > the actors within > > points 1-3 above. Also, it should tell how to > specify management > > interfaces for specific objects, and how to > achieve the > > synchronization. In addition more specific > documents would be needed > > for "list management", "authorization policy > management" and > > "synchronization event package". > > > > I think we could have the first version of such > framework draft could > > be ready for the next IETF Atlanta meeting, and > discussed there. Then > > it could be updated and work on more specific > drafts could start. > > > > But before starting anything like this, I would > like to get people's > > opinion about the technical part, and of course > chairs' opinion about > > the process. I'm sure there are plenty of other > approaches, but I > > haven't heard any proposals so far. In any case, > some kind of design > > team around this matter might be a good idea. > > > > Regards, > > Markus > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 30 14:03:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15348 for ; Mon, 30 Sep 2002 14:03:49 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8UI4Nsr002326; Mon, 30 Sep 2002 14:04:23 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01998; Mon, 30 Sep 2002 14:05:05 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01985 for ; Mon, 30 Sep 2002 14:04:11 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g8UI3wBf022190; Mon, 30 Sep 2002 14:03:58 -0400 (EDT) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g8UI3uWV027302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Sep 2002 14:03:57 -0400 (EDT) Message-ID: <3D9891EC.4070908@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: Rohan Mahy , Markus.Isomaki@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] The way forward in data manipulation work References: <20020930174312.46005.qmail@web20702.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 30 Sep 2002 14:03:24 -0400 Content-Transfer-Encoding: 7bit We have discussed this before, but I still fail to see how you can, in general, deduce from a SIP URL what the corresponding non-SIP URL is. In many cases, you will have other means to establish the binding (e.g., one could consider the various *-Info headers an example of such a binding), but these means tend to be within a dialog or for a particular request. Sean Olson wrote: > I would also like to see some consideration > of the impacts of binding SIP to HTTP. I'm not > at all convinced that BIND is the way to go > for this. > > Assuming we want an RPC mechanism > for this task (a big assumption), what is the > requirement for correlating the data manipulation > mechanism with SIP? Is this not implied by the > data being manipulated? > > /sean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 30 14:25:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16418 for ; Mon, 30 Sep 2002 14:25:51 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8UIQMsr002523; Mon, 30 Sep 2002 14:26:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02096; Mon, 30 Sep 2002 14:27:04 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02085 for ; Mon, 30 Sep 2002 14:26:58 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8UIRZF01699 for ; Mon, 30 Sep 2002 21:27:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 30 Sep 2002 21:17:59 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Sep 2002 21:17:59 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id VAA02255; Mon, 30 Sep 2002 21:17:58 +0300 (EETDST) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.6/8.11.2) id g8UIHLB08436; Mon, 30 Sep 2002 21:17:22 +0300 To: Seonman Kim Cc: Subject: Re: [Simple] Error when sending NOTIFY to MSN messenger (RTC) References: <01eb01c264e5$aba9b730$400015ac@skim> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <01eb01c264e5$aba9b730$400015ac@skim> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 30 Sep 2002 18:17:59.0218 (UTC) FILETIME=[B4D36920:01C268AD] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 30 Sep 2002 21:17:20 +0300 Seonman Kim writes: >And if someone knows the format of content body for NOTIFY message used >Windows RTC, please let me know. They use a malformed (or embraced & extended, if you like it that way) version of xpidf. You can easily find out their presence format by sending a SUBSCRIBE to a Windows Messenger, then using same shstuff when sending to Messenger. Pekka _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Sep 30 15:29:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18301 for ; Mon, 30 Sep 2002 15:29:50 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8UJUOsr002833; Mon, 30 Sep 2002 15:30:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02293; Mon, 30 Sep 2002 15:31:04 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02282 for ; Mon, 30 Sep 2002 15:30:40 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8UJUTaW007985; Mon, 30 Sep 2002 12:30:29 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABA13994; Mon, 30 Sep 2002 12:28:31 -0700 (PDT) Subject: Re: [Simple] The way forward in data manipulation work Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Sean Olson , Markus.Isomaki@nokia.com, simple@mailman.dynamicsoft.com To: Henning Schulzrinne From: Rohan Mahy In-Reply-To: <3D9891EC.4070908@cs.columbia.edu> Message-Id: <492739AA-D4AB-11D6-8705-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 30 Sep 2002 12:31:58 -0700 Content-Transfer-Encoding: 7bit On Monday, September 30, 2002, at 11:03 AM, Henning Schulzrinne wrote: > We have discussed this before, but I still fail to see how you can, in > general, "in general" well, that's the disagreement. In all the specific motivating scenarios for SIP BIND, there has been another very reasonable way to map between the SIP and non-SIP URIs. I'm not convinced that a general solution is needed (the requirements don't bear that out IMO). thanks, -rohan > deduce from a SIP URL what the corresponding non-SIP URL is. In many > cases, you will have other means to establish the binding (e.g., one > could consider the various *-Info headers an example of such a > binding), but these means tend to be within a dialog or for a > particular request. > > Sean Olson wrote: >> I would also like to see some consideration >> of the impacts of binding SIP to HTTP. I'm not >> at all convinced that BIND is the way to go >> for this. Assuming we want an RPC mechanism >> for this task (a big assumption), what is the >> requirement for correlating the data manipulation >> mechanism with SIP? Is this not implied by the >> data being manipulated? >> /sean > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple