From simple-admin@mailman.dynamicsoft.com Sat Jun 1 05:03:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09994 for ; Sat, 1 Jun 2002 05:03:50 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g51914Le004776 for ; Sat, 1 Jun 2002 05:01:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21612 for ; Sat, 1 Jun 2002 05:04:56 -0400 (EDT) Date: Sat, 1 Jun 2002 05:04:56 -0400 (EDT) Message-Id: <200206010904.FAA21612@mailman.dynamicsoft.com> Subject: mailman.dynamicsoft.com mailing list memberships reminder From: mailman-owner@mailman.dynamicsoft.com To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk This is a reminder, sent out once a month, about your mailman.dynamicsoft.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@mailman.dynamicsoft.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.dynamicsoft.com. Thanks! Passwords for simple-archive@lists.ietf.org: List Password // URL ---- -------- simple@mailman.dynamicsoft.com ifheto http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org From simple-admin@mailman.dynamicsoft.com Sat Jun 1 10:46:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23462 for ; Sat, 1 Jun 2002 10:46:50 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g51EhELe006537; Sat, 1 Jun 2002 10:43:14 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24153; Sat, 1 Jun 2002 10:47:02 -0400 (EDT) Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24142 for ; Sat, 1 Jun 2002 10:46:09 -0400 (EDT) Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17EA1c-0000Sf-00; Sat, 01 Jun 2002 15:38:36 +0100 Received: from modem-392.python.dialup.pol.co.uk ([217.134.209.136] helo=ADRIANXP) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17EA1Z-0004I3-00; Sat, 01 Jun 2002 15:38:33 +0100 Reply-To: From: "Adrian Bateman" To: "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" Cc: Subject: RE: Status discussion again RE: [Simple] Test message Organization: VisionTech Limited Message-ID: <001301c20979$e23d34b0$6405010a@ADRIANXP> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 1 Jun 2002 15:37:35 +0100 Content-Transfer-Encoding: 7bit On 31 May 2002 03:16, Li Hua Tang wrote: > > It's always open, but no driving force for input and output.:) Need > inspiration... > > Here is the point. 'Open' status only describes an objective > communication possibility. We may need something like 'Eager to chat!' > or 'I want to be silent.' to describe the user's subjective attitude > to communication. One is the capability (open or closed), the other is > the availability (user's willingness). That's what we have got known > from the previous status discussion. > > So can we summary status as below? > Open > - availble // always ready to chat > - away // temporarily not available > - invisible // only available to someone I want to chat > - busy // not ready to chat or no immediately response to messages > - in call // may ready to chat later > Closed > - unavailable // disconnect and can't chat > - do not disturb // don't want to receive message but close the > channel (Apart from the fact that invisible can't really be a state (visibly invisible?) so should look just like disconnnected,) I'll try to reiterate my thoughts on this discussion from a different tack. Why is it important to try to distill the different IM status values into a definitive set? I don't believe that the group will reach consensus on a definitive minimal set because one person's busy is another's do-not-disturb. Doesn't the benefit come from having a *reasonably* small and *well-known* vocabulary for IM status values? You don't even really need to decide which are open and which are closed - PIDF allows for that already. Perhaps rather than trying to find the set of status values, attention might be focussed on the reason for having such a set and the values might fall out of that discussion? Regards, Adrian. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 4 15:15:20 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11246 for ; Tue, 4 Jun 2002 15:15:20 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g54JBQss013941; Tue, 4 Jun 2002 15:11:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05827; Tue, 4 Jun 2002 15:15:19 -0400 (EDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05814 for ; Tue, 4 Jun 2002 15:14:25 -0400 (EDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g54JBQL21171 for ; Tue, 4 Jun 2002 19:11:26 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g54JAk015414 for ; Tue, 4 Jun 2002 19:10:46 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060412121115592 ; Tue, 04 Jun 2002 12:12:11 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 12:12:50 -0700 Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C394@orsmsx120.jf.intel.com> From: "Carr, Wayne" To: "'Jonathan Rosenberg'" , Paul Kyzivat Cc: Rohan Mahy , sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu Subject: RE: [Simple] PIDF for buddylists, was: Re: [Sipping] request to a dopt registration package as WG item MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Jun 2002 12:12:43 -0700 > from a read of the schema its not clear to me that a single document > with multiple presence elements is actually disallowed, in whcih case > its already there. XML documents have a single root element. In PIDF, presence is the root element so there's only one presence element. Someone could define another XML format with some other root element that included multiple PIDF presence elements inside that other root element. (or some non XML format could carry multiple XML documents) > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, May 31, 2002 11:09 AM > To: Paul Kyzivat > Cc: Rohan Mahy; sipping@ietf.org; simple@mailman.dynamicsoft.com; > impp@iastate.edu > Subject: [Simple] PIDF for buddylists, was: Re: [Sipping] request to > adopt registration package as WG item > > > I think my comments on using PIDF for the reg package are covered in a > separate email; I'll focus here on the PIDF v. buddylist concept. > However, this is well into simple territory (and IMPP), so I am cc'ing > those lists. > > inline: > > Paul Kyzivat wrote: > > > > comments inline. > > > > > > However, note that in cases of notifications of changes, > this issue > > > becomes largely moot. Changes in presence of buddies > happen one at a > > > time, so that each notify would usually contain just a > single presenec > > > doc anyway. THe exception is if the buddylist server is > batching the > > > notifies in order to reduce overhead. > > > > I think batching is potentially an important application of > buddylists. > > Buddylist servers may also be a good place to implement filtering to > > further reduce the traffic that > > the subscriber is exposed to. These potentials would be enhanced by > > being able to return the presence of multiple presentities > in a single > > presence document. > > I agree it would be helpful, although the difference between multipart > and multiple presentities in a single document is not huge. The real > problem is that this is somewhat of a new direction for PIDF > late in the > game, and in PIDF was engineered to be minimalistic. Adding > support for > a new feature is likely to meet with some resistance. I > suppose we could > define an extension to PIDF, although to be honest, from a read of the > schema its not clear to me that a single document with > multiple presence > elements is actually disallowed, in whcih case its already there. Of > course, its not likely to be interoperable... > > > > > > > > it would then make > > > > sense to subscribe to presence of either presentities > or buddylists > > > > without needed to know which is which. > > > > > > There are differences, most notably in the need for diffs > in the case > > of > > > buddylist. > > > > Seems to me these aren't important differences. The > features that seem > > important for buddylists and less important for presence of an > > individual are also at least > > potentially useful for the presence of an individual. > > Well, the diff feature is critical for buddylist, and currently > undefined for presence. Therefore, we need to have at least a new > package for it. We would also need some new attributes to support the > diffs (a partial/full flag, as we needed for watcherinfo), so > we are at > least talking about an extension to PIDF even if multiple presence > elements are allowed. I would be OK with doing that; the difference > between it and multipart is not huge, but its definitely better. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 5 17:04:17 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19874 for ; Wed, 5 Jun 2002 17:04:15 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g55L0Mss023565; Wed, 5 Jun 2002 17:00:22 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10113; Wed, 5 Jun 2002 17:04:14 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10102 for ; Wed, 5 Jun 2002 17:03:15 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g55L0uCL021864; Wed, 5 Jun 2002 17:00:57 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL50294; Wed, 5 Jun 2002 17:05:02 -0400 (EDT) Message-ID: <3CFE7BE9.3F84A182@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu References: <3CF62BAE.A73C9FCD@cisco.com> <3CF7BC51.6CFF41B4@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 05 Jun 2002 17:00:25 -0400 Content-Transfer-Encoding: 7bit Jonathan, Maybe I missed a document. You mention below the importance of diffs when reporting presence for buddylists. But I don't find any mention of diffs in draft-rosenberg-simple-buddylist-package-00. Or do you just mean that delivery of presence documents individually from each member of the buddylist as it changes is a form of diff? Upon thinking about this further, I think the existing presence document might be sufficient. Consider - is there any fundamental difference between a named buddylist and an address of record? If I view a buddylist as an address of record, then to populate it I simply REGISTER the addresses of the buddies as contacts. Then instead of a BLSS, I need a presence server with access to the location service populated by the registrar. And instead of a presence document with multiple presentities, I get a presence document with a single presentity (my buddylist name) and a bunch of contacts for my buddies. This would put a high priority on permitting diffs in the presence documents. Having buddylists represented this way would provide other opportunities to use them. Paul Jonathan Rosenberg wrote: > > I think my comments on using PIDF for the reg package are covered in a > separate email; I'll focus here on the PIDF v. buddylist concept. > However, this is well into simple territory (and IMPP), so I am cc'ing > those lists. > > inline: > > Paul Kyzivat wrote: > > > > comments inline. > > > > > > However, note that in cases of notifications of changes, this issue > > > becomes largely moot. Changes in presence of buddies happen one at a > > > time, so that each notify would usually contain just a single presenec > > > doc anyway. THe exception is if the buddylist server is batching the > > > notifies in order to reduce overhead. > > > > I think batching is potentially an important application of buddylists. > > Buddylist servers may also be a good place to implement filtering to > > further reduce the traffic that > > the subscriber is exposed to. These potentials would be enhanced by > > being able to return the presence of multiple presentities in a single > > presence document. > > I agree it would be helpful, although the difference between multipart > and multiple presentities in a single document is not huge. The real > problem is that this is somewhat of a new direction for PIDF late in the > game, and in PIDF was engineered to be minimalistic. Adding support for > a new feature is likely to meet with some resistance. I suppose we could > define an extension to PIDF, although to be honest, from a read of the > schema its not clear to me that a single document with multiple presence > elements is actually disallowed, in whcih case its already there. Of > course, its not likely to be interoperable... > > > > > > > it would then make > > > > sense to subscribe to presence of either presentities or buddylists > > > > without needed to know which is which. > > > > > > There are differences, most notably in the need for diffs in the case > > of > > > buddylist. > > > > Seems to me these aren't important differences. The features that seem > > important for buddylists and less important for presence of an > > individual are also at least > > potentially useful for the presence of an individual. > > Well, the diff feature is critical for buddylist, and currently > undefined for presence. Therefore, we need to have at least a new > package for it. We would also need some new attributes to support the > diffs (a partial/full flag, as we needed for watcherinfo), so we are at > least talking about an extension to PIDF even if multiple presence > elements are allowed. I would be OK with doing that; the difference > between it and multipart is not huge, but its definitely better. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 6 18:51:24 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03906 for ; Thu, 6 Jun 2002 18:51:24 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g56LKAss001034; Thu, 6 Jun 2002 17:20:11 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14041; Thu, 6 Jun 2002 17:24:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14030 for ; Thu, 6 Jun 2002 17:23:03 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g56LM87f007419; Thu, 6 Jun 2002 17:22:09 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL57082; Thu, 6 Jun 2002 17:26:16 -0400 (EDT) Message-ID: <3CFFD262.28CDB056@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu References: <3CFE7BE9.3F84A182@cisco.com> <3CFFB76F.2070907@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 06 Jun 2002 17:21:38 -0400 Content-Transfer-Encoding: 7bit Comments inline. Best results when viewed in fixed width font. Paul Jonathan Rosenberg wrote: > > Paul Kyzivat wrote: > > Jonathan, > > > > Maybe I missed a document. You mention below the importance of diffs > > when reporting presence for buddylists. But I don't find any mention of > > diffs in > > draft-rosenberg-simple-buddylist-package-00. > > You're right, actually. I thought about this more since posting, and its > not really needed. With watcherinfo (which does have diffs), you are > again getting notified about a list of things. However, the list itself > is dynamic and conveyed through the notifications itself. You therefore > need to have a flag as to whether the update is full state or partial > state, so that you know whether or not to delete a watcher because their > entry is not in the list (delete for full state, don't for partial). > > Now, in the case of buddylists, presumably the list itself is known to > the client through other means, and therefore, this particular flag is > not needed. I'm not sure this is a reasonable assumption. As long as we remain silent on how the list is managed, it is risky to assume that every subscriber has complete knowledge of the list content. There seem to be two reasonable alternatives here: provide diff information on presence reports from buddylists, or else provide a defined way to monitor the content of a buddylist itself. > > > Or do you just mean that > > delivery of presence documents individually from each member of the > > buddylist as it changes is a form > > of diff? > > > > Upon thinking about this further, I think the existing presence document > > might be sufficient. > > Wayne convinced me that we need to define a trivial new format; one that > has a new top-level XML element, and the sub-element is presence from PIDF. Depends on outcome of discussion below. Possibly some form of change will be required. > > > > > Consider - is there any fundamental difference between a named buddylist > > and an address of record? If I view a buddylist as an address of record, > > then to populate it I > > simply REGISTER the addresses of the buddies as contacts. > > Are you proposing an actual REGISTER for this? I think this is a pretty > big deviation from the meaning of REGISTER. I am proposing (as a strawhorse) that the concept of buddylist be subsumed into a slightly broader role for address of record. This is largely a conceptual change - I don't think the mechanics of managing address of record need to change. It is already permissible to populate a location service with an address of record either by using REGISTER or by some other method. One other method might be by uploading a buddylist. > > > Then instead > > of a BLSS, I need a presence server with access to the location service > > populated by the registrar. > > And instead of a presence document with multiple presentities, I get a > > presence document with a single presentity (my buddylist name) and a > > bunch of contacts for my > > buddies. > > How would you have out the contacts for the buddies? You've shifted > everything down a layer, so the bottom falls out as far as I can tell... Yeah, I didn't bother to mention that, and you caught me. :-) What I have in mind is that presence should be viewed as hierarchical. It is already that way, sort of, but only two levels are acknowledged in the hierarchy. The presentity can have status, and each of the contacts can have status. In registrations, it is permissible for the Contacts defining one address of record to themselves be addresses of record that have lower level definitions, etc. (I realize there aren't many, if any, published use cases for this.) If you want to understand the full hierarchical structure of registrations of that sort, you have to drill down one level at a time. It should be possible to do exactly the same thing for presence. Alternately, it might be more helpful for a presence subscription to be recursive, perhaps optionally. (This would be something like what has been proposed for the conference info event package.) As an example, consider the following hierarchy: everybody@bedrock.com / | \ barney@bedrock.com fred@bedrock.com pebbles@bedrock.com / / | \ \ ... / | \ ... / | \ / | \ fred.mobile@cells.r.us fflintstone@msn.com 1234@bedrock.com;user=phone These could all be valid sip addresses to call. They are also potentially all valid presentities to request presence documents for. What is the difference if I ask for the presence of 'everybody' and get info about its three subordinates, or if I ask for the presence of 'fred' and get the status of his three alternate devices? Why does there have to be an arbitrary distinction that 'everybody' is a buddylist, but 'fred' is an address of record? Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 6 18:52:40 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04329 for ; Thu, 6 Jun 2002 18:52:39 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g56JQXss000231; Thu, 6 Jun 2002 15:26:33 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13697; Thu, 6 Jun 2002 15:29:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13686 for ; Thu, 6 Jun 2002 15:28:01 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56JSJYH007361; Thu, 6 Jun 2002 15:28:19 -0400 (EDT) Message-ID: <3CFFB76F.2070907@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Rohan Mahy , sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu References: <3CFE7BE9.3F84A182@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 06 Jun 2002 15:26:39 -0400 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Jonathan, > > Maybe I missed a document. You mention below the importance of diffs > when reporting presence for buddylists. But I don't find any mention of > diffs in > draft-rosenberg-simple-buddylist-package-00. You're right, actually. I thought about this more since posting, and its not really needed. With watcherinfo (which does have diffs), you are again getting notified about a list of things. However, the list itself is dynamic and conveyed through the notifications itself. You therefore need to have a flag as to whether the update is full state or partial state, so that you know whether or not to delete a watcher because their entry is not in the list (delete for full state, don't for partial). Now, in the case of buddylists, presumably the list itself is known to the client through other means, and therefore, this particular flag is not needed. > Or do you just mean that > delivery of presence documents individually from each member of the > buddylist as it changes is a form > of diff? > > Upon thinking about this further, I think the existing presence document > might be sufficient. Wayne convinced me that we need to define a trivial new format; one that has a new top-level XML element, and the sub-element is presence from PIDF. > > Consider - is there any fundamental difference between a named buddylist > and an address of record? If I view a buddylist as an address of record, > then to populate it I > simply REGISTER the addresses of the buddies as contacts. Are you proposing an actual REGISTER for this? I think this is a pretty big deviation from the meaning of REGISTER. > Then instead > of a BLSS, I need a presence server with access to the location service > populated by the registrar. > And instead of a presence document with multiple presentities, I get a > presence document with a single presentity (my buddylist name) and a > bunch of contacts for my > buddies. How would you have out the contacts for the buddies? You've shifted everything down a layer, so the bottom falls out as far as I can tell... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 6 19:16:53 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11327 for ; Thu, 6 Jun 2002 19:16:53 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g56ND9ss001826; Thu, 6 Jun 2002 19:13:09 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14385; Thu, 6 Jun 2002 19:17:03 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14374 for ; Thu, 6 Jun 2002 19:16:55 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA16717 for ; Thu, 6 Jun 2002 16:15:20 -0700 (MST)] Received: [from artibeus.nsr.labs.mot.com (artibeus.nsr.labs.mot.com [173.23.95.73]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA04827 for ; Thu, 6 Jun 2002 16:15:38 -0700 (MST)] Received: from motorola.com (localhost [127.0.0.1]) by artibeus.nsr.labs.mot.com (8.11.6/8.11.6) with ESMTP id g56NHnu02826 for ; Thu, 6 Jun 2002 18:17:49 -0500 Message-ID: <3CFFED9D.B807A1DB@motorola.com> From: Bryan Thale Organization: Networks & Infrastructure Research, Motorola Labs X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: PIDF for buddylists References: <3CFE7BE9.3F84A182@cisco.com> <3CFFD262.28CDB056@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 06 Jun 2002 18:17:49 -0500 Content-Transfer-Encoding: 7bit > As an example, consider the following hierarchy: > > everybody@bedrock.com > / | \ > barney@bedrock.com fred@bedrock.com pebbles@bedrock.com > / / | \ \ > ... / | \ ... > / | \ > / | \ > fred.mobile@cells.r.us fflintstone@msn.com 1234@bedrock.com;user=phone > > These could all be valid sip addresses to call. They are also potentially all valid presentities to request presence documents for. What is the difference if I ask for the > presence of 'everybody' and get info about its three subordinates, or if I ask for the presence of 'fred' and get the status of his three alternate devices? > > Why does there have to be an arbitrary distinction that 'everybody' is a buddylist, but 'fred' is an address of record? Looking at it from the other direction, what does it mean to call a buddylist? Placing a call to 'fred' will eventually resolve down to one device or at least one user. That probably isn't what would be intended by a call to 'everybody' which sounds more like a multiparty call. If buddylists and AoRs are indistinguishable, how would a SIP application know what is the right thing to do? > Consider - is there any fundamental difference between a named buddylist > and an address of record? Isn't the difference that a buddylist is simply a handle used to conveniently reference a group of AoRs for the purpose of reporting presence info while an AoR is an alias whose purpose is to stand in for a particular destination address until such time as it can be fully resolved? Thus, a buddylist represents a group of information sources while an AoR represents a single destination. Bryan. -- Bryan Thale Networks & Infrastructure Research, Motorola Labs mailto:bryan.thale@motorola.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jun 7 09:46:12 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26181 for ; Fri, 7 Jun 2002 09:46:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g57Dg7ss004904; Fri, 7 Jun 2002 09:42:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16729; Fri, 7 Jun 2002 09:46:02 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14308 for ; Thu, 6 Jun 2002 19:04:41 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA11060 for ; Thu, 6 Jun 2002 16:03:05 -0700 (MST)] Received: [from artibeus.nsr.labs.mot.com (artibeus.nsr.labs.mot.com [173.23.95.73]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA02385 for ; Thu, 6 Jun 2002 16:03:05 -0700 (MST)] Received: from motorola.com (localhost [127.0.0.1]) by artibeus.nsr.labs.mot.com (8.11.6/8.11.6) with ESMTP id g56N5Yu02794 for ; Thu, 6 Jun 2002 18:05:34 -0500 Message-ID: <3CFFEABE.F3E3D839@motorola.com> From: Bryan Thale Organization: Networks & Infrastructure Research, Motorola Labs X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: PIDF for buddylists References: <3CFE7BE9.3F84A182@cisco.com> <3CFFD262.28CDB056@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 06 Jun 2002 18:05:34 -0500 Content-Transfer-Encoding: 7bit > As an example, consider the following hierarchy: > > everybody@bedrock.com > / | \ > barney@bedrock.com fred@bedrock.com pebbles@bedrock.com > / / | \ \ > ... / | \ ... > / | \ > / | \ > fred.mobile@cells.r.us fflintstone@msn.com 1234@bedrock.com;user=phone > > These could all be valid sip addresses to call. They are also potentially all valid presentities to request presence documents for. What is the difference if I ask for the > presence of 'everybody' and get info about its three subordinates, or if I ask for the presence of 'fred' and get the status of his three alternate devices? > > Why does there have to be an arbitrary distinction that 'everybody' is a buddylist, but 'fred' is an address of record? Looking at it from the other direction, what does it mean to call a buddylist? Placing a call to 'fred' will eventually resolve down to one device or at least one user. That probably isn't what would be intended by a call to 'everybody' which sounds more like a multiparty call. If buddylists and AoRs are indistinguishable, how would a SIP application know what is the right thing to do? > Consider - is there any fundamental difference between a named buddylist > and an address of record? Isn't the difference that a buddylist is simply a handle used to conveniently reference a group of AoRs for the purpose of reporting presence info while an AoR is an alias whose purpose is to stand in for a particular destination address until such time as it can be fully resolved? Thus, a buddylist represents a group of information sources while an AoR represents a single destination. Bryan. -- Bryan Thale Networks & Infrastructure Research, Motorola Labs mailto:bryan.thale@motorola.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jun 7 13:32:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05028 for ; Fri, 7 Jun 2002 13:32:11 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g57HR7ss007120; Fri, 7 Jun 2002 13:27:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17487; Fri, 7 Jun 2002 13:31:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17476 for ; Fri, 7 Jun 2002 13:30:09 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57HTKQh029149; Fri, 7 Jun 2002 13:29:21 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL61233; Fri, 7 Jun 2002 13:33:28 -0400 (EDT) Message-ID: <3D00ED53.93AF8D@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Thale CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: PIDF for buddylists References: <3CFE7BE9.3F84A182@cisco.com> <3CFFD262.28CDB056@cisco.com> <3CFFEABE.F3E3D839@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 07 Jun 2002 13:28:51 -0400 Content-Transfer-Encoding: 7bit Bryan Thale wrote: > > Looking at it from the other direction, what does it mean to call a buddylist? > > Placing a call to 'fred' will eventually resolve down to one device or at least one user. That probably isn't what would be intended by a call to 'everybody' which sounds > more like a multiparty call. If buddylists and AoRs are indistinguishable, how would a SIP application know what is the right thing to do? Well, maybe I should have called it 'anybody' instead of 'everybody'. It certainly is plausible that I want just want to talk to any member of bedrock. In this respect it is just like calling 'fred' and getting any of fred's devices. Calling all of them is harder, in many respects. It probably requires establishing a conference mixer, etc. If that is what you want, it can be achieved in a variety of ways. You could subscribe to presence, and then call all the contacts that are present. Or you could send an INVITE with a Request-Disposition of 'redirect'. This would return you all the contact addresses of the members in a 300 response, and you could use that to do multiple invitations. > > > Consider - is there any fundamental difference between a named buddylist > > and an address of record? > > Isn't the difference that a buddylist is simply a handle used to conveniently reference a group of AoRs for the purpose of reporting presence info while an AoR is an alias > whose purpose is to stand in for a particular destination address until such time as it can be fully resolved? Thus, a buddylist represents a group of information sources > while an AoR represents a single destination. They still sound like the same thing to me. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Jun 9 01:58:08 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17882 for ; Sun, 9 Jun 2002 01:58:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g595sDss011822; Sun, 9 Jun 2002 01:54:13 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23527; Sun, 9 Jun 2002 01:58:07 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23516 for ; Sun, 9 Jun 2002 01:57:11 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g595vRYH009093; Sun, 9 Jun 2002 01:57:27 -0400 (EDT) Message-ID: <3D02EDE4.4080809@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Rohan Mahy , sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu References: <3CFFD262.28CDB056@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sun, 09 Jun 2002 01:55:48 -0400 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: >> >>Now, in the case of buddylists, presumably the list itself is known to >>the client through other means, and therefore, this particular flag is >>not needed. > > > I'm not sure this is a reasonable assumption. As long as we remain > silent on how the list is managed, it is risky to assume that every > subscriber has complete knowledge of > the list content. Well, the question is whether this package is the right thing to let someone know that the list itself has changed, as opposed to just the presence of a user on the list changing. > > There seem to be two reasonable alternatives here: provide diff > information on presence reports from buddylists, or else provide a > defined way to monitor the content of a > buddylist itself. Right. My preference is to have a separate package for that. Indeed, there are several "lists" that one might have and wish to watch for changes in - authorization lists, deny lists, group lists (for group IM, for example), and so on. Itd' be nice those were all handled consistently. >>Are you proposing an actual REGISTER for this? I think this is a >>pretty >>big deviation from the meaning of REGISTER. > > > I am proposing (as a strawhorse) that the concept of buddylist be > subsumed into a slightly broader role for address of record. This is > largely a conceptual change - I don't > think the mechanics of managing address of record need to change. > > It is already permissible to populate a location service with an address > of record either by using REGISTER or by some other method. One other > method might be by uploading > a buddylist. I am still very uncomfortable with this. If an INVITE arrives for that "address of record" the call will fork to the people in your buddy list. I don't think this is what you really want to have happen. Probably you really want a conference call. Thats generally different from a call to an AOR that represents a user, as we know it today. Since I personally would only communicate with one of my registered contacts, forking and then cancelling unanswered branches makes sense. However, if the AOR represents a group, all of the "registered contacts" would communicate, and therefore, the conference call makes more sense. >>How would you have out the contacts for the buddies? You've shifted >>everything down a layer, so the bottom falls out as far as I can >> tell... > > Yeah, I didn't bother to mention that, and you caught me. :-) > > What I have in mind is that presence should be viewed as hierarchical. > It is already that way, sort of, but only two levels are acknowledged in > the hierarchy. The > presentity can have status, and each of the contacts can have status. > > In registrations, it is permissible for the Contacts defining one > address of record to themselves be addresses of record that have lower > level definitions, etc. (I realize > there aren't many, if any, published use cases for this.) Generally, call forwarding. > > If you want to understand the full hierarchical structure of > registrations of that sort, you have to drill down one level at a time. > It should be possible to do exactly the > same thing for presence. Alternately, it might be more helpful for a > presence subscription to be recursive, perhaps optionally. (This would > be something like what has been > proposed for the conference info event package.) > > As an example, consider the following hierarchy: > > everybody@bedrock.com > / | \ > barney@bedrock.com fred@bedrock.com pebbles@bedrock.com > / / | \ \ > ... / | \ ... > / | \ > / | \ > fred.mobile@cells.r.us fflintstone@msn.com 1234@bedrock.com;user=phone > > > These could all be valid sip addresses to call. They are also > potentially all valid presentities to request presence documents for. > What is the difference if I ask for the > presence of 'everybody' and get info about its three subordinates, or if > I ask for the presence of 'fred' and get the status of his three > alternate devices? At the very least, I think users who subscribe to this thing will want to know the difference. Beyond that, there is likely to be differences in the information you would want to convey at each level. Indeed, in PIDF today, very little information exists at the presentity level; its all at the contact level. To show that your model is sensible, I think you need to demonstarte that the same information and state applies to any level in the hierarchy above. Don't get me wrong - I am not saying that what you are proposing is a bad idea. In fact, its quite intriguing. But, its a big deviation from PIDF today, and from the architectural model that has been the foundation of PIDF for some time (RFC 2778). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jun 10 03:56:53 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24915 for ; Mon, 10 Jun 2002 03:56:53 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5A7rCss014301; Mon, 10 Jun 2002 03:53:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27791; Mon, 10 Jun 2002 03:57:06 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27780 for ; Mon, 10 Jun 2002 03:56:48 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA14619; Mon, 10 Jun 2002 09:55:23 +0200 (MET DST) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA02850; Mon, 10 Jun 2002 09:55:25 +0200 (MET DST) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 09:55:25 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E08@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'jdrosen@dynamicsoft.com'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: [SIMPLE] Comments on draft-ietf-simple-presence-07 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 09:55:21 +0200 Section 9.1 Privacy The 2nd bullet "User may not want to reveal that they have accepted subscription from certain users". I can understand if user may not want to reveal that he has _rejected_ subscriptions from certain users. That's polite blocking. But I am not aware of not revealing accepting subscriptions. Does the user reject it, but the present agent actually sets up the subscription? That can't work. We can't send NOTIFY to a subscriber if his subscription appeared (to him) to have been rejected. Nits: Section 4 2nd paragraph o "The subcription is carried along SIP proxies as any other request would be". "subscription" => "SUBSCRIBE request" o "...it eventually arrives at a presence server, which can either terminate the subscription..." "terminate the subscription" => "serves as the terminating point for the SUBSCRIBE request and handles the subscription" Section 4 6th paragraph o "This (refresh) SUBSCRIBE is nearly identical to the initial one, but contains the dialog identifier, different sequence numbers, and a set of Route headers..." => "...but contains the To tag, a higher sequence number, and possibly a set of Route headers..." Section 9.2 o "http" => "HTTP" Regards, Ya-Ching _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jun 10 15:57:37 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22541 for ; Mon, 10 Jun 2002 15:57:37 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5AJs6Ys005135; Mon, 10 Jun 2002 15:54:06 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02098; Mon, 10 Jun 2002 15:58:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02087 for ; Mon, 10 Jun 2002 15:57:10 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5AJtieL026067; Mon, 10 Jun 2002 15:55:44 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL70374; Mon, 10 Jun 2002 15:59:51 -0400 (EDT) Message-ID: <3D050421.72F23DAC@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu References: <3CFFD262.28CDB056@cisco.com> <3D02EDE4.4080809@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 15:55:13 -0400 Content-Transfer-Encoding: 7bit Jonathan - more comments below. Paul Jonathan Rosenberg wrote: > > > There seem to be two reasonable alternatives here: provide diff > > information on presence reports from buddylists, or else provide a > > defined way to monitor the content of a > > buddylist itself. > > Right. My preference is to have a separate package for that. Indeed, > there are several "lists" that one might have and wish to watch for > changes in - authorization lists, deny lists, group lists (for group IM, > for example), and so on. Itd' be nice those were all handled consistently. Whether there is a separate package or not, there may still be a need for diff information. The presence event package doesn't provide for diffs. In the absence of filters, it returns all information about the presentity, including all tuples, in each notification. Your proposal has distinguished buddylist from presentity. The buddylist eventpackage returns a full set of information about all buddy presentities upon an initial subscription, and thereafter effectively returns diffs in the sense that it only returns information about individual buddies whose presence status has changed. So the effect is that there is support for diffs on some but not all of the information. This makes sense if you assume that there might be a lot of buddies per buddylist, but not a lot of tuples per presentity. But this is only an assumption. There are plausible cases where there might be many tuples for a presentity. Now I have suggested we merge the concept of a buddylist that has a number of presentities with the concept of a presentity that has a number of tuples. If we do this, then it gets harder to distinguish when to use a diff behavior and when not to. While this presents a problem to be solved, once it is solved, it will work when the application is conceptually a presentity with lots of tuples as well as when it is a buddylist with lots of buddies. One solution would be analogous to what you have already proposed: use two different event package names to distinguish whether the returned notification stream uses diffs or not. (Even though the addressed entity being subscribed to is an address of record in both cases.) But while this would still be possible, I think there is probably a better choice. For instance, this might be incorporated into a filter definition. > > I am proposing (as a strawhorse) that the concept of buddylist be > > subsumed into a slightly broader role for address of record. This is > > largely a conceptual change - I don't > > think the mechanics of managing address of record need to change. > > > > It is already permissible to populate a location service with an address > > of record either by using REGISTER or by some other method. One other > > method might be by uploading > > a buddylist. > > I am still very uncomfortable with this. If an INVITE arrives for that > "address of record" the call will fork to the people in your buddy list. > I don't think this is what you really want to have happen. Probably you > really want a conference call. Thats generally different from a call to > an AOR that represents a user, as we know it today. Since I personally > would only communicate with one of my registered contacts, forking and > then cancelling unanswered branches makes sense. However, if the AOR > represents a group, all of the "registered contacts" would communicate, > and therefore, the conference call makes more sense. Which makes sense depends on context. There are lots of useful examples of a group address that I might want to call and really only want to talk to one member of the group. For instance I might want to call anybody in a particular household, or in a department of an organization. Nor do I think a given list will only be used one way or the other. There are times when I might want to send a reminder to all members of a group, and other times when I just need to deal with some member of the group. So this is a matter of expressing the desired manner of using the list, rather than a characteristic of the definition of the list. > At the very least, I think users who subscribe to this thing will want > to know the difference. If we can come up with a clear definition of what the difference is, then it should be relatively simple to encode that in a presence document, e.g. as a new sort of status value. The hard part is defining the difference. This is *already* a problem: suppose I have two devices, a phone that does voice, and a PC that does chat. I register them both with the same address of record: sip:paul@foo.org. If this same information is translated or rerepresented as a presence document, then it will appear as two tuples for the presentity. What are the implications of doing this: 1) Suppose you have a device capable of either voice or chat. It can generate in invitation offering both. If you send an invitation to my address of record, it will presumably be forked, and one or the other of my endpoints will be chosen, but you will have little choice in which. 2) A suitable presence client will show them both, perhaps annotated to indicate what media each supports. Using the same device as above, coupled to the presence client, you can choose which device to send an invitation to. If you wish, you can initiate an invitation to each, and so use both media. 3) In (2) I assumed that your presence-coupled UA sent invitations to the contact address of a tuple. If instead it send the invitation to the presentity address (address of record) then the results are more like (1), but more disconcerting. I may think I am calling your phone but get your chat UA instead. There would perhaps be a better, or at least more consistent, result if we consider the location service to have the full set of information that the presence document represents for a presentity. A forking proxy for an address-of-record would be able to use all of this information to process a call. But to get reasonable and consistent behavior for calls that are presence driven and those that are not, the presence information almost certainly needs to be enriched to indicate *why* multiple tuples are present and how choices among them should be made. This is similar to the information provided by callerprefs, but may need further enrichment. > > Beyond that, there is likely to be differences in the information you > would want to convey at each level. Indeed, in PIDF today, very little > information exists at the presentity level; its all at the contact > level. To show that your model is sensible, I think you need to > demonstarte that the same information and state applies to any level in > the hierarchy above. The presentity level information is pretty minimal in pidf today. Its not clear whether this is a problem or not. In large measure the extra information at the tuple level is there to characterize the differences between the tuples, or the intended role of each tuple. As long as you assume there is a single top level element, then it needs less of this information. OTOH, there is some merit in producing a rollup for the top of the hierarchy - e.g. a status value that somehow represents the aggregate status. This is probably pretty easy as long as you restrict status to OPEN and CLOSED. (Presentity is OPEN if any of the tuples are OPEN.) However this is probably simplistic. There may be no general algorithm for deriving the status of the presentity from the status' of the tuples. If this has to be explicitly generated, then it may not be worth providing. One simple way of reflecting the general model would be to change the schema so that a could contain another as an alternative to anyURL. This would permit the hierarchy to be exploded in a single document. But even without this, there is nothing to prevent interpretation of the URL in a as a reference to another presentity. > > Don't get me wrong - I am not saying that what you are proposing is a > bad idea. In fact, its quite intriguing. But, its a big deviation from > PIDF today, and from the architectural model that has been the > foundation of PIDF for some time (RFC 2778). Hey, I'm happy not be be considered insane for proposing it. :-) I reread that, and I don't think what I am suggesting does a violence to that model. Of course that model doesn't suggest or imply this sort of implementation, but neither does it seem to prevent it. But were we to go in this direction it would probably be advisable to discuss these concepts specifically. I realize that this is still half baked. I'm just testing the ideas now. My earlier comments on the registration event package were also part of this same concept. I haven't responded to your comments on that because that part is still in the oven. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jun 10 17:53:26 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27217 for ; Mon, 10 Jun 2002 17:53:26 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5ALo5Ys006125; Mon, 10 Jun 2002 17:50:06 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02489; Mon, 10 Jun 2002 17:54:03 -0400 (EDT) Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02473 for ; Mon, 10 Jun 2002 17:53:05 -0400 (EDT) Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17HX4e-0008Qi-00; Mon, 10 Jun 2002 22:51:40 +0100 Received: from modem-3510.zebra.dialup.pol.co.uk ([81.76.157.182] helo=ADRIANXP) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17HX4e-0006YL-00; Mon, 10 Jun 2002 22:51:40 +0100 Reply-To: From: "Adrian Bateman" To: "'Paul Kyzivat'" , "'Jonathan Rosenberg'" Cc: , , Organization: VisionTech Limited Message-ID: <000d01c210c8$d7d3a2b0$6405010a@ADRIANXP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3D050421.72F23DAC@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Simple] RE: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 22:50:26 +0100 Content-Transfer-Encoding: 7bit On 10 June 2002 20:55, Paul Kyzivat wrote: > Jonathan Rosenberg wrote: > > Don't get me wrong - I am not saying that what you are proposing is > > a > > bad idea. In fact, its quite intriguing. But, its a big deviation from > > PIDF today, and from the architectural model that has been the > > foundation of PIDF for some time (RFC 2778). > > Hey, I'm happy not be be considered insane for proposing it. :-) > > I reread that, and I don't think what I am suggesting does a violence > to that model. Of course that model doesn't suggest or imply this sort > of implementation, but neither does it seem to prevent it. But were we > to go in this direction it would probably be advisable to discuss > these concepts specifically. Don't forget that 2778/2779 only defined the base vocabulary/requirements. CPIM/PIDF/etc define the implementation decisions taken to produce our standard IMPP that fits the model. Adrian. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jun 10 18:53:16 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28656 for ; Mon, 10 Jun 2002 18:53:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5AMo4Ys006485; Mon, 10 Jun 2002 18:50:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02691; Mon, 10 Jun 2002 18:54:02 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02680 for ; Mon, 10 Jun 2002 18:53:53 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5AMq3Ai007891; Mon, 10 Jun 2002 18:52:03 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL71464; Mon, 10 Jun 2002 18:56:10 -0400 (EDT) Message-ID: <3D052D75.B2B7F829@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bateman@acm.org CC: sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu References: <000d01c210c8$d7d3a2b0$6405010a@ADRIANXP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 18:51:33 -0400 Content-Transfer-Encoding: 7bit Adrian Bateman wrote: > > Don't forget that 2778/2779 only defined the base > vocabulary/requirements. CPIM/PIDF/etc define the implementation > decisions taken to produce our standard IMPP that fits the model. Yes. I'm mindful that what we are discussing here is likely at minimum an extension to PIDF. I don't want to derail plans for timely progress on presence. Hopefully extensions should be sufficient, and could come down the pipeline after the current stuff progresses. One way to represent more than one level of hierarchy is simply to include a element in a as an extension element. So it could also be added as an optional element in a future extension and be backward compatible. A subscription option to receive differences rather than full updates could be encoded in the body as part of a filter. This would make sense, since it is a sort of filter. And it would be compatible with the current direction. One thing that might be a problem would be indicating that a response has had filtering and/or differencing applied. Some of it could be handled as extension values in tuples, but I can foresee a need to know this at the level too. One possible change to the current proposed PIDF format that might help here would be to make explicit provision for extension values within itself. This would look like: * Another approach for handling this kind of change would be to simply define a different presence document type for representing diffs and multilevel presence status. Clients wanting to use it would then have to be prepared for servers that can't handle it, by falling back to the old PIDF. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 11 02:08:08 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14086 for ; Tue, 11 Jun 2002 02:08:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5B5n4Ys007894; Tue, 11 Jun 2002 01:49:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03846; Tue, 11 Jun 2002 01:53:02 -0400 (EDT) Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03835 for ; Tue, 11 Jun 2002 01:52:22 -0400 (EDT) Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17HeYU-0001XV-00; Tue, 11 Jun 2002 06:50:58 +0100 Received: from modem-147.rhino.dialup.pol.co.uk ([62.137.96.147] helo=ADRIANXP) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17HeYT-0006NO-00; Tue, 11 Jun 2002 06:50:57 +0100 Reply-To: From: "Adrian Bateman" To: "'Paul Kyzivat'" Cc: , , Organization: VisionTech Limited Message-ID: <001501c2110b$cc6cccb0$6405010a@ADRIANXP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3D052D75.B2B7F829@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Simple] RE: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 06:49:48 +0100 Content-Transfer-Encoding: 7bit On 10 June 2002 23:51, Paul Kyzivat wrote: > One thing that might be a problem would be indicating that a response > has had filtering and/or differencing applied. Some of it could be > handled as extension values in tuples, but I can foresee a need to > know this at the level too. One possible change to the > current proposed PIDF format that might help here would be to make > explicit provision for extension values within itself. This > would look like: > > > > > maxOccurs="unbounded"/> > * * maxOccurs="unbounded"/> > > > This has been mentioned in the past, but AFAIK, this is the first concrete example of *why* we should make it. In the past, I think I've probably stuck with the letter of 2778 using our current approach, but on the basis that this is such a small change, has been requested a few times, and generally looks like a good idea, I think we should adopt it. > Another approach for handling this kind of change would be to simply > define a different presence document type for representing diffs and > multilevel presence status. Clients wanting to use it would then have > to be prepared for servers that can't handle it, by falling back to > the old PIDF. I'd like to avoid that if possible - I think we should make the change. Adrian. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 11 04:48:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16201 for ; Tue, 11 Jun 2002 04:48:36 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5B8jAYs008421; Tue, 11 Jun 2002 04:45:11 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04383; Tue, 11 Jun 2002 04:49:05 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04372 for ; Tue, 11 Jun 2002 04:48:04 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5B8kmT26962; Tue, 11 Jun 2002 03:46:48 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 03:46:44 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703CD@va02.va.neustar.com> From: "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Cc: "'rsparks@dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Message sessions Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 03:46:42 -0500 Now that the presence and watcherinfo work has gone forward to the IESG, we need to return to the issue of message sessions - we are quite a bit overdue on our deliverable to solve this problem, largely because many of the core SIP/SIMPLE people have been focusing on some other issues. As those of you who have followed the discussion regarding the MESSAGE method draft in the SIP WG are aware, there is now a better transition strategy emerging to determine how one segues from paging mode to session mode. At least one case in which we know we would like to transition is when large content (a binary media file, for example) is being transmitted over instant messages. However, although we know what message sessions are and what we'd like to use them for, we still have not arrived at any conclusions in the SIMPLE WG on the actual session protocol. Two proposals have been made for session protocols: http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-01.txt http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-session-0 0.txt In Minneapolis, we all collectively took an action item to review these approaches in order to determine their suitability. At the time, however, the second of these drafts was not available. We also really have no criteria on which to evaluate these drafts other than the requirements that fall out of CPIM. It is important that we arrive at some consensus about pursuing one (or both) of these documents as working group items shortly. At the very least, determining that they comply with CPIM guidelines is critical. The chairs would therefore like to solicit some volunteers to review these proposals in the next TWO weeks in the light of the following documents from the IMPP WG: http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-02.txt http://www.ietf.org/rfc/rfc2779.txt If you can commit to provide a written review of the comformance of one of the session protocol proposals to CPIM guidelines within the timeline, please contact the chairs (myself and Robert) privately; we'll assign reviewers shortly. We would also welcome any general discussion of the merits of these protocols, whether it is preferable to pursue one or both of these proposals, suggested requirements and so on. Jon Peterson NeuStar, Inc. SIMPLE WG co-chair _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 11 07:54:48 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19187 for ; Tue, 11 Jun 2002 07:54:48 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5BBp4Ys009071; Tue, 11 Jun 2002 07:51:05 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04901; Tue, 11 Jun 2002 07:55:04 -0400 (EDT) Received: from smtp5.cluster.oleane.net (smtp5.cluster.oleane.net [195.25.12.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04888 for ; Tue, 11 Jun 2002 07:54:23 -0400 (EDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp5.cluster.oleane.net with SMTP id g5BBr4g47950 for ; Tue, 11 Jun 2002 13:53:04 +0200 (CEST) Message-ID: <015001c2113f$7e228ac0$0701a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014D_01C21150.41576E60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Simple] International SIP 2003 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 13:59:51 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_014D_01C21150.41576E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The fourth edition of International SIP, the largest international = gathering exclusively dedicated to SIP, will take place January 21 to 24 = 2003 in Paris (Sofitel Bercy).=20 A call for proposals is online at: http://www.upperside.fr/intersip03/sip03intro.htm ------=_NextPart_000_014D_01C21150.41576E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
The fourth edition of International SIP, the largest = international gathering exclusively dedicated to SIP, will take place = January 21=20 to 24 2003 in Paris (Sofitel Bercy).
A call for proposals is online at:
http://www.upp= erside.fr/intersip03/sip03intro.htm
 
 
 
------=_NextPart_000_014D_01C21150.41576E60-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 11 17:06:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13124 for ; Tue, 11 Jun 2002 17:06:06 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5BL5BYs014343; Tue, 11 Jun 2002 17:05:11 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06641; Tue, 11 Jun 2002 17:05:04 -0400 (EDT) Received: from pallas.or.intel.com (pallas.or.intel.com [134.134.214.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06628 for ; Tue, 11 Jun 2002 17:04:40 -0400 (EDT) Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by pallas.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5BL4dt25693 for ; Tue, 11 Jun 2002 21:04:39 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002061113544311987 ; Tue, 11 Jun 2002 13:54:43 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 12:45:00 -0700 Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C3E1@orsmsx120.jf.intel.com> From: "Carr, Wayne" To: "'Adrian Bateman'" , "'Paul Kyzivat'" Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 12:44:52 -0700 I've been away travelling and haven't been following this - so apologies in advance. The proposal looks like adding the ability to add extensions as the direct child of the presence element. That's already in http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt The ** part of the suggested schema section below are in the XML schema now. Also for people not familiar with XML schema -- in another Internet Draft someone can define a new XML format in a new namespace that includes the PIDF format presence element (lists of them if they want). They don't need to redefine PIDF in their draft, they just include it by including an element with the pidf namespace - so can have lists of presence elements. I think the PIDF format is flexible enough that it can handle the types of things being discussed without changes to PIDF itself. > -----Original Message----- > From: Adrian Bateman [mailto:bateman@acm.org] > Sent: Monday, June 10, 2002 10:50 PM > To: 'Paul Kyzivat' > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; impp@iastate.edu > Subject: RE: PIDF for buddylists > > > On 10 June 2002 23:51, Paul Kyzivat wrote: > > One thing that might be a problem would be indicating that > a response > > has had filtering and/or differencing applied. Some of it could be > > handled as extension values in tuples, but I can foresee a need to > > know this at the level too. One possible change to the > > current proposed PIDF format that might help here would be to make > > explicit provision for extension values within > itself. This > > > would look like: > > > > > > > > maxOccurs="unbounded"/> > > > maxOccurs="unbounded"/> > > * minOccurs="0" > > * maxOccurs="unbounded"/> > > > > use="required"/> > > > > This has been mentioned in the past, but AFAIK, this is the first > concrete example of *why* we should make it. In the past, I think I've > probably stuck with the letter of 2778 using our current approach, but > on the basis that this is such a small change, has been > requested a few > times, and generally looks like a good idea, I think we > should adopt it. > > > Another approach for handling this kind of change would be > to simply > > define a different presence document type for representing > diffs and > > multilevel presence status. Clients wanting to use it would > then have > > to be prepared for servers that can't handle it, by falling back to > > the old PIDF. > > I'd like to avoid that if possible - I think we should make > the change. > > Adrian. > > > > > > [reminder: meta-impp@iastate.edu for non-technical > discussions, please] > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 11 17:35:41 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13791 for ; Tue, 11 Jun 2002 17:35:41 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5BLZ5Ys014675; Tue, 11 Jun 2002 17:35:06 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06755; Tue, 11 Jun 2002 17:35:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06742 for ; Tue, 11 Jun 2002 17:34:17 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5BLYDqs019397; Tue, 11 Jun 2002 17:34:13 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL78080; Tue, 11 Jun 2002 17:38:20 -0400 (EDT) Message-ID: <3D066CB7.F2F37BE6@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Carr, Wayne" CC: "'Adrian Bateman'" , sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu References: <86DB568235A8D511ABAC0002A5072CA50316C3E1@orsmsx120.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: PIDF for buddylists Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 17:33:43 -0400 Content-Transfer-Encoding: 7bit "Carr, Wayne" wrote: > > The proposal looks like adding the ability to add extensions as the direct > child of the presence element. That's already in > http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt The ** > part of the suggested schema section below are in the XML schema now. Oops! I was looking at an old version. Dumb, because I had the newer one too and just looked at the wrong one. So I guess no prep-work is required to permit later migration to the kinds of changes I am speculating about. > Also for people not familiar with XML schema -- in another Internet Draft > someone can define a new XML format in a new namespace that includes the > PIDF format presence element (lists of them if they want). They don't need > to redefine PIDF in their draft, they just include it by including an > element with the pidf namespace - so can have lists of presence elements. Yes, or course. But that would require adopting a new sip content-type to go forward. > > I think the PIDF format is flexible enough that it can handle the types of > things being discussed without changes to PIDF itself. Since the change I was looking for has already been made, I must agree. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 12 01:42:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25280 for ; Wed, 12 Jun 2002 01:42:49 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5C5g7Ys016591; Wed, 12 Jun 2002 01:42:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08101; Wed, 12 Jun 2002 01:42:02 -0400 (EDT) Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08090 for ; Wed, 12 Jun 2002 01:41:24 -0400 (EDT) Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by mail7.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17I0sk-0004c1-00; Wed, 12 Jun 2002 06:41:22 +0100 Received: from modem-1079.tiger.dialup.pol.co.uk ([62.136.212.55] helo=ADRIANXP) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17I0sj-0004i8-00; Wed, 12 Jun 2002 06:41:21 +0100 Reply-To: From: "Adrian Bateman" To: "'Carr, Wayne'" Cc: , , Subject: RE: [Simple] RE: PIDF for buddylists Organization: VisionTech Limited Message-ID: <000201c211d3$9e9f3200$6405010a@ADRIANXP> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <86DB568235A8D511ABAC0002A5072CA50316C3E1@orsmsx120.jf.intel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Jun 2002 06:40:00 +0100 Content-Transfer-Encoding: 7bit Sorry for not following the recent changes closely enough. I'm glad this change was made :o) Adrian. On 11 June 2002 20:44, Carr, Wayne wrote: > I've been away travelling and haven't been following this - so > apologies in advance. > > The proposal looks like adding the ability to add extensions as the > direct child of the presence element. That's already in > http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt > The ** part of the suggested schema section below are in the XML > schema now. > > Also for people not familiar with XML schema -- in another Internet > Draft someone can define a new XML format in a new namespace that > includes the PIDF format presence element (lists of them if they > want). They don't need to redefine PIDF in their draft, they just > include it by including an element with the pidf namespace - so can > have lists of presence elements. > > I think the PIDF format is flexible enough that it can handle the > types of things being discussed without changes to PIDF itself. > > > -----Original Message----- > > From: Adrian Bateman [mailto:bateman@acm.org] > > Sent: Monday, June 10, 2002 10:50 PM > > To: 'Paul Kyzivat' > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; > > impp@iastate.edu > > Subject: RE: PIDF for buddylists > > > > > > On 10 June 2002 23:51, Paul Kyzivat wrote: > > > One thing that might be a problem would be indicating that > > a response > > > has had filtering and/or differencing applied. Some of it could be > > > handled as extension values in tuples, but I can foresee a need to > > > know this at the level too. One possible change to the > > > current proposed PIDF format that might help here would be to make > > > explicit provision for extension values within > > itself. This > > > > > would look like: > > > > > > > > > > > > > maxOccurs="unbounded"/> > > > > > maxOccurs="unbounded"/> > > > * > minOccurs="0" > > > * maxOccurs="unbounded"/> > > > > > > > use="required"/> > > > > > > > This has been mentioned in the past, but AFAIK, this is the first > > concrete example of *why* we should make it. In the past, I think I've > > probably stuck with the letter of 2778 using our current approach, but > > on the basis that this is such a small change, has been requested a > > few times, and generally looks like a good idea, I think we > > should adopt it. > > > > > Another approach for handling this kind of change would be > > to simply > > > define a different presence document type for representing > > diffs and > > > multilevel presence status. Clients wanting to use it would > > then have > > > to be prepared for servers that can't handle it, by falling back > > > to the old PIDF. > > > > I'd like to avoid that if possible - I think we should make the > > change. > > > > Adrian. > > > > > > > > > > > > [reminder: meta-impp@iastate.edu for non-technical discussions, > > please] > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 12 04:19:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20294 for ; Wed, 12 Jun 2002 04:19:29 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5C8JBYs017054; Wed, 12 Jun 2002 04:19:11 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08575; Wed, 12 Jun 2002 04:19:03 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08564 for ; Wed, 12 Jun 2002 04:18:25 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5C8IOqq042252 for ; Wed, 12 Jun 2002 10:18:24 +0200 Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5C8IOx80064 for ; Wed, 12 Jun 2002 10:18:24 +0200 To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lamine Brahimi" X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 10:18:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] Urgent: SIMPLE on the market Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Jun 2002 10:18:23 +0200 Dear all, I would like to know if there is some Instant Messaging softwares that already use SIP and SIMPLE protocols. I know that Windows XP Messenger use a part of it in collaboration with Microsoft Messenger protocol. Is there any other Research prototypes or proprietary products using SIMPLE ? I have developed a Presence protocol based on SIMPLE for my diploma thesis, and I would like to know if there are other products in order to mention them in my final thesis report as a related work. Thanks, Lamine. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 13 03:59:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04191 for ; Thu, 13 Jun 2002 03:59:18 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5D7v9Ys024758; Thu, 13 Jun 2002 03:57:10 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12571; Thu, 13 Jun 2002 03:57:05 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12560 for ; Thu, 13 Jun 2002 03:56:35 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5D7uVYH012860; Thu, 13 Jun 2002 03:56:32 -0400 (EDT) Message-ID: <3D080A2A.4010308@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Torrey Searle CC: simple@mailman.dynamicsoft.com, Jean-Luc Sonnet Subject: Re: [Simple] Offline messaging References: <3CDB91E4.1050803@indigosw.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Jun 2002 22:57:46 -0400 Content-Transfer-Encoding: 7bit Digging through old emails, noticed there was no reply to this.... Torrey Searle wrote: > In the current messaging draft, it seems that Message Replay attack > prevention relies on the ability to determine that the message > originated from a offline messaging server, and that the message is an > offline message. > > Are their any plans on adding a way of marking a message as an offline > message? How would you trust such a marking? I think there is no real way to reliably differentiate an offline message from a replayed one. The best you can hope for is that the offiline messaging server actually sends a new message, signing it, with the original messages, headers, signatures, and all, as the payload. Thats certainly possible with MESSAGE. Generally, I think that, when there is a message received which has an old date, the user needs to be prompted to determine what to do. It could in fact be a new message, but the sender has an unsynchronized clock which is off by a day or two. You see that frequently in email.... I believe the MESSAGE draft pretty much provides that guideline. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 13 04:04:24 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04340 for ; Thu, 13 Jun 2002 04:04:23 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5D834Ys024831; Thu, 13 Jun 2002 04:03:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12611; Thu, 13 Jun 2002 04:03:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12579 for ; Thu, 13 Jun 2002 03:58:40 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5D7uNYH012857; Thu, 13 Jun 2002 03:56:26 -0400 (EDT) Message-ID: <3D08089B.6010805@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bateman@acm.org CC: "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <001301c20979$e23d34b0$6405010a@ADRIANXP> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Jun 2002 22:51:07 -0400 Content-Transfer-Encoding: 7bit Once again this one has stalled, but I think Adrian has captured the essence of why below: Adrian Bateman wrote: > On 31 May 2002 03:16, Li Hua Tang wrote: > >>So can we summary status as below? >>Open >> - availble // always ready to chat >> - away // temporarily not available >> - invisible // only available to someone I want to chat >> - busy // not ready to chat or no immediately response to > > messages > >> - in call // may ready to chat later >>Closed >> - unavailable // disconnect and can't chat >> - do not disturb // don't want to receive message but close the >>channel > > > > (Apart from the fact that invisible can't really be a state (visibly > invisible?) so should look just like disconnnected,) I'll try to > reiterate my thoughts on this discussion from a different tack. > > Why is it important to try to distill the different IM status values > into a definitive set? I don't believe that the group will reach > consensus on a definitive minimal set because one person's busy is > another's do-not-disturb. Doesn't the benefit come from having a > *reasonably* small and *well-known* vocabulary for IM status values? You > don't even really need to decide which are open and which are closed - > PIDF allows for that already. > > Perhaps rather than trying to find the set of status values, attention > might be focussed on the reason for having such a set and the values > might fall out of that discussion? This is the essence of the problem. We don't know *why* we want these various status values. Until we know what kinds of things we need to do with them, it will be hard to determine what we want to do. SO, I propose that we focus discussion instead on the things that might be done with such inforamtion. Most importantly, they are things that an automata would do, since anything else can be handled by the note. * display icons appropriate to the status This would in fact argue for a set of common reasons, such as "on the phone" and "in a meeting", irregardless if they don't say anything much beyond CLOSED or OPEN in terms of the ability to receive an IM. * Provide local language versions of the status Similar to the above item, it would require a set of common reasons. * have the secretary automatically connected to the boss in a phone call, when the boss becomes available, where the *secretary* defines available This is an interesting one. TO date, our assumption was that availability is the decision of the presentity; that it decides whether or not it wants to receive calls. THere is an argument to be made that, in the case above, for example, the watcher wants to determine what availability means, based on "raw" information about the boss - whether they are in a call or not, in a meeting or not, and so on. In order for that to work, the secretary's application needs detailed information on what the boss is doing so that it can make a decision. I am sure there are others; suggestions welcome, as well as comments on the above list. Again, I propose we focus on the usages for the status values, rather than on the values themselves. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 13 09:01:37 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10351 for ; Thu, 13 Jun 2002 09:01:37 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5DD0CYs025978; Thu, 13 Jun 2002 09:00:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13570; Thu, 13 Jun 2002 09:00:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13557 for ; Thu, 13 Jun 2002 08:59:23 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5DCxkgu006014; Thu, 13 Jun 2002 08:59:46 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL86826; Thu, 13 Jun 2002 09:03:53 -0400 (EDT) Message-ID: <3D089723.2314815@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: bateman@acm.org, simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <001301c20979$e23d34b0$6405010a@ADRIANXP> <3D08089B.6010805@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Jun 2002 08:59:15 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Once again this one has stalled, but I think Adrian has captured the > essence of why below: > > Adrian Bateman wrote: > > Perhaps rather than trying to find the set of status values, attention > > might be focussed on the reason for having such a set and the values > > might fall out of that discussion? > > This is the essence of the problem. We don't know *why* we want these > various status values. Until we know what kinds of things we need to do > with them, it will be hard to determine what we want to do. > > SO, I propose that we focus discussion instead on the things that might > be done with such inforamtion. Most importantly, they are things that an > automata would do, since anything else can be handled by the note. I agree that this is a useful way to progress. Some time ago I tried, rather unsuccessfully, to make a point about the sorts of statuses that are being proposed. I will try again: Most of the statuses can be classified into one of two buckets: - what the presentity is *doing* ("on the phone", "in meeting", "on vacation") - what the presentity is *willing to do* ("open"?, "do not disturb"?, "emergency calls only") Choosing one sort or another seems to be a matter of philosophy. You choose to represent what is being done if you are generating the status automatically and don't know what the presentity is willing to do, or if you want to put the onus on the caller to decide. You can choose to represent what the presentity is willing to do if the user is explicitly setting the status, if the user has set policy on how to determine what he is willing to do, and if you want to avoid failed attempts to communicate by accurately representing willingness. Automatons can use either sort to display icons, etc. The second sort are beter for caller automatons that automatically place calls, because the automaton has less to infer. OTOH, if you want to report that sort of status automatically then it will require a complex automaton in the presentity to infer the status from actions. I suppose we need both sorts, but it would be useful to be mindful of what kind the things we are defining are, and to attempt to make a reasonably complete set of each. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 13 10:05:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13204 for ; Thu, 13 Jun 2002 10:05:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5DE47Ys026707; Thu, 13 Jun 2002 10:04:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13775; Thu, 13 Jun 2002 10:04:03 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13764 for ; Thu, 13 Jun 2002 10:03:41 -0400 (EDT) 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 KAA08071; Thu, 13 Jun 2002 10:03:37 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07449; Thu, 13 Jun 2002 10:03:37 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 13 Jun 2002 10:03:36 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B54ED@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , bateman@acm.org Cc: "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: RE: Status discussion again RE: [Simple] Test message MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Jun 2002 10:03:35 -0400 Your admin screening for a boss is one example of forwarding decisions based on presence. There are others: Voicemail diversion based on presence Forward to cellphone when I'm not in the office ... There are other things a remote party might do depending on my presence. One really rich vein is a group call (call out ad-hoc conference). How about: Don't call a person marked >="busy" on a group call-out Display who might not be able to respond to a group call before you place it Prompt for an IM when you try to call someone who is "on the phone", but put up an alert when you try to call someone who is DND. Also consider an IM system on a PC and a SIP Phone on the same desk. Presumably, there is one presence system shared among them which could be three independent implementations (two watchers and one presentity). Thus "local" knowledge needs to be standardized to allow: Change alert mechanism for incoming calls (a simple example would be a more discreet alert if you were busy) Choose an appropriate voicemail greeting Don't set an alert if no one is there to see it Send an away message when an IM comes ... I think there is need to have a pretty well specified set of states, hard though that may be. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, June 12, 2002 10:51 PM > To: bateman@acm.org > Cc: 'Li Hua Tang'; 'DAO TRUNG Tin FTRD/DAC/ISS'; > simple@mailman.dynamicsoft.com > Subject: Re: Status discussion again RE: [Simple] Test message > > > Once again this one has stalled, but I think Adrian has captured the > essence of why below: > > Adrian Bateman wrote: > > On 31 May 2002 03:16, Li Hua Tang wrote: > > > >>So can we summary status as below? > >>Open > >> - availble // always ready to chat > >> - away // temporarily not available > >> - invisible // only available to someone I want to chat > >> - busy // not ready to chat or no immediately response to > > > > messages > > > >> - in call // may ready to chat later > >>Closed > >> - unavailable // disconnect and can't chat > >> - do not disturb // don't want to receive message but > close the > >>channel > > > > > > > > (Apart from the fact that invisible can't really be a state (visibly > > invisible?) so should look just like disconnnected,) I'll try to > > reiterate my thoughts on this discussion from a different tack. > > > > Why is it important to try to distill the different IM status values > > into a definitive set? I don't believe that the group will reach > > consensus on a definitive minimal set because one person's busy is > > another's do-not-disturb. Doesn't the benefit come from having a > > *reasonably* small and *well-known* vocabulary for IM > status values? You > > don't even really need to decide which are open and which > are closed - > > PIDF allows for that already. > > > > Perhaps rather than trying to find the set of status > values, attention > > might be focussed on the reason for having such a set and the values > > might fall out of that discussion? > > This is the essence of the problem. We don't know *why* we want these > various status values. Until we know what kinds of things we > need to do > with them, it will be hard to determine what we want to do. > > SO, I propose that we focus discussion instead on the things > that might > be done with such inforamtion. Most importantly, they are > things that an > automata would do, since anything else can be handled by the note. > > * display icons appropriate to the status > > This would in fact argue for a set of common reasons, such > as "on the > phone" and "in a meeting", irregardless if they don't say > anything much > beyond CLOSED or OPEN in terms of the ability to receive an IM. > > * Provide local language versions of the status > > Similar to the above item, it would require a set of > common reasons. > > * have the secretary automatically connected to the boss in a phone > call, when the boss becomes available, where the *secretary* defines > available > > This is an interesting one. TO date, our assumption was that > availability is the decision of the presentity; that it > decides whether > or not it wants to receive calls. THere is an argument to be > made that, > in the case above, for example, the watcher wants to determine what > availability means, based on "raw" information about the boss > - whether > they are in a call or not, in a meeting or not, and so on. In > order for > that to work, the secretary's application needs detailed > information on > what the boss is doing so that it can make a decision. > > > > I am sure there are others; suggestions welcome, as well as > comments on > the above list. Again, I propose we focus on the usages for > the status > values, rather than on the values themselves. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 13 11:15:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16978 for ; Thu, 13 Jun 2002 11:15:27 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5DFE7Ys027454; Thu, 13 Jun 2002 11:14:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14050; Thu, 13 Jun 2002 11:14:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14039 for ; Thu, 13 Jun 2002 11:13:38 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5DFDaXg018164; Thu, 13 Jun 2002 11:13:37 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL88068; Thu, 13 Jun 2002 11:17:43 -0400 (EDT) Message-ID: <3D08B681.E018320E@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <313680C9A886D511A06000204840E1CF030B54ED@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Jun 2002 11:13:05 -0400 Content-Transfer-Encoding: 7bit Another more extreme version of "forwarding decisions based on presence" is in a call center. What you really want is for the capabilities and capacity of each agent to be reported via presence, and for a server to subscribe to this presence information for all candidate agents. Then it can make forwarding decisions based on optimizing across all the candidate agents. For this, you need rich presence information, about media supported, skills, loading, possibly cost. This is more information than is needed for most informal usage, but I think these cases are merely the extremes of a continuum of applications of presence. I don't know if SIMPLE is interested in the more specialized forms of presence. Paul "Rosen, Brian" wrote: > > Your admin screening for a boss is one example of forwarding > decisions based on presence. There are others: > Voicemail diversion based on presence > Forward to cellphone when I'm not in the office > ... > > There are other things a remote party might do depending on my > presence. One really rich vein is a group call (call out > ad-hoc conference). How about: > Don't call a person marked >="busy" on a group call-out > Display who might not be able to respond to a group call > before you place it > Prompt for an IM when you try to call someone who is "on the phone", > but put up an alert when you try to call someone who is DND. > > Also consider an IM system on a PC and a SIP Phone on the same desk. > Presumably, there is one presence system shared among them which could > be three independent implementations (two watchers and one presentity). > Thus "local" knowledge needs to be standardized to allow: > Change alert mechanism for incoming calls (a simple example would > be a more discreet alert if you were busy) > Choose an appropriate voicemail greeting > Don't set an alert if no one is there to see it > Send an away message when an IM comes > ... > > I think there is need to have a pretty well specified set of states, > hard though that may be. > > Brian _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 13 12:24:16 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20505 for ; Thu, 13 Jun 2002 12:24:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5DGN4Ys028144; Thu, 13 Jun 2002 12:23:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14350; Thu, 13 Jun 2002 12:23:03 -0400 (EDT) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA14339 for ; Thu, 13 Jun 2002 12:22:19 -0400 (EDT) Message-ID: <20020613162219.39388.qmail@web11603.mail.yahoo.com> Received: from [131.107.3.75] by web11603.mail.yahoo.com via HTTP; Thu, 13 Jun 2002 09:22:19 PDT From: Sean Olson Subject: Re: Status discussion again RE: [Simple] Test message To: Paul Kyzivat , "Rosen, Brian" Cc: "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com In-Reply-To: <3D08B681.E018320E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Jun 2002 09:22:19 -0700 (PDT) I may be misunderstanding you, but I don't believe capacity and capabilities are necessarily things you want to publish as presence. I agree they are useful things to have for routing decisions, I just don't think they should be part of a presence document. Rather, I would prefer to see something like CC/PP used in conjunction with presence to enable the scenarios you are talking about. /sean --- Paul Kyzivat wrote: > Another more extreme version of "forwarding > decisions based on presence" is in a call center. > What you really want is for the capabilities and > capacity of each agent to be > reported via presence, and for a server to subscribe > to this presence information for all candidate > agents. Then it can make forwarding decisions based > on optimizing across > all the candidate agents. > > For this, you need rich presence information, about > media supported, skills, loading, possibly cost. > This is more information than is needed for most > informal usage, but I > think these cases are merely the extremes of a > continuum of applications of presence. I don't know > if SIMPLE is interested in the more specialized > forms of presence. > > Paul > > "Rosen, Brian" wrote: > > > > Your admin screening for a boss is one example of > forwarding > > decisions based on presence. There are others: > > Voicemail diversion based on presence > > Forward to cellphone when I'm not in the > office > > ... > > > > There are other things a remote party might do > depending on my > > presence. One really rich vein is a group call > (call out > > ad-hoc conference). How about: > > Don't call a person marked >="busy" on a > group call-out > > Display who might not be able to respond > to a group call > > before you place it > > Prompt for an IM when you try to call > someone who is "on the phone", > > but put up an alert when you try > to call someone who is DND. > > > > Also consider an IM system on a PC and a SIP Phone > on the same desk. > > Presumably, there is one presence system shared > among them which could > > be three independent implementations (two watchers > and one presentity). > > Thus "local" knowledge needs to be standardized to > allow: > > Change alert mechanism for incoming calls > (a simple example would > > be a more discreet alert if you > were busy) > > Choose an appropriate voicemail greeting > > Don't set an alert if no one is there to > see it > > Send an away message when an IM comes > > ... > > > > I think there is need to have a pretty well > specified set of states, > > hard though that may be. > > > > Brian > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 13 16:31:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29473 for ; Thu, 13 Jun 2002 16:31:36 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5DKV8Ys000302; Thu, 13 Jun 2002 16:31:08 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15102; Thu, 13 Jun 2002 16:31:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15091 for ; Thu, 13 Jun 2002 16:30:33 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5DKUqe4016174; Thu, 13 Jun 2002 16:30:53 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL90998; Thu, 13 Jun 2002 16:34:59 -0400 (EDT) Message-ID: <3D0900DE.2053AA84@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: "Rosen, Brian" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <20020613162219.39388.qmail@web11603.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Jun 2002 16:30:22 -0400 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > I may be misunderstanding you, but I don't > believe capacity and capabilities are necessarily > things you want to publish as presence. I agree > they are useful things to have for routing > decisions, I just don't think they should be > part of a presence document. Maybe we aren't thinking of the same things, because I see these as very relevant to presence. For instance, capability/willingness to communicate on the subject of auto-repair is just a slightly more refined form of the business/personal distinction. Another sort of capability is media. I might be available for voice only, or for voice and/or IM and/or video at a given address. Capacity can be viewed a couple of ways: maybe I can do IM both on my phone and my PC, but I can do it well on my PC with a keyboard, whereas I can only do it poorly on my phone. Capacity can also be a function of the person manning the presentity. Suppose the address is sip:answers@cars.r.us.com. Sometimes there is an auto guru manning it, so the capacity for auto-repair is high. Other times only a trainee is present, who will try, but isn't very good at auto-repair questions. So the capacity is less. > > Rather, I would prefer to see something like > CC/PP used in conjunction with presence to enable > the scenarios you are talking about. I hadn't heard of CC/PP until now. After a (very) quick search, it sounds like it is solving a different problem. Perhaps it is still applicable, but if so it would still need to be integrated with presence somehow. If it is XML, then perhaps it could be embedded in a special in the presence document. Because this stuff can change dynamically, and the presence client may need it to decide who to call, it would be bad to have to initiate some other sort of session with the presentity or contact to get this information. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 13 18:42:28 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02928 for ; Thu, 13 Jun 2002 18:42:27 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5DMg5Ys001177; Thu, 13 Jun 2002 18:42:05 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15505; Thu, 13 Jun 2002 18:42:03 -0400 (EDT) Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA15494 for ; Thu, 13 Jun 2002 18:41:39 -0400 (EDT) Message-ID: <20020613224139.65227.qmail@web11602.mail.yahoo.com> Received: from [131.107.3.72] by web11602.mail.yahoo.com via HTTP; Thu, 13 Jun 2002 15:41:39 PDT From: Sean Olson Subject: Re: Status discussion again RE: [Simple] Test message To: Paul Kyzivat Cc: "Rosen, Brian" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com In-Reply-To: <3D0900DE.2053AA84@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Jun 2002 15:41:39 -0700 (PDT) I think we are talking about different things. Part of the confusion on "status" is that it can refer to *at least* three different things: 1. Presence - can I communicate 2. Availability - do I want to communicate 3. Capability - what are the mechanisms I have at my disposal to communicate with I believe a raw notion of capability (e-mail, http, sip, etc.) may be appropriate for a "presence" document. However, more advanced notions such as I support H.263 video or I have a color display capable of 640x480 resolution, etc. are a bit of a stretch. Part of these device capabilities are covered by CC/PP (the target application is web browsing, but the CC/PP framework can be extended to much broader capabilities ala RDF) /sean --- Paul Kyzivat wrote: > > > Sean Olson wrote: > > > > I may be misunderstanding you, but I don't > > believe capacity and capabilities are necessarily > > things you want to publish as presence. I agree > > they are useful things to have for routing > > decisions, I just don't think they should be > > part of a presence document. > > Maybe we aren't thinking of the same things, because > I see these as very relevant to presence. > > For instance, capability/willingness to communicate > on the subject of auto-repair is just a slightly > more refined form of the business/personal > distinction. > > Another sort of capability is media. I might be > available for voice only, or for voice and/or IM > and/or video at a given address. > > Capacity can be viewed a couple of ways: maybe I can > do IM both on my phone and my PC, but I can do it > well on my PC with a keyboard, whereas I can only do > it poorly on my > phone. > > Capacity can also be a function of the person > manning the presentity. Suppose the address is > sip:answers@cars.r.us.com. Sometimes there is an > auto guru manning it, so the > capacity for auto-repair is high. Other times only a > trainee is present, who will try, but isn't very > good at auto-repair questions. So the capacity is > less. > > > > > Rather, I would prefer to see something like > > CC/PP used in conjunction with presence to enable > > the scenarios you are talking about. > > I hadn't heard of CC/PP until now. After a (very) > quick search, it sounds like it is solving a > different problem. Perhaps it is still applicable, > but if so it would still > need to be integrated with presence somehow. If it > is XML, then perhaps it could be embedded in a > special in the presence document. Because > this stuff can change > dynamically, and the presence client may need it to > decide who to call, it would be bad to have to > initiate some other sort of session with the > presentity or contact to get > this information. > > Paul __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jun 17 09:03:35 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29996 for ; Mon, 17 Jun 2002 09:03:34 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5HD28oF001000; Mon, 17 Jun 2002 09:02:08 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00928; Mon, 17 Jun 2002 09:02:06 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00917 for ; Mon, 17 Jun 2002 09:01:13 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5HD0TmY029282; Mon, 17 Jun 2002 09:00:29 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAM01286; Mon, 17 Jun 2002 09:04:35 -0400 (EDT) Message-ID: <3D0DDD4D.68DCDE21@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: "Rosen, Brian" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <20020613224139.65227.qmail@web11602.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 08:59:57 -0400 Content-Transfer-Encoding: 7bit Sean, I have not been following the technologies (CC/PP & RDF) that you reference, but I did poke around a bit to figure out what you are referring to. These may indeed be interesting technologies, applicable to this problem space. But it isn't clear that they were intended for it, so it will be necessary to verify if they are applicable, and how they might be made to fit. Since you clearly know more about them, can you say more about what you have in mind? In particular, I gather that these are descriptive notations, encoded in XML, and probably say nothing about how they might be delivered. When we are discussing presence, then it would make sense to me that they would be delivered as part of a presence document (at least the capabilities part) or possibly as part of a presence filter (the preference part). Do you agree, or do you have something else in mind? More below. Paul Sean Olson wrote: > > I think we are talking about different things. Part > of the confusion on "status" is that it can refer > to *at least* three different things: > > 1. Presence - can I communicate > 2. Availability - do I want to communicate > 3. Capability - what are the mechanisms I have > at my disposal to communicate with > > I believe a raw notion of capability (e-mail, http, > sip, etc.) may be appropriate for a "presence" > document. I think we clearly need more than this. The existing status work has scoped itself strictly to IM, but people also want to apply it to voice, so we clearly need to distinguish capability to communicate via IM from capability to communicate via voice. > > However, more advanced notions such as I support > H.263 video or I have a color display capable of > 640x480 resolution, etc. are a bit of a stretch. There has to be a line somewhere, but it is difficult to decide exactly where to draw that line. I think it must at least include the medium at the highest level (video/voice/IM). Below that level it may be reasonable to assume that communication will be possible in some way, possibly involving transcoders. > > Part of these device capabilities are covered > by CC/PP (the target application is web browsing, > but the CC/PP framework can be extended to much > broader capabilities ala RDF) > > /sean > > --- Paul Kyzivat wrote: > > > > > > Sean Olson wrote: > > > > > > I may be misunderstanding you, but I don't > > > believe capacity and capabilities are necessarily > > > things you want to publish as presence. I agree > > > they are useful things to have for routing > > > decisions, I just don't think they should be > > > part of a presence document. > > > > Maybe we aren't thinking of the same things, because > > I see these as very relevant to presence. > > > > For instance, capability/willingness to communicate > > on the subject of auto-repair is just a slightly > > more refined form of the business/personal > > distinction. > > > > Another sort of capability is media. I might be > > available for voice only, or for voice and/or IM > > and/or video at a given address. > > > > Capacity can be viewed a couple of ways: maybe I can > > do IM both on my phone and my PC, but I can do it > > well on my PC with a keyboard, whereas I can only do > > it poorly on my > > phone. > > > > Capacity can also be a function of the person > > manning the presentity. Suppose the address is > > sip:answers@cars.r.us.com. Sometimes there is an > > auto guru manning it, so the > > capacity for auto-repair is high. Other times only a > > trainee is present, who will try, but isn't very > > good at auto-repair questions. So the capacity is > > less. > > > > > > > > Rather, I would prefer to see something like > > > CC/PP used in conjunction with presence to enable > > > the scenarios you are talking about. > > > > I hadn't heard of CC/PP until now. After a (very) > > quick search, it sounds like it is solving a > > different problem. Perhaps it is still applicable, > > but if so it would still > > need to be integrated with presence somehow. If it > > is XML, then perhaps it could be embedded in a > > special in the presence document. Because > > this stuff can change > > dynamically, and the presence client may need it to > > decide who to call, it would be bad to have to > > initiate some other sort of session with the > > presentity or contact to get > > this information. > > > > Paul > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jun 17 19:34:26 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23568 for ; Mon, 17 Jun 2002 19:34:26 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5HNY7oF006128; Mon, 17 Jun 2002 19:34:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02743; Mon, 17 Jun 2002 19:34:03 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02732 for ; Mon, 17 Jun 2002 19:33:26 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5HNX6V28581; Mon, 17 Jun 2002 18:33:07 -0500 From: "Dean Willis" To: "'Sean Olson'" , "'Paul Kyzivat'" Cc: "'Rosen, Brian'" , "'Jonathan Rosenberg'" , , "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , Subject: RE: Status discussion again RE: [Simple] Test message Message-ID: <071a01c21657$38248b00$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020613224139.65227.qmail@web11602.mail.yahoo.com> Importance: Normal Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 17 Jun 2002 18:32:16 -0500 Content-Transfer-Encoding: 7bit > I believe a raw notion of capability (e-mail, http, > sip, etc.) may be appropriate for a "presence" > document. Yes! But I think of this as "style" or "mode" rather than capability. It expresses the semantic of "I prefer to communicate in this mode" rather than "My equipment is outfitted with a ____ ". -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 18 08:57:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15406 for ; Tue, 18 Jun 2002 08:57:52 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5ICv3oF008427; Tue, 18 Jun 2002 08:57:03 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04946; Tue, 18 Jun 2002 08:57:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04935 for ; Tue, 18 Jun 2002 08:56:51 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5ICvBnt018759; Tue, 18 Jun 2002 08:57:11 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAM08563; Tue, 18 Jun 2002 09:01:17 -0400 (EDT) Message-ID: <3D0F2E07.3390C89D@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Sean Olson'" , "'Rosen, Brian'" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <071a01c21657$38248b00$eb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Jun 2002 08:56:39 -0400 Content-Transfer-Encoding: 7bit Dean Willis wrote: > > > I believe a raw notion of capability (e-mail, http, > > sip, etc.) may be appropriate for a "presence" > > document. > > Yes! But I think of this as "style" or "mode" rather than capability. It > expresses the semantic of "I prefer to communicate in this mode" rather > than "My equipment is outfitted with a ____ ". By all means, think of it that way if it makes you feel better. But it amounts to the same thing either way. After all, this is *presence*, so you aren't just saying you prefer to communicate in that mode - you are saying you are (or believe you are) ready and capable of doing so. (It wouldn't be very useful to advertise your presence for IM unless you actually could receive IM messages.) The major difference is perhaps that you may be capable of modes that your prefer not to use. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 18 22:59:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12511 for ; Tue, 18 Jun 2002 22:59:10 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5J2wCoF014971; Tue, 18 Jun 2002 22:58:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07408; Tue, 18 Jun 2002 22:58:08 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07397 for ; Tue, 18 Jun 2002 22:57:54 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g5J2rgV06089; Tue, 18 Jun 2002 21:53:42 -0500 Message-ID: <008301c2173c$888e77f0$2dacff0c@C1893415A> From: "Dean Willis" To: "Paul Kyzivat" Cc: "'Sean Olson'" , "'Rosen, Brian'" , "'Jonathan Rosenberg'" , , "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , References: <071a01c21657$38248b00$eb036e3f@TXDWILLIS2> <3D0F2E07.3390C89D@cisco.com> Subject: Re: Status discussion again RE: [Simple] Test message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Jun 2002 21:53:45 -0500 Content-Transfer-Encoding: 7bit When the 3G people talk "capability" they sometimes mean "I have a 160x160 display in 4-shade gray, the following fonts, a speaker phone, a microphone, AMR, EFR, and FR codecs, and a camera that can capture QQCIF at 4 fps. My contract allows authorization of RABs to 144kbps after 8:00 PM in my local time zone. My keyboard map is " . . . overloaded term. -- Dean ----- Original Message ----- From: "Paul Kyzivat" To: "Dean Willis" Cc: "'Sean Olson'" ; "'Rosen, Brian'" ; "'Jonathan Rosenberg'" ; ; "'Li Hua Tang'" ; "'DAO TRUNG Tin FTRD/DAC/ISS'" ; Sent: Tuesday, June 18, 2002 7:56 AM Subject: Re: Status discussion again RE: [Simple] Test message > > > Dean Willis wrote: > > > > > I believe a raw notion of capability (e-mail, http, > > > sip, etc.) may be appropriate for a "presence" > > > document. > > > > Yes! But I think of this as "style" or "mode" rather than capability. It > > expresses the semantic of "I prefer to communicate in this mode" rather > > than "My equipment is outfitted with a ____ ". > > By all means, think of it that way if it makes you feel better. > > But it amounts to the same thing either way. After all, this is *presence*, so you aren't just saying you prefer to communicate in that mode - you are saying you are (or > believe you are) ready and capable of doing so. > > (It wouldn't be very useful to advertise your presence for IM unless you actually could receive IM messages.) > > The major difference is perhaps that you may be capable of modes that your prefer not to use. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 18 23:02:25 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12640 for ; Tue, 18 Jun 2002 23:02:25 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5J321oF015006; Tue, 18 Jun 2002 23:02:01 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07439; Tue, 18 Jun 2002 23:02:03 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07414 for ; Tue, 18 Jun 2002 22:58:22 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g5J2wGV06121; Tue, 18 Jun 2002 21:58:17 -0500 Message-ID: <008b01c2173d$2b8474a0$2dacff0c@C1893415A> From: "Dean Willis" To: "Peterson, Jon" , Cc: References: <70565611B164D511957A001083FCDD56018703CD@va02.va.neustar.com> Subject: Re: [Simple] Message sessions MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Jun 2002 21:58:20 -0500 Content-Transfer-Encoding: 7bit Jon asked: > Now that the presence and watcherinfo work has gone forward to the IESG, we > need to return to the issue of message sessions - we are quite a bit overdue . . . > Two proposals have been made for session protocols: > > http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-01.txt > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi on-0 > 0.txt I personally lean towards the mrose approach. BEEP does a decent job of the message delivery operation. It allows standardized relay elements to be added as needed and provides for a sort of path-discovery that would appear to be beneficial in firewall traversal scenarios. It provides a nice layering distinctiuon between "can I talk to you" and "may I talk to the network". -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 19 13:43:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28737 for ; Wed, 19 Jun 2002 13:43:49 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5JHh5oF019991; Wed, 19 Jun 2002 13:43:05 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10176; Wed, 19 Jun 2002 13:43:04 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10165 for ; Wed, 19 Jun 2002 13:42:09 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g5JHg7h03361; Wed, 19 Jun 2002 19:42:07 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g5JHg5i23705; Wed, 19 Jun 2002 19:42:06 +0200 (MEST) Received: from alpha.mchp.siemens.de (alpha [139.23.202.151]) by mail-y.mchp.siemens.de with ESMTP id g5JHg4VZ026696; Wed, 19 Jun 2002 19:42:04 +0200 (MET DST) Received: from cs.columbia.edu (mhpa6v8c [139.23.202.84]) by alpha.mchp.siemens.de with ESMTP id g5JHg4q9029130; Wed, 19 Jun 2002 19:42:04 +0200 (MET DST) Message-ID: <3D10C246.3060803@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "Peterson, Jon" , simple@mailman.dynamicsoft.com, rsparks@dynamicsoft.com Subject: Re: [Simple] Message sessions References: <70565611B164D511957A001083FCDD56018703CD@va02.va.neustar.com> <008b01c2173d$2b8474a0$2dacff0c@C1893415A> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 19 Jun 2002 13:41:26 -0400 Content-Transfer-Encoding: 7bit I would prefer simple-message-session. I don't want to have to administer two very different types of devices, with different (and, in the case of mrose, undefined) network management. I still agree with the argument in simple-message that a unified mechanism for page and session is very desirable. Transitioning and gatewaying will be much easier. I don't see why mrose has an advantage in "standardized relay elements to be added as needed". What can be added there that can't be added in simple-message? I'm afraid I find the "firewall discovery" item too vague to understand what exactly the advantage would be. The overall system complexity, in terms of explaining what's going on and in terms of implementing, seem far less in a unified system where page and session mode share conceptual elements where this makes sense. Dean Willis wrote: > Jon asked: > >>Now that the presence and watcherinfo work has gone forward to the > > IESG, we > >>need to return to the issue of message sessions - we are quite a bit > > overdue > . . . > >>Two proposals have been made for session protocols: >> >>http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-01.txt >> > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi > on-0 > >>0.txt > > > I personally lean towards the mrose approach. BEEP does a decent job of > the message delivery operation. It allows standardized relay elements to > be added as needed and provides for a sort of path-discovery that would > appear to be beneficial in firewall traversal scenarios. It provides a > nice layering distinctiuon between "can I talk to you" and "may I talk > to the network". > > -- > Dean > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 20 08:12:41 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26716 for ; Thu, 20 Jun 2002 08:12:41 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5KCBDoF025811; Thu, 20 Jun 2002 08:11:13 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13256; Thu, 20 Jun 2002 08:11:06 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id IAA13245 for ; Thu, 20 Jun 2002 08:10:47 -0400 (EDT) Received: (qmail 22824 invoked from network); 20 Jun 2002 13:08:52 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.40) by nghmail with SMTP; 20 Jun 2002 13:08:52 -0000 Message-ID: <004601c21853$d226b720$5601a8c0@knowsys.net> From: "vishal" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C21881.E1EABB60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Simple] buddy list draft Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 20 Jun 2002 17:42:43 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C21881.E1EABB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , Is there any draft available which talks about buddy list management = ,I mean what message should be sent to add,delete and modify buddy list = information regards, vishal Vishal , Knowledge Systems Pvt Ltd ,INDIA 470, East End Main Road =20 9th Block Jayanagar , Bangalore 560 069 =20 Telephone: +91-80-6545252 ------=_NextPart_000_0041_01C21881.E1EABB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi ,
    Is there any draft = available=20 which talks about buddy list management ,I mean what message should be = sent to=20 add,delete and modify buddy list information
 
regards, vishal
 
Vishal ,
Knowledge Systems Pvt = Ltd =20 ,INDIA
470, East End Main Road 
9th Block Jayanagar = ,
Bangalore=20 560 069 
Telephone: +91-80-6545252
------=_NextPart_000_0041_01C21881.E1EABB60-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 20 09:42:31 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29763 for ; Thu, 20 Jun 2002 09:42:31 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5KDf2oF026521; Thu, 20 Jun 2002 09:41:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13566; Thu, 20 Jun 2002 09:41:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13555 for ; Thu, 20 Jun 2002 09:40:04 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.185]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5KDe4YH018098; Thu, 20 Jun 2002 09:40:05 -0400 (EDT) Message-ID: <3D11DB33.2020105@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vishal CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] buddy list draft References: <004601c21853$d226b720$5601a8c0@knowsys.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 20 Jun 2002 09:40:03 -0400 Content-Transfer-Encoding: 7bit There is nothing yet, beyond things like using the web (which I still think is the best means whenever its available). One of the items on our new charter is a requirements document for manipulation of buddy lists, amongst other operations, which will lead to a specification for such manipulations. -Jonathan R. vishal wrote: > Hi , > Is there any draft available which talks about buddy list management > ,I mean what message should be sent to add,delete and modify buddy list > information > > regards, vishal > > Vishal , > Knowledge Systems Pvt Ltd ,INDIA > 470, East End Main Road > 9th Block Jayanagar , > Bangalore 560 069 > Telephone: +91-80-6545252 > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 20 17:32:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13358 for ; Thu, 20 Jun 2002 17:32:00 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5KLVBoF001423; Thu, 20 Jun 2002 17:31:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14911; Thu, 20 Jun 2002 17:31:07 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14900 for ; Thu, 20 Jun 2002 17:30:14 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g5KLUBr28766; Thu, 20 Jun 2002 16:30:11 -0500 (CDT) Message-ID: <3D124922.4010509@dynamicsoft.com> From: Ben Campbell 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: Simple CC: Ben Campbell , Jonathan Rosenberg , Brian Stucker , Sean Olson , Jon Peterson References: <3D00F561.9010208@dynamicsoft.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Choosing a mechanism for presence publication. Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 20 Jun 2002 16:29:06 -0500 Content-Transfer-Encoding: 7bit Several of us have engaged in an offline discussion on how to handle the publication of presence imformation from a PUA to a remote PA. We think we have reached a preliminary conclusion on the mechanism choice. This email reflects (what I believe to be) the consensus of that group so far. The bottom line is, there is significant advantage in using a SIP based mechanism. There has been some controversy over the choice of mechanism by which SIMPLE presence user agents publish information to remote presence agents. The two most favored approaches so far have been the creation of a new SIP method for the purpose, and the use of HTTP. Nature of Presence Publication: We propose a model for presence composition where more than one PUA may publish on behalf of a single presentity. Those PUAs may exist in separate administrative domains. The publications eventually make it to a logical network element that composes the views of presence sent by the various PUAs into a composite presence document. For the moment, at least, we are calling this logical element a "compositor". This model implies a few assumptions for publication: 1) A PUA must be capable of remotely publishing a presence document to a compositor. There is no requirement so far for the PUA to query a PA to determine what document it had published previously. We assume the PUA can subscribe to the final composed document via SIMPLE. 2) A presence document can be expressed by a MIME body part. 3) The document published by a PUA to a particular input is not dependent upon previous publications to that input. The only transaction semantic for a given input is "replace". (Note that this does not prevent the compositor from applying complex application semantics to compose the input, along with all other inputs, into a composite presence document.) Any versioning is handled by payload itself. 4) The composition semantics belong to the local policy of the compositor. The PUA does not need to understand these semantics, and cannot expect to make composition policy choices as part of the publication action. If a principle needs to make composition policy decisions, that is through some other mechanism. 5) There may be multiple PUAs publishing on behalf of the same presentity. There is no assumption that these PUAs all connect through the same network, or even belong to the same administrative or security domain. Differences between HTTP and SIP publication: HTTP is well suited for moving data around in the form of MIME body parts. An HTTP client-to-server publication solution would not require much work to specify. A SOAP over HTTP solution would additionally allow complex transaction semantics with little additional work. HTTP, however, does not have a well-defined routing model at the application level. It works fine if the publication point is well known and fairly static, but it will require additional work to deal with situations where the publication point changes dynamically. SIP, on the otherhand, is built around the concept of mobility of endpoints. The SIP proxy, registrar, and location service concepts provide a rich mechanism of finding a dynamically changing endpoint from and address of record. SIP, however, does not have an existing method suited for presence publication. REGISTER gets us part of the way, but has well-known limitations when used for this purpose. SIP is, by nature, also adept at moving around MIME payloads, so the creation of such a method is not a particularly difficult task. Motivation for a SIP based mechanism: The application-level routing capabilities of SIP can be very useful for presence publication. If all PUAs for a given presentity exist in the same administrative domain, then they can most likely publish directly to a compositor. But if PUAs exist outside the administrative domain, it is likely they will not be able to do so. For example, suppose that Alice uses a presence service that allows multiple PUAs to publish to a compositor inside the service provider network. Further suppose that Alice wishes to incorporate presence information from an external provider, that has no business relationship with her primary provider. For this example, Alice wishes to use a shared browsing service that tracks the "location" she is currently browsing in the web. That service acts as a PUA on Alice's behalf, and publishes the information to her primary presence provider. Other users of the shared browsing service can subscribe to her presence information, and determine when they are browsing the same site. The presence provider is highly unlikely to allow the external PUA to send data directly to the compositor. But if Alice registers a contact with a methods parameter value of "PUBLISH", that PUA can send a publish request to an edge proxy in the presence providers network, and use Alice's address of record as the requestURI. This AoR could be her normal SIP URI, or it could be a special AoR for the purposes of presence publication. The proxy forwards the request to the compositor, without the external PUA having to talk directly to the compositor, or even know its IP address. Now consider that Alice's primary providor is actually an enterprise. That enterprise has different compositors for different departments. The external provider has no way of knowing this internal organization, nor does it know what department Alice works in. Still, Alice register's her publication contact at an enterprise registrar, the external provider sends the publish request to Alice's address of record, and the companies internal SIP network handles things from there, eventually getting the request to the correct compositor. The composition model does not at first appear to require publishing to dynamically changing PAs. But a very powerful, but often forgotten, aspect of SIMPLE is it allows a PA to exist on an end-user device. Indeed, some early implentations of SIMPLE rely on exactly that model. It is reasonable to expect the composition model above to co-exist with end-user device PAs, where the PA location changes dynamically. For example, imagine Alice hosts a PA on her PC, which aquires its IP address via DHCP. This address changes relatively frequently, and registers a publish contact with an enterprise registrar. Now, imagine she also has a mobile phone which contains a PUA. She wants her presence document to show a combined view of her PCs concept of her presence and her mobile phone service's concept of her precence. She cannot simply tell the mobile service her PC address since it changes often. Instead, she tells the service an AoR to publish presence to. The mobile service publishes presence state to that AoR, which resolves to a SIP proxy or redirect server. Normal SIP proxy or redirect behavior is invoked to get the publication to Alice's PC based on her publish contact registration. It is our opinion that SIP style routing is very useful for presence publication. Without the application level routing capabilities of SIP, it would be difficult to build these sort of services. It is more appropriate to add a publication mechanism to SIP than to standardize SIP-style routing features for HTTP proxies. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 20 22:13:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18701 for ; Thu, 20 Jun 2002 22:13:36 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5L2D2oF002546; Thu, 20 Jun 2002 22:13:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15701; Thu, 20 Jun 2002 22:13:03 -0400 (EDT) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15690 for ; Thu, 20 Jun 2002 22:12:34 -0400 (EDT) Received: from maillennium.att.com ([135.25.114.99]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g5L2CWgY018617 for ; Thu, 20 Jun 2002 22:12:33 -0400 (EDT) Received: from att.com ([135.210.40.170]) by maillennium.att.com (mailgw1) with SMTP id <20020621021231gw1009aru9e> (Authid: tony); Fri, 21 Jun 2002 02:12:31 +0000 Message-ID: <3D128B90.8080600@att.com> From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple Subject: Re: [Simple] Choosing a mechanism for presence publication. References: <3D00F561.9010208@dynamicsoft.com> <3D124922.4010509@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 20 Jun 2002 22:12:32 -0400 Content-Transfer-Encoding: 7bit I feel that this is going in the right direction and agree with the conclusion to use a SIP enhancement for doing publication. Tony Hansen tony@att.com Ben Campbell wrote: > Several of us have engaged in an offline discussion on how to handle the > publication of presence imformation from a PUA to a remote PA. We think > we have reached a preliminary conclusion on the mechanism choice. This > email reflects (what I believe to be) the consensus of that group so > far. The bottom line is, there is significant advantage in using a SIP > based mechanism. ... _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jun 21 16:56:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01157 for ; Fri, 21 Jun 2002 16:56:43 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5LKu1oF008785; Fri, 21 Jun 2002 16:56:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18847; Fri, 21 Jun 2002 16:56:04 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18836 for ; Fri, 21 Jun 2002 16:55:00 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g5LKsIr25601; Fri, 21 Jun 2002 15:54:18 -0500 (CDT) Message-ID: <3D139238.8010102@dynamicsoft.com> From: Ben Campbell 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: Sean Olson CC: Paul Kyzivat , "Rosen, Brian" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <20020613224139.65227.qmail@web11602.mail.yahoo.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 15:53:12 -0500 Content-Transfer-Encoding: 7bit Sean Olson wrote: > I think we are talking about different things. Part > of the confusion on "status" is that it can refer > to *at least* three different things: > > 1. Presence - can I communicate > 2. Availability - do I want to communicate > 3. Capability - what are the mechanisms I have > at my disposal to communicate with > > I believe a raw notion of capability (e-mail, http, > sip, etc.) may be appropriate for a "presence" > document. > > However, more advanced notions such as I support > H.263 video or I have a color display capable of > 640x480 resolution, etc. are a bit of a stretch. > > Part of these device capabilities are covered > by CC/PP (the target application is web browsing, > but the CC/PP framework can be extended to much > broader capabilities ala RDF) One could also make this sort of thing up to the underlying communication protocol, rather than move them as part of presence. For example, I might have a SIP contact in a presence document. I don't have to add what codecs I support. If someone wants to talk to me, they send an INVITE, and the normal SIP process figures out the codec. There is of course some benefit to knowing the mode (am I INVITEing for a video session vs. a voice session.) > > /sean > > --- Paul Kyzivat wrote: > >> >>Sean Olson wrote: >> >>>I may be misunderstanding you, but I don't >>>believe capacity and capabilities are necessarily >>>things you want to publish as presence. I agree >>>they are useful things to have for routing >>>decisions, I just don't think they should be >>>part of a presence document. >> >>Maybe we aren't thinking of the same things, because >>I see these as very relevant to presence. >> >>For instance, capability/willingness to communicate >>on the subject of auto-repair is just a slightly >>more refined form of the business/personal >>distinction. >> >>Another sort of capability is media. I might be >>available for voice only, or for voice and/or IM >>and/or video at a given address. >> >>Capacity can be viewed a couple of ways: maybe I can >>do IM both on my phone and my PC, but I can do it >>well on my PC with a keyboard, whereas I can only do >>it poorly on my >>phone. >> >>Capacity can also be a function of the person >>manning the presentity. Suppose the address is >>sip:answers@cars.r.us.com. Sometimes there is an >>auto guru manning it, so the >>capacity for auto-repair is high. Other times only a >>trainee is present, who will try, but isn't very >>good at auto-repair questions. So the capacity is >>less. >> >> >>>Rather, I would prefer to see something like >>>CC/PP used in conjunction with presence to enable >>>the scenarios you are talking about. >> >>I hadn't heard of CC/PP until now. After a (very) >>quick search, it sounds like it is solving a >>different problem. Perhaps it is still applicable, >>but if so it would still >>need to be integrated with presence somehow. If it >>is XML, then perhaps it could be embedded in a >>special in the presence document. Because >>this stuff can change >>dynamically, and the presence client may need it to >>decide who to call, it would be bad to have to >>initiate some other sort of session with the >>presentity or contact to get >>this information. >> >> Paul > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jun 21 18:46:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03353 for ; Fri, 21 Jun 2002 18:46:49 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5LMk8oF009535; Fri, 21 Jun 2002 18:46:08 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19191; Fri, 21 Jun 2002 18:46:06 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19180 for ; Fri, 21 Jun 2002 18:45:28 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5LMjfjX019617; Fri, 21 Jun 2002 18:45:41 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAM32030; Fri, 21 Jun 2002 18:49:47 -0400 (EDT) Message-ID: <3D13AC75.B14B3AAE@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Sean Olson , "Rosen, Brian" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <20020613224139.65227.qmail@web11602.mail.yahoo.com> <3D139238.8010102@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 18:45:09 -0400 Content-Transfer-Encoding: 7bit Regarding what sort of "capabilities" should be reflected in presence, knowing the mode (audio, video, etc.) is very important. Individual codecs is probably going too far. But this is a fine line. While I probably don't want to describe codecs for audio, I perhaps do want to describe the "codecs" for application - e.g. application/wb - because the likelihood of success isn't very good without. Maybe this is a matter of judicious use of wildcards - advertise audio/* but application/wb. Paul Ben Campbell wrote: > > One could also make this sort of thing up to the underlying > communication protocol, rather than move them as part of presence. For > example, I might have a SIP contact in a presence document. I don't have > to add what codecs I support. If someone wants to talk to me, they send > an INVITE, and the normal SIP process figures out the codec. There is of > course some benefit to knowing the mode (am I INVITEing for a video > session vs. a voice session.) _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jun 21 19:42:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04418 for ; Fri, 21 Jun 2002 19:42:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5LNf0oF009772; Fri, 21 Jun 2002 19:41:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19371; Fri, 21 Jun 2002 19:41:03 -0400 (EDT) Received: from web11605.mail.yahoo.com (web11605.mail.yahoo.com [216.136.172.57]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA19360 for ; Fri, 21 Jun 2002 19:40:34 -0400 (EDT) Message-ID: <20020621234033.95187.qmail@web11605.mail.yahoo.com> Received: from [207.46.137.9] by web11605.mail.yahoo.com via HTTP; Fri, 21 Jun 2002 16:40:33 PDT From: Sean Olson Subject: Re: Status discussion again RE: [Simple] Test message To: Paul Kyzivat , Ben Campbell Cc: Sean Olson , "Rosen, Brian" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com In-Reply-To: <3D13AC75.B14B3AAE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 16:40:33 -0700 (PDT) Mode seems to make sense. I like the idea of announcing supported MIME types, BUT I think it is very dangerous to infer applications from MIME types (as you hint at for the application/wb case). I see this leading to a rathole. Could we set the bar at just announcing "modes" for now? /sean --- Paul Kyzivat wrote: > Regarding what sort of "capabilities" should be > reflected in presence, knowing the mode (audio, > video, etc.) is very important. Individual codecs is > probably going too far. > > But this is a fine line. While I probably don't want > to describe codecs for audio, I perhaps do want to > describe the "codecs" for application - e.g. > application/wb - > because the likelihood of success isn't very good > without. > > Maybe this is a matter of judicious use of wildcards > - advertise audio/* but application/wb. > > Paul > > Ben Campbell wrote: > > > > One could also make this sort of thing up to the > underlying > > communication protocol, rather than move them as > part of presence. For > > example, I might have a SIP contact in a presence > document. I don't have > > to add what codecs I support. If someone wants to > talk to me, they send > > an INVITE, and the normal SIP process figures out > the codec. There is of > > course some benefit to knowing the mode (am I > INVITEing for a video > > session vs. a voice session.) > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jun 24 07:50:35 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01079 for ; Mon, 24 Jun 2002 07:50:35 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5OBoON7000796; Mon, 24 Jun 2002 07:50:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00785; Mon, 24 Jun 2002 07:50:19 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00771 for ; Mon, 24 Jun 2002 07:49:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00840; Mon, 24 Jun 2002 07:49:13 -0400 (EDT) Message-Id: <200206241149.HAA00840@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-allen-simple-msg-3gpp-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 24 Jun 2002 07:49:13 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : 3GPP work on SIP based messaging Author(s) : A. Allen Filename : draft-allen-simple-msg-3gpp-00.txt Pages : 6 Date : 21-Jun-02 The 3rd Generation Partnership Project (3GPP) is using SIP RFC 3261 [1] as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IM CN Subsystem). 3GPP has recently started working on messaging over the IM CN Subsystem. It is intended that this will utilize the IM CN Subsystem for delivery and may be based on IEFT protocols including the work being performed in the SIMPLE working group. In this document is provided an outline and areas of interest of the 3GPP work on SIP based messaging for the information of the SIMPLE working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allen-simple-msg-3gpp-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-allen-simple-msg-3gpp-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-allen-simple-msg-3gpp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020621140602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allen-simple-msg-3gpp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-allen-simple-msg-3gpp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621140602.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 25 01:24:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14011 for ; Tue, 25 Jun 2002 01:24:50 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5P5O2N7007260; Tue, 25 Jun 2002 01:24:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03651; Tue, 25 Jun 2002 01:24:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03640 for ; Tue, 25 Jun 2002 01:23:21 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5P5NYvl014191; Tue, 25 Jun 2002 01:23:35 -0400 (EDT) Received: from cisco.com (sjc-vpn2-896.cisco.com [10.21.115.128]) by cannon.cisco.com (Mirapoint) with ESMTP id AAM40701; Tue, 25 Jun 2002 01:27:31 -0400 (EDT) Message-ID: <3D17FE2C.60CDC385@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: Ben Campbell , "Rosen, Brian" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <20020621234033.95187.qmail@web11605.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 25 Jun 2002 01:22:52 -0400 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Mode seems to make sense. I like the idea > of announcing supported MIME types, BUT I think > it is very dangerous to infer applications from > MIME types (as you hint at for the > application/wb case). I see this leading to a > rathole. Could we set the bar at just > announcing "modes" for now? You have to tell me what you mean by "mode" then. I don't think of application/wb as an "application" in any specific sense. As far as I am concerned, "application" and "voice" are simply different subdivisions of the overall mimetype namespace. But "voice" in its own right is much more specific than "application" is. I have a reasonable chance of deciding if I can support "voice" without more detail. (If I can't support the offered codecs then I can probably find a transcoder that can convert to something I do understand.) But by itself "application" tells me nothing about what I will be expected to do. And in general there are no transcoders that can convert between application/wb that I support and application/foo that I don't - there is no least common denominator between subtypes of application. If the bar is set so low that mime subtypes can never be used, then presence will not be at all useful for any media that happen to be described by subtypes of application. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 25 02:38:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24242 for ; Tue, 25 Jun 2002 02:38:41 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5P6c6N7007494; Tue, 25 Jun 2002 02:38:06 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03891; Tue, 25 Jun 2002 02:38:04 -0400 (EDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA03880 for ; Tue, 25 Jun 2002 02:37:35 -0400 (EDT) Received: from 12-235-154-217.client.attbi.com (HELO BOB) (seancolson@12.235.154.217 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jun 2002 06:37:30 -0000 Reply-To: From: "Sean Olson" To: "'Paul Kyzivat'" Cc: "'Ben Campbell'" , "'Rosen, Brian'" , "'Jonathan Rosenberg'" , , "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , Subject: RE: Status discussion again RE: [Simple] Test message Message-ID: <000001c21c12$cb7ab1c0$6601a8c0@BOB> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3D17FE2C.60CDC385@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 24 Jun 2002 23:37:35 -0700 Content-Transfer-Encoding: 7bit What I mean is that while application/wb may give you a clue as to the application, text/html, image/jpeg, or even message/sip do not. MIME types are not usually a good indication of the application that will process that media. "voice" is interesting, but as a MIME type would more likely be represented as the less useful audio/g711, etc. If what you want to convey is a list of MIME types, that's fine. I just don't want to confuse that with a list of applications. (Of course, MIME types are best represented with a suitable subtype as you mention) By mode, I meant a token that succintly defines an application -- like "voice" perhaps. But I definitely don't want to get into the game of defining a list of codecs ... this is much better handled by SIP itself than by a presence document format. /sean -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Paul Kyzivat Sent: Monday, June 24, 2002 10:23 PM To: Sean Olson Cc: Ben Campbell; Rosen, Brian; 'Jonathan Rosenberg'; bateman@acm.org; 'Li Hua Tang'; 'DAO TRUNG Tin FTRD/DAC/ISS'; simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message Sean Olson wrote: > > Mode seems to make sense. I like the idea > of announcing supported MIME types, BUT I think > it is very dangerous to infer applications from > MIME types (as you hint at for the > application/wb case). I see this leading to a > rathole. Could we set the bar at just > announcing "modes" for now? You have to tell me what you mean by "mode" then. I don't think of application/wb as an "application" in any specific sense. As far as I am concerned, "application" and "voice" are simply different subdivisions of the overall mimetype namespace. But "voice" in its own right is much more specific than "application" is. I have a reasonable chance of deciding if I can support "voice" without more detail. (If I can't support the offered codecs then I can probably find a transcoder that can convert to something I do understand.) But by itself "application" tells me nothing about what I will be expected to do. And in general there are no transcoders that can convert between application/wb that I support and application/foo that I don't - there is no least common denominator between subtypes of application. If the bar is set so low that mime subtypes can never be used, then presence will not be at all useful for any media that happen to be described by subtypes of application. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 25 09:23:02 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04764 for ; Tue, 25 Jun 2002 09:23:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5PDM9N7008877; Tue, 25 Jun 2002 09:22:09 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05020; Tue, 25 Jun 2002 09:22:07 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05008 for ; Tue, 25 Jun 2002 09:21:53 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5PDNfW22368 for ; Tue, 25 Jun 2002 16:23:42 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Jun 2002 16:21:51 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 25 Jun 2002 16:21:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message sessions Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE33C@esebe013.NOE.Nokia.com> Thread-Topic: [Simple] Message sessions Thread-Index: AcIXuTuQ/elXHPCLSDuf9UxUbxd0LAD0ru2A To: , Cc: , , X-OriginalArrivalTime: 25 Jun 2002 13:21:51.0651 (UTC) FILETIME=[44761730:01C21C4B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA05008 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 25 Jun 2002 16:21:51 +0300 Content-Transfer-Encoding: 8bit Hi, I would also prefer simple-message-session, mainly because of the ability to have a unified mechanism for both the paging mode and the session mode IM. Also, having SIP MESSAGE as the session transport may have benefits in multiparty sessions. However, I don't see any reason why simple-exchange shouldn't progress as well. Ultimately these are session IM "codecs", and I don't think having several of them hurts as long as there is one that by default is supported by all implementations. So perhaps we should have simple-message-session as a WG item for SIMPLE, but encourage simple-exchange to progress as well. Maybe towards Informational RFC status, if not standards track? Cheers, Aki > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, June 19, 2002 8:41 PM > To: Dean Willis > Cc: Peterson, Jon; simple@mailman.dynamicsoft.com; > rsparks@dynamicsoft.com > Subject: Re: [Simple] Message sessions > > > I would prefer simple-message-session. I don't want to have to > administer two very different types of devices, with > different (and, in > the case of mrose, undefined) network management. > > I still agree with the argument in simple-message that a unified > mechanism for page and session is very desirable. Transitioning and > gatewaying will be much easier. > > I don't see why mrose has an advantage in "standardized relay > elements > to be added as needed". What can be added there that can't be > added in > simple-message? > > I'm afraid I find the "firewall discovery" item too vague to > understand > what exactly the advantage would be. > > The overall system complexity, in terms of explaining what's going on > and in terms of implementing, seem far less in a unified system where > page and session mode share conceptual elements where this > makes sense. > > Dean Willis wrote: > > Jon asked: > > > >>Now that the presence and watcherinfo work has gone forward to the > > > > IESG, we > > > >>need to return to the issue of message sessions - we are quite a bit > > > > overdue > > . . . > > > >>Two proposals have been made for session protocols: > >> > >>http://www.ietf.org/internet-drafts/draft-mrose-simple-excha nge-01.txt >> > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi > on-0 > >>0.txt > > > I personally lean towards the mrose approach. BEEP does a decent job of > the message delivery operation. It allows standardized relay elements to > be added as needed and provides for a sort of path-discovery that would > appear to be beneficial in firewall traversal scenarios. It provides a > nice layering distinctiuon between "can I talk to you" and "may I talk > to the network". > > -- > Dean > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 25 17:35:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29853 for ; Tue, 25 Jun 2002 17:35:41 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5PLZ3N7013388; Tue, 25 Jun 2002 17:35:03 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06518; Tue, 25 Jun 2002 17:35:05 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06505 for ; Tue, 25 Jun 2002 17:34:41 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5PLYfYH022376 for ; Tue, 25 Jun 2002 17:34:41 -0400 (EDT) Message-ID: <3D18E1EF.7050700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] updated buddy list package draft Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 25 Jun 2002 17:34:39 -0400 Content-Transfer-Encoding: 7bit Folks, I've submitted an update to the buddy list event package. As this is now a charter item based on our new charter, it also has a new -ietf name. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-simple-presencelist-package-00.txt Some of the changes since the previous version: * change from the term "buddy list" to "presence list" and "buddy" to "presentity" since apparently buddy list is an AOL term. * specified a new XML document type, using XML schema, that adds list capability to PIDF. THis is now a mandatory-to imeplement type for this package. You also need to support PIDF and MAY support multipart/mixed. * a presence-list can contain presentities and also other presence-lists. This requires the presence list server (PLS) to itself use the presence-list package when subscribing to elements in the list, and then backing off to regular presence if that package is not supported. This is a potential issue. * formal specification of algorithm to support partial updates. * IANA registrations of new namespace and MIME type. There are several open issues. I will send separate emails on those, one per each open issue, in order to facilitate discussion. THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jun 25 22:26:30 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06834 for ; Tue, 25 Jun 2002 22:26:30 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5Q2Q7N7014602; Tue, 25 Jun 2002 22:26:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07324; Tue, 25 Jun 2002 22:26:04 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07313 for ; Tue, 25 Jun 2002 22:25:12 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5Q2PDYH022507 for ; Tue, 25 Jun 2002 22:25:13 -0400 (EDT) Message-ID: <3D192608.6030407@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] new I-D on data requirements Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 25 Jun 2002 22:25:12 -0400 Content-Transfer-Encoding: 7bit Folks, Myself and Markus Isomaki have submitted an Internet Draft that is a first cut at requirements for management of buddy list and authorization list functions (this is also a new item on our charter). Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt In addition to the baseline requirements for these functions, the draft also proposes a model for unifying these problems. This is also a first cut; comments and criticisms and welcome. My aim is to determine if there is consensus to adopt this as the starting point for our work item on this topic. Thanks! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 02:22:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29541 for ; Wed, 26 Jun 2002 02:22:42 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5Q6M2N7015308; Wed, 26 Jun 2002 02:22:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07962; Wed, 26 Jun 2002 02:22:04 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA07951 for ; Wed, 26 Jun 2002 02:21:55 -0400 (EDT) Received: (qmail 28508 invoked from network); 26 Jun 2002 07:19:38 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.36) by nghmail with SMTP; 26 Jun 2002 07:19:38 -0000 Message-ID: <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net> From: "vishal" To: "Jonathan Rosenberg" , References: <3D192608.6030407@dynamicsoft.com> Subject: Re: [Simple] new I-D on data requirements MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 11:52:26 +0530 Content-Transfer-Encoding: 7bit Dr Jonathon, I think following requirements can also be added to this draft section 2.2 1. Server SHOULD be able to contact other servers in case buddy list not found in local storage. 2. server should be able to accept requests coming directly from client or via intermediate entity like proxy (if it includes authetication info). 3. server should be able to route response over same route as request i.e support for record-route. 4. MUST have Multicast capability at server i.e UDP support .In case buddy list shared by many user ,modified by one user then server SHOULD be able to synchronize cache of clients. 5. Server SHOULD be able to limit maximum number of users sharing buddy list. 6. Server SHOULD be able to specify maximum buddy list nesting(list within list) level. section 2.2 REQ 8: A buddy list should be considered deleted when all the owners of buddy list have deleted it. Deleted buddy list should not be accessible after deletion section 4.3 (protocol requirements) 1. Support for conference invitation to multiple users .Command can be sent to buddy list server with buddy list name .Server MUST resolve buddy list to buddy(s) and send INVITE message (or route through intermediate entity) to all online users after checking their status. regards, vishal ----- Original Message ----- From: Jonathan Rosenberg To: Sent: Wednesday, June 26, 2002 7:55 AM Subject: [Simple] new I-D on data requirements > Folks, > > Myself and Markus Isomaki have submitted an Internet Draft that is a > first cut at requirements for management of buddy list and authorization > list functions (this is also a new item on our charter). Until it > appears in the archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt > > In addition to the baseline requirements for these functions, the draft > also proposes a model for unifying these problems. This is also a first > cut; comments and criticisms and welcome. > > My aim is to determine if there is consensus to adopt this as the > starting point for our work item on this topic. > > Thanks! > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 09:22:30 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17721 for ; Wed, 26 Jun 2002 09:22:30 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5QDM4N7016667; Wed, 26 Jun 2002 09:22:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09138; Wed, 26 Jun 2002 09:22:04 -0400 (EDT) Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09127 for ; Wed, 26 Jun 2002 09:21:01 -0400 (EDT) Received: (from www@localhost) by keskus.tct.hut.fi (8.10.0/8.10.0) id g5QDKtB16772; Wed, 26 Jun 2002 16:20:55 +0300 (EET DST) From: Costa Requena X-Authentication-Warning: keskus.tct.hut.fi: www set sender to jose@tct.hut.fi using -f To: vishal Subject: Re: [Simple] new I-D on data requirements Message-ID: <1025097655.3d19bfb781f8d@keskus.tct.hut.fi> Cc: Jonathan Rosenberg , simple@mailman.dynamicsoft.com References: <3D192608.6030407@dynamicsoft.com> <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net> In-Reply-To: <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Originating-IP: 192.100.124.220 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 16:20:55 +0300 (EET DST) Content-Transfer-Encoding: 8bit Hi Vishal, I have some comments: > I think following requirements can also be added to this draft > section 2.2 > > 1. Server SHOULD be able to contact other servers in case buddy list > not found in local storage. Are you proposing some recursive mechanism in case the buddy list contain a nested buddy list? It could be OK if the nested buddy list is within the same domain but it could have some security flaws when fetching the buddy list from other serves/domain. I think it should be stated that nested buddy list should contain FQDN within the local domain. > 4. MUST have Multicast capability at server i.e UDP support .In case > buddy > list shared by many user ,modified by one user then server SHOULD be > able > to synchronize cache of > clients. Correct me if I'm wrong but is the idea to share the same buddy list by multiple users? I think that each presentity has its own buddy list, despite he/she can use different list to perform the buddy list functionality. The same buddy list can be used from different termianls but still the owner or presentity is the same. BR Jose _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 10:13:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19790 for ; Wed, 26 Jun 2002 10:13:11 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5QED0N7017262; Wed, 26 Jun 2002 10:13:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09358; Wed, 26 Jun 2002 10:13:04 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09347 for ; Wed, 26 Jun 2002 10:12:50 -0400 (EDT) Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5QECoxc001776; Wed, 26 Jun 2002 10:12:50 -0400 (EDT) Received: (from petkos@localhost) by dynasty.cs.columbia.edu (8.9.3/8.9.3) id KAA03547; Wed, 26 Jun 2002 10:12:49 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200206261412.KAA03547@dynasty.cs.columbia.edu> To: simple@mailman.dynamicsoft.com Cc: vishal@knowsys.net X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] new I-D on data requirements Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 10:12:49 -0400 (EDT) Content-Transfer-Encoding: 7bit Vishal, > section 4.3 (protocol requirements) > > 1. Support for conference invitation to multiple users .Command can be > sent to buddy list server with buddy list name .Server MUST resolve > buddy list to buddy(s) and send INVITE message (or route through > intermediate entity) > to all online users after checking their status. > > regards, vishal This was not conferencing requirements draft. Anyway, conf-reqs draft includes this mass-invitation requirement (as well as many other requirements listed also in the buddylist reqs draft). Petri _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 10:51:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21413 for ; Wed, 26 Jun 2002 10:51:22 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5QEp0N7017653; Wed, 26 Jun 2002 10:51:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09509; Wed, 26 Jun 2002 10:51:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09498 for ; Wed, 26 Jun 2002 10:50:41 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5QEoeYH022821; Wed, 26 Jun 2002 10:50:40 -0400 (EDT) Message-ID: <3D19D4C0.1080608@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vishal CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] new I-D on data requirements References: <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 10:50:40 -0400 Content-Transfer-Encoding: 7bit vishal wrote: > Dr Jonathon, > I think following requirements can also be added to this draft > section 2.2 > > 1. Server SHOULD be able to contact other servers in case buddy list > not found in local storage. Let me make sure I understand. I want to manipulate the list sip:myfriends@domain.com. So, I contact the server for example.com. It realizes that it doesn't own domain.com, so it forwards the control requests to domain.com. Is that what you want? If so, it sounds like a basic proxy function, as provided by both SIP and HTTP as well. If thats what you mean, I am OK with that. > 2. server should be able to accept requests coming directly from client > or via intermediate entity like proxy (if it includes authetication > info). Is this not the same as 1.? > 3. server should be able to route response over same route as request > i.e > support for record-route. Are you talking about the requests to manipulate the buddy list? There is no notion of session here - this is a transactional/RPC type of protocol. Record-routing makes no sense for transactional mechanisms. Thats why you can't record-route OPTIONS in SIP. If you are asking for the response to follow the same path as the request, thats part of the definition of proxying. > 4. MUST have Multicast capability at server i.e UDP support .In case > buddy > list shared by many user ,modified by one user then server SHOULD be > able > to synchronize cache of > clients. I agree with the existence of multiple clients. Thats already captured in REQ 12. However, cache synchronization (which is also a requirement) is not the same as multicast, and I would personally rather shoot myself in the head than try to develop a distributed cache synchronization protocol using multicast. Regardless, this document is about requirements, not implementation, and I believe the requirement for multiple cached copies, each of which can be manipulated, is already captured in REQ 11 and REQ 12. > 5. Server SHOULD be able to limit maximum number of users sharing buddy > list. What does it mean to "share" in this context? Share meaning "number of simultaneously cached copies?" Share meaning "number of subscriptions to the list"? > 6. Server SHOULD be able to specify maximum buddy list nesting(list > within > list) level. Since the a list within a list may not be local, there is no way for a server to even know what the depth is, since the tree is effectively distributed across the servers that own the various lists. From the perspective of a server, each list is of depth one - it contains entries that are subscribed to, period. > > section 2.2 REQ 8: A buddy list should be considered deleted when all > the > owners of buddy list have deleted it. Deleted buddy list should not be > accessible after deletion You have a different model in mind than is currently specified in the document. I think you view there as being a list that is replicated once for each "owner" that accesses the list. When an owner modifies their replicated instance, that change is copied across all other instances. However, when deleted, only their instance is deleted. The list would still continue to exist for others. I don't really see the benefit in this model, as opposed to the current model, where there is just one list. > > section 4.3 (protocol requirements) > > 1. Support for conference invitation to multiple users .Command can be > sent to buddy list server with buddy list name .Server MUST resolve > buddy list to buddy(s) and send INVITE message (or route through > intermediate entity) > to all online users after checking their status. This is outside the scope of this document. This document is about manipulating the list. As Petri has pointed out, you are asking for a mass invitation function, which is covered in his conferencing requirements document. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 10:53:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21510 for ; Wed, 26 Jun 2002 10:53:38 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5QEqwN7017702; Wed, 26 Jun 2002 10:52:58 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09534; Wed, 26 Jun 2002 10:53:04 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09521 for ; Wed, 26 Jun 2002 10:52:26 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5QEqKYH022824; Wed, 26 Jun 2002 10:52:20 -0400 (EDT) Message-ID: <3D19D523.4030005@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Petri K. Koskelainen" CC: simple@mailman.dynamicsoft.com, vishal@knowsys.net Subject: Re: [Simple] new I-D on data requirements References: <200206261412.KAA03547@dynasty.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 10:52:19 -0400 Content-Transfer-Encoding: 7bit Petri K. Koskelainen wrote: > Vishal, > > >>section 4.3 (protocol requirements) >> >>1. Support for conference invitation to multiple users .Command can be >> sent to buddy list server with buddy list name .Server MUST resolve >> buddy list to buddy(s) and send INVITE message (or route through >>intermediate entity) >> to all online users after checking their status. >> >>regards, vishal > > > This was not conferencing requirements draft. > Anyway, conf-reqs draft includes this mass-invitation > requirement (as well as many other requirements listed also > in the buddylist reqs draft). Indeed, many of the functions here are needed for conferencing as well. This was the reason for my attempt to provide a generalized model at the end. It was my hope that this generalized model would support the data manipulation for conferencing as well. Certainly, conferencing has many other requirements that are beyond the scope of data manipulation, but some aspects are certainly in scope. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 11:13:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22502 for ; Wed, 26 Jun 2002 11:13:11 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5QFCxN7017983; Wed, 26 Jun 2002 11:12:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09663; Wed, 26 Jun 2002 11:13:04 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09652 for ; Wed, 26 Jun 2002 11:12:56 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5QFDOi13083 for ; Wed, 26 Jun 2002 18:13:24 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Jun 2002 18:12:55 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 26 Jun 2002 18:12:55 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 26 Jun 2002 18:12:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message sessions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20376@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Message sessions Thread-Index: AcIXuTuQ/elXHPCLSDuf9UxUbxd0LAD0ru2AAGVPIfA= To: , , Cc: , , X-OriginalArrivalTime: 26 Jun 2002 15:12:54.0972 (UTC) FILETIME=[F285EFC0:01C21D23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA09652 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 18:12:54 +0300 Content-Transfer-Encoding: 8bit I also prefer simple-message-session for the same reasons provided by others. I do have one objection though and that of course has something to do with the hop attribute and the proxy manipulating the body. Now, Jonathan hates objections without alternate suggestion, so here is one :) We define 2 new headers, media-type and media-path. We define media-type to contain message/sip media-type: message/sip We define media-path to contain what the hop attribute contains. This works much like path-header except that it's specifying the path of the media and that it reaches the UAs. These headers are of course reflected in the response so that both UAs learn the media path. Of course, we can just define one header called sip-message-media-path (or something similar), that this limits extensibility. I haven't thought about this thoroughly, so flame me. Regards, Hisham > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Tuesday, June 25, 2002 4:22 PM > To: hgs@cs.columbia.edu; dean.willis@softarmor.com > Cc: jon.peterson@neustar.biz; simple@mailman.dynamicsoft.com; > rsparks@dynamicsoft.com > Subject: RE: [Simple] Message sessions > > > Hi, > > I would also prefer simple-message-session, mainly because of > the ability to have a unified mechanism for both the paging > mode and the session mode IM. Also, having SIP MESSAGE as the > session transport may have benefits in multiparty sessions. > > However, I don't see any reason why simple-exchange shouldn't > progress as well. Ultimately these are session IM "codecs", > and I don't think having several of them hurts as long as > there is one that by default is supported by all implementations. > > So perhaps we should have simple-message-session as a WG item > for SIMPLE, but encourage simple-exchange to progress as > well. Maybe towards Informational RFC status, if not standards track? > > Cheers, > Aki > > > > -----Original Message----- > > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Wednesday, June 19, 2002 8:41 PM > > To: Dean Willis > > Cc: Peterson, Jon; simple@mailman.dynamicsoft.com; > > rsparks@dynamicsoft.com > > Subject: Re: [Simple] Message sessions > > > > > > I would prefer simple-message-session. I don't want to have to > > administer two very different types of devices, with > > different (and, in > > the case of mrose, undefined) network management. > > > > I still agree with the argument in simple-message that a unified > > mechanism for page and session is very desirable. Transitioning and > > gatewaying will be much easier. > > > > I don't see why mrose has an advantage in "standardized relay > > elements > > to be added as needed". What can be added there that can't be > > added in > > simple-message? > > > > I'm afraid I find the "firewall discovery" item too vague to > > understand > > what exactly the advantage would be. > > > > The overall system complexity, in terms of explaining > what's going on > > and in terms of implementing, seem far less in a unified > system where > > page and session mode share conceptual elements where this > > makes sense. > > > > Dean Willis wrote: > > > Jon asked: > > > > > >>Now that the presence and watcherinfo work has gone forward to the > > > > > > IESG, we > > > > > >>need to return to the issue of message sessions - we are > quite a bit > > > > > > overdue > > > . . . > > > > > >>Two proposals have been made for session protocols: > > >> > > >>http://www.ietf.org/internet-drafts/draft-mrose-simple-excha > nge-01.txt > >> > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi > on-0 > >>0.txt > > > I personally lean towards the mrose approach. BEEP does a decent job of > the message delivery operation. It allows standardized relay elements to > be added as needed and provides for a sort of path-discovery that would > appear to be beneficial in firewall traversal scenarios. It provides a > nice layering distinctiuon between "can I talk to you" and "may I talk > to the network". > > -- > Dean > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 12:40:24 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28228 for ; Wed, 26 Jun 2002 12:40:24 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5QGe1N7018918; Wed, 26 Jun 2002 12:40:01 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10030; Wed, 26 Jun 2002 12:40:04 -0400 (EDT) Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10017 for ; Wed, 26 Jun 2002 12:39:07 -0400 (EDT) Received: from pc110 (pc110.tct.hut.fi [130.233.154.110]) by keskus.tct.hut.fi (8.10.0/8.10.0) with SMTP id g5QGd2r22355; Wed, 26 Jun 2002 19:39:02 +0300 (EET DST) From: "jose" To: "Jonathan Rosenberg" , "Petri K. Koskelainen" Cc: , Subject: RE: [Simple] new I-D on data requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D19D523.4030005@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 19:39:02 +0300 Content-Transfer-Encoding: 7bit Hi, Some comments! > > > >>section 4.3 (protocol requirements) > >> > >>1. Support for conference invitation to multiple users > .Command can be > >> sent to buddy list server with buddy list name .Server > MUST resolve > >> buddy list to buddy(s) and send INVITE message (or route through > >>intermediate entity) > >> to all online users after checking their status. > >> > >>regards, vishal > > > > > > This was not conferencing requirements draft. > > Anyway, conf-reqs draft includes this mass-invitation > > requirement (as well as many other requirements listed also > > in the buddylist reqs draft). > > Indeed, many of the functions here are needed for > conferencing as well. > This was the reason for my attempt to provide a generalized > model at the > end. It was my hope that this generalized model would support > the data > manipulation for conferencing as well. Certainly, > conferencing has many > other requirements that are beyond the scope of data > manipulation, but > some aspects are certainly in scope. Certainly, conferencing have many other requirements but probably the proposed generic model would fit just as a piece within the conferencing machinery. (probably into the membership control). Petri what do you think? BR Jose > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 14:31:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04399 for ; Wed, 26 Jun 2002 14:31:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5QITIN7019932; Wed, 26 Jun 2002 14:29:19 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10363; Wed, 26 Jun 2002 14:29:04 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10352 for ; Wed, 26 Jun 2002 14:28:24 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5QIS8YH023051; Wed, 26 Jun 2002 14:28:08 -0400 (EDT) Message-ID: <3D1A07B7.9080701@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, hgs@cs.columbia.edu, dean.willis@softarmor.com, jon.peterson@neustar.biz, simple@mailman.dynamicsoft.com, rsparks@dynamicsoft.com Subject: Re: [Simple] Message sessions References: <2038BCC78B1AD641891A0D1AE133DBB7C20376@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 14:28:07 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > We define 2 new headers, media-type and media-path. > > We define media-type to contain message/sip > > media-type: message/sip > > We define media-path to contain what the hop attribute contains. This > works much like path-header except that it's specifying the path of the > media and that it reaches the UAs. > > These headers are of course reflected in the response so that both UAs > learn the media path. > > Of course, we can just define one header called sip-message-media-path > (or something similar), that this limits extensibility. > > I haven't thought about this thoroughly, so flame me. In what way does this differ from: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jun 26 15:21:55 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06718 for ; Wed, 26 Jun 2002 15:21:55 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5QJKxN7020459; Wed, 26 Jun 2002 15:20:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10549; Wed, 26 Jun 2002 15:21:03 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10538 for ; Wed, 26 Jun 2002 15:20:36 -0400 (EDT) Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5QJKRxc026753; Wed, 26 Jun 2002 15:20:27 -0400 (EDT) Received: (from petkos@localhost) by dynasty.cs.columbia.edu (8.9.3/8.9.3) id PAA23241; Wed, 26 Jun 2002 15:20:26 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200206261920.PAA23241@dynasty.cs.columbia.edu> Subject: Re: [Simple] new I-D on data requirements To: jose@tct.hut.fi (jose) Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg), petkos@cs.columbia.edu (Petri K. Koskelainen), simple@mailman.dynamicsoft.com, vishal@knowsys.net In-Reply-To: from "jose" at Jun 26, 2002 07:39:02 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 15:20:26 -0400 (EDT) Content-Transfer-Encoding: 7bit > Certainly, conferencing have many other requirements but probably the > proposed generic model would fit just as a piece within the conferencing > machinery. > (probably into the membership control). > > Petri what do you think? > BR > Jose I guess it is too early to speculate on that. (well, it is always possible to speculate) First we have to create and agree on the requirements for all use cases (data/conference/group manipulation) and then to analyse whether general create/add/delete etc solution can be utilized for all of them. It might be useful to have one common data manipulation solution, and then a lot of extensions for specific use cases. On the other hand, it may turn out that the benefit of having one solution for a couple of create/add/delete functions is relative small if the real problems are elsewhere, and this minor issue enforces the use of same mechanism for extensions as well (e.g. XML, SOAP, ACAP, whatever mechanism). Moreover, it may require too many compromises if we have to interpret for each command that "if this is conference, then do this, if this is a buddylist then do that". Buddylist and conference semantics are very close, but still different. General solution may also restrict the specific use cases too much. For example, buddylist requirements say that it must be possible to authorize only specific users to manipulate the list. What if conferencing scenario would like to separate between delete and update operations ? (this was just an example) The danger is that the general solution always have to enable the most complex and feature-rich solution thus combining the worst of every use case. If own dedicated solution is developed for each use, it may be simpler and more effective. But as said earlier, we have to wait for the requirements. -- Petri _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 27 01:46:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23991 for ; Thu, 27 Jun 2002 01:46:42 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5R5k4N7023314; Thu, 27 Jun 2002 01:46:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12304; Thu, 27 Jun 2002 01:46:04 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12293 for ; Thu, 27 Jun 2002 01:45:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5R5l3W03525 for ; Thu, 27 Jun 2002 08:47:03 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 08:45:12 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 08:45:12 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 08:45:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message sessions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20377@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Message sessions Thread-Index: AcIdP7Inwp0yTrb0QXqkQsXEQxySUQAXcaig To: Cc: , , , , , X-OriginalArrivalTime: 27 Jun 2002 05:45:12.0110 (UTC) FILETIME=[CDE36CE0:01C21D9D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id BAA12293 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 08:45:11 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, June 26, 2002 9:28 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Niemi Aki (NET/Espoo); hgs@cs.columbia.edu; > dean.willis@softarmor.com; jon.peterson@neustar.biz; > simple@mailman.dynamicsoft.com; rsparks@dynamicsoft.com > Subject: Re: [Simple] Message sessions > > > > > hisham.khartabil@nokia.com wrote: > > We define 2 new headers, media-type and media-path. > > > > We define media-type to contain message/sip > > > > media-type: message/sip > > > > We define media-path to contain what the hop attribute > contains. This > > works much like path-header except that it's specifying the > path of the > > media and that it reaches the UAs. > > > > These headers are of course reflected in the response so > that both UAs > > learn the media path. > > > > Of course, we can just define one header called > sip-message-media-path > > (or something similar), that this limits extensibility. > > > > I haven't thought about this thoroughly, so flame me. > > In what way does this differ from: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-se > ssion-policy-00.txt Sorry, I haven't read that one yet. But I scanned it quickly and looked the examples. It is probably not that different. - Hisham > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 27 06:44:35 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10015 for ; Thu, 27 Jun 2002 06:44:34 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RAhLN7024137; Thu, 27 Jun 2002 06:43:21 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13190; Thu, 27 Jun 2002 06:43:24 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13167 for ; Thu, 27 Jun 2002 06:41:12 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09422; Thu, 27 Jun 2002 06:40:28 -0400 (EDT) Message-Id: <200206271040.GAA09422@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-rosenberg-simple-data-req-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 06:40:28 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Manipulation of Data Elements in SIMPLE Systems Author(s) : J. Rosenberg, M. Isomaki Filename : draft-rosenberg-simple-data-req-00.txt Pages : 14 Date : 26-Jun-02 In an instant messaging and presence application, it is frequently necessary for the user to configure a number of pieces of information. Users will need to manipulate their buddy list, adding and removing presentities, and manipulate their authorization lists, which specify the set of users that can subscribe to their presence. In this document, we provide a set of requirements for such data manipulations, and provide a framework for viewing them in a common way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-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-rosenberg-simple-data-req-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-rosenberg-simple-data-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020626135002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-simple-data-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-simple-data-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626135002.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 27 06:47:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10172 for ; Thu, 27 Jun 2002 06:47:35 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RAkjN7024196; Thu, 27 Jun 2002 06:46:45 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13229; Thu, 27 Jun 2002 06:46:51 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13172 for ; Thu, 27 Jun 2002 06:41:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09439; Thu, 27 Jun 2002 06:40:34 -0400 (EDT) Message-Id: <200206271040.GAA09439@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-kiss-simple-presence-wireless-reqs-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 06:40:34 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Presence Service based on 3GPP specifications and wireless environment characteristics Author(s) : K. Kiss, G. Bajko Filename : draft-kiss-simple-presence-wireless-reqs-00.txt Pages : 10 Date : 26-Jun-02 This Internet-Draft defines requirements for Presence Service based on 3GPP specifications and wireless environment characteristics. The requirements presented in this document are proposed to be evaluated by the SIMPLE Working Group. The result of this evaluation process could help to determine the work expected to be done in IETF and identify the work which might be done in other standardization bodies, such as 3GPP. Thus, a more precise work-share between standardization bodies could be worked out. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiss-simple-presence-wireless-reqs-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-kiss-simple-presence-wireless-reqs-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-kiss-simple-presence-wireless-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020626135015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kiss-simple-presence-wireless-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626135015.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 27 06:50:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10354 for ; Thu, 27 Jun 2002 06:50:26 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RAnXN7024266; Thu, 27 Jun 2002 06:49:33 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13268; Thu, 27 Jun 2002 06:49:39 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13177 for ; Thu, 27 Jun 2002 06:41:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09475; Thu, 27 Jun 2002 06:40:44 -0400 (EDT) Message-Id: <200206271040.GAA09475@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-olson-simple-publish-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 06:40:44 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIMPLE Presence Publication Mechanism Author(s) : B. Campbell Filename : draft-olson-simple-publish-00.txt Pages : 21 Date : 26-Jun-02 This document describes an extension to the Session Initiation Protocol (SIP) [1]. The purpose of this extension is to create a means for publishing event state (notably presence information) as part of the SIMPLE [4] framework for presence and instant messaging. The method described in this document allows presence information to be published to a presence agent on behalf of a user. This method can be extended to support publication of other event state, but it is not intended to be a general-purpose mechanism for transport of arbitrary data as there are better suited mechanisms for this purpose (ftp, http, etc.) This method is intended to be a simple, light- weight mechanism that employs SIP in order to support SIMPLE services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-olson-simple-publish-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-olson-simple-publish-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-olson-simple-publish-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020626135036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-olson-simple-publish-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-olson-simple-publish-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626135036.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 27 09:05:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15976 for ; Thu, 27 Jun 2002 09:05:36 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RD53N7024842; Thu, 27 Jun 2002 09:05:03 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13751; Thu, 27 Jun 2002 09:05:05 -0400 (EDT) Received: from nghmail ([63.104.239.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA13738 for ; Thu, 27 Jun 2002 09:04:32 -0400 (EDT) Received: (qmail 21885 invoked from network); 27 Jun 2002 14:02:04 -0000 Received: from unknown (HELO MC11VOIP) (61.11.57.68) by nghmail with SMTP; 27 Jun 2002 14:02:04 -0000 Message-ID: <00b501c21ddb$3cddb000$5601a8c0@knowsys.net> From: "vishal" To: "Jonathan Rosenberg" Cc: References: <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net> <3D19D4C0.1080608@dynamicsoft.com> Subject: Re: [Simple] new I-D on data requirements MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 18:33:54 +0530 Content-Transfer-Encoding: 7bit Hi, please find my comments below regards, vishal ----- Original Message ----- From: Jonathan Rosenberg To: vishal Cc: Sent: Wednesday, June 26, 2002 8:20 PM Subject: Re: [Simple] new I-D on data requirements > > > vishal wrote: > > Dr Jonathon, > > I think following requirements can also be added to this draft > > section 2.2 > > > > 1. Server SHOULD be able to contact other servers in case buddy list > > not found in local storage. > > Let me make sure I understand. I want to manipulate the list > sip:myfriends@domain.com. So, I contact the server for example.com. It > realizes that it doesn't own domain.com, so it forwards the control > requests to domain.com. Is that what you want? > > If so, it sounds like a basic proxy function, as provided by both SIP > and HTTP as well. If thats what you mean, I am OK with that. yes , I mean buddy list server(BLS) MUST be able to forward incoming requests to appropriate BLS .(As i understood BLS is separate component than proxy so BLS SHOULD also support this feature). > > > 2. server should be able to accept requests coming directly from client > > or via intermediate entity like proxy (if it includes authetication > > info). > > Is this not the same as 1.? > > > 3. server should be able to route response over same route as request > > i.e > > support for record-route. > > Are you talking about the requests to manipulate the buddy list? There > is no notion of session here - this is a transactional/RPC type of > protocol. Record-routing makes no sense for transactional mechanisms. > Thats why you can't record-route OPTIONS in SIP. If you are asking for > the response to follow the same path as the request, thats part of the > definition of proxying. > (no comment) > > > 4. MUST have Multicast capability at server i.e UDP support .In case > > buddy > > list shared by many user ,modified by one user then server SHOULD be > > able > > to synchronize cache of > > clients. > > I agree with the existence of multiple clients. Thats already captured > in REQ 12. However, cache synchronization (which is also a requirement) > is not the same as multicast, and I would personally rather shoot myself > in the head than try to develop a distributed cache synchronization > protocol using multicast. Regardless, this document is about > requirements, not implementation, and I believe the requirement for > multiple cached copies, each of which can be manipulated, is already > captured in REQ 11 and REQ 12. > > > > > 5. Server SHOULD be able to limit maximum number of users sharing buddy > > list. > > What does it mean to "share" in this context? Share meaning "number of > simultaneously cached copies?" Share meaning "number of subscriptions to > the list"? > I mean "number of subscriptions to the list ". > > > 6. Server SHOULD be able to specify maximum buddy list nesting(list > > within > > list) level. > > Since the a list within a list may not be local, there is no way for a > server to even know what the depth is, since the tree is effectively > distributed across the servers that own the various lists. From the > perspective of a server, each list is of depth one - it contains entries > that are subscribed to, period. > yes I agree... if the list is not local then this info can not be maintained but this is useful info. > > > > > section 2.2 REQ 8: A buddy list should be considered deleted when all > > the > > owners of buddy list have deleted it. Deleted buddy list should not be > > accessible after deletion > > You have a different model in mind than is currently specified in the > document. I think you view there as being a list that is replicated once > for each "owner" that accesses the list. When an owner modifies their > replicated instance, that change is copied across all other instances. > However, when deleted, only their instance is deleted. The list would > still continue to exist for others. > > I don't really see the benefit in this model, as opposed to the current > model, where there is just one list. Different instances mean ,server will track number of users sharing this list and their association with user(s).As soon as somebody deletes list ,his association will be deleted and number of instance will be decremented .No need to maintain separate copy of list.This list will not "visible" to the user who deleted .Similarly if new user wants to associate itself then just adjust number of instance and association ,no need to create list. (I apologise for discussing implementation issues here...) > > > > > > section 4.3 (protocol requirements) > > > > 1. Support for conference invitation to multiple users .Command can be > > sent to buddy list server with buddy list name .Server MUST resolve > > buddy list to buddy(s) and send INVITE message (or route through > > intermediate entity) > > to all online users after checking their status. > > This is outside the scope of this document. This document is about > manipulating the list. As Petri has pointed out, you are asking for a > mass invitation function, which is covered in his conferencing > requirements document. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 27 11:02:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22239 for ; Thu, 27 Jun 2002 11:02:38 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RF28N7025990; Thu, 27 Jun 2002 11:02:08 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14129; Thu, 27 Jun 2002 11:02:08 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14118 for ; Thu, 27 Jun 2002 11:01:37 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA14906; Thu, 27 Jun 2002 17:01:19 +0200 (MET DST) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA12142; Thu, 27 Jun 2002 17:01:32 +0200 (MET DST) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 17:01:32 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E27@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'bcampbell@dynamicsoft.com'" , "'seanol@microsoft.com'" Cc: simple@mailman.dynamicsoft.com Subject: [SIMPLE] PState (Publication-State) Header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 17:01:17 +0200 draft-olson-simple-publish-00.txt introduced the PState header. It is stated that "The response to the PUBLISH MUST contain the Publication-State header in order to provide the publisher the duration for which the publication is considered valid. The value of this may be decreased from the expiration given by the publisher in the original PUBLISH method, but SHOULD NOT be increased". I have some questions: - If the expiration value in the response is mandatory and it depends on the expiration given by the publisher, shouldn't it be mandatory for the publisher to give a value in PUBLISH ? The draft only states the "the PUBLISH may contain an expiration value". Another way is to specify in the draft a default expiration value in the absence of the Expires header in PUBLISH. - Why can't the Expires header be used instead of adding a new header PState ? - If the event state that is published through the PUBLISH method is soft-state, where would the expiration timer be running and what happens when it expires? Does the presence agent send a notification to the watchers when it happens and if yes, what should the state be changed to ? Regards, Ya-Ching _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 27 11:33:23 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24569 for ; Thu, 27 Jun 2002 11:33:23 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RFWwN7026403; Thu, 27 Jun 2002 11:32:58 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14294; Thu, 27 Jun 2002 11:33:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14283 for ; Thu, 27 Jun 2002 11:32:45 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.122]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5RFWiYH023646; Thu, 27 Jun 2002 11:32:45 -0400 (EDT) Message-ID: <3D1B301B.9020008@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson , simple@mailman.dynamicsoft.com Subject: Re: [Simple] updated buddy list package draft References: <20020625220559.90169.qmail@web11605.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 11:32:43 -0400 Content-Transfer-Encoding: 7bit Sean responded privately; forwarding my reply to the list for discussion. Sean Olson wrote: > I've only taken a very quick glance at the document. > My first impression is that we should support this > as a template package -- presence.list or something > like that. I also think thats reasonable. > I also think we should use multipart/mixed > instead of creating a new conglomerated PIDF format. > This ties into the notion of a template package > because you can subscribe to a list of entities and > get event state for those entities in multiple > (MIME) documents. Otherwise we have to invent > two flavors for every event document format: one > for a single document and one for a compound document. This is listed as one of the open issues in the doc. The only problem I had with multipart/mixed is that the conflomerated PIDF format provides some additional information. Namely, it provides the partial/full flag and a version number. The partial/full flag is used to support partial updates. Without it, if you get a NOTIFY that lists N things in the list, does that mean that there are only N things on the list (so that you should delete anything but those N), or just that only those N are being reported (so that you don't delete anything but those N)? The version number, we can live without (we can use cseq instead), but it works better than cseq. Whenever you see a gap in sequence numbers, and you have partial notifications, you need to trigger a full-state update. The spec says that this is done in the immediate NOTIFY caused by a SUBSCRIBE. Now, if we use cseq, we need to trigger full state updates on gaps in cseq. Gaps in cseq can happen because of a re-authentication of the NOTIFY at a proxy, for example. So, even though there is no gap in the document sequence, there is a gap in the cseq sequence. The result would be a needless full-state update. Not catastrophic, just wasteful. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jun 27 13:59:04 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04901 for ; Thu, 27 Jun 2002 13:59:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RHw7N7027856; Thu, 27 Jun 2002 13:58:10 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14783; Thu, 27 Jun 2002 13:58:04 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14302 for ; Thu, 27 Jun 2002 11:34:08 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 08:34:06 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Jun 2002 08:34:06 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Jun 2002 08:34:05 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 08:34:05 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Thu, 27 Jun 2002 08:34:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [SIMPLE] PState (Publication-State) Header Message-ID: Thread-Topic: [SIMPLE] PState (Publication-State) Header thread-index: AcId64p7OE4t2TAwSraDvIeq3qYDfAAA1dAA From: "Sean Olson" To: "Tan Ya-Ching ICM N PG U ID A 1" , Cc: X-OriginalArrivalTime: 27 Jun 2002 15:34:04.0997 (UTC) FILETIME=[11EE1F50:01C21DF0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA14302 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 08:34:03 -0700 Content-Transfer-Encoding: 8bit Some answers inline below. Thanks for the quick comments! /sean -----Original Message----- From: Tan Ya-Ching ICM N PG U ID A 1 [mailto:Ya-Ching.Tan@icn.siemens.de] Sent: Thursday, June 27, 2002 8:01 AM To: 'bcampbell@dynamicsoft.com'; Sean Olson Cc: simple@mailman.dynamicsoft.com Subject: [SIMPLE] PState (Publication-State) Header draft-olson-simple-publish-00.txt introduced the PState header. It is stated that "The response to the PUBLISH MUST contain the Publication-State header in order to provide the publisher the duration for which the publication is considered valid. The value of this may be decreased from the expiration given by the publisher in the original PUBLISH method, but SHOULD NOT be increased". I have some questions: - If the expiration value in the response is mandatory and it depends on the expiration given by the publisher, shouldn't it be mandatory for the publisher to give a value in PUBLISH ? The draft only states the "the PUBLISH may contain an expiration value". Another way is to specify in the draft a default expiration value in the absence of the Expires header in PUBLISH. [Sean] I don't believe it should be mandatory for the publisher. It is mandatory in the response to make it clear that this is soft-state. The publisher, however, may have no prior notion of how long the publication state is valid for -- it may even be indefinite. - Why can't the Expires header be used instead of adding a new header PState ? [Sean] The reasoning is that we should avoid using Expires: in the same manner as REGISTER. But this is a valid question and Jonathan has pointed out that Expires: would be a more appropriate header as well. I'm open to changing this in the -01 version of this draft. - If the event state that is published through the PUBLISH method is soft-state, where would the expiration timer be running and what happens when it expires? Does the presence agent send a notification to the watchers when it happens and if yes, what should the state be changed to ? [Sean] The expiration timer would be running in the presence agent in our model. When the timer expires, the state is purged, and a notification should be generated. The state would be changed to the composite state resulting from the removal of this slot (i.e. the compositor should be involved to determine the new composite state). This should be more clearly spelled out and will be included in a -01 draft. Regards, Ya-Ching _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jun 28 02:12:33 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11478 for ; Fri, 28 Jun 2002 02:12:33 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5S6C3N7001739; Fri, 28 Jun 2002 02:12:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16809; Fri, 28 Jun 2002 02:12:05 -0400 (EDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA16798 for ; Fri, 28 Jun 2002 02:11:06 -0400 (EDT) Received: from 12-235-154-217.client.attbi.com (HELO BOB) (seancolson@12.235.154.217 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Jun 2002 06:11:06 -0000 Reply-To: From: "Sean Olson" To: "'Jonathan Rosenberg'" , Subject: RE: [Simple] updated buddy list package draft Message-ID: <000301c21e6a$9c5aacb0$6601a8c0@BOB> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3D1B301B.9020008@dynamicsoft.com> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 27 Jun 2002 23:11:15 -0700 Content-Transfer-Encoding: 7bit The version information could be a compelling reason to adopt a composite PIDF format. This would be made even more compelling if there was a standard way to handle versioning information across event packages -- even if this was constrained to XML only formats. To be clear, there are several requirements I think should be considered: 1) Version information that can be used to differentiate event documents in a temporal fashion (this can be considered independently from partial vs. full state) 2) A method for differentiating full state from partial state (perhaps implicitly) 3) A means to represent a compound document that is a result of 1 or more individual event documents with a uniform and straightforward procedure for recovering the individual documents 4) A means to send a partial update with a uniform and straightforward procedure to construct the updated state based on this partial update and a previous full state /sean -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Jonathan Rosenberg Sent: Thursday, June 27, 2002 8:33 AM To: Sean Olson; simple@mailman.dynamicsoft.com Subject: Re: [Simple] updated buddy list package draft Sean responded privately; forwarding my reply to the list for discussion. Sean Olson wrote: > I've only taken a very quick glance at the document. > My first impression is that we should support this > as a template package -- presence.list or something > like that. I also think thats reasonable. > I also think we should use multipart/mixed > instead of creating a new conglomerated PIDF format. > This ties into the notion of a template package > because you can subscribe to a list of entities and > get event state for those entities in multiple > (MIME) documents. Otherwise we have to invent > two flavors for every event document format: one > for a single document and one for a compound document. This is listed as one of the open issues in the doc. The only problem I had with multipart/mixed is that the conflomerated PIDF format provides some additional information. Namely, it provides the partial/full flag and a version number. The partial/full flag is used to support partial updates. Without it, if you get a NOTIFY that lists N things in the list, does that mean that there are only N things on the list (so that you should delete anything but those N), or just that only those N are being reported (so that you don't delete anything but those N)? The version number, we can live without (we can use cseq instead), but it works better than cseq. Whenever you see a gap in sequence numbers, and you have partial notifications, you need to trigger a full-state update. The spec says that this is done in the immediate NOTIFY caused by a SUBSCRIBE. Now, if we use cseq, we need to trigger full state updates on gaps in cseq. Gaps in cseq can happen because of a re-authentication of the NOTIFY at a proxy, for example. So, even though there is no gap in the document sequence, there is a gap in the cseq sequence. The result would be a needless full-state update. Not catastrophic, just wasteful. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jun 28 06:38:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17928 for ; Fri, 28 Jun 2002 06:38:37 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5SAc1N7002518; Fri, 28 Jun 2002 06:38:01 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17593; Fri, 28 Jun 2002 06:38:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17573 for ; Fri, 28 Jun 2002 06:37:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17500; Fri, 28 Jun 2002 06:36:53 -0400 (EDT) Message-Id: <200206281036.GAA17500@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-barnes-simple-imsx-prot-eval-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 28 Jun 2002 06:36:53 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMSX Protocol Evaluation for Session Based IM Author(s) : M. Barnes Filename : draft-barnes-simple-imsx-prot-eval-00.txt Pages : 10 Date : 27-Jun-02 This document is submitted to the SIMPLE WG as part of the ongoing discussion on the selection of the protocol for support of Session Based Instant Messaging. It evaluates the suitability of the IMSX protocol as a transport for Session Based IM. IMSX defines a BEEP profile for exchanging CPIM messages after SIP has performed its session setup signaling. This document evaluates IMSX against the IMPP requirements and its ability to interoperate with other IM systems based upon the CPIM profile. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-simple-imsx-prot-eval-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-barnes-simple-imsx-prot-eval-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-barnes-simple-imsx-prot-eval-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020627133126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-barnes-simple-imsx-prot-eval-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-barnes-simple-imsx-prot-eval-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627133126.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple