From simple-admin@mailman.dynamicsoft.com Fri Feb 1 05:00: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 FAA11327 for ; Fri, 1 Feb 2002 05:00:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g119vjgZ001560 for ; Fri, 1 Feb 2002 04:57:45 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17841 for ; Fri, 1 Feb 2002 05:00:18 -0500 (EST) Date: Fri, 1 Feb 2002 05:00:18 -0500 (EST) Message-Id: <200202011000.FAA17841@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 Fri Feb 1 10:53:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27277 for ; Fri, 1 Feb 2002 10:53:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g11FoXgZ005384; Fri, 1 Feb 2002 10:50:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21689; Fri, 1 Feb 2002 10:53:02 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA21678 for ; Fri, 1 Feb 2002 10:52:45 -0500 (EST) Received: (qmail 2852 invoked by alias); 1 Feb 2002 15:52:20 -0000 Received: from unknown (HELO indigosw.com) (194.78.202.25) by 0 with SMTP; 1 Feb 2002 15:52:20 -0000 Message-ID: <3C5AB9A2.9090002@indigosw.com> From: Nicolas Dramais Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: SIMPLE list CC: "'Rosen, Brian'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , Jonathan Rosenberg , Mayerhofer Andreas A References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Mobility of Buddy List, Again 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, 01 Feb 2002 16:52:02 +0100 Content-Transfer-Encoding: 7bit Hi all, I would like to know what the status is now with mobility of buddy lists. I'm referring to the thread created on this topic in June 2001. I agree that draft-rosenberg-impp-buddylist-00.txt addresses one piece of the puzzle (even though it has expired now), being the storage and retrieval of buddy lists to and from a presence server. However, in order to have my presence server doing the dirty work of subscribing to each individual entry in my buddy list on my behalf, yet another piece is missing : some sort of composite Notify bringing back to the watcher presence statuses of all individual entries in my list residing at the server. Is there enough interest on this list to re-activate the above buddylist draft as a SIMPLE work item ? Is there enough interest on this list to define and standardize this composite Notify ? Or is there a consensus that this puzzle is more an implementation matter ? Thanks, Nicolas. -- Nicolas DRAMAIS Indigo Software "We join the dots" ~~~~~~~~~~~~~~~~~~~~~~ 50, rue Wiertz 1050 Brussels Belgium Phone: +3222350952 Fax: +3222802676 mailto:ndramais@indigosw.com ~~~~~~~~~~~~~~~~~~~~~~ http://www.indigosw.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Feb 2 22:55:09 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 WAA12439 for ; Sat, 2 Feb 2002 22:55:09 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g133pagZ012631; Sat, 2 Feb 2002 22:51:36 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28160; Sat, 2 Feb 2002 22:54:04 -0500 (EST) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28149 for ; Sat, 2 Feb 2002 22:53:35 -0500 (EST) Received: from cwc.nus.edu.sg ([172.16.3.114]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id LAA28605 for ; Sun, 3 Feb 2002 11:51:43 +0800 (SGT) Message-ID: <3C5CB5C4.5070505@cwc.nus.edu.sg> From: Nirmalya Ghosh Organization: Centre for Wireless Communications, Singapore User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] How does a Presence Server (acting as a PA) get to know of new users registrations at the proxy/registrar? 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, 03 Feb 2002 12:00:04 +0800 Content-Transfer-Encoding: 7bit Hi All, I am just wondering how would a Presence Server (PS) acting as a Presence Agent (PA) get to know of new users' registrations at the proxy/registrar? I am referring to a scenario where the PS relies on partner proxy/registrars for knowledge of new users registering with them, so that (in future) it can act as a PA on their behalf of those users. I thought of a few ways: [1] The PS has access to the registration database, which it keeps monitoring at regular intervals for looking for new users. If a new user is found, then the PS subscribes to the user (basically asking it for permission to act as its PA). [2] The proxy/registrar sends a MESSAGE to the PS, informing it of each new user registration. [3] Assuming that a user registration cud be considered an event, then perhaps the PS could have subscribed to the proxy/registrar, which would send a NOTIFY back to the PS every time a new user registered. (I am not sure of this last option). Any suggestions? Thanks & Regards, Nirmalya _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Feb 4 05:34: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 FAA18014 for ; Mon, 4 Feb 2002 05:34:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g14AUh4q000423; Mon, 4 Feb 2002 05:30:43 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00474; Mon, 4 Feb 2002 05:33:06 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA00461 for ; Mon, 4 Feb 2002 05:32:50 -0500 (EST) Received: (qmail 27541 invoked by alias); 4 Feb 2002 11:40:31 -0000 Received: from unknown (HELO indigosw.com) (194.78.202.25) by 0 with SMTP; 4 Feb 2002 11:40:31 -0000 Message-ID: <3C5E6326.2060809@indigosw.com> From: Nicolas Dramais Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: SIMPLE list CC: Torrey Searle , "'Rosen, Brian'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , Jonathan Rosenberg , Mayerhofer Andreas A Subject: Re: [Simple] Mobility of Buddy List, Again References: <3C5AB9A2.9090002@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: Mon, 04 Feb 2002 11:32:06 +0100 Content-Transfer-Encoding: 7bit All, I hadn't seen that a new draft called draft-rosenberg-simple-buddylist-package-00.txt had been created to address part of my concern below : to have my presence server, acting as a BLSS, ie. do the dirty work of subscribing to each individual entry in my buddy list on my behalf. It looks fine. This new draft also approaches the composite Notify mechanism by suggesting either multipart-body Notify or single-body Notify containing a list or lists of my buddies' presence data. I think the draft should go further and specify the preferred way of using composite Notifies for interop' concerns. However, even though I agree the transport mechanism to store, modify and retrieve buddy lists onto the server is to be performed with other protocols than SIP, SIMPLE should nevertheless cite the preferred solution for doing it; for instance HTTP or SMTP; and thus should stay in the scope of SIMPLE. This is to increase interoperability among different SIMPLE implementation vendors. As such, whatever the preferred transport method, a transport-independent buddylist xml format is necessary and should be agreed upon. Accordingly, as mentioned below, I think it would be a great idea to reactivate the standardization and agreement of such a format like attempted in draft-rosenberg-impp-buddylist-00.txt. We suggest choosing for HTTP as transport carrying xml formatted buddylist documents for storing, modifying and retrieving buddy lists to and from a presence server. Reactions welcome. Thanks, Nicolas. Nicolas Dramais wrote: > Hi all, > > I would like to know what the status is now with mobility of buddy > lists. I'm referring to the thread created on this topic in June 2001. > I agree that draft-rosenberg-impp-buddylist-00.txt addresses one piece > of the puzzle (even though it has expired now), being the storage and > retrieval of buddy lists to and from a presence server. However, in > order to have my presence server doing the dirty work of subscribing > to each individual entry in my buddy list on my behalf, yet another > piece is missing : some sort of composite Notify bringing back to the > watcher presence statuses of all individual entries in my list > residing at the server. > > Is there enough interest on this list to re-activate the above > buddylist draft as a SIMPLE work item ? > Is there enough interest on this list to define and standardize this > composite Notify ? > > Or is there a consensus that this puzzle is more an implementation > matter ? > > Thanks, > Nicolas. > -- Nicolas DRAMAIS Indigo Software "We join the dots" ~~~~~~~~~~~~~~~~~~~~~~ 50, rue Wiertz 1050 Brussels Belgium Phone: +3222350952 Fax: +3222802676 mailto:ndramais@indigosw.com ~~~~~~~~~~~~~~~~~~~~~~ http://www.indigosw.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Feb 5 17:31:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21877 for ; Tue, 5 Feb 2002 17:31:55 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g15MRl4q015320; Tue, 5 Feb 2002 17:27:48 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06936; Tue, 5 Feb 2002 17:30:07 -0500 (EST) 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 RAA06923 for ; Tue, 5 Feb 2002 17:29:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g15MTZ6Y014902; Tue, 5 Feb 2002 17:29:37 -0500 (EST) Message-ID: <3C605CA3.5723B3EA@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicolas Dramais CC: SIMPLE list , Torrey Searle , "'Rosen, Brian'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , Mayerhofer Andreas A Subject: Re: [Simple] Mobility of Buddy List, Again References: <3C5E6326.2060809@indigosw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 05 Feb 2002 17:28:51 -0500 Content-Transfer-Encoding: 7bit Nicolas Dramais wrote: > > However, even though I agree the transport mechanism to store, modify > and retrieve buddy lists onto the server is to be performed with other > protocols than SIP, SIMPLE should nevertheless cite the preferred > solution for doing it; for instance HTTP or SMTP; and thus should stay > in the scope of SIMPLE. This is to increase interoperability among > different SIMPLE implementation vendors. > As such, whatever the preferred transport method, a > transport-independent buddylist xml format is necessary and should be > agreed upon. Accordingly, as mentioned below, I think it would be a > great idea to reactivate the standardization and agreement of such a > format like attempted in draft-rosenberg-impp-buddylist-00.txt. There is a general issue here about architectures vs. protocols. IETF has traditionally not specified architectures. It has left that work to other fora, such as 3gpp, packetcable, and so on, and has tried (without as much success as they would like) to have these groups feed requiremetns back to ietf for needed extensions. The mechanisms for managing the buddy list fit into this category. It is clear that there are multiple solutions for this, and that in some cases, no standard is needed (a web page, for example, would allow a user to edit there buddy list). So, IETF could not say "this is the mechanism you use for managing a buddy list in a presence architecture". It could offer a standard for such, and other people could specify an architecture that says "use this". The question that needs to be asked, then, is how should such a standard look? We have debated this many times, without much resolution. It really is a pressing issue, since there needs to be something beyond web pages for several of these. We actually have several things which all fit into this general space: 1. management of buddy lists - adding/removing/viewing members 2. management of explicit presence state; telling the PA that I'm available, or not, or what have you. Also known as "publish". 3. management of authorization policies - telling the PA whether or not users A or B can subscribe or not. These can be simple (yea/nea) or arbitrarily complex. I would argue we should solve these all in the same way, and I think there is little dispute on that. Now, are these SIP, or something else? Well, the only way to answer that in general is to look at requirements. Steve Donovan has published some nice requirements already on this, in: http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt I happen to be of the personal opinion that SOAP works nicely for this. They are all pure client/server, all transactional data manipulation or query operations. They may involve large content (what is my buddy list?). Furthermore, I can see cases where there might even be more than one solution. Authorization, for example, is awfully complicated. Itd be nice to have a really simple yea/nea interface, but more complex ones that we can evolve over time. Since, with SOAP, one can simply define a new WIDL for these as needed, its a bit easier. The main arguments I have heard in SIPs favor are: 1. its already there in the end device, 2. its easier to tie in authentication 3. less UA configuration Regarding point (1); this is one of those "binary v. text" things which is nearly impossible to resolve, since it is not a techincal argument per se. I think many handsets have http in them already. XML will be there for PIDF. So, I don't know how big an issue it is for real. Regarding (2), if you are allowing a user to manipulate these things via a web page, you are already needing to solve the issue of tying in your authentication DB with a web application. So, I don't see the real issue per se. Regarding (3), the UA would need to be configured with the soap server to talk to. If SIP were used, presumably the PUBLISH request, or whatever it is, would go to the outbound proxy, avoiding the need to have an additional piece of configuration. This is more of a system issue, since for some architectures such configuration mechanisms likely exist (wireless handsets), and in others they dont (PCs), and there certainly is no standard way to do configuration of end devices at this time. SHould there be agreement on this direction (and I know there is not at this time), the question is whether we would specify the widl here and then submit the rfc to w3c, or if someone just goes and comes up with one and registers it. I dont think there is precedent for that at all; that might argue in favor of a SIP solution since the process is a bit more known. ANyway, I would really, really like to resolve this, since these components are needed for many architectures, and they are the hangup to a complete solution at this point. -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 Feb 5 19:08:21 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25140 for ; Tue, 5 Feb 2002 19:08:20 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1604U4q016131; Tue, 5 Feb 2002 19:04:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07255; Tue, 5 Feb 2002 19:07:03 -0500 (EST) Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA07244 for ; Tue, 5 Feb 2002 19:06:08 -0500 (EST) Message-ID: <20020206000526.76476.qmail@web11608.mail.yahoo.com> Received: from [12.237.5.37] by web11608.mail.yahoo.com via HTTP; Tue, 05 Feb 2002 16:05:26 PST From: Sean Olson Subject: Re: [Simple] Mobility of Buddy List, Again To: Jonathan Rosenberg , Nicolas Dramais Cc: SIMPLE list , Torrey Searle , "'Rosen, Brian'" , "'Sean Olson \(EUS\)'" , "'Vencour Marcel'" , Mayerhofer Andreas A In-Reply-To: <3C605CA3.5723B3EA@dynamicsoft.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: Tue, 5 Feb 2002 16:05:26 -0800 (PST) I also favor a SOAP solution for this problem space. What is the right way forward from a process point of view? Is this in the charter for SIMPLE, or can this work be safely labelled as out-of-scope? I'm not sure W3C is the right place for this work either, but it seems like a better fit than the IETF. my two cents, sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Feb 6 22:08: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 WAA09091 for ; Wed, 6 Feb 2002 22:08:05 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1733a4q024659; Wed, 6 Feb 2002 22:03:36 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12094; Wed, 6 Feb 2002 22:06:04 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12082 for ; Wed, 6 Feb 2002 22:05:13 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1732b4q024638; Wed, 6 Feb 2002 22:02:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 22:04:33 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F362FFF7@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach Reply-To: sip@ietf.org To: "'sip@ietf.org'" Cc: "'simple@mailman.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] draft-ietf-sip-events-02 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, 6 Feb 2002 22:04:30 -0500 draft-ietf-sip-events-02.txt has been submitted for publication. All known issues have been resolved, and this draft is ready for working group last call. Until it appears in the archives, you may access a copy at: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.txt Also, a PDF version of the draft, with changebars, may be retrieved from: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.pdf /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 7 03:56: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 DAA22990 for ; Thu, 7 Feb 2002 03:56:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g178p14q025578; Thu, 7 Feb 2002 03:51:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13193; Thu, 7 Feb 2002 03:53:04 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13182 for ; Thu, 7 Feb 2002 03:52:26 -0500 (EST) Received: from d23rh902.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g178kY969460 for ; Thu, 7 Feb 2002 19:46:34 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh902.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g178rhO50398 for ; Thu, 7 Feb 2002 19:53:43 +1100 To: simple@mailman.dynamicsoft.com Cc: "Hong Cai" , "Wei BJ Lu" X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 07/02/2002 16:51:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] PS = back-to-back PA + registrar? 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, 7 Feb 2002 16:51:51 +0800 Hi all, It's generally accepted that a PS is a combined PA/Proxy/Registrar. During our work we find that it's difficult for PS to change the role from proxy to PA or otherwise, when the presentity changes status from online to offline or otherwise. (In our understanding, PS acts as a proxy if the presentity is online and acts as a PA when the presentity goes offline.) Maybe a back-to-back PA + registrar is a better combination. It can hide the complexity for PS to handle the subscriptions. Assume once the presentity comes online, it registers to the PS, with or without the presence documents or CPL. PS generates a subscription to this registered presentity (not considering the third party registration) and gets presence info from the notification created by the presentity. All the presence info are stored in the backstage database and updated with the notifications. When a watcher invokes a subscription to the PS, the PS can access to this database to get current presence info of the specific presentity. It's a simple model. The PS is an end presentity to any watcher and also an end watcher for any presentity. It can low down the number of transactions exsiting in the PS. Another advantage of this model is that through this way the PS can provide flexible features to higher application level. For example, all the presence info are available from the PS. In this case, it requires the high performance of database management. It needs to update the presence info according to the notifications from presentities and it must fire an event to notify the PS to generate a notification to the watchers. Sometimes the database manager must provide merging presence info when querying. A question puzzles me in this condition. If a subscription with buddylist event package is received, the PS handles it acting as a PA, not a BLSS. Is it reasonable? What's your opinion of this model? Any comment is highly anticipated! Best regards, Tang Lihua Research Member, Infrastructure Technology IBM China Research Lab. 4/F, HaoHai Building, No.7, 5th Street, Shangdi, Beijing 100085 Phone: (8610)62986677-542 Tie line 905-542 Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Feb 11 16:09:09 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 QAA17180 for ; Mon, 11 Feb 2002 16:09:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1BL5UoN006519; Mon, 11 Feb 2002 16:05:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02344; Mon, 11 Feb 2002 16:08:04 -0500 (EST) 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 QAA02333 for ; Mon, 11 Feb 2002 16:07:37 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1BL7d6Y025573; Mon, 11 Feb 2002 16:07:39 -0500 (EST) Message-ID: <3C68326B.4D120C19@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com, Hong Cai , Wei BJ Lu Subject: Re: [Simple] PS = back-to-back PA + registrar? References: 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, 11 Feb 2002 16:06:51 -0500 Content-Transfer-Encoding: 7bit Li Hua Tang wrote: > > Hi all, > > It's generally accepted that a PS is a combined PA/Proxy/Registrar. > During > our work we find that it's difficult for PS to change the role from > proxy > to PA or otherwise, when the presentity changes status from online to > offline or otherwise. (In our understanding, PS acts as a proxy if the > presentity is online and acts as a PA when the presentity goes offline.) It should work. Can you identify specific problems? > > Maybe a back-to-back PA + registrar is a better combination. It can hide > the complexity for PS to handle the subscriptions. Assume once the > presentity comes online, it registers to the PS, with or without the > presence documents or CPL. PS generates a subscription to this > registered > presentity (not considering the third party registration) and gets > presence > info from the notification created by the presentity. All the presence > info > are stored in the backstage database and updated with the notifications. > When a watcher invokes a subscription to the PS, the PS can access to > this > database to get current presence info of the specific presentity. It's a > simple model. The PS is an end presentity to any watcher and also an end > watcher for any presentity. It can low down the number of transactions > exsiting in the PS. > Another advantage of this model is that through this way the PS can > provide > flexible features to higher application level. For example, all the > presence info are available from the PS. This is certainly a valid model. It has been discussed on the list, and is certainly allowed. The specification does not mandate implementation architectures, it merely provides tools. I don't think there is anything in the spec that would prevent this from working adequately well. Maybe just a mention encouraging user agents to support it.... > A question puzzles me in this condition. If a subscription with > buddylist > event package is received, the PS handles it acting as a PA, not a BLSS. > Is > it reasonable? A BLSS is a type of PA; its one that handles that particular event package. -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 Feb 14 02:39: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 CAA12695 for ; Thu, 14 Feb 2002 02:39:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1E7ZRoN027127; Thu, 14 Feb 2002 02:35:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12797; Thu, 14 Feb 2002 02:38:04 -0500 (EST) 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 CAA12786 for ; Thu, 14 Feb 2002 02:37:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1E7c26Y001019; Thu, 14 Feb 2002 02:38:02 -0500 (EST) Message-ID: <3C6B692B.BB78B6A7@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tang Lihua CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Somes questions about behavior of PS References: 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, 14 Feb 2002 02:37:15 -0500 Content-Transfer-Encoding: 7bit Sorry for the delay in responding... other IETF activities have kept me busy. Inline. Tang Lihua wrote: > > Hi,guys > > I want to clarify the behaviour of PS. My questions are as follows: > > About Registrar > 1. How to upload buddylist or watcherlist to PS? There is no specified or mandatory way. Certainly a web page can be used. There is some demand for a more automated way; this is a common problem for many data elements that need to be managed. There is a separate thread on that for the case of managing publication of presence documents, where SOAP has been proposed. > If a buddylist is stored in PS, should PS automaticly send > out > subscription to each buddy on the list? If the subscription is to the buddy list, yes, this is documented in: http://search.ietf.org/internet-drafts/draft-rosenberg-simple-buddylist-package-00.txt > And it's strange that in this > case > a watcher will receive notifications but no subscription is sent out by > the > watcher itself. Not really strange. See the above draft. > Also another problem is that it will burden PS with > handling all the buddylists or watcherlists. Its not mandatory to provide in a system, of course. A provider can limit this however its policy dictates. > 2. If a user gets unregistered, remove this user from database or just > mark > it as 'Unregistered'? > How can the PS know an offline presentity is a once registered user? Is > User Managerment a need? Generally, the way a PS constructs a presence document is a matter of policy, and it is a complex policy issue, involving the user, the provider, and possibly third party policies. The presence document can be based on registration status, but usually not solely based on it. Registration doesn't affect whether a user is a valid customer of the service, of course. When you say "remove this user from the DB", that makes no sense to me, since they are still a valid customer. > > About Authentication > 1. Is the authentication in PS a server-side(as proxy) or a ua-side > one(as > PA) one? A PA is a type of SIP UA, and thus uses the user-user authentication. If the PS is acting as a proxy, it would use proxy-user autehtnication. Please note that SIMPLE authentication has gotten radically better in the past month or so as a result of big improvements in overall sip security mechanisms. > If a subscription is sent to an offline presentity, should the > PS > challenge the subscriber? Generally, all subscriptions need to be authenticated. > 2. Should the PS maintain access password lists of each presentity for > each > possible watcher? Is there a better way for PS to authorize the watcher? SIP provides several ways: 1. password lists provided by the presentity, as you mention. Doesn't scale well, doesn't allow unknown subscribers. Good for some usages, though. 2. S/MIME. New for sip, and works well for presence. It assumes client certs, which is not awfully common, but OK. 3. transitivte trust. The new sips scheme works well here. So, we have solutions that run the gamut. This is a hard problem in general, as its in the area of inter-domain authentication between entities that may not know each other. > 2. Draft says, 'For pending subscriptions, the state of the presentity > SHOULD include some kind of textual note that indicates a pending > status.' > Is there any solution to it till now? Solution to what? The status is marked as "pending" or something. > More, how can the PS notify the > watcher that a buddy is offline now or a buddy gets online? A NOTIFY message. That is the point of the presence mechanism. -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 Feb 19 15:20:46 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 PAA04214 for ; Tue, 19 Feb 2002 15:20:46 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1JJR8Ql012853; Tue, 19 Feb 2002 14:27:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06293; Tue, 19 Feb 2002 14:29:48 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06282 for ; Tue, 19 Feb 2002 14:28:40 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1JJPsQl012840 for ; Tue, 19 Feb 2002 14:25:54 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Feb 2002 14:27:56 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630084@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach Reply-To: sip@ietf.org To: "'simple@mailman.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] draft-ietf-sip-events-03.txt available 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, 19 Feb 2002 14:27:55 -0500 Thanks to everyone who reviewed the SIP Events draft for WGLC. A new version of the draft taking these comments into account is now available. Until it appears in the archives, you can get a copy from: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.txt And, of course, the unofficial PDF version with changebars: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.pdf /Adam _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 21 04:25: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 EAA11723 for ; Thu, 21 Feb 2002 04:25:22 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1L9MQQl027169; Thu, 21 Feb 2002 04:22:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13081; Thu, 21 Feb 2002 04:25:07 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13068 for ; Thu, 21 Feb 2002 04:24:11 -0500 (EST) Received: from d23rh902.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g1L9II968572; Thu, 21 Feb 2002 20:18:18 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh902.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1L9OtR32064; Thu, 21 Feb 2002 20:24:56 +1100 Subject: Re: [Simple] PS = back-to-back PA + registrar? To: Jonathan Rosenberg , simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 21/02/2002 17:23:31 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, 21 Feb 2002 17:23:27 +0800 Sorry for my slow response. I just come back from vacation. Jonathan Rosenberg To: Li Hua Tang/China/IBM@IBMCN Cai/China/IBM@IBMCN, Wei BJ Lu/China/IBM@IBMCN Subject: Re: [Simple] PS = back-to-back PA + 2002-02-12 registrar? 05:06 >Li Hua Tang wrote: > > Hi all, > > It's generally accepted that a PS is a combined PA/Proxy/Registrar. > During > our work we find that it's difficult for PS to change the role from > proxy > to PA or otherwise, when the presentity changes status from online to > offline or otherwise. (In our understanding, PS acts as a proxy if the > presentity is online and acts as a PA when the presentity goes offline.) >It should work. Can you identify specific problems? Yes, you are right. It can work. According to the latest version of draft-itef-sip-events-03, we find how the PS can notify the watcher to generate a new subscription when a presentity change status from offline to online (using header "Subscription-State" and reason code). A new SUBSCRIBE request is received, so the PS can change the role from PA to proxy. That's what once troubled us. There is still a problem we are not satisfied. In normal conditions, or if the requests are always record-routing, all is ok. What we are concerned is what would PS do if the presentity crashes. PS as a proxy (which doesn't maintain transactions) can't initiate NOTIFY request to the watcher to make it know that the presentity is now not available. Only when the watcher sends out refreshing SUBSCRIBE (directly to the presentity, like re-INVITE) and gets no response (or 481 response if the presentity comes online again during this period), the watcher can know the change. So the watcher may generate a new subscription and PS can handle it again. It's a very passive way. If a Proxy+PA+Registrar model is taken, a new SUBSCRIBE request is the only trigger for PS to change role between proxy and PA. The key problem is whether, when and how the watcher sends this new subscription. > > Maybe a back-to-back PA + registrar is a better combination. It can hide > the complexity for PS to handle the subscriptions. Assume once the > presentity comes online, it registers to the PS, with or without the > presence documents or CPL. PS generates a subscription to this > registered > presentity (not considering the third party registration) and gets > presence > info from the notification created by the presentity. All the presence > info > are stored in the backstage database and updated with the notifications. > When a watcher invokes a subscription to the PS, the PS can access to > this > database to get current presence info of the specific presentity. It's a > simple model. The PS is an end presentity to any watcher and also an end > watcher for any presentity. It can low down the number of transactions > exsiting in the PS. > Another advantage of this model is that through this way the PS can > provide > flexible features to higher application level. For example, all the > presence info are available from the PS. >This is certainly a valid model. It has been discussed on the list, and >is certainly allowed. The specification does not mandate implementation >architectures, it merely provides tools. I don't think there is anything >in the spec that would prevent this from working adequately well. Maybe >just a mention encouraging user agents to support it.... > A question puzzles me in this condition. If a subscription with > buddylist > event package is received, the PS handles it acting as a PA, not a BLSS. > Is > it reasonable? >A BLSS is a type of PA; its one that handles that particular event >package. -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 Feb 21 13:17: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 NAA27594 for ; Thu, 21 Feb 2002 13:17:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1LIDJQl001196; Thu, 21 Feb 2002 13:13:19 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14742; Thu, 21 Feb 2002 13:16:02 -0500 (EST) 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 NAA14731 for ; Thu, 21 Feb 2002 13:15:39 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA58926 for ; Thu, 21 Feb 2002 19:14:54 +0100 Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1LIGXm31300 for ; Thu, 21 Feb 2002 19:16:33 +0100 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.8 |June 18, 2001) at 21/02/2002 19:14:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] Handling unregistration of a Presentity in a presence server 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, 21 Feb 2002 19:15:06 +0100 Dear all, I'm a Student doing his Diploma Thesis at IBM and I'm writing a presence server for handling NOTIFY and SUBSCRIBE requests. The presentity updates its presence info via a REGISTER method to the presence Server with a description param. For the moment the presence server does not act as a registrar. We do not need it. It only generates notifications of changes to watchers on behalf of a presentity . We do not use Proxys. I have three questions: 1) I think that only one Contact header should be present in the REGISTER request with the desired description param. Is it OK? Otherwise can you tell me what is the benefit of having multiple Contact headers. 2) suppose a presentity does not refresh its Registration to the server and timeout occurs. What should the Presence Server send to the unregistered presentity's watchers ? Do we NOTIFY watchers for example with an "offline" or whatever convenient state or it is not worth sending a NOTIFY and in this case send a 404 (NOT FOUND) or possibly a NOTIFY with Subscription-Expires=0;reason ="presentity does not exist" when receiving SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity. 3)As a consequence, What is the difference when we receive a SUBSCRIBE to a presentity that has unregistered (do we need to keep trace that it has been registered one time before ?) and a SUBSCRIBE to a presentity the presence server never heard about. Does the presence server have to send a 404 (NOT FOUND) for both? Regards, Lamine. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 21 21:06:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09254 for ; Thu, 21 Feb 2002 21:06:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1M23LQl005068; Thu, 21 Feb 2002 21:03:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16153; Thu, 21 Feb 2002 21:06:03 -0500 (EST) 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 VAA16140 for ; Thu, 21 Feb 2002 21:05:19 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1M24o619663; Thu, 21 Feb 2002 21:04:50 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAF61126; Thu, 21 Feb 2002 21:07:42 -0500 (EST) Message-ID: <3C75A5B5.ABD570ED@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: Lamine Brahimi CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Handling unregistration of a Presentity in a presence server References: 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, 21 Feb 2002 20:58:13 -0500 Content-Transfer-Encoding: 7bit I'm not the expert, but I will offer an opinion. See below. Paul Lamine Brahimi wrote: > > Dear all, > > I'm a Student doing his Diploma Thesis at IBM and I'm writing a presence > server for handling NOTIFY and SUBSCRIBE requests. Glad to hear that IBM is sponsoring such useful work. > The presentity updates its presence info via a REGISTER method to the > presence Server with a description param. > For the moment the presence server does not act as a registrar. We do not > need it. It only generates notifications of changes to watchers on behalf > of a presentity . Using REGISTER but not acting as a registrar seems to be cheating. You can presumably get away with it for testing, but it would seem unwise to ship something like that. I think either you should integrate your presence server with your registrar, or else you should update your presence info some other way. > We do not use Proxys. Really? I suppose this is why you don't need a registrar! So are your clients required to use SUBSCRIBE to learn where to send? How do they know where to send the SUBSCRIBE? Normally I would expect that would find the presence server via a proxy. If this is really true, then you could claim that your presence server really is a registrar, but there just aren't any proxies around to use the results. (A bogus argument but impossible to disprove.) > > I have three questions: > > 1) I think that only one Contact header should be present in the REGISTER > request with the desired description param. Is it OK? Otherwise can you > tell me what is the benefit of having multiple Contact headers. The benefit is when you have multiple points at which your address of record may be reached. E.g. an office phone, home phone, cell phone. Using REGISTER, it might be unusual for these to be registered in the same REGISTER message, but it is legal. More likely for this example would be for each to send separate REGISTER messages. In that case you are expected to aggregate them when reporting presence. It is also permissible to register different kinds of URLs - e.g. a sip address and a mailto address. Of course the mailto address might not be of much use to your presence clients. > > 2) suppose a presentity does not refresh its Registration to the server and > timeout occurs. What should the Presence Server send to the unregistered > presentity's watchers ? > Do we NOTIFY watchers for example with an "offline" or whatever > convenient state or it is not worth sending a NOTIFY and in this case send > a 404 (NOT FOUND) or possibly a NOTIFY with Subscription-Expires=0;reason > ="presentity does not exist" when receiving > SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity. I believe you are expected to send a NOTIFY to subscribers when the registration expires. You might be able to avoid this by controlling the expiration time of the subscriptions so that they never extend beyond the expiration of the registration, but that doesn't sound like a good idea. > > 3)As a consequence, What is the difference when we receive a SUBSCRIBE to > a presentity that has unregistered (do we need to keep trace that it has > been registered one time before ?) and a SUBSCRIBE to a presentity the > presence server never heard about. Does the presence server have to send a > 404 (NOT FOUND) for both? You shouldn't have to retain state about expired registrations. There shouldn't be any difference to the subscriber for the two cases. > > Regards, > Lamine. > > _______________________________________________ > 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 Feb 22 05:13: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 FAA25984 for ; Fri, 22 Feb 2002 05:13:28 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1MA9NQl006324; Fri, 22 Feb 2002 05:09:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17602; Fri, 22 Feb 2002 05:12:05 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA17590 for ; Fri, 22 Feb 2002 05:11:15 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 22 Feb 2002 10:10:45 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Handling unregistration of a Presentity in a presence server Message-ID: <45730E094814E44488F789C1CDED27AEC552B7@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Simple] Handling unregistration of a Presentity in a presence server Thread-Index: AcG7Rdu25aZWykHXT9ChDWQodxrwRQAQXJlQ From: "James Undery" To: "Paul Kyzivat" , "Lamine Brahimi" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA17590 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, 22 Feb 2002 10:12:51 -0000 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Lamine Brahimi wrote: > > The presentity updates its presence info via a REGISTER > method to the > > presence Server with a description param. > > For the moment the presence server does not act as a > registrar. We do not > > need it. It only generates notifications of changes to > watchers on behalf > > of a presentity . > > Using REGISTER but not acting as a registrar seems to be cheating. > You can presumably get away with it for testing, but it would seem > unwise to ship something like that. > > I think either you should integrate your presence server with your > registrar, or else you should update your presence info some > other way. I'd like to interject that using registration info for presence isn't a good idea, the draft http://search.ietf.org/internet-drafts/draft-donovan-publish-requirement s-01.txt provides the requirements of a better mechanism. > > I have three questions: > > > > 1) I think that only one Contact header should be present > in the REGISTER > > request with the desired description param. Is it OK? > Otherwise can you > > tell me what is the benefit of having multiple Contact headers. What you're doing is a bad idea description params are far more likely to change than registrations. > > > > 2) suppose a presentity does not refresh its Registration > to the server and > > timeout occurs. What should the Presence Server send to the > unregistered > > presentity's watchers ? > > Do we NOTIFY watchers for example with an "offline" or whatever > > convenient state or it is not worth sending a NOTIFY and in > this case send > > a 404 (NOT FOUND) or possibly a NOTIFY with > Subscription-Expires=0;reason > > ="presentity does not exist" when receiving > > SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity. > > I believe you are expected to send a NOTIFY to subscribers when > the registration expires. You might be able to avoid this by > controlling the expiration time of the subscriptions so that they > never extend beyond the expiration of the registration, but that > doesn't sound like a good idea. The subscriptions and the registrations are totally unrelated, sending a NOTIFY with offline status seems the most sensible. (You can't send a 404 to a subscriber inplace of a NOTIFY and I'd contend your confusion arises from you're abuse of registration.) > > > > 3)As a consequence, What is the difference when we receive > a SUBSCRIBE to > > a presentity that has unregistered (do we need to keep > trace that it has > > been registered one time before ?) and a SUBSCRIBE to a > presentity the > > presence server never heard about. Does the presence server > have to send a > > 404 (NOT FOUND) for both? > > You shouldn't have to retain state about expired registrations. > There shouldn't be any difference to the subscriber for the two cases. Have I mentioned using registrations was a bad idea. James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Feb 22 08:58:54 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02093 for ; Fri, 22 Feb 2002 08:58:54 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1MDqKQl007188; Fri, 22 Feb 2002 08:52:20 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18294; Fri, 22 Feb 2002 08:55:04 -0500 (EST) 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 IAA18281 for ; Fri, 22 Feb 2002 08:54:53 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1MDsP716418; Fri, 22 Feb 2002 08:54:25 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAF62372; Fri, 22 Feb 2002 08:57:17 -0500 (EST) Message-ID: <3C764C02.AF2FF2CC@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: James Undery CC: Lamine Brahimi , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Handling unregistration of a Presentity in a presence server References: <45730E094814E44488F789C1CDED27AEC552B7@GBNEWP0758M.eu.ubiquity.net> 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, 22 Feb 2002 08:47:46 -0500 Content-Transfer-Encoding: 7bit Comments below. Paul James Undery wrote: > > I'd like to interject that using registration info for presence isn't a > good idea, the draft > http://search.ietf.org/internet-drafts/draft-donovan-publish-requirement > s-01.txt provides the requirements of a better mechanism. I partially disagree. If I use registration to add, remove, or change contact information, that ought to affect a presence server. It just doesn't make any sense for a presence server to be advertising that I am present when in fact I am unreachable. Also, the callerprefs draft introduces options on the Contacts in registrations that clearly ought to be interrelated with presence. Of course you can place the burden on the UA to update both in a consistent way, but that is simply asking for trouble. And it isn't consistent with the semantics of registration, where independent UAs can register with the same address of record and be merged automatically. The discussions of merging presence documents went nowhere, so if you want to permit that, using registration to update presence is better defined. That said, if you want to maintain a consistent registration, but want to update nuances of your presence within the the envelope of that registration, then some other mechanism might be appropriate. Another observation - for somebody building something now, a draft of *requirements* for publishing a presence document isn't very useful. > What you're doing is a bad idea description params are far more likely > to change than registrations. Well, by definition the description param is part of the registration, so it can't be more likely to change than the registration. But I suppose your point is that the description of presence state is more likely to change than is the contact address, so that if all you want to change is presence state it might be better to use some mechanism other than Contact parameters to represent it. But that assumes that you don't need to change registration data at the same time. For example, suppose you want to change your presence state when you are in a call, and suppose your registration initially contains: Contact: ;q=1 Contact: ;q=.5 If all you want to do is say you are busy in a call, just updating a presence document makes sense. But if you want to remain available for urgent calls but not others, then (using callerprefs) you would need to update your registration with: Contact: ;q=1;priority=urgent Contact: ;q=.5 and then at the end of the call you would need to restore your registration to the original value. Updating only a presence document wouldn't have the same effect, because it wouldn't affect calls that ignore presence. This just highlights the point that callerprefs and presence haven't been aligned. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Feb 22 09:23:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03204 for ; Fri, 22 Feb 2002 09:23:53 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1MEKGQl007523; Fri, 22 Feb 2002 09:20:16 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18404; Fri, 22 Feb 2002 09:23:02 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA18393 for ; Fri, 22 Feb 2002 09:22:52 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 22 Feb 2002 14:22:23 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Handling unregistration of a Presentity in a presence server Message-ID: <45730E094814E44488F789C1CDED27AEC552B8@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Simple] Handling unregistration of a Presentity in a presence server Thread-Index: AcG7qL7nWl3sWD3WSvuGgLAcK9kmMgAADIKw From: "James Undery" To: "Paul Kyzivat" Cc: "Lamine Brahimi" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA18393 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, 22 Feb 2002 14:24:30 -0000 Content-Transfer-Encoding: 8bit Comments inline > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > James Undery wrote: > > > > I'd like to interject that using registration info for > presence isn't a > > good idea, the draft > > > http://search.ietf.org/internet-drafts/draft-donovan-publish-r > equirement > > s-01.txt provides the requirements of a better mechanism. > > I partially disagree. > > If I use registration to add, remove, or change contact information, > that ought to affect a presence server. It just doesn't make any sense > for a presence server to be advertising that I am present > when in fact I > am unreachable. Also, the callerprefs draft introduces options on the > Contacts in registrations that clearly ought to be interrelated with > presence. Yes, if all you provide is online/offline info only, registration is tolerable, however, once you've introduced presence descriptions such as busy/on the phone/in a meeting then registration is totally inappropriate. Presence is more dynamic in nature than registration. > Of course you can place the burden on the UA to update both in a > consistent way, but that is simply asking for trouble. And it isn't > consistent with the semantics of registration, where > independent UAs can > register with the same address of record and be merged automatically. > The discussions of merging presence documents went nowhere, so if you > want to permit that, using registration to update presence is better > defined. I'd definately place the burden on the PA, which is exactly where it is today in services like MSN (bad example I know), Yahoo, ICQ etc. The semantics of registration aren't well defined if a location service returns multiple contacts it's local policy that decided how a proxy will try to contact them (or even redirect to them). > That said, if you want to maintain a consistent registration, but want > to update nuances of your presence within the the envelope of that > registration, then some other mechanism might be appropriate. > > Another observation - for somebody building something now, a draft of > *requirements* for publishing a presence document isn't very useful. Well perhaps looking closer at the requirements and experimenting would be a better project ;-) > > What you're doing is a bad idea description params are far > more likely > > to change than registrations. > > Well, by definition the description param is part of the registration, > so it can't be more likely to change than the registration. > > But I suppose your point is that the description of presence state is > more likely to change than is the contact address, so that if all you > want to change is presence state it might be better to use some > mechanism other than Contact parameters to represent it. > > But that assumes that you don't need to change registration > data at the > same time. > > For example, suppose you want to change your presence state > when you are > in a call, and suppose your registration initially contains: > > Contact: ;q=1 > Contact: ;q=.5 > > If all you want to do is say you are busy in a call, just updating a > presence document makes sense. But if you want to remain available for > urgent calls but not others, then (using callerprefs) you > would need to > update your registration with: > > Contact: ;q=1;priority=urgent > Contact: ;q=.5 > > and then at the end of the call you would need to restore your > registration to the original value. Updating only a presence document > wouldn't have the same effect, because it wouldn't affect calls that > ignore presence. This is exactly why this is a really bad idea. And the reason for using 480 or 486 responses. Just because you can get the same effect in SIP from multiple mechanisms doesn't mean they are all equally good. > This just highlights the point that callerprefs and presence haven't > been aligned. Well callerprefs are hints and presence is about hints so I guess the two are related, unfortunately for the original poster this whole area is pretty much undefined. James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Feb 22 11:46:44 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 LAA09952 for ; Fri, 22 Feb 2002 11:46:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1MGhIQl009176; Fri, 22 Feb 2002 11:43:18 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18847; Fri, 22 Feb 2002 11:46:02 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18835 for ; Fri, 22 Feb 2002 11:45:14 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA130470 for ; Fri, 22 Feb 2002 17:44:29 +0100 Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1MGkHR49792 for ; Fri, 22 Feb 2002 17:46:17 +0100 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.8 |June 18, 2001) at 22/02/2002 17:44:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] Response to Unsubscription 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, 22 Feb 2002 17:44:21 +0100 Dear all, What response: NOTIFY, 200 OK or both do we have to send when receiving an unsubscription ? It is not clear in the latest draft Thanks, Lamine. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Feb 22 12:58:46 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 MAA13865 for ; Fri, 22 Feb 2002 12:58:46 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1MHtIQl010008; Fri, 22 Feb 2002 12:55:18 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19113; Fri, 22 Feb 2002 12:58:03 -0500 (EST) 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 MAA19101 for ; Fri, 22 Feb 2002 12:57:06 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1MHuaM05601; Fri, 22 Feb 2002 12:56:36 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAF64830; Fri, 22 Feb 2002 12:59:26 -0500 (EST) Message-ID: <3C7684C2.658739CA@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: Lamine Brahimi CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Response to Unsubscription References: 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, 22 Feb 2002 12:49:54 -0500 Content-Transfer-Encoding: 7bit I thought it was clear. There is no special UNSUBSCRIBE - it is simply a variant of SUBSCRIBE, so the responses must be consistent with that. Like any request, it must receive a response, so you must send a 200 OK. Then, because it is a SUBSCRIBE, you must also send a NOTIFY. Then the subscription is gone, so you are done. Paul Lamine Brahimi wrote: > > Dear all, > > What response: NOTIFY, 200 OK or both do we have to send when receiving an > unsubscription ? > It is not clear in the latest draft > Thanks, > Lamine. > > _______________________________________________ > 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 Feb 22 13:08: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 NAA14351 for ; Fri, 22 Feb 2002 13:08:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1MI5GQl010174; Fri, 22 Feb 2002 13:05:17 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19173; Fri, 22 Feb 2002 13:08:03 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19161 for ; Fri, 22 Feb 2002 13:07:29 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A8AF8DEA0134; Fri, 22 Feb 2002 13:06:39 -0500 Message-ID: <002901c1bbca$c0cc7fe0$2300000a@acmepacket.com> From: "Bob Penfield" To: , "Lamine Brahimi" References: Subject: Re: [Simple] Response to Unsubscription MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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, 22 Feb 2002 13:00:03 -0500 Content-Transfer-Encoding: 7bit draft-ietf-sip-events-03.txt section 4.1.4.3 states: Unsubscribing is handled in the same way as refreshing of a subscription, with the "Expires" header set to "0". Note that a successful unsubscription will also trigger a final NOTIFY message. The notifier sends a 200 OK (successful) response to the SUBSCRIBE and sends the final NOTIFY. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Lamine Brahimi" To: Sent: Friday, February 22, 2002 11:44 AM Subject: [Simple] Response to Unsubscription > Dear all, > > What response: NOTIFY, 200 OK or both do we have to send when receiving an > unsubscription ? > It is not clear in the latest draft > Thanks, > Lamine. > > > _______________________________________________ > 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 Sun Feb 24 12:23: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 MAA13724 for ; Sun, 24 Feb 2002 12:23:05 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1OHELQl016888; Sun, 24 Feb 2002 12:14:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27574; Sun, 24 Feb 2002 12:17:04 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27563 for ; Sun, 24 Feb 2002 12:16:21 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA117290 for ; Sun, 24 Feb 2002 18:15:35 +0100 Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1OHG0P08506 for ; Sun, 24 Feb 2002 18:16:00 +0100 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.8 |June 18, 2001) at 24/02/2002 18:14:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] Howt to deal with Notifications when having multiple PUAs for a presentity 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, 24 Feb 2002 18:14:15 +0100 Dear all, Thanks for previous advices. I have a specific question: I allow my presentity to have several PUAs thus several presence-Info (one per PUA identified by a Contact-address in the Contact-Header in the REGISTER msg etc ...). It is the presence server (colocated with the registrar) that aggregates all presence-Info of a presentity and NOTIFY the watchers. What should the presence server do if a presentity PUA (identified by a contact-address) is not updated and thus expires ???? Can we consider that as an update of presence Info? Should I notify all the watchers with all the the remaining PUAs presence-Info only? Should I notify all the watchers with all the PUAs and a status "NOT FOUND" (see rfc 2778) for the one which has expired? Should I do nothing and wait for a "true" presence-Info change to notify watchers ? Or, in order to avoid that, can we consider a REGISTER-refresh to update ALL the presentity Contact-addresses (even they are not all present in ther Contact header) and symetrically the same thing for an unregistration? It does not follow exactly the spec but it avoids a lot of complexity? Thanks for the help/ Regards, Lamine. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Feb 24 15:06:44 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 PAA15576 for ; Sun, 24 Feb 2002 15:06:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1OK3GQl017212; Sun, 24 Feb 2002 15:03:16 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28099; Sun, 24 Feb 2002 15:06:03 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28085; Sun, 24 Feb 2002 15:05:43 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id VAA137518; Sun, 24 Feb 2002 21:04:58 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1OK5NP90484; Sun, 24 Feb 2002 21:05:23 +0100 To: "Lamine Brahimi" Cc: simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com MIME-Version: 1.0 Subject: Re: [Simple] Howt to deal with Notifications when having multiple PUAs for a presentity X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/02/2002 22:05:32, Serialize complete at 24/02/2002 22:05:32 Content-Type: multipart/alternative; boundary="=_alternative 006E31F642256B6A_=" 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, 24 Feb 2002 22:05:26 +0200 This is a multipart message in MIME format. --=_alternative 006E31F642256B6A_= Content-Type: text/plain; charset="us-ascii" I would say that if the registration of a PUA expires you should consider it as an update to the presence info. Think of the case where each PUA is representing a mobile device and one of the mobile devices was shut down. Avshalom Houri Lotus Sametime, IBM Software Group avshalom@il.ibm.com Lamine Brahimi/Zurich/IBM@IBMCH Sent by: simple-admin@mailman.dynamicsoft.com 24/02/2002 19:14 To: simple@mailman.dynamicsoft.com cc: Subject: [Simple] Howt to deal with Notifications when having multiple PUAs for a presentity Dear all, Thanks for previous advices. I have a specific question: I allow my presentity to have several PUAs thus several presence-Info (one per PUA identified by a Contact-address in the Contact-Header in the REGISTER msg etc ...). It is the presence server (colocated with the registrar) that aggregates all presence-Info of a presentity and NOTIFY the watchers. What should the presence server do if a presentity PUA (identified by a contact-address) is not updated and thus expires ???? Can we consider that as an update of presence Info? Should I notify all the watchers with all the the remaining PUAs presence-Info only? Should I notify all the watchers with all the PUAs and a status "NOT FOUND" (see rfc 2778) for the one which has expired? Should I do nothing and wait for a "true" presence-Info change to notify watchers ? Or, in order to avoid that, can we consider a REGISTER-refresh to update ALL the presentity Contact-addresses (even they are not all present in ther Contact header) and symetrically the same thing for an unregistration? It does not follow exactly the spec but it avoids a lot of complexity? Thanks for the help/ Regards, Lamine. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple --=_alternative 006E31F642256B6A_= Content-Type: text/html; charset="us-ascii"
I would say that if the registration of a PUA expires you should consider it as an update to the presence info.
Think of the case where each PUA is representing a mobile device and one of the mobile devices was shut down.

Avshalom Houri
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com


Lamine Brahimi/Zurich/IBM@IBMCH
Sent by: simple-admin@mailman.dynamicsoft.com

24/02/2002 19:14

       
        To:        simple@mailman.dynamicsoft.com
        cc:        
        Subject:        [Simple] Howt to deal with Notifications when having multiple PUAs for a presentity

       


Dear all,
Thanks for previous advices.
I have a specific question:

I allow my presentity to have several PUAs thus several presence-Info (one
per PUA identified by a Contact-address in the Contact-Header  in the
REGISTER msg etc ...).
It is the presence server (colocated with the registrar)  that aggregates
all presence-Info of a presentity and NOTIFY the watchers.
What should the presence server do if a presentity PUA (identified by a
contact-address) is not updated and thus expires ????
Can we consider that as an update of presence Info?
Should I notify all the watchers with all the the remaining PUAs
presence-Info only?
Should I notify all the watchers with all the PUAs and a status "NOT FOUND"
(see rfc 2778) for the one which has expired?
Should I do nothing and wait for a "true" presence-Info change to notify
watchers ?

Or, in order to avoid that, can we consider a REGISTER-refresh to update
ALL the presentity Contact-addresses (even they are not all
present in ther Contact header) and symetrically  the same thing for an
unregistration?
It does not follow exactly the spec but it avoids a lot of complexity?

Thanks for the help/
Regards,
Lamine.


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

--=_alternative 006E31F642256B6A_=-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Feb 24 21:59:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20113 for ; Sun, 24 Feb 2002 21:58:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1P2tIQl018093; Sun, 24 Feb 2002 21:55:19 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29432; Sun, 24 Feb 2002 21:58:04 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29420 for ; Sun, 24 Feb 2002 21:57:23 -0500 (EST) Received: from d23rh901.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g1P2qMN46498 for ; Mon, 25 Feb 2002 13:52:22 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1P2vKi109544 for ; Mon, 25 Feb 2002 13:57:20 +1100 Subject: Re: [Simple] Handling unregistration of a Presentity in a presence server To: "Lamine Brahimi" , simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 25/02/2002 10:56:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 25 Feb 2002 10:56:35 +0800 Please see my comments below. Best regards, Tang Lihua Research Member, IBM China Research Lab. Email: tanglih@cn.ibm.com Paul Kyzivat To: Lamine Brahimi/Zurich/IBM@IBMCH Sent by: cc: simple@mailman.dynamicsoft.com simple-admin@mailman.dynam Subject: Re: [Simple] Handling unregistration of icsoft.com a Presentity in a presence server 2002-02-22 09:58 I'm not the expert, but I will offer an opinion. See below. Paul Lamine Brahimi wrote: > > Dear all, > > I'm a Student doing his Diploma Thesis at IBM and I'm writing a presence > server for handling NOTIFY and SUBSCRIBE requests. >Glad to hear that IBM is sponsoring such useful work. > The presentity updates its presence info via a REGISTER method to the > presence Server with a description param. > For the moment the presence server does not act as a registrar. We do not > need it. It only generates notifications of changes to watchers on behalf > of a presentity . >Using REGISTER but not acting as a registrar seems to be cheating. >You can presumably get away with it for testing, but it would seem >unwise to ship something like that. I quite agree this. Registrar is an important components of PS. >I think either you should integrate your presence server with your >registrar, or else you should update your presence info some other way. >> We do not use Proxys. >Really? I suppose this is why you don't need a registrar! >So are your clients required to use SUBSCRIBE to learn where to send? >How do they know where to send the SUBSCRIBE? Normally I would >expect that would find the presence server via a proxy. >If this is really true, then you could claim that your presence >server really is a registrar, but there just aren't any proxies >around to use the results. >(A bogus argument but impossible to disprove.) > > I have three questions: > > 1) I think that only one Contact header should be present in the REGISTER > request with the desired description param. Is it OK? Otherwise can you > tell me what is the benefit of having multiple Contact headers. >The benefit is when you have multiple points at which your address >of record may be reached. E.g. an office phone, home phone, cell phone. >Using REGISTER, it might be unusual for these to be registered >in the same REGISTER message, but it is legal. More likely for this >example would be for each to send separate REGISTER messages. >In that case you are expected to aggregate them when reporting >presence. >It is also permissible to register different kinds of URLs - e.g. >a sip address and a mailto address. Of course the mailto address >might not be of much use to your presence clients. > > 2) suppose a presentity does not refresh its Registration to the server and > timeout occurs. What should the Presence Server send to the unregistered > presentity's watchers ? > Do we NOTIFY watchers for example with an "offline" or whatever > convenient state or it is not worth sending a NOTIFY and in this case send > a 404 (NOT FOUND) or possibly a NOTIFY with Subscription-Expires=0;reason > ="presentity does not exist" when receiving > SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity. Brahimi, I guess you still use an old version of sip-events draft. In the latest one http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.txt, the header "Subscription-Expires" has been changed to "Subscription-State" and the reason code is totally different. And I think you'd better use the defined reason code to describe the status. >I believe you are expected to send a NOTIFY to subscribers when >the registration expires. You might be able to avoid this by >controlling the expiration time of the subscriptions so that they >never extend beyond the expiration of the registration, but that >doesn't sound like a good idea. > > 3)As a consequence, What is the difference when we receive a SUBSCRIBE to > a presentity that has unregistered (do we need to keep trace that it has > been registered one time before ?) and a SUBSCRIBE to a presentity the > presence server never heard about. Does the presence server have to send a > 404 (NOT FOUND) for both? It's different. You know REGISTER and SUBSCRIBE requests are quite different. A valid user is the one who can access to Presence Sevice. Even if this valid user has unregistered, the PS must handle the subscription to it. So if a SUBSCRIBE request is received to a invalid presentity (the PS never hears about), 404 Not Found can be sent back. If the SUBSCRIBE request is to a valid presentity but now it's not available, the PS must handle it and send back NOTIFY acting as a PA. This NOTIFY requst has such a header "Subscription-State: terminated;reason=deactivated", or "Subscription-State: terminated;reason=probation;retry-after=100". It's your preference to choose an impementation way. >You shouldn't have to retain state about expired registrations. >There shouldn't be any difference to the subscriber for the two cases. > > Regards, > Lamine. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Feb 25 05:44: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 FAA04114 for ; Mon, 25 Feb 2002 05:44:42 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1PAfHZq000463; Mon, 25 Feb 2002 05:41:17 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00511; Mon, 25 Feb 2002 05:44:03 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00499 for ; Mon, 25 Feb 2002 05:43:02 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA152460 for ; Mon, 25 Feb 2002 11:42:14 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1PAi4J48588 for ; Mon, 25 Feb 2002 11:44:05 +0100 To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/02/2002 12:44:05, Serialize complete at 25/02/2002 12:44:05 Content-Type: multipart/alternative; boundary="=_alternative 0039878342256B6B_=" Subject: [Simple] Session of MESSAGES 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, 25 Feb 2002 12:30:16 +0200 This is a multipart message in MIME format. --=_alternative 0039878342256B6B_= Content-Type: text/plain; charset="us-ascii" From the minutes of the SIMPLE meeting in the last IETF: draft-rosenberg-simple-im-transport: * Weakly expressed support. Moderately strong hum against proceeding with this proposal. - concerns over keeping IMTP and SIP syncronized * Alternate proposal solicited - if none appears before early January, work will proceed with IMTP * Split opinions on whether a proposal must be held to mankin-im-session-guide Until today there was not much discussion in the group regarding this issue. There was one submission of an alternative suggestion: draft-mrose-simple-exchange-01.txt (IMSX). This suggestion had had very minimal discussion in the list. I think that we should start discussing the following: * Should a proposal must be held to mankin-im-session-guide * The different alternatives on the table Thanks Avshalom Houri Lotus Sametime, IBM Software Group avshalom@il.ibm.com --=_alternative 0039878342256B6B_= Content-Type: text/html; charset="us-ascii"
From the minutes of the SIMPLE meeting in the last IETF:

draft-rosenberg-simple-im-transport:

* Weakly expressed support. Moderately strong hum against
 proceeding with this proposal.
 - concerns over keeping IMTP and SIP syncronized
 
* Alternate proposal solicited - if none appears before
 early January, work will proceed with IMTP

* Split opinions on whether a proposal must be held to
 mankin-im-session-guide

Until today there was not much discussion in the group regarding this issue. There was one submission of an alternative suggestion:
draft-mrose-simple-exchange-01.txt (IMSX). This suggestion had had very minimal discussion in the list.

I think that we should start discussing the following:
* Should a proposal must be held to mankin-im-session-guide
* The different alternatives on the table

Thanks
Avshalom Houri
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com
 --=_alternative 0039878342256B6B_=-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Feb 25 09:51: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 JAA12471 for ; Mon, 25 Feb 2002 09:51:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1PEmGZq001715; Mon, 25 Feb 2002 09:48:16 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01264; Mon, 25 Feb 2002 09:51:02 -0500 (EST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01253 for ; Mon, 25 Feb 2002 09:50:18 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA166158 for ; Mon, 25 Feb 2002 15:49:30 +0100 Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1PEpMJ78828 for ; Mon, 25 Feb 2002 15:51:22 +0100 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.8 |June 18, 2001) at 25/02/2002 15:49:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] On SIP-Specific event Notification new Draft Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 25 Feb 2002 15:49:26 +0100 Dear all, Thanks for reporting me the new draft for SIP-Specific event Notification. If an initial SUBSCRIBE request is not sent on a pre-existing dialog, the subscriber will wait for a response to the SUBSCRIBE request or a matching NOTIFY. Responses are matched to such SUBSCRIBE requests if they contain the same the same "Call-ID", the same "From" header field, the same "To" header field, excluding the "tag", and the same "CSeq". Rules for the comparison of these headers are described in SIP [1]. If a 200-class response matches such a SUBSCRIBE request, it creates a new subscription and a new dialog (unless they have already been created by a matching NOTIFY request; see below). ........ So far, so good .... However, If an initial SUBSCRIBE is sent on a pre-existing dialog, a matching 200-class response or successful NOTIFY request merely creates a new subscription associated with that dialog. Multiple subscriptions can be associated with a single dialog. How an initial SUBSCRIBE can be sent on a pre-existing dialog otherwise than sending to the same presentity several times the SAME SUSBCRIBE ? As a consequence what is the benefit of having multiple Subscriptions in the same dialog ??? Thanks, Lamine. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Feb 25 11:36:43 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 LAA16973 for ; Mon, 25 Feb 2002 11:36:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1PGXKZq002979; Mon, 25 Feb 2002 11:33:20 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01605; Mon, 25 Feb 2002 11:36:02 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA00368 for ; Mon, 25 Feb 2002 05:04:34 -0500 (EST) Received: (qmail 14635 invoked by alias); 25 Feb 2002 10:03:49 -0000 Received: from unknown (HELO indigosw.com) (194.78.202.25) by 0 with SMTP; 25 Feb 2002 10:03:49 -0000 Message-ID: <3C7A0C4E.8070000@indigosw.com> From: Torrey Searle Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020206 X-Accept-Language: en-us MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Expires: 0 in a SUBSCRIBE 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, 25 Feb 2002 11:05:02 +0100 Content-Transfer-Encoding: 7bit Should Expires: 0 be treated as a special case? Generally unscubscription is treated by the draft as a regular subscription update. However, it seems that in the current draft, treating Unscription as regular re-subscription can cause a problem of "423 Interval too brief" to be generated. I think that an Expiration time of 0 should be given special meaning and explicitly be exempt from the subscription length checks. Torrey Searle Indigo Software tsearle@indigosw.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Feb 25 14:17:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25675 for ; Mon, 25 Feb 2002 14:16:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1PJCgZq004657; Mon, 25 Feb 2002 14:12:44 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02137; Mon, 25 Feb 2002 14:15:12 -0500 (EST) 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 OAA02124 for ; Mon, 25 Feb 2002 14:14:37 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.234]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1PJEb6Y016920; Mon, 25 Feb 2002 14:14:40 -0500 (EST) Message-ID: <3C7A8CE9.70D795E8@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Torrey Searle CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Expires: 0 in a SUBSCRIBE References: <3C7A0C4E.8070000@indigosw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 25 Feb 2002 14:13:45 -0500 Content-Transfer-Encoding: 7bit Torrey Searle wrote: > > Should Expires: 0 be treated as a special case? Generally > unscubscription is treated by the draft as a regular subscription > update. However, it seems that in the current draft, treating > Unscription as regular re-subscription can cause a problem of "423 > Interval too brief" to be generated. It shouldn't. This is clear in bis, at least: The registrar MAY shorten the expiration interval. If and only if the expiration interval is greater than 1722 zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY 1723 reject the registration with a response of 423 (Registration Too Brief). 1724 sip-events seems to have lost this detail when the 423 text was integrated into the document. That needs to be fixed. -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 Feb 26 04:16:44 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 EAA21271 for ; Tue, 26 Feb 2002 04:16:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1Q9DLZq008687; Tue, 26 Feb 2002 04:13:21 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04783; Tue, 26 Feb 2002 04:16:05 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04768 for ; Tue, 26 Feb 2002 04:14:57 -0500 (EST) Received: from d23rh901.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g1Q991N300688 for ; Tue, 26 Feb 2002 20:09:01 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1Q9Dun43062 for ; Tue, 26 Feb 2002 20:13:56 +1100 To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 26/02/2002 17:13:16 MIME-Version: 1.0 Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id EAA04768 Subject: [Simple] Handling Expires:0 are different in two drafts, why? 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, 26 Feb 2002 17:13:13 +0800 Content-Transfer-Encoding: 8bit Hi all, I am puzzled by how to handle a SUBSCRIBE request with an "Expires" of 0. In the draft draft-ietf-sip-events-03 it's said, Note that the NOTIFY messages triggered by SUBSCRIBE messages with ¡°Expires¡± headers of 0 will contain a ¡°Subscription-State¡± value of ¡°terminated¡±,and a ¡°reason¡± parameter of ¡°timeout¡±. In this condition, the subscription is terminated and reason=timeout may cause a new subscription. But considering a SUBSCRIBE request for Event:presence.winfo, it's said in the draft draft-rosenberg-impp-watcherinfo-00, notifications triggered as a result of a fetch operation (a SUBSCRIBE with Expires of 0) SHOULD result in the full state of all watchers (of course, only those watchers that have been authorized to be divulged to the subscriber) to be present in the NOTIFY. In this condition, what would the value of ¡°Subscription-State¡± be? I think the subscription is still active here. What do you think about these two cases? Best regards, Tang Lihua Research Member, Infrastructure Technology IBM China Research Lab. Phone: (8610)62986677-542 Tie line: 905-542 Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Feb 26 17: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 RAA23834 for ; Tue, 26 Feb 2002 17:42:28 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1QMURZq015235; Tue, 26 Feb 2002 17:30:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07195; Tue, 26 Feb 2002 17:33:07 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07183 for ; Tue, 26 Feb 2002 17:32:42 -0500 (EST) Received: from maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g1QMVqZ19471 for ; Tue, 26 Feb 2002 17:31:53 -0500 (EST) Received: from att.com (tony-ob.mt.att.com[135.91.110.214]) by maillennium.att.com (mailgw1) with SMTP id <20020226223151gw100k1vfae> (Authid: tony); Tue, 26 Feb 2002 22:31:51 +0000 Message-ID: <3C7C0CCC.D6EBC1BC@att.com> From: Tony Hansen X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SIMPLE list References: <20020206000526.76476.qmail@web11608.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again) 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, 26 Feb 2002 17:31:40 -0500 Content-Transfer-Encoding: 7bit Here are some ideas on how this could play out within the IETF. One of the documents being put out in the SIP WG is SIP Call Flow Examples. It shows how the SIP protocol should be used in an IP Telephony service. Another effort in the IETF is the Voice Profile for Internet Messaging (VPIM) working group. That group has been figuring out how to do voice messaging (for voice mailboxes) using existing protocols, such as SMTP and IMAP. Where the existing protocols were lacking, they also worked on filling in the gaps, either within the VPIM WG or in conjunction with other working groups (e.g., imap-ext). Note: the VPIM WG was originally formed due to input from an external organization, the EMA, but the work has all been done here in the IETF. The problem we're facing here in SIMPLE seems to be in the same category, and the solution may be similar. It appears that what is required is a profile for an instant messaging service saying how it should pull together the different piece parts to form a coherent whole. I'm convinced we can solve this problem. Getting feedback from the industry is absolutely useful in the process, but I think the work needs to happen here, in the IETF. And I'm willing to work on it. Comments? Should something like this go on the SIMPLE agenda for Minneapolis? Tony Hansen tony@att.com Sean Olson wrote: > > I also favor a SOAP solution for this problem space. > What is the right way forward from a process point > of view? Is this in the charter for SIMPLE, or > can this work be safely labelled as out-of-scope? > I'm not sure W3C is the right place for this work > either, but it seems like a better fit than the > IETF. Jonathan Rosenberg wrote: > > Nicolas Dramais wrote: > > > > However, even though I agree the transport mechanism to store, modify > > and retrieve buddy lists onto the server is to be performed with other > > protocols than SIP, SIMPLE should nevertheless cite the preferred > > solution for doing it; for instance HTTP or SMTP; and thus should stay > > in the scope of SIMPLE. This is to increase interoperability among > > different SIMPLE implementation vendors. > > As such, whatever the preferred transport method, a > > transport-independent buddylist xml format is necessary and should be > > agreed upon. Accordingly, as mentioned below, I think it would be a > > great idea to reactivate the standardization and agreement of such a > > format like attempted in draft-rosenberg-impp-buddylist-00.txt. > > There is a general issue here about architectures vs. protocols. IETF > has traditionally not specified architectures. It has left that work to > other fora, such as 3gpp, packetcable, and so on, and has tried (without > as much success as they would like) to have these groups feed > requiremetns back to ietf for needed extensions. > > The mechanisms for managing the buddy list fit into this category. It is > clear that there are multiple solutions for this, and that in some > cases, no standard is needed (a web page, for example, would allow a > user to edit there buddy list). > > So, IETF could not say "this is the mechanism you use for managing a > buddy list in a presence architecture". It could offer a standard for > such, and other people could specify an architecture that says "use > this". The question that needs to be asked, then, is how should such a > standard look? > > We have debated this many times, without much resolution. It really is a > pressing issue, since there needs to be something beyond web pages for > several of these. We actually have several things which all fit into > this general space: > > 1. management of buddy lists - adding/removing/viewing members > 2. management of explicit presence state; telling the PA that I'm > available, or not, or what have you. Also known as "publish". > 3. management of authorization policies - telling the PA whether or not > users A or B can subscribe or not. These can be simple (yea/nea) or > arbitrarily complex. > > I would argue we should solve these all in the same way, and I think > there is little dispute on that. Now, are these SIP, or something else? > Well, the only way to answer that in general is to look at requirements. > Steve Donovan has published some nice requirements already on this, in: > > http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt > > I happen to be of the personal opinion that SOAP works nicely for this. > They are all pure client/server, all transactional data manipulation or > query operations. They may involve large content (what is my buddy > list?). Furthermore, I can see cases where there might even be more than > one solution. Authorization, for example, is awfully complicated. Itd be > nice to have a really simple yea/nea interface, but more complex ones > that we can evolve over time. Since, with SOAP, one can simply define a > new WIDL for these as needed, its a bit easier. > > The main arguments I have heard in SIPs favor are: > > 1. its already there in the end device, > 2. its easier to tie in authentication > 3. less UA configuration > > Regarding point (1); this is one of those "binary v. text" things which > is nearly impossible to resolve, since it is not a techincal argument > per se. I think many handsets have http in them already. XML will be > there for PIDF. So, I don't know how big an issue it is for real. > Regarding (2), if you are allowing a user to manipulate these things via > a web page, you are already needing to solve the issue of tying in your > authentication DB with a web application. So, I don't see the real issue > per se. Regarding (3), the UA would need to be configured with the soap > server to talk to. If SIP were used, presumably the PUBLISH request, or > whatever it is, would go to the outbound proxy, avoiding the need to > have an additional piece of configuration. This is more of a system > issue, since for some architectures such configuration mechanisms likely > exist (wireless handsets), and in others they dont (PCs), and there > certainly is no standard way to do configuration of end devices at this > time. > > SHould there be agreement on this direction (and I know there is not at > this time), the question is whether we would specify the widl here and > then submit the rfc to w3c, or if someone just goes and comes up with > one and registers it. I dont think there is precedent for that at all; > that might argue in favor of a SIP solution since the process is a bit > more known. > > ANyway, I would really, really like to resolve this, since these > components are needed for many architectures, and they are the hangup to > a complete solution at this point. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Feb 27 05:44: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 FAA15915 for ; Wed, 27 Feb 2002 05:44:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RAecZq017879; Wed, 27 Feb 2002 05:40:38 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09404; Wed, 27 Feb 2002 05:42:04 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA09393 for ; Wed, 27 Feb 2002 05:41:25 -0500 (EST) Received: (qmail 18489 invoked by alias); 27 Feb 2002 10:40:38 -0000 Received: from unknown (HELO indigosw.com) (194.78.202.25) by 0 with SMTP; 27 Feb 2002 10:40:38 -0000 Message-ID: <3C7CB7A4.9010908@indigosw.com> From: Nicolas Dramais Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Hansen CC: SIMPLE list Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again) References: <20020206000526.76476.qmail@web11608.mail.yahoo.com> <3C7C0CCC.D6EBC1BC@att.com> Content-Type: multipart/alternative; boundary="------------040108000904090405090007" 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, 27 Feb 2002 11:40:36 +0100 --------------040108000904090405090007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Tony, please see my comments below. Nicolas. Tony Hansen wrote: >Here are some ideas on how this could play out within the IETF. > >One of the documents being put out in the SIP WG is SIP Call Flow >Examples. It shows how the SIP protocol should be used in an IP >Telephony service. > Indeed, why not do the same kind of "informational" Call Flow Examples document for showing how SIMPLE should be used in deploying a SIP for Presence service (showing the use of SOAP transported by SIP or HTTP for buddy list mobility and list management, presence state and authorization management) ? > > >Another effort in the IETF is the Voice Profile for Internet Messaging >(VPIM) working group. That group has been figuring out how to do voice >messaging (for voice mailboxes) using existing protocols, such as SMTP >and IMAP. Where the existing protocols were lacking, they also worked on >filling in the gaps, either within the VPIM WG or in conjunction with >other working groups (e.g., imap-ext). Note: the VPIM WG was originally >formed due to input from an external organization, the EMA, but the work >has all been done here in the IETF. > >The problem we're facing here in SIMPLE seems to be in the same >category, and the solution may be similar. It appears that what is >required is a profile for an instant messaging service saying how it >should pull together the different piece parts to form a coherent whole. > Well, I guess like many other people on this list, we believe that SIP for Presence can be applied to a much broader scope of applications than just for an IM service. Hence, we want to separate very much Presence from IM. So I' d rather name it Presence service instead of IM service. > > >I'm convinced we can solve this problem. Getting feedback from the >industry is absolutely useful in the process, but I think the work needs >to happen here, in the IETF. And I'm willing to work on it. > As mentioned below, we too want to insure a minimum of Presence service interoperability among different SIMPLE implementation vendors; especially for mobility of buddy lists and for the management issues Jonathan pointed out below. We are also willing to contribute to it, being on the IETF list or the W3C. Regards, Nicolas. > > >Comments? Should something like this go on the SIMPLE agenda for >Minneapolis? > > Tony Hansen > tony@att.com > >Sean Olson wrote: > >>I also favor a SOAP solution for this problem space. >>What is the right way forward from a process point >>of view? Is this in the charter for SIMPLE, or >>can this work be safely labelled as out-of-scope? >>I'm not sure W3C is the right place for this work >>either, but it seems like a better fit than the >>IETF. >> > >Jonathan Rosenberg wrote: > >>Nicolas Dramais wrote: >> >>>However, even though I agree the transport mechanism to store, modify >>>and retrieve buddy lists onto the server is to be performed with other >>>protocols than SIP, SIMPLE should nevertheless cite the preferred >>>solution for doing it; for instance HTTP or SMTP; and thus should stay >>>in the scope of SIMPLE. This is to increase interoperability among >>>different SIMPLE implementation vendors. >>>As such, whatever the preferred transport method, a >>>transport-independent buddylist xml format is necessary and should be >>>agreed upon. Accordingly, as mentioned below, I think it would be a >>>great idea to reactivate the standardization and agreement of such a >>>format like attempted in draft-rosenberg-impp-buddylist-00.txt. >>> >>There is a general issue here about architectures vs. protocols. IETF >>has traditionally not specified architectures. It has left that work to >>other fora, such as 3gpp, packetcable, and so on, and has tried (without >>as much success as they would like) to have these groups feed >>requiremetns back to ietf for needed extensions. >> >>The mechanisms for managing the buddy list fit into this category. It is >>clear that there are multiple solutions for this, and that in some >>cases, no standard is needed (a web page, for example, would allow a >>user to edit there buddy list). >> >>So, IETF could not say "this is the mechanism you use for managing a >>buddy list in a presence architecture". It could offer a standard for >>such, and other people could specify an architecture that says "use >>this". The question that needs to be asked, then, is how should such a >>standard look? >> >>We have debated this many times, without much re >>solution. It really is a >>pressing issue, since there needs to be something beyond web pages for >>several of these. We actually have several things which all fit into >>this general space: >> >>1. management of buddy lists - adding/removing/viewing members >>2. management of explicit presence state; telling the PA that I'm >>available, or not, or what have you. Also known as "publish". >>3. management of authorization policies - telling the PA whether or not >>users A or B can subscribe or not. These can be simple (yea/nea) or >>arbitrarily complex. >> >>I would argue we should solve these all in the same way, and I think >>there is little dispute on that. Now, are these SIP, or something else? >>Well, the only way to answer that in general is to look at requirements. >>Steve Donovan has published some nice requirements already on this, in: >> >>http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt >> >>I happen to be of the personal opinion that SOAP works nicely for this. >>They are all pure client/server, all transactional data manipulation or >>query operations. They may involve large content (what is my buddy >>list?). Furthermore, I can see cases where there might even be more than >>one solution. Authorization, for example, is awfully complicated. Itd be >>nice to have a really simple yea/nea interface, but more complex ones >>that we can evolve over time. Since, with SOAP, one can simply define a >>new WIDL for these as needed, its a bit easier. >> >>The main arguments I have heard in SIPs favor are: >> >>1. its already there in the end device, >>2. its easier to tie in authentication >>3. less UA configuration >> >>Regarding point (1); this is one of those "binary v. text" things which >>is nearly impossible to resolve, since it is not a techincal argu >>ment >>per se. I think many handsets have http in them already. XML will be >>there for PIDF. So, I don't know how big an issue it is for real. >>Regarding (2), if you are allowing a user to manipulate these things via >>a web page, you are already needing to solve the issue of tying in your >>authentication DB with a web application. So, I don't see the real issue >>per se. Regarding (3), the UA would need to be configured with the soap >>server to talk to. If SIP were used, presumably the PUBLISH request, or >>whatever it is, would go to the outbound proxy, avoiding the need to >>have an additional piece of configuration. This is more of a system >>issue, since for some architectures such configuration mechanisms likely >>exist (wireless handsets), and in others they dont (PCs), and there >>certainly is no standard way to do configuration of end devices at this >>time. >> >>SHould there be agreement on this direction (and I know there is not at >>this time), >> the question is whether we would specify the widl here and >>then submit the rfc to w3c, or if someone just goes and comes up with >>one and registers it. I dont think there is precedent for that at all; >>that might argue in favor of a SIP solution since the process is a bit >>more known. >> >>ANyway, I would really, really like to resolve this, since these >>components are needed for many architectures, and they are the hangup to >>a complete solution at this point. >> >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > -- Nicolas DRAMAIS Indigo Software ~~~~~~~~~~~~~~~~~~~~~~ 50, rue Wiertz 1050 Brussels Belgium Phone: +3222350952 Fax: +3222802676 mailto:ndramais@indigosw.com ~~~~~~~~~~~~~~~~~~~~~~ http://www.indigosw.com --------------040108000904090405090007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi Tony,

please see my comments below.

Nicolas.

Tony Hansen wrote:
Here are some ideas on how this could play out within the IETF.

One of the documents being put out in the SIP WG is SIP Call Flow
Examples. It shows how the SIP protocol should be used in an IP
Telephony service.
Indeed, why not do the same kind of "informational" Call Flow Examples document for showing how SIMPLE should be used in deploying a SIP for Presence service (showing the use of SOAP transported by SIP or HTTP for buddy list mobility and list management, presence state and authorization management) ?


Another effort in the IETF is the Voice Profile for Internet Messaging
(VPIM) working group. That group has been figuring out how to do voice
messaging (for voice mailboxes) using existing protocols, such as SMTP
and IMAP. Where the existing protocols were lacking, they also worked on
filling in the gaps, either within the VPIM WG or in conjunction with
other working groups (e.g., imap-ext). Note: the VPIM WG was originally
formed due to input from an external organization, the EMA, but the work
has all been done here in the IETF.

The problem we're facing here in SIMPLE seems to be in the same
category, and the solution may be similar. It appears that what is
required is a profile for an instant messaging service saying how it
should pull together the different piece parts to form a coherent whole.
Well, I guess like many other people on this list, we believe that SIP for Presence can be applied to a much broader scope of applications than just for an IM service.
Hence, we want to separate very much Presence from IM.
So I' d rather name it Presence service instead of IM service.


I'm convinced we can solve this problem. Getting feedback from the
industry is absolutely useful in the process, but I think the work needs
to happen here, in the IETF. And I'm willing to work on it.
As mentioned below, we too want to insure a minimum of Presence service interoperability among different SIMPLE implementation vendors; especially for mobility of buddy lists and for the management issues Jonathan pointed out below.
We are also willing to contribute to it, being on the IETF list or the W3C.

Regards,
Nicolas. 


Comments? Should something like this go on the SIMPLE agenda for
Minneapolis?

	Tony Hansen
	tony@att.com

Sean Olson wrote:
I also favor a SOAP solution for this problem space.
What is the right way forward from a process point
of view? Is this in the charter for SIMPLE, or
can this work be safely labelled as out-of-scope?
I'm not sure W3C is the right place for this work
either, but it seems like a better fit than the
IETF.

Jonathan Rosenberg wrote:
Nicolas Dramais wrote:
However, even though I agree the transport mechanism to store, modify
and retrieve buddy lists onto the server is to be performed with other
protocols than SIP, SIMPLE should  nevertheless cite the preferred
solution for doing it; for instance HTTP or SMTP; and thus should stay
in the scope of SIMPLE. This is to increase interoperability among
different SIMPLE implementation vendors.
As such, whatever the preferred transport method, a
transport-independent buddylist xml format is necessary and should be
agreed upon. Accordingly, as mentioned below, I think it would be a
great idea to reactivate the standardization and agreement of such a
format like attempted in draft-rosenberg-impp-buddylist-00.txt.
There is a general issue here about architectures vs. protocols. IETF
has traditionally not specified architectures. It has left that work to
other fora, such as 3gpp, packetcable, and so on, and has tried (without
as much success as they would like) to have these groups feed
requiremetns back to ietf for needed extensions.

The mechanisms for managing the buddy list fit into this category. It is
clear that there are multiple solutions for this, and that in some
cases, no standard is needed (a web page, for example, would allow a
user to edit there buddy list).

So, IETF could not say "this is the mechanism you use for managing a
buddy list in a presence architecture". It could offer a standard for
such, and other people could specify an architecture that says "use
this". The question that needs to be asked, then, is how should such a
standard look?

We have debated this many times, without much re

solution. It really is a
pressing issue, since there needs to be something beyond web pages for
several of these. We actually have several things which all fit into
this general space:

1. management of buddy lists - adding/removing/viewing members
2. management of explicit presence state; telling the PA that I'm
available, or not, or what have you. Also known as "publish".
3. management of authorization policies - telling the PA whether or not
users A or B can subscribe or not. These can be simple (yea/nea) or
arbitrarily complex.

I would argue we should solve these all in the same way, and I think
there is little dispute on that. Now, are these SIP, or something else?
Well, the only way to answer that in general is to look at requirements.
Steve Donovan has published some nice requirements already on this, in:

http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt

I happen to be of the personal opinion that SOAP works nicely for this.
They are all pure client/server, all transactional data manipulation or
query operations. They may involve large content (what is my buddy
list?). Furthermore, I can see cases where there might even be more than
one solution. Authorization, for example, is awfully complicated. Itd be
nice to have a really simple yea/nea interface, but more complex ones
that we can evolve over time. Since, with SOAP, one can simply define a
new WIDL for these as needed, its a bit easier.

The main arguments I have heard in SIPs favor are:

1. its already there in the end device,
2. its easier to tie in authentication
3. less UA configuration

Regarding point (1); this is one of those "binary v. text" things which
is nearly impossible to resolve, since it is not a techinc
al argu
ment
per se. I think many handsets have http in them already. XML will be
there for PIDF. So, I don't know how big an issue it is for real.
Regarding (2), if you are allowing a user to manipulate these things via
a web page, you are already needing to solve the issue of tying in your
authentication DB with a web application. So, I don't see the real issue
per se. Regarding (3), the UA would need to be configured with the soap
server to talk to. If SIP were used, presumably the PUBLISH request, or
whatever it is, would go to the outbound proxy, avoiding the need to
have an additional piece of configuration. This is more of a system
issue, since for some architectures such configuration mechanisms likely
exist (wireless handsets), and in others they dont (PCs), and there
certainly is no standard way to do configuration of end devices at this
time.

SHould there be agreement on this direction (and I know there is not at
thi
s time),
 the question is whether we would specify the widl here and
then submit the rfc to w3c, or if someone just goes and comes up with
one and registers it. I dont think there is precedent for that at all;
that might argue in favor of a SIP solution since the process is a bit
more known.

ANyway, I would really, really like to resolve this, since these
components are needed for many architectures, and they are the hangup to
a complete solution at this point.
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple



-- 
Nicolas DRAMAIS
Indigo Software
~~~~~~~~~~~~~~~~~~~~~~
50, rue Wiertz
1050 Brussels
Belgium
Phone: +3222350952
Fax: +3222802676
mailto:ndramais@indigosw.com
~~~~~~~~~~~~~~~~~~~~~~
http://www.indigosw.com


--------------040108000904090405090007-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Feb 27 10:07:09 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 KAA26152 for ; Wed, 27 Feb 2002 10:07:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RF1cZq019230; Wed, 27 Feb 2002 10:01:39 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10223; Wed, 27 Feb 2002 10:03:03 -0500 (EST) 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 HAA09739 for ; Wed, 27 Feb 2002 07:27:50 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18728; Wed, 27 Feb 2002 07:26:59 -0500 (EST) Message-Id: <200202271226.HAA18728@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-ietf-simple-cpim-mapping-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: Wed, 27 Feb 2002 07:26:58 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : CPIM Mapping of SIMPLE Presence and Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-simple-cpim-mapping-00.txt Pages : 12 Date : 26-Feb-02 The SIMPLE work group has defined a SIP events package for distribution of presence information. It has also proposed a MESSAGE extension for the transport of instant messages. This document describes how those mechanisms map to the abstract CPIM service, in order to interoperate with other CPIM compliant presence and instant messaging services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cpim-mapping-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-ietf-simple-cpim-mapping-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-cpim-mapping-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: <20020226131227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cpim-mapping-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cpim-mapping-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226131227.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 Wed Feb 27 13:11: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 NAA07482 for ; Wed, 27 Feb 2002 13:11:54 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RI7mZq021395; Wed, 27 Feb 2002 13:07:48 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10839; Wed, 27 Feb 2002 13:09:05 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10828 for ; Wed, 27 Feb 2002 13:08:36 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RI5iZq021368; Wed, 27 Feb 2002 13:05:44 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 13:07:50 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300B2@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach Reply-To: sip@ietf.org To: "'sip@ietf.org'" Cc: "'simple@mailman.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] New Version: draft-ietf-sip-events-04 complete 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, 27 Feb 2002 13:07:46 -0500 FYI: a new version of the SIP Events draft is available. Until it appears in the archives, a copy is available from the locations listed below. WGLC has already concluded; this announcement is for information purposes only. I am not soliciting comments from the working group at this time. Official version: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.txt Unofficial PDF version w/changebars: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.pdf Changes from -03 are nominal, and are documented at: http://pages.sbcglobal.net/roaches/ietf/event-changes.html /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Feb 27 16:18:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18927 for ; Wed, 27 Feb 2002 16:18:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RLCcZq023259; Wed, 27 Feb 2002 16:12:38 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11460; Wed, 27 Feb 2002 16:14:03 -0500 (EST) 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 QAA11439 for ; Wed, 27 Feb 2002 16:13:26 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1RLDS6Y019245; Wed, 27 Feb 2002 16:13:28 -0500 (EST) Message-ID: <3C7D227E.3E8288A6@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Handling Expires:0 are different in two drafts, why? References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Feb 2002 13:16:30 -0500 Content-Transfer-Encoding: 8bit Li Hua Tang wrote: > > Hi all, > > I am puzzled by how to handle a SUBSCRIBE request with an "Expires" of > 0. There is no special casing. Its a SUBSCRIBE that just happens to expire real soon. > > In the draft draft-ietf-sip-events-03 it's said, > Note that the NOTIFY messages triggered by SUBSCRIBE messages with > ¡°Expires¡± headers of 0 will contain a ¡°Subscription-State¡± value > of ¡°terminated¡±,and a ¡°reason¡± parameter of ¡°timeout¡±. > In this condition, the subscription is terminated and reason=timeout may > cause > a new subscription. > > But considering a SUBSCRIBE request for Event:presence.winfo, it's said > in > the > draft draft-rosenberg-impp-watcherinfo-00, > notifications triggered as a result of a fetch operation (a > SUBSCRIBE with Expires of 0) SHOULD result in the full state of all > watchers (of course, only those watchers that have been authorized > to > be divulged to the subscriber) to be present in the NOTIFY. > In this condition, what would the value of ¡°Subscription-State¡± be? I > think > the subscription is still active here. A fetch does not create a subscription; at least, not one that lives for more than an infinitesimal period of time. Effectively, the fetch creates an instantaneously expiring subscription, causing a NOTIFY to be sent. That NOTIFY has the current state, along with the Subscription-State header, with a value terminated and reason of timeout. Thus, the two statements above are not contradictory. -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 Feb 27 16:18: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 QAA18977 for ; Wed, 27 Feb 2002 16:18:36 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RLEsZq023352; Wed, 27 Feb 2002 16:14:54 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11484; Wed, 27 Feb 2002 16:16:25 -0500 (EST) 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 QAA11444 for ; Wed, 27 Feb 2002 16:13:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1RLDX6Y019248; Wed, 27 Feb 2002 16:13:33 -0500 (EST) Message-ID: <3C7D243D.84C492B4@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Avshalom Houri CC: Lamine Brahimi , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Howt to deal with Notifications when having multiplePUAs for a presentity References: 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, 27 Feb 2002 13:23:57 -0500 Content-Transfer-Encoding: 7bit Avshalom Houri wrote: > > I would say that if the registration of a PUA expires you should > consider it as an update to the presence info. > Think of the case where each PUA is representing a mobile device and one > of the mobile devices was shut down. Correct. Some more details inline. Lamine writes: > > Dear all, > Thanks for previous advices. > I have a specific question: > > I allow my presentity to have several PUAs thus several presence-Info > (one > per PUA identified by a Contact-address in the Contact-Header in the > REGISTER msg etc ...). > It is the presence server (colocated with the registrar) that > aggregates > all presence-Info of a presentity and NOTIFY the watchers. > What should the presence server do if a presentity PUA (identified by a > contact-address) is not updated and thus expires ???? > Can we consider that as an update of presence Info? Definitely. The role of the PA is to take the sources of presence it knows about, and generate a total presence document for the presentity based on those sources. That includes, but by no means is limited to, registrations. > Should I notify all the watchers with all the the remaining PUAs > presence-Info only? That probably makes the most sense. > Should I notify all the watchers with all the PUAs and a status "NOT > FOUND" > (see rfc 2778) for the one which has expired? Probably the updated presence document would omit the contact address for the PUA whose registration has expired. > Should I do nothing and wait for a "true" presence-Info change to notify > watchers ? > > Or, in order to avoid that, can we consider a REGISTER-refresh to update > ALL the presentity Contact-addresses (even they are not all > present in ther Contact header) No, because thats not what the REGISTER means. THe spec doesn't prevent this, but the presence document you generate would not be accurate. -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 Feb 27 16: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 QAA19231 for ; Wed, 27 Feb 2002 16:22:30 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RLGRZq023429; Wed, 27 Feb 2002 16:16:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11507; Wed, 27 Feb 2002 16:17:58 -0500 (EST) 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 QAA11449 for ; Wed, 27 Feb 2002 16:13:35 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1RLDb6Y019251; Wed, 27 Feb 2002 16:13:38 -0500 (EST) Message-ID: <3C7D2986.74356922@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] PS = back-to-back PA + registrar? References: 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, 27 Feb 2002 13:46:30 -0500 Content-Transfer-Encoding: 7bit inline. Li Hua Tang wrote: > > > It's generally accepted that a PS is a combined PA/Proxy/Registrar. > > During > > our work we find that it's difficult for PS to change the role from > > proxy > > to PA or otherwise, when the presentity changes status from online to > > offline or otherwise. (In our understanding, PS acts as a proxy if the > > presentity is online and acts as a PA when the presentity goes > offline.) > > >It should work. Can you identify specific problems? > > Yes, you are right. It can work. According to the latest version of > draft-itef-sip-events-03, we find how the PS can notify the watcher to > generate a new subscription when a presentity change status from offline > to > online (using header "Subscription-State" and reason code). A new > SUBSCRIBE > request is received, so the PS can change the role from PA to proxy. > That's > what once troubled us. > > There is still a problem we are not satisfied. In normal conditions, or > if > the requests are always record-routing, all is ok. What we are concerned > is > what would PS do if the presentity crashes. PS as a proxy (which doesn't > maintain transactions) can't initiate NOTIFY request to the watcher to > make > it know that the presentity is now not available. Only when the watcher > sends out refreshing SUBSCRIBE (directly to the presentity, like > re-INVITE) > and gets no response (or 481 response if the presentity comes online > again > during this period), the watcher can know the change. So the watcher may > generate a new subscription and PS can handle it again. It's a very > passive > way. Correct. This is an inherent limitation of the end-system based notification model. There will be a delay, equal to the refresh interval of SUBSCRIBE, to detect the failure of a PA. If a network server is used (and made reliable itself, through state replication or whatever means are needed), the watcher can be notified of the change as quickly as the PA can know. That depends on the subscription refresh interval. -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 Feb 27 17:30: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 RAA22460 for ; Wed, 27 Feb 2002 17:30:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RMR3Zq024429; Wed, 27 Feb 2002 17:27:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11780; Wed, 27 Feb 2002 17:28:05 -0500 (EST) Received: from excalibur.santera.com (mail.santera.com [4.22.157.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA11229 for ; Wed, 27 Feb 2002 15:12:21 -0500 (EST) 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" Message-ID: Thread-Topic: [Sip] New Version: draft-ietf-sip-events-04 complete thread-index: AcG/vB/RCq4nW0+fRsO/G7zKqWqvaQACplJA From: "Chiou, Mark" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA11229 Subject: [Simple] RE: [Sip] draft-ietf-sip-events-04; Questions 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, 27 Feb 2002 14:11:31 -0600 Content-Transfer-Encoding: 8bit Hi Adam, I have the following questions regarding to 7.4 new Method: 1. Why the Contact header is mandatory for SUBSCRIBER and NOTIFY? If the Contact is not applicable to these methods, then "-" should be applied to R, 1xx, 2xx, 3xx, and 485. 2. I don't think 3xx is applicable to these two methods, such that contact 3xx should have "-" instead of "o". Regards, Mark Chiou _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Feb 27 17:35: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 RAA22713 for ; Wed, 27 Feb 2002 17:35:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RMStZq024493; Wed, 27 Feb 2002 17:28:55 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11802; Wed, 27 Feb 2002 17:30:28 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA11263 for ; Wed, 27 Feb 2002 15:18:52 -0500 (EST) 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" Message-ID: Thread-Topic: [Sip] New Version: draft-ietf-sip-events-04 complete thread-index: AcG/vB/RCq4nW0+fRsO/G7zKqWqvaQADu9oA From: "Chiou, Mark" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA11263 Subject: [Simple] Question regarding SIP-Specific Event Notification 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, 27 Feb 2002 14:18:01 -0600 Content-Transfer-Encoding: 8bit Hi Adam, Could you explain why the immediately NOTIFY request is required when Notifier receives a SUBSCRIBER request? For my opinion, the 200 OK response for the SUBSCRIBER request is sufficient. Thanks, Mark _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Feb 27 22:33: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 WAA02057 for ; Wed, 27 Feb 2002 22:33:28 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1S3ThZq025760; Wed, 27 Feb 2002 22:29:44 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12756; Wed, 27 Feb 2002 22:31:04 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12745 for ; Wed, 27 Feb 2002 22:30:50 -0500 (EST) Received: from d23rh901.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g1S3P0x130924 for ; Thu, 28 Feb 2002 14:25:00 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S3Unw71188 for ; Thu, 28 Feb 2002 14:30:49 +1100 Subject: Re: [Simple] New Version: draft-ietf-sip-events-04 complete To: X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 11:30:12 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, 28 Feb 2002 11:30:08 +0800 Adam, I noticed one new reason code noresource is added. Could you please give a scenario where it can be used? Best regards, Tang Lihua Research Member, Infrastructure Technology IBM China Research Lab. Phone: (8610)62986677-542 Tie line: 905-542 Email: tanglih@cn.ibm.com Adam Roach To: "'sip@ietf.org'" Sent by: cc: "'simple@mailman.dynamicsoft.com'" simple-admin@mailman.dynam icsoft.com Subject: [Simple] New Version: draft-ietf-sip-events-04 complete 2002-02-28 02:07 Please respond to sip FYI: a new version of the SIP Events draft is available. Until it appears in the archives, a copy is available from the locations listed below. WGLC has already concluded; this announcement is for information purposes only. I am not soliciting comments from the working group at this time. Official version: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.txt Unofficial PDF version w/changebars: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.pdf Changes from -03 are nominal, and are documented at: http://pages.sbcglobal.net/roaches/ietf/event-changes.html /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 28 04:11:32 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 EAA15023 for ; Thu, 28 Feb 2002 04:11:31 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1S97aZq026761; Thu, 28 Feb 2002 04:07:36 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13783; Thu, 28 Feb 2002 04:09:03 -0500 (EST) 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 EAA13772 for ; Thu, 28 Feb 2002 04:08:44 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA62826 for ; Thu, 28 Feb 2002 10:07:53 +0100 Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S99h726926 for ; Thu, 28 Feb 2002 10:09:44 +0100 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.8 |June 18, 2001) at 28/02/2002 10:07:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] Watcher with Multiple PUAs 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, 28 Feb 2002 10:07:43 +0100 Dear all, I wonder where to send Notifications if Watcher has Multiple PUAs (or contact-adresses)? Regards, Lamine. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 28 08:48: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 IAA22647 for ; Thu, 28 Feb 2002 08:48:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SDiZZq027837; Thu, 28 Feb 2002 08:44:35 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14702; Thu, 28 Feb 2002 08:46:03 -0500 (EST) 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 IAA14691 for ; Thu, 28 Feb 2002 08:45:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1SDjD6Y020086; Thu, 28 Feb 2002 08:45:16 -0500 (EST) Message-ID: <3C7E342E.733788F1@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lamine Brahimi CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Watcher with Multiple PUAs References: 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, 28 Feb 2002 08:44:14 -0500 Content-Transfer-Encoding: 7bit SUBSCRIBE can carry but a single Contact address. -Jonathan R. Lamine Brahimi wrote: > > Dear all, > > I wonder where to send Notifications if Watcher has Multiple PUAs (or > contact-adresses)? > Regards, > Lamine. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple -- 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 Feb 28 09:36: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 JAA25122 for ; Thu, 28 Feb 2002 09:36:29 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SEVXZq028238; Thu, 28 Feb 2002 09:31:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14891; Thu, 28 Feb 2002 09:33:02 -0500 (EST) 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 JAA14880 for ; Thu, 28 Feb 2002 09:32:43 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1SEWm6Y020113; Thu, 28 Feb 2002 09:32:48 -0500 (EST) Message-ID: <3C7E3F5B.405E3DCC@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] New Version: draft-ietf-sip-events-04 complete References: 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, 28 Feb 2002 09:31:55 -0500 Content-Transfer-Encoding: 7bit Li Hua Tang wrote: > > Adam, > > I noticed one new reason code noresource is added. Could you please give a > scenario where it can be used? It was discussed at length on the sip list. Its not useful for presence, but is useful for other resources, such as call state, where the subscription terminates on the end of the call. -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 Feb 28 10:41: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 KAA28993 for ; Thu, 28 Feb 2002 10:41:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SFaeZq028909; Thu, 28 Feb 2002 10:36:40 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15124; Thu, 28 Feb 2002 10:38:08 -0500 (EST) 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 HAA14377 for ; Thu, 28 Feb 2002 07:06:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17538; Thu, 28 Feb 2002 07:05:12 -0500 (EST) Message-Id: <200202281205.HAA17538@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-components-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, 28 Feb 2002 07:05:11 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Component Model for SIMPLE Author(s) : J. Rosenberg Filename : draft-rosenberg-simple-components-00.txt Pages : Date : 27-Feb-02 The SIMPLE working group has developed a core set of specifications for messaging and presence functionality. However, those protocols alone are not sufficient to build a complete IM and presence application. In this document, we advocate a componentized model, whereby the other pieces of the system are very loosely coupled, and easily swapped out for others, in order to allow innovation and differentiation. We also propose some simple solutions for several of them to allow for interop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-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-components-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-components-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: <20020227124628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-simple-components-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-simple-components-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020227124628.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 Feb 28 11:37: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 LAA02514 for ; Thu, 28 Feb 2002 11:37:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SGWbZq029548; Thu, 28 Feb 2002 11:32:37 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15316; Thu, 28 Feb 2002 11:34:04 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15305 for ; Thu, 28 Feb 2002 11:33:09 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SGU9Zq029508; Thu, 28 Feb 2002 11:30:10 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGK5V>; Thu, 28 Feb 2002 11:32:15 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300B6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Chiou, Mark'" , sip@ietf.org Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] RE: [Sip] draft-ietf-sip-events-04; Questions 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, 28 Feb 2002 11:32:14 -0500 > -----Original Message----- > From: Chiou, Mark [mailto:MChiou@Santera.com] > > 1. Why the Contact header is mandatory for SUBSCRIBER and > NOTIFY? If the Contact is not applicable to these methods, > then "-" should be applied to R, 1xx, 2xx, 3xx, and 485. Contact headers form an important part of the route. This behavior mirrors that of the bis draft. > 2. I don't think 3xx is applicable to these two methods, such > that contact 3xx should have "-" instead of "o". 3xx responses are applicable to all methods, and there's nothing that an extension can do about it. Redirect servers will always redirect unknown methods. I could also argue that 3xx responses can be quite useful for SUBSCRIBE, with some fairly compelling examples, but the above fact makes it a rather moot point. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 28 12:29: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 MAA06735 for ; Thu, 28 Feb 2002 12:29:22 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SHOWZq000360; Thu, 28 Feb 2002 12:24:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15544; Thu, 28 Feb 2002 12:26:03 -0500 (EST) 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 MAA15533 for ; Thu, 28 Feb 2002 12:25:16 -0500 (EST) Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA06575 for ; Thu, 28 Feb 2002 12:24:19 -0500 (EST) Received: (from petkos@localhost) by dynasty.cs.columbia.edu (8.9.3/8.9.3) id MAA04612 for simple@mailman.dynamicsoft.com; Thu, 28 Feb 2002 12:24:18 -0500 (EST) From: "Petri K. Koskelainen" Message-Id: <200202281724.MAA04612@dynasty.cs.columbia.edu> To: simple@mailman.dynamicsoft.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) 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, 28 Feb 2002 12:24:18 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, The draft proposes that In-Reply-To header should be used for message threading in paging mode, and the draft also states that in message session mode threading is already provided. I don't fully agree here. It works for two-party messaging but not well in group messaging scenarios. Problem 1: Message session supports only one discussion thread per session. This does not well reflect real-life scenarios. For example, there may be a group chat session with 20 people. It is very likely that they have different conversation topics going-on at the same time although they are in the same group. It is also likely that smaller sub-threads emerge and it would be nice if these can be somehow shown in the user interface similarly to current network news UIs. For example, if there are several questions asked in the group and users respond with "yes!" or "no" in the message body it is quite difficult to know to which question they were intended. User Interface could show them nicely if there were header support for it. Problem 2: Group messaging server creates new Call-IDs for each call-leg. In-Reply-To has also problems in group IM paging mode since the server creates new Call-IDs for each participant. One call-id is valid only between one user and the server. The server has to remember all previous Call-IDs so it can change Call-IDs in In-Reply-To accordingly when somebody is responding to group message. It must have the history and know that a message it sent to Bob a day ago with Call-ID=X is in fact the same message than message sent to Alice with Call-ID=Y. This becames quite complicated. Problem 3: Lack of global and common ID for each group message. Now it is difficult to reference a specific group instant message afterwards so that everybody understands it. Only the server has the knowledge (if it keeps the history). The recipients don't know that group IM sent to me with Call-ID=X is the same than group IM sent to Alice with Call-ID=Y. In some cases it would be useful to have the information available in the message. These problems can be solved if new header (Message-ID) is defined and References header is used (like in NNTP messages). BR, -- Petri _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 28 13:18: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 NAA10116 for ; Thu, 28 Feb 2002 13:18:21 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SIDWZq000834; Thu, 28 Feb 2002 13:13:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15716; Thu, 28 Feb 2002 13:15:04 -0500 (EST) 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 NAA15703 for ; Thu, 28 Feb 2002 13:14:34 -0500 (EST) 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 SMTP id g1SID8B12843; Thu, 28 Feb 2002 12:13:08 -0600 Message-ID: <014301c1c083$7fa086c0$bc036e3f@TXDWILLIS2> From: "Dean Willis" To: "Petri K. Koskelainen" , References: <200202281724.MAA04612@dynasty.cs.columbia.edu> Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) 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: Thu, 28 Feb 2002 12:12:35 -0600 Content-Transfer-Encoding: 7bit Petri, talking abouta thread that decomposes int subordinate threads, wrote: > These problems can be solved if new header (Message-ID) > is defined and References header is used (like in NNTP messages). I'm reminded of the tumbler approach that Ted Nelson developed in the Xanadu framework for providing infinitely subscopable addressing. Essentially, a subscope of any address could could be declared by suffixing a "." and a subscope identifier to the existing address. Although tumblers used numeric addressing ostensibly derived from byte counts within static documents, a similar mechanism was later used for describing heirarchy in usenet groups, such as "rec.humor.funny.standards.messaging". -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 28 20:36:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28677 for ; Thu, 28 Feb 2002 20:36:21 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g211WcZq004415; Thu, 28 Feb 2002 20:32:38 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17033; Thu, 28 Feb 2002 20:34:04 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17021 for ; Thu, 28 Feb 2002 20:33:10 -0500 (EST) Received: from d23rh901.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g211SBn328726 for ; Fri, 1 Mar 2002 12:28:11 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g211X5S92052 for ; Fri, 1 Mar 2002 12:33:07 +1100 To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 01/03/2002 09:32:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] Is there any sip draft for presence status? 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, 1 Mar 2002 09:32:24 +0800 Hi all, I wonder if there is some sip draft to define user presence status, such as available/do-not-disturb/away/offline/invisible etc. I think we need a standard to describe it. Best regards, Tang Lihua Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Feb 28 21:31:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29551 for ; Thu, 28 Feb 2002 21:31:38 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g212RVZq004753; Thu, 28 Feb 2002 21:27:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17225; Thu, 28 Feb 2002 21:29:02 -0500 (EST) 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 VAA17214 for ; Thu, 28 Feb 2002 21:28:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.62]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g212So6Y020964; Thu, 28 Feb 2002 21:28:51 -0500 (EST) Message-ID: <3C7EE72C.116DAF19@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Is there any sip draft for presence status? References: 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, 28 Feb 2002 21:27:56 -0500 Content-Transfer-Encoding: 7bit See: http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-01.txt which is the mandatory presence document format for SIMPLE. -Jonathan R. Li Hua Tang wrote: > > Hi all, > > I wonder if there is some sip draft to define user presence status, such > as > available/do-not-disturb/away/offline/invisible etc. I think we need a > standard > to describe it. > > Best regards, > > Tang Lihua > Email: tanglih@cn.ibm.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple -- 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 Feb 28 22:15: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 WAA01335 for ; Thu, 28 Feb 2002 22:15:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g213BXZq004944; Thu, 28 Feb 2002 22:11:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA17381; Thu, 28 Feb 2002 22:13:02 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA17370 for ; Thu, 28 Feb 2002 22:12:18 -0500 (EST) Received: from d23rh901.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g2137Jn278806; Fri, 1 Mar 2002 14:07:19 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g213CES44116; Fri, 1 Mar 2002 14:12:14 +1100 To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 01/03/2002 11:11:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] draft-rosenberg-simple-components-00.txt (Realtime Authorization) 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, 1 Mar 2002 11:11:34 +0800 Jonathan, Thanks for your indication to user presence status. I find related definition in RFC2778. One more question about realtime authorization. If the presentity has subscribed for winfo event, the PS can send the pending wacther status to the presentity to ask for authorization. But if the presentity didn't do so at early time, how can the PS notify it of a waiting authorization? I read the draft about QAUTH, but it seems a too old draft and I don't know whether it's still valid (or adopted by other vendors) now? Best regards, Tang Lihua Research Member, Infrastructure Technology IBM China Research Lab. Phone: (8610)62986677-542 Tie line: 905-542 Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple