From mailnull@www1.ietf.org Mon Mar 3 02:33:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10982 for ; Mon, 3 Mar 2003 02:33:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h237heB19904 for simple-archive@odin.ietf.org; Mon, 3 Mar 2003 02:43:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h237hdp19901 for ; Mon, 3 Mar 2003 02:43:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10972 for ; Mon, 3 Mar 2003 02:33:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h237hUp19889; Mon, 3 Mar 2003 02:43:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h237gbp19844 for ; Mon, 3 Mar 2003 02:42:37 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10963 for ; Mon, 3 Mar 2003 02:32:13 -0500 (EST) 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 h237Wvo13324 for ; Mon, 3 Mar 2003 09:32:57 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Mar 2003 09:34:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 09:34:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 09:34:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Garbage collection in publish RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701428E51@esebe019.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLeR2FZk/FTIHt8QgS1SlysRoio8wAAnhvAADHbsEA= To: , , , , , X-OriginalArrivalTime: 03 Mar 2003 07:34:13.0660 (UTC) FILETIME=[49D07DC0:01C2E157] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h237gcp19845 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 Mar 2003 09:34:12 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Think of the famous scenario where I'm at the office with my PUA publishing a tuple that I'm "in the office". Now I go home and forget to turn that off, keeping in mind that there are refreshes going on by that PUA. At home, I switch my home pc on and my PUA there publishes a tuple to override the one sent by the PUA at the office. In this case, a stack model does not work, my watchers would get my presence "in the office, "at home" alternating throughout the night. A replace model looks better, once I publish from home, the compositor simply stops accepting publications from the office. But this fails once I go back to the office the next day, leaving my home pc running (how do I now tell the compositor to ignore the tuple published from home and start accepting ones from the office? they are both now publishing refreshes). The "winner" model is even better. But what is an example of that local policy? especially when the two PUAs are not synchronised to publish at the same time? I think there is a need for a PUA to send some sort of flag in the publish telling the compositor from which PUA to accept publications from. Example is a flag saying "this is not a refresh". When I go to the office in the morning, I press a button on my PUA for it to send a new publish with that flag set. This is a kind of replace model combined with winner :) Of course time stamping helps here also, but is time stamp set to when the tuple is created or set every time before a tuple is published. If it is the former, then that could be used by the compositor (local policy) to determine which PUA is the winner. When I go to the office the next day, I re-publish that tuple with an updated time stamp. Regards, Hisham > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, February 27, 2003 3:32 PM > To: seancolson@yahoo.com; jon.peterson@neustar.biz; Isomaki Markus > (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); simple@ietf.org > Subject: Garbage collection in publish RE: [Simple] > draft-ietf-simple-publish-reqs-00 > > > Hi, > > Comments inline. > > > -----Original Message----- > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > Sent: 27 February, 2003 11:27 > > To: Niemi Aki (NMP/Helsinki); jon.peterson@neustar.biz; > > Isomaki Markus > > (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); simple@ietf.org > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > So it seems the main issue is garbage collection. I > > > think there is a requirement here not yet covered in > > > the reqs-draft, that the PUBLISH mechanism must > > > provide the composer means to do garbage collection > > > in case a PUA dies. I think this implies a hearbeat > > > / refresh type function for the publications. > > > > > > Then there's another question on how a composer does > > > grabage collection. I think the two options > > > presented in this thread are the "replace" model and > > > the "stack" model. In theory, the stack model is > > > better, but I can't think of an actual use case > > > scenario where that would be striclty needed. So to > > > avoid the complexity, I'm fine with the replace > > > model. > > > > I'm confused about these two models. Are you speaking > > about two different PUAs publishing to the same > > tuple -or- are do you mean two different PUAs > > publishing to two different tuples that the > > composer aggregates? I'm trying to understand how > > these models relate to garbage collection (and if > > there are other models we need to consider) > > > > I assume you are talking about > > two PUAs publishing to the same tuple. > > Yes. > > > In the stack model, when one > > PUA dies its state is popped and the second PUA's > > state becomes the new state for that tuple. > > > > In the replace model, I assume you mean latest > > PUA wins and therefore when one PUA dies, the other > > would have to re-PUBLISH its state for it to take > > effect -- how does the second PUA know to re-PUBLISH > > and when does that occur? > > I was assuming that the second PUA would simply re-publish > when it is its time to refresh. In fact, the stack model is > only needed if publications from different PUAs had different > expirys (like one being a multiple of the other). But if the > composer can always guarantee that the refresh rates are > aligned, I think the two models are the same. > > And since the composer can always lower a publisher's rate, I > guess the only thing missing is "Min-Expires" for the opposite case? > > > In a possible third model, local policy at the > > composer > > determines the "winner". It's not necessarily a stack > > or a last-one-wins model. In this case, it may not > > be necessary for the second PUA to re-PUBLISH. > > This is true, there are actually three models. Out of the > three, I think the "replace" model and the "winner" model are > the relevant ones. > > Cheers, > Aki > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 3 06:34:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17425 for ; Mon, 3 Mar 2003 06:34:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23BiME07470 for simple-archive@odin.ietf.org; Mon, 3 Mar 2003 06:44:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23BiMp07467 for ; Mon, 3 Mar 2003 06:44:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17416 for ; Mon, 3 Mar 2003 06:33:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23BiGp07455; Mon, 3 Mar 2003 06:44:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Bhbp07430 for ; Mon, 3 Mar 2003 06:43:37 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17413 for ; Mon, 3 Mar 2003 06:33:08 -0500 (EST) 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 h23BXpo27813 for ; Mon, 3 Mar 2003 13:33:51 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Mar 2003 13:35:08 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 13:35:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194518D@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLfCaNSgWlPRWmJSjy39CDZEEiY3QCbcdCw To: , , , , , X-OriginalArrivalTime: 03 Mar 2003 11:35:08.0023 (UTC) FILETIME=[F1494070:01C2E178] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23Bhbp07431 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 Mar 2003 13:35:07 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Comments inline. > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 28 February, 2003 11:12 > To: Khartabil Hisham (NMP/Helsinki); > jon.peterson@neustar.biz; Niemi Aki > (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss Krisztian > (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > --- hisham.khartabil@nokia.com wrote: > > When you send a NOTIFY with status of CLOSED. Is > > that soft state? does it expire? I guess not. So, we > > have some sort of hard state. How else would I > > interpret a status of closed? > > Hmmm. Does this mean you would expect a PUA to > store this status persistently? The NOTIFY is > a snapshot of state at a particular point in time. > It can be considered to expire when the subscription > expires --- after your subscription expires, there is > no way to refresh this state other than > re-subscribing. I would interpret the state in the > NOTIFY to endure until another NOTIFY is received or > until the subscription expires, whichever comes first. > > > > > Could it be like the following: > > - whatever is published in a tuple is soft state. > > - When the state published expires, we default to > > the hard state (this could be open or closed). > > That is exactly what I had in mind. The only open > issue is how to set this hard state. I believe this > is best done through a separate administrative > interface and not through PUBLISH. I'm open to other > opinions. If someone can come up with a simple > mechanism for indicating hard state in the PUBLISH > request, I don't have any strong objections to doing > this. I'm actually starting to lean towards using PUBLISH for this. The rationale being that this seems an integral part of publishing, and it doesn't seem useful to have to leave this bit out and to a separate administrative interface. If such an interface already existed, it surely could be reused. But mandating such an interface just for this purpose seems heavy. Also, as the main motivation for using PUBLISH in the first place was routing, and that surely applies here as well. I'm afraid if we don't solve the hard state with PUBLISH, it won't get solved at all. So, I see a few possible options: 1) special case some Expires value for this, 2) add an Event param for hard state, or 3) create a Require option for this. Does any one of these seem reasonable? Cheers, Aki > > > > > Are you Sean suggesting that this hard state is not > > set using the PUBLISH message? > > That's my opinion. Again, I'm open to being proven > wrong. > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Peterson, Jon > > [mailto:jon.peterson@neustar.biz] > > > Sent: Wednesday, February 26, 2003 9:55 PM > > > To: Niemi Aki (NMP/Helsinki); Isomaki Markus > > (NRC/Helsinki); Kiss > > > Krisztian (NRC/Tampere); simple@ietf.org > > > Subject: RE: [Simple] > > draft-ietf-simple-publish-reqs-00 > > > > > > > > > > > > The argument that there is some 'hard state' that > > exists in > > > the absence of > > > any publications (namely, the state or document > > expressing > > > that the user is > > > away) is in some ways attractive, yes. You are > > correct that a > > > registrar > > > doesn't supply null contact addresses or something > > when the > > > user in question > > > has no registration, but rather provides a > > specific failure > > > response. Of > > > course, the events framework has a different > > semantics - > > > subscriptions are > > > accepted when there is currently no published > > presence > > > information for a > > > user. Sending a failure response wouldn't be > > workable. > > > > > > There are, however, a couple of NOTIFY syntaxes > > that might > > > communicate that > > > there is no available presence information. One is > > that a > > > NOTIFY might not > > > contain any body. Another is that the presence > > agent or > > > compositor invents a > > > simple tuple that contains a status of CLOSED. The > > latter > > > option may sound a > > > lot like hard state, whereas the former does not. > > Whether or > > > not the latter > > > option is really 'state' though is debatable - > > almost an > > > implementation > > > question. Having a default response to queries in > > the absence > > > of state does > > > not, in and of itself, constitute state in my > > opinion. It > > > does not require, > > > for example, per-user tables in memory that have > > some > > > specific values, as > > > far as I can imagine how it would be implemented. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: aki.niemi@nokia.com > > [mailto:aki.niemi@nokia.com] > > > > Sent: Wednesday, February 26, 2003 3:23 AM > > > > To: jon.peterson@neustar.biz; > > Markus.Isomaki@nokia.com; > > > > krisztian.kiss@nokia.com; simple@ietf.org > > > > Subject: RE: [Simple] > > draft-ietf-simple-publish-reqs-00 > > > > > > > > > > > > Hi, > > > > > > > > Few comments inline. BTW, a good set of > > requirements. > > > > > > > > Cheers, > > > > Aki > > > > > > > [snip] > > > > > > > > > Of course, some sort of management interface > > could be > > > > > defined so that users > > > > > could do their own manual garbage collection. > > But that would > > > > > be annoying. > > > > > The REGISTER model, in which stale > > information automatically > > > > > goes away for > > > > > you, is much more suitable to real-time > > communications. > > > > > > > > Similarly, when all devices are off, or out of > > coverage, I > > > > would like to see a presence document that says > > *something* > > > > even though that something is unavailable at the > > moment. > > > > > > > > Just like when I get a 480 and not 404 back when > > the callee > > > > is in an unregistered state. > > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 3 08:18:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23598 for ; Mon, 3 Mar 2003 08:18:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23DSD915903 for simple-archive@odin.ietf.org; Mon, 3 Mar 2003 08:28:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DSDp15900 for ; Mon, 3 Mar 2003 08:28:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23592 for ; Mon, 3 Mar 2003 08:17:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DS9p15876; Mon, 3 Mar 2003 08:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DRcp15845 for ; Mon, 3 Mar 2003 08:27:38 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23580 for ; Mon, 3 Mar 2003 08:17:08 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h23DIdXa008754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Mar 2003 08:18:40 -0500 (EST) Message-ID: <3E63564B.2030002@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, seancolson@yahoo.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org Subject: Re: Garbage collection in publish RE: [Simple] draft-ietf-simple-publish-reqs-00 References: <2038BCC78B1AD641891A0D1AE133DBB701428E51@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701428E51@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Mar 2003 08:19:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It sounds like you're inventing WebDAV, one requirement at at time... hisham.khartabil@nokia.com wrote: > Think of the famous scenario where I'm at the office with my PUA publishing a tuple that I'm "in the office". Now I go home and forget to turn that off, keeping in mind that there are refreshes going on by that PUA. > > At home, I switch my home pc on and my PUA there publishes a tuple to override the one sent by the PUA at the office. > > In this case, a stack model does not work, my watchers would get my presence "in the office, "at home" alternating throughout the night. > > A replace model looks better, once I publish from home, the compositor simply stops accepting publications from the office. But this fails once I go back to the office the next day, leaving my home pc running (how do I now tell the compositor to ignore the tuple published from home and start accepting ones from the office? they are both now publishing refreshes). > > The "winner" model is even better. But what is an example of that local policy? especially when the two PUAs are not synchronised to publish at the same time? > > I think there is a need for a PUA to send some sort of flag in the publish telling the compositor from which PUA to accept publications from. Example is a flag saying "this is not a refresh". When I go to the office in the morning, I press a button on my PUA for it to send a new publish with that flag set. This is a kind of replace model combined with winner :) > > Of course time stamping helps here also, but is time stamp set to when the tuple is created or set every time before a tuple is published. If it is the former, then that could be used by the compositor (local policy) to determine which PUA is the winner. When I go to the office the next day, I re-publish that tuple with an updated time stamp. > > Regards, > Hisham > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 3 09:58:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27772 for ; Mon, 3 Mar 2003 09:58:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23F8BU24487 for simple-archive@odin.ietf.org; Mon, 3 Mar 2003 10:08:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23F8Bp24484 for ; Mon, 3 Mar 2003 10:08:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27747 for ; Mon, 3 Mar 2003 09:57:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23F85p24473; Mon, 3 Mar 2003 10:08:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23F74p23674 for ; Mon, 3 Mar 2003 10:07:04 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27680 for ; Mon, 3 Mar 2003 09:56:29 -0500 (EST) From: hisham.khartabil@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 h23F1lY02342 for ; Mon, 3 Mar 2003 17:01:47 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Mar 2003 16:58:30 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 16:58:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE72FE@esebe019.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLfCaNSgWlPRWmJSjy39CDZEEiY3QCbcdCwAAdJ7zA= To: , , , , , X-OriginalArrivalTime: 03 Mar 2003 14:58:29.0839 (UTC) FILETIME=[5A229DF0:01C2E195] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23F75p23675 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 Mar 2003 16:58:28 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I basically agree with Aki about interface reuse, but since we are still at the stage of negotiating requirements, we need to agree if a requirement that mandates the solution to support hard state publication to be present in the requirements draft. Now to the solution: What about a PIDF extension that overrides the Expires-header value? or going back to the expires-like header that the first version of publish had (I can't remember the name of that header). This expires like header allows indicating hard state. Regards, Hisham > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Monday, March 03, 2003 1:35 PM > To: seancolson@yahoo.com; Khartabil Hisham (NMP/Helsinki); > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki); Kiss > Krisztian > (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > Hi, > > Comments inline. > > > -----Original Message----- > > From: ext Sean Olson [mailto:seancolson@yahoo.com] > > Sent: 28 February, 2003 11:12 > > To: Khartabil Hisham (NMP/Helsinki); > > jon.peterson@neustar.biz; Niemi Aki > > (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss Krisztian > > (NRC/Tampere); simple@ietf.org > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > > > --- hisham.khartabil@nokia.com wrote: > > > When you send a NOTIFY with status of CLOSED. Is > > > that soft state? does it expire? I guess not. So, we > > > have some sort of hard state. How else would I > > > interpret a status of closed? > > > > Hmmm. Does this mean you would expect a PUA to > > store this status persistently? The NOTIFY is > > a snapshot of state at a particular point in time. > > It can be considered to expire when the subscription > > expires --- after your subscription expires, there is > > no way to refresh this state other than > > re-subscribing. I would interpret the state in the > > NOTIFY to endure until another NOTIFY is received or > > until the subscription expires, whichever comes first. > > > > > > > > Could it be like the following: > > > - whatever is published in a tuple is soft state. > > > - When the state published expires, we default to > > > the hard state (this could be open or closed). > > > > That is exactly what I had in mind. The only open > > issue is how to set this hard state. I believe this > > is best done through a separate administrative > > interface and not through PUBLISH. I'm open to other > > opinions. If someone can come up with a simple > > mechanism for indicating hard state in the PUBLISH > > request, I don't have any strong objections to doing > > this. > > I'm actually starting to lean towards using PUBLISH for this. > The rationale being that this seems an integral part of > publishing, and it doesn't seem useful to have to leave this > bit out and to a separate administrative interface. If such > an interface already existed, it surely could be reused. But > mandating such an interface just for this purpose seems heavy. > > Also, as the main motivation for using PUBLISH in the first > place was routing, and that surely applies here as well. I'm > afraid if we don't solve the hard state with PUBLISH, it > won't get solved at all. > > So, I see a few possible options: 1) special case some > Expires value for this, 2) add an Event param for hard state, > or 3) create a Require option for this. > > Does any one of these seem reasonable? > > Cheers, > Aki > > > > > > > > > Are you Sean suggesting that this hard state is not > > > set using the PUBLISH message? > > > > That's my opinion. Again, I'm open to being proven > > wrong. > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: ext Peterson, Jon > > > [mailto:jon.peterson@neustar.biz] > > > > Sent: Wednesday, February 26, 2003 9:55 PM > > > > To: Niemi Aki (NMP/Helsinki); Isomaki Markus > > > (NRC/Helsinki); Kiss > > > > Krisztian (NRC/Tampere); simple@ietf.org > > > > Subject: RE: [Simple] > > > draft-ietf-simple-publish-reqs-00 > > > > > > > > > > > > > > > > The argument that there is some 'hard state' that > > > exists in > > > > the absence of > > > > any publications (namely, the state or document > > > expressing > > > > that the user is > > > > away) is in some ways attractive, yes. You are > > > correct that a > > > > registrar > > > > doesn't supply null contact addresses or something > > > when the > > > > user in question > > > > has no registration, but rather provides a > > > specific failure > > > > response. Of > > > > course, the events framework has a different > > > semantics - > > > > subscriptions are > > > > accepted when there is currently no published > > > presence > > > > information for a > > > > user. Sending a failure response wouldn't be > > > workable. > > > > > > > > There are, however, a couple of NOTIFY syntaxes > > > that might > > > > communicate that > > > > there is no available presence information. One is > > > that a > > > > NOTIFY might not > > > > contain any body. Another is that the presence > > > agent or > > > > compositor invents a > > > > simple tuple that contains a status of CLOSED. The > > > latter > > > > option may sound a > > > > lot like hard state, whereas the former does not. > > > Whether or > > > > not the latter > > > > option is really 'state' though is debatable - > > > almost an > > > > implementation > > > > question. Having a default response to queries in > > > the absence > > > > of state does > > > > not, in and of itself, constitute state in my > > > opinion. It > > > > does not require, > > > > for example, per-user tables in memory that have > > > some > > > > specific values, as > > > > far as I can imagine how it would be implemented. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: aki.niemi@nokia.com > > > [mailto:aki.niemi@nokia.com] > > > > > Sent: Wednesday, February 26, 2003 3:23 AM > > > > > To: jon.peterson@neustar.biz; > > > Markus.Isomaki@nokia.com; > > > > > krisztian.kiss@nokia.com; simple@ietf.org > > > > > Subject: RE: [Simple] > > > draft-ietf-simple-publish-reqs-00 > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Few comments inline. BTW, a good set of > > > requirements. > > > > > > > > > > Cheers, > > > > > Aki > > > > > > > > > [snip] > > > > > > > > > > > Of course, some sort of management interface > > > could be > > > > > > defined so that users > > > > > > could do their own manual garbage collection. > > > But that would > > > > > > be annoying. > > > > > > The REGISTER model, in which stale > > > information automatically > > > > > > goes away for > > > > > > you, is much more suitable to real-time > > > communications. > > > > > > > > > > Similarly, when all devices are off, or out of > > > coverage, I > > > > > would like to see a presence document that says > > > *something* > > > > > even though that something is unavailable at the > > > moment. > > > > > > > > > > Just like when I get a 480 and not 404 back when > > > the callee > > > > > is in an unregistered state. > > > > > > > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 3 12:36:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04235 for ; Mon, 3 Mar 2003 12:36:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23HkPr07971 for simple-archive@odin.ietf.org; Mon, 3 Mar 2003 12:46:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23HkPp07968 for ; Mon, 3 Mar 2003 12:46:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04220 for ; Mon, 3 Mar 2003 12:35:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23HkLp07941; Mon, 3 Mar 2003 12:46:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23HjVp07861 for ; Mon, 3 Mar 2003 12:45:31 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04201 for ; Mon, 3 Mar 2003 12:34:57 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 3 Mar 2003 17:39:39 +0000 Received: from gbnewp1014m ([172.25.1.88]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Mon, 3 Mar 2003 17:37:00 +0000 From: "Neil Deason" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Mar 2003 17:37:00.0799 (UTC) FILETIME=[7F1BF0F0:01C2E1AB] Content-Transfer-Encoding: 7bit Subject: [Simple] SIP and HTTP for presence publication Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 Mar 2003 09:36:58 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit draft-ietf-simple-publish-reqs-00 discusses the use of either HTTP or SIP for presence state publication as if they have to be mutually exclusive. As the draft points out HTTP provides a much better data transfer mechanism than SIP. SIP has application layer routing richness that HTTP does not. So why not use SIP to initiate/modify/terminate a presence state data transfer session that uses HTTP? Cheers, Neil. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 4 04:33:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10345 for ; Tue, 4 Mar 2003 04:33:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h249hPc20199 for simple-archive@odin.ietf.org; Tue, 4 Mar 2003 04:43:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249hPp20196 for ; Tue, 4 Mar 2003 04:43:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10296 for ; Tue, 4 Mar 2003 04:32:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249hJp20175; Tue, 4 Mar 2003 04:43:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249gMp20099 for ; Tue, 4 Mar 2003 04:42:22 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10230 for ; Tue, 4 Mar 2003 04:31:25 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h249XQ829933 for ; Tue, 4 Mar 2003 09:33:26 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FS3MPX58; Tue, 4 Mar 2003 09:33:26 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 09:32:23 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: simple@ietf.org Subject: RE: [Simple] I-D ACTION:draft-lonnfors-simple-partial-notify-00.t xt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E230.F2F0264C" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Mar 2003 09:32:18 -0000 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_01C2E230.F2F0264C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, I am not convinced by the discussion on SIGCOMP which has been = introduced into this draft (Section 1.1). Firstly, is this even the correct place to describe these issues ?? If = we really expect to see large binary content in SIP messages, then we = should document the impacts for SIGCOMP somewhere more general - not buried in = a presence partial notifications discussion. If we do not expect such = content, we should document that fact somewhere more general too. We need to = make a decision one way or the other because it has important implications for = the design of SIGCOMP compressors. Secondly, two of the solutions referred to involve the SIGCOMP layer = having knowledge of the content type, which is a major architectural change. Presently, the SIGCOMP layer does not parse SIP, MIME etc. Thirdly, the last solution mentioned involves leaving 'binary' content uncompressed, but this does not necessarily mean that this content will = not mess up the dynamic dictionary. The compression scheme would need to = detect 'uncompressible' parts of the message and leave these out of the = dictionary. So, if we expect binary content in SIP, we should document the impacts = in SIGCOMP somewhere in the sip/sipping WGs. We should decide whether we = expect SIGCOMP to cope with such binary content in an efficient way (i.e. if = we think the same content will be sent multiple times) or whether we are = happy for SIGCOMP to leave such content uncompressed (i.e. if we think the = same content will generally only be sent once). Finally, I think we concluded in the last discussion on this that it = was not appropriate to include in-line binary content in the presence document itself due to encoding issues - there is still some reference to this = in the draft. Large binary content would need to referenced from the presence document, and we left it open whether this reference could be to other = MIME parts within the same SIP message. Regards, Mark > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 24 February 2003 11:45 > Cc: simple@ietf.org > Subject: [Simple] I-D=20 > ACTION:draft-lonnfors-simple-partial-notify-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Partial Notification of Presence Information > Author(s) : J. Costa-Requena, E. Leppanen et al. > Filename : draft-lonnfors-simple-partial-notify-00.txt > Pages : 24 > Date : 2003-2-21 > =09 > A Presence service implemented using SIMPLE has some constraints for=20 > delivering presence information to devices with low data processing=20 > capabilities, small display, and limited battery power. Other=20 > limitations can be caused by the interface between the terminal and=20 > the network, i.e. over radio links with high latency and low=20 > bandwidth. This memo presents a solution that aids in reducing the=20 > impact of those constrains and increasing efficiency, by introducing=20 > a new MIME-type =E6partial notifications=C6 and a Require header=20 > extension =E6partial-notification=C6. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part > ial-notify-00.txt >=20 > To remove yourself from the IETF Announcement list, send a message to = > ietf-announce-request with the word unsubscribe in the body=20 > of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-lonnfors-simple-partial-notify-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-lonnfors-simple-partial-notify-00.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01C2E230.F2F0264C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] I-D = ACTION:draft-lonnfors-simple-partial-notify-00.txt

All,

I am not convinced by the discussion on SIGCOMP which = has been introduced into this draft (Section 1.1).

Firstly, is this even the correct place to describe = these issues ?? If we really expect to see large binary content in SIP = messages, then we should document the impacts for SIGCOMP somewhere = more general - not buried in a presence partial notifications = discussion. If we do not expect such content, we should document that = fact somewhere more general too. We need to make a decision one way or = the other because it has important implications for the design of = SIGCOMP compressors.

Secondly, two of the solutions referred to involve = the SIGCOMP layer having knowledge of the content type, which is a = major architectural change. Presently, the SIGCOMP layer does not parse = SIP, MIME etc.

Thirdly, the last solution mentioned involves leaving = 'binary' content uncompressed, but this does not necessarily mean that = this content will not mess up the dynamic dictionary. The compression = scheme would need to detect 'uncompressible' parts of the message and = leave these out of the dictionary.

So, if we expect binary content in SIP, we should = document the impacts in SIGCOMP somewhere in the sip/sipping WGs. We = should decide whether we expect SIGCOMP to cope with such binary = content in an efficient way (i.e. if we think the same content will be = sent multiple times) or whether we are happy for SIGCOMP to leave such = content uncompressed (i.e. if we think the same content will generally = only be sent once).

Finally, I think we concluded in the last discussion = on this that it was not appropriate to include in-line binary content = in the presence document itself due to encoding issues - there is still = some reference to this in the draft. Large binary content would need to = referenced from the presence document, and we left it open whether this = reference could be to other MIME parts within the same SIP = message.

Regards,

Mark

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> Sent: 24 February 2003 11:45
> Cc: simple@ietf.org
> Subject: [Simple] I-D
> = ACTION:draft-lonnfors-simple-partial-notify-00.txt
>
>
> A New Internet-Draft is available from the = on-line
> Internet-Drafts directories.
>
>
>       = Title           : Partial = Notification of Presence Information
>       = Author(s)       : J. Costa-Requena, E. = Leppanen et al.
>       = Filename        : = draft-lonnfors-simple-partial-notify-00.txt
>       = Pages           : = 24
>       = Date            : = 2003-2-21
>      
> A Presence service implemented using SIMPLE has = some constraints for
> delivering presence information to devices with = low data processing
> capabilities, small display, and limited = battery power. Other
> limitations can be caused by the interface = between the terminal and
> the network, i.e. over radio links with high = latency and low
> bandwidth. This memo presents a solution that = aids in reducing the
> impact of those constrains and increasing = efficiency, by introducing
> a new MIME-type =E6partial notifications=C6 and = a Require header
> extension =E6partial-notification=C6.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lonnfors-sim= ple-part
> ial-notify-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-lonnfors-simple-partial-notify-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-lonnfors-simple-partial-notify-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_001_01C2E230.F2F0264C-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 4 05:01:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10944 for ; Tue, 4 Mar 2003 05:01:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24AC9i22186 for simple-archive@odin.ietf.org; Tue, 4 Mar 2003 05:12:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24AC9p22183 for ; Tue, 4 Mar 2003 05:12:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10939 for ; Tue, 4 Mar 2003 05:01:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24AC5p22174; Tue, 4 Mar 2003 05:12:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24ABVp22148 for ; Tue, 4 Mar 2003 05:11:31 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10914 for ; Tue, 4 Mar 2003 05:00:34 -0500 (EST) 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 h24A5mY22718 for ; Tue, 4 Mar 2003 12:05:48 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Mar 2003 12:02:31 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Mar 2003 12:02:30 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Mar 2003 12:02:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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-lonnfors-simple-partial-notify-00.txt Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1717B@esebe004.ntc.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-lonnfors-simple-partial-notify-00.txt Thread-Index: AcLiMVNA2BaWiSXUSWOH+wl9dprAfAAAJOFw To: , X-OriginalArrivalTime: 04 Mar 2003 10:02:30.0729 (UTC) FILETIME=[2B4B3B90:01C2E235] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24ABVp22149 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Mar 2003 12:02:30 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi mark, Inline inside : All, I am not convinced by the discussion on SIGCOMP which has been introduced into this draft (Section 1.1). Firstly, is this even the correct place to describe these issues ?? Yes, you are right. To move discussion forward we needed to place text somewhere and in this case only place we could place it was the partial notification draft. If we really expect to see large binary content in SIP messages, then we should document the impacts for SIGCOMP somewhere more general - not buried in a presence partial notifications discussion. Yes If we do not expect such content, we should document that fact somewhere more general too. We need to make a decision one way or the other because it has important implications for the design of SIGCOMP compressors. This is probably true. Secondly, two of the solutions referred to involve the SIGCOMP layer having knowledge of the content type, which is a major architectural change. Presently, the SIGCOMP layer does not parse SIP, MIME etc. We have been talking about this issue with SIGCOMP author Z. Liu (as at least I not an expert in this are) and these were mentioned as possible solutions for this problem. I am also not convinced that these two solutions are the best ones and if other people feel same I am quite happy to drop them. Thirdly, the last solution mentioned involves leaving 'binary' content uncompressed, but this does not necessarily mean that this content will not mess up the dynamic dictionary. The compression scheme would need to detect 'uncompressible' parts of the message and leave these out of the dictionary. As far as I know this should be quite easy thing to accomplish for a SIGCOMP implementation. Of course it should be specified (recommended) somewhere what is appropriate threshold value for data which should be considered 'uncompressible'. So, if we expect binary content in SIP, we should document the impacts in SIGCOMP somewhere in the sip/sipping WGs. We should decide whether we expect SIGCOMP to cope with such binary content in an efficient way (i.e. if we think the same content will be sent multiple times) or whether we are happy for SIGCOMP to leave such content uncompressed (i.e. if we think the same content will generally only be sent once). Finally, I think we concluded in the last discussion on this that it was not appropriate to include in-line binary content in the presence document itself due to encoding issues - there is still some reference to this in the draft. Large binary content would need to referenced from the presence document, and we left it open whether this reference could be to other MIME parts within the same SIP message. Yes, this is our mistake. I also agree that large binary data should not be in-line with other presence data. This will be fixed in next version Thanks for comments - Mikko Regards, Mark > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 24 February 2003 11:45 > Cc: simple@ietf.org > Subject: [Simple] I-D > ACTION:draft-lonnfors-simple-partial-notify-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Partial Notification of Presence Information > Author(s) : J. Costa-Requena, E. Leppanen et al. > Filename : draft-lonnfors-simple-partial-notify-00.txt > Pages : 24 > Date : 2003-2-21 > > A Presence service implemented using SIMPLE has some constraints for > delivering presence information to devices with low data processing > capabilities, small display, and limited battery power. Other > limitations can be caused by the interface between the terminal and > the network, i.e. over radio links with high latency and low > bandwidth. This memo presents a solution that aids in reducing the > impact of those constrains and increasing efficiency, by introducing > a new MIME-type æpartial notificationsÆ and a Require header > extension æpartial-notificationÆ. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part > ial-notify-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-lonnfors-simple-partial-notify-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-lonnfors-simple-partial-notify-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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 4 13:14:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04299 for ; Tue, 4 Mar 2003 13:14:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24IPKa01472 for simple-archive@odin.ietf.org; Tue, 4 Mar 2003 13:25:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24IPKp01469 for ; Tue, 4 Mar 2003 13:25:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04288 for ; Tue, 4 Mar 2003 13:14:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24IPDp01421; Tue, 4 Mar 2003 13:25:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24IKLp29746 for ; Tue, 4 Mar 2003 13:20:21 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04202 for ; Tue, 4 Mar 2003 13:09:16 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h24IB8H25896; Tue, 4 Mar 2003 12:11:08 -0600 Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 From: Ben Campbell To: aki.niemi@nokia.com Cc: Sean Olson , Jon Peterson , Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194518A@esebe013.ntc.nokia.com> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194518A@esebe013.ntc.nokia.com> Content-Type: text/plain Message-Id: <1046801459.2110.20.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 04 Mar 2003 12:10:59 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-02-27 at 11:15, aki.niemi@nokia.com wrote: > Hi, > > Maybe I'm missing something here, but as I see it, in order to do garbage collection, the composer needs to assign PUAs to refresh their publications in certain intervals. The shorter this refresh period is, the more efficient the garbage collection is; the longer the period, the more garbage state will be around. > > Now I agree that a large Expires would seem to accomplish the hard-state publication, but to what value do we draw the line? When will the composer simply accept a long lasting publication, and not reduce the Expires value to its local default to enable efficient garbage collection? > > I think the problem is that the Expires has dual meening in this case. It implies the lifetime of the presence info, as well as the validity period of the publication. Unless we standardize a value for Expires, after which it becomes solely the lifetime of the presence info (to indicate that the state is not to be garbage collected), different systems will behave differently. > > What if we define this explicitly, say Expires=0, or Expires=4294967295 means this is meant to be stored "indefinitely"? > Sorry for jumping late into the conversation, but the problem is, I think, that this approach _assumes_ the compositor supports a concept of hard state, or default state, or whatever you want to call it. Such support should be a matter of local policy. Some compositors might fall back to a default state when everything else expires. But an equally valid model is to pass the expiration times on to watchers, and do _nothing_ at expiration time. The semanitic becomes something to the effect of "this is the last I heard, and it is probably stale, but make your own decision." My personal opinion is that a presence system has room for both hard and soft state, and that PUBLISH should be explicitly scoped as a mechanism for dynamic manipulation of soft state. Hard state manipulation is better left for the data manipulation requirements that have been discussed separately. Setting hard state data is not that different that establishing buddy list entries, or asserting watcher authorization policy. It doesn't _need_ the dynamicism of PUBLISH. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 4 15:45:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09928 for ; Tue, 4 Mar 2003 15:45:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Kubv12847 for simple-archive@odin.ietf.org; Tue, 4 Mar 2003 15:56:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Kub512844 for ; Tue, 4 Mar 2003 15:56:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09905 for ; Tue, 4 Mar 2003 15:45:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KuX512836; Tue, 4 Mar 2003 15:56:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Ktd512776 for ; Tue, 4 Mar 2003 15:55:39 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09894 for ; Tue, 4 Mar 2003 15:44:30 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h24KkUC07546; Tue, 4 Mar 2003 20:46:30 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 15:46:34 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EAE@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'hisham.khartabil@nokia.com'" , aki.niemi@nokia.com, Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Mar 2003 15:46:32 -0500 The problem here is this - do you expect the hard state of CLOSED for a particular tuple to be part of what the compositor sends in presence documents to watchers from now to the end of the world? If I am available at a conference room at a company I visit for an hour, and then publish a state of closed from that conference room, should that tuple (with a CLOSED status) be available to people who subscribe to my presence nine months from now? I don't think so. That's why this is not hard state. We want these things to go away, not persist forever. I definitely think a NOTIFY of CLOSED is soft state. When I publish a tuple with CLOSED, that immediately lets all current watchers know that I am no longer available at that contact address or what have you. It is important that this notification is sent. However, I think that CLOSED state should subsequently expire, just like any other state, for the sake of garbage collection, so that watchers who subsequently subscribe to my presence will not be overwhelmed with dozens of irrelevant and outdated tuples. In the case in which I have published no tuples recently, and all state for me has expired, I agree that a compositor might generate a 'dummy' tuple of CLOSED, and this is something like hard state (though whether it is per-user state or not is debatable, and perhaps even implementation-specific). I'm not sure PUBLISH is necessarily needed to manage this default response. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Thursday, February 27, 2003 3:38 PM > To: jon.peterson@neustar.biz; aki.niemi@nokia.com; > Markus.Isomaki@nokia.com; krisztian.kiss@nokia.com; simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > When you send a NOTIFY with status of CLOSED. Is that soft > state? does it expire? I guess not. So, we have some sort of > hard state. How else would I interpret a status of closed? > > Could it be like the following: > - whatever is published in a tuple is soft state. > - When the state published expires, we default to the hard > state (this could be open or closed). > > Are you Sean suggesting that this hard state is not set using > the PUBLISH message? > > Regards, > Hisham > > > -----Original Message----- > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Wednesday, February 26, 2003 9:55 PM > > To: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss > > Krisztian (NRC/Tampere); simple@ietf.org > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > > > The argument that there is some 'hard state' that exists in > > the absence of > > any publications (namely, the state or document expressing > > that the user is > > away) is in some ways attractive, yes. You are correct that a > > registrar > > doesn't supply null contact addresses or something when the > > user in question > > has no registration, but rather provides a specific failure > > response. Of > > course, the events framework has a different semantics - > > subscriptions are > > accepted when there is currently no published presence > > information for a > > user. Sending a failure response wouldn't be workable. > > > > There are, however, a couple of NOTIFY syntaxes that might > > communicate that > > there is no available presence information. One is that a > > NOTIFY might not > > contain any body. Another is that the presence agent or > > compositor invents a > > simple tuple that contains a status of CLOSED. The latter > > option may sound a > > lot like hard state, whereas the former does not. Whether or > > not the latter > > option is really 'state' though is debatable - almost an > > implementation > > question. Having a default response to queries in the absence > > of state does > > not, in and of itself, constitute state in my opinion. It > > does not require, > > for example, per-user tables in memory that have some > > specific values, as > > far as I can imagine how it would be implemented. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > > Sent: Wednesday, February 26, 2003 3:23 AM > > > To: jon.peterson@neustar.biz; Markus.Isomaki@nokia.com; > > > krisztian.kiss@nokia.com; simple@ietf.org > > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > > > > Hi, > > > > > > Few comments inline. BTW, a good set of requirements. > > > > > > Cheers, > > > Aki > > > > > [snip] > > > > > > > Of course, some sort of management interface could be > > > > defined so that users > > > > could do their own manual garbage collection. But that would > > > > be annoying. > > > > The REGISTER model, in which stale information automatically > > > > goes away for > > > > you, is much more suitable to real-time communications. > > > > > > Similarly, when all devices are off, or out of coverage, I > > > would like to see a presence document that says *something* > > > even though that something is unavailable at the moment. > > > > > > Just like when I get a 480 and not 404 back when the callee > > > is in an unregistered state. > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 4 16:00:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10264 for ; Tue, 4 Mar 2003 16:00:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24LB7n14200 for simple-archive@odin.ietf.org; Tue, 4 Mar 2003 16:11:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24LB7514197 for ; Tue, 4 Mar 2003 16:11:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10233 for ; Tue, 4 Mar 2003 15:59:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24LB4514189; Tue, 4 Mar 2003 16:11:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24LAo514164 for ; Tue, 4 Mar 2003 16:10:50 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10228 for ; Tue, 4 Mar 2003 15:59:41 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h24L1gC08025; Tue, 4 Mar 2003 21:01:43 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 16:01:46 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EAF@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Neil Deason'" , simple@ietf.org Subject: RE: [Simple] SIP and HTTP for presence publication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Mar 2003 16:01:45 -0500 Well, I'm really loath to re-open this discussion... we've already moved pretty far down one path, and it isn't clear that any other has genuine advantages over our current direction. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Monday, March 03, 2003 9:37 AM > To: simple@ietf.org > Subject: [Simple] SIP and HTTP for presence publication > > > draft-ietf-simple-publish-reqs-00 discusses the use of either HTTP or > SIP for presence state publication as if they have to be mutually > exclusive. > > As the draft points out HTTP provides a much better data transfer > mechanism than SIP. SIP has application layer routing > richness that HTTP > does not. So why not use SIP to initiate/modify/terminate a presence > state data transfer session that uses HTTP? > > Cheers, > Neil. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 4 17:11:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12182 for ; Tue, 4 Mar 2003 17:11:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24MMBr18960 for simple-archive@odin.ietf.org; Tue, 4 Mar 2003 17:22:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24MMB518957 for ; Tue, 4 Mar 2003 17:22:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12170 for ; Tue, 4 Mar 2003 17:11:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24MM7518949; Tue, 4 Mar 2003 17:22:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24MLA518917 for ; Tue, 4 Mar 2003 17:21:10 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12160 for ; Tue, 4 Mar 2003 17:09:58 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 4 Mar 2003 22:14:43 +0000 Received: from gbnewp1014m ([172.25.1.88]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Mar 2003 22:12:01 +0000 From: "Neil Deason" To: "Peterson, Jon" , Subject: RE: [Simple] SIP and HTTP for presence publication Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EAF@stntexch2.va.neustar.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 04 Mar 2003 22:12:01.0354 (UTC) FILETIME=[149E92A0:01C2E29B] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Mar 2003 14:12:00 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jon. > Well, I'm really loath to re-open this discussion... we've > already moved Can you provide a pointer to the discussion of SIP *and* HTTP for presence publication, not SIP *or* HTTP. That is all that is discussed in draft-ietf-simple-publish-reqs-00, maybe I missed something on the list? > pretty far down one path, and it isn't clear that any other > has genuine advantages over our current direction. Well I believe I can give advantages of SIP *and* HTTP. The reason that the requirements draft gives for using SIP alone is that it provides a solution that can leverage the power of SIP's application layer routing. Well so does using an INVITE to set up a HTTP session. Furthermore, using HTTP is the right thing for the job of data transfer, the draft itself acknowledges this. If you then accept the premise that the HTTP session could transport SOAP you are entering a realm of possibilities more sophisticated than a new SIP method offers. So combining HTTP and SIP could offer the best of both worlds and is in keeping with the IETF principal of designing modular protocols that work together. Contrast that with bad thing of adding methods to SIP that deviate from the protocols stated objective of initiating, modifying and terminating sessions. There are already well known examples of this in place, but we do not need to use that as precedent for solving every problem we come across in the communications space directly within SIP. The idea of adding a "POST" method to SIP is just as misguided as trying to add SIP-style routing features for HTTP proxies. Cheers, Neil. > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Sent: Monday, March 03, 2003 9:37 AM > > To: simple@ietf.org > > Subject: [Simple] SIP and HTTP for presence publication > > > > > > draft-ietf-simple-publish-reqs-00 discusses the use of > either HTTP or > > SIP for presence state publication as if they have to be mutually > > exclusive. > > > > As the draft points out HTTP provides a much better data transfer > > mechanism than SIP. SIP has application layer routing > > richness that HTTP > > does not. So why not use SIP to initiate/modify/terminate a presence > > state data transfer session that uses HTTP? > > > > Cheers, > > Neil. > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 4 18:11:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14728 for ; Tue, 4 Mar 2003 18:11:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24NMB222761 for simple-archive@odin.ietf.org; Tue, 4 Mar 2003 18:22:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NMB522758 for ; Tue, 4 Mar 2003 18:22:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14690 for ; Tue, 4 Mar 2003 18:10:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NM7522748; Tue, 4 Mar 2003 18:22:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NLN522722 for ; Tue, 4 Mar 2003 18:21:23 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14614 for ; Tue, 4 Mar 2003 18:10:09 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h24NCBC11738; Tue, 4 Mar 2003 23:12:11 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 18:12:15 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EB3@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Neil Deason'" , simple@ietf.org Subject: RE: [Simple] SIP and HTTP for presence publication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Mar 2003 18:12:14 -0500 It's not my place to stifle discussion on this mailing list, but I fear this is a very counterproductive line of inquiry. I am afraid that your note below provides no substantial evidence of advantages to your model, it merely hints that HTTP (and potentially SOAP) are superior to SIP as data tranfer protocol. So what properties would we derive from the use of these other protocols that we cannot garner from the PUBLISH method model, exactly? 'It uses SOAP' is not innately persuasive. A solution based on integrating HTTP sessions into SIP for publication does have limitations, in my opinion. For one thing, SIP PUBLISH requests would be routed on a per-transaction basis, which creates more dynamism than we would realize from the establishment of a persistent pair of HTTP endpoints through the session initiation model - in this second case the application-layer routing benefits only the session initiation messages, not the publications themselves. The draft does speak in some detail to why this dynamism is desirable. One material need for application-layer routing of publications is the standard NAT traversal issue - sending publications through the SIP proxy hierarchy makes this manageable, but there is no guarantee that any given HTTP client and server will be able to communicate with one another directly. This is especially troublesome, as the draft notes, when a PA is operated on an end-user device. I am moreover not inclined to think that presence information is 'session' data at all. I believe that the sorts of sessions that are established by SIP are real-time communications sessions, peer-to-peer - not sessions with intermediaries (i.e. compositors) for the purposes of relaying something like presence information. I believe this understanding of 'sessions' is amply substantiated by RFC3261; I would refer you to the definition of 'session' in Section 6. And also, I do not think that publication deviates from SIP's mission in the slightest. The Introduction of RFC3261 identifies two purposes for the SIP protocol - one being the session management function you describe below, the other being the discovery function (which in the context of RFC3261 refers to REGISTER and associated behavior). PUBLISH jibes well with that second aspect of SIP. Finally, I would note that PUBLISH has already become a WG item of SIMPLE. These are not the first versions of this draft to be produced, and we chairs believed that there was rough consensus to pursue this direction. You are of course welcome to submit your own counterproposal, and it will be given due attention in the WG, but this will not halt the progress of the PUBLISH draft. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Tuesday, March 04, 2003 2:12 PM > To: Peterson, Jon; simple@ietf.org > Subject: RE: [Simple] SIP and HTTP for presence publication > > > Hi Jon. > > > Well, I'm really loath to re-open this discussion... we've > > already moved > > Can you provide a pointer to the discussion of SIP *and* HTTP for > presence publication, not SIP *or* HTTP. That is all that is discussed > in draft-ietf-simple-publish-reqs-00, maybe I missed something on the > list? > > > pretty far down one path, and it isn't clear that any other > > has genuine advantages over our current direction. > > Well I believe I can give advantages of SIP *and* HTTP. The > reason that > the requirements draft gives for using SIP alone is that it provides a > solution that can leverage the power of SIP's application > layer routing. > Well so does using an INVITE to set up a HTTP session. Furthermore, > using HTTP is the right thing for the job of data transfer, the draft > itself acknowledges this. If you then accept the premise that the HTTP > session could transport SOAP you are entering a realm of possibilities > more sophisticated than a new SIP method offers. > > So combining HTTP and SIP could offer the best of both worlds > and is in > keeping with the IETF principal of designing modular > protocols that work > together. Contrast that with bad thing of adding methods to SIP that > deviate from the protocols stated objective of initiating, > modifying and > terminating sessions. There are already well known examples of this in > place, but we do not need to use that as precedent for solving every > problem we come across in the communications space directly > within SIP. > The idea of adding a "POST" method to SIP is just as > misguided as trying > to add SIP-style routing features for HTTP proxies. > > Cheers, > Neil. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > > Sent: Monday, March 03, 2003 9:37 AM > > > To: simple@ietf.org > > > Subject: [Simple] SIP and HTTP for presence publication > > > > > > > > > draft-ietf-simple-publish-reqs-00 discusses the use of > > either HTTP or > > > SIP for presence state publication as if they have to be mutually > > > exclusive. > > > > > > As the draft points out HTTP provides a much better data transfer > > > mechanism than SIP. SIP has application layer routing > > > richness that HTTP > > > does not. So why not use SIP to initiate/modify/terminate > a presence > > > state data transfer session that uses HTTP? > > > > > > Cheers, > > > Neil. > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 05:33:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24226 for ; Wed, 5 Mar 2003 05:33:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25AiKB12866 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 05:44:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25AiK512863 for ; Wed, 5 Mar 2003 05:44:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24220 for ; Wed, 5 Mar 2003 05:32:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25AiC512855; Wed, 5 Mar 2003 05:44:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Ahx512830 for ; Wed, 5 Mar 2003 05:43:59 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24213 for ; Wed, 5 Mar 2003 05:32:30 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h25AYUt24534; Wed, 5 Mar 2003 10:34:30 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FS3MTK6G; Wed, 5 Mar 2003 10:34:30 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 10:33:20 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'mikko.lonnfors@nokia.com'" , simple@ietf.org Subject: RE: [Simple] I-D ACTION:draft-lonnfors-simple-partial-notify-00.t xt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E302.A2A3A5CE" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Mar 2003 10:33:17 -0000 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_01C2E302.A2A3A5CE Content-Type: text/plain; charset="iso-8859-1" Mikko, All, The correct place to document such recommendations about SIGCOMP would be in some ROCH documentation, perhaps the SIGCOMP User Guide ? I notice that RFC3322 (Signalling Compression Requirements & Assumptions) already assumes that the signalling messages are ASCII encoded, so if this is not the case I think it's fairly urgent to get some discussion going. Before we go to ROCH, though, we need to make some decision on what kind of content we see being commonly included in SIP messages - i.e. what does SIGCOMP have to deal with in addition to SIP Headers and SDP ?? To my mind this is a discussion for SIPPING - does anyone object to moving this discussion there ? (Let's avoid creating a cross-posted thread if possible - they're always a nightmare). ...Mark > -----Original Message----- > From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com] > Sent: 04 March 2003 10:03 > To: Watson, Mark [MOP:EP10:EXCH]; simple@ietf.org > Subject: RE: [Simple] I-D > ACTION:draft-lonnfors-simple-partial-notify-00.txt > > > Hi mark, > > Inline inside : > > > All, > I am not convinced by the discussion on SIGCOMP which has > been introduced into this draft (Section 1.1). > Firstly, is this even the correct place to describe these issues ?? > > > Yes, you are right. To move discussion forward we needed to > place text somewhere and in this case only place we could > place it was the partial notification draft. > > > If we really expect to see large binary content in SIP > messages, then we should document the impacts for SIGCOMP > somewhere more general - not buried in a presence partial > notifications discussion. > > > Yes > > > If we do not expect such content, we should document that > fact somewhere more general too. We need to make a decision > one way or the other because it has important implications > for the design of SIGCOMP compressors. > > > This is probably true. > > > Secondly, two of the solutions referred to involve the > SIGCOMP layer having knowledge of the content type, which is > a major architectural change. Presently, the SIGCOMP layer > does not parse SIP, MIME etc. > > > We have been talking about this issue with SIGCOMP author Z. > Liu (as at least I not an expert in this are) and these were > mentioned as possible solutions for this problem. I am also > not convinced that these two solutions are the best ones and > if other people feel same I am quite happy to drop them. > > > Thirdly, the last solution mentioned involves leaving > 'binary' content uncompressed, but this does not necessarily > mean that this content will not mess up the dynamic > dictionary. The compression scheme would need to detect > 'uncompressible' parts of the message and leave these out of > the dictionary. > > > As far as I know this should be quite easy thing to > accomplish for a SIGCOMP implementation. Of course it should > be specified (recommended) somewhere what is appropriate > threshold value for data which should be considered 'uncompressible'. > > > So, if we expect binary content in SIP, we should document > the impacts in SIGCOMP somewhere in the sip/sipping WGs. We > should decide whether we expect SIGCOMP to cope with such > binary content in an efficient way (i.e. if we think the same > content will be sent multiple times) or whether we are happy > for SIGCOMP to leave such content uncompressed (i.e. if we > think the same content will generally only be sent once). > > Finally, I think we concluded in the last discussion on this > that it was not appropriate to include in-line binary content > in the presence document itself due to encoding issues - > there is still some reference to this in the draft. Large > binary content would need to referenced from the presence > document, and we left it open whether this reference could be > to other MIME parts within the same SIP message. > > > Yes, this is our mistake. I also agree that large binary data > should not be in-line with other presence data. This will be > fixed in next version > > > Thanks for comments > - Mikko > > Regards, > Mark > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 24 February 2003 11:45 > > Cc: simple@ietf.org > > Subject: [Simple] I-D > > ACTION:draft-lonnfors-simple-partial-notify-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Partial Notification of Presence > Information > > Author(s) : J. Costa-Requena, E. Leppanen et al. > > Filename : draft-lonnfors-simple-partial-notify-00.txt > > Pages : 24 > > Date : 2003-2-21 > > > > A Presence service implemented using SIMPLE has some > constraints for > > delivering presence information to devices with low data processing > > capabilities, small display, and limited battery power. Other > > limitations can be caused by the interface between the terminal and > > the network, i.e. over radio links with high latency and low > > bandwidth. This memo presents a solution that aids in reducing the > > impact of those constrains and increasing efficiency, by > introducing > > a new MIME-type æpartial notificationsÆ and a Require header > > extension æpartial-notificationÆ. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part > > ial-notify-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-lonnfors-simple-partial-notify-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-lonnfors-simple-partial-notify-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_001_01C2E302.A2A3A5CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] I-D = ACTION:draft-lonnfors-simple-partial-notify-00.txt

Mikko, All,

The correct place to document such recommendations = about SIGCOMP would be in some ROCH documentation, perhaps the SIGCOMP = User Guide ? I notice that RFC3322 (Signalling Compression Requirements = & Assumptions) already assumes that the signalling messages are = ASCII encoded, so if this is not the case I think it's fairly urgent to = get some discussion going.

Before we go to ROCH, though, we need to make some = decision on what kind of content we see being commonly included in SIP = messages - i.e. what does SIGCOMP have to deal with in addition to SIP = Headers and SDP ??

To my mind this is a discussion for SIPPING - does = anyone object to moving this discussion there ? (Let's avoid creating a = cross-posted thread if possible - they're always a = nightmare).

...Mark



> -----Original Message-----
> From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com= ]
> Sent: 04 March 2003 10:03
> To: Watson, Mark [MOP:EP10:EXCH]; = simple@ietf.org
> Subject: RE: [Simple] I-D
> = ACTION:draft-lonnfors-simple-partial-notify-00.txt
>
>
> Hi mark,
>
> Inline inside <ML>:
>
>
> All,
> I am not convinced by the discussion on SIGCOMP = which has
> been introduced into this draft (Section 1.1). =
> Firstly, is this even the correct place to = describe these issues ??
>
> <ML>
> Yes, you are right. To move discussion forward = we needed to
> place text somewhere and in this case only = place we could
> place it was the partial notification = draft.
> </ML>
>
>  If we really expect to see large binary = content in SIP
> messages, then we should document the impacts = for SIGCOMP
> somewhere more general - not buried in a = presence partial
> notifications discussion.
>
> <ML>
> Yes
> </ML>
>
> If we do not expect such content, we should = document that
> fact somewhere more general too. We need to = make a decision
> one way or the other because it has important = implications
> for the design of SIGCOMP compressors.
>
> <ML>
> This is probably true.
> </ML>
>
> Secondly, two of the solutions referred to = involve the
> SIGCOMP layer having knowledge of the content = type, which is
> a major architectural change. Presently, the = SIGCOMP layer
> does not parse SIP, MIME etc.
>
> <ML>
> We have been talking about this issue with = SIGCOMP author Z.
> Liu (as at least I not an expert in this are) = and these were
> mentioned as possible solutions for this = problem. I am also
> not convinced that these two solutions are the = best ones and
> if other people feel same I am quite happy to = drop them.
> </ML>
>
> Thirdly, the last solution mentioned involves = leaving
> 'binary' content uncompressed, but this does = not necessarily
> mean that this content will not mess up the = dynamic
> dictionary. The compression scheme would need = to detect
> 'uncompressible' parts of the message and leave = these out of
> the dictionary.
>
> <ML>
> As far as I know this should be quite easy = thing to
> accomplish for a SIGCOMP implementation. Of = course it should
> be specified (recommended) somewhere what is = appropriate
> threshold value for data which should be = considered 'uncompressible'.
> </ML>
>
> So, if we expect binary content in SIP, we = should document
> the impacts in SIGCOMP somewhere in the = sip/sipping WGs. We
> should decide whether we expect SIGCOMP to cope = with such
> binary content in an efficient way (i.e. if we = think the same
> content will be sent multiple times) or whether = we are happy
> for SIGCOMP to leave such content uncompressed = (i.e. if we
> think the same content will generally only be = sent once).
>
> Finally, I think we concluded in the last = discussion on this
> that it was not appropriate to include in-line = binary content
> in the presence document itself due to encoding = issues -
> there is still some reference to this in the = draft. Large
> binary content would need to referenced from = the presence
> document, and we left it open whether this = reference could be
> to other MIME parts within the same SIP = message.
>
> <ML>
> Yes, this is our mistake. I also agree that = large binary data
> should not be in-line with other presence data. = This will be
> fixed in next version
> </ML>
>
> Thanks for comments
> - Mikko
>
> Regards,
> Mark
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> > Sent: 24 February 2003 11:45
> > Cc: simple@ietf.org
> > Subject: [Simple] I-D
> > ACTION:draft-lonnfors-simple-partial-notify= -00.txt
> >
> >
> > A New Internet-Draft is available from the = on-line
> > Internet-Drafts directories.
> >
> >
> >       = Title           : = Partial Notification of Presence
> Information
> >       = Author(s)       : J. Costa-Requena, E. = Leppanen et al.
> >       = Filename        : = draft-lonnfors-simple-partial-notify-00.txt
> >       = Pages           : 24 =
> >       = Date            = : 2003-2-21
> >       =
> > A Presence service implemented using = SIMPLE has some
> constraints for
> > delivering presence information to devices = with low data processing
> > capabilities, small display, and limited = battery power. Other
> > limitations can be caused by the interface = between the terminal and
> > the network, i.e. over radio links with = high latency and low
> > bandwidth. This memo presents a solution = that aids in reducing the
> > impact of those constrains and increasing = efficiency, by
> introducing
> > a new MIME-type =E6partial = notifications=C6 and a Require header
> > extension =E6partial-notification=C6. =
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lonnfors-sim= ple-part
> > ial-notify-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-lonnfors-simple-partial-notify-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-lonnfors-simple-partial-notify-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.
> = >           &n= bsp;  
> = >           &n= bsp;  
> > Below is the data which will enable a MIME = compliant mail reader
> > implementation to automatically retrieve = the ASCII version of the
> > Internet-Draft.
> >
>

------_=_NextPart_001_01C2E302.A2A3A5CE-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 06:01:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24874 for ; Wed, 5 Mar 2003 06:01:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BCEv14866 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 06:12:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BCE514863 for ; Wed, 5 Mar 2003 06:12:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24842 for ; Wed, 5 Mar 2003 06:00:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BC5514853; Wed, 5 Mar 2003 06:12:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BBp514825 for ; Wed, 5 Mar 2003 06:11:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24837 for ; Wed, 5 Mar 2003 06:00:23 -0500 (EST) 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.5/Switch-2.2.0) with ESMTP id h25B5jF25711 for ; Wed, 5 Mar 2003 13:05:45 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 13:02:21 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 13:02:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945196@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLieXDJwqZy1C+kQ0iV6lCA4M/HhAAhg82w To: Cc: , , , , X-OriginalArrivalTime: 05 Mar 2003 11:02:21.0545 (UTC) FILETIME=[B2000590:01C2E306] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25BBp514826 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Mar 2003 13:02:20 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Some comments inline. > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 04 March, 2003 20:11 > To: Niemi Aki (NMP/Helsinki) > Cc: Sean Olson; Jon Peterson; Isomaki Markus (NRC/Helsinki); Kiss > Krisztian (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > [snip] > > > Sorry for jumping late into the conversation, but the problem is, I > think, that this approach _assumes_ the compositor supports > a concept of > hard state, or default state, or whatever you want to call it. Such > support should be a matter of local policy. Some compositors > might fall > back to a default state when everything else expires. But an equally > valid model is to pass the expiration times on to watchers, and do > _nothing_ at expiration time. The semanitic becomes something to the > effect of "this is the last I heard, and it is probably > stale, but make > your own decision." Yes, I'm assuming that the composer supports the default state, or fallback status concept. I'm also stating a requirement, that the PUBLISH mechanism should support setting the default status - I'm not saying all composers must support this concept, or support setting the default status with PUBLISH. My point is that the default status is not that different from "live" status, so that we would need to defer the problem to another interface or work item. I would even argue, that what you say above also makes assumptions about the system. It assumes that watchers understand something about expiration of presence statuses, which they don't by default. Expires of a PUBLISH can't be mapped to the subscriptions of watchers, and a timestamp in a presence document says nothing about expiration. I'm also a little worried about the duality of Expires in PUBLISH. On one side there's a need to do garbage collection efficiently, and on the other hand, there's a need to publish event state that carries an explicit lifetime. The former fits my interpretation of Expires, but the latter is unclear to me - seems like a new requirement for presence info itself. Sort of like a "Back in 15 minutes" note in a machine-readable form. > My personal opinion is that a presence system has room for > both hard and > soft state, and that PUBLISH should be explicitly scoped as > a mechanism > for dynamic manipulation of soft state. Hard state manipulation is > better left for the data manipulation requirements that have been > discussed separately. Setting hard state data is not that > different that > establishing buddy list entries, or asserting watcher authorization > policy. It doesn't _need_ the dynamicism of PUBLISH. Publishing this hard state may be as simple as publishing a presentity element. I don't think that being able to publish a that will survive my turning off my PUA devices for a few hours is that unreasonable with PUBLISH. It would seem that the same benefits for using PUBLISH in soft state updates apply here as well. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 06:35:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26869 for ; Wed, 5 Mar 2003 06:35:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BktQ17644 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 06:46:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bkt517641 for ; Wed, 5 Mar 2003 06:46:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26847 for ; Wed, 5 Mar 2003 06:35:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bkp517631; Wed, 5 Mar 2003 06:46:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BfF516948 for ; Wed, 5 Mar 2003 06:41:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25812; Wed, 5 Mar 2003 06:29:46 -0500 (EST) Message-Id: <200303051129.GAA25812@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-niemi-simple-im-wireless-reqs-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Mar 2003 06:29:46 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Instant Messaging in 3GPP Wireless Systems Author(s) : A. Niemi Filename : draft-niemi-simple-im-wireless-reqs-01.txt Pages : 12 Date : 2003-3-4 This document lists the requirements specific to 3GPP wireless Instant Messaging systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-01.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-im-wireless-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-4174029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-simple-im-wireless-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174029.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 07:30:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28570 for ; Wed, 5 Mar 2003 07:30:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25CfBT22241 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 07:41:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25CfB522238 for ; Wed, 5 Mar 2003 07:41:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28565 for ; Wed, 5 Mar 2003 07:29:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Cf6522230; Wed, 5 Mar 2003 07:41:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Ceu522211 for ; Wed, 5 Mar 2003 07:40:56 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28557 for ; Wed, 5 Mar 2003 07:29:25 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25CYlF13177 for ; Wed, 5 Mar 2003 14:34:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 14:31:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 14:31:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7334@esebe019.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLiejYxlaSu0U6wS8eWKBSZxfINLwAmMLfQ To: , Cc: , , , , X-OriginalArrivalTime: 05 Mar 2003 12:31:27.0557 (UTC) FILETIME=[2478B750:01C2E313] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25Ceu522212 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Mar 2003 14:31:27 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, March 04, 2003 8:11 PM > To: Niemi Aki (NMP/Helsinki) > Cc: Sean Olson; Jon Peterson; Isomaki Markus (NRC/Helsinki); Kiss > Krisztian (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > On Thu, 2003-02-27 at 11:15, aki.niemi@nokia.com wrote: > > Hi, > > > > Maybe I'm missing something here, but as I see it, in order > to do garbage collection, the composer needs to assign PUAs > to refresh their publications in certain intervals. The > shorter this refresh period is, the more efficient the > garbage collection is; the longer the period, the more > garbage state will be around. > > > > Now I agree that a large Expires would seem to accomplish > the hard-state publication, but to what value do we draw the > line? When will the composer simply accept a long lasting > publication, and not reduce the Expires value to its local > default to enable efficient garbage collection? > > > > I think the problem is that the Expires has dual meening in > this case. It implies the lifetime of the presence info, as > well as the validity period of the publication. Unless we > standardize a value for Expires, after which it becomes > solely the lifetime of the presence info (to indicate that > the state is not to be garbage collected), different systems > will behave differently. > > > > What if we define this explicitly, say Expires=0, or > Expires=4294967295 means this is meant to be stored "indefinitely"? > > > > > Sorry for jumping late into the conversation, but the problem is, I > think, that this approach _assumes_ the compositor supports a > concept of > hard state, or default state, or whatever you want to call it. Such > support should be a matter of local policy. Some compositors > might fall > back to a default state when everything else expires. But an equally > valid model is to pass the expiration times on to watchers, and do > _nothing_ at expiration time. The semanitic becomes something to the > effect of "this is the last I heard, and it is probably > stale, but make > your own decision." Never the less, there should be a requirement for a solution to enable this hard state publication. The solution is a different issue. /Hisham > > My personal opinion is that a presence system has room for > both hard and > soft state, and that PUBLISH should be explicitly scoped as a > mechanism > for dynamic manipulation of soft state. Hard state manipulation is > better left for the data manipulation requirements that have been > discussed separately. Setting hard state data is not that > different that > establishing buddy list entries, or asserting watcher authorization > policy. It doesn't _need_ the dynamicism of PUBLISH. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 10:28:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05012 for ; Wed, 5 Mar 2003 10:28:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25FdFK04080 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 10:39:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FdF504077 for ; Wed, 5 Mar 2003 10:39:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04990 for ; Wed, 5 Mar 2003 10:27:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FdA504057; Wed, 5 Mar 2003 10:39:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FcI503973 for ; Wed, 5 Mar 2003 10:38:18 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04878 for ; Wed, 5 Mar 2003 10:26:45 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA29650; Wed, 5 Mar 2003 16:28:44 +0100 (MET) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA27950; Wed, 5 Mar 2003 16:28:11 +0100 (MET) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 16:28:46 +0100 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E7510E@mchh161e.mch4.siemens.de> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Peterson, Jon'" Cc: "'Sean Olson'" , simple@ietf.org Subject: AW: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt 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 www1.ietf.org id h25FcI503974 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Mar 2003 16:28:41 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Some comments : 1) Table 1 : A new row should be added under the "Expires" : Header Field where proxy PUBLISH ---------------------------------------------------------- Expires 2xx m Section 3.3 states that "The final response to the PUBLISH request MUST carry the expiration value chosen by the compositor in an Expires: header". 2) The PUBLISH request in the example has a To tag. This implies that it is sent within a dialog, as RFC 3261 states that "A request outside of a dialog MUST NOT contain a To tag". However, session 3 states that the PUBLISH request is allowed to fork, which would mean that it is outside of a dialog. 4) In the example, the Contact header in the 200 OK to the SUBSCRIBE should not be , but 5) In the example, the NOTIFY message Request-URI should not be sip:presentity@domain.com, but sip:watcher@domain.com. The same error is in the response to the NOTIFY. 6) The mandatory header Max-Forwards is missing in all requests in the example. Ya-Ching Tan | -----Ursprüngliche Nachricht----- | Von: Peterson, Jon [mailto:jon.peterson@neustar.biz] | Gesendet: 27 February 2003 21:40 | An: 'Drage, Keith (Keith)'; simple@ietf.org | Betreff: RE: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt | | | Yes, um, that would be my fault. I thought I had removed | instances of Facet | and Stream from the document entirely. The examples are in error. | | Jon Peterson | NeuStar, Inc. | _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 13:13:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18610 for ; Wed, 5 Mar 2003 13:13:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25IOQg04488 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 13:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IOQO04485 for ; Wed, 5 Mar 2003 13:24:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18375 for ; Wed, 5 Mar 2003 13:13:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IOLO04439; Wed, 5 Mar 2003 13:24:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25INoO04411 for ; Wed, 5 Mar 2003 13:23:50 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18324 for ; Wed, 5 Mar 2003 13:12:39 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 5 Mar 2003 18:17:25 +0000 Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Wed, 5 Mar 2003 18:14:43 +0000 From: "Neil Deason" To: "Peterson, Jon" , Subject: RE: [Simple] SIP and HTTP for presence publication Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EB3@stntexch2.va.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 05 Mar 2003 18:14:44.0140 (UTC) FILETIME=[18FDDEC0:01C2E343] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Mar 2003 10:14:38 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > I am afraid that your note below provides no substantial evidence of > advantages to your model, it merely hints that HTTP (and > potentially SOAP) > are superior to SIP as data tranfer protocol. So what > properties would we > derive from the use of these other protocols that we cannot > garner from the > PUBLISH method model, exactly? 'It uses SOAP' is not innately > persuasive. Potential for SOAP usage is not my major point - merely a note of an observation made in the reqs draft itself. What I am saying is that if SIP application routing is required in presence data publication then utilise that feature without adding complexity and baggage to SIP itself. SIP is not a data transfer protocol. I believe that is widely accepted. There are good technical reasons for this from the fact that UDP can be used as transport providing concerns over congestion control and message fragmentation. There are also fundamental issues here: Protocols that do not have a bounded scope become overly complex and tend to fail. Hence the IETF approach to have modular protocols that can work together. SIP is not meant as replacement for HTTP, so don't add a POST method to SIP if you can just use POST in the first place. It is not that you cannot do this within SIP through PUBLISH, but that you should not. > A solution based on integrating HTTP sessions into SIP for > publication does > have limitations, in my opinion. For one thing, SIP PUBLISH > requests would > be routed on a per-transaction basis, which creates more > dynamism than we > would realize from the establishment of a persistent pair of > HTTP endpoints > through the session initiation model - in this second case the > application-layer routing benefits only the session > initiation messages, not > the publications themselves. The draft does speak in some > detail to why this > dynamism is desirable. If you mean Section 1.2.2 I don't believe it makes case for such dynamism. There is nothing there that shows the overhead of managing mobility a the session level through SIP would be too great and that you need to use a series of discrete SIP request/response transactions instead. How much do you expect the compositors to move around? The example given is a compositor running on a device using dynamic IP addresses obtained from DHCP. A PUBLISH gets routed according to a reREGISTERed address when the IP address changes, just as an INVITE would. This is the inherent mobility support for SIP. If you don't believe in that it is time for RTP/INFO for every SIP phone using DHCP ;) What section 1.2.2 actually makes a case for is the discovery capability of SIP. That is already there and you do not need to reinvent parts of HTTP within SIP to use it. > One material need for > application-layer routing of > publications is the standard NAT traversal issue - sending > publications > through the SIP proxy hierarchy makes this manageable, but there is no > guarantee that any given HTTP client and server will be able > to communicate > with one another directly. This is especially troublesome, as > the draft > notes, when a PA is operated on an end-user device. I think it a very reasonable assumption that the end devices will support HTTP clients that can contact servers, even through FWs/NAT. > I am moreover not inclined to think that presence information > is 'session' > data at all. I believe that the sorts of sessions that are > established by > SIP are real-time communications sessions, peer-to-peer - not > sessions with > intermediaries (i.e. compositors) for the purposes of > relaying something > like presence information. I believe this understanding of > 'sessions' is > amply substantiated by RFC3261; I would refer you to the definition of > 'session' in Section 6. Sure it takes the definition of session from SDP which refers to data streams between senders and receivers. If you look at RFC 2327 you will see that the supported media types defined there for sessions are "audio", "video", "application", "data" and "control". This usage being a valid example of a data session. But I think we digress. > And also, I do not think that publication deviates from SIP's > mission in the > slightest. The Introduction of RFC3261 identifies two > purposes for the SIP > protocol - one being the session management function you > describe below, the > other being the discovery function (which in the context of > RFC3261 refers > to REGISTER and associated behavior). PUBLISH jibes well with > that second > aspect of SIP. Disagree - REGISTER is about enabling the discovery mechanism. PUBLISH it is about data transfer leveraging that discovery mechanism. You can still leverage the discovery part for data transfer without needing to add yet more complexity to SIP. > Finally, I would note that PUBLISH has already become a WG > item of SIMPLE. > These are not the first versions of this draft to be > produced, and we chairs > believed that there was rough consensus to pursue this > direction. You are of > course welcome to submit your own counterproposal, and it > will be given due > attention in the WG, but this will not halt the progress of > the PUBLISH > draft. What I would actually like to see is a cleaner requirements draft. The current iteration has hangovers from being split out from the PUBLISH draft. A requirements draft should not have a conclusion as to what the solution is. Drafts proposing solutions should state how they meet requirements. It should not be a requirement for a solution to extend define a new SIP method. The actual underlying requirement seems to be for a compositor discovery mechanism. The protocol analysis of SIP and HTTP in the requirements is incomplete as the option of combining SIP and HTTP is not discussed. Finally imho the requirements draft fails to justify the conclusion that adding SIP style application logic to HTTP is wrong, but adding POST like data transfer to SIP is right. Cheers, Neil. > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Sent: Tuesday, March 04, 2003 2:12 PM > > To: Peterson, Jon; simple@ietf.org > > Subject: RE: [Simple] SIP and HTTP for presence publication > > > > > > Hi Jon. > > > > > Well, I'm really loath to re-open this discussion... we've > > > already moved > > > > Can you provide a pointer to the discussion of SIP *and* HTTP for > > presence publication, not SIP *or* HTTP. That is all that > is discussed > > in draft-ietf-simple-publish-reqs-00, maybe I missed > something on the > > list? > > > > > pretty far down one path, and it isn't clear that any other > > > has genuine advantages over our current direction. > > > > Well I believe I can give advantages of SIP *and* HTTP. The > > reason that > > the requirements draft gives for using SIP alone is that it > provides a > > solution that can leverage the power of SIP's application > > layer routing. > > Well so does using an INVITE to set up a HTTP session. Furthermore, > > using HTTP is the right thing for the job of data transfer, > the draft > > itself acknowledges this. If you then accept the premise > that the HTTP > > session could transport SOAP you are entering a realm of > possibilities > > more sophisticated than a new SIP method offers. > > > > So combining HTTP and SIP could offer the best of both worlds > > and is in > > keeping with the IETF principal of designing modular > > protocols that work > > together. Contrast that with bad thing of adding methods to SIP that > > deviate from the protocols stated objective of initiating, > > modifying and > > terminating sessions. There are already well known examples > of this in > > place, but we do not need to use that as precedent for solving every > > problem we come across in the communications space directly > > within SIP. > > The idea of adding a "POST" method to SIP is just as > > misguided as trying > > to add SIP-style routing features for HTTP proxies. > > > > Cheers, > > Neil. > > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > > > Sent: Monday, March 03, 2003 9:37 AM > > > > To: simple@ietf.org > > > > Subject: [Simple] SIP and HTTP for presence publication > > > > > > > > > > > > draft-ietf-simple-publish-reqs-00 discusses the use of > > > either HTTP or > > > > SIP for presence state publication as if they have to > be mutually > > > > exclusive. > > > > > > > > As the draft points out HTTP provides a much better > data transfer > > > > mechanism than SIP. SIP has application layer routing > > > > richness that HTTP > > > > does not. So why not use SIP to initiate/modify/terminate > > a presence > > > > state data transfer session that uses HTTP? > > > > > > > > Cheers, > > > > Neil. > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 17:34:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03262 for ; Wed, 5 Mar 2003 17:34:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25MjKK30348 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 17:45:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MjKO30345 for ; Wed, 5 Mar 2003 17:45:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03242 for ; Wed, 5 Mar 2003 17:34:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MjFO30335; Wed, 5 Mar 2003 17:45:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MiwO30284 for ; Wed, 5 Mar 2003 17:44:58 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03236 for ; Wed, 5 Mar 2003 17:33:43 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h25MZjC03305; Wed, 5 Mar 2003 22:35:45 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 17:35:50 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EC1@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Neil Deason'" , simple@ietf.org Subject: RE: [Simple] SIP and HTTP for presence publication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Mar 2003 17:35:48 -0500 Some notes inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Wednesday, March 05, 2003 10:15 AM > To: Peterson, Jon; simple@ietf.org > Subject: RE: [Simple] SIP and HTTP for presence publication > > [snip] > > Potential for SOAP usage is not my major point - merely a note of an > observation made in the reqs draft itself. What I am saying is that if > SIP application routing is required in presence data publication then > utilize that feature without adding complexity and baggage to SIP > itself. SIP is not a data transfer protocol. I believe that is widely > accepted. There are good technical reasons for this from the fact that > UDP can be used as transport providing concerns over congestion control > and message fragmentation. There are also fundamental issues here: > Protocols that do not have a bounded scope become overly complex and > tend to fail. Hence the IETF approach to have modular protocols that can > work together. SIP is not meant as replacement for HTTP, so don't add a > POST method to SIP if you can just use POST in the first place. It is > not that you cannot do this within SIP through PUBLISH, but that you > should not. > I'm afraid I disagree with much of this. SIP is widely acknowledged to be reasonable protocol for transporting SDP. What makes PIDF, say, so different from SDP? There's no question in my mind that SIP is not a media transfer protocol, and that SIP should not be used to carry real-time communications data itself, sure. But I don't see why this extends to PIDF. Why REGISTER is not also like POST is obscure to me; I think all of this clearly falls within existing SIP boundaries, and is not symptomatic of unnecessary bloat. If your concern is that PIDF would, say, be radically larger than SDP, then look to requirement 9, which is essentially a requirement for content indirection. In fact, content indirection may give you many of the virtues of combining SIP and HTTP without some of the vices I see in the sessions-of-HTTP approach. Would that be sufficient for you? > > If you mean Section 1.2.2 I don't believe it makes case for such > dynamism. There is nothing there that shows the overhead of managing > mobility a the session level through SIP would be too great and that you > need to use a series of discrete SIP request/response transactions > instead. How much do you expect the compositors to move around? The > example given is a compositor running on a device using dynamic IP > addresses obtained from DHCP. A PUBLISH gets routed according to a > reREGISTERed address when the IP address changes, just as an INVITE > would. Right, the difference is that you send an INVITE to establish a persistent relationship over which successive publications of presence information will be sent. PUBLISH, on the other hand, would be routed on a per-transaction basis. In order for the INVITE-based approach to be routed on a per-publication basis, you would be setting up and terminating a session every time you published, which seems very cumbersome to me from a messaging perspective. Consider as well that some have expressed a desire for PUBLISH to fork. The implications for that to the session-based model should be obvious. > > I think it a very reasonable assumption that the end devices will > support HTTP clients that can contact servers, even through FWs/NAT. > Possibly. It would be nice for the purposes of content indirection. > > Disagree - REGISTER is about enabling the discovery mechanism. PUBLISH > it is about data transfer leveraging that discovery mechanism. You can > still leverage the discovery part for data transfer without needing to > add yet more complexity to SIP. > Presence publication is not about enabling the discovery mechanism? I find that a bit difficult to accept. Presence is an incremental step forward in the management of discovery above REGISTER, and presence publication is in many ways a generalization of registration. You use presence information to decide which communications interfaces associated with a user you will attempt to contact, based on their disposition. > > What I would actually like to see is a cleaner requirements draft. The > current iteration has hangovers from being split out from the PUBLISH > draft. A requirements draft should not have a conclusion as to what the > solution is. Drafts proposing solutions should state how they meet > requirements. It should not be a requirement for a solution to extend > define a new SIP method. The actual underlying requirement seems to be > for a compositor discovery mechanism. The protocol analysis of SIP and > HTTP in the requirements is incomplete as the option of combining SIP > and HTTP is not discussed. Finally imho the requirements draft fails to > justify the conclusion that adding SIP style application logic to HTTP > is wrong, but adding POST like data transfer to SIP is right. > The purposes of supplying that text about SIP v. HTTP was to preempt the religious arguments about this that previously prevented us from making progress. In the publication design team, we ultimately found that there were too few criteria for a strong case to be made for either option. Eventually, this becomes a matter of choosing vanilla or chocolate. Hopefully content indirection can blend the two flavors sufficiently. > Cheers, > Neil. > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > > Sent: Tuesday, March 04, 2003 2:12 PM > > > To: Peterson, Jon; simple@ietf.org > > > Subject: RE: [Simple] SIP and HTTP for presence publication > > > > > > > > > Hi Jon. > > > > > > > Well, I'm really loath to re-open this discussion... we've > > > > already moved > > > > > > Can you provide a pointer to the discussion of SIP *and* HTTP for > > > presence publication, not SIP *or* HTTP. That is all that > > is discussed > > > in draft-ietf-simple-publish-reqs-00, maybe I missed > > something on the > > > list? > > > > > > > pretty far down one path, and it isn't clear that any other > > > > has genuine advantages over our current direction. > > > > > > Well I believe I can give advantages of SIP *and* HTTP. The > > > reason that > > > the requirements draft gives for using SIP alone is that it > > provides a > > > solution that can leverage the power of SIP's application > > > layer routing. > > > Well so does using an INVITE to set up a HTTP session. > Furthermore, > > > using HTTP is the right thing for the job of data transfer, > > the draft > > > itself acknowledges this. If you then accept the premise > > that the HTTP > > > session could transport SOAP you are entering a realm of > > possibilities > > > more sophisticated than a new SIP method offers. > > > > > > So combining HTTP and SIP could offer the best of both worlds > > > and is in > > > keeping with the IETF principal of designing modular > > > protocols that work > > > together. Contrast that with bad thing of adding methods > to SIP that > > > deviate from the protocols stated objective of initiating, > > > modifying and > > > terminating sessions. There are already well known examples > > of this in > > > place, but we do not need to use that as precedent for > solving every > > > problem we come across in the communications space directly > > > within SIP. > > > The idea of adding a "POST" method to SIP is just as > > > misguided as trying > > > to add SIP-style routing features for HTTP proxies. > > > > > > Cheers, > > > Neil. > > > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > > > > Sent: Monday, March 03, 2003 9:37 AM > > > > > To: simple@ietf.org > > > > > Subject: [Simple] SIP and HTTP for presence publication > > > > > > > > > > > > > > > draft-ietf-simple-publish-reqs-00 discusses the use of > > > > either HTTP or > > > > > SIP for presence state publication as if they have to > > be mutually > > > > > exclusive. > > > > > > > > > > As the draft points out HTTP provides a much better > > data transfer > > > > > mechanism than SIP. SIP has application layer routing > > > > > richness that HTTP > > > > > does not. So why not use SIP to initiate/modify/terminate > > > a presence > > > > > state data transfer session that uses HTTP? > > > > > > > > > > Cheers, > > > > > Neil. > > > > > > > > > > _______________________________________________ > > > > > Simple mailing list > > > > > Simple@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 17:47:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03838 for ; Wed, 5 Mar 2003 17:47:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Mw7F31020 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 17:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Mw7O31017 for ; Wed, 5 Mar 2003 17:58:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03808 for ; Wed, 5 Mar 2003 17:46:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Mw3O31009; Wed, 5 Mar 2003 17:58:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MvUO30963 for ; Wed, 5 Mar 2003 17:57:30 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03780 for ; Wed, 5 Mar 2003 17:46:15 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h25Mm0C03602; Wed, 5 Mar 2003 22:48:01 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 17:48:06 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EC2@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'aki.niemi@nokia.com'" , bcampbell@dynamicsoft.com Cc: seancolson@yahoo.com, Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Mar 2003 17:48:05 -0500 A couple notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Wednesday, March 05, 2003 3:02 AM > To: bcampbell@dynamicsoft.com > Cc: seancolson@yahoo.com; jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; krisztian.kiss@nokia.com; simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > [snip] > > Yes, I'm assuming that the composer supports the default > state, or fallback status concept. I'm also stating a > requirement, that the PUBLISH mechanism should support > setting the default status - I'm not saying all composers > must support this concept, or support setting the default > status with PUBLISH. My point is that the default status is > not that different from "live" status, so that we would need > to defer the problem to another interface or work item. > I think it is reasonable for there to be a requirement for compositors to have some default behavior for notifications in the absence of current presence information about a user. We should include that; in fact, an earlier version circulated to the pub design team had text along those lines, but we couldn't arrive at the right wording for it. I think we're in a better position to do so now, after some discussion. The issue of how different it is from "live" status though is a bit more difficult. A PIDF document can contain 0 tuples. A compositor might consider this to be the 'base' document it holds for every user. Sending a tuple-less PIDF document to watchers definitely, in my mind, communicates that no presence information is currently available for the presentity. I'm not sure why this default document would need to be modified by users. > I would even argue, that what you say above also makes > assumptions about the system. It assumes that watchers > understand something about expiration of presence statuses, > which they don't by default. Expires of a PUBLISH can't be > mapped to the subscriptions of watchers, and a timestamp in a > presence document says nothing about expiration. > Agreed that it is probably not advisable to reuse Expires to relay publication durations to end users. Henning's RPIDS model has its own way of expressing the duration of an individual tuple, which is ultimately a better approach, I think. [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 5 19:26:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07925 for ; Wed, 5 Mar 2003 19:26:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h260bAB06003 for simple-archive@odin.ietf.org; Wed, 5 Mar 2003 19:37:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h260bAO05993 for ; Wed, 5 Mar 2003 19:37:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07915 for ; Wed, 5 Mar 2003 19:25:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h260b5O05835; Wed, 5 Mar 2003 19:37:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h260aWO05617 for ; Wed, 5 Mar 2003 19:36:32 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07881 for ; Wed, 5 Mar 2003 19:25:14 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 6 Mar 2003 00:30:00 +0000 Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Mar 2003 00:27:19 +0000 From: "Neil Deason" To: "Peterson, Jon" , Subject: RE: [Simple] SIP and HTTP for presence publication Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EC1@stntexch2.va.neustar.com> X-OriginalArrivalTime: 06 Mar 2003 00:27:20.0041 (UTC) FILETIME=[2625A590:01C2E377] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Mar 2003 16:27:14 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline too... > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Some notes inline. > > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] [snip] > I'm afraid I disagree with much of this. SIP is widely > acknowledged to be > reasonable protocol for transporting SDP. What makes PIDF, > say, so different > from SDP? The difference is that SDP is directly tied to the raison d'etre of SIP - initiate, modify, terminate sessions. Transport of presence data to a compositor is not. It is a problem that can be addressed by SIP, but appears unnecessary to do so. To come at this another way - if I can use PUBLISH for PIDF can I also use it to transport SEACAP? > If your concern is that PIDF would, say, be radically larger > than SDP, then > look to requirement 9, which is essentially a requirement for content > indirection. In fact, content indirection may give you many > of the virtues > of combining SIP and HTTP without some of the vices I see in the > sessions-of-HTTP approach. Would that be sufficient for you? Not really because the problem I have is the extension to SIP. This just proves the existence of HTTP connectivity between publisher and connectivity - so use it rather than add include HTTP POST semantics to SIP. This is how modular IETF protocols are supposed to work together. > > If you mean Section 1.2.2 I don't believe it makes case for such > > dynamism. There is nothing there that shows the overhead of managing > > mobility a the session level through SIP would be too great > and that you > > need to use a series of discrete SIP request/response transactions > > instead. How much do you expect the compositors to move around? The > > example given is a compositor running on a device using dynamic IP > > addresses obtained from DHCP. A PUBLISH gets routed according to a > > reREGISTERed address when the IP address changes, just as an INVITE > > would. > > Right, the difference is that you send an INVITE to establish > a persistent > relationship over which successive publications of presence > information will > be sent. PUBLISH, on the other hand, would be routed on a > per-transaction > basis. In order for the INVITE-based approach to be routed on a > per-publication basis, you would be setting up and > terminating a session > every time you published, which seems very cumbersome to me > from a messaging > perspective. We agree on the difference here - but what is your use case for requiring this level of per publication application layer routing. I take it you accept the DHCP example in the reqs draft does not provide it. I don't see the level of persistence of publication sessions to a compositor as being so short lived that it is not comparable to say instant messaging sessions. I would more typically expect the compositor to be less dynamic than the publishers. In which case an INVITE for the publisher to set up a publication session to the compositor terminated with a BYE when it is going away is a good fit. > Consider as well that some have expressed a desire for > PUBLISH to fork. The > implications for that to the session-based model should be obvious. Actually the wider implications of forking PUBLISH might be a reason you do not want to use a SIP method. Need to see a motivating requirement clarified to appraise this point. Do you have text in mind for a reqs-01 draft for this? > > Disagree - REGISTER is about enabling the discovery > mechanism. PUBLISH > > it is about data transfer leveraging that discovery > mechanism. You can > > still leverage the discovery part for data transfer without > needing to > > add yet more complexity to SIP. > > Presence publication is not about enabling the discovery > mechanism? I find > that a bit difficult to accept. Presence is an incremental > step forward in > the management of discovery above REGISTER, and presence > publication is in > many ways a generalization of registration. You use presence > information to > decide which communications interfaces associated with a user you will > attempt to contact, based on their disposition. Differentiate between presence publication and PUBLISH as the mechanism. As has been noted by others before many people would have REGISTER on the list of stuff that would be done differently given the time over. This doesn't make a good precedent for PUBLISH. > > What I would actually like to see is a cleaner requirements > draft. The > > current iteration has hangovers from being split out from > the PUBLISH > > draft. A requirements draft should not have a conclusion as > to what the > > solution is. Drafts proposing solutions should state how they meet > > requirements. It should not be a requirement for a solution > to extend > > define a new SIP method. The actual underlying requirement > seems to be > > for a compositor discovery mechanism. The protocol analysis > of SIP and > > HTTP in the requirements is incomplete as the option of > combining SIP > > and HTTP is not discussed. Finally imho the requirements > draft fails to > > justify the conclusion that adding SIP style application > logic to HTTP > > is wrong, but adding POST like data transfer to SIP is right. > > > > The purposes of supplying that text about SIP v. HTTP was to > preempt the > religious arguments about this that previously prevented us > from making > progress. In the publication design team, we ultimately found > that there > were too few criteria for a strong case to be made for either option. > Eventually, this becomes a matter of choosing vanilla or chocolate. > Hopefully content indirection can blend the two flavors sufficiently. Well call me greedy but I will have each in its own right ;) I am sure you see what I am saying by now - you don't have to choose between them and then extend one to compenstate for missing functionality provided by the other. Use both without adding anything more to either. Other than the possible open issue re: frequency of presence publication vs. overhead of managing publication within a session format, I have yet to see a reason to do otherwise. Cheers, Neil. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 6 03:59:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28826 for ; Thu, 6 Mar 2003 03:59:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h269ADW15999 for simple-archive@odin.ietf.org; Thu, 6 Mar 2003 04:10:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h269ACO15996 for ; Thu, 6 Mar 2003 04:10:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28780 for ; Thu, 6 Mar 2003 03:58:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h269A9O15970; Thu, 6 Mar 2003 04:10:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26988O15839 for ; Thu, 6 Mar 2003 04:08:08 -0500 Received: from hotgroup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28752 for ; Thu, 6 Mar 2003 03:56:37 -0500 (EST) Message-Id: <200303060856.DAA28752@ietf.org> Received: from chenjian ([218.88.35.61]) by hotgroup.org ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Thu, 06 Mar 2003 17:02:23 +0800 From: "paopai" To: "simple@ietf.org" X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" X-Authenticated-Sender: swifthorse@hotgroup.org X-MDRemoteIP: 218.88.35.61 X-Return-Path: swifthorse@hotgroup.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26988O15840 Subject: [Simple] (no subject) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Mar 2003 16:59:13 +0800 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit simple£¬ÄúºÃ£¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Ö Àñ£¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡paopai ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡swifthorse@hotgroup.org ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-03-06 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 6 22:30:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25919 for ; Thu, 6 Mar 2003 22:30:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h273fcp21110 for simple-archive@odin.ietf.org; Thu, 6 Mar 2003 22:41:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h273fcO21107 for ; Thu, 6 Mar 2003 22:41:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25912 for ; Thu, 6 Mar 2003 22:29:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h273fWO21098; Thu, 6 Mar 2003 22:41:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h273eiO19869 for ; Thu, 6 Mar 2003 22:40:45 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25904 for ; Thu, 6 Mar 2003 22:28:55 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h273Uu913261; Thu, 6 Mar 2003 21:30:56 -0600 Subject: Re: [Simple] [Fwd: I-D ACTION:draft-schulzrinne-simple-iscomposing-00.txt] From: Ben Campbell To: Henning Schulzrinne Cc: simple@ietf.org In-Reply-To: <3E5F6AFE.3010800@cs.columbia.edu> References: <3E5F6AFE.3010800@cs.columbia.edu> Content-Type: text/plain Message-Id: <1047007366.1525.9.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Mar 2003 21:22:46 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Henning, A couple of questions: 1) Even in the two-mode approach, do you think their would be a use for an expiration of sorts? For example, if I send and active state, then logoff prior to the idle state being sent, when can the recipient assume that I am no longer composing? 2) I may have missed it, but I did not remember seeing any explanation of what the content-type attribute in the xml schema means. I assume it is a hint about what sort of content I might be composing. Is this correct? On Fri, 2003-02-28 at 07:58, Henning Schulzrinne wrote: > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-schulzrinne-simple-iscomposing-00.txt > Date: 28 Feb 2003 07:24:24 -0500 > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : is-composing Indication for Instant Messaging Using > the Session Initiation Protocol (SIP) > Author(s) : H. Schulzrinne > Filename : draft-schulzrinne-simple-iscomposing-00.txt > Pages : 8 > Date : 2003-2-27 > > In instant messaging systems, it is useful to know that the other > party is composing a message, e.g., typing. This document defines a > new content type and XML namespace that conveys information about a > message being composed. The message could be of any type, including > text, voice or video > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-schulzrinne-simple-iscomposing-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-schulzrinne-simple-iscomposing-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schulzrinne-simple-iscomposing-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 6 22:39:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26108 for ; Thu, 6 Mar 2003 22:39:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h273p8824732 for simple-archive@odin.ietf.org; Thu, 6 Mar 2003 22:51:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h273p8O24729 for ; Thu, 6 Mar 2003 22:51:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26104 for ; Thu, 6 Mar 2003 22:39:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h273p3O24703; Thu, 6 Mar 2003 22:51:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h273o8O24487 for ; Thu, 6 Mar 2003 22:50:08 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26092 for ; Thu, 6 Mar 2003 22:38:19 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h273eJ913389; Thu, 6 Mar 2003 21:40:20 -0600 Subject: Re: draft-kiss-simple-winfo-filter-reqs-00 (was RE: [Simple] I-D ACTION:draft-khartabil-simple-winfo-filter-00.txt) From: Ben Campbell To: krisztian.kiss@nokia.com Cc: simple@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1047007918.1525.14.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Mar 2003 21:31:58 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Krisztian, Just a tiny little nit that I am loath to even mention, but section 4.3 seems to be more specification of mechanism than requirements. I think you mean to say that it MUST be possible for a server to indicate that it does not support or understand the specific filter settings, and that it MUST (MAY?) be possible for the server to indicate why. On Mon, 2003-02-24 at 14:36, krisztian.kiss@nokia.com wrote: > All, > > The corresponding requirements document (Requirements for Filtering of Watcher Information) is draft-kiss-simple-winfo-filter-reqs-00. > Until it appears in the repository, please download from: > http://free.x3.hu/krkiss/draft-kiss-simple-winfo-filter-reqs-00.txt > > Comments are welcome. > > Regards, > Krisztian > > > > -----Original Message----- > > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Monday, February 24, 2003 1:44 PM > > Cc: simple@ietf.org > > Subject: [Simple] I-D > > ACTION:draft-khartabil-simple-winfo-filter-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Event Notification Filtering for Watcher Info > > Author(s) : H. Khartabil, E. Leppanen > > Filename : draft-khartabil-simple-winfo-filter-00.txt > > Pages : 18 > > Date : 2003-2-21 > > > > Watcher information template-package for the SIP event framework > > refers to the set of users subscribed to a particular resource > > within a particular event package. The Watcher Information I-D does > > not describe a mechanism of how filtering of watcher information can > > be achieved. > > This document defines a watcher info filter. It provides the > > mechanism whereby a watcherinfo subscriber can specify the watcher > > info event filtering rules, using XML, for the notifier and how that > > notifier is to behave when receiving such filter. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-khartabil-simple-win > fo-filter-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-khartabil-simple-winfo-filter-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-khartabil-simple-winfo-filter-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@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 7 03:15:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14176 for ; Fri, 7 Mar 2003 03:15:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h278RJa28257 for simple-archive@odin.ietf.org; Fri, 7 Mar 2003 03:27:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278RIO28254 for ; Fri, 7 Mar 2003 03:27:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14171 for ; Fri, 7 Mar 2003 03:15:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278RBO28243; Fri, 7 Mar 2003 03:27:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278Q6O28206 for ; Fri, 7 Mar 2003 03:26:06 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14158 for ; Fri, 7 Mar 2003 03:14:09 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h278GCC31837; Fri, 7 Mar 2003 08:16:13 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 03:16:21 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214ED4@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Neil Deason'" , simple@ietf.org Subject: RE: [Simple] SIP and HTTP for presence publication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Mar 2003 03:16:19 -0500 A few more incidental comments below, but unsurprisingly, I don't think we're going to come to any quick agreement about this. As I said before, if you really strongly about the matter, I would recommend counterproposing. Jon Peterson NeuStar, Inc. > > > -----Original Message----- > > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > [snip] > > > What makes PIDF, say, so different from SDP? > > The difference is that SDP is directly tied to the raison > d'etre of SIP - initiate, modify, terminate sessions. > Transport of presence data to a compositor is not. It is > a problem that can be addressed by SIP, but appears > unnecessary to do so. To come at this another way - if I > can use PUBLISH for PIDF can I also use it to transport > SEACAP? > Again, I disagree with your assertion that SIP has a single purpose rather than two. Frankly, I don't think that any argument to the contrary is tenable. There is simply too much text to this effect in the base specification. I don't think the difference between the use of SIP for carrying registrations and the use of SIP for carrying presence information is radically different. I note you haven't been picking on the NOTIFY method - do you think it would be better to replace NOTIFY for presence with a PA->UAS HTTP connection set up with an INVITE? The PUBLISH method has been developed specifically for presence publication. We have not shut the door on other usages, but I do share your concern that PUBLISH could be applied inappropriately. Before the work is complete, there will need to be some defense against that at a process level. > > > In fact, content indirection may give you many of the virtues > > of combining SIP and HTTP without some of the vices I see in the > > sessions-of-HTTP approach. Would that be sufficient for you? > > Not really because the problem I have is the extension to SIP. I thought the problem you had was that HTTP is better, somehow. If your only problem is that we are extending SIP unnnecessarily, that's a somewhat lesser concern (but I am not insensitive to SIP bloat). If there were some properties we would get from HTTP that would make this all work better, that would be one thing. But so far I'm not sure you've volunteered any, which brings us back to chocolate and vanilla. > This just proves the existence of HTTP connectivity between > publisher and connectivity - so use it rather than add > include HTTP POST semantics to SIP. This is how modular > IETF protocols are supposed to work together. > Well, it doesn't prove that connectivity exists, it assumes it - and no doubt in some instances that assumption will be misguided. In any event, I find it somewhat unlikely that the content of presence publications will be large. Each individual PUA probably has knowledge of only a relatively small chunk of presence information. Notifications that contain the composed presence of many PUAs have a potential to become quite large indeed, but I doubt that PUBLISHes will. So maybe content indirection will not be so widely used here. > > In order for the INVITE-based approach to be routed on a > > per-publication basis, you would be setting up and terminating a session > > every time you published, which seems very cumbersome to me from a messaging > > perspective. > > We agree on the difference here - but what is your use case > for requiring this level of per publication application > layer routing. I take it you accept the DHCP example in the > reqs draft does not provide it. I don't see the level of > persistence of publication sessions to a compositor as > being so short lived that it is not comparable to say > instant messaging sessions. I would more typically > expect the compositor to be less dynamic than the > publishers. In which case an INVITE for the publisher to set up a > publication session to the compositor terminated with > a BYE when it is going away is a good fit. > I think the DHCP example is intended to motivate this, yes. I don't feel strongly either way about that use case - I don't think it's totally implausible, but nor do I feel it's monumentally important. But I think it provides one instance in which per-transaction routing of publications is significant. Maybe there are others. Co-authors, any thoughts? > > Consider as well that some have expressed a desire for PUBLISH to fork. The > > implications for that to the session-based model should be obvious. > > Actually the wider implications of forking PUBLISH might be a > reason you do not want to use a SIP method. Need to see > a motivating requirement clarified to appraise this point. > Do you have text in mind for a reqs-01 draft for this? > I guess the text about forking ended up in simple-publish-00, not in simple-publish-reqs-00. There's a certain amount of 'why use a new SIP method' material in simple-publish-00. Probably this forking text, with a commensurate requirement, should be moved back to simple-publish-reqs-00. Or maybe, as you previously suggested, all of the HTTP vs. SIP text should be moved forward to simple-publish-00. Incidentally, the implications of forking for the sessions-of-HTTP model are worse, I think, than any implications for the PUBLISH method. > > > Differentiate between presence publication and PUBLISH > as the mechanism. As has been noted by others before many > people would have REGISTER on the list of stuff that would > be done differently given the time over. This doesn't make > a good precedent for PUBLISH. The problems with REGISTER are not intrinsic - the problem is not that SIP supports a registration capability at all. There are a set of specific deficiencies (like the overloading of Contact headers) in REGISTER that merit correction, and if backwards compatibility weren't a concern they could be rectified fairly easily. There is no doubt in my mind that SIP needs to have access to a registration capability. > > > > The purposes of supplying that text about SIP v. HTTP was to preempt the > > religious arguments about this that previously prevented us from making > > progress. In the publication design team, we ultimately found that there > > were too few criteria for a strong case to be made for either option. > > Eventually, this becomes a matter of choosing vanilla or chocolate. > > Hopefully content indirection can blend the two flavors sufficiently. > > Well call me greedy but I will have each in its own right ;) > I am sure you see what I am saying by now - you don't > have to choose between them and then extend one to compenstate > for missing functionality provided by the other. Use both > without adding anything more to either. Other than the possible > open issue re: frequency of presence publication vs. overhead of > managing publication within a session format, I have yet to see > a reason to do otherwise. It would be hard to shake me from the opinion that sessions-of-HTTP is misguided, at least significantly moreso than adding a SIP method for publication. But I think we understand one another, here. Maybe we can talk more about this in SF, in a higher-bandwidth medium. > > Cheers, > Neil. > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 7 08:20:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00048 for ; Fri, 7 Mar 2003 08:20:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27DWLP24335 for simple-archive@odin.ietf.org; Fri, 7 Mar 2003 08:32:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DWKO24332 for ; Fri, 7 Mar 2003 08:32:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00043 for ; Fri, 7 Mar 2003 08:20:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DWFO24311; Fri, 7 Mar 2003 08:32:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DVsO24282 for ; Fri, 7 Mar 2003 08:31:54 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00035 for ; Fri, 7 Mar 2003 08:19:52 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h27DLtNq013252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Mar 2003 08:21:55 -0500 (EST) Message-ID: <3E689CF8.1060901@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: simple@ietf.org Subject: Re: [Simple] [Fwd: I-D ACTION:draft-schulzrinne-simple-iscomposing-00.txt] References: <3E5F6AFE.3010800@cs.columbia.edu> <1047007366.1525.9.camel@verite.localdomain> In-Reply-To: <1047007366.1525.9.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Mar 2003 08:22:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > 1) Even in the two-mode approach, do you think their would be a use for > an expiration of sorts? For example, if I send and active state, then > logoff prior to the idle state being sent, when can the recipient assume > that I am no longer composing? I had kind of assumed that presence would indicate logging off, but that's probably not a good assumption. Maybe one solution is to have the sender specify a "soft state" timeout interval after which it commits to refresh the indication. I have no data to back this up, but I would guess that if you set this to 30 seconds for normal text chat, you'll almost never end up sending a second 'active' message. (I think the most common reason for long composing times is probably that people forget to press the Send button when they're done.) > > 2) I may have missed it, but I did not remember seeing any explanation > of what the content-type attribute in the xml schema means. I assume it > is a hint about what sort of content I might be composing. Is this > correct? Yes; I'll clarify. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 7 09:52:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06994 for ; Fri, 7 Mar 2003 09:52:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27F4Ns32727 for simple-archive@odin.ietf.org; Fri, 7 Mar 2003 10:04:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F4MO32724 for ; Fri, 7 Mar 2003 10:04:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06901 for ; Fri, 7 Mar 2003 09:52:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F4CO32700; Fri, 7 Mar 2003 10:04:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F31O32601 for ; Fri, 7 Mar 2003 10:03:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06587; Fri, 7 Mar 2003 09:50:56 -0500 (EST) Message-Id: <200303071450.JAA06587@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-campbell-simple-im-sessions-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Mar 2003 09:50:56 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Instant Message Sessions in SIMPLE Author(s) : B. Campbell, J. Rosenberg et. al. Filename : draft-campbell-simple-im-sessions-01.txt Pages : 40 Date : 2003-3-6 The SIP MESSAGE method is used to send instant messages, where each message is independent of any other message. This is often called pager-mode messaging, due to the fact that this model is similar to that of most two-way pager devices. Another model is called session-mode. In session-mode, the instant messages are part of a media session that provides ordering, a security context, and other functions. This media session is established using a SIP INVITE, just as an audio or video session would be established. This document describes a The Message Session Relay Protocol (MSRP), a mechanism for transmitting session-mode messages with minimal relay support. Additionally, this document describes using the SDP offer/ answer model to initiate such sessions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-01.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-campbell-simple-im-sessions-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-campbell-simple-im-sessions-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6141951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-campbell-simple-im-sessions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-campbell-simple-im-sessions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6141951.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 7 10:34:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11040 for ; Fri, 7 Mar 2003 10:34:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27FkRY05177 for simple-archive@odin.ietf.org; Fri, 7 Mar 2003 10:46:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FkRO05174 for ; Fri, 7 Mar 2003 10:46:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11018 for ; Fri, 7 Mar 2003 10:34:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FkLO05165; Fri, 7 Mar 2003 10:46:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FjvO05108 for ; Fri, 7 Mar 2003 10:45:57 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11013 for ; Fri, 7 Mar 2003 10:33:53 -0500 (EST) 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.5/Switch-2.2.0) with ESMTP id h27FYZ129581 for ; Fri, 7 Mar 2003 17:34:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Mar 2003 17:35:55 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 17:35:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019451A6@esebe013.ntc.nokia.com> Thread-Topic: New version of the 3GPP messaging requirements Thread-Index: AcLkvz40JfGJGBgpT7K9LSgJGRdBjA== To: X-OriginalArrivalTime: 07 Mar 2003 15:35:55.0744 (UTC) FILETIME=[3E738600:01C2E4BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27FjvO05109 Subject: [Simple] New version of the 3GPP messaging requirements Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Mar 2003 17:35:55 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi All, I've submitted an updated version of the 3GPP messaging requirements to the I-D directories. This document is basically meant to serve as a check list as the requirements get adopted by various other work items. So I'll keep updating it in the mean time. However, some changes were also made based on changes in 3GPP stage 1 (requirements) work since the -00 version was published before Atlanta; as well as based on some commments and suggestions I've received. Here's a link to the I-D: http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-01.txt Comments are welcome! Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 7 10:46:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11635 for ; Fri, 7 Mar 2003 10:46:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Fw7Y06127 for simple-archive@odin.ietf.org; Fri, 7 Mar 2003 10:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Fw7O06122 for ; Fri, 7 Mar 2003 10:58:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11625 for ; Fri, 7 Mar 2003 10:46:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Fw2O06114; Fri, 7 Mar 2003 10:58:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FvNO06074 for ; Fri, 7 Mar 2003 10:57:23 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11584 for ; Fri, 7 Mar 2003 10:45:18 -0500 (EST) 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.5/Switch-2.2.0) with ESMTP id h27FohF03390 for ; Fri, 7 Mar 2003 17:50:43 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 17:47:21 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 17:47:21 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 17:47:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-kiss-simple-winfo-filter-reqs-00 (was RE: [Simple] I-DACTION:draft-khartabil-simple-winfo-filter-00.txt) Message-ID: Thread-Topic: draft-kiss-simple-winfo-filter-reqs-00 (was RE: [Simple] I-DACTION:draft-khartabil-simple-winfo-filter-00.txt) Thread-Index: AcLkW0jHmBtIz7ebR0201gaVUT4RowAVJlfA To: Cc: X-OriginalArrivalTime: 07 Mar 2003 15:47:20.0610 (UTC) FILETIME=[D6A9C820:01C2E4C0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27FvNO06075 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Mar 2003 17:47:20 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Thanks, Ben. Your suggestion seems to be a correct formulation for the actual requirement. The same seems to apply to section 4.4 in draft-moran-simple-pres-filter-reqs-00.txt. Regards, Krisztian > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, March 07, 2003 5:32 AM > To: Kiss Krisztian (NRC/Tampere) > Cc: simple@ietf.org > Subject: Re: draft-kiss-simple-winfo-filter-reqs-00 (was RE: [Simple] > I-DACTION:draft-khartabil-simple-winfo-filter-00.txt) > > > Hi Krisztian, > > Just a tiny little nit that I am loath to even mention, but > section 4.3 > seems to be more specification of mechanism than requirements. I think > you mean to say that it MUST be possible for a server to indicate that > it does not support or understand the specific filter > settings, and that > it MUST (MAY?) be possible for the server to indicate why. > > > > On Mon, 2003-02-24 at 14:36, krisztian.kiss@nokia.com wrote: > > All, > > > > The corresponding requirements document (Requirements for > Filtering of Watcher Information) is > draft-kiss-simple-winfo-filter-reqs-00. > > Until it appears in the repository, please download from: > > http://free.x3.hu/krkiss/draft-kiss-simple-winfo-filter-reqs-00.txt > > > > Comments are welcome. > > > > Regards, > > Krisztian > > > > > > > -----Original Message----- > > > From: ext Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] > > > Sent: Monday, February 24, 2003 1:44 PM > > > Cc: simple@ietf.org > > > Subject: [Simple] I-D > > > ACTION:draft-khartabil-simple-winfo-filter-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > > > > Title : Event Notification Filtering for Watcher Info > > > Author(s) : H. Khartabil, E. Leppanen > > > Filename : draft-khartabil-simple-winfo-filter-00.txt > > > Pages : 18 > > > Date : 2003-2-21 > > > > > > Watcher information template-package for the SIP event framework > > > refers to the set of users subscribed to a particular resource > > > within a particular event package. The Watcher > Information I-D does > > > not describe a mechanism of how filtering of watcher > information can > > > be achieved. > > > This document defines a watcher info filter. It provides the > > > mechanism whereby a watcherinfo subscriber can specify > the watcher > > > info event filtering rules, using XML, for the notifier > and how that > > > notifier is to behave when receiving such filter. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-khartabil-simple-win > > fo-filter-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-khartabil-simple-winfo-filter-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-khartabil-simple-winfo-filter-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@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 7 11:05:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12589 for ; Fri, 7 Mar 2003 11:05:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27GHUZ08295 for simple-archive@odin.ietf.org; Fri, 7 Mar 2003 11:17:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GHUO08292 for ; Fri, 7 Mar 2003 11:17:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12572 for ; Fri, 7 Mar 2003 11:05:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GHPO08284; Fri, 7 Mar 2003 11:17:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GE2O08121 for ; Fri, 7 Mar 2003 11:14:02 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12521 for ; Fri, 7 Mar 2003 11:01:57 -0500 (EST) From: krisztian.kiss@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27G2e114767 for ; Fri, 7 Mar 2003 18:02:40 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Mar 2003 18:04:00 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 18:04:00 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 18:04:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: New version of the 3GPP presence requirements (was RE: [Simple] New version of the 3GPP messaging requirements) Message-ID: Thread-Topic: New version of the 3GPP messaging requirements Thread-Index: AcLkvz40JfGJGBgpT7K9LSgJGRdBjAAAaLFA To: X-OriginalArrivalTime: 07 Mar 2003 16:04:00.0142 (UTC) FILETIME=[2A6E42E0:01C2E4C3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27GE2O08122 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Mar 2003 18:04:00 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, The new version of the 3GPP presence requirements I-D can be also downloaded from (until it appears in the repository): http://free.x3.hu/krkiss/draft-kiss-simple-presence-wireless-reqs-02.txt This document serves the similar purpose as the messaging one, to provide a check list whether the requirements listed by the document are addressed by simple work items/other specific requirements documents. Regards, Krisztian > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Friday, March 07, 2003 5:36 PM > To: simple@ietf.org > Subject: [Simple] New version of the 3GPP messaging requirements > > > Hi All, > > I've submitted an updated version of the 3GPP messaging > requirements to the I-D directories. This document is > basically meant to serve as a check list as the requirements > get adopted by various other work items. So I'll keep > updating it in the mean time. > > However, some changes were also made based on changes in 3GPP > stage 1 (requirements) work since the -00 version was > published before Atlanta; as well as based on some commments > and suggestions I've received. > > Here's a link to the I-D: > http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wire less-reqs-01.txt Comments are welcome! Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 7 15:48:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01226 for ; Fri, 7 Mar 2003 15:48:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KxhA06996 for simple-archive@odin.ietf.org; Fri, 7 Mar 2003 15:59:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KxhO06993 for ; Fri, 7 Mar 2003 15:59:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01147 for ; Fri, 7 Mar 2003 15:47:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KxZO06952; Fri, 7 Mar 2003 15:59:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KlCO05797 for ; Fri, 7 Mar 2003 15:47:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29291; Fri, 7 Mar 2003 15:35:01 -0500 (EST) Message-Id: <200303072035.PAA29291@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-kiss-simple-presence-wireless-reqs-02.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Mar 2003 15:35:00 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Presence Service in 3GPP Wireless Systems Author(s) : K. Kiss Filename : draft-kiss-simple-presence-wireless-reqs-02.txt Pages : 13 Date : 2003-3-7 This Internet-Draft defines requirements for Presence Service in 3GPP wireless systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiss-simple-presence-wireless-reqs-02.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-kiss-simple-presence-wireless-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7152652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kiss-simple-presence-wireless-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7152652.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Mar 9 09:01:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18843 for ; Sun, 9 Mar 2003 09:01:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29EEQW15139 for simple-archive@odin.ietf.org; Sun, 9 Mar 2003 09:14:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29EEQO15136 for ; Sun, 9 Mar 2003 09:14:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18745 for ; Sun, 9 Mar 2003 09:01:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29EEKO15094; Sun, 9 Mar 2003 09:14:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29ED4O15030 for ; Sun, 9 Mar 2003 09:13:04 -0500 Received: from il-tlv-smtpout2.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18442 for ; Sun, 9 Mar 2003 08:59:58 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h29E1px31346 for ; Sun, 9 Mar 2003 16:01:51 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id <1W08QLZ4>; Sun, 9 Mar 2003 16:01:59 +0200 Message-ID: <385D702A9C11D511A9E90008C7160AD505454123@ismail1.comverse.com> From: Cnaan Oded To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E644.718AFC36" Subject: [Simple] Updating Presence permissions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Mar 2003 16:01:56 +0200 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_01C2E644.718AFC36 Content-Type: text/plain; charset="iso-8859-1" When user A, who is not authorized to get user B's presence, subscribes to B, the PS issues a NOTIFY to B, on the winfo package, with A in a 'pending' state. The winfo draft says that "...Joe then authorizes A's subscription through some means..." but I could not find any other reference to this action. Is it done over SIP or HTTP? Can someone point me to the specs/draft? Thanks, Oded ------_=_NextPart_001_01C2E644.718AFC36 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Updating Presence permissions

When user A, who is not authorized to get user B's = presence, subscribes to B, the PS issues a NOTIFY to B, on the winfo = package, with A in a 'pending' state.

The winfo draft says that "...Joe then = authorizes A's subscription through some means..." but I could not = find any other reference to this action. Is it done over SIP or HTTP? = Can someone point me to the specs/draft?

Thanks,
Oded

------_=_NextPart_001_01C2E644.718AFC36-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 10 00:27:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05972 for ; Mon, 10 Mar 2003 00:27:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A5ePw02494 for simple-archive@odin.ietf.org; Mon, 10 Mar 2003 00:40:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A5eOO02491 for ; Mon, 10 Mar 2003 00:40:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05872 for ; Mon, 10 Mar 2003 00:27:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A5eHO02482; Mon, 10 Mar 2003 00:40:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A5d0O02428 for ; Mon, 10 Mar 2003 00:39:00 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05611 for ; Mon, 10 Mar 2003 00:25:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2A5RlJD014717; Mon, 10 Mar 2003 00:27:47 -0500 (EST) Message-ID: <3E6C224B.7020605@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: Cnaan Oded CC: simple@ietf.org Subject: Re: [Simple] Updating Presence permissions References: <385D702A9C11D511A9E90008C7160AD505454123@ismail1.comverse.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Mar 2003 00:27:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is the subject of: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-acap-data-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-01.txt -Jonathan R. Cnaan Oded wrote: > When user A, who is not authorized to get user B's presence, subscribes > to B, the PS issues a NOTIFY to B, on the winfo package, with A in a > 'pending' state. > > The winfo draft says that "...Joe then authorizes A's subscription > through some means..." but I could not find any other reference to this > action. Is it done over SIP or HTTP? Can someone point me to the > specs/draft? > > Thanks, > Oded > -- 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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 10 00:50:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09971 for ; Mon, 10 Mar 2003 00:50:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A63Dx03125 for simple-archive@odin.ietf.org; Mon, 10 Mar 2003 01:03:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A63CO03122 for ; Mon, 10 Mar 2003 01:03:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09853 for ; Mon, 10 Mar 2003 00:49:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A625O03077; Mon, 10 Mar 2003 01:02:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A61mO03058 for ; Mon, 10 Mar 2003 01:01:48 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09603 for ; Mon, 10 Mar 2003 00:48:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2A5oaJD014728; Mon, 10 Mar 2003 00:50:37 -0500 (EST) Message-ID: <3E6C27A7.3010608@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: "Peterson, Jon" CC: "'Neil Deason'" , simple@ietf.org Subject: Re: [Simple] SIP and HTTP for presence publication References: <15A2739B7DAA624D8091C65981D7DA8101214ED4@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Mar 2003 00:50:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I just want to chime in here in support of Jon on this particular topic. I think that PUBLISH is as intrinsic to the sip events story as SUB/NOT itself, and that if you think SIP is a poor choice for PUBLISH, you must conclude that it is also a poor choice for SIP events, or at least, that we should throw away rfc3265 in favor of an INVITE-based mechanism. I, for one, am not interested in doing that. I also believe that a "mixed" model, whereby publication is handled using an INVITE-initiated session, but notification is with SUB/NOT, achieves nothing but awkward implementations. As for PUBLISH vs. SEACAP, these are very different things. SEACAP is about database operations. PUBLISH is about a blind push of data into a huge policy system, which is not at all like a database. Publications from third parties are critical (we have several examples of that so far - publication of presence on a web site, AOL warning capabilities, etc.), whereas that makes no sense to me in a SEACAP type of system. This results in differing requirements for routing and in basic semantics. So, as long as the PUBLISH draft is clear in terms of scope, and explains the above issues well, I am not worried about feature creep into PUBLISH. Thanks, Jonathan R. Peterson, Jon wrote: > A few more incidental comments below, but unsurprisingly, I don't think > we're going to come to any quick agreement about this. As I said before, if > you really strongly about the matter, I would recommend counterproposing. > > Jon Peterson > NeuStar, Inc. > > > >>>>-----Original Message----- >>>>From: Neil Deason [mailto:ndeason@ubiquity.net] >>> >>[snip] >> >> >>>What makes PIDF, say, so different from SDP? >> >>The difference is that SDP is directly tied to the raison >>d'etre of SIP - initiate, modify, terminate sessions. >>Transport of presence data to a compositor is not. It is >>a problem that can be addressed by SIP, but appears >>unnecessary to do so. To come at this another way - if I >>can use PUBLISH for PIDF can I also use it to transport >>SEACAP? >> > > > Again, I disagree with your assertion that SIP has a single purpose rather > than two. Frankly, I don't think that any argument to the contrary is > tenable. There is simply too much text to this effect in the base > specification. I don't think the difference between the use of SIP for > carrying registrations and the use of SIP for carrying presence information > is radically different. I note you haven't been picking on the NOTIFY method > - do you think it would be better to replace NOTIFY for presence with a > PA->UAS HTTP connection set up with an INVITE? > > The PUBLISH method has been developed specifically for presence publication. > We have not shut the door on other usages, but I do share your concern that > PUBLISH could be applied inappropriately. Before the work is complete, there > will need to be some defense against that at a process level. > > >> >> >>>In fact, content indirection may give you many of the virtues >>>of combining SIP and HTTP without some of the vices I see in the >>>sessions-of-HTTP approach. Would that be sufficient for you? >> >>Not really because the problem I have is the extension to SIP. > > > I thought the problem you had was that HTTP is better, somehow. If your only > problem is that we are extending SIP unnnecessarily, that's a somewhat > lesser concern (but I am not insensitive to SIP bloat). If there were some > properties we would get from HTTP that would make this all work better, that > would be one thing. But so far I'm not sure you've volunteered any, which > brings us back to chocolate and vanilla. > > >>This just proves the existence of HTTP connectivity between >>publisher and connectivity - so use it rather than add >>include HTTP POST semantics to SIP. This is how modular >>IETF protocols are supposed to work together. >> > > > Well, it doesn't prove that connectivity exists, it assumes it - and no > doubt in some instances that assumption will be misguided. > > In any event, I find it somewhat unlikely that the content of presence > publications will be large. Each individual PUA probably has knowledge of > only a relatively small chunk of presence information. Notifications that > contain the composed presence of many PUAs have a potential to become quite > large indeed, but I doubt that PUBLISHes will. So maybe content indirection > will not be so widely used here. > > >>>In order for the INVITE-based approach to be routed on a >>>per-publication basis, you would be setting up and terminating a session >>>every time you published, which seems very cumbersome to me from a >> > messaging > >>>perspective. >> >>We agree on the difference here - but what is your use case >>for requiring this level of per publication application >>layer routing. I take it you accept the DHCP example in the >>reqs draft does not provide it. I don't see the level of >>persistence of publication sessions to a compositor as >>being so short lived that it is not comparable to say >>instant messaging sessions. I would more typically >>expect the compositor to be less dynamic than the >>publishers. In which case an INVITE for the publisher to set up a >>publication session to the compositor terminated with >>a BYE when it is going away is a good fit. >> > > > I think the DHCP example is intended to motivate this, yes. I don't feel > strongly either way about that use case - I don't think it's totally > implausible, but nor do I feel it's monumentally important. But I think it > provides one instance in which per-transaction routing of publications is > significant. Maybe there are others. Co-authors, any thoughts? > > >>>Consider as well that some have expressed a desire for PUBLISH to fork. >> > The > >>>implications for that to the session-based model should be obvious. >> >>Actually the wider implications of forking PUBLISH might be a >>reason you do not want to use a SIP method. Need to see >>a motivating requirement clarified to appraise this point. >>Do you have text in mind for a reqs-01 draft for this? >> > > > I guess the text about forking ended up in simple-publish-00, not in > simple-publish-reqs-00. There's a certain amount of 'why use a new SIP > method' material in simple-publish-00. Probably this forking text, with a > commensurate requirement, should be moved back to simple-publish-reqs-00. Or > maybe, as you previously suggested, all of the HTTP vs. SIP text should be > moved forward to simple-publish-00. > > Incidentally, the implications of forking for the sessions-of-HTTP model are > worse, I think, than any implications for the PUBLISH method. > > >> >> >>Differentiate between presence publication and PUBLISH >>as the mechanism. As has been noted by others before many >>people would have REGISTER on the list of stuff that would >>be done differently given the time over. This doesn't make >>a good precedent for PUBLISH. > > > The problems with REGISTER are not intrinsic - the problem is not that SIP > supports a registration capability at all. There are a set of specific > deficiencies (like the overloading of Contact headers) in REGISTER that > merit correction, and if backwards compatibility weren't a concern they > could be rectified fairly easily. There is no doubt in my mind that SIP > needs to have access to a registration capability. > > >>>The purposes of supplying that text about SIP v. HTTP was to preempt the >>>religious arguments about this that previously prevented us from making >>>progress. In the publication design team, we ultimately found that there >>>were too few criteria for a strong case to be made for either option. >>>Eventually, this becomes a matter of choosing vanilla or chocolate. >>>Hopefully content indirection can blend the two flavors sufficiently. >> >>Well call me greedy but I will have each in its own right ;) >>I am sure you see what I am saying by now - you don't >>have to choose between them and then extend one to compenstate >>for missing functionality provided by the other. Use both >>without adding anything more to either. Other than the possible >>open issue re: frequency of presence publication vs. overhead of >>managing publication within a session format, I have yet to see >>a reason to do otherwise. > > > It would be hard to shake me from the opinion that sessions-of-HTTP is > misguided, at least significantly moreso than adding a SIP method for > publication. > > But I think we understand one another, here. Maybe we can talk more about > this in SF, in a higher-bandwidth medium. > > >>Cheers, >>Neil. >> >> >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 11 16:56:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14029 for ; Tue, 11 Mar 2003 16:56:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BMAOd05281 for simple-archive@odin.ietf.org; Tue, 11 Mar 2003 17:10:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMAOO05278 for ; Tue, 11 Mar 2003 17:10:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13984 for ; Tue, 11 Mar 2003 16:56:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMAIO05262; Tue, 11 Mar 2003 17:10:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BM9DO05198 for ; Tue, 11 Mar 2003 17:09:13 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13942 for ; Tue, 11 Mar 2003 16:55:04 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2BLvB920582 for ; Tue, 11 Mar 2003 15:57:11 -0600 Subject: [Fwd: [Simple] I-D ACTION:draft-campbell-simple-im-sessions-01.txt] From: Ben Campbell To: Simple WG Content-Type: text/plain Message-Id: <1047419763.1483.38.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Mar 2003 15:56:04 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just a heads up--this draft has some substantial changes since the 00 version, to deal with issues that came up trying to use COMEDIA. And since without COMEDIA use it became fairly difficult to define the sdp signaling for message sessions without making too many assumptions about the message transport, we converged the two back into a single draft. There are still a number of open issues, but I hope this version will at least get the discussion going again. -----Forwarded Message----- From: Internet-Drafts@ietf.org Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-campbell-simple-im-sessions-01.txt Date: 07 Mar 2003 09:50:56 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Instant Message Sessions in SIMPLE Author(s) : B. Campbell, J. Rosenberg et. al. Filename : draft-campbell-simple-im-sessions-01.txt Pages : 40 Date : 2003-3-6 The SIP MESSAGE method is used to send instant messages, where each message is independent of any other message. This is often called pager-mode messaging, due to the fact that this model is similar to that of most two-way pager devices. Another model is called session-mode. In session-mode, the instant messages are part of a media session that provides ordering, a security context, and other functions. This media session is established using a SIP INVITE, just as an audio or video session would be established. This document describes a The Message Session Relay Protocol (MSRP), a mechanism for transmitting session-mode messages with minimal relay support. Additionally, this document describes using the SDP offer/ answer model to initiate such sessions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-01.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-campbell-simple-im-sessions-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-campbell-simple-im-sessions-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 11 17:49:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16016 for ; Tue, 11 Mar 2003 17:49:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BN3HB08566 for simple-archive@odin.ietf.org; Tue, 11 Mar 2003 18:03:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN3HO08563 for ; Tue, 11 Mar 2003 18:03:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15990 for ; Tue, 11 Mar 2003 17:49:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN3CO08493; Tue, 11 Mar 2003 18:03:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN0IO08336 for ; Tue, 11 Mar 2003 18:00:18 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15907 for ; Tue, 11 Mar 2003 17:46:07 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2BMlA921319; Tue, 11 Mar 2003 16:47:10 -0600 Subject: RE: [Simple] some thoughts on "warnings" From: Ben Campbell To: Cullen Jennings Cc: Jonathan Rosenberg , Simple WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1047422774.1480.48.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Mar 2003 16:46:14 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 20:09, Cullen Jennings wrote: > Can you trust Henning's PA to correctly tabulate warns that warn against > Henning? > I have similar concerns, as it is hard for me to imagine such an approach being useful outside of a walled-garden provider environment. I think this is a place where we would definitely be well served to thoroughly understand the requirements prior to building the mechanism--in particular, the trust models involved. > This seems like a push mechanism where every time someone adds a warn on > somebody the message broadcast all over the place. It might be better to > have it more a pull mechanism so that when you want to find out if you > should trust AOR trying to contact you, you can query some set of people to > get a warning for the AOR. The set of people could be random or a set or > people you trust. (I have no idea what trust means in this context :-) One model that comes to mind is some sort of third-party, trusted clearing house for warning information, where my relationship with the clearing house is unrelated to the other party's relationship with their service provider. Or maybe something like an anti-spam black-hole list. It is not obvious to me that PUBLISH is the solution for either of those architectures. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 12 00:15:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26614 for ; Wed, 12 Mar 2003 00:15:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C5TH601749 for simple-archive@odin.ietf.org; Wed, 12 Mar 2003 00:29:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C5THO01746 for ; Wed, 12 Mar 2003 00:29:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26606 for ; Wed, 12 Mar 2003 00:14:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C5TCO01736; Wed, 12 Mar 2003 00:29:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C5SxO01713 for ; Wed, 12 Mar 2003 00:28:59 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26603 for ; Wed, 12 Mar 2003 00:14:41 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2C5GoC17047 for ; Wed, 12 Mar 2003 05:16:50 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 00:17:04 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214F03@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "Simpletons (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Draft agenda SIMPLE 56th Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Mar 2003 00:17:03 -0500 This is our current plan for the SIMPLE meeting at 56th. Comments to the chairs are welcome. Jon Peterson NeuStar, Inc. ---- SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) Monday, March 17 at 1530-1730 ================================ CHAIRS: Robert Sparks Jon Peterson 1530 - Agenda bashing / Administrivia / Charter Update (Chairs) 1540 - Message Sessions (Campbell) draft-campbell-simple-cpimmsg-sessions-00.txt (not refreshed) draft-campbell-simple-im-sessions-01.txt draft-sparks-simple-jabber-sessions-00.txt 1600 - PUBLISH (Peterson) draft-ietf-simple-publish-00.txt draft-ietf-simple-publish-reqs-00.txt draft-niemi-simple-publish-framework-00.txt (not refreshed) draft-olson-simple-publish-02.txt 1620 - RPIDS (Schulzrinne) draft-schulzrinne-simple-rpids-01.txt draft-kyzivat-simple-prescaps-reqts-00.txt (not refreshed) draft-lonnfors-simple-prescaps-ext-00.txt (not refreshed) 1640 - isComposing (Schulzrinne) draft-schulzrinne-simple-iscomposing-00.txt 1650 - Data Manipulation / Advanced Messaging (Rosenberg) draft-ietf-simple-data-req-01.txt draft-rosenberg-simple-acap-data-00.txt draft-isomaki-simple-list-man-sem-00.txt (not refreshed) (Advanced Messaging) draft-burger-simple-imdn-00.txt draft-rosenberg-simple-messaging-requirements-00.txt 1705 - Event List Template (Roach) draft-ietf-simple-event-list-00.txt 1715 - Filtering / Partial Notification (Lonnfors / Khartabil / Kiss) draft-khartabil-simple-presence-filter-00.txt draft-khartabil-simple-winfo-filter-00.txt draft-kiss-simple-winfo-filter-reqs-00.txt draft-moran-simple-pres-filter-reqs-00.txt (Partial Notification) draft-lonnfors-simple-partial-notify-00.txt draft-lonnfors-simple-presinfo-deliv-reqs-00 1730 - Close meeting _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 13 02:19:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22491 for ; Thu, 13 Mar 2003 02:19:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D7XTN01021 for simple-archive@odin.ietf.org; Thu, 13 Mar 2003 02:33:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D7XSO01017 for ; Thu, 13 Mar 2003 02:33:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22429 for ; Thu, 13 Mar 2003 02:18:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D7XKO01006; Thu, 13 Mar 2003 02:33:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D7WPO00955 for ; Thu, 13 Mar 2003 02:32:25 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22303 for ; Thu, 13 Mar 2003 02:17:34 -0500 (EST) 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.5/Switch-2.2.0) with ESMTP id h2D7NCF18211 for ; Thu, 13 Mar 2003 09:23:12 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 09:19:42 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 09:19:42 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 09:19:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD3B8@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLjaUlMxnJJ4jxySTqSaagiBv5AwwBNiX6A To: , Cc: , , , X-OriginalArrivalTime: 13 Mar 2003 07:19:42.0365 (UTC) FILETIME=[EA9CECD0:01C2E930] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2D7WPO00956 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 09:19:29 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, One comment below (offering to justify the need for users to modify default statuses). > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 06 March, 2003 00:48 > To: Niemi Aki (NMP/Helsinki); bcampbell@dynamicsoft.com > Cc: seancolson@yahoo.com; Isomaki Markus (NRC/Helsinki); > Kiss Krisztian > (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 [snip] > The issue of how different it is from "live" status though > is a bit more > difficult. A PIDF document can contain 0 tuples. A > compositor might consider > this to be the 'base' document it holds for every user. > Sending a tuple-less > PIDF document to watchers definitely, in my mind, > communicates that no > presence information is currently available for the > presentity. I'm not sure > why this default document would need to be modified by users. I envision two types of publications by users. Publications of type "live" statuses, which in order to be accurate need garbage collection, hence they need to be refreshed by users. Then there are the "default" statuses, which are persistent, and in the absence of any "live" publications, form the presentity's presence document. I'm mainly interested in two simple use cases. 1) A user is travelling and boards an airplane. She turns her device off, and would like to publish a note saying that she's on a plane. Having her phone turned off would need to result in a CLOSED status. 2) A user goes out of radio coverage (or someone steps on her LAN line). The presence status she previously published as OPEN is no longer refreshed and defaults to CLOSED. This is good since now people will email her instead of trying IMs. Both of these use cases show that "hard state" is really inherent to a usable presence system. The PUBLISH work really should tackle this aspect of presence in order for the SIMPLE based systems to measure up to systems already out there. Cheers, Aki [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 13 14:06:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13133 for ; Thu, 13 Mar 2003 14:06:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJLDU22330 for simple-archive@odin.ietf.org; Thu, 13 Mar 2003 14:21:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJLDO22327 for ; Thu, 13 Mar 2003 14:21:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13120 for ; Thu, 13 Mar 2003 14:06:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJL8O22309; Thu, 13 Mar 2003 14:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJKjO22285 for ; Thu, 13 Mar 2003 14:20:45 -0500 Received: from web41509.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13099 for ; Thu, 13 Mar 2003 14:05:40 -0500 (EST) Message-ID: <20030313190750.35231.qmail@web41509.mail.yahoo.com> Received: from [131.107.3.84] by web41509.mail.yahoo.com via HTTP; Thu, 13 Mar 2003 11:07:50 PST From: Sean Olson Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 To: aki.niemi@nokia.com, jon.peterson@neustar.biz, bcampbell@dynamicsoft.com Cc: seancolson@yahoo.com, Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD3B8@esebe013.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 11:07:50 -0800 (PST) Ok, I'm sold. This makes sense to me for some systems. Assuming that we have a requirement for publication of "hard state", what are the potential mechanisms we could use? --- aki.niemi@nokia.com wrote: > Hi, > > One comment below (offering to justify the need for > users to modify default statuses). > > > -----Original Message----- > > From: ext Peterson, Jon > [mailto:jon.peterson@neustar.biz] > > Sent: 06 March, 2003 00:48 > > To: Niemi Aki (NMP/Helsinki); > bcampbell@dynamicsoft.com > > Cc: seancolson@yahoo.com; Isomaki Markus > (NRC/Helsinki); > > Kiss Krisztian > > (NRC/Tampere); simple@ietf.org > > Subject: RE: [Simple] > draft-ietf-simple-publish-reqs-00 > > [snip] > > > The issue of how different it is from "live" > status though > > is a bit more > > difficult. A PIDF document can contain 0 tuples. > A > > compositor might consider > > this to be the 'base' document it holds for every > user. > > Sending a tuple-less > > PIDF document to watchers definitely, in my mind, > > > communicates that no > > presence information is currently available for > the > > presentity. I'm not sure > > why this default document would need to be > modified by users. > > I envision two types of publications by users. > Publications of type "live" statuses, which in order > to be accurate need garbage collection, hence they > need to be refreshed by users. Then there are the > "default" statuses, which are persistent, and in the > absence of any "live" publications, form the > presentity's presence document. > > I'm mainly interested in two simple use cases. > > 1) A user is travelling and boards an airplane. She > turns her device off, and would like to publish a > note saying that she's on a plane. Having her phone > turned off would need to result in a CLOSED status. > > 2) A user goes out of radio coverage (or someone > steps on her LAN line). The presence status she > previously published as OPEN is no longer refreshed > and defaults to CLOSED. This is good since now > people will email her instead of trying IMs. > > Both of these use cases show that "hard state" is > really inherent to a usable presence system. The > PUBLISH work really should tackle this aspect of > presence in order for the SIMPLE based systems to > measure up to systems already out there. > > Cheers, > Aki > > [snip] > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 13 14:09:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13248 for ; Thu, 13 Mar 2003 14:09:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJO4X22532 for simple-archive@odin.ietf.org; Thu, 13 Mar 2003 14:24:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJO4O22529 for ; Thu, 13 Mar 2003 14:24:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13235 for ; Thu, 13 Mar 2003 14:08:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJO0O22515; Thu, 13 Mar 2003 14:24:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJN3O22454 for ; Thu, 13 Mar 2003 14:23:03 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13212 for ; Thu, 13 Mar 2003 14:07:58 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2DJ91926340; Thu, 13 Mar 2003 13:09:04 -0600 Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs From: Ben Campbell To: "Rosen, Brian" Cc: "'Paul Kyzivat'" , hisham.khartabil@nokia.com, Jonathan Rosenberg , Simple WG In-Reply-To: <313680C9A886D511A06000204840E1CF030B5E86@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF030B5E86@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain Message-Id: <1047582532.1817.33.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Mar 2003 13:08:52 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I also apologize for coming in late to this converation, but here goes. (I am responding the thread in general, rather than sending a bunch of responses to individual emails.) In general, I like Jonathan's approach. If for no other reason than it is more philosophically aligned with a controversial informational RFC I happen to like a lot. (3087). Actually, though, it allows a more general approach than caller-prefs, in that I could provide a tuple contact that acted as an entry point into a CPL script, or an application server of some type. Maybe even a direct call to a voice mail box, as per the examples in 3087. But I do have a couple of concerns: 1) Why do we assume the PS is constructing the tuple contacts? Certainly an implementation could do this, but they could also be published by a device, couldn't they? 2) What about callers that are not using presence clients at all? Are they left entirely out in the cold by this approach? Would we have to maintain a caller-prefs based mechanism in parallel? It almost seems to me that Jonathan's approach, allong with some markup to indicate if the contact URI should be used "raw", or should have caller-prefs parameters applied to it, could give the best of both worlds. On Thu, 2003-02-20 at 10:44, Rosen, Brian wrote: > I'm glad we got back to this, as I really want to get closure. > .... snip.... > > I think the actual problem, if any, is with the client. It is > > the server > > that gets to decide which of these models it wishes to use. > > The client > > must accomodate. > > > > For us it is not a problem - you only publish one tuple, so > > to us it is > > just a single virtual device. > Well, your client has to use caller preferences to influence > what happens to the call, if he wants to do that. If we don't > make that work well, and clients won't implement it, > we won't have good interoperability. > > > > > I don't know if this is a problem to you or not. Clients need to be > > prepared to present information about multiple tuples to their users, > > and preferably provide the user with suitable courses of action on a > > per-tuple basis. This is more work than if there is but a > > single tuple. > > But I can think of some concise and convenient GUI interfaces > > for this > It would be interesting to do some useability studies on this. > > > > > > I'm not objecting to having a way to provide a device > > > address if the principal wishes to. I'm trying to > > > figure out a way so that if the principal does NOT > > > wish to provide device addresses, or even enumerate > > > the devices he has, all watcher/UA implementations will > > > work pretty well. > > > > Where is the problem? > Making the syntax of the (RPIDS) presence document and > the syntax of caller preferences match enough to make > influencing outcome obvious. > > Making the representation of data in one tuple rich enough > to express the state of a presentity instead of the state > of a device. > > Brian > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 13 14:30:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14065 for ; Thu, 13 Mar 2003 14:30:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJikq24433 for simple-archive@odin.ietf.org; Thu, 13 Mar 2003 14:44:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJikO24430 for ; Thu, 13 Mar 2003 14:44:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14011 for ; Thu, 13 Mar 2003 14:29:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJieO24413; Thu, 13 Mar 2003 14:44:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJfBO24178 for ; Thu, 13 Mar 2003 14:41:11 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13882 for ; Thu, 13 Mar 2003 14:26:05 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2DJS5926645; Thu, 13 Mar 2003 13:28:06 -0600 Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 From: Ben Campbell To: Sean Olson Cc: aki.niemi@nokia.com, Jon Peterson , Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, Simple WG In-Reply-To: <20030313190750.35231.qmail@web41509.mail.yahoo.com> References: <20030313190750.35231.qmail@web41509.mail.yahoo.com> Content-Type: text/plain Message-Id: <1047583653.1816.44.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Mar 2003 13:27:33 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would like to reiterate my previous comment that setting default states seems to fit better into the data manipulation work, also in progress. On Thu, 2003-03-13 at 13:07, Sean Olson wrote: > Ok, I'm sold. This makes sense to me for some > systems. Assuming that we have a requirement for > publication of "hard state", what are the potential > mechanisms we could use? > > > --- aki.niemi@nokia.com wrote: > > Hi, > > > > One comment below (offering to justify the need for > > users to modify default statuses). > > > > > -----Original Message----- > > > From: ext Peterson, Jon > > [mailto:jon.peterson@neustar.biz] > > > Sent: 06 March, 2003 00:48 > > > To: Niemi Aki (NMP/Helsinki); > > bcampbell@dynamicsoft.com > > > Cc: seancolson@yahoo.com; Isomaki Markus > > (NRC/Helsinki); > > > Kiss Krisztian > > > (NRC/Tampere); simple@ietf.org > > > Subject: RE: [Simple] > > draft-ietf-simple-publish-reqs-00 > > > > [snip] > > > > > The issue of how different it is from "live" > > status though > > > is a bit more > > > difficult. A PIDF document can contain 0 tuples. > > A > > > compositor might consider > > > this to be the 'base' document it holds for every > > user. > > > Sending a tuple-less > > > PIDF document to watchers definitely, in my mind, > > > > > communicates that no > > > presence information is currently available for > > the > > > presentity. I'm not sure > > > why this default document would need to be > > modified by users. > > > > I envision two types of publications by users. > > Publications of type "live" statuses, which in order > > to be accurate need garbage collection, hence they > > need to be refreshed by users. Then there are the > > "default" statuses, which are persistent, and in the > > absence of any "live" publications, form the > > presentity's presence document. > > > > I'm mainly interested in two simple use cases. > > > > 1) A user is travelling and boards an airplane. She > > turns her device off, and would like to publish a > > note saying that she's on a plane. Having her phone > > turned off would need to result in a CLOSED status. > > > > 2) A user goes out of radio coverage (or someone > > steps on her LAN line). The presence status she > > previously published as OPEN is no longer refreshed > > and defaults to CLOSED. This is good since now > > people will email her instead of trying IMs. > > > > Both of these use cases show that "hard state" is > > really inherent to a usable presence system. The > > PUBLISH work really should tackle this aspect of > > presence in order for the SIMPLE based systems to > > measure up to systems already out there. > > > > Cheers, > > Aki > > > > [snip] > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Web Hosting - establish your business online > http://webhosting.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 13 15:59:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18827 for ; Thu, 13 Mar 2003 15:59:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DLETR31864 for simple-archive@odin.ietf.org; Thu, 13 Mar 2003 16:14:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLETO31861 for ; Thu, 13 Mar 2003 16:14:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18805 for ; Thu, 13 Mar 2003 15:59:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLEKO31842; Thu, 13 Mar 2003 16:14:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLDkO31816 for ; Thu, 13 Mar 2003 16:13:46 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18793 for ; Thu, 13 Mar 2003 15:58:38 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06115; Thu, 13 Mar 2003 16:00:46 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10194; Thu, 13 Mar 2003 16:00:48 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 16:00:47 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5F5B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Ben Campbell'" Cc: "'Paul Kyzivat'" , hisham.khartabil@nokia.com, Jonathan Rosenberg , Simple WG Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 16:00:46 -0500 Boy, I'd really like to get closure on this. The fundamental difference between this problem and the one 3087 deals with is that the target of the 3087 URI is very explicit, and very precise, and it doesn't depend on any called party preferences. You deposit a message in a voicemail. Here, we have something quite different. My presence service offers some (possibly fascinating) information about me, and you want to contact me. The discussion is how you influence how you contact me. The point I keep trying to maintain is that, unlike in 3087, I get to choose if I let you get to my cellphone or not. You can ask for it, but I may not give it to you. I cannot prevent anyone, nor would I want to, from giving out the sip address (or E.164) of their cellphone. However, I would prefer to give out only my one-true AoR. I would prefer that (ideally) no one has the actual URI of my cellphone except my home proxy (when I register it). Now, you could well know that I have a cellphone. And when you call me, you can ask to ring my cellphone. I might have rules in my proxy that allows you to get to my cellphone from my AoR. So, the subject at hand is how you influence what device I answer on. Isn't that pretty much what caller prefs is for? Now, I'll admit that its entirely possible to come up with some kind of naming convention that lets my presence system and my home proxy have a set of made-up URIs that correspond to a set of what I would call "caller preferences". That would match 3087. Since it's not necessarily true that my home proxy is my presence service, if they aren't the same then whatever presence hands out better be understandable to my home proxy. So, we would need specs to say how one home proxy implementation interworks with someone else's presence implementation. That means we have to specify the URI construction convention; it's not a URI constructed by the presence service, and it's not constructed by the home proxy unless we invent some kind of way the It's either that or the things that are in these URIs really are device addresses and not AoRs. Doing it all with caller prefs solves that. Doing it with Jonathan's proposal means we have to do some sip work to make the language the PS uses in the URIs match some kind of standard. Of course, as you point out, that would also make the UA that doesn't have a watcher be able to influence a call. In theory, that could work with both approaches; the UA would either know what the caller prefs language was like, or it would know what the URI naming convention was. Brian > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, March 13, 2003 2:09 PM > To: Rosen, Brian > Cc: 'Paul Kyzivat'; hisham.khartabil@nokia.com; Jonathan Rosenberg; > Simple WG > Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs > > > I also apologize for coming in late to this converation, but > here goes. > (I am responding the thread in general, rather than sending a bunch of > responses to individual emails.) > > In general, I like Jonathan's approach. If for no other reason than it > is more philosophically aligned with a controversial > informational RFC I > happen to like a lot. (3087). Actually, though, it allows a > more general > approach than caller-prefs, in that I could provide a tuple > contact that > acted as an entry point into a CPL script, or an application server of > some type. Maybe even a direct call to a voice mail box, as per the > examples in 3087. > > But I do have a couple of concerns: > > 1) Why do we assume the PS is constructing the tuple > contacts? Certainly > an implementation could do this, but they could also be published by a > device, couldn't they? > > 2) What about callers that are not using presence clients at all? Are > they left entirely out in the cold by this approach? Would we have to > maintain a caller-prefs based mechanism in parallel? > > It almost seems to me that Jonathan's approach, allong with > some markup > to indicate if the contact URI should be used "raw", or should have > caller-prefs parameters applied to it, could give the best of both > worlds. > > On Thu, 2003-02-20 at 10:44, Rosen, Brian wrote: > > I'm glad we got back to this, as I really want to get closure. > > .... snip.... > > > I think the actual problem, if any, is with the client. It is > > > the server > > > that gets to decide which of these models it wishes to use. > > > The client > > > must accomodate. > > > > > > For us it is not a problem - you only publish one tuple, so > > > to us it is > > > just a single virtual device. > > Well, your client has to use caller preferences to influence > > what happens to the call, if he wants to do that. If we don't > > make that work well, and clients won't implement it, > > we won't have good interoperability. > > > > > > > > I don't know if this is a problem to you or not. Clients > need to be > > > prepared to present information about multiple tuples to > their users, > > > and preferably provide the user with suitable courses of > action on a > > > per-tuple basis. This is more work than if there is but a > > > single tuple. > > > But I can think of some concise and convenient GUI interfaces > > > for this > > It would be interesting to do some useability studies on this. > > > > > > > > > I'm not objecting to having a way to provide a device > > > > address if the principal wishes to. I'm trying to > > > > figure out a way so that if the principal does NOT > > > > wish to provide device addresses, or even enumerate > > > > the devices he has, all watcher/UA implementations will > > > > work pretty well. > > > > > > Where is the problem? > > Making the syntax of the (RPIDS) presence document and > > the syntax of caller preferences match enough to make > > influencing outcome obvious. > > > > Making the representation of data in one tuple rich enough > > to express the state of a presentity instead of the state > > of a device. > > > > Brian > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 14 19:43:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21007 for ; Fri, 14 Mar 2003 19:43:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F0wF124666 for simple-archive@odin.ietf.org; Fri, 14 Mar 2003 19:58:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0wFO24663 for ; Fri, 14 Mar 2003 19:58:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20997 for ; Fri, 14 Mar 2003 19:42:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0w9O24651; Fri, 14 Mar 2003 19:58:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0vPO24620 for ; Fri, 14 Mar 2003 19:57:25 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20992 for ; Fri, 14 Mar 2003 19:41:44 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2F0hjC19221; Sat, 15 Mar 2003 00:43:46 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 19:44:04 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214F3C@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Ben Campbell'" , Sean Olson Cc: aki.niemi@nokia.com, Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, Simple WG Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Mar 2003 19:44:02 -0500 I concur with Ben on this point - setting default attributes of compositor behavior is best left to the data manipulation work. A little more below. Jon Peterson NeuStar, Inc. --- [snip] > > --- aki.niemi@nokia.com wrote: > > > > > > I'm mainly interested in two simple use cases. > > > > > > 1) A user is travelling and boards an airplane. She > > > turns her device off, and would like to publish a > > > note saying that she's on a plane. Having her phone > > > turned off would need to result in a CLOSED status. > > > I can see why you might want to use PUBLISH for this. It would make sense, for example, that if a PIDF body in a PUBLISH contains a -level note, that would become the -level note used by the compositor, and that it would not be subject to expiration (unlike the tuples in the PIDF document, which would expire eventually). I imagine this would be pretty easy for a compositor to implement - just take the note from the most recent PUBLISH and use that. However, when you get off the plane, how do you clear that -level note? Do you have to overwrite it (i.e. PUBLISH new presence) to clear it? Are there ever cases where you'd want to set or unset the default without publishing any presence information? I think there are. This seems more like the data manipulation problem than the publication problem. Turning off a phone, btw, will naturally lead to a CLOSED state, if either the phone PUBLISHes a CLOSED tuple before going offline, or just allows its tuple(s) to expire. > > > 2) A user goes out of radio coverage (or someone > > > steps on her LAN line). The presence status she > > > previously published as OPEN is no longer refreshed > > > and defaults to CLOSED. This is good since now > > > people will email her instead of trying IMs. > > > From my perspective, when all presence publications expire the compositor is left with a document that contains no tuples - it doesn't need to have a tuple that says CLOSED, the lack of tuples explains well enough that nothing is OPEN. The need for some default tuple still isn't clear to me. If the reference to email above suggests that the default PIDF doc would contain a mailto URI (either in a default tuple or in some other way), I'm not sure that presence information should be used to advertise non-real-time forms of communication. Any communications interface that would always have a state of OPEN doesn't have presence, IMHO. > > > Both of these use cases show that "hard state" is > > > really inherent to a usable presence system. The > > > PUBLISH work really should tackle this aspect of > > > presence in order for the SIMPLE based systems to > > > measure up to systems already out there. > > > > > > Cheers, > > > Aki > > > > > > [snip] > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Web Hosting - establish your business online > > http://webhosting.yahoo.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 17 04:06:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07539 for ; Mon, 17 Mar 2003 04:06:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H9NGw16238 for simple-archive@odin.ietf.org; Mon, 17 Mar 2003 04:23:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9NGO16235 for ; Mon, 17 Mar 2003 04:23:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07530 for ; Mon, 17 Mar 2003 04:06:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9NAO16226; Mon, 17 Mar 2003 04:23:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9MEO16197 for ; Mon, 17 Mar 2003 04:22:14 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07511 for ; Mon, 17 Mar 2003 04:05:25 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2H95hJD018792; Mon, 17 Mar 2003 04:05:44 -0500 (EST) Message-ID: <3E757B90.5080402@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: Cullen Jennings , Simple WG Subject: Re: [Simple] some thoughts on "warnings" References: <1047422774.1480.48.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 02:38:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK, I am convinced that this is sufficiently difficult to do correctly that we should not attempt to address it at this time. -Jonathan R. Ben Campbell wrote: > On Sat, 2003-02-22 at 20:09, Cullen Jennings wrote: > >>Can you trust Henning's PA to correctly tabulate warns that warn against >>Henning? >> > > > I have similar concerns, as it is hard for me to imagine such an > approach being useful outside of a walled-garden provider environment. I > think this is a place where we would definitely be well served to > thoroughly understand the requirements prior to building the > mechanism--in particular, the trust models involved. > > > >>This seems like a push mechanism where every time someone adds a warn on >>somebody the message broadcast all over the place. It might be better to >>have it more a pull mechanism so that when you want to find out if you >>should trust AOR trying to contact you, you can query some set of people to >>get a warning for the AOR. The set of people could be random or a set or >>people you trust. (I have no idea what trust means in this context :-) > > > One model that comes to mind is some sort of third-party, trusted > clearing house for warning information, where my relationship with the > clearing house is unrelated to the other party's relationship with their > service provider. Or maybe something like an anti-spam black-hole list. > It is not obvious to me that PUBLISH is the solution for either of those > architectures. > > > -- 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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 17 14:42:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27081 for ; Mon, 17 Mar 2003 14:42:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HJxIf29122 for simple-archive@odin.ietf.org; Mon, 17 Mar 2003 14:59:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJxIO29119 for ; Mon, 17 Mar 2003 14:59:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27022 for ; Mon, 17 Mar 2003 14:42:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJxBO29102; Mon, 17 Mar 2003 14:59:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJw9O29053 for ; Mon, 17 Mar 2003 14:58:09 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27012 for ; Mon, 17 Mar 2003 14:41:05 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2HJkrT13868 for ; Mon, 17 Mar 2003 21:46:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 21:43:18 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 21:43:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD3E0@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLqi/Zaw9OXoA6VST6Qw0hd4d8kOQBXyw+A To: , , Cc: , , X-OriginalArrivalTime: 17 Mar 2003 19:43:18.0020 (UTC) FILETIME=[75449C40:01C2ECBD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HJwDO29054 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 21:43:17 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jon, Using the data manipulation work for setting default statuses certainly makes sense. It just isn't completely clear to me that publication of default status necessarily demands it. The very simple design of the corresponding dataset class would have exactly three attributes: entry id, presentity URI, and the default presence document. The PUBLISH definitely should be able to handle this much data manipulation. In addition, a single mechanism would save us from having to provision, find, establish an SA, connect to etc. a data manipulation server. But if the WG consensus leans towards data manipulation, I can certainly live with it. However, I wouldn't want to mandate yet another set of specs to implementing what I feel is a must-have feature for presence. Some further comments below. Cheers, Aki > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 15 March, 2003 02:44 > To: 'Ben Campbell'; Sean Olson > Cc: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss > Krisztian (NRC/Tampere); Simple WG > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > I concur with Ben on this point - setting default attributes > of compositor > behavior is best left to the data manipulation work. > > A little more below. > > Jon Peterson > NeuStar, Inc. > > --- > > [snip] > > > --- aki.niemi@nokia.com wrote: > > > > > > > > > I'm mainly interested in two simple use cases. > > > > > > > > 1) A user is travelling and boards an airplane. She > > > > turns her device off, and would like to publish a > > > > note saying that she's on a plane. Having her phone > > > > turned off would need to result in a CLOSED status. > > > > > > I can see why you might want to use PUBLISH for this. It > would make sense, > for example, that if a PIDF body in a PUBLISH contains a > -level > note, that would become the -level note used by > the compositor, > and that it would not be subject to expiration (unlike the > tuples in the > PIDF document, which would expire eventually). I imagine > this would be > pretty easy for a compositor to implement - just take the > note from the most > recent PUBLISH and use that. > > However, when you get off the plane, how do you clear that > -level note? Do you have to overwrite it (i.e. > PUBLISH new > presence) to clear it? Are there ever cases where you'd want > to set or unset > the default without publishing any presence information? I > think there are. > This seems more like the data manipulation problem than the > publication > problem. This is a good point. The simple solution is that a new publication of a default status always replaces the existing one. So after stepping out of the airplane, the user would publish a new set of persistent state, that has the cleared. Of course finer control over specific pieces of a default status presence document would be nice, but I could live without it. > Turning off a phone, btw, will naturally lead to a CLOSED > state, if either > the phone PUBLISHes a CLOSED tuple before going offline, or > just allows its > tuple(s) to expire. PUBLISHing a CLOSED would not work if it eventually expires (and disappear). Therefore the default status concept is critical in this scenario. > > > > 2) A user goes out of radio coverage (or someone > > > > steps on her LAN line). The presence status she > > > > previously published as OPEN is no longer refreshed > > > > and defaults to CLOSED. This is good since now > > > > people will email her instead of trying IMs. > > > > > > From my perspective, when all presence publications expire > the compositor is > left with a document that contains no tuples - it > doesn't need to > have a tuple that says CLOSED, the lack of tuples explains > well enough that > nothing is OPEN. The need for some default tuple still isn't > clear to me. > > If the reference to email above suggests that the default > PIDF doc would > contain a mailto URI (either in a default tuple or in some > other way), I'm > not sure that presence information should be used to > advertise non-real-time > forms of communication. Any communications interface that > would always have > a state of OPEN doesn't have presence, IMHO. I think here we clearly disagree. From my point of view, publishing reachability information shouldn't be limited to (near) real-time communications. Even if email is not a real-time communication medium such as voice or IM, there is a lot of useful information that one can provide to watchers. For example, the fact that a user has an MWI subscription active makes it much more likely that an email reaches the recipient relatively soon - compared to an account that gets read once a week. [snip] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 17 17:55:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05719 for ; Mon, 17 Mar 2003 17:55:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HNCJc12443 for simple-archive@odin.ietf.org; Mon, 17 Mar 2003 18:12:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNCJO12440 for ; Mon, 17 Mar 2003 18:12:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05676 for ; Mon, 17 Mar 2003 17:55:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNCAO12423; Mon, 17 Mar 2003 18:12:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNApO12302 for ; Mon, 17 Mar 2003 18:10:51 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05661 for ; Mon, 17 Mar 2003 17:53:43 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2HMsUM19902 for ; Tue, 18 Mar 2003 00:54:30 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 00:55:53 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 00:55:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE73C8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLqi/Zaw9OXoA6VST6Qw0hd4d8kOQBXyw+AADsIKJA= To: , , , Cc: , , X-OriginalArrivalTime: 17 Mar 2003 22:55:54.0153 (UTC) FILETIME=[5D429190:01C2ECD8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HNApO12303 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 00:55:53 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit We are defining a PUBLISH mechanism for presence. Why is there a need to split the protocol to be used to publish the soft state of presence info from default (hard) state? Its a presence publishing solution. why is it that my terminal needs to support SEACAP or whatever solution for data manipulation is, just for the sole purpose of me publishing hard state (if I don't want to have buddy lists, etc. on servers)? Regards, Hisham > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Monday, March 17, 2003 9:43 PM > To: jon.peterson@neustar.biz; bcampbell@dynamicsoft.com; > seancolson@yahoo.com > Cc: Isomaki Markus (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); > simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > Hi Jon, > > Using the data manipulation work for setting default statuses > certainly makes sense. It just isn't completely clear to me > that publication of default status necessarily demands it. > > The very simple design of the corresponding dataset class > would have exactly three attributes: entry id, presentity > URI, and the default presence document. The PUBLISH > definitely should be able to handle this much data > manipulation. In addition, a single mechanism would save us > from having to provision, find, establish an SA, connect to > etc. a data manipulation server. > > But if the WG consensus leans towards data manipulation, I > can certainly live with it. However, I wouldn't want to > mandate yet another set of specs to implementing what I feel > is a must-have feature for presence. > > Some further comments below. > > Cheers, > Aki > > > -----Original Message----- > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: 15 March, 2003 02:44 > > To: 'Ben Campbell'; Sean Olson > > Cc: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss > > Krisztian (NRC/Tampere); Simple WG > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > I concur with Ben on this point - setting default attributes > > of compositor > > behavior is best left to the data manipulation work. > > > > A little more below. > > > > Jon Peterson > > NeuStar, Inc. > > > > --- > > > > [snip] > > > > --- aki.niemi@nokia.com wrote: > > > > > > > > > > > > I'm mainly interested in two simple use cases. > > > > > > > > > > 1) A user is travelling and boards an airplane. She > > > > > turns her device off, and would like to publish a > > > > > note saying that she's on a plane. Having her phone > > > > > turned off would need to result in a CLOSED status. > > > > > > > > > I can see why you might want to use PUBLISH for this. It > > would make sense, > > for example, that if a PIDF body in a PUBLISH contains a > > -level > > note, that would become the -level note used by > > the compositor, > > and that it would not be subject to expiration (unlike the > > tuples in the > > PIDF document, which would expire eventually). I imagine > > this would be > > pretty easy for a compositor to implement - just take the > > note from the most > > recent PUBLISH and use that. > > > > However, when you get off the plane, how do you clear that > > -level note? Do you have to overwrite it (i.e. > > PUBLISH new > > presence) to clear it? Are there ever cases where you'd want > > to set or unset > > the default without publishing any presence information? I > > think there are. > > This seems more like the data manipulation problem than the > > publication > > problem. > > This is a good point. The simple solution is that a new > publication of a default status always replaces the existing > one. So after stepping out of the airplane, the user would > publish a new set of persistent state, that has the cleared. > > Of course finer control over specific pieces of a default > status presence document would be nice, but I could live without it. > > > Turning off a phone, btw, will naturally lead to a CLOSED > > state, if either > > the phone PUBLISHes a CLOSED tuple before going offline, or > > just allows its > > tuple(s) to expire. > > PUBLISHing a CLOSED would not work if it eventually expires > (and disappear). Therefore the default status concept is > critical in this scenario. > > > > > > 2) A user goes out of radio coverage (or someone > > > > > steps on her LAN line). The presence status she > > > > > previously published as OPEN is no longer refreshed > > > > > and defaults to CLOSED. This is good since now > > > > > people will email her instead of trying IMs. > > > > > > > > > From my perspective, when all presence publications expire > > the compositor is > > left with a document that contains no tuples - it > > doesn't need to > > have a tuple that says CLOSED, the lack of tuples explains > > well enough that > > nothing is OPEN. The need for some default tuple still isn't > > clear to me. > > > > If the reference to email above suggests that the default > > PIDF doc would > > contain a mailto URI (either in a default tuple or in some > > other way), I'm > > not sure that presence information should be used to > > advertise non-real-time > > forms of communication. Any communications interface that > > would always have > > a state of OPEN doesn't have presence, IMHO. > > I think here we clearly disagree. From my point of view, > publishing reachability information shouldn't be limited to > (near) real-time communications. Even if email is not a > real-time communication medium such as voice or IM, there is > a lot of useful information that one can provide to watchers. > For example, the fact that a user has an MWI subscription > active makes it much more likely that an email reaches the > recipient relatively soon - compared to an account that gets > read once a week. > > [snip] > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 17 19:48:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10577 for ; Mon, 17 Mar 2003 19:48:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I15Dg20395 for simple-archive@odin.ietf.org; Mon, 17 Mar 2003 20:05:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I15DO20392 for ; Mon, 17 Mar 2003 20:05:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10558 for ; Mon, 17 Mar 2003 19:48:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I157O20384; Mon, 17 Mar 2003 20:05:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I14fO20346 for ; Mon, 17 Mar 2003 20:04:41 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10510 for ; Mon, 17 Mar 2003 19:47:32 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2I0neYk003727 for ; Mon, 17 Mar 2003 19:49:40 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Mar 2003 18:49:43 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645A5@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Event Lists and aggregate state Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 18:49:42 -0600 From the discussion raised during the RPIDS presentation, an idea occured to me. I don't think it's baked enough to bother raising during my presentation today, but I wanted to throw it out for more minds to chew on. Based on the outcome of today's discussion, RPIDS will include a mechanism to include the aggregate state of a group (e.g. sip:helpdesk@example.com might have a simple OPEN/CLOSED indication). In particular, including the detailed state of all of the included items is relegated to the list draft. The first issue that was raised was a slight inelagancy, in the fact that one might want to subscribe to "sip:helpdesk@example.com" to get the aggregate state, or they might want to subscribe to "sip:helpdesk@example.com" to get detailed information about the members. Without requiring use to use different URIs (most practically, different user IDs), there's no way with the current way the mechanisms are defined to indicate which you want. Now, we could make a minor tweak to event lists which allows you to leave out indication of support for lists if you just want the aggregate state (if supported), this is a bit inelegant, and doesn't solve the problem in the more general sense (e.g. the list "sip:helpdesk@example.com" may in turn contains the lists "sip:helpdesk-north-america@example.com" and "sip:helpdesk-europe@example.com"; subscribers may want aggregate information for each of those lists). Now, the way that event lists is currently written, only the "leaves" in the subscription tree can include state. It would be a trivial excercise to add an optional "cid" parameter to the element that points to one of the bodyparts, and allow this bodypart to contain aggregate state for the list. This approach *feels* general to me, although it may well require new body types for certain packages. That's not really different than presnce, actually: PIDF isn't designed to communicate such aggregate state, although RPIDS is. So, should we add this sort of mechanism to the event lists draft? Comments? Support? Opposition? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 17 22:43:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15386 for ; Mon, 17 Mar 2003 22:43:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I40Rg32491 for simple-archive@odin.ietf.org; Mon, 17 Mar 2003 23:00:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I40RO32488 for ; Mon, 17 Mar 2003 23:00:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15381 for ; Mon, 17 Mar 2003 22:43:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I40KO32472; Mon, 17 Mar 2003 23:00:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I3xAO32395 for ; Mon, 17 Mar 2003 22:59:10 -0500 Received: from web41503.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15369 for ; Mon, 17 Mar 2003 22:41:56 -0500 (EST) Message-ID: <20030318034410.62995.qmail@web41503.mail.yahoo.com> Received: from [130.129.141.171] by web41503.mail.yahoo.com via HTTP; Mon, 17 Mar 2003 19:44:10 PST From: Sean Olson Subject: Re: [Simple] Event Lists and aggregate state To: Adam Roach , "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645A5@dyn-tx-exch-001.dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 19:44:10 -0800 (PST) Is this aggregate state computed in some way? If so, what is the computation used to come up with the aggregate state? Issues that come to mind are extensions to the PIDF format and the use of tuple IDs (what is a tuple). These may be non-issues but it would be nice to see this resolution in any recommendation for aggregation of state. --- Adam Roach wrote: > From the discussion raised during the RPIDS > presentation, > an idea occured to me. I don't think it's baked > enough to > bother raising during my presentation today, but I > wanted > to throw it out for more minds to chew on. > > Based on the outcome of today's discussion, RPIDS > will > include a mechanism to include the aggregate state > of > a group (e.g. sip:helpdesk@example.com might have a > simple OPEN/CLOSED indication). In particular, > including > the detailed state of all of the included items is > relegated to the list draft. > > The first issue that was raised was a slight > inelagancy, > in the fact that one might want to subscribe to > "sip:helpdesk@example.com" to get the aggregate > state, > or they might want to subscribe to > "sip:helpdesk@example.com" > to get detailed information about the members. > Without > requiring use to use different URIs (most > practically, > different user IDs), there's no way with the current > way the mechanisms are defined to indicate which you > want. Now, we could make a minor tweak to event > lists > which allows you to leave out indication of support > for > lists if you just want the aggregate state (if > supported), > this is a bit inelegant, and doesn't solve the > problem > in the more general sense (e.g. the list > "sip:helpdesk@example.com" may in turn contains the > lists "sip:helpdesk-north-america@example.com" and > "sip:helpdesk-europe@example.com"; subscribers may > want > aggregate information for each of those lists). > > Now, the way that event lists is currently written, > only > the "leaves" in the subscription tree can include > state. > It would be a trivial excercise to add an optional > "cid" > parameter to the element that points to one > of the > bodyparts, and allow this bodypart to contain > aggregate > state for the list. This approach *feels* general to > me, > although it may well require new body types for > certain > packages. That's not really different than presnce, > actually: PIDF isn't designed to communicate such > aggregate > state, although RPIDS is. > > So, should we add this sort of mechanism to the > event > lists draft? > > Comments? Support? Opposition? > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 17 23:06:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16255 for ; Mon, 17 Mar 2003 23:06:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I4NCG01810 for simple-archive@odin.ietf.org; Mon, 17 Mar 2003 23:23:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I4NBO01807 for ; Mon, 17 Mar 2003 23:23:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16186 for ; Mon, 17 Mar 2003 23:05:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I4N6O01795; Mon, 17 Mar 2003 23:23:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I4MwO01780 for ; Mon, 17 Mar 2003 23:22:58 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16174 for ; Mon, 17 Mar 2003 23:05:46 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2I46XM04787 for ; Tue, 18 Mar 2003 06:06:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 06:07:57 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 06:07:57 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 06:07:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Event Lists and aggregate state Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE73CA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Event Lists and aggregate state Thread-Index: AcLs6GwE5w8ODZe2Shi1SbaBtLP90gAGcvmw To: , X-OriginalArrivalTime: 18 Mar 2003 04:07:57.0260 (UTC) FILETIME=[F519F8C0:01C2ED03] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2I4MwO01781 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 06:07:55 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit What your saying here, if I understand correctly, is that if a subscriber leaves out the "supported: eventlist" header out, but subscribe to a list, then they are subscribing for an aggregate state of the list. Am I correct? If so, then I don't see any harm in that. For filters, I would say the filter applies to the aggregated state (document). This allows non-list implementations to subscribe to a list and get aggregate state. Only the user knows its a list. This only works if the format (XML document) of the aggregate state is the same as the format of the normal state document where the subscriber subscribes to one resource. Does this fit with your proposal? The way the aggregate state is computed is then package specific. /Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Tuesday, March 18, 2003 2:50 AM > To: 'simple@ietf.org' > Subject: [Simple] Event Lists and aggregate state > > > From the discussion raised during the RPIDS presentation, > an idea occured to me. I don't think it's baked enough to > bother raising during my presentation today, but I wanted > to throw it out for more minds to chew on. > > Based on the outcome of today's discussion, RPIDS will > include a mechanism to include the aggregate state of > a group (e.g. sip:helpdesk@example.com might have a > simple OPEN/CLOSED indication). In particular, including > the detailed state of all of the included items is > relegated to the list draft. > > The first issue that was raised was a slight inelagancy, > in the fact that one might want to subscribe to > "sip:helpdesk@example.com" to get the aggregate state, > or they might want to subscribe to "sip:helpdesk@example.com" > to get detailed information about the members. Without > requiring use to use different URIs (most practically, > different user IDs), there's no way with the current > way the mechanisms are defined to indicate which you > want. Now, we could make a minor tweak to event lists > which allows you to leave out indication of support for > lists if you just want the aggregate state (if supported), > this is a bit inelegant, and doesn't solve the problem > in the more general sense (e.g. the list > "sip:helpdesk@example.com" may in turn contains the > lists "sip:helpdesk-north-america@example.com" and > "sip:helpdesk-europe@example.com"; subscribers may want > aggregate information for each of those lists). > > Now, the way that event lists is currently written, only > the "leaves" in the subscription tree can include state. > It would be a trivial excercise to add an optional "cid" > parameter to the element that points to one of the > bodyparts, and allow this bodypart to contain aggregate > state for the list. This approach *feels* general to me, > although it may well require new body types for certain > packages. That's not really different than presnce, > actually: PIDF isn't designed to communicate such aggregate > state, although RPIDS is. > > So, should we add this sort of mechanism to the event > lists draft? > > Comments? Support? Opposition? > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 18 14:16:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24981 for ; Tue, 18 Mar 2003 14:16:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJXtN09984 for simple-archive@odin.ietf.org; Tue, 18 Mar 2003 14:33:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJXtO09981 for ; Tue, 18 Mar 2003 14:33:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24962 for ; Tue, 18 Mar 2003 14:16:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJXnO09969; Tue, 18 Mar 2003 14:33:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJUqO09753 for ; Tue, 18 Mar 2003 14:30:53 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24878 for ; Tue, 18 Mar 2003 14:13:21 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2IJEAM09887 for ; Tue, 18 Mar 2003 21:14:10 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 18 Mar 2003 21:15:33 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 21:15:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE73D3@esebe019.ntc.nokia.com> Thread-Topic: Comments on simple-im-sessions-01 Thread-Index: AcLtgr1LZAIx+G7QQBeyZM5tkLDwBQ== To: X-OriginalArrivalTime: 18 Mar 2003 19:15:32.0309 (UTC) FILETIME=[BED70850:01C2ED82] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJUrO09754 Subject: [Simple] Comments on simple-im-sessions-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 21:15:31 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit - The first problem, which was already brought up in the simple meeting was about the offer/answer exchange and that it is broken. You certainly need another offer answer exchange and not just an answer to an answer. UPDATE, as suggested, would be used, but I wasn't sure of the call flows in this case. Is it: --> INVITE offer <-- 18x answer --> UPDATE offer <-- 200 (UPDATE) answer <-- 200 (INV) --> ACK or --> INVITE offer <-- 200 answer --> UPDATE offer <-- 200 answer I think the former has the advantage that the session is only established after the media negotiation is complete. Also, have you considered PRACK? - Section 6.2 says: "An MSRP transaction consists of exactly one request and one response. A response matches a transaction if it share the same TR-ID value, and if the T-URI value in the response matches a the URI for the endpoint that sent the request" Why is there a need for check the T-URI in the response. We are matching transactions here and I assume that TR-ID is unique enough. - "the msrp uri should be hard to guess and MUST not duplicate any uri used in other active sessions hosted". Can this be exchanged for "the msrp uri must be random and unique for every session"? - In the steps for hosting a session (Inviter and invitee cases), the steps suggest (step 2 in both cases) to listen for a connection from the peer before sending the SDP offer (answer). Why would you start listening on ports that you haven't informed anyone about yet? I think steps 2 should be the last step. i.e. start listening for connections after you send the SDP. - 6.6: there needs to be a timeout timer for no responses arriving at all. A timer value of 32 seconds maybe. If no response arrives, the session needs to be torn down. - I don't understand the need for the visitor to send a LEAVE request. Signalling protocol (BYE) is enough for the host to start tearing down the session. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 18 17:00:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02366 for ; Tue, 18 Mar 2003 17:00:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IMHDO24501 for simple-archive@odin.ietf.org; Tue, 18 Mar 2003 17:17:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMHDO24498 for ; Tue, 18 Mar 2003 17:17:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02315 for ; Tue, 18 Mar 2003 16:59:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMH7O24473; Tue, 18 Mar 2003 17:17:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMGLO24409 for ; Tue, 18 Mar 2003 17:16:21 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02276 for ; Tue, 18 Mar 2003 16:58:45 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2IM0vYk007214; Tue, 18 Mar 2003 17:00:57 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 16:00:59 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645AC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Sean Olson'" , Adam Roach , "'simple@ietf.org'" Subject: RE: [Simple] Event Lists and aggregate state MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 16:00:59 -0600 The idea isn't completely baked yet, but the general idea was that computation of these aggregate states would generally be an implementation decision, although I expect that it would generally be a rather straightforward excercise for implementors to come up with some reasonable aggregation. With the helpdesk example, presence aggregation could be as simple as reporting "OPEN" if at least one resource was "OPEN", and closed otherwise. Specifying a canonical aggregation algorithm, I fear, would tie the hands of implementors (i.e. I see this as a potential area for significant value-add), and it would also impose significant burden on specification of event packages (including any PIDF extensions). Specification of a *syntax*, of course, would be necessary. I see this as adjunct work to defining a package for which aggregation might be useful. /a > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Monday, March 17, 2003 21:44 > To: Adam Roach; 'simple@ietf.org' > Subject: Re: [Simple] Event Lists and aggregate state > > > Is this aggregate state computed in some way? If so, > what is the computation used to come up with the > aggregate state? Issues that come to mind are > extensions to the PIDF format and the use of tuple > IDs (what is a tuple). These may be non-issues but > it would be nice to see this resolution in any > recommendation for aggregation of state. > > > --- Adam Roach wrote: > > From the discussion raised during the RPIDS > > presentation, > > an idea occured to me. I don't think it's baked > > enough to > > bother raising during my presentation today, but I > > wanted > > to throw it out for more minds to chew on. > > > > Based on the outcome of today's discussion, RPIDS > > will > > include a mechanism to include the aggregate state > > of > > a group (e.g. sip:helpdesk@example.com might have a > > simple OPEN/CLOSED indication). In particular, > > including > > the detailed state of all of the included items is > > relegated to the list draft. > > > > The first issue that was raised was a slight > > inelagancy, > > in the fact that one might want to subscribe to > > "sip:helpdesk@example.com" to get the aggregate > > state, > > or they might want to subscribe to > > "sip:helpdesk@example.com" > > to get detailed information about the members. > > Without > > requiring use to use different URIs (most > > practically, > > different user IDs), there's no way with the current > > way the mechanisms are defined to indicate which you > > want. Now, we could make a minor tweak to event > > lists > > which allows you to leave out indication of support > > for > > lists if you just want the aggregate state (if > > supported), > > this is a bit inelegant, and doesn't solve the > > problem > > in the more general sense (e.g. the list > > "sip:helpdesk@example.com" may in turn contains the > > lists "sip:helpdesk-north-america@example.com" and > > "sip:helpdesk-europe@example.com"; subscribers may > > want > > aggregate information for each of those lists). > > > > Now, the way that event lists is currently written, > > only > > the "leaves" in the subscription tree can include > > state. > > It would be a trivial excercise to add an optional > > "cid" > > parameter to the element that points to one > > of the > > bodyparts, and allow this bodypart to contain > > aggregate > > state for the list. This approach *feels* general to > > me, > > although it may well require new body types for > > certain > > packages. That's not really different than presnce, > > actually: PIDF isn't designed to communicate such > > aggregate > > state, although RPIDS is. > > > > So, should we add this sort of mechanism to the > > event > > lists draft? > > > > Comments? Support? Opposition? > > > > /a > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 18 17:04:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02682 for ; Tue, 18 Mar 2003 17:04:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IMLCf24856 for simple-archive@odin.ietf.org; Tue, 18 Mar 2003 17:21:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMLCO24853 for ; Tue, 18 Mar 2003 17:21:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02517 for ; Tue, 18 Mar 2003 17:03:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IML8O24844; Tue, 18 Mar 2003 17:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMKsO24710 for ; Tue, 18 Mar 2003 17:20:54 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02505 for ; Tue, 18 Mar 2003 17:03:19 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2IM5VYk007217; Tue, 18 Mar 2003 17:05:31 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 16:05:33 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645AD@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Adam Roach , simple@ietf.org Subject: RE: [Simple] Event Lists and aggregate state MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 16:05:33 -0600 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > What your saying here, if I understand correctly, is that if > a subscriber leaves out the "supported: eventlist" header > out, but subscribe to a list, then they are subscribing for > an aggregate state of the list. Am I correct? If so, then I > don't see any harm in that. No, that's the solution that I called "inelegant" and criticised for not addressing the general problem. It is what I *don't* want to happen. My proposal, without the thought process that got me there, is to allow the element in the metadata to contain an optional "cid" parameter pointing to a body part, which contains aggregated information for the entire list. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 18 17:49:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03580 for ; Tue, 18 Mar 2003 17:49:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IN6LJ27445 for simple-archive@odin.ietf.org; Tue, 18 Mar 2003 18:06:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IN6LO27442 for ; Tue, 18 Mar 2003 18:06:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03550 for ; Tue, 18 Mar 2003 17:48:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IN6AO27429; Tue, 18 Mar 2003 18:06:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IN5hO27391 for ; Tue, 18 Mar 2003 18:05:43 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03536 for ; Tue, 18 Mar 2003 17:48:06 -0500 (EST) Received: from cs.columbia.edu (ca-71-247.wired.ietf56.ietf.org [130.129.71.247]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h2IMoI0S010956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Mar 2003 17:50:19 -0500 (EST) Message-ID: <3E77A1F6.6010006@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Event Lists and aggregate state References: <9BF66EBF6BEFD942915B4D4D45C051F3A645AD@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645AD@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 17:47:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Slightly related question: How do I tell the PA whether I only care about the group status as a whole or the collection of individual status? Section 3.1 in the draft is less than clear on this. It is not clear (to me) whether including the 'Supported: eventlist' requests the list rather than the aggregate. > No, that's the solution that I called "inelegant" and > criticised for not addressing the general problem. It > is what I *don't* want to happen. > > My proposal, without the thought process that got me > there, is to allow the element in the metadata > to contain an optional "cid" parameter pointing to > a body part, which contains aggregated information > for the entire list. > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 18 18:43:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06452 for ; Tue, 18 Mar 2003 18:43:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J00I530980 for simple-archive@odin.ietf.org; Tue, 18 Mar 2003 19:00:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J00HO30977 for ; Tue, 18 Mar 2003 19:00:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06304 for ; Tue, 18 Mar 2003 18:42:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J00DO30969; Tue, 18 Mar 2003 19:00:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INxxO30905 for ; Tue, 18 Mar 2003 18:59:59 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06297 for ; Tue, 18 Mar 2003 18:42:23 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2INiJYk007304; Tue, 18 Mar 2003 18:44:19 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 17:44:22 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645AE@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , Adam Roach Cc: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Event Lists and aggregate state MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 17:44:22 -0600 > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Slightly related question: How do I tell the PA whether I only care > about the group status as a whole or the collection of individual > status? We can certainly look at other ways of addressing this, but under the solution I'm proposing, it becomes a question of filtering. > Section 3.1 in the draft is less than clear on this. > It is not > clear (to me) whether including the 'Supported: eventlist' > requests the > list rather than the aggregate. Once again, I *don't* think using "Supported: eventlist" to indicate whether you want a list or an aggregate is a very good idea. That's been the main point of this whole thread. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 19 02:16:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00961 for ; Wed, 19 Mar 2003 02:16:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J7XLs06365 for simple-archive@odin.ietf.org; Wed, 19 Mar 2003 02:33:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J7XKO06362 for ; Wed, 19 Mar 2003 02:33:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00515 for ; Wed, 19 Mar 2003 02:15:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J7XEO06353; Wed, 19 Mar 2003 02:33:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J7WJO06318 for ; Wed, 19 Mar 2003 02:32:19 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29971 for ; Wed, 19 Mar 2003 02:14:23 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2J6NOBd000854; Wed, 19 Mar 2003 01:23:24 -0500 (EST) Message-ID: <3E780CD4.7030109@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: "'Henning Schulzrinne'" , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Event Lists and aggregate state References: <9BF66EBF6BEFD942915B4D4D45C051F3A645AE@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Mar 2003 01:23:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >>Slightly related question: How do I tell the PA whether I only care >>about the group status as a whole or the collection of individual >>status? > > > We can certainly look at other ways of addressing this, > but under the solution I'm proposing, it becomes a > question of filtering. I agree that the correct solution is: 1. RPIDS have attributes that describe group state (for example, a percentage that indicates the amount of presentities in the group which are in some state) 2. The event list mechanism be capable of including such a presence document, using a cid attribute of the list element, 3. Filtering is used to indicate whether this information is desired or not. I am OK with doing (2) as part of the list draft. THinking about this a bit, I would prefer to defer the definition of group presence state from RPIDS at this time. It can always be handled separately, and its not clear to me that we really understand what states we want to convey for it. Furthermore, since we don't have the filtering in place yet, in order for the list spec to proceed, the default mode of operation will need to be to never include the state of the list itself unless it is explicitly requested through some future filter mechanism, to be defined. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 19 08:15:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20327 for ; Wed, 19 Mar 2003 08:15:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JDXKg27790 for simple-archive@odin.ietf.org; Wed, 19 Mar 2003 08:33:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JDXKO27787 for ; Wed, 19 Mar 2003 08:33:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20299 for ; Wed, 19 Mar 2003 08:15:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JDXCO27770; Wed, 19 Mar 2003 08:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JDWnO27732 for ; Wed, 19 Mar 2003 08:32:49 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20289 for ; Wed, 19 Mar 2003 08:14:56 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2J5XGBd000835; Wed, 19 Mar 2003 00:34:31 -0500 (EST) Message-ID: <3E780113.7060605@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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on simple-im-sessions-01 References: <2038BCC78B1AD641891A0D1AE133DBB7FE73D3@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Mar 2003 00:33:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > - The first problem, which was already brought up in the simple > meeting was about the offer/answer exchange and that it is broken. > You certainly need another offer answer exchange and not just an > answer to an answer. UPDATE, as suggested, would be used, but I > wasn't sure of the call flows in this case. The intent is that it should work with a single offer/answer exchange. I do not think that doing so is a problem. It merely needs a comedia-like step where you drop one of two connections if you end up with both getting established. > - Section 6.2 says: "An MSRP transaction consists of exactly one > request and one response. A response matches a transaction if it > share the same TR-ID value, and if the T-URI value in the response > matches a the URI for the endpoint that sent the request" > > Why is there a need for check the T-URI in the response. We are > matching transactions here and I assume that TR-ID is unique enough. I can't think of a reason. Ben, did you have something specific in mind? > - In the steps for hosting a session (Inviter and invitee cases), the > steps suggest (step 2 in both cases) to listen for a connection from > the peer before sending the SDP offer (answer). Why would you start > listening on ports that you haven't informed anyone about yet? I > think steps 2 should be the last step. i.e. start listening for > connections after you send the SDP. Its really the same as regular offer/answer. You need to be prepared to receive media the instant the SDP is sent. The sane way to implement that is to being listening just before you send it. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 19 12:33:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26924 for ; Wed, 19 Mar 2003 12:33:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JHpHK14742 for simple-archive@odin.ietf.org; Wed, 19 Mar 2003 12:51:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JHpHO14739 for ; Wed, 19 Mar 2003 12:51:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26906 for ; Wed, 19 Mar 2003 12:33:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JHpAO14731; Wed, 19 Mar 2003 12:51:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JHobO14705 for ; Wed, 19 Mar 2003 12:50:37 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26894 for ; Wed, 19 Mar 2003 12:32:38 -0500 (EST) Received: from cs.columbia.edu (wl-138-255.wireless.ietf56.ietf.org [130.129.138.255]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h2JHYjeF001286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Mar 2003 12:34:47 -0500 (EST) Message-ID: <3E78A981.9000407@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Event Lists and aggregate state References: <9BF66EBF6BEFD942915B4D4D45C051F3A645AE@dyn-tx-exch-001.dynamicsoft.com> <3E780CD4.7030109@dynamicsoft.com> In-Reply-To: <3E780CD4.7030109@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Mar 2003 12:31:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > 1. RPIDS have attributes that describe group state (for example, a > percentage that indicates the amount of presentities in the group which > are in some state) I'm not sure that a percentage is particularly useful in most cases. At least in most cases, an observer only cares whether contacting sales@example.com can reach somebody, not whether 27% of the sales staff is taking a cigarette break. (In ACD scenarios, membership in particular groups is fluid, as agents are shifted to different tasks as load changes. Thus, this number is often not well-defined.) I can see the use for ad-hoc conferencing, but even there, it seems like a 0/100 scenario (everybody there) or you need to know who is there. (No point starting the meeting if the principals aren't there.) In the interest of simplicity, I'd like to see additional use cases. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 19 15:58:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07581 for ; Wed, 19 Mar 2003 15:58:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLFhW04201 for simple-archive@odin.ietf.org; Wed, 19 Mar 2003 16:15:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLFhO04198 for ; Wed, 19 Mar 2003 16:15:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07550 for ; Wed, 19 Mar 2003 15:57:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLFcO04178; Wed, 19 Mar 2003 16:15:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLCdO03978 for ; Wed, 19 Mar 2003 16:12:39 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07473; Wed, 19 Mar 2003 15:54:36 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2JKuo924748; Wed, 19 Mar 2003 14:56:50 -0600 From: Robert Sparks Reply-To: sip@ietf.org To: sip@ietf.org, simple@ietf.org, sipping@ietf.org Content-Type: text/plain Message-Id: <1048107377.1063.49.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] [Fwd: RE: SIP WG bugzilla instance] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2003 12:56:18 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All - I apologize now for violating the no-crosspost policy, but this spans all the groups. Please, please, reply _ONLY_ to sip@ietf.org (which is what should happen if you hit your reply button if I've built this message correctly). If you have any opinions, positive or negative, about our use of bugzilla for issue tracking and whether other groups should follow the model, now would be a good time to comment. Thanks! RjS -----Forwarded Message----- > From: john.loughney@nokia.com > To: rsparks@dynamicsoft.com, wgchairs@ietf.org > Subject: RE: SIP WG bugzilla instance > Date: 19 Mar 2003 22:46:52 +0200 > > Robert, > > Any comments on how the WG & WG Chairs like it? > > John > > > At the session on improving working group chair training > > (and chair effectiveness), tools came up. The SIP related > > working groups have been effectively using a bugzilla variant > > to track document issues and help drive open issues to > > conclusion. > > > > It's available at http://www.sipwg.org (or http://bugs.sipit.net). > > > > One point to bring forth at the beginning - we use this as > > a tracking tool, not an alternative venue for list discussion. > > Document/issue owners are able to make changes to a bug - > > people ask the owner to add things to the tracking tool on > > the appropriate list. The chairs make sure that the owners > > accurately capture threads on the tracking tool. > > > > RjS > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 19 16:36:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10200 for ; Wed, 19 Mar 2003 16:36:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLsDc09004 for simple-archive@odin.ietf.org; Wed, 19 Mar 2003 16:54:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLsDO09001 for ; Wed, 19 Mar 2003 16:54:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10178 for ; Wed, 19 Mar 2003 16:36:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLs5O08964; Wed, 19 Mar 2003 16:54:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLrmO08921 for ; Wed, 19 Mar 2003 16:53:48 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10151 for ; Wed, 19 Mar 2003 16:35:45 -0500 (EST) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2JLUHSc006292; Wed, 19 Mar 2003 16:30:17 -0500 (EST) Received: from cisco.com (sjc-vpn3-401.cisco.com [10.21.65.145]) by cannon.cisco.com (Mirapoint) with ESMTP id ABF69642; Wed, 19 Mar 2003 16:38:54 -0500 (EST) Message-ID: <3E78E165.2090709@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Rosenberg , Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Event Lists and aggregate state References: <9BF66EBF6BEFD942915B4D4D45C051F3A645AE@dyn-tx-exch-001.dynamicsoft.com> <3E780CD4.7030109@dynamicsoft.com> <3E78A981.9000407@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Mar 2003 16:30:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think group presence is generally a hard problem to define, much less solve. Its still a useful problem, but lets not delude ourselves that we can do quickly, so I agree it shouldn't be in RPIDS. With normal presence of individuals, a buddy will typically use the presence status to pick a time to call when there is good probability that the call will be answered by the individual behind the presentity, rather than an answering machine. In the case of groups and ACDs, you might imagine wanting to use presence the same way: I want to watch the presence of the Sales group at Acme.com and only call when someone is available to take my call. That works sometimes, when talking on the phone is only a part time activity of the group members. But consider when I want to call Sabre to make a flight reservation. I may *want* to wait until there is an agent free to take my call before I place the call, but I am unlikely to ever find such a time. I am working at cross purposes with the management of the group, which wants to ensure that every agent is on the phone all the time. This means that in such cases I need a different form of availability. It might take the form of expected wait time. But even that is very difficult to predict in general - wait time will vary depending on who is calling and what they want, which may not even be communicated until after the call is made. I am curious how many out there are interested in working on this problem. Paul Henning Schulzrinne wrote: >> 1. RPIDS have attributes that describe group state (for example, a >> percentage that indicates the amount of presentities in the group >> which are in some state) > > > I'm not sure that a percentage is particularly useful in most cases. At > least in most cases, an observer only cares whether contacting > sales@example.com can reach somebody, not whether 27% of the sales staff > is taking a cigarette break. (In ACD scenarios, membership in particular > groups is fluid, as agents are shifted to different tasks as load > changes. Thus, this number is often not well-defined.) > > I can see the use for ad-hoc conferencing, but even there, it seems like > a 0/100 scenario (everybody there) or you need to know who is there. (No > point starting the meeting if the principals aren't there.) > > In the interest of simplicity, I'd like to see additional use cases. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 19 16:47:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10811 for ; Wed, 19 Mar 2003 16:47:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JM57L10401 for simple-archive@odin.ietf.org; Wed, 19 Mar 2003 17:05:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM57O10398 for ; Wed, 19 Mar 2003 17:05:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10759 for ; Wed, 19 Mar 2003 16:47:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM52O10390; Wed, 19 Mar 2003 17:05:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM41O10232 for ; Wed, 19 Mar 2003 17:04:01 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10690 for ; Wed, 19 Mar 2003 16:45:57 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2JLmB925473 for ; Wed, 19 Mar 2003 15:48:11 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1048110458.2793.2.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE meeting presentations Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2003 13:47:38 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit are available at http://www.softarmor.com/simple/meets/ietf56/slides Presenters - please verify that these are correct. This directory will be handed off to the proceedings as soon as I recieve your confirmation. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 20 14:04:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29644 for ; Thu, 20 Mar 2003 14:04:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KJMF416765 for simple-archive@odin.ietf.org; Thu, 20 Mar 2003 14:22:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJMFO16762 for ; Thu, 20 Mar 2003 14:22:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29629 for ; Thu, 20 Mar 2003 14:03:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJM9O16742; Thu, 20 Mar 2003 14:22:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJL7O16685 for ; Thu, 20 Mar 2003 14:21:07 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29589 for ; Thu, 20 Mar 2003 14:02:37 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2KJ4oP06189; Thu, 20 Mar 2003 14:04:51 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA18017; Thu, 20 Mar 2003 13:04:48 -0600 (CST) Message-ID: <3E7A10CD.3060504@lucent.com> From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Henning Schulzrinne , Jonathan Rosenberg , Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Event Lists and aggregate state References: <9BF66EBF6BEFD942915B4D4D45C051F3A645AE@dyn-tx-exch-001.dynamicsoft.com> <3E780CD4.7030109@dynamicsoft.com> <3E78A981.9000407@cs.columbia.edu> <3E78E165.2090709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 13:04:45 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I think group presence is generally a hard problem to define, much less > solve. Its still a useful problem, but lets not delude ourselves that we > can do quickly, so I agree it shouldn't be in RPIDS. I believe Paul's observation below is fairly insightful in approaching group presence. I think we all agree that group presence becomes harder to quantify as the number of group members increase. Furthermore, as Paul points out, subscribing to the presence of a large group (such as ones comprised of sales@example.com or customer-support@lands-end.com or reservations@ual.com) is at odds with the interest of the said business since the business would ensure that agents are always present. More interesting (and approachable) use of group presence is when the group cardinality is low (10, 15, I don't know what the low water mark is, but definitely not in the hundreds). These types of groups typically represent an individual's buddy list or family member list. > With normal presence of individuals, a buddy will typically use the > presence status to pick a time to call when there is good probability > that the call will be answered by the individual behind the presentity, > rather than an answering machine. > > In the case of groups and ACDs, you might imagine wanting to use > presence the same way: I want to watch the presence of the Sales group > at Acme.com and only call when someone is available to take my call. > > That works sometimes, when talking on the phone is only a part time > activity of the group members. > > But consider when I want to call Sabre to make a flight reservation. I > may *want* to wait until there is an agent free to take my call before I > place the call, but I am unlikely to ever find such a time. I am working > at cross purposes with the management of the group, which wants to > ensure that every agent is on the phone all the time. > > This means that in such cases I need a different form of availability. > It might take the form of expected wait time. But even that is very > difficult to predict in general - wait time will vary depending on who > is calling and what they want, which may not even be communicated until > after the call is made. > > I am curious how many out there are interested in working on this problem. > > Paul > > Henning Schulzrinne wrote: > >>> 1. RPIDS have attributes that describe group state (for example, a >>> percentage that indicates the amount of presentities in the group >>> which are in some state) >> >> >> >> I'm not sure that a percentage is particularly useful in most cases. >> At least in most cases, an observer only cares whether contacting >> sales@example.com can reach somebody, not whether 27% of the sales >> staff is taking a cigarette break. (In ACD scenarios, membership in >> particular groups is fluid, as agents are shifted to different tasks >> as load changes. Thus, this number is often not well-defined.) >> >> I can see the use for ad-hoc conferencing, but even there, it seems >> like a 0/100 scenario (everybody there) or you need to know who is >> there. (No point starting the meeting if the principals aren't there.) >> >> In the interest of simplicity, I'd like to see additional use cases. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 20 14:19:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00597 for ; Thu, 20 Mar 2003 14:19:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KJb8M17710 for simple-archive@odin.ietf.org; Thu, 20 Mar 2003 14:37:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJb8O17699 for ; Thu, 20 Mar 2003 14:37:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00590 for ; Thu, 20 Mar 2003 14:18:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJb4O17539; Thu, 20 Mar 2003 14:37:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJa1O17359 for ; Thu, 20 Mar 2003 14:36:01 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00428 for ; Thu, 20 Mar 2003 14:17:32 -0500 (EST) Received: from cs.columbia.edu (wl-134-224.wireless.ietf56.ietf.org [130.129.134.224]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h2KJJjCC007773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Mar 2003 14:19:46 -0500 (EST) Message-ID: <3E7A1398.2040908@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: simple@ietf.org Subject: Re: [Simple] Event Lists and aggregate state References: <9BF66EBF6BEFD942915B4D4D45C051F3A645AE@dyn-tx-exch-001.dynamicsoft.com> <3E780CD4.7030109@dynamicsoft.com> <3E78A981.9000407@cs.columbia.edu> <3E78E165.2090709@cisco.com> <3E7A10CD.3060504@lucent.com> In-Reply-To: <3E7A10CD.3060504@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 14:16:40 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > More interesting (and approachable) use of group presence is > when the group cardinality is low (10, 15, I don't know what > the low water mark is, but definitely not in the hundreds). > These types of groups typically represent an individual's buddy > list or family member list. Finding group status for an 'amorphous' group of people, such as a buddy list, is probably not all that interesting. Knowing that 25.7% of my buddy list is online is probably of limited use. I can see use for custom-lists such as 'my-project-team', but as I mentioned, in those groups, members are typically not simple counts. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 21 09:46:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14526 for ; Fri, 21 Mar 2003 09:46:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LF4hG10172 for simple-archive@odin.ietf.org; Fri, 21 Mar 2003 10:04:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LF4hO10169 for ; Fri, 21 Mar 2003 10:04:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14508 for ; Fri, 21 Mar 2003 09:45:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LF4YO10143; Fri, 21 Mar 2003 10:04:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LF32O10076 for ; Fri, 21 Mar 2003 10:03:02 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14489 for ; Fri, 21 Mar 2003 09:44:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2LEkOBd002800; Fri, 21 Mar 2003 09:46:24 -0500 (EST) Message-ID: <3E7A8E3C.30906@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: Henning Schulzrinne CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Event Lists and aggregate state References: <9BF66EBF6BEFD942915B4D4D45C051F3A645AE@dyn-tx-exch-001.dynamicsoft.com> <3E780CD4.7030109@dynamicsoft.com> <3E78A981.9000407@cs.columbia.edu> <3E78E165.2090709@cisco.com> <3E7A10CD.3060504@lucent.com> <3E7A1398.2040908@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 22:59:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit First off, I will preface this by saying that I still believe that group presence should be out of RPIDS. I am interested in working on it (and thus my response below), but lets get the basics done first. More inline. Henning Schulzrinne wrote: >> >> More interesting (and approachable) use of group presence is >> when the group cardinality is low (10, 15, I don't know what >> the low water mark is, but definitely not in the hundreds). >> These types of groups typically represent an individual's buddy >> list or family member list. > > > Finding group status for an 'amorphous' group of people, such as a buddy > list, is probably not all that interesting. Knowing that 25.7% of my > buddy list is online is probably of limited use. One application of group presence is to make a decision whether to subscribe to the list members (using Adam's list extensions). One way to make such a determination is through such a percentage. If no one in the group is at a particular state (such as OPEN), its probably not worth subscribing to the list to find more details. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 21 12:39:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19978 for ; Fri, 21 Mar 2003 12:39:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LHwEp22613 for simple-archive@odin.ietf.org; Fri, 21 Mar 2003 12:58:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHwEO22610 for ; Fri, 21 Mar 2003 12:58:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19970 for ; Fri, 21 Mar 2003 12:39:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHw9O22592; Fri, 21 Mar 2003 12:58:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHv5O22559 for ; Fri, 21 Mar 2003 12:57:05 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19932 for ; Fri, 21 Mar 2003 12:38:07 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2LHeN930313; Fri, 21 Mar 2003 11:40:23 -0600 Subject: Re: [Simple] Event Lists and aggregate state From: Ben Campbell To: Adam Roach Cc: "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645A5@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645A5@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048268332.1520.14.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 21 Mar 2003 09:38:53 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In general, I think I agree with the mechanism you propose, if we really do have a need for a state of the list, rather than state of the members. But I am unsure of the problem we are trying to solve. I realize the general futility of attacking an _example_, but it seems to me that in the help desk example below, you are _not_ subscribing to a list. You are instead subscribing to a _derived_ presentity, where the helpdesk presence is derived in an application specific fashion. There is no _generalizeable_ relationship between the presence info for "helpdesk" and the presence info of the various people who might fill the role of help desk. From this perspective, the helpdesk, and a list of helpdesk operators, are different applications, and should have different URIs. The application that generates state for the helpdesk _might_ well subscribe to the list of help desk operators, but again, that is application specific. One possible "state of the list" item might be the membership roster itself--but you already have a mechanism for that. So, unless the consensus of the list really believes the use case under discussion in fact is a list application (and history leads me to believe I will be in the minority on that point), I would prefer to see some more motivation for the need before we do to much work on it. On Mon, 2003-03-17 at 16:49, Adam Roach wrote: > >From the discussion raised during the RPIDS presentation, > an idea occured to me. I don't think it's baked enough to > bother raising during my presentation today, but I wanted > to throw it out for more minds to chew on. > > Based on the outcome of today's discussion, RPIDS will > include a mechanism to include the aggregate state of > a group (e.g. sip:helpdesk@example.com might have a > simple OPEN/CLOSED indication). In particular, including > the detailed state of all of the included items is > relegated to the list draft. > > The first issue that was raised was a slight inelagancy, > in the fact that one might want to subscribe to > "sip:helpdesk@example.com" to get the aggregate state, > or they might want to subscribe to "sip:helpdesk@example.com" > to get detailed information about the members. Without > requiring use to use different URIs (most practically, > different user IDs), there's no way with the current > way the mechanisms are defined to indicate which you > want. Now, we could make a minor tweak to event lists > which allows you to leave out indication of support for > lists if you just want the aggregate state (if supported), > this is a bit inelegant, and doesn't solve the problem > in the more general sense (e.g. the list > "sip:helpdesk@example.com" may in turn contains the > lists "sip:helpdesk-north-america@example.com" and > "sip:helpdesk-europe@example.com"; subscribers may want > aggregate information for each of those lists). > > Now, the way that event lists is currently written, only > the "leaves" in the subscription tree can include state. > It would be a trivial excercise to add an optional "cid" > parameter to the element that points to one of the > bodyparts, and allow this bodypart to contain aggregate > state for the list. This approach *feels* general to me, > although it may well require new body types for certain > packages. That's not really different than presnce, > actually: PIDF isn't designed to communicate such aggregate > state, although RPIDS is. > > So, should we add this sort of mechanism to the event > lists draft? > > Comments? Support? Opposition? > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 21 12:42:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20133 for ; Fri, 21 Mar 2003 12:42:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LI17q22850 for simple-archive@odin.ietf.org; Fri, 21 Mar 2003 13:01:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LI16O22847 for ; Fri, 21 Mar 2003 13:01:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20109 for ; Fri, 21 Mar 2003 12:42:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LI13O22830; Fri, 21 Mar 2003 13:01:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LI0qO22804 for ; Fri, 21 Mar 2003 13:00:52 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20102 for ; Fri, 21 Mar 2003 12:41:54 -0500 (EST) Received: from cs.columbia.edu (wl-134-224.wireless.ietf56.ietf.org [130.129.134.224]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h2LHi7eN024943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Mar 2003 12:44:09 -0500 (EST) Message-ID: <3E7B4EB2.80905@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Event Lists and aggregate state References: <9BF66EBF6BEFD942915B4D4D45C051F3A645AE@dyn-tx-exch-001.dynamicsoft.com> <3E780CD4.7030109@dynamicsoft.com> <3E78A981.9000407@cs.columbia.edu> <3E78E165.2090709@cisco.com> <3E7A10CD.3060504@lucent.com> <3E7A1398.2040908@cs.columbia.edu> <3E7A8E3C.30906@dynamicsoft.com> In-Reply-To: <3E7A8E3C.30906@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 12:41:06 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > First off, I will preface this by saying that I still believe that group > presence should be out of RPIDS. I am interested in working on it (and > thus my response below), but lets get the basics done first. is already out (in my editing version). This differs from the notion of whole-group status. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 21 13:05:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20855 for ; Fri, 21 Mar 2003 13:05:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LIOAv24937 for simple-archive@odin.ietf.org; Fri, 21 Mar 2003 13:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIO9O24934 for ; Fri, 21 Mar 2003 13:24:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20834 for ; Fri, 21 Mar 2003 13:05:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIO5O24910; Fri, 21 Mar 2003 13:24:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LINWO24882 for ; Fri, 21 Mar 2003 13:23:32 -0500 Received: from ierw.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20780 for ; Fri, 21 Mar 2003 13:04:34 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16145 for ; Fri, 21 Mar 2003 13:04:14 -0500 (EST) Received: from cof110avexu2.global.avaya.com (h135-9-6-17.avaya.com [135.9.6.17]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16134 for ; Fri, 21 Mar 2003 13:04:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EFD4.A51946B8" Message-ID: Thread-Index: AcLv1KUSOqBLoIJeTBeWLPRd8rVv4Q== From: "Raman, Sundereshwaran (Sundereshwaran)" To: Subject: [Simple] (no subject) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 11:06:50 -0700 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EFD4.A51946B8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just wondering is there any vendor who has implemented = "draft-ietf-simple-presence-09.txt" ? We want to test our = implementation. Sundi ------_=_NextPart_001_01C2EFD4.A51946B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just wondering is there any vendor who = has implemented "draft-ietf-simple-presence-09.txt" ? We want = to test our implementation.

Sundi


------_=_NextPart_001_01C2EFD4.A51946B8-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 21 13:05:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20868 for ; Fri, 21 Mar 2003 13:05:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LIOBC24953 for simple-archive@odin.ietf.org; Fri, 21 Mar 2003 13:24:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIOBO24950 for ; Fri, 21 Mar 2003 13:24:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20838 for ; Fri, 21 Mar 2003 13:05:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIO7O24926; Fri, 21 Mar 2003 13:24:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LINXO24887 for ; Fri, 21 Mar 2003 13:23:33 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20783 for ; Fri, 21 Mar 2003 13:04:35 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2LI6n930721; Fri, 21 Mar 2003 12:06:49 -0600 Subject: Re: [Simple] Comments on simple-im-sessions-01 From: Ben Campbell To: hisham.khartabil@nokia.com Cc: Simple WG In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE73D3@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7FE73D3@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1048270003.1520.39.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 21 Mar 2003 10:06:43 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the comments! On Tue, 2003-03-18 at 11:15, hisham.khartabil@nokia.com wrote: > - The first problem, which was already brought up in the simple meeting was about the offer/answer exchange and that it is broken. You certainly need another offer answer exchange and not just an answer to an answer. UPDATE, as suggested, would be used, but I wasn't sure of the call flows in this case. Is it: > > --> INVITE offer > <-- 18x answer > --> UPDATE offer > <-- 200 (UPDATE) answer > <-- 200 (INV) > --> ACK > > or > --> INVITE offer > <-- 200 answer > --> UPDATE offer > <-- 200 answer > > I think the former has the advantage that the session is only established after the media negotiation is complete. Also, have you considered PRACK? > In your example above, I am not sure why the callee would be sending a 18x class response under normal circumstances, as it is unlikely to know the caller will want to take back the host role. It _might_ make sense to say that the callee should do that _if_ it is attempting to assume the host role from the caller. However, on further reflection, I am not sure UPDATE is the way to go here at all. It may make more sense to have each endpoint advertise whether they are willing to host, or _must_ host, using something like the direction attributes from COMEDIA. I think Jonathan was trying to communicate that to me last week, but I was apparently being dense at the time. > - Section 6.2 says: > "An MSRP transaction consists of exactly one request and one response. > A response matches a transaction if it share the same TR-ID value, > and if the T-URI value in the response matches a the URI for the > endpoint that sent the request" > > Why is there a need for check the T-URI in the response. We are matching transactions here and I assume that TR-ID is unique enough. The TR-ID is unique only in the context of a session. Therefore determining a transaction match requires both fields. I wrestled with whether the T-URI should be unique on its own. What do people think? > > - "the msrp uri should be hard to guess and MUST not duplicate any uri used in other active sessions hosted". Can this be exchanged for "the msrp uri must be random and unique for every session"? That is more clear, thanks! > > - In the steps for hosting a session (Inviter and invitee cases), the steps suggest (step 2 in both cases) to listen for a connection from the peer before sending the SDP offer (answer). Why would you start listening on ports that you haven't informed anyone about yet? I think steps 2 should be the last step. i.e. start listening for connections after you send the SDP. If you send the offer, then listen, you have a race condition where the invitee might attempt to connect before you get the listen port setup. This is analogous to saying that when sending an offer for an RTP session, you must be immediately ready to recieve RTP on the port. > > - 6.6: there needs to be a timeout timer for no responses arriving at all. A timer value of 32 seconds maybe. If no response arrives, the session needs to be torn down. > Oops. I thought I mentioned a timeout in this section, but it appears I did not. I am not entirely sure we need to specify a time period for it. At most, maybe a default value. I welcome discussion on whether we should just arbitrarily pick 32 seconds for a default because it is such a common number in SIP, or if the reasoning that leads to 32 seconds in SIP is also true here. > - I don't understand the need for the visitor to send a LEAVE request. Signalling protocol (BYE) is enough for the host to start tearing down the session. LEAVE was there to allow a visitor to tell a relay it is leaving, even if the host fails to do so. However, with the discussion about makeing both bind and visit into soft-state operations, both LEAVE and RELEASE probably become moot. > > Regards, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 21 13:21:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21387 for ; Fri, 21 Mar 2003 13:21:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LIdXI26874 for simple-archive@odin.ietf.org; Fri, 21 Mar 2003 13:39:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIdWO26871 for ; Fri, 21 Mar 2003 13:39:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21373 for ; Fri, 21 Mar 2003 13:20:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIdSO26803; Fri, 21 Mar 2003 13:39:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIaVO25836 for ; Fri, 21 Mar 2003 13:36:31 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21265 for ; Fri, 21 Mar 2003 13:17:32 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2LIJk930888; Fri, 21 Mar 2003 12:19:46 -0600 Subject: Re: [Simple] (no subject) From: Robert Sparks To: "Raman, Sundereshwaran ""(Sundereshwaran)" Cc: simple@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1048270722.1007.58.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 21 Mar 2003 10:18:42 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are many implementations of that work (actually presence-10, which is in the hands of the IESG). There will be a SIMPLE interop at the end of April hosted by Jasomi Networks in Canada, most likely Apr 30 through Mar 2. As soon as the details finalize (early next week I hope), I'll post them to this list. I look forward to seeing your implementation there! RjS On Fri, 2003-03-21 at 10:06, Raman, Sundereshwaran (Sundereshwaran) wrote: > Just wondering is there any vendor who has implemented > "draft-ietf-simple-presence-09.txt" ? We want to test our > implementation. > > Sundi > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 21 15:49:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27238 for ; Fri, 21 Mar 2003 15:49:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LL8EN05923 for simple-archive@odin.ietf.org; Fri, 21 Mar 2003 16:08:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LL8EO05920 for ; Fri, 21 Mar 2003 16:08:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27217 for ; Fri, 21 Mar 2003 15:49:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LL88O05912; Fri, 21 Mar 2003 16:08:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LL77O05221 for ; Fri, 21 Mar 2003 16:07:07 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27179 for ; Fri, 21 Mar 2003 15:48:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2LKoQBd002963; Fri, 21 Mar 2003 15:50:26 -0500 (EST) Message-ID: <3E7B7B0D.5090106@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: hisham.khartabil@nokia.com, Simple WG Subject: Re: [Simple] Comments on simple-im-sessions-01 References: <2038BCC78B1AD641891A0D1AE133DBB7FE73D3@esebe019.ntc.nokia.com> <1048270003.1520.39.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 15:50:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: >> - Section 6.2 says: "An MSRP transaction consists of exactly one >> request and one response. A response matches a transaction if it >> share the same TR-ID value, and if the T-URI value in the response >> matches a the URI for the endpoint that sent the request" >> >> Why is there a need for check the T-URI in the response. We are >> matching transactions here and I assume that TR-ID is unique >> enough. > > > The TR-ID is unique only in the context of a session. Therefore > determining a transaction match requires both fields. I wrestled with > whether the T-URI should be unique on its own. What do people think? WHy not just make the TR-ID unique in general, rather than within the session? -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Mar 23 05:37:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29521 for ; Sun, 23 Mar 2003 05:37:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NAuN129331 for simple-archive@odin.ietf.org; Sun, 23 Mar 2003 05:56:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NAuNO29328 for ; Sun, 23 Mar 2003 05:56:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29483 for ; Sun, 23 Mar 2003 05:36:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NAuHO29320; Sun, 23 Mar 2003 05:56:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NAtDO29298 for ; Sun, 23 Mar 2003 05:55:13 -0500 Received: from il-tlv-smtpout1.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29422 for ; Sun, 23 Mar 2003 05:35:26 -0500 (EST) Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h2NAbYY31262 for ; Sun, 23 Mar 2003 12:37:34 +0200 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Sun, 23 Mar 2003 12:37:41 +0200 Message-ID: <385D702A9C11D511A9E90008C7160AD505454196@ismail1.comverse.com> From: Cnaan Oded To: Simple WG MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F128.39B09A7A" Subject: [Simple] Meeting minutes Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 12:37:39 +0200 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_01C2F128.39B09A7A Content-Type: text/plain; charset="iso-8859-1" Where can one find the last meeting minutes? Thanks, Oded ------_=_NextPart_001_01C2F128.39B09A7A Content-Type: text/html; charset="iso-8859-1" Meeting minutes

Where can one find the last meeting minutes?

Thanks,
Oded

------_=_NextPart_001_01C2F128.39B09A7A-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 05:06:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09229 for ; Mon, 24 Mar 2003 05:06:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OAQ7020112 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 05:26:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OAQ7O20109 for ; Mon, 24 Mar 2003 05:26:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09218 for ; Mon, 24 Mar 2003 05:05:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OAQ2O20100; Mon, 24 Mar 2003 05:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OAONO20029 for ; Mon, 24 Mar 2003 05:24:23 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09201 for ; Mon, 24 Mar 2003 05:04:06 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2OA4vM14454 for ; Mon, 24 Mar 2003 12:04:57 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Mar 2003 12:06:21 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Mar 2003 12:06:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Comments on simple-im-sessions-01 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7413@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on simple-im-sessions-01 Thread-Index: AcLuGdus+VLs7v1XSsaIYmzMTadAkwD0kfog To: Cc: X-OriginalArrivalTime: 24 Mar 2003 10:06:20.0662 (UTC) FILETIME=[049B3960:01C2F1ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OAONO20030 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 12:06:19 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, March 19, 2003 7:33 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on simple-im-sessions-01 > > > - In the steps for hosting a session (Inviter and invitee > cases), the > > steps suggest (step 2 in both cases) to listen for a > connection from > > the peer before sending the SDP offer (answer). Why would you start > > listening on ports that you haven't informed anyone about yet? I > > think steps 2 should be the last step. i.e. start listening for > > connections after you send the SDP. > > Its really the same as regular offer/answer. You need to be > prepared to > receive media the instant the SDP is sent. The sane way to implement > that is to being listening just before you send it. Actually, in the offer/answer RFC, it says "Once the offerer has sent the offer, it MUST be prepared to receive media...". Similar sentence for the answerer. I interpret this to mean start listening after the offer is sent. Anyway, I get your point. Regards, Hisham > > -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 11:28:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24737 for ; Mon, 24 Mar 2003 11:28:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OGmLF14487 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 11:48:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OGmLO14484 for ; Mon, 24 Mar 2003 11:48:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24718 for ; Mon, 24 Mar 2003 11:27:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OGmEO14457; Mon, 24 Mar 2003 11:48:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OGlsO14432 for ; Mon, 24 Mar 2003 11:47:54 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24708 for ; Mon, 24 Mar 2003 11:27:30 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2OGTl931333; Mon, 24 Mar 2003 10:29:49 -0600 Subject: Re: [Simple] Meeting minutes From: Robert Sparks To: Cnaan Oded Cc: Simple WG In-Reply-To: <385D702A9C11D511A9E90008C7160AD505454196@ismail1.comverse.com> References: <385D702A9C11D511A9E90008C7160AD505454196@ismail1.comverse.com> Content-Type: text/plain Message-Id: <1048523385.1249.0.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 10:29:46 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit They'll appear here shortly - sorry for the delay. RjS On Sun, 2003-03-23 at 04:37, Cnaan Oded wrote: > Where can one find the last meeting minutes? > > Thanks, > Oded > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 14:59:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00642 for ; Mon, 24 Mar 2003 14:59:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OKJF428795 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 15:19:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKJFO28792 for ; Mon, 24 Mar 2003 15:19:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00625 for ; Mon, 24 Mar 2003 14:58:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKJAO28784; Mon, 24 Mar 2003 15:19:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKJ0O28765 for ; Mon, 24 Mar 2003 15:19:00 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00619 for ; Mon, 24 Mar 2003 14:58:32 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2OK0jTU003490 for ; Mon, 24 Mar 2003 15:00:45 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 14:00:50 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645BF@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Urgent: Event Lists Open Issue Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:00:49 -0600 I've been informed by the chairs that event lists is something we want to close Really Soon Now. As I mentioned during the SIMPLE meeting last week, there is still one open issue, and it's pretty big. To summarize: - RFC 3265 allows SUBSCRIBE messages to contain bodies and "Event:" header parameters to further refine subscriptions. In general, the type of information that can be usefully included in these two places is some form of filtering. - Subscribing to a list resource typically creates a number of subscriptions. - Including a filter in such a subscription is ambiguous: does it apply to the list subscription, the underlying subscriptions, or both? Discussions so far seem to indicate consensus that applying such bodies to the underlying subscriptions is problematic. I agree. Given the forgoing, we're left with the question of how to apply filters to any underlying subscriptions. One obvious punt is to say that such filters are provisioned as part of the list, just like the membership of such a list is. This seems a bit inflexible, since it artificially ties the filter to the list, regardless of the nature of the subscriber. Another approach might be to have some mechanism for the subscriber to somehow retrieve the structure of the list, and then post a set of filters for each element in the list, but this seems horribly complicated and rife with potential race conditions. Alternately, we could push this issue off onto whoever creates the actual filter definitions, forcing them to define them in such a way that they make sense in a list context. Obviously, this imposes a greater burden on what is already a difficult problem. I'm certain that this isn't the entire list of possible solutions. This note is an urgent call for people to ponder and discuss this particular issue. We can't close event lists until this is decided in some way. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 15:15:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02319 for ; Mon, 24 Mar 2003 15:15:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OKZGm29480 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 15:35:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKZGO29477 for ; Mon, 24 Mar 2003 15:35:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02268 for ; Mon, 24 Mar 2003 15:14:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKZBO29465; Mon, 24 Mar 2003 15:35:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKYVO29429 for ; Mon, 24 Mar 2003 15:34:31 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02200 for ; Mon, 24 Mar 2003 15:14:02 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2OKGF902297; Mon, 24 Mar 2003 14:16:15 -0600 Subject: Re: [Simple] Urgent: Event Lists Open Issue From: Robert Sparks To: Adam Roach , Jon Peterson Cc: "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645BF@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645BF@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048536972.1249.70.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 14:16:13 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIMPLE List Members: Please concentrate your efforts on resolving this issue. Post your comments as soon as possible - we are going to try to close this _this week_ and issue WGLC on this document shortly thereafter. Thanks, RjS On Mon, 2003-03-24 at 14:00, Adam Roach wrote: > I've been informed by the chairs that event lists is something we > want to close Really Soon Now. > > As I mentioned during the SIMPLE meeting last week, there is still > one open issue, and it's pretty big. To summarize: > > - RFC 3265 allows SUBSCRIBE messages to contain bodies and > "Event:" header parameters to further refine subscriptions. > In general, the type of information that can be usefully > included in these two places is some form of filtering. > > - Subscribing to a list resource typically creates a number of > subscriptions. > > - Including a filter in such a subscription is ambiguous: does > it apply to the list subscription, the underlying subscriptions, > or both? > > Discussions so far seem to indicate consensus that applying > such bodies to the underlying subscriptions is problematic. > I agree. Given the forgoing, we're left with the question > of how to apply filters to any underlying subscriptions. > > One obvious punt is to say that such filters are provisioned > as part of the list, just like the membership of such a list > is. This seems a bit inflexible, since it artificially ties > the filter to the list, regardless of the nature of the > subscriber. > > Another approach might be to have some mechanism for the > subscriber to somehow retrieve the structure of the list, > and then post a set of filters for each element in the > list, but this seems horribly complicated and rife with > potential race conditions. > > Alternately, we could push this issue off onto whoever creates > the actual filter definitions, forcing them to define them > in such a way that they make sense in a list context. > Obviously, this imposes a greater burden on what is already > a difficult problem. > > I'm certain that this isn't the entire list of possible > solutions. This note is an urgent call for people to > ponder and discuss this particular issue. We can't close > event lists until this is decided in some way. > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 15:33:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02842 for ; Mon, 24 Mar 2003 15:33:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OKrGu30890 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 15:53:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKrGO30887 for ; Mon, 24 Mar 2003 15:53:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02825 for ; Mon, 24 Mar 2003 15:32:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKrAO30879; Mon, 24 Mar 2003 15:53:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKqlO30847 for ; Mon, 24 Mar 2003 15:52:47 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02819 for ; Mon, 24 Mar 2003 15:32:18 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2OKYfBd004586; Mon, 24 Mar 2003 15:34:41 -0500 (EST) Message-ID: <3E7F6BDC.9040602@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: "'simple@ietf.org'" Subject: Re: [Simple] Urgent: Event Lists Open Issue References: <9BF66EBF6BEFD942915B4D4D45C051F3A645BF@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 15:34:36 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: > I've been informed by the chairs that event lists is something we > want to close Really Soon Now. > > As I mentioned during the SIMPLE meeting last week, there is still > one open issue, and it's pretty big. To summarize: > > - RFC 3265 allows SUBSCRIBE messages to contain bodies and > "Event:" header parameters to further refine subscriptions. > In general, the type of information that can be usefully > included in these two places is some form of filtering. > > - Subscribing to a list resource typically creates a number of > subscriptions. > > - Including a filter in such a subscription is ambiguous: does > it apply to the list subscription, the underlying subscriptions, > or both? It applies to the list. Its really simple - you subscribe to a resource. Whatever that resource is, the filters are applied to the resource you subscribe to. There is nothing special about a list as a type of resource. > > Discussions so far seem to indicate consensus that applying > such bodies to the underlying subscriptions is problematic. > I agree. Given the forgoing, we're left with the question > of how to apply filters to any underlying subscriptions. > > One obvious punt is to say that such filters are provisioned > as part of the list, just like the membership of such a list > is. This seems a bit inflexible, since it artificially ties > the filter to the list, regardless of the nature of the > subscriber. > > Another approach might be to have some mechanism for the > subscriber to somehow retrieve the structure of the list, > and then post a set of filters for each element in the > list, but this seems horribly complicated and rife with > potential race conditions. > > Alternately, we could push this issue off onto whoever creates > the actual filter definitions, forcing them to define them > in such a way that they make sense in a list context. > Obviously, this imposes a greater burden on what is already > a difficult problem. I think this is the right answer. Filters are specific to the type of resource you are subscribing to. Thus, if you subscribe to a list, the filters have to know its a list. Practically speaking, this doesnt seem hard, really. If you know how to build a filter for a single presentity, a filter for a list would simply include any filters to apply to a particular presentity. You can also have list wide filters that would apply no matter who the presentity is. > > I'm certain that this isn't the entire list of possible > solutions. This note is an urgent call for people to > ponder and discuss this particular issue. We can't close > event lists until this is decided in some way. I strongly believe that this is a problem for the filters. The draft should merely point in that direction. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 15:51:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03387 for ; Mon, 24 Mar 2003 15:51:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OLBHA32422 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 16:11:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLBHO32419 for ; Mon, 24 Mar 2003 16:11:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03380 for ; Mon, 24 Mar 2003 15:50:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLBCO32411; Mon, 24 Mar 2003 16:11:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLAVO32366 for ; Mon, 24 Mar 2003 16:10:31 -0500 Received: from d12lmsgate-2.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03370 for ; Mon, 24 Mar 2003 15:50:01 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2OKqA33029584; Mon, 24 Mar 2003 21:52:10 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2OKq72g162186; Mon, 24 Mar 2003 21:52:07 +0100 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645BF@dyn-tx-exch-001.dynamicsoft.com> To: Adam Roach Cc: "'simple@ietf.org'" Subject: Re: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/03/2003 22:52:07, Serialize complete at 24/03/2003 22:52:07 Content-Type: text/plain; charset="US-ASCII" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:52:05 +0200 It seems that filter definitions would need a lot more work anyway. RFC 3265 defines a very basic filtering mechanism. So I would say that we should push this issue off to the filtering work. Avshalom Adam Roach Sent by: simple-admin@ietf.org 24/03/2003 22:00 To "'simple@ietf.org'" cc Subject [Simple] Urgent: Event Lists Open Issue I've been informed by the chairs that event lists is something we want to close Really Soon Now. As I mentioned during the SIMPLE meeting last week, there is still one open issue, and it's pretty big. To summarize: - RFC 3265 allows SUBSCRIBE messages to contain bodies and "Event:" header parameters to further refine subscriptions. In general, the type of information that can be usefully included in these two places is some form of filtering. - Subscribing to a list resource typically creates a number of subscriptions. - Including a filter in such a subscription is ambiguous: does it apply to the list subscription, the underlying subscriptions, or both? Discussions so far seem to indicate consensus that applying such bodies to the underlying subscriptions is problematic. I agree. Given the forgoing, we're left with the question of how to apply filters to any underlying subscriptions. One obvious punt is to say that such filters are provisioned as part of the list, just like the membership of such a list is. This seems a bit inflexible, since it artificially ties the filter to the list, regardless of the nature of the subscriber. Another approach might be to have some mechanism for the subscriber to somehow retrieve the structure of the list, and then post a set of filters for each element in the list, but this seems horribly complicated and rife with potential race conditions. Alternately, we could push this issue off onto whoever creates the actual filter definitions, forcing them to define them in such a way that they make sense in a list context. Obviously, this imposes a greater burden on what is already a difficult problem. I'm certain that this isn't the entire list of possible solutions. This note is an urgent call for people to ponder and discuss this particular issue. We can't close event lists until this is decided in some way. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 16:12:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03913 for ; Mon, 24 Mar 2003 16:12:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OLWIr00737 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 16:32:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLWIO00734 for ; Mon, 24 Mar 2003 16:32:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03883 for ; Mon, 24 Mar 2003 16:11:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLWDO00726; Mon, 24 Mar 2003 16:32:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLV3O00669 for ; Mon, 24 Mar 2003 16:31:03 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03852 for ; Mon, 24 Mar 2003 16:09:54 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2OLBuTU003541 for ; Mon, 24 Mar 2003 16:12:08 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 15:12:02 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645C1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 15:12:01 -0600 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > Filters are specific to the type of resource you are subscribing > to. Thus, if you subscribe to a list, the filters have to know its > a list. Because of the change we decided to make in Atlanta, the subscriber does not know whether the resource is a list. Since the subscriber is specifying the filters, you *can't* send one type of filter for a single resource, and a different type for a list; you don't know which one you're subscribing to. You might argue that the UAC sitting in front of a user *will* generally know whether the resource is a list, the RLS to which it subscribes may need to create back-end subscriptions to service the subscription. By the very nature of the change that we agreed to in Atlanta -- that subscriptions can have arbitrary nesting -- the RLS cannot know whether this backend subscription is for a list. We cannot have one type of filter for a list, and a different type for a single resource. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 16:35:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04431 for ; Mon, 24 Mar 2003 16:35:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OLtBk02438 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 16:55:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLtBO02435 for ; Mon, 24 Mar 2003 16:55:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04399 for ; Mon, 24 Mar 2003 16:34:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLt6O02419; Mon, 24 Mar 2003 16:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLsFO02361 for ; Mon, 24 Mar 2003 16:54:15 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04353 for ; Mon, 24 Mar 2003 16:33:44 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2OLZxTU004072 for ; Mon, 24 Mar 2003 16:35:59 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 15:36:03 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645C2@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Jonathan Rosenberg Cc: Adam Roach , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 15:35:57 -0600 Ben Campbell writes: > You have made some effort in the draft so far to be clear that the > presence of so-called "back-end" subscriptions are really an > implementation decision, and not part of the list subscription > specification. From that perspective, specifying that a list > subscription filter propagates to back-end subscriptions is > inappropriate. Assuming that back-end subscriptions exist. One list > implementation might choose to have non-filtered back-end > subscriptions, > and perform filtering locally. Another might choose to create > filters on > each back-end subscription. These filters may or may not derive from a > filter on the top list subscription. This is all up to local policy. Sorry; I'm being a bit sloppy with my terminology. You are correct in your assertion that literal back-end SIP subscriptions may or may not exist; that's an implementation decision. However, even if all the resources are controlled by a single server, you still end up having conceptual subscriptions (not SIP subscriptions, but "subscription" in the more general information technology sense) to the state of the resources in the list. Perhaps the problem is that I'm not really being concrete enough. Taking as an example location-enhanced presence (as proposed in draft-peterson-geopriv-pres-00), let's say that I want to subscribe to a presence list, but want to install a filter that says, "only notify me when someone's location changes by more than 100 miles". In order to do this, I generally want to include such information in the SUBSCRIBE request itself. If we relegate the filtering of these (possibly conceptual, non-SIP) subscriptions to be an RLS implementation decision, doing so becomes impossible. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 16:42:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03389 for ; Mon, 24 Mar 2003 15:51:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OLBHE32438 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 16:11:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLBHO32428 for ; Mon, 24 Mar 2003 16:11:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03382 for ; Mon, 24 Mar 2003 15:50:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLBBO32391; Mon, 24 Mar 2003 16:11:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLAMO32359 for ; Mon, 24 Mar 2003 16:10:22 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03367 for ; Mon, 24 Mar 2003 15:49:53 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2OKqB902788; Mon, 24 Mar 2003 14:52:11 -0600 Subject: Re: [Simple] Urgent: Event Lists Open Issue From: Ben Campbell To: Jonathan Rosenberg Cc: Adam Roach , "'simple@ietf.org'" In-Reply-To: <3E7F6BDC.9040602@dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645BF@dyn-tx-exch-001.dynamicsoft.com> <3E7F6BDC.9040602@dynamicsoft.com> Content-Type: text/plain Message-Id: <1048539067.1523.16.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 14:51:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-03-24 at 14:34, Jonathan Rosenberg wrote: > inline. > > Adam Roach wrote: > > I've been informed by the chairs that event lists is something we > > want to close Really Soon Now. > > > > As I mentioned during the SIMPLE meeting last week, there is still > > one open issue, and it's pretty big. To summarize: > > > > - RFC 3265 allows SUBSCRIBE messages to contain bodies and > > "Event:" header parameters to further refine subscriptions. > > In general, the type of information that can be usefully > > included in these two places is some form of filtering. > > > > - Subscribing to a list resource typically creates a number of > > subscriptions. > > > > - Including a filter in such a subscription is ambiguous: does > > it apply to the list subscription, the underlying subscriptions, > > or both? > > It applies to the list. > > Its really simple - you subscribe to a resource. Whatever that resource > is, the filters are applied to the resource you subscribe to. There is > nothing special about a list as a type of resource. > If I understand Jonathan correctly, then I agree completely. You have made some effort in the draft so far to be clear that the presence of so-called "back-end" subscriptions are really an implementation decision, and not part of the list subscription specification. From that perspective, specifying that a list subscription filter propagates to back-end subscriptions is inappropriate. Assuming that back-end subscriptions exist. One list implementation might choose to have non-filtered back-end subscriptions, and perform filtering locally. Another might choose to create filters on each back-end subscription. These filters may or may not derive from a filter on the top list subscription. This is all up to local policy. > > > > > Discussions so far seem to indicate consensus that applying > > such bodies to the underlying subscriptions is problematic. > > I agree. Given the forgoing, we're left with the question > > of how to apply filters to any underlying subscriptions. > > > > One obvious punt is to say that such filters are provisioned > > as part of the list, just like the membership of such a list > > is. This seems a bit inflexible, since it artificially ties > > the filter to the list, regardless of the nature of the > > subscriber. > > > > Another approach might be to have some mechanism for the > > subscriber to somehow retrieve the structure of the list, > > and then post a set of filters for each element in the > > list, but this seems horribly complicated and rife with > > potential race conditions. > > > > Alternately, we could push this issue off onto whoever creates > > the actual filter definitions, forcing them to define them > > in such a way that they make sense in a list context. > > Obviously, this imposes a greater burden on what is already > > a difficult problem. > > I think this is the right answer. Filters are specific to the type of > resource you are subscribing to. Thus, if you subscribe to a list, the > filters have to know its a list. > > Practically speaking, this doesnt seem hard, really. If you know how to > build a filter for a single presentity, a filter for a list would simply > include any filters to apply to a particular presentity. You can also > have list wide filters that would apply no matter who the presentity is. > > > > > I'm certain that this isn't the entire list of possible > > solutions. This note is an urgent call for people to > > ponder and discuss this particular issue. We can't close > > event lists until this is decided in some way. > > I strongly believe that this is a problem for the filters. The draft > should merely point in that direction. Agreed. And to restate what I said above, the list draft should neither assume nor prevent any relationship between filters specified at the top level subscriptions, and any filters that may be applied in any resulting back-end subscriptions. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 16:54:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05153 for ; Mon, 24 Mar 2003 16:54:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMEFb04607 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 17:14:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMEFO04603 for ; Mon, 24 Mar 2003 17:14:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05145 for ; Mon, 24 Mar 2003 16:53:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMEAO04588; Mon, 24 Mar 2003 17:14:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMDFO04561 for ; Mon, 24 Mar 2003 17:13:15 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05124 for ; Mon, 24 Mar 2003 16:52:44 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2OLt2903667; Mon, 24 Mar 2003 15:55:02 -0600 Subject: RE: [Simple] Urgent: Event Lists Open Issue From: Ben Campbell To: Adam Roach Cc: Jonathan Rosenberg , "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645C2@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C2@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048542835.1523.31.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 15:53:55 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-03-24 at 15:35, Adam Roach wrote: > Ben Campbell writes: > > > You have made some effort in the draft so far to be clear that the > > presence of so-called "back-end" subscriptions are really an > > implementation decision, and not part of the list subscription > > specification. From that perspective, specifying that a list > > subscription filter propagates to back-end subscriptions is > > inappropriate. Assuming that back-end subscriptions exist. One list > > implementation might choose to have non-filtered back-end > > subscriptions, > > and perform filtering locally. Another might choose to create > > filters on > > each back-end subscription. These filters may or may not derive from a > > filter on the top list subscription. This is all up to local policy. > > Sorry; I'm being a bit sloppy with my terminology. > > You are correct in your assertion that literal back-end SIP > subscriptions may or may not exist; that's an implementation > decision. However, even if all the resources are controlled > by a single server, you still end up having conceptual > subscriptions (not SIP subscriptions, but "subscription" in > the more general information technology sense) to the state > of the resources in the list. > > Perhaps the problem is that I'm not really being concrete > enough. Taking as an example location-enhanced presence > (as proposed in draft-peterson-geopriv-pres-00), let's say > that I want to subscribe to a presence list, but want to > install a filter that says, "only notify me when someone's > location changes by more than 100 miles". > > In order to do this, I generally want to include such > information in the SUBSCRIBE request itself. If we relegate > the filtering of these (possibly conceptual, non-SIP) > subscriptions to be an RLS implementation decision, doing > so becomes impossible. > OK, I clearly misunderstood the question. In fact, I am not sure I _currently_ understand the question either, as I have a hard time understanding the distinction between applying a filter to the list subscription and applying the subscription to the "conceptual" underlying subsriptions. As far as my UAC is concerned, its all the same thing, isn't it? Assuming we will have a mechanism to express a filter in a SUBSCRIBE request (delivered as a separate work item), what is missing? Is it a question of having sufficient expressivity in that mechanism to allow me to associate filter with a specific entry on a list, vs the entire list? For example, is it a question of saying "only tell me when someone moves 100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"? If this is anywhere near the question you have in mind, then I still believe it is a matter of establishing proper requirements for the filtering work item, and out of scope for this document. > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:03:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05478 for ; Mon, 24 Mar 2003 17:03:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMN8W05041 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 17:23:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMN8O05038 for ; Mon, 24 Mar 2003 17:23:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05434 for ; Mon, 24 Mar 2003 17:02:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMN2O05030; Mon, 24 Mar 2003 17:23:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMMwO04998 for ; Mon, 24 Mar 2003 17:22:58 -0500 Received: from d12lmsgate-2.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05416 for ; Mon, 24 Mar 2003 17:02:27 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2OM4b33095414; Mon, 24 Mar 2003 23:04:37 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2OM4a2g273464; Mon, 24 Mar 2003 23:04:36 +0100 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645C2@dyn-tx-exch-001.dynamicsoft.com> To: Adam Roach Cc: Ben Campbell , Jonathan Rosenberg , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/03/2003 00:04:36, Serialize complete at 25/03/2003 00:04:36 Content-Type: text/plain; charset="US-ASCII" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 00:04:33 +0200 I think that you can not do "only notify me when someone's location changes by *more than* 100 miles" with what is defined in RFC 3265. You will need to define a language etc. So why the the events lists should be stopped by this when there is no complete solution defined anyway? It might be that doing all the filtering needed in the SUBSCRIBE itself will not be possible since there might be an additional exchange of information needed in order to get the resource type and the filtering possibilities for that resource. Avshalom Adam Roach Sent by: simple-admin@ietf.org 24/03/2003 23:35 To Ben Campbell , Jonathan Rosenberg cc Adam Roach , "'simple@ietf.org'" Subject RE: [Simple] Urgent: Event Lists Open Issue Ben Campbell writes: > You have made some effort in the draft so far to be clear that the > presence of so-called "back-end" subscriptions are really an > implementation decision, and not part of the list subscription > specification. From that perspective, specifying that a list > subscription filter propagates to back-end subscriptions is > inappropriate. Assuming that back-end subscriptions exist. One list > implementation might choose to have non-filtered back-end > subscriptions, > and perform filtering locally. Another might choose to create > filters on > each back-end subscription. These filters may or may not derive from a > filter on the top list subscription. This is all up to local policy. Sorry; I'm being a bit sloppy with my terminology. You are correct in your assertion that literal back-end SIP subscriptions may or may not exist; that's an implementation decision. However, even if all the resources are controlled by a single server, you still end up having conceptual subscriptions (not SIP subscriptions, but "subscription" in the more general information technology sense) to the state of the resources in the list. Perhaps the problem is that I'm not really being concrete enough. Taking as an example location-enhanced presence (as proposed in draft-peterson-geopriv-pres-00), let's say that I want to subscribe to a presence list, but want to install a filter that says, "only notify me when someone's location changes by more than 100 miles". In order to do this, I generally want to include such information in the SUBSCRIBE request itself. If we relegate the filtering of these (possibly conceptual, non-SIP) subscriptions to be an RLS implementation decision, doing so becomes impossible. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:11:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05662 for ; Mon, 24 Mar 2003 17:11:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMV9L05365 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 17:31:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMV9O05362 for ; Mon, 24 Mar 2003 17:31:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05645 for ; Mon, 24 Mar 2003 17:10:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMV4O05337; Mon, 24 Mar 2003 17:31:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMRFO05192 for ; Mon, 24 Mar 2003 17:27:15 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05567 for ; Mon, 24 Mar 2003 17:06:44 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2OM8xTU004195 for ; Mon, 24 Mar 2003 17:08:59 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 16:09:04 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645C4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: Jonathan Rosenberg , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 16:08:59 -0600 Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > I have a hard time > understanding the distinction between applying a filter to the list > subscription and applying the subscription to the "conceptual" > underlying subsriptions. Thinking still of these conceptual underlying subscriptions, a subscription to a list creates an arbitrarily deep tree of subscriptions, in which all of the leaves are non-list resources, and all other nodes are list resources. Keeping this tree in mind, the question being posed fundamentally boils down to this: When a filter document is included in a SUBSCRIBE message to a list, which of these nodes does it apply to? a) Only the root node? b) Only the leaves? c) Everything? d) Everything but the leaves? e) Some subset of nodes not listed above? > For example, is it a question of saying "only tell me when > someone moves > 100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"? That's interesting, but not really what I had in mind. It also indicates to me that the model you had in your mind was option "b) Only the leaves". /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:14:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05739 for ; Mon, 24 Mar 2003 17:14:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMY8C05519 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 17:34:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMY8O05516 for ; Mon, 24 Mar 2003 17:34:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05722 for ; Mon, 24 Mar 2003 17:13:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMY3O05508; Mon, 24 Mar 2003 17:34:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMXkO05484 for ; Mon, 24 Mar 2003 17:33:46 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05718 for ; Mon, 24 Mar 2003 17:13:15 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2OMFTTU004198; Mon, 24 Mar 2003 17:15:30 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 16:15:34 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645C5@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Avshalom Houri'" , Adam Roach Cc: Ben Campbell , Jonathan Rosenberg , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 16:15:28 -0600 > -----Original Message----- > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > > I think that you can not do "only notify me when someone's > location changes by *more than* 100 miles" with what is > defined in RFC 3265. You will need to define a language etc. > So why the > the events lists should be stopped by this when there is no complete > solution > defined anyway? I'm not trying to define the actual filters. I'm trying to make sure that such a definition will be possible at a later date. 3265 makes certain this *can* happen by basically leaving the SUBSCRIBE bodies open for adding filters. Now, if we're describing a way to conceptually create several subscriptions all at once, we need to define *how* these filters will apply, *not* what the filters are. > It might be that doing all the filtering needed in the > SUBSCRIBE itself > will not be > possible since there might be an additional exchange of > information needed > in order > to get the resource type and the filtering possibilities for that > resource. With SUBSCRIBE in its original form, you could. The "Event" header tols you the resource type. Concrete filtering mechanisms would define the possibilities, presumably using a 415-like rejection of filter languages that aren't understood. I know that the filtering problem is difficult. I just want to make certain that the lists draft doesn't make it impossible. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:25:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06056 for ; Mon, 24 Mar 2003 17:25:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMj9006739 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 17:45:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMj9O06736 for ; Mon, 24 Mar 2003 17:45:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06048 for ; Mon, 24 Mar 2003 17:24:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMj4O06728; Mon, 24 Mar 2003 17:45:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMiJO06694 for ; Mon, 24 Mar 2003 17:44:19 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06014 for ; Mon, 24 Mar 2003 17:23:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2OMQCBd004620; Mon, 24 Mar 2003 17:26:12 -0500 (EST) Message-ID: <3E7F85F9.3010905@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: "'simple@ietf.org'" Subject: Re: [Simple] Urgent: Event Lists Open Issue References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C1@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:26:01 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > >>Filters are specific to the type of resource you are subscribing >>to. Thus, if you subscribe to a list, the filters have to know its >>a list. > > > Because of the change we decided to make in Atlanta, > the subscriber does not know whether the resource is a > list. Since the subscriber is specifying the filters, > you *can't* send one type of filter for a single resource, > and a different type for a list; you don't know which one > you're subscribing to. Right. So, that means that our filters for presence need to work for lists too. I think thats pretty easy. In the most common case, your filters are things like "dont send me geoloc" or "send me notifications only when the basic status goes to open". These kinds of filters make perfect sense for a single user subscription, and also for a list subscription. In the latter case, they simply apply to each element in the list. The only problematic case is where you want to specify different filters for each presentity. I think we need only leave hooks for such a mechanism in the filter work, and then we can work the details later. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:30:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06201 for ; Mon, 24 Mar 2003 17:30:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMolH06982 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 17:50:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMolO06979 for ; Mon, 24 Mar 2003 17:50:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06183 for ; Mon, 24 Mar 2003 17:30:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMogO06951; Mon, 24 Mar 2003 17:50:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMlIO06826 for ; Mon, 24 Mar 2003 17:47:18 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06094 for ; Mon, 24 Mar 2003 17:26:46 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2OMT5904244; Mon, 24 Mar 2003 16:29:05 -0600 Subject: RE: [Simple] Urgent: Event Lists Open Issue From: Robert Sparks To: Adam Roach Cc: Ben Campbell , Jonathan Rosenberg , "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645C4@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C4@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048544942.1869.133.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 16:29:02 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So consider this question from the perspective of the rate-limiting kind of filter. We've asserted earlier that these kinds of filters aren't event package specific, so we can carve away solutions that call to individual packages. The question then becomes do you have to be able to talk about lists when you express one of these generic rate limiting filters? If you place a "No more than once a minute" filter on a subcription to a list, are you saying A) I don't want more than one NOTIFY per minute as a result of this list subscription. or B) I don't want more than one NOTIFY per minute for any given leaf in the list/tree. I think what we have to decide first is whether the answer is always A or always B, or if the generic rate filter needs to be able to specify one of those options. RjS On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > > I have a hard time > > understanding the distinction between applying a filter to the list > > subscription and applying the subscription to the "conceptual" > > underlying subsriptions. > > Thinking still of these conceptual underlying subscriptions, > a subscription to a list creates an arbitrarily deep tree > of subscriptions, in which all of the leaves are non-list > resources, and all other nodes are list resources. > > Keeping this tree in mind, the question being posed fundamentally > boils down to this: When a filter document is included in a > SUBSCRIBE message to a list, which of these nodes does it apply to? > > a) Only the root node? > b) Only the leaves? > c) Everything? > d) Everything but the leaves? > e) Some subset of nodes not listed above? > > > For example, is it a question of saying "only tell me when > > someone moves > > 100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"? > > That's interesting, but not really what I had in mind. It also > indicates to me that the model you had in your mind was option > "b) Only the leaves". > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:30:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06210 for ; Mon, 24 Mar 2003 17:30:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMolX06998 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 17:50:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMolO06995 for ; Mon, 24 Mar 2003 17:50:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06185 for ; Mon, 24 Mar 2003 17:30:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMohO06971; Mon, 24 Mar 2003 17:50:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMmqO06868 for ; Mon, 24 Mar 2003 17:48:52 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06131 for ; Mon, 24 Mar 2003 17:28:21 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2OMUiBd004629; Mon, 24 Mar 2003 17:30:44 -0500 (EST) Message-ID: <3E7F8709.4070208@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: Robert Sparks CC: Adam Roach , Ben Campbell , "'simple@ietf.org'" Subject: Re: [Simple] Urgent: Event Lists Open Issue References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C4@dyn-tx-exch-001.dynamicsoft.com> <1048544942.1869.133.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:30:33 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The answer is A. -Jonathan R. Robert Sparks wrote: > So consider this question from the perspective of the > rate-limiting kind of filter. We've asserted earlier > that these kinds of filters aren't event package specific, > so we can carve away solutions that call to individual > packages. The question then becomes do you have to be > able to talk about lists when you express one of these > generic rate limiting filters? > > If you place a "No more than once a minute" filter on > a subcription to a list, are you saying > > A) I don't want more than one NOTIFY per minute as > a result of this list subscription. > > or > > B) I don't want more than one NOTIFY per minute for > any given leaf in the list/tree. > > I think what we have to decide first is whether the > answer is always A or always B, or if the generic rate > filter needs to be able to specify one of those options. > > > RjS > > On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > >>Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >> >> >>>I have a hard time >>>understanding the distinction between applying a filter to the list >>>subscription and applying the subscription to the "conceptual" >>>underlying subsriptions. >> >>Thinking still of these conceptual underlying subscriptions, >>a subscription to a list creates an arbitrarily deep tree >>of subscriptions, in which all of the leaves are non-list >>resources, and all other nodes are list resources. >> >>Keeping this tree in mind, the question being posed fundamentally >>boils down to this: When a filter document is included in a >>SUBSCRIBE message to a list, which of these nodes does it apply to? >> >>a) Only the root node? >>b) Only the leaves? >>c) Everything? >>d) Everything but the leaves? >>e) Some subset of nodes not listed above? >> >> >>>For example, is it a question of saying "only tell me when >>>someone moves >>>100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"? >> >>That's interesting, but not really what I had in mind. It also >>indicates to me that the model you had in your mind was option >>"b) Only the leaves". >> >>/a >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:31:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06244 for ; Mon, 24 Mar 2003 17:31:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMp6X07047 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 17:51:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMp6O07044 for ; Mon, 24 Mar 2003 17:51:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06194 for ; Mon, 24 Mar 2003 17:30:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMp1O07032; Mon, 24 Mar 2003 17:51:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMoHO06922 for ; Mon, 24 Mar 2003 17:50:17 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06164 for ; Mon, 24 Mar 2003 17:29:45 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2OMW0TU004217 for ; Mon, 24 Mar 2003 17:32:00 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 16:32:05 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645C7@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Robert Sparks Cc: Adam Roach , Ben Campbell , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 16:31:55 -0600 But only for rate limiting. Think about other kinds of filters. /a > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, March 24, 2003 16:31 > To: Robert Sparks > Cc: Adam Roach; Ben Campbell; 'simple@ietf.org' > Subject: Re: [Simple] Urgent: Event Lists Open Issue > > > The answer is A. > > -Jonathan R. > > Robert Sparks wrote: > > So consider this question from the perspective of the > > rate-limiting kind of filter. We've asserted earlier > > that these kinds of filters aren't event package specific, > > so we can carve away solutions that call to individual > > packages. The question then becomes do you have to be > > able to talk about lists when you express one of these > > generic rate limiting filters? > > > > If you place a "No more than once a minute" filter on > > a subcription to a list, are you saying > > > > A) I don't want more than one NOTIFY per minute as > > a result of this list subscription. > > > > or > > > > B) I don't want more than one NOTIFY per minute for > > any given leaf in the list/tree. > > > > I think what we have to decide first is whether the > > answer is always A or always B, or if the generic rate > > filter needs to be able to specify one of those options. > > > > > > RjS > > > > On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > > > >>Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > >> > >> > >>>I have a hard time > >>>understanding the distinction between applying a filter to the list > >>>subscription and applying the subscription to the "conceptual" > >>>underlying subsriptions. > >> > >>Thinking still of these conceptual underlying subscriptions, > >>a subscription to a list creates an arbitrarily deep tree > >>of subscriptions, in which all of the leaves are non-list > >>resources, and all other nodes are list resources. > >> > >>Keeping this tree in mind, the question being posed fundamentally > >>boils down to this: When a filter document is included in a > >>SUBSCRIBE message to a list, which of these nodes does it apply to? > >> > >>a) Only the root node? > >>b) Only the leaves? > >>c) Everything? > >>d) Everything but the leaves? > >>e) Some subset of nodes not listed above? > >> > >> > >>>For example, is it a question of saying "only tell me when > >>>someone moves > >>>100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"? > >> > >>That's interesting, but not really what I had in mind. It also > >>indicates to me that the model you had in your mind was option > >>"b) Only the leaves". > >> > >>/a > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:46:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06697 for ; Mon, 24 Mar 2003 17:46:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ON6AF07785 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 18:06:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON6AO07782 for ; Mon, 24 Mar 2003 18:06:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06681 for ; Mon, 24 Mar 2003 17:45:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON63O07771; Mon, 24 Mar 2003 18:06:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMxnO07458 for ; Mon, 24 Mar 2003 17:59:49 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06565 for ; Mon, 24 Mar 2003 17:39:17 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2OMfZ904527; Mon, 24 Mar 2003 16:41:35 -0600 Subject: RE: [Simple] Urgent: Event Lists Open Issue From: Robert Sparks To: Adam Roach Cc: Jonathan Rosenberg , Ben Campbell , "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645C7@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C7@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048545692.1249.143.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 16:41:32 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm not convinced the answer is always A for rate limiting. More on that below. For other kinds of filters, particularly those based on filtering content, the burden _has_ to live in the definition of the filter. I'm not sure yet whether that means a filter has to be list agnostic. It may be that a filter can express "Do this if you are a list, otherwise do that". Back to rate limiting. The effect of A below for presence is that if 10 of my buddies happen to change their presence state about the same time (which happens frequently at the end of meetings), I won't find out about one of them until at least 10 minutes later. This points out value in being able to assert B as the right thing to do. RjS On Mon, 2003-03-24 at 16:31, Adam Roach wrote: > But only for rate limiting. Think about other kinds of filters. > > /a > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Monday, March 24, 2003 16:31 > > To: Robert Sparks > > Cc: Adam Roach; Ben Campbell; 'simple@ietf.org' > > Subject: Re: [Simple] Urgent: Event Lists Open Issue > > > > > > The answer is A. > > > > -Jonathan R. > > > > Robert Sparks wrote: > > > So consider this question from the perspective of the > > > rate-limiting kind of filter. We've asserted earlier > > > that these kinds of filters aren't event package specific, > > > so we can carve away solutions that call to individual > > > packages. The question then becomes do you have to be > > > able to talk about lists when you express one of these > > > generic rate limiting filters? > > > > > > If you place a "No more than once a minute" filter on > > > a subcription to a list, are you saying > > > > > > A) I don't want more than one NOTIFY per minute as > > > a result of this list subscription. > > > > > > or > > > > > > B) I don't want more than one NOTIFY per minute for > > > any given leaf in the list/tree. > > > > > > I think what we have to decide first is whether the > > > answer is always A or always B, or if the generic rate > > > filter needs to be able to specify one of those options. > > > > > > > > > RjS > > > > > > On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > > > > > >>Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > >> > > >> > > >>>I have a hard time > > >>>understanding the distinction between applying a filter to the list > > >>>subscription and applying the subscription to the "conceptual" > > >>>underlying subsriptions. > > >> > > >>Thinking still of these conceptual underlying subscriptions, > > >>a subscription to a list creates an arbitrarily deep tree > > >>of subscriptions, in which all of the leaves are non-list > > >>resources, and all other nodes are list resources. > > >> > > >>Keeping this tree in mind, the question being posed fundamentally > > >>boils down to this: When a filter document is included in a > > >>SUBSCRIBE message to a list, which of these nodes does it apply to? > > >> > > >>a) Only the root node? > > >>b) Only the leaves? > > >>c) Everything? > > >>d) Everything but the leaves? > > >>e) Some subset of nodes not listed above? > > >> > > >> > > >>>For example, is it a question of saying "only tell me when > > >>>someone moves > > >>>100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"? > > >> > > >>That's interesting, but not really what I had in mind. It also > > >>indicates to me that the model you had in your mind was option > > >>"b) Only the leaves". > > >> > > >>/a > > >>_______________________________________________ > > >>Simple mailing list > > >>Simple@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Scientist Parsippany, NJ 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:49:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06791 for ; Mon, 24 Mar 2003 17:49:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ON9Kn08703 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 18:09:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON9KO08700 for ; Mon, 24 Mar 2003 18:09:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06760 for ; Mon, 24 Mar 2003 17:48:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON9FO08678; Mon, 24 Mar 2003 18:09:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON2pO07596 for ; Mon, 24 Mar 2003 18:02:51 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06598 for ; Mon, 24 Mar 2003 17:42:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2OMihBd004636; Mon, 24 Mar 2003 17:44:43 -0500 (EST) Message-ID: <3E7F8A50.80105@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: Robert Sparks CC: Adam Roach , Ben Campbell , "'simple@ietf.org'" Subject: Re: [Simple] Urgent: Event Lists Open Issue References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C7@dyn-tx-exch-001.dynamicsoft.com> <1048545692.1249.143.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:44:32 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Sparks wrote: > For other kinds of filters, particularly those based on filtering > content, the burden _has_ to live in the definition of the filter. > I'm not sure yet whether that means a filter has to be list agnostic. > It may be that a filter can express "Do this if you are a list, > otherwise do that". I still assert that for the most common cases, you will want to apply the same filter across all users in the list. In the cases where you dont, the filter mechanism merely needs to provide the ability to specify per-user filters. > > Back to rate limiting. The effect of A below for presence is that > if 10 of my buddies happen to change their presence state about > the same time (which happens frequently at the end of meetings), > I won't find out about one of them until at least 10 minutes later. > > This points out value in being able to assert B as the right thing > to do. Its the same point as above. A baseline rate limiting mechanism will work for lists and single user presentities. It may not be sufficient for all list subscriptions, in whcih case we could define additional rate limiting mechanisms that define behavior on a per-user basis. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:57:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07190 for ; Mon, 24 Mar 2003 17:57:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONH9Z09188 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 18:17:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONH9O09185 for ; Mon, 24 Mar 2003 18:17:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07130 for ; Mon, 24 Mar 2003 17:56:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONH4O09111; Mon, 24 Mar 2003 18:17:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONASO08759 for ; Mon, 24 Mar 2003 18:10:28 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06825 for ; Mon, 24 Mar 2003 17:49:56 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2OMqBTU004272 for ; Mon, 24 Mar 2003 17:52:11 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 16:52:15 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645C9@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , Adam Roach Cc: Jonathan Rosenberg , Ben Campbell , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 16:52:11 -0600 > Back to rate limiting. The effect of A below for presence is that > if 10 of my buddies happen to change their presence state about > the same time (which happens frequently at the end of meetings), > I won't find out about one of them until at least 10 minutes later. > > This points out value in being able to assert B as the right thing > to do. Actually, that seems to me to just point out that the rate-limiting solution needs to be "average over some period", not "absolute". (This is in reference to the filtering dicussion on the topic, not worth rehashing here). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 17:57:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07204 for ; Mon, 24 Mar 2003 17:57:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONHCf09208 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 18:17:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONHCO09203 for ; Mon, 24 Mar 2003 18:17:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07136 for ; Mon, 24 Mar 2003 17:56:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONH7O09148; Mon, 24 Mar 2003 18:17:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON8vO08641 for ; Mon, 24 Mar 2003 18:08:57 -0500 Received: from d12lmsgate-2.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06753 for ; Mon, 24 Mar 2003 17:48:24 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2OMob33032910; Mon, 24 Mar 2003 23:50:37 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2OMoX2g171426; Mon, 24 Mar 2003 23:50:34 +0100 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645C5@dyn-tx-exch-001.dynamicsoft.com> MIME-Version: 1.0 To: Adam Roach Cc: "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/03/2003 00:50:33, Serialize complete at 25/03/2003 00:50:33 Content-Type: text/plain; charset="US-ASCII" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 00:50:31 +0200 Inline. simple-admin@ietf.org wrote on 25/03/2003 00:15:28: > > -----Original Message----- > > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > > > > I think that you can not do "only notify me when someone's > > location changes by *more than* 100 miles" with what is > > defined in RFC 3265. You will need to define a language etc. > > So why the > > the events lists should be stopped by this when there is no complete > > solution > > defined anyway? > > I'm not trying to define the actual filters. > > I'm trying to make sure that such a definition will > be possible at a later date. > > 3265 makes certain this *can* happen by basically leaving > the SUBSCRIBE bodies open for adding filters. > > Now, if we're describing a way to conceptually create > several subscriptions all at once, we need to define > *how* these filters will apply, *not* what the filters > are. > I am not sure that we can separate the two. Part of the filters definitions might be their applicability. As in the example you sent to Ben: a) Only the root node? b) Only the leaves? c) Everything? d) Everything but the leaves? e) Some subset of nodes not listed above? Part of the filter definition can be the subset that the filter applies to. > > It might be that doing all the filtering needed in the > > SUBSCRIBE itself > > will not be > > possible since there might be an additional exchange of > > information needed > > in order > > to get the resource type and the filtering possibilities for that > > resource. > > With SUBSCRIBE in its original form, you could. > The "Event" header tells you the resource type. > Concrete filtering mechanisms would define the > possibilities, presumably using a 415-like > rejection of filter languages that aren't understood. > > I know that the filtering problem is difficult. > I just want to make certain that the lists draft > doesn't make it impossible. > What I tried to say is that I assume that the filtering draft will need to define a new method in order to enable the filtering. For example a user will send a method to get the filter properties of a resource before sending the actual SUBSCRIBE. It am afraid that it might get even further then that. The filtering in RFC3265 is syntactic filtering "byte-by-byte" as the draft says. We can not assume that this kind of filtering can be applicable also to lists and probably other complex objects that might come in the future. > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 18:04:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07635 for ; Mon, 24 Mar 2003 18:04:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONO9R09814 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 18:24:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONO8O09811 for ; Mon, 24 Mar 2003 18:24:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07558 for ; Mon, 24 Mar 2003 18:03:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONO3O09801; Mon, 24 Mar 2003 18:24:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONO0O09787 for ; Mon, 24 Mar 2003 18:24:00 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07535 for ; Mon, 24 Mar 2003 18:03:26 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2ON5fTU004282 for ; Mon, 24 Mar 2003 18:05:41 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 17:05:46 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645CA@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , Adam Roach Cc: Jonathan Rosenberg , Ben Campbell , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:05:39 -0600 > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > For other kinds of filters, particularly those based on filtering > content, the burden _has_ to live in the definition of the filter. > I'm not sure yet whether that means a filter has to be list agnostic. > It may be that a filter can express "Do this if you are a list, > otherwise do that". I was composing a note along the same lines, but you said it far more succinctly. Actually, my example was going to keep the list-agnostic property, and suggest that you could specify two filters in a multipart body: one filter applied to the list resources, and another applied to the non-list resources. I think it is important that we be able to keep the list stuff out of the filters themselves. The filtering work is bubbling up all over: SIP, XMPP, LEMONADE, WEBDAV... it looks very much like there would be *great* benefit to coordinating te filtering work and re-using it in a bunch of places. If we make the filter syntax list-aware, we might have a harder time fostering such re-use. Using a multipart body in the way I describe would eliminate such a barrier. If this sounds good, then the only provision we need to add to the current lists draft is some mechanism for indicating which body part applies to lists, and which applies to non-lists. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 18:07:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08140 for ; Mon, 24 Mar 2003 18:07:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONR6o09935 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 18:27:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONR6O09932 for ; Mon, 24 Mar 2003 18:27:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08044 for ; Mon, 24 Mar 2003 18:06:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONR2O09920; Mon, 24 Mar 2003 18:27:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONQmO09892 for ; Mon, 24 Mar 2003 18:26:48 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07961 for ; Mon, 24 Mar 2003 18:06:15 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2ON8S904975; Mon, 24 Mar 2003 17:08:28 -0600 Subject: Re: [Simple] Urgent: Event Lists Open Issue From: Robert Sparks To: Jonathan Rosenberg Cc: Adam Roach , Ben Campbell , "'simple@ietf.org'" In-Reply-To: <3E7F8A50.80105@dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C7@dyn-tx-exch-001.dynamicsoft.com> <1048545692.1249.143.camel@RjS.localdomain> <3E7F8A50.80105@dynamicsoft.com> Content-Type: text/plain Message-Id: <1048547304.1249.156.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 17:08:25 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-03-24 at 16:44, Jonathan Rosenberg wrote: > Robert Sparks wrote: > > > For other kinds of filters, particularly those based on filtering > > content, the burden _has_ to live in the definition of the filter. > > I'm not sure yet whether that means a filter has to be list agnostic. > > It may be that a filter can express "Do this if you are a list, > > otherwise do that". > > I still assert that for the most common cases, you will want to apply > the same filter across all users in the list. In the cases where you > dont, the filter mechanism merely needs to provide the ability to > specify per-user filters. > > > > > Back to rate limiting. The effect of A below for presence is that > > if 10 of my buddies happen to change their presence state about > > the same time (which happens frequently at the end of meetings), > > I won't find out about one of them until at least 10 minutes later. > > > > This points out value in being able to assert B as the right thing > > to do. > > Its the same point as above. A baseline rate limiting mechanism will > work for lists and single user presentities. It may not be sufficient > for all list subscriptions, in whcih case we could define additional > rate limiting mechanisms that define behavior on a per-user basis. > So are you saying, then, that the default behavior is A (from earlier) but that we need to pass a requirement to sipping to be able to express a choice for B for the baseline rate limiting mechanism? Or are you saying that the baseline behavior is A, not matter what, and that if you want B behavior, you have to specify it in a package specific filter document? RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 18:55:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10133 for ; Mon, 24 Mar 2003 18:55:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0FAO12963 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 19:15:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0FAO12960 for ; Mon, 24 Mar 2003 19:15:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10122 for ; Mon, 24 Mar 2003 18:54:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0F4O12952; Mon, 24 Mar 2003 19:15:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0EBO12893 for ; Mon, 24 Mar 2003 19:14:11 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10101 for ; Mon, 24 Mar 2003 18:53:36 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2ONtr905652; Mon, 24 Mar 2003 17:55:53 -0600 Subject: RE: [Simple] Urgent: Event Lists Open Issue From: Ben Campbell To: Adam Roach Cc: Jonathan Rosenberg , "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645C4@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C4@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048550081.1525.47.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 17:54:41 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > > I have a hard time > > understanding the distinction between applying a filter to the list > > subscription and applying the subscription to the "conceptual" > > underlying subsriptions. > > Thinking still of these conceptual underlying subscriptions, > a subscription to a list creates an arbitrarily deep tree > of subscriptions, in which all of the leaves are non-list > resources, and all other nodes are list resources. > > Keeping this tree in mind, the question being posed fundamentally > boils down to this: When a filter document is included in a > SUBSCRIBE message to a list, which of these nodes does it apply to? > > a) Only the root node? > b) Only the leaves? > c) Everything? > d) Everything but the leaves? > e) Some subset of nodes not listed above? > > > For example, is it a question of saying "only tell me when > > someone moves > > 100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"? > > That's interesting, but not really what I had in mind. It also > indicates to me that the model you had in your mind was option > "b) Only the leaves". > No, actually what I had in mind was "a) Only the root.". Maybe my disconnect is it still feels that the only rational model is "A) only the root", and options B and C are, among others, possible mechanisms the root can use to implement that. (Which, by the way, seems to take us back to my first response.) Since we seem to be talking _way_ past each other, let me extend your concrete example. If I only want to see notifies that involve a 100 mi or more change in geoloc, I express that on my SUBSCRIBE request to the list. Now, the list server could go about that in a number of ways. It could delegate subscriptions for each list entry (with real or conceptual subscriptions), and only pass through notifications when the threshold is reached. This seems like a clear case of option a). Now, it could also do this by attaching a derived filter to each delegated subscription, so that _it_ only sees the changes that match the rule, and passes them all on to the watcher. That would _seem_ like option B. But from the watcher's perspective, these two approaches should be indistinguishable. I guess my point is, it seems to me this should be specified based on what goes into the root subscription, and what comes back out--which should be doable without explicitly dealing with filters in the list draft, just as it is without explicitly reving 3265. > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 19:02:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10415 for ; Mon, 24 Mar 2003 19:02:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0MH913307 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 19:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0MHO13304 for ; Mon, 24 Mar 2003 19:22:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10361 for ; Mon, 24 Mar 2003 19:01:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0MDO13273; Mon, 24 Mar 2003 19:22:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0J3O13120 for ; Mon, 24 Mar 2003 19:19:03 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10232 for ; Mon, 24 Mar 2003 18:58:29 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2P00g905732; Mon, 24 Mar 2003 18:00:42 -0600 Subject: RE: [Simple] Urgent: Event Lists Open Issue From: Ben Campbell To: Robert Sparks Cc: Adam Roach , Jonathan Rosenberg , "'simple@ietf.org'" In-Reply-To: <1048544942.1869.133.camel@RjS.localdomain> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645C4@dyn-tx-exch-001.dynamicsoft.com> <1048544942.1869.133.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1048550369.1525.52.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 17:59:29 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-03-24 at 16:29, Robert Sparks wrote: > So consider this question from the perspective of the > rate-limiting kind of filter. We've asserted earlier > that these kinds of filters aren't event package specific, > so we can carve away solutions that call to individual > packages. The question then becomes do you have to be > able to talk about lists when you express one of these > generic rate limiting filters? > > If you place a "No more than once a minute" filter on > a subcription to a list, are you saying > > A) I don't want more than one NOTIFY per minute as > a result of this list subscription. > > or > > B) I don't want more than one NOTIFY per minute for > any given leaf in the list/tree. > > I think what we have to decide first is whether the > answer is always A or always B, or if the generic rate > filter needs to be able to specify one of those options. > OK, I can buy that--but that example is of exactly the same form as one I gave for geoloc, to which Adam responded that was not the question. So, how is that question different from saying " Notify me whenever any list member moves 100 mi" vs "Notify me when a particular member moves more than 100 mi"? The problem underlying both of our examples seems to be one of filter rule expressivity, and I don't understand why that decision needs to be made in the list draft. > > RjS > > On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > > > > I have a hard time > > > understanding the distinction between applying a filter to the list > > > subscription and applying the subscription to the "conceptual" > > > underlying subsriptions. > > > > Thinking still of these conceptual underlying subscriptions, > > a subscription to a list creates an arbitrarily deep tree > > of subscriptions, in which all of the leaves are non-list > > resources, and all other nodes are list resources. > > > > Keeping this tree in mind, the question being posed fundamentally > > boils down to this: When a filter document is included in a > > SUBSCRIBE message to a list, which of these nodes does it apply to? > > > > a) Only the root node? > > b) Only the leaves? > > c) Everything? > > d) Everything but the leaves? > > e) Some subset of nodes not listed above? > > > > > For example, is it a question of saying "only tell me when > > > someone moves > > > 100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"? > > > > That's interesting, but not really what I had in mind. It also > > indicates to me that the model you had in your mind was option > > "b) Only the leaves". > > > > /a > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 19:02:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10427 for ; Mon, 24 Mar 2003 19:02:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0MIG13323 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 19:22:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0MIO13320 for ; Mon, 24 Mar 2003 19:22:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10363 for ; Mon, 24 Mar 2003 19:01:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0MEO13295; Mon, 24 Mar 2003 19:22:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0JVO13136 for ; Mon, 24 Mar 2003 19:19:31 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10260 for ; Mon, 24 Mar 2003 18:58:57 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2P01CTU004435 for ; Mon, 24 Mar 2003 19:01:12 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 18:01:17 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645CB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: Jonathan Rosenberg , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 18:01:15 -0600 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Now, it could also do this by attaching a derived filter to each > delegated subscription, so that _it_ only sees the changes that match > the rule, and passes them all on to the watcher. That would > _seem_ like > option B. But from the watcher's perspective, these two approaches > should be indistinguishable. For this example, yes. Think more closely about the example Robert gives, in which the difference is not just detectable, but also substantial. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 19:11:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10668 for ; Mon, 24 Mar 2003 19:11:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0VB913745 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 19:31:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0VBO13742 for ; Mon, 24 Mar 2003 19:31:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10661 for ; Mon, 24 Mar 2003 19:10:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0V6O13734; Mon, 24 Mar 2003 19:31:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0UDO13696 for ; Mon, 24 Mar 2003 19:30:13 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10645 for ; Mon, 24 Mar 2003 19:09:38 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2P0BrTU004457 for ; Mon, 24 Mar 2003 19:11:53 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 18:11:58 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645CC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: Jonathan Rosenberg , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 18:11:47 -0600 After some further reflection, I think I see the disconnect here. When I say "applied to the root only", you're still thinking of what I mean by "applied to everything". The type of filter that would be "applied to the root only" or "applied to non-leaves only" would be something along the lines of "inform me only when the 'state' attribute of an element transitions from 'active' to 'terminated'". (Visual aid: example at the top of page 13 of draft-ietf-simple-event-list-00) The point of my "tell me when someone moves by more than 100 miles" example is that this is exactly the sort of filter that CANNOT be applied to the root node, only to leaf nodes. /a > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, March 24, 2003 17:55 > To: Adam Roach > Cc: Jonathan Rosenberg; 'simple@ietf.org' > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > > > > I have a hard time > > > understanding the distinction between applying a filter > to the list > > > subscription and applying the subscription to the "conceptual" > > > underlying subsriptions. > > > > Thinking still of these conceptual underlying subscriptions, > > a subscription to a list creates an arbitrarily deep tree > > of subscriptions, in which all of the leaves are non-list > > resources, and all other nodes are list resources. > > > > Keeping this tree in mind, the question being posed fundamentally > > boils down to this: When a filter document is included in a > > SUBSCRIBE message to a list, which of these nodes does it apply to? > > > > a) Only the root node? > > b) Only the leaves? > > c) Everything? > > d) Everything but the leaves? > > e) Some subset of nodes not listed above? > > > > > For example, is it a question of saying "only tell me when > > > someone moves > > > 100 miles" vs. "Tell me when Alice moves 50 mi or Bob > moves 75 mi"? > > > > That's interesting, but not really what I had in mind. It also > > indicates to me that the model you had in your mind was option > > "b) Only the leaves". > > > > No, actually what I had in mind was "a) Only the root.". > > Maybe my disconnect is it still feels that the only rational model is > "A) only the root", and options B and C are, among others, possible > mechanisms the root can use to implement that. (Which, by the > way, seems > to take us back to my first response.) > > Since we seem to be talking _way_ past each other, let me extend your > concrete example. If I only want to see notifies that involve a 100 mi > or more change in geoloc, I express that on my SUBSCRIBE > request to the > list. Now, the list server could go about that in a number of ways. It > could delegate subscriptions for each list entry (with real or > conceptual subscriptions), and only pass through > notifications when the > threshold is reached. This seems like a clear case of option a). > > Now, it could also do this by attaching a derived filter to each > delegated subscription, so that _it_ only sees the changes that match > the rule, and passes them all on to the watcher. That would > _seem_ like > option B. But from the watcher's perspective, these two approaches > should be indistinguishable. > > I guess my point is, it seems to me this should be specified based on > what goes into the root subscription, and what comes back out--which > should be doable without explicitly dealing with filters in the list > draft, just as it is without explicitly reving 3265. > > > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 19:24:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10962 for ; Mon, 24 Mar 2003 19:24:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0iY415078 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 19:44:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0iYO15075 for ; Mon, 24 Mar 2003 19:44:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10938 for ; Mon, 24 Mar 2003 19:24:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0iTO15067; Mon, 24 Mar 2003 19:44:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0fNO14923 for ; Mon, 24 Mar 2003 19:41:23 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10879 for ; Mon, 24 Mar 2003 19:20:50 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2P0N7906051; Mon, 24 Mar 2003 18:23:07 -0600 Subject: RE: [Simple] Urgent: Event Lists Open Issue From: Ben Campbell To: Adam Roach Cc: Jonathan Rosenberg , "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645CC@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645CC@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048551761.1525.58.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 18:22:41 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Actually, the disconnect was a question of where the rule is executed vs. expressing what a particular rule applies to. I originally thought the latter, redirected myself to the former, and now have come full circle in believing we are talking about the latter. On Mon, 2003-03-24 at 18:11, Adam Roach wrote: > After some further reflection, I think I see the disconnect > here. > > When I say "applied to the root only", you're still thinking > of what I mean by "applied to everything". > > The type of filter that would be "applied to the root only" > or "applied to non-leaves only" would be something along > the lines of "inform me only when the 'state' attribute of an > element transitions from 'active' to 'terminated'". > (Visual aid: example at the top of page 13 of > draft-ietf-simple-event-list-00) > > The point of my "tell me when someone moves by more than 100 > miles" example is that this is exactly the sort of filter > that CANNOT be applied to the root node, only to leaf nodes. > > /a > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Monday, March 24, 2003 17:55 > > To: Adam Roach > > Cc: Jonathan Rosenberg; 'simple@ietf.org' > > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > > > > On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > > > > > > I have a hard time > > > > understanding the distinction between applying a filter > > to the list > > > > subscription and applying the subscription to the "conceptual" > > > > underlying subsriptions. > > > > > > Thinking still of these conceptual underlying subscriptions, > > > a subscription to a list creates an arbitrarily deep tree > > > of subscriptions, in which all of the leaves are non-list > > > resources, and all other nodes are list resources. > > > > > > Keeping this tree in mind, the question being posed fundamentally > > > boils down to this: When a filter document is included in a > > > SUBSCRIBE message to a list, which of these nodes does it apply to? > > > > > > a) Only the root node? > > > b) Only the leaves? > > > c) Everything? > > > d) Everything but the leaves? > > > e) Some subset of nodes not listed above? > > > > > > > For example, is it a question of saying "only tell me when > > > > someone moves > > > > 100 miles" vs. "Tell me when Alice moves 50 mi or Bob > > moves 75 mi"? > > > > > > That's interesting, but not really what I had in mind. It also > > > indicates to me that the model you had in your mind was option > > > "b) Only the leaves". > > > > > > > No, actually what I had in mind was "a) Only the root.". > > > > Maybe my disconnect is it still feels that the only rational model is > > "A) only the root", and options B and C are, among others, possible > > mechanisms the root can use to implement that. (Which, by the > > way, seems > > to take us back to my first response.) > > > > Since we seem to be talking _way_ past each other, let me extend your > > concrete example. If I only want to see notifies that involve a 100 mi > > or more change in geoloc, I express that on my SUBSCRIBE > > request to the > > list. Now, the list server could go about that in a number of ways. It > > could delegate subscriptions for each list entry (with real or > > conceptual subscriptions), and only pass through > > notifications when the > > threshold is reached. This seems like a clear case of option a). > > > > Now, it could also do this by attaching a derived filter to each > > delegated subscription, so that _it_ only sees the changes that match > > the rule, and passes them all on to the watcher. That would > > _seem_ like > > option B. But from the watcher's perspective, these two approaches > > should be indistinguishable. > > > > I guess my point is, it seems to me this should be specified based on > > what goes into the root subscription, and what comes back out--which > > should be doable without explicitly dealing with filters in the list > > draft, just as it is without explicitly reving 3265. > > > > > > > /a > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 19:34:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11237 for ; Mon, 24 Mar 2003 19:34:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0sEw15386 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 19:54:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0sEO15383 for ; Mon, 24 Mar 2003 19:54:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11190 for ; Mon, 24 Mar 2003 19:33:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0s5O15375; Mon, 24 Mar 2003 19:54:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0rZO15335 for ; Mon, 24 Mar 2003 19:53:35 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11181 for ; Mon, 24 Mar 2003 19:33:02 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2P0ZI906238; Mon, 24 Mar 2003 18:35:19 -0600 Subject: RE: [Simple] Urgent: Event Lists Open Issue From: Ben Campbell To: Adam Roach Cc: Robert Sparks , Jonathan Rosenberg , "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645CA@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645CA@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048552477.1523.70.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 18:34:37 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-03-24 at 17:05, Adam Roach wrote: > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > For other kinds of filters, particularly those based on filtering > > content, the burden _has_ to live in the definition of the filter. > > I'm not sure yet whether that means a filter has to be list agnostic. > > It may be that a filter can express "Do this if you are a list, > > otherwise do that". > > I was composing a note along the same lines, but you said it far more > succinctly. > > Actually, my example was going to keep the list-agnostic property, > and suggest that you could specify two filters in a multipart > body: one filter applied to the list resources, and another > applied to the non-list resources. > I think the rule expression language should be agnostic to the mechanics of list subscriptions, but it should _not_ assume that a given subscription (and its resulting ruleset) is only about a particular presentity. For example, I would like to be able to express that a rule applies to Bob. Also, I would like to be able to express that a rule applies to everybody, or everybody in a domain, etc. If you do that right, it ought to be equally applicable for a list subsription and a scaler subscription. If I express a rule to apply to everyone, that means all resources that show up in the tree. If I have a scaler subscription, my tree is trivial. If I want a rule to apply to Bob, then for a scaler subscription to Bob, it works fine. For a scaler subscription to Carol, it is meaningless. For a list subscription in which Bob shows up _anywhere_ in the tree, it applies to Bob. Note that this does not require the rule language to have any concept of the tree structure, or how lists work. It only requires a rule language that accepts the idea of a 1 to many relationship between subcriptions and presentities. Now, if such a rule language existed, it seems to me the only thing that the list draft needs to specify is that a ruleset may be delivered in the body of a SUBSCRIBE request. > I think it is important that we be able to keep the list stuff out > of the filters themselves. The filtering work is bubbling up all > over: SIP, XMPP, LEMONADE, WEBDAV... it looks very much like there > would be *great* benefit to coordinating te filtering work and > re-using it in a bunch of places. > > If we make the filter syntax list-aware, we might have a harder > time fostering such re-use. Using a multipart body in the way > I describe would eliminate such a barrier. > > If this sounds good, then the only provision we need to add > to the current lists draft is some mechanism for indicating > which body part applies to lists, and which applies to non-lists. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 19:43:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11503 for ; Mon, 24 Mar 2003 19:43:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P13B815723 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 20:03:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P13AO15720 for ; Mon, 24 Mar 2003 20:03:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11482 for ; Mon, 24 Mar 2003 19:42:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P134O15710; Mon, 24 Mar 2003 20:03:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P12YO15693 for ; Mon, 24 Mar 2003 20:02:34 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11465 for ; Mon, 24 Mar 2003 19:42:00 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2P0iDTU004480 for ; Mon, 24 Mar 2003 19:44:13 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 18:44:18 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645D0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: Robert Sparks , Jonathan Rosenberg , "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 18:44:16 -0600 Yes, I think that's where we're getting. The key distinction I was trying to make below is that we almost certainly do *not* want to add the ability to say "inform me only when the 'state' attribute of an element transitions from 'active' to 'terminated'" to the language that tells us how to filter presence. And the one that tells us how to filter registrations. And the one that tells us how to filter dialog state. And the one that tells us how to filter SPIRITS. And the one that tells us how to filter phoneconfig. And the one that tells us how to filter MWI. And the one that tells us how to filter winfo. And the one that tells us how to filter signalled digits. And the one that tells us how to filter... See where I'm going? /a > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, March 24, 2003 18:35 > To: Adam Roach > Cc: Robert Sparks; Jonathan Rosenberg; 'simple@ietf.org' > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > > > On Mon, 2003-03-24 at 17:05, Adam Roach wrote: > > > -----Original Message----- > > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > > > For other kinds of filters, particularly those based on filtering > > > content, the burden _has_ to live in the definition of the filter. > > > I'm not sure yet whether that means a filter has to be > list agnostic. > > > It may be that a filter can express "Do this if you are a list, > > > otherwise do that". > > > > I was composing a note along the same lines, but you said > it far more > > succinctly. > > > > Actually, my example was going to keep the list-agnostic property, > > and suggest that you could specify two filters in a multipart > > body: one filter applied to the list resources, and another > > applied to the non-list resources. > > > > I think the rule expression language should be agnostic to > the mechanics > of list subscriptions, but it should _not_ assume that a given > subscription (and its resulting ruleset) is only about a particular > presentity. > > For example, I would like to be able to express that a rule applies to > Bob. Also, I would like to be able to express that a rule applies to > everybody, or everybody in a domain, etc. > > If you do that right, it ought to be equally applicable for a list > subsription and a scaler subscription. If I express a rule to apply to > everyone, that means all resources that show up in the tree. > If I have a > scaler subscription, my tree is trivial. If I want a rule to apply to > Bob, then for a scaler subscription to Bob, it works fine. > For a scaler > subscription to Carol, it is meaningless. For a list subscription in > which Bob shows up _anywhere_ in the tree, it applies to Bob. > Note that > this does not require the rule language to have any concept > of the tree > structure, or how lists work. It only requires a rule language that > accepts the idea of a 1 to many relationship between subcriptions and > presentities. > > Now, if such a rule language existed, it seems to me the only > thing that > the list draft needs to specify is that a ruleset may be delivered in > the body of a SUBSCRIBE request. > > > I think it is important that we be able to keep the list stuff out > > of the filters themselves. The filtering work is bubbling up all > > over: SIP, XMPP, LEMONADE, WEBDAV... it looks very much like there > > would be *great* benefit to coordinating te filtering work and > > re-using it in a bunch of places. > > > > If we make the filter syntax list-aware, we might have a harder > > time fostering such re-use. Using a multipart body in the way > > I describe would eliminate such a barrier. > > > > If this sounds good, then the only provision we need to add > > to the current lists draft is some mechanism for indicating > > which body part applies to lists, and which applies to non-lists. > > > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 20:59:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13507 for ; Mon, 24 Mar 2003 20:59:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P2JH621274 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 21:19:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2JHO21271 for ; Mon, 24 Mar 2003 21:19:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13477 for ; Mon, 24 Mar 2003 20:58:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2JAO21262; Mon, 24 Mar 2003 21:19:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2IiO21158 for ; Mon, 24 Mar 2003 21:18:44 -0500 Received: from web41504.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13443 for ; Mon, 24 Mar 2003 20:58:08 -0500 (EST) Message-ID: <20030325020027.84011.qmail@web41504.mail.yahoo.com> Received: from [207.46.225.252] by web41504.mail.yahoo.com via HTTP; Mon, 24 Mar 2003 18:00:27 PST From: Sean Olson Subject: RE: [Simple] Urgent: Event Lists Open Issue To: Adam Roach , Ben Campbell Cc: Robert Sparks , Jonathan Rosenberg , "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645D0@dyn-tx-exch-001.dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 18:00:27 -0800 (PST) The unfortunate consequence of this is that the filter you place in a subscription needs to be complete in the sense that it filters out anything you might possibly not want to see because if you happen to unknowingly subscribe to a list, you might very well get back something you did not expect (a leaf). Thus filters will get long and complex and you will probably need a better mechanism for managing filters than SUBSCRIBE itself leading to even more protocol machinery that was supposed to simplify the life of the client, not complicate it. Filters must be designed with hierarchy in mind and must allow "everything but" and "nothing but" definitions. Hmmmm.... sounds like a job for LISP. --- Adam Roach wrote: > Yes, I think that's where we're getting. > > The key distinction I was trying to make below is > that we > almost certainly do *not* want to add the ability to > say > "inform me only when the 'state' attribute of an > > element transitions from 'active' to 'terminated'" > to the > language that tells us how to filter presence. And > the one that > tells us how to filter registrations. And the one > that tells > us how to filter dialog state. And the one that > tells us how > to filter SPIRITS. And the one that tells us how to > filter > phoneconfig. And the one that tells us how to filter > MWI. > And the one that tells us how to filter winfo. And > the one > that tells us how to filter signalled digits. And > the one > that tells us how to filter... > > See where I'm going? > > /a > > > -----Original Message----- > > From: Ben Campbell > [mailto:bcampbell@dynamicsoft.com] > > Sent: Monday, March 24, 2003 18:35 > > To: Adam Roach > > Cc: Robert Sparks; Jonathan Rosenberg; > 'simple@ietf.org' > > Subject: RE: [Simple] Urgent: Event Lists Open > Issue > > > > > > > > > > On Mon, 2003-03-24 at 17:05, Adam Roach wrote: > > > > -----Original Message----- > > > > From: Robert Sparks > [mailto:rsparks@dynamicsoft.com] > > > > > > > > For other kinds of filters, particularly those > based on filtering > > > > content, the burden _has_ to live in the > definition of the filter. > > > > I'm not sure yet whether that means a filter > has to be > > list agnostic. > > > > It may be that a filter can express "Do this > if you are a list, > > > > otherwise do that". > > > > > > I was composing a note along the same lines, but > you said > > it far more > > > succinctly. > > > > > > Actually, my example was going to keep the > list-agnostic property, > > > and suggest that you could specify two filters > in a multipart > > > body: one filter applied to the list resources, > and another > > > applied to the non-list resources. > > > > > > > I think the rule expression language should be > agnostic to > > the mechanics > > of list subscriptions, but it should _not_ assume > that a given > > subscription (and its resulting ruleset) is only > about a particular > > presentity. > > > > For example, I would like to be able to express > that a rule applies to > > Bob. Also, I would like to be able to express that > a rule applies to > > everybody, or everybody in a domain, etc. > > > > If you do that right, it ought to be equally > applicable for a list > > subsription and a scaler subscription. If I > express a rule to apply to > > everyone, that means all resources that show up in > the tree. > > If I have a > > scaler subscription, my tree is trivial. If I want > a rule to apply to > > Bob, then for a scaler subscription to Bob, it > works fine. > > For a scaler > > subscription to Carol, it is meaningless. For a > list subscription in > > which Bob shows up _anywhere_ in the tree, it > applies to Bob. > > Note that > > this does not require the rule language to have > any concept > > of the tree > > structure, or how lists work. It only requires a > rule language that > > accepts the idea of a 1 to many relationship > between subcriptions and > > presentities. > > > > Now, if such a rule language existed, it seems to > me the only > > thing that > > the list draft needs to specify is that a ruleset > may be delivered in > > the body of a SUBSCRIBE request. > > > > > I think it is important that we be able to keep > the list stuff out > > > of the filters themselves. The filtering work is > bubbling up all > > > over: SIP, XMPP, LEMONADE, WEBDAV... it looks > very much like there > > > would be *great* benefit to coordinating te > filtering work and > > > re-using it in a bunch of places. > > > > > > If we make the filter syntax list-aware, we > might have a harder > > > time fostering such re-use. Using a multipart > body in the way > > > I describe would eliminate such a barrier. > > > > > > If this sounds good, then the only provision we > need to add > > > to the current lists draft is some mechanism for > indicating > > > which body part applies to lists, and which > applies to non-lists. > > > > > > /a > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 22:10:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15505 for ; Mon, 24 Mar 2003 22:10:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3UFG26370 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 22:30:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3UFO26367 for ; Mon, 24 Mar 2003 22:30:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15498 for ; Mon, 24 Mar 2003 22:09:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3U8O26359; Mon, 24 Mar 2003 22:30:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3TtO26328 for ; Mon, 24 Mar 2003 22:29:55 -0500 Received: from d12lmsgate-5.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15465 for ; Mon, 24 Mar 2003 22:09:17 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2P3BYOI009792 for ; Tue, 25 Mar 2003 04:11:34 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2P3BY2g270776 for ; Tue, 25 Mar 2003 04:11:35 +0100 In-Reply-To: <20030325020027.84011.qmail@web41504.mail.yahoo.com> To: "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/03/2003 05:11:34, Serialize complete at 25/03/2003 05:11:34 Content-Type: text/plain; charset="US-ASCII" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 05:11:24 +0200 Sounds like a filtering working group is going to be created soon... For the event lists draft are we all OK with having two filters in the SUBSCRIBE, One applies to an atomic objects and the other applies to complex ones and leave the details of the filter language to the filtering work? Avshalom Sean Olson Sent by: simple-admin@ietf.org 25/03/2003 04:00 To Adam Roach , Ben Campbell cc Robert Sparks , Jonathan Rosenberg , "'simple@ietf.org'" Subject RE: [Simple] Urgent: Event Lists Open Issue The unfortunate consequence of this is that the filter you place in a subscription needs to be complete in the sense that it filters out anything you might possibly not want to see because if you happen to unknowingly subscribe to a list, you might very well get back something you did not expect (a leaf). Thus filters will get long and complex and you will probably need a better mechanism for managing filters than SUBSCRIBE itself leading to even more protocol machinery that was supposed to simplify the life of the client, not complicate it. Filters must be designed with hierarchy in mind and must allow "everything but" and "nothing but" definitions. Hmmmm.... sounds like a job for LISP. --- Adam Roach wrote: > Yes, I think that's where we're getting. > > The key distinction I was trying to make below is > that we > almost certainly do *not* want to add the ability to > say > "inform me only when the 'state' attribute of an > > element transitions from 'active' to 'terminated'" > to the > language that tells us how to filter presence. And > the one that > tells us how to filter registrations. And the one > that tells > us how to filter dialog state. And the one that > tells us how > to filter SPIRITS. And the one that tells us how to > filter > phoneconfig. And the one that tells us how to filter > MWI. > And the one that tells us how to filter winfo. And > the one > that tells us how to filter signalled digits. And > the one > that tells us how to filter... > > See where I'm going? > > /a > > > -----Original Message----- > > From: Ben Campbell > [mailto:bcampbell@dynamicsoft.com] > > Sent: Monday, March 24, 2003 18:35 > > To: Adam Roach > > Cc: Robert Sparks; Jonathan Rosenberg; > 'simple@ietf.org' > > Subject: RE: [Simple] Urgent: Event Lists Open > Issue > > > > > > > > > > On Mon, 2003-03-24 at 17:05, Adam Roach wrote: > > > > -----Original Message----- > > > > From: Robert Sparks > [mailto:rsparks@dynamicsoft.com] > > > > > > > > For other kinds of filters, particularly those > based on filtering > > > > content, the burden _has_ to live in the > definition of the filter. > > > > I'm not sure yet whether that means a filter > has to be > > list agnostic. > > > > It may be that a filter can express "Do this > if you are a list, > > > > otherwise do that". > > > > > > I was composing a note along the same lines, but > you said > > it far more > > > succinctly. > > > > > > Actually, my example was going to keep the > list-agnostic property, > > > and suggest that you could specify two filters > in a multipart > > > body: one filter applied to the list resources, > and another > > > applied to the non-list resources. > > > > > > > I think the rule expression language should be > agnostic to > > the mechanics > > of list subscriptions, but it should _not_ assume > that a given > > subscription (and its resulting ruleset) is only > about a particular > > presentity. > > > > For example, I would like to be able to express > that a rule applies to > > Bob. Also, I would like to be able to express that > a rule applies to > > everybody, or everybody in a domain, etc. > > > > If you do that right, it ought to be equally > applicable for a list > > subsription and a scaler subscription. If I > express a rule to apply to > > everyone, that means all resources that show up in > the tree. > > If I have a > > scaler subscription, my tree is trivial. If I want > a rule to apply to > > Bob, then for a scaler subscription to Bob, it > works fine. > > For a scaler > > subscription to Carol, it is meaningless. For a > list subscription in > > which Bob shows up _anywhere_ in the tree, it > applies to Bob. > > Note that > > this does not require the rule language to have > any concept > > of the tree > > structure, or how lists work. It only requires a > rule language that > > accepts the idea of a 1 to many relationship > between subcriptions and > > presentities. > > > > Now, if such a rule language existed, it seems to > me the only > > thing that > > the list draft needs to specify is that a ruleset > may be delivered in > > the body of a SUBSCRIBE request. > > > > > I think it is important that we be able to keep > the list stuff out > > > of the filters themselves. The filtering work is > bubbling up all > > > over: SIP, XMPP, LEMONADE, WEBDAV... it looks > very much like there > > > would be *great* benefit to coordinating te > filtering work and > > > re-using it in a bunch of places. > > > > > > If we make the filter syntax list-aware, we > might have a harder > > > time fostering such re-use. Using a multipart > body in the way > > > I describe would eliminate such a barrier. > > > > > > If this sounds good, then the only provision we > need to add > > > to the current lists draft is some mechanism for > indicating > > > which body part applies to lists, and which > applies to non-lists. > > > > > > /a > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 22:31:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16188 for ; Mon, 24 Mar 2003 22:31:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3pWC28054 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 22:51:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3pWO28051 for ; Mon, 24 Mar 2003 22:51:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16168 for ; Mon, 24 Mar 2003 22:30:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3pNO28037; Mon, 24 Mar 2003 22:51:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3mTO27933 for ; Mon, 24 Mar 2003 22:48:29 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16138 for ; Mon, 24 Mar 2003 22:27:51 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.20]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2P3UEBd004703; Mon, 24 Mar 2003 22:30:15 -0500 (EST) Message-ID: <3E7FCD43.6010105@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: Avshalom Houri CC: "'simple@ietf.org'" Subject: Re: [Simple] Urgent: Event Lists Open Issue References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:30:11 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I dont even think we need to go that far. I think that it should say that a filter can appear in the body, and that work on filters is still under investigation. Period. We can have this nice long debate on the meaning of filters in infinitely deep trees later on. -Jonathan R. Avshalom Houri wrote: > Sounds like a filtering working group is going to be created soon... > > For the event lists draft are we all OK with having two filters in the > SUBSCRIBE, > One applies to an atomic objects and the other applies to complex ones and > leave > the details of the filter language to the filtering work? > > Avshalom > > > > > Sean Olson > Sent by: simple-admin@ietf.org > 25/03/2003 04:00 > > To > Adam Roach , Ben Campbell > > cc > Robert Sparks , Jonathan Rosenberg > , "'simple@ietf.org'" > Subject > RE: [Simple] Urgent: Event Lists Open Issue > > > > > > > The unfortunate consequence of this is that the > filter you place in a subscription needs to be > complete in the sense that it filters out anything > you might possibly not want to see because if you > happen to unknowingly subscribe to a list, you might > very well get back something you did not expect (a > leaf). > > Thus filters will get long and complex and you > will probably need a better mechanism for managing > filters than SUBSCRIBE itself leading to even > more protocol machinery that was supposed to simplify > the life of the client, not complicate it. > > Filters must be designed with hierarchy in mind > and must allow "everything but" and "nothing but" > definitions. Hmmmm.... sounds like a job for LISP. > > > --- Adam Roach wrote: > >>Yes, I think that's where we're getting. >> >>The key distinction I was trying to make below is >>that we >>almost certainly do *not* want to add the ability to >>say >>"inform me only when the 'state' attribute of an >> >>element transitions from 'active' to 'terminated'" >>to the >>language that tells us how to filter presence. And >>the one that >>tells us how to filter registrations. And the one >>that tells >>us how to filter dialog state. And the one that >>tells us how >>to filter SPIRITS. And the one that tells us how to >>filter >>phoneconfig. And the one that tells us how to filter >>MWI. >>And the one that tells us how to filter winfo. And >>the one >>that tells us how to filter signalled digits. And >>the one >>that tells us how to filter... >> >>See where I'm going? >> >>/a >> >> >>>-----Original Message----- >>>From: Ben Campbell >> >>[mailto:bcampbell@dynamicsoft.com] >> >>>Sent: Monday, March 24, 2003 18:35 >>>To: Adam Roach >>>Cc: Robert Sparks; Jonathan Rosenberg; >> >>'simple@ietf.org' >> >>>Subject: RE: [Simple] Urgent: Event Lists Open >> >>Issue >> >>> >>> >>> >>>On Mon, 2003-03-24 at 17:05, Adam Roach wrote: >>> >>>>>-----Original Message----- >>>>>From: Robert Sparks >>>> >>[mailto:rsparks@dynamicsoft.com] >> >>>>>For other kinds of filters, particularly those >>>> >>based on filtering >> >>>>>content, the burden _has_ to live in the >>>> >>definition of the filter. >> >>>>>I'm not sure yet whether that means a filter >>>> >>has to be >> >>>list agnostic. >>> >>>>>It may be that a filter can express "Do this >>>> >>if you are a list, >> >>>>>otherwise do that". >>>> >>>>I was composing a note along the same lines, but >>> >>you said >> >>>it far more >>> >>>>succinctly. >>>> >>>>Actually, my example was going to keep the >>> >>list-agnostic property, >> >>>>and suggest that you could specify two filters >>> >>in a multipart >> >>>>body: one filter applied to the list resources, >>> >>and another >> >>>>applied to the non-list resources. >>>> >>> >>>I think the rule expression language should be >> >>agnostic to >> >>>the mechanics >>>of list subscriptions, but it should _not_ assume >> >>that a given >> >>>subscription (and its resulting ruleset) is only >> >>about a particular >> >>>presentity. >>> >>>For example, I would like to be able to express >> >>that a rule applies to >> >>>Bob. Also, I would like to be able to express that >> >>a rule applies to >> >>>everybody, or everybody in a domain, etc. >>> >>>If you do that right, it ought to be equally >> >>applicable for a list >> >>>subsription and a scaler subscription. If I >> >>express a rule to apply to >> >>>everyone, that means all resources that show up in >> >>the tree. >> >>>If I have a >>>scaler subscription, my tree is trivial. If I want >> >>a rule to apply to >> >>>Bob, then for a scaler subscription to Bob, it >> >>works fine. >> >>>For a scaler >>>subscription to Carol, it is meaningless. For a >> >>list subscription in >> >>>which Bob shows up _anywhere_ in the tree, it >> >>applies to Bob. >> >>>Note that >>>this does not require the rule language to have >> >>any concept >> >>>of the tree >>>structure, or how lists work. It only requires a >> >>rule language that >> >>>accepts the idea of a 1 to many relationship >> >>between subcriptions and >> >>>presentities. >>> >>>Now, if such a rule language existed, it seems to >> >>me the only >> >>>thing that >>>the list draft needs to specify is that a ruleset >> >>may be delivered in >> >>>the body of a SUBSCRIBE request. >>> >>> >>>>I think it is important that we be able to keep >>> >>the list stuff out >> >>>>of the filters themselves. The filtering work is >>> >>bubbling up all >> >>>>over: SIP, XMPP, LEMONADE, WEBDAV... it looks >>> >>very much like there >> >>>>would be *great* benefit to coordinating te >>> >>filtering work and >> >>>>re-using it in a bunch of places. >>>> >>>>If we make the filter syntax list-aware, we >>> >>might have a harder >> >>>>time fostering such re-use. Using a multipart >>> >>body in the way >> >>>>I describe would eliminate such a barrier. >>>> >>>>If this sounds good, then the only provision we >>> >>need to add >> >>>>to the current lists draft is some mechanism for >>> >>indicating >> >>>>which body part applies to lists, and which >>> >>applies to non-lists. >> >>>>/a >>> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 22:31:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16209 for ; Mon, 24 Mar 2003 22:31:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3q4c28123 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 22:52:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3q4O28118 for ; Mon, 24 Mar 2003 22:52:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16192 for ; Mon, 24 Mar 2003 22:31:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3q0O28097; Mon, 24 Mar 2003 22:52:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3puO28083 for ; Mon, 24 Mar 2003 22:51:56 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16182 for ; Mon, 24 Mar 2003 22:31:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.20]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2P3XgBd004707; Mon, 24 Mar 2003 22:33:42 -0500 (EST) Message-ID: <3E7FCE13.7080501@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: Ben Campbell , "'simple@ietf.org'" Subject: Re: [Simple] Urgent: Event Lists Open Issue References: <9BF66EBF6BEFD942915B4D4D45C051F3A645CC@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:33:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Question inline. Adam Roach wrote: > After some further reflection, I think I see the disconnect > here. > > When I say "applied to the root only", you're still thinking > of what I mean by "applied to everything". > > The type of filter that would be "applied to the root only" > or "applied to non-leaves only" would be something along > the lines of "inform me only when the 'state' attribute of an > element transitions from 'active' to 'terminated'". > (Visual aid: example at the top of page 13 of > draft-ietf-simple-event-list-00) Why can't this be applied to everythign? The list server would pass such a filter on, and any leaves would process it. Those leaves which are not would send no notifications, and the one which is wuold send them only on state transitions. Perhaps you had in mind that the list server would interpret this rule, and as a result, only subscribe to , and in that body, construct its own filter that applies to a single presentity, saying "inform me when the state changes from active to terminated"? Note that I still believe this should not impact the list draft, which should still just say that filters appear in the bodies, which is under development. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 22:42:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16371 for ; Mon, 24 Mar 2003 22:42:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P42Tp28500 for simple-archive@odin.ietf.org; Mon, 24 Mar 2003 23:02:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P42TO28497 for ; Mon, 24 Mar 2003 23:02:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16355 for ; Mon, 24 Mar 2003 22:41:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P42NO28488; Mon, 24 Mar 2003 23:02:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3xZO28384 for ; Mon, 24 Mar 2003 22:59:35 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16329 for ; Mon, 24 Mar 2003 22:38:57 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2P3fB908899; Mon, 24 Mar 2003 21:41:11 -0600 Subject: RE: [Simple] Urgent: Event Lists Open Issue From: Ben Campbell To: Sean Olson Cc: Adam Roach , Robert Sparks , Jonathan Rosenberg , "'simple@ietf.org'" In-Reply-To: <20030325020027.84011.qmail@web41504.mail.yahoo.com> References: <20030325020027.84011.qmail@web41504.mail.yahoo.com> Content-Type: text/plain Message-Id: <1048563622.1523.72.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2003 21:40:22 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-03-24 at 20:00, Sean Olson wrote: > The unfortunate consequence of this is that the > filter you place in a subscription needs to be > complete in the sense that it filters out anything > you might possibly not want to see because if you > happen to unknowingly subscribe to a list, you might > very well get back something you did not expect (a > leaf). > I would assume that a watcher not prepared to deal with a list would not include the supported tag for lists. > Thus filters will get long and complex and you > will probably need a better mechanism for managing > filters than SUBSCRIBE itself leading to even > more protocol machinery that was supposed to simplify > the life of the client, not complicate it. > > Filters must be designed with hierarchy in mind > and must allow "everything but" and "nothing but" > definitions. Hmmmm.... sounds like a job for LISP. > > > --- Adam Roach wrote: > > Yes, I think that's where we're getting. > > > > The key distinction I was trying to make below is > > that we > > almost certainly do *not* want to add the ability to > > say > > "inform me only when the 'state' attribute of an > > > > element transitions from 'active' to 'terminated'" > > to the > > language that tells us how to filter presence. And > > the one that > > tells us how to filter registrations. And the one > > that tells > > us how to filter dialog state. And the one that > > tells us how > > to filter SPIRITS. And the one that tells us how to > > filter > > phoneconfig. And the one that tells us how to filter > > MWI. > > And the one that tells us how to filter winfo. And > > the one > > that tells us how to filter signalled digits. And > > the one > > that tells us how to filter... > > > > See where I'm going? > > > > /a > > > > > -----Original Message----- > > > From: Ben Campbell > > [mailto:bcampbell@dynamicsoft.com] > > > Sent: Monday, March 24, 2003 18:35 > > > To: Adam Roach > > > Cc: Robert Sparks; Jonathan Rosenberg; > > 'simple@ietf.org' > > > Subject: RE: [Simple] Urgent: Event Lists Open > > Issue > > > > > > > > > > > > > > > On Mon, 2003-03-24 at 17:05, Adam Roach wrote: > > > > > -----Original Message----- > > > > > From: Robert Sparks > > [mailto:rsparks@dynamicsoft.com] > > > > > > > > > > For other kinds of filters, particularly those > > based on filtering > > > > > content, the burden _has_ to live in the > > definition of the filter. > > > > > I'm not sure yet whether that means a filter > > has to be > > > list agnostic. > > > > > It may be that a filter can express "Do this > > if you are a list, > > > > > otherwise do that". > > > > > > > > I was composing a note along the same lines, but > > you said > > > it far more > > > > succinctly. > > > > > > > > Actually, my example was going to keep the > > list-agnostic property, > > > > and suggest that you could specify two filters > > in a multipart > > > > body: one filter applied to the list resources, > > and another > > > > applied to the non-list resources. > > > > > > > > > > I think the rule expression language should be > > agnostic to > > > the mechanics > > > of list subscriptions, but it should _not_ assume > > that a given > > > subscription (and its resulting ruleset) is only > > about a particular > > > presentity. > > > > > > For example, I would like to be able to express > > that a rule applies to > > > Bob. Also, I would like to be able to express that > > a rule applies to > > > everybody, or everybody in a domain, etc. > > > > > > If you do that right, it ought to be equally > > applicable for a list > > > subsription and a scaler subscription. If I > > express a rule to apply to > > > everyone, that means all resources that show up in > > the tree. > > > If I have a > > > scaler subscription, my tree is trivial. If I want > > a rule to apply to > > > Bob, then for a scaler subscription to Bob, it > > works fine. > > > For a scaler > > > subscription to Carol, it is meaningless. For a > > list subscription in > > > which Bob shows up _anywhere_ in the tree, it > > applies to Bob. > > > Note that > > > this does not require the rule language to have > > any concept > > > of the tree > > > structure, or how lists work. It only requires a > > rule language that > > > accepts the idea of a 1 to many relationship > > between subcriptions and > > > presentities. > > > > > > Now, if such a rule language existed, it seems to > > me the only > > > thing that > > > the list draft needs to specify is that a ruleset > > may be delivered in > > > the body of a SUBSCRIBE request. > > > > > > > I think it is important that we be able to keep > > the list stuff out > > > > of the filters themselves. The filtering work is > > bubbling up all > > > > over: SIP, XMPP, LEMONADE, WEBDAV... it looks > > very much like there > > > > would be *great* benefit to coordinating te > > filtering work and > > > > re-using it in a bunch of places. > > > > > > > > If we make the filter syntax list-aware, we > > might have a harder > > > > time fostering such re-use. Using a multipart > > body in the way > > > > I describe would eliminate such a barrier. > > > > > > > > If this sounds good, then the only provision we > > need to add > > > > to the current lists draft is some mechanism for > > indicating > > > > which body part applies to lists, and which > > applies to non-lists. > > > > > > > > /a > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 24 23:48:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17977 for ; Mon, 24 Mar 2003 23:48:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P58M301419 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 00:08:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P58MO01416 for ; Tue, 25 Mar 2003 00:08:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17972 for ; Mon, 24 Mar 2003 23:47:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P589O01326; Tue, 25 Mar 2003 00:08:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P55UO00413 for ; Tue, 25 Mar 2003 00:05:30 -0500 Received: from smtp013.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17818 for ; Mon, 24 Mar 2003 23:44:48 -0500 (EST) Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Mar 2003 04:47:07 -0000 Reply-To: From: "Sean Olson" To: "'Jonathan Rosenberg'" , "'Avshalom Houri'" Cc: Subject: RE: [Simple] Urgent: Event Lists Open Issue Message-ID: <000201c2f289$9b0a2590$6501a8c0@cranberry> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E7FCD43.6010105@dynamicsoft.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2P55UO00414 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 20:47:13 -0800 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Fair enough. I was beginning to put together a filter for this mail thread ;-) -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Monday, March 24, 2003 7:30 PM To: Avshalom Houri Cc: 'simple@ietf.org' Subject: Re: [Simple] Urgent: Event Lists Open Issue I dont even think we need to go that far. I think that it should say that a filter can appear in the body, and that work on filters is still under investigation. Period. We can have this nice long debate on the meaning of filters in infinitely deep trees later on. -Jonathan R. Avshalom Houri wrote: > Sounds like a filtering working group is going to be created soon... > > For the event lists draft are we all OK with having two filters in the > SUBSCRIBE, > One applies to an atomic objects and the other applies to complex ones and > leave > the details of the filter language to the filtering work? > > Avshalom > > > > > Sean Olson > Sent by: simple-admin@ietf.org > 25/03/2003 04:00 > > To > Adam Roach , Ben Campbell > > cc > Robert Sparks , Jonathan Rosenberg > , "'simple@ietf.org'" > Subject > RE: [Simple] Urgent: Event Lists Open Issue > > > > > > > The unfortunate consequence of this is that the > filter you place in a subscription needs to be > complete in the sense that it filters out anything > you might possibly not want to see because if you > happen to unknowingly subscribe to a list, you might > very well get back something you did not expect (a > leaf). > > Thus filters will get long and complex and you > will probably need a better mechanism for managing > filters than SUBSCRIBE itself leading to even > more protocol machinery that was supposed to simplify > the life of the client, not complicate it. > > Filters must be designed with hierarchy in mind > and must allow "everything but" and "nothing but" definitions. > Hmmmm.... sounds like a job for LISP. > > > --- Adam Roach wrote: > >>Yes, I think that's where we're getting. >> >>The key distinction I was trying to make below is >>that we >>almost certainly do *not* want to add the ability to >>say >>"inform me only when the 'state' attribute of an >> >>element transitions from 'active' to 'terminated'" >>to the >>language that tells us how to filter presence. And >>the one that >>tells us how to filter registrations. And the one >>that tells >>us how to filter dialog state. And the one that >>tells us how >>to filter SPIRITS. And the one that tells us how to >>filter >>phoneconfig. And the one that tells us how to filter >>MWI. >>And the one that tells us how to filter winfo. And >>the one >>that tells us how to filter signalled digits. And >>the one >>that tells us how to filter... >> >>See where I'm going? >> >>/a >> >> >>>-----Original Message----- >>>From: Ben Campbell >> >>[mailto:bcampbell@dynamicsoft.com] >> >>>Sent: Monday, March 24, 2003 18:35 >>>To: Adam Roach >>>Cc: Robert Sparks; Jonathan Rosenberg; >> >>'simple@ietf.org' >> >>>Subject: RE: [Simple] Urgent: Event Lists Open >> >>Issue >> >>> >>> >>> >>>On Mon, 2003-03-24 at 17:05, Adam Roach wrote: >>> >>>>>-----Original Message----- >>>>>From: Robert Sparks >>>> >>[mailto:rsparks@dynamicsoft.com] >> >>>>>For other kinds of filters, particularly those >>>> >>based on filtering >> >>>>>content, the burden _has_ to live in the >>>> >>definition of the filter. >> >>>>>I'm not sure yet whether that means a filter >>>> >>has to be >> >>>list agnostic. >>> >>>>>It may be that a filter can express "Do this >>>> >>if you are a list, >> >>>>>otherwise do that". >>>> >>>>I was composing a note along the same lines, but >>> >>you said >> >>>it far more >>> >>>>succinctly. >>>> >>>>Actually, my example was going to keep the >>> >>list-agnostic property, >> >>>>and suggest that you could specify two filters >>> >>in a multipart >> >>>>body: one filter applied to the list resources, >>> >>and another >> >>>>applied to the non-list resources. >>>> >>> >>>I think the rule expression language should be >> >>agnostic to >> >>>the mechanics >>>of list subscriptions, but it should _not_ assume >> >>that a given >> >>>subscription (and its resulting ruleset) is only >> >>about a particular >> >>>presentity. >>> >>>For example, I would like to be able to express >> >>that a rule applies to >> >>>Bob. Also, I would like to be able to express that >> >>a rule applies to >> >>>everybody, or everybody in a domain, etc. >>> >>>If you do that right, it ought to be equally >> >>applicable for a list >> >>>subsription and a scaler subscription. If I >> >>express a rule to apply to >> >>>everyone, that means all resources that show up in >> >>the tree. >> >>>If I have a >>>scaler subscription, my tree is trivial. If I want >> >>a rule to apply to >> >>>Bob, then for a scaler subscription to Bob, it >> >>works fine. >> >>>For a scaler >>>subscription to Carol, it is meaningless. For a >> >>list subscription in >> >>>which Bob shows up _anywhere_ in the tree, it >> >>applies to Bob. >> >>>Note that >>>this does not require the rule language to have >> >>any concept >> >>>of the tree >>>structure, or how lists work. It only requires a >> >>rule language that >> >>>accepts the idea of a 1 to many relationship >> >>between subcriptions and >> >>>presentities. >>> >>>Now, if such a rule language existed, it seems to >> >>me the only >> >>>thing that >>>the list draft needs to specify is that a ruleset >> >>may be delivered in >> >>>the body of a SUBSCRIBE request. >>> >>> >>>>I think it is important that we be able to keep >>> >>the list stuff out >> >>>>of the filters themselves. The filtering work is >>> >>bubbling up all >> >>>>over: SIP, XMPP, LEMONADE, WEBDAV... it looks >>> >>very much like there >> >>>>would be *great* benefit to coordinating te >>> >>filtering work and >> >>>>re-using it in a bunch of places. >>>> >>>>If we make the filter syntax list-aware, we >>> >>might have a harder >> >>>>time fostering such re-use. Using a multipart >>> >>body in the way >> >>>>I describe would eliminate such a barrier. >>>> >>>>If this sounds good, then the only provision we >>> >>need to add >> >>>>to the current lists draft is some mechanism for >>> >>indicating >> >>>>which body part applies to lists, and which >>> >>applies to non-lists. >> >>>>/a >>> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 02:14:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01617 for ; Tue, 25 Mar 2003 02:14:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P7YGl20220 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 02:34:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P7YFO20217 for ; Tue, 25 Mar 2003 02:34:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01425 for ; Tue, 25 Mar 2003 02:13:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P7Y8O20201; Tue, 25 Mar 2003 02:34:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P7X2O20164 for ; Tue, 25 Mar 2003 02:33:02 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01304 for ; Tue, 25 Mar 2003 02:12:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2P7IOX02849 for ; Tue, 25 Mar 2003 09:18:24 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Mar 2003 09:14:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Mar 2003 09:14:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Urgent: Event Lists Open Issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7420@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Urgent: Event Lists Open Issue Thread-Index: AcLyY182sQ5y+ZtmQ5WBvnq84aOBHgAOKlpw To: , Cc: , X-OriginalArrivalTime: 25 Mar 2003 07:14:38.0013 (UTC) FILETIME=[32297ED0:01C2F29E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2P7X2O20165 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 09:14:33 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The draft below discusses this issue and defines a filter for presence that handles situations where a filter is made for a list or a member of that list. It mentions that a filter applies to all the URIs that result in a lookup of the list URI. It does not mention that the filter is propagated down to the leaf subscriptions. This is an RLS behaviour that needs to be defined in list draft, IMO. http://www.ietf.org/internet-drafts/draft-khartabil-simple-presence-filter-00.txt I would suggest that the RLS should not propagate the filter down to the leaves. The reason for that is it then requires UAS (edge presence servers) to understand, interpret and apply the filters. It is the job of the RLS to filter the NOTIFYs coming into the RLS and create new NOTIFY bodies according to that filter. I think I'm advocating option a) below. Regards, Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Tuesday, March 25, 2003 2:12 AM > To: Ben Campbell; Adam Roach > Cc: Jonathan Rosenberg; 'simple@ietf.org' > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > After some further reflection, I think I see the disconnect > here. > > When I say "applied to the root only", you're still thinking > of what I mean by "applied to everything". > > The type of filter that would be "applied to the root only" > or "applied to non-leaves only" would be something along > the lines of "inform me only when the 'state' attribute of an > element transitions from 'active' to 'terminated'". > (Visual aid: example at the top of page 13 of > draft-ietf-simple-event-list-00) > > The point of my "tell me when someone moves by more than 100 > miles" example is that this is exactly the sort of filter > that CANNOT be applied to the root node, only to leaf nodes. > > /a > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Monday, March 24, 2003 17:55 > > To: Adam Roach > > Cc: Jonathan Rosenberg; 'simple@ietf.org' > > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > > > > On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > > > > > > I have a hard time > > > > understanding the distinction between applying a filter > > to the list > > > > subscription and applying the subscription to the "conceptual" > > > > underlying subsriptions. > > > > > > Thinking still of these conceptual underlying subscriptions, > > > a subscription to a list creates an arbitrarily deep tree > > > of subscriptions, in which all of the leaves are non-list > > > resources, and all other nodes are list resources. > > > > > > Keeping this tree in mind, the question being posed fundamentally > > > boils down to this: When a filter document is included in a > > > SUBSCRIBE message to a list, which of these nodes does it > apply to? > > > > > > a) Only the root node? > > > b) Only the leaves? > > > c) Everything? > > > d) Everything but the leaves? > > > e) Some subset of nodes not listed above? > > > > > > > For example, is it a question of saying "only tell me when > > > > someone moves > > > > 100 miles" vs. "Tell me when Alice moves 50 mi or Bob > > moves 75 mi"? > > > > > > That's interesting, but not really what I had in mind. It also > > > indicates to me that the model you had in your mind was option > > > "b) Only the leaves". > > > > > > > No, actually what I had in mind was "a) Only the root.". > > > > Maybe my disconnect is it still feels that the only > rational model is > > "A) only the root", and options B and C are, among others, possible > > mechanisms the root can use to implement that. (Which, by the > > way, seems > > to take us back to my first response.) > > > > Since we seem to be talking _way_ past each other, let me > extend your > > concrete example. If I only want to see notifies that > involve a 100 mi > > or more change in geoloc, I express that on my SUBSCRIBE > > request to the > > list. Now, the list server could go about that in a number > of ways. It > > could delegate subscriptions for each list entry (with real or > > conceptual subscriptions), and only pass through > > notifications when the > > threshold is reached. This seems like a clear case of option a). > > > > Now, it could also do this by attaching a derived filter to each > > delegated subscription, so that _it_ only sees the changes > that match > > the rule, and passes them all on to the watcher. That would > > _seem_ like > > option B. But from the watcher's perspective, these two approaches > > should be indistinguishable. > > > > I guess my point is, it seems to me this should be > specified based on > > what goes into the root subscription, and what comes back out--which > > should be doable without explicitly dealing with filters in the list > > draft, just as it is without explicitly reving 3265. > > > > > > > /a > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 02:29:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02422 for ; Tue, 25 Mar 2003 02:29:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P7nHq21526 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 02:49:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P7nGO21523 for ; Tue, 25 Mar 2003 02:49:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02413 for ; Tue, 25 Mar 2003 02:28:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P7nAO21511; Tue, 25 Mar 2003 02:49:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P7mAO21448 for ; Tue, 25 Mar 2003 02:48:10 -0500 Received: from smtp014.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02364 for ; Tue, 25 Mar 2003 02:27:28 -0500 (EST) Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Mar 2003 07:29:47 -0000 Reply-To: From: "Sean Olson" To: , Message-ID: <000b01c2f2a0$54f9a050$6501a8c0@cranberry> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2P7mAO21449 Subject: [Simple] Comments on draft-ietf-simple-event-list-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 23:29:54 -0800 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Comments on draft-ietf-simple-event-list-00: 1) Here is a slightly cleaned up XML schema: NOTE: You will probably want to add an IANA registration for the XML namespace (urn:ietf:params:xml:ns:rlmi) similar to the one found in the CPIM-PIDF draft I've thrown in anyAttribute in a couple of spots as well as the any element for the element definition. 2) Why do you allow a list with 0 resource elements? I could not think of a use case for this. (If there is no reason, the schema should be changed to have a minOccurs of 1) 3) It would be nice to pass along a preference to disable forking of event packages that support it. I'm assuming a Request-Disposition: header ala caller prefs would be sufficient. This seems more critical for the RLS than for the subscriber. Is it reasonable for the RLS to request non-forking of the resource SUBSCRIBEs even if the initial subscriber did not? 4) In the event that one of the resource subscriptions from the RLS gets terminated, the subscriber does not seem to have any option but to un-SUBSCRIBE and re-SUBSCRIBE in the hope of refreshing the resource subscription. Is there another way? 5) One of the problems that was given as motivation for the draft in the Introduction: o If a subscriber has only intermittent connectivity, and generally polls for state rather than simply subscribing, the latency to obtain the state of the entire resource can be large. The messaging required for each poll can also be substantial. does not seem to be solved by this mechanism. If connectivity is intermittent, how would an RLS help? How would an RLS reduce the state of the resource notification (other than through the use of partial notifications and filtering that can be applied for a non-list subcription as well)? 6) The specification of a charset parameter in the Content-Type seems redundant for the XML payload. For example: Content-Type: application/rlmi+xml;charset="UTF-8" (Just a small nit) cheers, sean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 07:43:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07738 for ; Tue, 25 Mar 2003 07:43:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PD3W208217 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 08:03:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PD3VO08214 for ; Tue, 25 Mar 2003 08:03:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07702 for ; Tue, 25 Mar 2003 07:42:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PD3GO08196; Tue, 25 Mar 2003 08:03:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PD2tO08166 for ; Tue, 25 Mar 2003 08:02:55 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07672 for ; Tue, 25 Mar 2003 07:40:56 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2PCfmU00739 for ; Tue, 25 Mar 2003 14:41:48 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Mar 2003 14:43:15 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Mar 2003 14:43:15 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Urgent: Event Lists Open Issue X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019451D8@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Urgent: Event Lists Open Issue Thread-Index: AcLyiiJbZ9wNw+aAQmS7vcGzT8oPeQAPLUtw To: , , Cc: X-OriginalArrivalTime: 25 Mar 2003 12:43:15.0668 (UTC) FILETIME=[1ACCE140:01C2F2CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PD2tO08171 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:43:13 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Or rather we need some rate limit. There seemed to be a bit of a burst in this thread overnight - makes it really difficult to follow... ;) But to the issue, I also agree with the below statement. Cheers, Aki > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 25 March, 2003 06:47 > To: 'Jonathan Rosenberg'; 'Avshalom Houri' > Cc: simple@ietf.org > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > Fair enough. I was beginning to put together a filter for > this mail thread > ;-) > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] > On Behalf Of > Jonathan Rosenberg > Sent: Monday, March 24, 2003 7:30 PM > To: Avshalom Houri > Cc: 'simple@ietf.org' > Subject: Re: [Simple] Urgent: Event Lists Open Issue > > > I dont even think we need to go that far. I think that it should say > that a filter can appear in the body, and that work on > filters is still > under investigation. Period. We can have this nice long > debate on the > meaning of filters in infinitely deep trees later on. > > -Jonathan R. > > Avshalom Houri wrote: > > Sounds like a filtering working group is going to be > created soon... > > > > For the event lists draft are we all OK with having two > filters in the > > SUBSCRIBE, > > One applies to an atomic objects and the other applies to > complex ones and > > > leave > > the details of the filter language to the filtering work? > > > > Avshalom > > > > > > > > > > Sean Olson > > Sent by: simple-admin@ietf.org > > 25/03/2003 04:00 > > > > To > > Adam Roach , Ben Campbell > > > > cc > > Robert Sparks , Jonathan Rosenberg > > , "'simple@ietf.org'" > > Subject > > RE: [Simple] Urgent: Event Lists Open Issue > > > > > > > > > > > > > > The unfortunate consequence of this is that the > > filter you place in a subscription needs to be > > complete in the sense that it filters out anything > > you might possibly not want to see because if you > > happen to unknowingly subscribe to a list, you might > > very well get back something you did not expect (a > > leaf). > > > > Thus filters will get long and complex and you > > will probably need a better mechanism for managing > > filters than SUBSCRIBE itself leading to even > > more protocol machinery that was supposed to simplify > > the life of the client, not complicate it. > > > > Filters must be designed with hierarchy in mind > > and must allow "everything but" and "nothing but" definitions. > > Hmmmm.... sounds like a job for LISP. > > > > > > --- Adam Roach wrote: > > > >>Yes, I think that's where we're getting. > >> > >>The key distinction I was trying to make below is > >>that we > >>almost certainly do *not* want to add the ability to > >>say > >>"inform me only when the 'state' attribute of an > >> > >>element transitions from 'active' to 'terminated'" > >>to the > >>language that tells us how to filter presence. And > >>the one that > >>tells us how to filter registrations. And the one > >>that tells > >>us how to filter dialog state. And the one that > >>tells us how > >>to filter SPIRITS. And the one that tells us how to > >>filter > >>phoneconfig. And the one that tells us how to filter > >>MWI. > >>And the one that tells us how to filter winfo. And > >>the one > >>that tells us how to filter signalled digits. And > >>the one > >>that tells us how to filter... > >> > >>See where I'm going? > >> > >>/a > >> > >> > >>>-----Original Message----- > >>>From: Ben Campbell > >> > >>[mailto:bcampbell@dynamicsoft.com] > >> > >>>Sent: Monday, March 24, 2003 18:35 > >>>To: Adam Roach > >>>Cc: Robert Sparks; Jonathan Rosenberg; > >> > >>'simple@ietf.org' > >> > >>>Subject: RE: [Simple] Urgent: Event Lists Open > >> > >>Issue > >> > >>> > >>> > >>> > >>>On Mon, 2003-03-24 at 17:05, Adam Roach wrote: > >>> > >>>>>-----Original Message----- > >>>>>From: Robert Sparks > >>>> > >>[mailto:rsparks@dynamicsoft.com] > >> > >>>>>For other kinds of filters, particularly those > >>>> > >>based on filtering > >> > >>>>>content, the burden _has_ to live in the > >>>> > >>definition of the filter. > >> > >>>>>I'm not sure yet whether that means a filter > >>>> > >>has to be > >> > >>>list agnostic. > >>> > >>>>>It may be that a filter can express "Do this > >>>> > >>if you are a list, > >> > >>>>>otherwise do that". > >>>> > >>>>I was composing a note along the same lines, but > >>> > >>you said > >> > >>>it far more > >>> > >>>>succinctly. > >>>> > >>>>Actually, my example was going to keep the > >>> > >>list-agnostic property, > >> > >>>>and suggest that you could specify two filters > >>> > >>in a multipart > >> > >>>>body: one filter applied to the list resources, > >>> > >>and another > >> > >>>>applied to the non-list resources. > >>>> > >>> > >>>I think the rule expression language should be > >> > >>agnostic to > >> > >>>the mechanics > >>>of list subscriptions, but it should _not_ assume > >> > >>that a given > >> > >>>subscription (and its resulting ruleset) is only > >> > >>about a particular > >> > >>>presentity. > >>> > >>>For example, I would like to be able to express > >> > >>that a rule applies to > >> > >>>Bob. Also, I would like to be able to express that > >> > >>a rule applies to > >> > >>>everybody, or everybody in a domain, etc. > >>> > >>>If you do that right, it ought to be equally > >> > >>applicable for a list > >> > >>>subsription and a scaler subscription. If I > >> > >>express a rule to apply to > >> > >>>everyone, that means all resources that show up in > >> > >>the tree. > >> > >>>If I have a > >>>scaler subscription, my tree is trivial. If I want > >> > >>a rule to apply to > >> > >>>Bob, then for a scaler subscription to Bob, it > >> > >>works fine. > >> > >>>For a scaler > >>>subscription to Carol, it is meaningless. For a > >> > >>list subscription in > >> > >>>which Bob shows up _anywhere_ in the tree, it > >> > >>applies to Bob. > >> > >>>Note that > >>>this does not require the rule language to have > >> > >>any concept > >> > >>>of the tree > >>>structure, or how lists work. It only requires a > >> > >>rule language that > >> > >>>accepts the idea of a 1 to many relationship > >> > >>between subcriptions and > >> > >>>presentities. > >>> > >>>Now, if such a rule language existed, it seems to > >> > >>me the only > >> > >>>thing that > >>>the list draft needs to specify is that a ruleset > >> > >>may be delivered in > >> > >>>the body of a SUBSCRIBE request. > >>> > >>> > >>>>I think it is important that we be able to keep > >>> > >>the list stuff out > >> > >>>>of the filters themselves. The filtering work is > >>> > >>bubbling up all > >> > >>>>over: SIP, XMPP, LEMONADE, WEBDAV... it looks > >>> > >>very much like there > >> > >>>>would be *great* benefit to coordinating te > >>> > >>filtering work and > >> > >>>>re-using it in a bunch of places. > >>>> > >>>>If we make the filter syntax list-aware, we > >>> > >>might have a harder > >> > >>>>time fostering such re-use. Using a multipart > >>> > >>body in the way > >> > >>>>I describe would eliminate such a barrier. > >>>> > >>>>If this sounds good, then the only provision we > >>> > >>need to add > >> > >>>>to the current lists draft is some mechanism for > >>> > >>indicating > >> > >>>>which body part applies to lists, and which > >>> > >>applies to non-lists. > >> > >>>>/a > >>> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on > your desktop! > > http://platinum.yahoo.com > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 07:56:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08011 for ; Tue, 25 Mar 2003 07:56:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PDHAN09423 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 08:17:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PDHAO09420 for ; Tue, 25 Mar 2003 08:17:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07995 for ; Tue, 25 Mar 2003 07:56:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PDH5O09411; Tue, 25 Mar 2003 08:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PDGUO09373 for ; Tue, 25 Mar 2003 08:16:30 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07987 for ; Tue, 25 Mar 2003 07:55:42 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2PCuWU12860 for ; Tue, 25 Mar 2003 14:56:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Mar 2003 14:57:54 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Mar 2003 14:57:53 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Urgent: Event Lists Open Issue X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019451D9@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Urgent: Event Lists Open Issue Thread-Index: AcLyWmpzLxEXNOwtSGW8dShS8C8FHgAcbbTA To: , Cc: , , X-OriginalArrivalTime: 25 Mar 2003 12:57:53.0970 (UTC) FILETIME=[264F2120:01C2F2CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PDGUO09374 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:57:53 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit It seems to me we're trying to get all the benefits of throttles, filters and list subscriptions (and combinations of those) without any of the drawbacks. My feeling is that we should make the simple case work first, and not worry about the more complex scenarios. For example, a rate limit of 1/min is not real useful for a list with 10 buddies. In fact it's pretty much as useless as a 1/10min throttle for a single buddy. I think an optimization will fail or never get finished if it becomes too complex and tries to solve too many sub-cases. Cheers, Aki > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 25 March, 2003 01:08 > To: Jonathan Rosenberg > Cc: Adam Roach; Ben Campbell; 'simple@ietf.org' > Subject: Re: [Simple] Urgent: Event Lists Open Issue > > > > On Mon, 2003-03-24 at 16:44, Jonathan Rosenberg wrote: > > Robert Sparks wrote: > > > > > For other kinds of filters, particularly those based on filtering > > > content, the burden _has_ to live in the definition of > the filter. > > > I'm not sure yet whether that means a filter has to be > list agnostic. > > > It may be that a filter can express "Do this if you are a list, > > > otherwise do that". > > > > I still assert that for the most common cases, you will > want to apply > > the same filter across all users in the list. In the cases > where you > > dont, the filter mechanism merely needs to provide the ability to > > specify per-user filters. > > > > > > > > Back to rate limiting. The effect of A below for presence is that > > > if 10 of my buddies happen to change their presence state about > > > the same time (which happens frequently at the end of meetings), > > > I won't find out about one of them until at least 10 > minutes later. > > > > > > This points out value in being able to assert B as the > right thing > > > to do. > > > > Its the same point as above. A baseline rate limiting > mechanism will > > work for lists and single user presentities. It may not be > sufficient > > for all list subscriptions, in whcih case we could define > additional > > rate limiting mechanisms that define behavior on a per-user basis. > > > > So are you saying, then, that the default behavior is A > (from earlier) > but that we need to pass a requirement to sipping to be able > to express > a choice for B for the baseline rate limiting mechanism? > > Or are you saying that the baseline behavior is A, not > matter what, and > that if you want B behavior, you have to specify it in a package > specific filter document? > > RjS > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 14:11:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25946 for ; Tue, 25 Mar 2003 14:11:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJVha04444 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 14:31:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJVhO04441 for ; Tue, 25 Mar 2003 14:31:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25929 for ; Tue, 25 Mar 2003 14:10:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJVaO04423; Tue, 25 Mar 2003 14:31:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJTwO04285 for ; Tue, 25 Mar 2003 14:29:58 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25881 for ; Tue, 25 Mar 2003 14:09:01 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2PJBFTU006738; Tue, 25 Mar 2003 14:11:15 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 13:11:20 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645D4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Adam Roach , Ben Campbell Cc: Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 13:11:19 -0600 You're falling into the same trap that Ben did. We're not discussing *who* applies the filters; we're discussing *to* *what* *data* are they applied. /a > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, March 25, 2003 1:15 > To: adam@dynamicsoft.com; bcampbell@dynamicsoft.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > The draft below discusses this issue and defines a filter for > presence that handles situations where a filter is made for a > list or a member of that list. It mentions that a filter > applies to all the URIs that result in a lookup of the list > URI. It does not mention that the filter is propagated down > to the leaf subscriptions. This is an RLS behaviour that > needs to be defined in list draft, IMO. > > http://www.ietf.org/internet-drafts/draft-khartabil-simple-pre > sence-filter-00.txt > > I would suggest that the RLS should not propagate the filter > down to the leaves. The reason for that is it then requires > UAS (edge presence servers) to understand, interpret and > apply the filters. It is the job of the RLS to filter the > NOTIFYs coming into the RLS and create new NOTIFY bodies > according to that filter. > > I think I'm advocating option a) below. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Tuesday, March 25, 2003 2:12 AM > > To: Ben Campbell; Adam Roach > > Cc: Jonathan Rosenberg; 'simple@ietf.org' > > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > > > > After some further reflection, I think I see the disconnect > > here. > > > > When I say "applied to the root only", you're still thinking > > of what I mean by "applied to everything". > > > > The type of filter that would be "applied to the root only" > > or "applied to non-leaves only" would be something along > > the lines of "inform me only when the 'state' attribute of an > > element transitions from 'active' to 'terminated'". > > (Visual aid: example at the top of page 13 of > > draft-ietf-simple-event-list-00) > > > > The point of my "tell me when someone moves by more than 100 > > miles" example is that this is exactly the sort of filter > > that CANNOT be applied to the root node, only to leaf nodes. > > > > /a > > > > > -----Original Message----- > > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: Monday, March 24, 2003 17:55 > > > To: Adam Roach > > > Cc: Jonathan Rosenberg; 'simple@ietf.org' > > > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > > > > > > > On Mon, 2003-03-24 at 16:08, Adam Roach wrote: > > > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > > > > > > > > I have a hard time > > > > > understanding the distinction between applying a filter > > > to the list > > > > > subscription and applying the subscription to the "conceptual" > > > > > underlying subsriptions. > > > > > > > > Thinking still of these conceptual underlying subscriptions, > > > > a subscription to a list creates an arbitrarily deep tree > > > > of subscriptions, in which all of the leaves are non-list > > > > resources, and all other nodes are list resources. > > > > > > > > Keeping this tree in mind, the question being posed > fundamentally > > > > boils down to this: When a filter document is included in a > > > > SUBSCRIBE message to a list, which of these nodes does it > > apply to? > > > > > > > > a) Only the root node? > > > > b) Only the leaves? > > > > c) Everything? > > > > d) Everything but the leaves? > > > > e) Some subset of nodes not listed above? > > > > > > > > > For example, is it a question of saying "only tell me when > > > > > someone moves > > > > > 100 miles" vs. "Tell me when Alice moves 50 mi or Bob > > > moves 75 mi"? > > > > > > > > That's interesting, but not really what I had in mind. It also > > > > indicates to me that the model you had in your mind was option > > > > "b) Only the leaves". > > > > > > > > > > No, actually what I had in mind was "a) Only the root.". > > > > > > Maybe my disconnect is it still feels that the only > > rational model is > > > "A) only the root", and options B and C are, among > others, possible > > > mechanisms the root can use to implement that. (Which, by the > > > way, seems > > > to take us back to my first response.) > > > > > > Since we seem to be talking _way_ past each other, let me > > extend your > > > concrete example. If I only want to see notifies that > > involve a 100 mi > > > or more change in geoloc, I express that on my SUBSCRIBE > > > request to the > > > list. Now, the list server could go about that in a number > > of ways. It > > > could delegate subscriptions for each list entry (with real or > > > conceptual subscriptions), and only pass through > > > notifications when the > > > threshold is reached. This seems like a clear case of option a). > > > > > > Now, it could also do this by attaching a derived filter to each > > > delegated subscription, so that _it_ only sees the changes > > that match > > > the rule, and passes them all on to the watcher. That would > > > _seem_ like > > > option B. But from the watcher's perspective, these two approaches > > > should be indistinguishable. > > > > > > I guess my point is, it seems to me this should be > > specified based on > > > what goes into the root subscription, and what comes back > out--which > > > should be doable without explicitly dealing with filters > in the list > > > draft, just as it is without explicitly reving 3265. > > > > > > > > > > /a > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 14:24:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26759 for ; Tue, 25 Mar 2003 14:24:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJieU05988 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 14:44:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJieO05985 for ; Tue, 25 Mar 2003 14:44:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26724 for ; Tue, 25 Mar 2003 14:23:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJhPO05886; Tue, 25 Mar 2003 14:43:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJX4O04530 for ; Tue, 25 Mar 2003 14:33:04 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26004 for ; Tue, 25 Mar 2003 14:12:08 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2PJEMTU006744; Tue, 25 Mar 2003 14:14:22 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 13:14:27 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645D5@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'aki.niemi@nokia.com'" , Robert Sparks , Jonathan Rosenberg Cc: Adam Roach , Ben Campbell , simple@ietf.org Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 13:14:26 -0600 Once again: we don't need to actually define the filters themselves at this point; we just need to make certain that there *will* be a way to define them. I want to make certain that people attacking the filtering work item won't look back on the lists work and say, "well, that was stupid. If they'd just done this one little thing, our job wouldn't be impossible." /a > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Tuesday, March 25, 2003 6:58 > To: rsparks@dynamicsoft.com; jdrosen@dynamicsoft.com > Cc: adam@dynamicsoft.com; bcampbell@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] Urgent: Event Lists Open Issue > > > It seems to me we're trying to get all the benefits of > throttles, filters and list subscriptions (and combinations > of those) without any of the drawbacks. My feeling is that we > should make the simple case work first, and not worry about > the more complex scenarios. For example, a rate limit of > 1/min is not real useful for a list with 10 buddies. In fact > it's pretty much as useless as a 1/10min throttle for a single buddy. > > I think an optimization will fail or never get finished if it > becomes too complex and tries to solve too many sub-cases. > > Cheers, > Aki > > > -----Original Message----- > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: 25 March, 2003 01:08 > > To: Jonathan Rosenberg > > Cc: Adam Roach; Ben Campbell; 'simple@ietf.org' > > Subject: Re: [Simple] Urgent: Event Lists Open Issue > > > > > > > > On Mon, 2003-03-24 at 16:44, Jonathan Rosenberg wrote: > > > Robert Sparks wrote: > > > > > > > For other kinds of filters, particularly those based > on filtering > > > > content, the burden _has_ to live in the definition of > > the filter. > > > > I'm not sure yet whether that means a filter has to be > > list agnostic. > > > > It may be that a filter can express "Do this if you > are a list, > > > > otherwise do that". > > > > > > I still assert that for the most common cases, you will > > want to apply > > > the same filter across all users in the list. In the cases > > where you > > > dont, the filter mechanism merely needs to provide the > ability to > > > specify per-user filters. > > > > > > > > > > > Back to rate limiting. The effect of A below for > presence is that > > > > if 10 of my buddies happen to change their presence state about > > > > the same time (which happens frequently at the end of > meetings), > > > > I won't find out about one of them until at least 10 > > minutes later. > > > > > > > > This points out value in being able to assert B as the > > right thing > > > > to do. > > > > > > Its the same point as above. A baseline rate limiting > > mechanism will > > > work for lists and single user presentities. It may not be > > sufficient > > > for all list subscriptions, in whcih case we could define > > additional > > > rate limiting mechanisms that define behavior on a > per-user basis. > > > > > > > So are you saying, then, that the default behavior is A > > (from earlier) > > but that we need to pass a requirement to sipping to be able > > to express > > a choice for B for the baseline rate limiting mechanism? > > > > Or are you saying that the baseline behavior is A, not > > matter what, and > > that if you want B behavior, you have to specify it in a package > > specific filter document? > > > > RjS > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 14:30:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27099 for ; Tue, 25 Mar 2003 14:30:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJoSV06406 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 14:50:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJoSO06403 for ; Tue, 25 Mar 2003 14:50:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27020 for ; Tue, 25 Mar 2003 14:29:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJn4O06263; Tue, 25 Mar 2003 14:49:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJhaO05902 for ; Tue, 25 Mar 2003 14:43:36 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26679 for ; Tue, 25 Mar 2003 14:22:40 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2PJOsTU006754; Tue, 25 Mar 2003 14:24:55 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 13:24:59 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645D6@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Avshalom Houri Cc: "'simple@ietf.org'" Subject: RE: [Simple] Urgent: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 13:24:59 -0600 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > I dont even think we need to go that far. I think that it should say > that a filter can appear in the body, and that work on > filters is still > under investigation. Period. We can have this nice long debate on the > meaning of filters in infinitely deep trees later on. You are making an erroneous assumption that the filter work will be SIP only. There is a growing need for notifiction filtering everywhere: SIP/SIMPLE, CalSched, VPIM, Lemonade, OPES, LDAP-EXT, IPP, WebDav, and XMPP have all had proposed working group items that touch on this topic. Hallway conversations I've had with reasonably well-connected individuals indicate that there is growing support for some sort of coordination of this work. Avshalom is correct in predicting that a working group may well surface around this topic. I'm certain that input for requirements will be solicited from all interested groups; however, if SIP has gone and done something that requires a particularly onerous requirement -- or one that cannot be generally understood -- it *will* be ignored in any such effort. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 15:27:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01538 for ; Tue, 25 Mar 2003 15:27:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKleK12541 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 15:47:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKleO12538 for ; Tue, 25 Mar 2003 15:47:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01501 for ; Tue, 25 Mar 2003 15:26:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKjZO12407; Tue, 25 Mar 2003 15:45:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKgxO12101 for ; Tue, 25 Mar 2003 15:42:59 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01257 for ; Tue, 25 Mar 2003 15:22:02 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2PKOGTU006806 for ; Tue, 25 Mar 2003 15:24:16 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 14:24:21 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645D7@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'simple@ietf.org'" Subject: RE: [Simple] Closing: Event Lists Open Issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:24:20 -0600 After a re-reading of the notes in this thread, and some private discussions, I'm convinced that we have largely reached a common conclusion. Almost no-one got there by the same logic, but the overall sentiment seems to be that we can safely close this topic, make no corresponding changes in the lists draft, and address any resultant issues once we start defining the nuts and bolts of filtering mechanisms. Thanks to those who gave input on the topic and to everyone else for tolerating the high-volume nature of the discussion. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 17:09:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06331 for ; Tue, 25 Mar 2003 17:09:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PMTf021301 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 17:29:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMTfO21298 for ; Tue, 25 Mar 2003 17:29:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06325 for ; Tue, 25 Mar 2003 17:08:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMRZO21209; Tue, 25 Mar 2003 17:27:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMHHO20645 for ; Tue, 25 Mar 2003 17:17:17 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05681 for ; Tue, 25 Mar 2003 16:56:17 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2PLwZ924629; Tue, 25 Mar 2003 15:58:35 -0600 Subject: Re: [Simple] Comments on draft-ietf-simple-event-list-00 From: Ben Campbell To: Sean Olson Cc: Adam Roach , Simple WG In-Reply-To: <000b01c2f2a0$54f9a050$6501a8c0@cranberry> References: <000b01c2f2a0$54f9a050$6501a8c0@cranberry> Content-Type: text/plain Message-Id: <1048629444.2534.32.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 25 Mar 2003 15:57:24 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2003-03-25 at 01:29, Sean Olson wrote: [...] > 2) Why do you allow a list with 0 resource elements? I could not think of a > use case for this. > (If there is no reason, the schema should be changed to have a minOccurs > of 1) I can imagine an empty list existing. For example, a provisioned list that has not yet had entries added, or one where all the entries have been deleted. For example, I might get a brand new account from a service provider, and subscribe to my contact list that is initially empty. As I add contacts to the list, possibly through some other interface, my client gets NOTIFY requests telling it about the new entries. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 18:05:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09087 for ; Tue, 25 Mar 2003 18:05:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PNQCn25965 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 18:26:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNQCO25962 for ; Tue, 25 Mar 2003 18:26:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09029 for ; Tue, 25 Mar 2003 18:05:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNO6O25902; Tue, 25 Mar 2003 18:24:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNNjO25836 for ; Tue, 25 Mar 2003 18:23:45 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08777 for ; Tue, 25 Mar 2003 18:02:42 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2PN4uTU006998; Tue, 25 Mar 2003 18:04:56 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 17:05:03 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645DA@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'seancolson@yahoo.com'" , Adam Roach , simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Comments on draft-ietf-simple-event-list-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 17:05:01 -0600 Sean Olson [mailto:seancolson@yahoo.com] writes: > Comments on draft-ietf-simple-event-list-00: > > 1) Here is a slightly cleaned up XML schema: Excellent. Thank you. > NOTE: You will probably want to add an IANA registration for the XML > namespace > (urn:ietf:params:xml:ns:rlmi) similar to the one found in the > CPIM-PIDF > draft Added. > I've thrown in anyAttribute in a couple of spots as well as > the any element > for the > element definition. I don't know offhand what these mean, but assume they afford some degree of extensibility. That seems good. > 2) Why do you allow a list with 0 resource elements? I could > not think of a > use case for this. > (If there is no reason, the schema should be changed to > have a minOccurs > of 1) You get notifications when a resource is added to or removed from a list. If the last member is removed from a list, the way to express that is to send meta-information which contains no resources. > 3) It would be nice to pass along a preference to disable > forking of event > packages that > support it. I'm assuming a Request-Disposition: header ala > caller prefs > would be sufficient. This > seems more critical for the RLS than for the subscriber. Instructing forking proxies not to fork is a more general SIP problem that we can't solve here. > Is it reasonable > for the RLS to request > non-forking of the resource SUBSCRIBEs even if the initial > subscriber did > not? The way that RLSes handle back-end subscriptions is completely their own business. If they want to shut down multiple legs just because they feel like it, that's fine (as long as it doesn't contravene any normative language in the corresponding event package). > 4) In the event that one of the resource subscriptions from > the RLS gets > terminated, the subscriber > does not seem to have any option but to un-SUBSCRIBE and > re-SUBSCRIBE in > the hope of refreshing the > resource subscription. Is there another way? Once again, the way that an RLS handles any back-end subscriptions is its own business, but I would argue that any implementation that didn't keep such subscriptions alive for as long as possible (e.g. performing appropriate recovery when they terminated) is poorly designed. I would certainly *not* recommend having a client re-subscribe to try to clear such a case. > 5) One of the problems that was given as motivation for the > draft in the > Introduction: > > o If a subscriber has only intermittent connectivity, and > generally > polls for state rather than simply subscribing, the latency to > obtain the state of the entire resource can be large. The > messaging required for each poll can also be substantial. > > does not seem to be solved by this mechanism. If connectivity is > intermittent, how would an RLS help? You can poll. This works exceptionally well if the RLS also hosts the resources (as will often be the case in networks exhibiting this behavior). Because you're only having to poll the list instead of each individual resource, you do end up having a savings in overhead that can be considerable for a large list. > 6) The specification of a charset parameter in the Content-Type seems > redundant for the XML payload. > For example: > > Content-Type: application/rlmi+xml;charset="UTF-8" > > > > (Just a small nit) RFC 3023 recommends inclusion of the charset parameter on Content-Type headers for XML body types: Although listed as an optional parameter, the use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the character encoding of the XML MIME entity. ... Conformant with [RFC2046], if a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of "us-ascii". As I read it, omission of a "charset" parameter on the "Content-Type" header would *override* any internally-contained "encoding" attribute with "us-ascii". Certainly not what we want. Should I include a discussion of this topic in the lists draft? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 18:49:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11652 for ; Tue, 25 Mar 2003 18:49:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q09gO29584 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 19:09:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q09gO29581 for ; Tue, 25 Mar 2003 19:09:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11627 for ; Tue, 25 Mar 2003 18:48:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q07cO29400; Tue, 25 Mar 2003 19:07:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNuwO28237 for ; Tue, 25 Mar 2003 18:56:58 -0500 Received: from web41501.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11129 for ; Tue, 25 Mar 2003 18:35:55 -0500 (EST) Message-ID: <20030325233816.28752.qmail@web41501.mail.yahoo.com> Received: from [131.107.3.78] by web41501.mail.yahoo.com via HTTP; Tue, 25 Mar 2003 15:38:16 PST From: Sean Olson Subject: Re: [Simple] RE: Comments on draft-ietf-simple-event-list-00 To: Adam Roach , simple@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645DA@dyn-tx-exch-001.dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 15:38:16 -0800 (PST) > > 5) One of the problems that was given as > motivation for the > > draft in the > > Introduction: > > > > o If a subscriber has only intermittent > connectivity, and > > generally > > polls for state rather than simply > subscribing, the latency to > > obtain the state of the entire resource can > be large. The > > messaging required for each poll can also be > substantial. > > > > does not seem to be solved by this mechanism. > If connectivity is > > intermittent, how would an RLS help? > > You can poll. This works exceptionally well if the > RLS also hosts > the resources (as will often be the case in networks > exhibiting > this behavior). > > Because you're only having to poll the list instead > of each > individual resource, you do end up having a savings > in > overhead that can be considerable for a large list. I guess I was confused because it seems like polling with an RLS can (depending on the implementation of the RLS) be somewhat useless. The draft alludes to this at one point. [snip] > Should I include a discussion of this topic in the > lists draft? Nope. Your answer makes it clear why this is needed and desirable. Thanks! > > /a __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 19:13:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12511 for ; Tue, 25 Mar 2003 19:13:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q0YCA31114 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 19:34:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0YCO31111 for ; Tue, 25 Mar 2003 19:34:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12487 for ; Tue, 25 Mar 2003 19:13:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0Y8O31103; Tue, 25 Mar 2003 19:34:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0XRO31082 for ; Tue, 25 Mar 2003 19:33:27 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12478 for ; Tue, 25 Mar 2003 19:12:23 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2Q0EdTU007065; Tue, 25 Mar 2003 19:14:39 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 18:14:44 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645DD@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Sean Olson'" , Adam Roach , simple@ietf.org Cc: Jonathan Rosenberg , Ben Campbell Subject: RE: [Simple] RE: Comments on draft-ietf-simple-event-list-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 18:14:43 -0600 Sean> 5) One of the problems that was given as Sean> motivation for the draft in the Introduction: Sean> Sean> o If a subscriber has only intermittent Sean> connectivity, and generally Sean> polls for state rather than simply Sean> subscribing, the latency to Sean> obtain the state of the entire resource can Sean> be large. The messaging required for each Sean> poll can also be substantial. Adam> You can poll. This works exceptionally well if the Adam> RLS also hosts the resources (as will often be the Adam> case in networks exhibiting this behavior). Adam> Adam> Because you're only having to poll the list instead Adam> of each individual resource, you do end up having Adam> a savings in overhead that can be considerable for Adam> a large list. Sean> I guess I was confused because it seems like polling Sean> with an RLS can (depending on the implementation of Sean> the RLS) be somewhat useless. The draft alludes to Sean> this at one point. That's true. It depends greatly on whether one can know a priori whether the RLS will also serve the resources. Since this really is only the case in a closed system, I don't have any problem with taking out this particular bullet point. I didn't write that part of the document, though: Jonthan? Ben? Do either of you object to removing this bullet? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Mar 25 21:13:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15111 for ; Tue, 25 Mar 2003 21:13:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q2YGs06161 for simple-archive@odin.ietf.org; Tue, 25 Mar 2003 21:34:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q2YGO06158 for ; Tue, 25 Mar 2003 21:34:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15102 for ; Tue, 25 Mar 2003 21:13:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q2YAO06140; Tue, 25 Mar 2003 21:34:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q2VnO06050 for ; Tue, 25 Mar 2003 21:31:49 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15072 for ; Tue, 25 Mar 2003 21:10:44 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2Q2Cx928160; Tue, 25 Mar 2003 20:12:59 -0600 Subject: RE: [Simple] RE: Comments on draft-ietf-simple-event-list-00 From: Ben Campbell To: Adam Roach Cc: "'Sean Olson'" , Simple WG , Jonathan Rosenberg In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645DD@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645DD@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048644766.1524.8.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 25 Mar 2003 20:12:46 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2003-03-25 at 18:14, Adam Roach wrote: > Sean> 5) One of the problems that was given as > Sean> motivation for the draft in the Introduction: > Sean> > Sean> o If a subscriber has only intermittent > Sean> connectivity, and generally > Sean> polls for state rather than simply > Sean> subscribing, the latency to > Sean> obtain the state of the entire resource can > Sean> be large. The messaging required for each > Sean> poll can also be substantial. > > Adam> You can poll. This works exceptionally well if the > Adam> RLS also hosts the resources (as will often be the > Adam> case in networks exhibiting this behavior). > Adam> > Adam> Because you're only having to poll the list instead > Adam> of each individual resource, you do end up having > Adam> a savings in overhead that can be considerable for > Adam> a large list. > > Sean> I guess I was confused because it seems like polling > Sean> with an RLS can (depending on the implementation of > Sean> the RLS) be somewhat useless. The draft alludes to > Sean> this at one point. > > That's true. It depends greatly on whether one can > know a priori whether the RLS will also serve the > resources. Since this really is only the case > in a closed system, I don't have any problem with > taking out this particular bullet point. > > I didn't write that part of the document, though: > Jonthan? Ben? Do either of you object to removing > this bullet? It is equally possible to build RLS implementations where polling is very useful. Even if the RLS does not have authoritative knowledge of all the list members, nothing forces the RLS to associate back-end subscription lifetimes with the list subscription lifetime. So you could build an RLS where the first poll attempt triggers back-end subscriptions. The first poll would not net much, but subsequent polls could be _very_ useful. However, I can accept that a motivation that is so highly implementation dependent is fairly weak, so I do not object to removing or softening it. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 03:18:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17850 for ; Wed, 26 Mar 2003 03:18:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q8dMV07408 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 03:39:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q8dMO07405 for ; Wed, 26 Mar 2003 03:39:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17846 for ; Wed, 26 Mar 2003 03:18:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q8dFO07390; Wed, 26 Mar 2003 03:39:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q8cJO07350 for ; Wed, 26 Mar 2003 03:38:19 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17835 for ; Wed, 26 Mar 2003 03:17:06 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2Q8NEX16429 for ; Wed, 26 Mar 2003 10:23:14 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Mar 2003 10:19:25 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 10:19:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] RE: Comments on draft-ietf-simple-event-list-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7434@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: Comments on draft-ietf-simple-event-list-00 Thread-Index: AcLzPa2rGTZSq6qaRvqekDJaaYqxPQAMhPJg To: , Cc: , , X-OriginalArrivalTime: 26 Mar 2003 08:19:24.0957 (UTC) FILETIME=[695FD4D0:01C2F370] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2Q8cJO07351 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:19:24 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit A separate issue: I build a list then I subscribe to the list. I start receiving notifications. During the subscription, I add a new member to the list. When does this become effective? I mean when would I start receiving notifications about this new member? a) Immediately b) After a subscription refresh? c) After a new subscription? Should there be some discussion in the draft about this? or is this implementation specific? Regards, Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, March 26, 2003 4:13 AM > To: Adam Roach > Cc: 'Sean Olson'; Simple WG; Jonathan Rosenberg > Subject: RE: [Simple] RE: Comments on draft-ietf-simple-event-list-00 > > > On Tue, 2003-03-25 at 18:14, Adam Roach wrote: > > Sean> 5) One of the problems that was given as > > Sean> motivation for the draft in the Introduction: > > Sean> > > Sean> o If a subscriber has only intermittent > > Sean> connectivity, and generally > > Sean> polls for state rather than simply > > Sean> subscribing, the latency to > > Sean> obtain the state of the entire resource can > > Sean> be large. The messaging required for each > > Sean> poll can also be substantial. > > > > Adam> You can poll. This works exceptionally well if the > > Adam> RLS also hosts the resources (as will often be the > > Adam> case in networks exhibiting this behavior). > > Adam> > > Adam> Because you're only having to poll the list instead > > Adam> of each individual resource, you do end up having > > Adam> a savings in overhead that can be considerable for > > Adam> a large list. > > > > Sean> I guess I was confused because it seems like polling > > Sean> with an RLS can (depending on the implementation of > > Sean> the RLS) be somewhat useless. The draft alludes to > > Sean> this at one point. > > > > That's true. It depends greatly on whether one can > > know a priori whether the RLS will also serve the > > resources. Since this really is only the case > > in a closed system, I don't have any problem with > > taking out this particular bullet point. > > > > I didn't write that part of the document, though: > > Jonthan? Ben? Do either of you object to removing > > this bullet? > > It is equally possible to build RLS implementations where polling is > very useful. Even if the RLS does not have authoritative knowledge of > all the list members, nothing forces the RLS to associate back-end > subscription lifetimes with the list subscription lifetime. > So you could > build an RLS where the first poll attempt triggers back-end > subscriptions. The first poll would not net much, but subsequent polls > could be _very_ useful. > > However, I can accept that a motivation that is so highly > implementation > dependent is fairly weak, so I do not object to removing or softening > it. > > > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 06:41:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21880 for ; Wed, 26 Mar 2003 06:41:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QC2Fb21265 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 07:02:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QC2FO21262 for ; Wed, 26 Mar 2003 07:02:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21869 for ; Wed, 26 Mar 2003 06:40:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QC29O21253; Wed, 26 Mar 2003 07:02:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QC1iO21229 for ; Wed, 26 Mar 2003 07:01:44 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21863 for ; Wed, 26 Mar 2003 06:40:27 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2QBkZX07482 for ; Wed, 26 Mar 2003 13:46:35 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 26 Mar 2003 13:42:47 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 13:42:45 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019451DC@esebe013.ntc.nokia.com> Thread-Topic: [Simple] RE: Comments on draft-ietf-simple-event-list-00 Thread-Index: AcLzPa2rGTZSq6qaRvqekDJaaYqxPQAMhPJgAAbP+gA= To: X-OriginalArrivalTime: 26 Mar 2003 11:42:45.0709 (UTC) FILETIME=[D196D7D0:01C2F38C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QC1iO21230 Subject: [Simple] Event header params in event list subscriptions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 13:42:45 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Chapter 3.2 of the event list draft talks about Event header params, and suggests that all parameters are propagated towards the leaf subscriptions. Is this a good idea? As an example, if an event throttle would in fact be an Event header parameter, should it be propagated, or should it instead be applied only to the root subscription? Would a propagated throttle in fact be applied at multiple levels, virtually quenching the list? Also, it could be a problem if the RLS does support a specific parameter, but none of the other nodes/leafs do. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 09:49:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28193 for ; Wed, 26 Mar 2003 09:49:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QFASk03701 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 10:10:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFASO03698 for ; Wed, 26 Mar 2003 10:10:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28133 for ; Wed, 26 Mar 2003 09:49:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFAIO03685; Wed, 26 Mar 2003 10:10:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QF9HO03621 for ; Wed, 26 Mar 2003 10:09:17 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28006 for ; Wed, 26 Mar 2003 09:47:56 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2QEoG906160 for ; Wed, 26 Mar 2003 08:50:16 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1048690208.934.26.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Call for availability: Interim meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Mar 2003 08:50:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks - As mentioned at our meeting in IETF56 we are going to hold an interim meeting between now and IETF57. We're planning a two day session, but need to choose the actual dates. Location will depend on the dates, but will probably be in eastern Canada. If, and _only_ if, you are definitely planning to attend please reply to me PRIVATELY by Friday with your availability between May 12 and June 13. We'll find a date that accomodates as many responders as possible. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 10:14:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29957 for ; Wed, 26 Mar 2003 10:14:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QFZCp04771 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 10:35:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFZCO04768 for ; Wed, 26 Mar 2003 10:35:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29896 for ; Wed, 26 Mar 2003 10:13:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFZ6O04759; Wed, 26 Mar 2003 10:35:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFYOO04700 for ; Wed, 26 Mar 2003 10:34:24 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29794 for ; Wed, 26 Mar 2003 10:13:04 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2QFFO906582 for ; Wed, 26 Mar 2003 09:15:24 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1048691715.934.32.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Draft minutes from the SIMPLE IETF56 meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Mar 2003 09:15:15 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The minutes from the SIMPLE IETF56 meeting are available at http://www.softarmor.com/simple/meets/ietf56/notes/ RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 12:54:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05377 for ; Wed, 26 Mar 2003 12:54:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QIFMg18273 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 13:15:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIFMO18270 for ; Wed, 26 Mar 2003 13:15:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05350 for ; Wed, 26 Mar 2003 12:53:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIFGO18253; Wed, 26 Mar 2003 13:15:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIEMO18201 for ; Wed, 26 Mar 2003 13:14:22 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05306 for ; Wed, 26 Mar 2003 12:52:57 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2QHtCTU008220; Wed, 26 Mar 2003 12:55:12 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 11:55:18 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645E1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'aki.niemi@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Event header params in event list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 11:55:17 -0600 This is part of the open issue we just closed. You might have noticed a recent thread entitled, "Urgent: Event Lists Open Issue;" it covers exactly this topic. The short answer: this is being removed, and will be resolved by the filtering work. /a > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Wednesday, March 26, 2003 5:43 > To: simple@ietf.org > Subject: [Simple] Event header params in event list subscriptions > > > Hi, > > Chapter 3.2 of the event list draft talks about Event header > params, and suggests that all parameters are propagated > towards the leaf subscriptions. Is this a good idea? > > As an example, if an event throttle would in fact be an Event > header parameter, should it be propagated, or should it > instead be applied only to the root subscription? Would a > propagated throttle in fact be applied at multiple levels, > virtually quenching the list? > > Also, it could be a problem if the RLS does support a > specific parameter, but none of the other nodes/leafs do. > > Cheers, > Aki > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 13:50:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07047 for ; Wed, 26 Mar 2003 13:50:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJBJ323253 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 14:11:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJBJO23250 for ; Wed, 26 Mar 2003 14:11:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07033 for ; Wed, 26 Mar 2003 13:49:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJBFO23231; Wed, 26 Mar 2003 14:11:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJAIO23178 for ; Wed, 26 Mar 2003 14:10:18 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06991 for ; Wed, 26 Mar 2003 13:48:51 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2QIp9909665; Wed, 26 Mar 2003 12:51:09 -0600 Subject: RE: [Simple] Event header params in event list subscriptions From: Robert Sparks To: Adam Roach Cc: "'aki.niemi@nokia.com'" , simple@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645E1@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645E1@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048704659.1905.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Mar 2003 12:51:00 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki actually participated in the thread you call out. Step away from the example he gave and look at the question again. Suppose an event carries parameters on the Event header that somehow affect processing the subscription. Suppose further that there might be an effect that can't be characterized as "filtering". What then? The answer certainly isn't going to come out of the filtering work. The same type of question can be applied to other parts of the message, Require or Accept for example. Those are all useful questions to ask, but I believe the answers to each of them are going to be implementation specific (Remember that an RLS might well be responsible for all the "leaves" and never have to go off-board for more information, or may go off-board using not-SIP). This draft doesn't need to specify the details of how this back-end part of an RLS behaves. In summary - I agree that the point should be removed. These questions will be addressed as needed in other contexts. RjS On Wed, 2003-03-26 at 11:55, Adam Roach wrote: > This is part of the open issue we just closed. You might > have noticed a recent thread entitled, "Urgent: Event Lists > Open Issue;" it covers exactly this topic. > > The short answer: this is being removed, and will be > resolved by the filtering work. > > /a > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Wednesday, March 26, 2003 5:43 > > To: simple@ietf.org > > Subject: [Simple] Event header params in event list subscriptions > > > > > > Hi, > > > > Chapter 3.2 of the event list draft talks about Event header > > params, and suggests that all parameters are propagated > > towards the leaf subscriptions. Is this a good idea? > > > > As an example, if an event throttle would in fact be an Event > > header parameter, should it be propagated, or should it > > instead be applied only to the root subscription? Would a > > propagated throttle in fact be applied at multiple levels, > > virtually quenching the list? > > > > Also, it could be a problem if the RLS does support a > > specific parameter, but none of the other nodes/leafs do. > > > > Cheers, > > Aki > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 15:31:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13013 for ; Wed, 26 Mar 2003 15:31:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QKqIS31674 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 15:52:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QKqIO31671 for ; Wed, 26 Mar 2003 15:52:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12988 for ; Wed, 26 Mar 2003 15:30:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QKqDO31659; Wed, 26 Mar 2003 15:52:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QKpvO31617 for ; Wed, 26 Mar 2003 15:51:57 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12979 for ; Wed, 26 Mar 2003 15:30:29 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2QKWbTU008359; Wed, 26 Mar 2003 15:32:38 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 14:32:42 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645E5@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , Adam Roach Cc: "'aki.niemi@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Event header params in event list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 14:32:41 -0600 From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Step away from the example he gave and look at the question > again. Suppose an event carries parameters on the Event header > that somehow affect processing the subscription. Suppose further > that there might be an effect that can't be characterized as > "filtering". What then? The answer certainly isn't going to > come out of the filtering work. It's not obvious to me that such parameters could be characterized as anything other than filtering. Can you provide an example? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 15:52:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13863 for ; Wed, 26 Mar 2003 15:52:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QLCvv01243 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 16:12:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLCuO01240 for ; Wed, 26 Mar 2003 16:12:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13834 for ; Wed, 26 Mar 2003 15:51:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLCpO01221; Wed, 26 Mar 2003 16:12:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QL9lO00982 for ; Wed, 26 Mar 2003 16:09:47 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13731 for ; Wed, 26 Mar 2003 15:48:20 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2QKob911376; Wed, 26 Mar 2003 14:50:37 -0600 Subject: RE: [Simple] Event header params in event list subscriptions From: Robert Sparks To: Adam Roach Cc: "'aki.niemi@nokia.com'" , simple@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A645E5@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A645E5@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1048711826.1905.48.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Mar 2003 14:50:27 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Off the top of my head, no. But, we put an extension point on the Event header field. Are you comfortable saying that no one will ever find a use for it that isn't an expression of a filter? I'm not. If you convince me that such parameters can only be filters, and we determine that bodies are the right place to express filters (which is the direction I think we're taking) then I'll argue to remove the ability to carry parameters in that header field. I don't think you're disagreeing with the action plan to remove the point that started this thread from the document though, right? RjS On Wed, 2003-03-26 at 14:32, Adam Roach wrote: > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > Step away from the example he gave and look at the question > > again. Suppose an event carries parameters on the Event header > > that somehow affect processing the subscription. Suppose further > > that there might be an effect that can't be characterized as > > "filtering". What then? The answer certainly isn't going to > > come out of the filtering work. > > It's not obvious to me that such parameters could be characterized > as anything other than filtering. Can you provide an example? > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Mar 26 16:33:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16003 for ; Wed, 26 Mar 2003 16:33:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QLsFX04904 for simple-archive@odin.ietf.org; Wed, 26 Mar 2003 16:54:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLsFO04900 for ; Wed, 26 Mar 2003 16:54:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15972 for ; Wed, 26 Mar 2003 16:32:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLs9O04886; Wed, 26 Mar 2003 16:54:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLrTO04846 for ; Wed, 26 Mar 2003 16:53:29 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15952 for ; Wed, 26 Mar 2003 16:32:01 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2QLYCTU008440; Wed, 26 Mar 2003 16:34:12 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 15:34:17 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A645E8@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , Adam Roach Cc: "'aki.niemi@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Event header params in event list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 15:34:16 -0600 No, I'll still remove it. /a > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, March 26, 2003 14:50 > To: Adam Roach > Cc: 'aki.niemi@nokia.com'; simple@ietf.org > Subject: RE: [Simple] Event header params in event list subscriptions > > > Off the top of my head, no. But, we put an extension point on the > Event header field. Are you comfortable saying that no one will > ever find a use for it that isn't an expression of a filter? I'm > not. > > If you convince me that such parameters can only be filters, and > we determine that bodies are the right place to express filters > (which is the direction I think we're taking) then I'll argue to > remove the ability to carry parameters in that header field. > > I don't think you're disagreeing with the action plan to remove > the point that started this thread from the document though, right? > > RjS > > On Wed, 2003-03-26 at 14:32, Adam Roach wrote: > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > > Step away from the example he gave and look at the question > > > again. Suppose an event carries parameters on the Event header > > > that somehow affect processing the subscription. Suppose further > > > that there might be an effect that can't be characterized as > > > "filtering". What then? The answer certainly isn't going to > > > come out of the filtering work. > > > > It's not obvious to me that such parameters could be characterized > > as anything other than filtering. Can you provide an example? > > > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 27 00:53:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04471 for ; Thu, 27 Mar 2003 00:53:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R6EIK08441 for simple-archive@odin.ietf.org; Thu, 27 Mar 2003 01:14:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6EHO08438 for ; Thu, 27 Mar 2003 01:14:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04423 for ; Thu, 27 Mar 2003 00:52:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6ECO08428; Thu, 27 Mar 2003 01:14:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6DFO08376 for ; Thu, 27 Mar 2003 01:13:15 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04408 for ; Thu, 27 Mar 2003 00:51:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2R5s1Bd005836; Thu, 27 Mar 2003 00:54:01 -0500 (EST) Message-ID: <3E8291F3.4000107@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: Adam Roach , "'Sean Olson'" , Simple WG Subject: Re: [Simple] RE: Comments on draft-ietf-simple-event-list-00 References: <9BF66EBF6BEFD942915B4D4D45C051F3A645DD@dyn-tx-exch-001.dynamicsoft.com> <1048644766.1524.8.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 00:53:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: >> >>Sean> I guess I was confused because it seems like polling >>Sean> with an RLS can (depending on the implementation of >>Sean> the RLS) be somewhat useless. The draft alludes to >>Sean> this at one point. >> >>That's true. It depends greatly on whether one can >>know a priori whether the RLS will also serve the >>resources. Since this really is only the case >>in a closed system, I don't have any problem with >>taking out this particular bullet point. >> >>I didn't write that part of the document, though: >>Jonthan? Ben? Do either of you object to removing >>this bullet? > > > It is equally possible to build RLS implementations where polling is > very useful. Even if the RLS does not have authoritative knowledge of > all the list members, nothing forces the RLS to associate back-end > subscription lifetimes with the list subscription lifetime. So you could > build an RLS where the first poll attempt triggers back-end > subscriptions. The first poll would not net much, but subsequent polls > could be _very_ useful. > > However, I can accept that a motivation that is so highly implementation > dependent is fairly weak, so I do not object to removing or softening > it. I think it has to go one of two ways. Either we say a LOT more about recommended ways to build the back-ends of such systems, so that a subscriber can expect better poll behavior, or, we say nothing about the back-ends, and then the motivation doesnt make sense. I vote for the latter, and so would prefer to remove the bullet. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Mar 27 00:55:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04646 for ; Thu, 27 Mar 2003 00:55:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R6H5f08563 for simple-archive@odin.ietf.org; Thu, 27 Mar 2003 01:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6H5O08560 for ; Thu, 27 Mar 2003 01:17:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04624 for ; Thu, 27 Mar 2003 00:55:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6H1O08550; Thu, 27 Mar 2003 01:17:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6F2O08498 for ; Thu, 27 Mar 2003 01:15:02 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04503 for ; Thu, 27 Mar 2003 00:53:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2R5tlBd005839; Thu, 27 Mar 2003 00:55:48 -0500 (EST) Message-ID: <3E82925E.3070808@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: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, adam@dynamicsoft.com, seancolson@yahoo.com, simple@ietf.org Subject: Re: [Simple] RE: Comments on draft-ietf-simple-event-list-00 References: <2038BCC78B1AD641891A0D1AE133DBB7FE7434@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 00:55:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > A separate issue: > > I build a list then I subscribe to the list. I start receiving notifications. During the subscription, I add a new member to the list. When does this become effective? I mean when would I start receiving notifications about this new member? > > a) Immediately > b) After a subscription refresh? > c) After a new subscription? The answer is (a) if you want a useful system. > > Should there be some discussion in the draft about this? or is this implementation specific? I think its worth mentioning in the draft that the list could change during the lifetime of the subscription, in which case the RLS should take the appropriate actions as soon as possible. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Mar 28 20:43:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28262 for ; Fri, 28 Mar 2003 20:43:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2T25JL26459 for simple-archive@odin.ietf.org; Fri, 28 Mar 2003 21:05:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T25JO26456 for ; Fri, 28 Mar 2003 21:05:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28229 for ; Fri, 28 Mar 2003 20:42:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T25FO26448; Fri, 28 Mar 2003 21:05:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T24JO26404 for ; Fri, 28 Mar 2003 21:04:19 -0500 Received: from mail4.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28211 for ; Fri, 28 Mar 2003 20:41:47 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h2T1i3n4000605 for ; Fri, 28 Mar 2003 20:44:03 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Mar 2003 19:44:09 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64608@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] New Event Lists Draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Mar 2003 19:44:07 -0600 A new events list draft has been submitted to the internet-drafts editor. Until it becomes available in the archives, you may retrieve a copy from: An HTML version is available at: This draft incorporates the resolution of the recent discussion on filtering, adds a hook for including aggregate states, and cleans up the XML definition significantly. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 31 07:31:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04567 for ; Mon, 31 Mar 2003 07:31:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VCsOg32263 for simple-archive@odin.ietf.org; Mon, 31 Mar 2003 07:54:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VCsOO32260 for ; Mon, 31 Mar 2003 07:54:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04551 for ; Mon, 31 Mar 2003 07:30:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VCsGO32252; Mon, 31 Mar 2003 07:54:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VCrdO32237 for ; Mon, 31 Mar 2003 07:53:39 -0500 Received: from il-tlv-smtpout2.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04537 for ; Mon, 31 Mar 2003 07:29:52 -0500 (EST) Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h2VCW8S19654 for ; Mon, 31 Mar 2003 15:32:08 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Mon, 31 Mar 2003 15:32:16 +0300 Message-ID: <385D702A9C11D511A9E90008C7160AD5054541DF@ISMAIL1> From: Cnaan Oded To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F781.8F2D8684" Subject: [Simple] Tuple references and device coupling Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 15:32:15 +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_01C2F781.8F2D8684 Content-Type: text/plain; charset="windows-1255" Although the question "what a tuple represents" has not been discussed in depth yet, it seems that most implementation have chosen to either represent devices or services. For example, a tuple may represent a cell phone but can also represent an IM client running on a mobile phone. Here is a simple example of 2 such tuples: open tel:09012345678 open busy sip:user@domain.com There are cases where there is a relationship between these tuples. For example, in the above example, the IM client is running on the same device described by the first tuple, meaning that there might be some information (e.g., location) that is related to both tuples. One approach to handle it would be to duplicate this information. Having 'Location' described in the tuple representing the device as well as the one representing the service. This approach is not efficient in terms of volume as many tuples might relate to the same information. Another possible solution would be to create a reference between tuples, in this example between a "service tuple" and a "device tuple". In this case, the information is described only once but is referenced from other tuples. For example: open busy sip:user@domain.com Following the latter option, the device status, location, LCD resolution or any other attributes associated with the device may be picked up from the "phone" tuple so that the "mobile-im" tuple represents only the service characteristics. Following the above example, if the user is on a call, and his device state changes from "open" to "call" (assuming this is a valid value), the "phone" tuple is the only one that changes (and will be included in the NOTIFY). The IM watcher would be able to deduce on which device the client is running and therefore its state (and location...). Although IM was used in the example, it may imply to any other service such as Voicemail, Calendar, PTT, Address book, MMS etc. Note that not all services are associated with devices. An email service, for example, may be self sufficient as there is no real meaning to instant or direct communications and since the session is transient. Another related issue that calls for attention is the ability to create coupling between services and the device they are currently using. For example, assuming a user that has 2 phones, only one with a PTT client, turns on both phones, the PTT service needs to be able to inform the presence server not only that it is active but also on which of the devices (of course that this info is subject to privacy policy as any other information element). Having the ability to tie a service to a device allows the PS to perform advanced compositions. For example, in the previous example, the PS may automatically change the PTT state to busy when the user is on a voice call without having the client to publish anything (using network agents). This may also be useful when aggregating additional presence info that is not intrinsic to the service (e.g., location). Oded Cnaan ------_=_NextPart_001_01C2F781.8F2D8684 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Although the=20 question "what a tuple represents" has not been discussed in depth = yet, it=20 seems that most implementation have chosen to either represent devices = or=20 services. For example, a tuple may represent a cell phone but can also = represent=20 an IM client running on a mobile phone.
 
Here is a=20 simple example of 2 such tuples:
 
<?xml=20 version=3D"1.0" encoding=3D"UTF-8"?>
<presence=20 xmlns=3D"urn:ietf:params:xml:ns:cpim-pidf"
 =20 entity=3D"pres:someone@example.com">
  =20 <tuple id=3D"phone">
     =20 <status>
        =20 <basic>open</basic>
     =20 </status>
     =20 <contact>tel:09012345678</contact>
  =20  </tuple>
 
  =20 <tuple id=3D"mobile-im">
     =20 <status>
        =20 <basic>open</basic>
         <im:i= m>busy</im:im>
     =20 </status>
     =20 <contact>sip:user@domain.com</contact>
  =20  </tuple>
 
</presence>

There are=20 cases where there is a relationship between these tuples. For example, = in the=20 above example, the IM client is running on the same device described by = the=20 first tuple, meaning that there might be some information (e.g., = location) that=20 is related to both tuples.
 
One approach=20 to handle it would be to duplicate this information. Having 'Location' = described=20 in the tuple representing the device as well as the one representing = the=20 service. This approach is not efficient in terms of volume as many = tuples might=20 relate to the same information.
 
Another=20 possible solution would be to create a reference between tuples, = in this=20 example between a "service tuple" and a "device tuple". In this case, = the=20 information is described only once but is referenced from other tuples. = For=20 example:
 
  =20 <tuple id=3D"mobile-im" ref=3D"phone">
    &nbs= p;=20 <status>
        =20 <basic>open</basic>
         <im:i= m>busy</im:im>
     =20 </status>
     =20 <contact>sip:user@domain.com</contact>
  =20  </tuple>
 
Following the=20 latter option, the device status, location, LCD resolution or any other = attributes associated with the device may be picked up from the "phone" = tuple so=20 that the "mobile-im" tuple represents only the service=20 characteristics.
 
Following the=20 above example, if the user is on a call, and his device state changes = from=20 "open" to "call" (assuming this is a valid value), the "phone" tuple is = the only=20 one that changes (and will be included in the NOTIFY). The IM watcher = would be=20 able to deduce on which device the client is running and therefore its = state=20 (and location...).
 
Although IM=20 was used in the example, it may imply to any other service such as = Voicemail,=20 Calendar, PTT, Address book, MMS etc.
 
Note that not=20 all services are associated with devices. An email service, for = example, may be=20 self sufficient as there is no real meaning to instant or direct = communications=20 and since the session is transient.
 
Another=20 related issue that calls for attention is the ability to create = coupling between=20 services and the device they are currently using. For example, assuming = a user=20 that has 2 phones, only one with a PTT client, turns on both = phones, the=20 PTT service needs to be able to inform the presence server not only = that it is=20 active but also on which of the devices (of course that this info is = subject to=20 privacy policy as any other information element).
 
Having the=20 ability to tie a service to a device allows the PS to perform advanced=20 compositions. For example, in the previous example, the PS may = automatically=20 change the PTT state to busy when the user is on a voice call without = having the=20 client to publish anything (using network agents). This may also be = useful when=20 aggregating additional presence info that is not intrinsic to the = service (e.g.,=20 location).
 
 
Oded = Cnaan
 
------_=_NextPart_001_01C2F781.8F2D8684-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 31 11:46:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13826 for ; Mon, 31 Mar 2003 11:46:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VH9fe19576 for simple-archive@odin.ietf.org; Mon, 31 Mar 2003 12:09:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VH9fT19573 for ; Mon, 31 Mar 2003 12:09:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13811 for ; Mon, 31 Mar 2003 11:45:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VH9bT19542; Mon, 31 Mar 2003 12:09:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VH0YO17992 for ; Mon, 31 Mar 2003 12:00:34 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13439 for ; Mon, 31 Mar 2003 11:36:44 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h2VGd8917810; Mon, 31 Mar 2003 10:39:08 -0600 Subject: WGLC Imminent: Re: [Simple] New Event Lists Draft From: Robert Sparks To: Adam Roach Cc: "'simple@ietf.org'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64608@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A64608@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1049128723.1034.16.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 31 Mar 2003 10:38:44 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks - Last call on this document will begin as soon as it shows up in the I-D repository. Please feel free to review and comment now. RjS On Fri, 2003-03-28 at 19:44, Adam Roach wrote: > A new events list draft has been submitted to the internet-drafts > editor. Until it becomes available in the archives, you may > retrieve a copy from: > > > > > An HTML version is available at: > > l> > > This draft incorporates the resolution of the recent discussion > on filtering, adds a hook for including aggregate states, and > cleans up the XML definition significantly. > > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 31 12:18:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15141 for ; Mon, 31 Mar 2003 12:18:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VHfNG22613 for simple-archive@odin.ietf.org; Mon, 31 Mar 2003 12:41:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VHfNT22610 for ; Mon, 31 Mar 2003 12:41:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15133 for ; Mon, 31 Mar 2003 12:17:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VHfET22579; Mon, 31 Mar 2003 12:41:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VHeJT22510 for ; Mon, 31 Mar 2003 12:40:19 -0500 Received: from web41511.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15110 for ; Mon, 31 Mar 2003 12:16:29 -0500 (EST) Message-ID: <20030331171853.71515.qmail@web41511.mail.yahoo.com> Received: from [131.107.3.72] by web41511.mail.yahoo.com via HTTP; Mon, 31 Mar 2003 09:18:53 PST From: Sean Olson Subject: Re: [Simple] Tuple references and device coupling To: Cnaan Oded , simple@ietf.org In-Reply-To: <385D702A9C11D511A9E90008C7160AD5054541DF@ISMAIL1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 09:18:53 -0800 (PST) There seems to be a third option which is popular as well. The tuple ID is just an ordering mechanism within an XML document to determine when tuples are added and removed. Additional syntax is then required to achieve the semantics of device/service that you mention below. This appears to be the approach adopted in the RPIDS draft. Perhaps Henning or Paul can comment? Regards, Sean --- Cnaan Oded wrote: > Although the question "what a tuple represents" has > not been discussed in > depth yet, it seems that most implementation have > chosen to either represent > devices or services. For example, a tuple may > represent a cell phone but can > also represent an IM client running on a mobile > phone. > > Here is a simple example of 2 such tuples: > > > entity="pres:someone@example.com"> > > > > open > > tel:09012345678 > > > > > open > busy > > sip:user@domain.com > > > > > > There are cases where there is a relationship > between these tuples. For > example, in the above example, the IM client is > running on the same device > described by the first tuple, meaning that there > might be some information > (e.g., location) that is related to both tuples. > > One approach to handle it would be to duplicate this > information. Having > 'Location' described in the tuple representing the > device as well as the one > representing the service. This approach is not > efficient in terms of volume > as many tuples might relate to the same information. > > Another possible solution would be to create a > reference between tuples, in > this example between a "service tuple" and a "device > tuple". In this case, > the information is described only once but is > referenced from other tuples. > For example: > > > > open > busy > > sip:user@domain.com > > > Following the latter option, the device status, > location, LCD resolution or > any other attributes associated with the device may > be picked up from the > "phone" tuple so that the "mobile-im" tuple > represents only the service > characteristics. > > Following the above example, if the user is on a > call, and his device state > changes from "open" to "call" (assuming this is a > valid value), the "phone" > tuple is the only one that changes (and will be > included in the NOTIFY). The > IM watcher would be able to deduce on which device > the client is running and > therefore its state (and location...). > > Although IM was used in the example, it may imply to > any other service such > as Voicemail, Calendar, PTT, Address book, MMS etc. > > Note that not all services are associated with > devices. An email service, > for example, may be self sufficient as there is no > real meaning to instant > or direct communications and since the session is > transient. > > Another related issue that calls for attention is > the ability to create > coupling between services and the device they are > currently using. For > example, assuming a user that has 2 phones, only one > with a PTT client, > turns on both phones, the PTT service needs to be > able to inform the > presence server not only that it is active but also > on which of the devices > (of course that this info is subject to privacy > policy as any other > information element). > > Having the ability to tie a service to a device > allows the PS to perform > advanced compositions. For example, in the previous > example, the PS may > automatically change the PTT state to busy when the > user is on a voice call > without having the client to publish anything (using > network agents). This > may also be useful when aggregating additional > presence info that is not > intrinsic to the service (e.g., location). > > > Oded Cnaan > > __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 31 13:00:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16983 for ; Mon, 31 Mar 2003 13:00:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VIOKu05475 for simple-archive@odin.ietf.org; Mon, 31 Mar 2003 13:24:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIOJK05472 for ; Mon, 31 Mar 2003 13:24:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16976 for ; Mon, 31 Mar 2003 13:00:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIO5K05446; Mon, 31 Mar 2003 13:24:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIIDK04903 for ; Mon, 31 Mar 2003 13:18:13 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16560 for ; Mon, 31 Mar 2003 12:54:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2VHuhBd008203; Mon, 31 Mar 2003 12:56:44 -0500 (EST) Message-ID: <3E888157.5040605@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: Sean Olson CC: Cnaan Oded , simple@ietf.org Subject: Re: [Simple] Tuple references and device coupling References: <20030331171853.71515.qmail@web41511.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 12:56:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It all comes back to the same problem - what does a tuple represent? Ultimately, tuples (and in general, a presence document) are tools for modeling real-world systems that have components like people, devices, applications, and so on. We NEED to have agreed-upon definitions of what a tuple is, and how it is used to model real-world systems, or these problems will continue to plague us. What Oded is saying is that the presence document has to take into account the fact that there are relationships between devices and applications in the real world, and the model needs to take that into account. -Jonathan R. Sean Olson wrote: > There seems to be a third option which is popular > as well. The tuple ID is just an ordering mechanism > within an XML document to determine when tuples are > added and removed. Additional syntax is then required > to achieve the semantics of device/service that you > mention below. This appears to be the approach > adopted in the RPIDS draft. Perhaps Henning or Paul > can comment? > > Regards, > Sean > > --- Cnaan Oded wrote: > >>Although the question "what a tuple represents" has >>not been discussed in >>depth yet, it seems that most implementation have >>chosen to either represent >>devices or services. For example, a tuple may >>represent a cell phone but can >>also represent an IM client running on a mobile >>phone. >> >>Here is a simple example of 2 such tuples: >> >> >>> entity="pres:someone@example.com"> >> >> >> >> open >> >> tel:09012345678 >> >> >> >> >> open >> busy >> >> sip:user@domain.com >> >> >> >> >> >>There are cases where there is a relationship >>between these tuples. For >>example, in the above example, the IM client is >>running on the same device >>described by the first tuple, meaning that there >>might be some information >>(e.g., location) that is related to both tuples. >> >>One approach to handle it would be to duplicate this >>information. Having >>'Location' described in the tuple representing the >>device as well as the one >>representing the service. This approach is not >>efficient in terms of volume >>as many tuples might relate to the same information. >> >>Another possible solution would be to create a >>reference between tuples, in >>this example between a "service tuple" and a "device >>tuple". In this case, >>the information is described only once but is >>referenced from other tuples. >>For example: >> >> >> >> open >> busy >> >> sip:user@domain.com >> >> >>Following the latter option, the device status, >>location, LCD resolution or >>any other attributes associated with the device may >>be picked up from the >>"phone" tuple so that the "mobile-im" tuple >>represents only the service >>characteristics. >> >>Following the above example, if the user is on a >>call, and his device state >>changes from "open" to "call" (assuming this is a >>valid value), the "phone" >>tuple is the only one that changes (and will be >>included in the NOTIFY). The >>IM watcher would be able to deduce on which device >>the client is running and >>therefore its state (and location...). >> >>Although IM was used in the example, it may imply to >>any other service such >>as Voicemail, Calendar, PTT, Address book, MMS etc. >> >>Note that not all services are associated with >>devices. An email service, >>for example, may be self sufficient as there is no >>real meaning to instant >>or direct communications and since the session is >>transient. >> >>Another related issue that calls for attention is >>the ability to create >>coupling between services and the device they are >>currently using. For >>example, assuming a user that has 2 phones, only one >>with a PTT client, >>turns on both phones, the PTT service needs to be >>able to inform the >>presence server not only that it is active but also >>on which of the devices >>(of course that this info is subject to privacy >>policy as any other >>information element). >> >>Having the ability to tie a service to a device >>allows the PS to perform >>advanced compositions. For example, in the previous >>example, the PS may >>automatically change the PTT state to busy when the >>user is on a voice call >>without having the client to publish anything (using >>network agents). This >>may also be useful when aggregating additional >>presence info that is not >>intrinsic to the service (e.g., location). >> >> >>Oded Cnaan >> >> > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 31 13:20:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17814 for ; Mon, 31 Mar 2003 13:20:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VIhWj07184 for simple-archive@odin.ietf.org; Mon, 31 Mar 2003 13:43:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIhVK07181 for ; Mon, 31 Mar 2003 13:43:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17752 for ; Mon, 31 Mar 2003 13:19:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIhOK07168; Mon, 31 Mar 2003 13:43:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIWmK05948 for ; Mon, 31 Mar 2003 13:32:48 -0500 Received: from web41509.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17336 for ; Mon, 31 Mar 2003 13:08:56 -0500 (EST) Message-ID: <20030331181121.1932.qmail@web41509.mail.yahoo.com> Received: from [131.107.3.78] by web41509.mail.yahoo.com via HTTP; Mon, 31 Mar 2003 10:11:21 PST From: Sean Olson Subject: Re: [Simple] Tuple references and device coupling To: Jonathan Rosenberg Cc: Cnaan Oded , simple@ietf.org In-Reply-To: <3E888157.5040605@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 10:11:21 -0800 (PST) Understood... now the next immediate question is: Does the syntax provided by PIDF contain the semantics of device, application, and user? Of course you can build this with the syntax of a tuple. The problem is that you can build this in more than one way and there is no clear standard way to do this. I was hoping that RPIDS would solve this, at least for the SIMPLE community. Am I wrong? --- Jonathan Rosenberg wrote: > It all comes back to the same problem - what does a > tuple represent? > > Ultimately, tuples (and in general, a presence > document) are tools for > modeling real-world systems that have components > like people, devices, > applications, and so on. We NEED to have agreed-upon > definitions of what > a tuple is, and how it is used to model real-world > systems, or these > problems will continue to plague us. > > What Oded is saying is that the presence document > has to take into > account the fact that there are relationships > between devices and > applications in the real world, and the model needs > to take that into > account. > > -Jonathan R. > > Sean Olson wrote: > > There seems to be a third option which is popular > > as well. The tuple ID is just an ordering > mechanism > > within an XML document to determine when tuples > are > > added and removed. Additional syntax is then > required > > to achieve the semantics of device/service that > you > > mention below. This appears to be the approach > > adopted in the RPIDS draft. Perhaps Henning or > Paul > > can comment? > > > > Regards, > > Sean > > > > --- Cnaan Oded wrote: > > > >>Although the question "what a tuple represents" > has > >>not been discussed in > >>depth yet, it seems that most implementation have > >>chosen to either represent > >>devices or services. For example, a tuple may > >>represent a cell phone but can > >>also represent an IM client running on a mobile > >>phone. > >> > >>Here is a simple example of 2 such tuples: > >> > >> > >> >> entity="pres:someone@example.com"> > >> > >> > >> > >> open > >> > >> tel:09012345678 > >> > >> > >> > >> > >> open > >> busy > >> > >> sip:user@domain.com > >> > >> > >> > >> > >> > >>There are cases where there is a relationship > >>between these tuples. For > >>example, in the above example, the IM client is > >>running on the same device > >>described by the first tuple, meaning that there > >>might be some information > >>(e.g., location) that is related to both tuples. > >> > >>One approach to handle it would be to duplicate > this > >>information. Having > >>'Location' described in the tuple representing the > >>device as well as the one > >>representing the service. This approach is not > >>efficient in terms of volume > >>as many tuples might relate to the same > information. > >> > >>Another possible solution would be to create a > >>reference between tuples, in > >>this example between a "service tuple" and a > "device > >>tuple". In this case, > >>the information is described only once but is > >>referenced from other tuples. > >>For example: > >> > >> > >> > >> open > >> busy > >> > >> sip:user@domain.com > >> > >> > >>Following the latter option, the device status, > >>location, LCD resolution or > >>any other attributes associated with the device > may > >>be picked up from the > >>"phone" tuple so that the "mobile-im" tuple > >>represents only the service > >>characteristics. > >> > >>Following the above example, if the user is on a > >>call, and his device state > >>changes from "open" to "call" (assuming this is a > >>valid value), the "phone" > >>tuple is the only one that changes (and will be > >>included in the NOTIFY). The > >>IM watcher would be able to deduce on which device > >>the client is running and > >>therefore its state (and location...). > >> > >>Although IM was used in the example, it may imply > to > >>any other service such > >>as Voicemail, Calendar, PTT, Address book, MMS > etc. > >> > >>Note that not all services are associated with > >>devices. An email service, > >>for example, may be self sufficient as there is no > >>real meaning to instant > >>or direct communications and since the session is > >>transient. > >> > >>Another related issue that calls for attention is > >>the ability to create > >>coupling between services and the device they are > >>currently using. For > >>example, assuming a user that has 2 phones, only > one > >>with a PTT client, > >>turns on both phones, the PTT service needs to be > >>able to inform the > >>presence server not only that it is active but > also > >>on which of the devices > >>(of course that this info is subject to privacy > >>policy as any other > >>information element). > >> > >>Having the ability to tie a service to a device > >>allows the PS to perform > >>advanced compositions. For example, in the > previous > >>example, the PS may > >>automatically change the PTT state to busy when > the > >>user is on a voice call > >>without having the client to publish anything > (using > >>network agents). This > >>may also be useful when aggregating additional > >>presence info that is not > >>intrinsic to the service (e.g., location). > >> > >> > >>Oded Cnaan > >> > >> > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Platinum - Watch CBS' NCAA March Madness, > live on your desktop! > > http://platinum.yahoo.com > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > Chief Scientist > Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 31 14:18:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19782 for ; Mon, 31 Mar 2003 14:18:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VJfpd11276 for simple-archive@odin.ietf.org; Mon, 31 Mar 2003 14:41:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VJfpK11271 for ; Mon, 31 Mar 2003 14:41:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19772 for ; Mon, 31 Mar 2003 14:17:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VJfiK11227; Mon, 31 Mar 2003 14:41:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VJTRK09999 for ; Mon, 31 Mar 2003 14:29:28 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19434 for ; Mon, 31 Mar 2003 14:05:33 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26234; Mon, 31 Mar 2003 14:07:50 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17576; Mon, 31 Mar 2003 14:07:51 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 14:07:50 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5FDC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sean Olson'" , Jonathan Rosenberg Cc: Cnaan Oded , simple@ietf.org Subject: RE: [Simple] Tuple references and device coupling MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 14:07:49 -0500 Perhaps the time has come to take this particular bull by the horns and make it EXPLICIT what the tuple represents. We've had too many disagreements on mechanisms where the parties want the tuple to represent different things. Our solutions thus far usually mean widening options to make all things possible. Pehaps we can make an explicit tree shaped hierarchy where a User may have a series of Devices, each one of which may have a number of Applications Each of these can provide presence. If we were to go this far, I'd like links between them (parent/sibling) so that in a real world mixed environment, you have a chance to figure out what is happening. Brian > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Monday, March 31, 2003 1:11 PM > To: Jonathan Rosenberg > Cc: Cnaan Oded; simple@ietf.org > Subject: Re: [Simple] Tuple references and device coupling > > > Understood... now the next immediate question is: > > Does the syntax provided by PIDF contain the > semantics of device, application, and user? > > Of course you can build this with the syntax of > a tuple. The problem is that you can build this > in more than one way and there is no clear > standard way to do this. > > I was hoping that RPIDS would solve this, at > least for the SIMPLE community. > > Am I wrong? > > --- Jonathan Rosenberg > wrote: > > It all comes back to the same problem - what does a > > tuple represent? > > > > Ultimately, tuples (and in general, a presence > > document) are tools for > > modeling real-world systems that have components > > like people, devices, > > applications, and so on. We NEED to have agreed-upon > > definitions of what > > a tuple is, and how it is used to model real-world > > systems, or these > > problems will continue to plague us. > > > > What Oded is saying is that the presence document > > has to take into > > account the fact that there are relationships > > between devices and > > applications in the real world, and the model needs > > to take that into > > account. > > > > -Jonathan R. > > > > Sean Olson wrote: > > > There seems to be a third option which is popular > > > as well. The tuple ID is just an ordering > > mechanism > > > within an XML document to determine when tuples > > are > > > added and removed. Additional syntax is then > > required > > > to achieve the semantics of device/service that > > you > > > mention below. This appears to be the approach > > > adopted in the RPIDS draft. Perhaps Henning or > > Paul > > > can comment? > > > > > > Regards, > > > Sean > > > > > > --- Cnaan Oded wrote: > > > > > >>Although the question "what a tuple represents" > > has > > >>not been discussed in > > >>depth yet, it seems that most implementation have > > >>chosen to either represent > > >>devices or services. For example, a tuple may > > >>represent a cell phone but can > > >>also represent an IM client running on a mobile > > >>phone. > > >> > > >>Here is a simple example of 2 such tuples: > > >> > > >> > > >> > >> entity="pres:someone@example.com"> > > >> > > >> > > >> > > >> open > > >> > > >> tel:09012345678 > > >> > > >> > > >> > > >> > > >> open > > >> busy > > >> > > >> sip:user@domain.com > > >> > > >> > > >> > > >> > > >> > > >>There are cases where there is a relationship > > >>between these tuples. For > > >>example, in the above example, the IM client is > > >>running on the same device > > >>described by the first tuple, meaning that there > > >>might be some information > > >>(e.g., location) that is related to both tuples. > > >> > > >>One approach to handle it would be to duplicate > > this > > >>information. Having > > >>'Location' described in the tuple representing the > > >>device as well as the one > > >>representing the service. This approach is not > > >>efficient in terms of volume > > >>as many tuples might relate to the same > > information. > > >> > > >>Another possible solution would be to create a > > >>reference between tuples, in > > >>this example between a "service tuple" and a > > "device > > >>tuple". In this case, > > >>the information is described only once but is > > >>referenced from other tuples. > > >>For example: > > >> > > >> > > >> > > >> open > > >> busy > > >> > > >> sip:user@domain.com > > >> > > >> > > >>Following the latter option, the device status, > > >>location, LCD resolution or > > >>any other attributes associated with the device > > may > > >>be picked up from the > > >>"phone" tuple so that the "mobile-im" tuple > > >>represents only the service > > >>characteristics. > > >> > > >>Following the above example, if the user is on a > > >>call, and his device state > > >>changes from "open" to "call" (assuming this is a > > >>valid value), the "phone" > > >>tuple is the only one that changes (and will be > > >>included in the NOTIFY). The > > >>IM watcher would be able to deduce on which device > > >>the client is running and > > >>therefore its state (and location...). > > >> > > >>Although IM was used in the example, it may imply > > to > > >>any other service such > > >>as Voicemail, Calendar, PTT, Address book, MMS > > etc. > > >> > > >>Note that not all services are associated with > > >>devices. An email service, > > >>for example, may be self sufficient as there is no > > >>real meaning to instant > > >>or direct communications and since the session is > > >>transient. > > >> > > >>Another related issue that calls for attention is > > >>the ability to create > > >>coupling between services and the device they are > > >>currently using. For > > >>example, assuming a user that has 2 phones, only > > one > > >>with a PTT client, > > >>turns on both phones, the PTT service needs to be > > >>able to inform the > > >>presence server not only that it is active but > > also > > >>on which of the devices > > >>(of course that this info is subject to privacy > > >>policy as any other > > >>information element). > > >> > > >>Having the ability to tie a service to a device > > >>allows the PS to perform > > >>advanced compositions. For example, in the > > previous > > >>example, the PS may > > >>automatically change the PTT state to busy when > > the > > >>user is on a voice call > > >>without having the client to publish anything > > (using > > >>network agents). This > > >>may also be useful when aggregating additional > > >>presence info that is not > > >>intrinsic to the service (e.g., location). > > >> > > >> > > >>Oded Cnaan > > >> > > >> > > > > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Platinum - Watch CBS' NCAA March Madness, > > live on your desktop! > > > http://platinum.yahoo.com > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 > > Lanidex Plaza > > Chief Scientist > > Parsippany, NJ 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Mar 31 20:23:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05875 for ; Mon, 31 Mar 2003 20:23:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h311lKX03324 for simple-archive@odin.ietf.org; Mon, 31 Mar 2003 20:47:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h311lKK03321 for ; Mon, 31 Mar 2003 20:47:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05865 for ; Mon, 31 Mar 2003 20:23:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h311lAK03312; Mon, 31 Mar 2003 20:47:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h311kVK03294 for ; Mon, 31 Mar 2003 20:46:31 -0500 Received: from web41507.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05825 for ; Mon, 31 Mar 2003 20:22:29 -0500 (EST) Message-ID: <20030401012455.55609.qmail@web41507.mail.yahoo.com> Received: from [131.107.3.72] by web41507.mail.yahoo.com via HTTP; Mon, 31 Mar 2003 17:24:55 PST From: Sean Olson Subject: RE: [Simple] Tuple references and device coupling To: "Rosen, Brian" , Jonathan Rosenberg Cc: Cnaan Oded , simple@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF030B5FDC@whq-msgusr-02.pit.comms.marconi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 17:24:55 -0800 (PST) Sounds like a reasonable way forward. My only comment is that we might wish to model applications independent of a device, but that could be a future improvement. Based on this understanding, it would seem that tuple == device? --- "Rosen, Brian" wrote: > Perhaps the time has come to take this particular > bull by the horns > and make it EXPLICIT what the tuple represents. > We've had > too many disagreements on mechanisms where the > parties want the > tuple to represent different things. Our solutions > thus far > usually mean widening options to make all things > possible. > > Pehaps we can make an explicit tree shaped hierarchy > where a > User may have a series of > Devices, each one of which may have a number of > Applications > Each of these can provide presence. > > If we were to go this far, I'd like links between > them (parent/sibling) > so that in a real world mixed environment, you have > a chance to > figure out what is happening. > > Brian > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Monday, March 31, 2003 1:11 PM > > To: Jonathan Rosenberg > > Cc: Cnaan Oded; simple@ietf.org > > Subject: Re: [Simple] Tuple references and device > coupling > > > > > > Understood... now the next immediate question is: > > > > Does the syntax provided by PIDF contain the > > semantics of device, application, and user? > > > > Of course you can build this with the syntax of > > a tuple. The problem is that you can build this > > in more than one way and there is no clear > > standard way to do this. > > > > I was hoping that RPIDS would solve this, at > > least for the SIMPLE community. > > > > Am I wrong? > > > > --- Jonathan Rosenberg > > wrote: > > > It all comes back to the same problem - what > does a > > > tuple represent? > > > > > > Ultimately, tuples (and in general, a presence > > > document) are tools for > > > modeling real-world systems that have components > > > like people, devices, > > > applications, and so on. We NEED to have > agreed-upon > > > definitions of what > > > a tuple is, and how it is used to model > real-world > > > systems, or these > > > problems will continue to plague us. > > > > > > What Oded is saying is that the presence > document > > > has to take into > > > account the fact that there are relationships > > > between devices and > > > applications in the real world, and the model > needs > > > to take that into > > > account. > > > > > > -Jonathan R. > > > > > > Sean Olson wrote: > > > > There seems to be a third option which is > popular > > > > as well. The tuple ID is just an ordering > > > mechanism > > > > within an XML document to determine when > tuples > > > are > > > > added and removed. Additional syntax is then > > > required > > > > to achieve the semantics of device/service > that > > > you > > > > mention below. This appears to be the approach > > > > > adopted in the RPIDS draft. Perhaps Henning or > > > Paul > > > > can comment? > > > > > > > > Regards, > > > > Sean > > > > > > > > --- Cnaan Oded > wrote: > > > > > > > >>Although the question "what a tuple > represents" > > > has > > > >>not been discussed in > > > >>depth yet, it seems that most implementation > have > > > >>chosen to either represent > > > >>devices or services. For example, a tuple may > > > >>represent a cell phone but can > > > >>also represent an IM client running on a > mobile > > > >>phone. > > > >> > > > >>Here is a simple example of 2 such tuples: > > > >> > > > >> > > > >> xmlns="urn:ietf:params:xml:ns:cpim-pidf" > > > >> entity="pres:someone@example.com"> > > > >> > > > >> > > > >> > > > >> open > > > >> > > > >> tel:09012345678 > > > >> > > > >> > > > >> > > > >> > > > >> open > > > >> busy > > > >> > > > >> sip:user@domain.com > > > >> > > > >> > > > >> > > > >> > > > >> > > > >>There are cases where there is a relationship > > > >>between these tuples. For > > > >>example, in the above example, the IM client > is > > > >>running on the same device > > > >>described by the first tuple, meaning that > there > > > >>might be some information > > > >>(e.g., location) that is related to both > tuples. > > > >> > > > >>One approach to handle it would be to > duplicate > > > this > > > >>information. Having > > > >>'Location' described in the tuple representing > the > > > >>device as well as the one > > > >>representing the service. This approach is not > > > >>efficient in terms of volume > > > >>as many tuples might relate to the same > > > information. > > > >> > > > >>Another possible solution would be to create a > > > >>reference between tuples, in > > > >>this example between a "service tuple" and a > > > "device > > > >>tuple". In this case, > > > >>the information is described only once but is > > > >>referenced from other tuples. > > > >>For example: > > > >> > > > >> > > > >> > > > >> open > > > >> busy > > > >> > > > >> sip:user@domain.com > > > >> > > > >> > > > >>Following the latter option, the device > status, > > > >>location, LCD resolution or > > > >>any other attributes associated with the > device > > > may > > > >>be picked up from the > > > >>"phone" tuple so that the "mobile-im" tuple > > > >>represents only the service > > > >>characteristics. > > > >> > > > >>Following the above example, if the user is on > a > > > >>call, and his device state > > > >>changes from "open" to "call" (assuming this > is a > > > >>valid value), the "phone" > > > >>tuple is the only one that changes (and will > be > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple