From extest-admin@lists.bell-labs.com Wed Jan 1 05:17:55 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02208 for ; Wed, 1 Jan 2003 05:17:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h01ALA209422 for ; Wed, 1 Jan 2003 05:21:10 -0500 Date: Wed, 1 Jan 2003 05:21:10 -0500 Message-Id: <200301011021.h01ALA209422@share.research.bell-labs.com> Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: spirits-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your lists.bell-labs.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, spirits-request@lists.bell-labs.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@lists.bell-labs.com. Thanks! Passwords for spirits-archive@lists.ietf.org: List Password // URL ---- -------- spirits@lists.bell-labs.com unmora http://lists.bell-labs.com/mailman/options/spirits/spirits-archive%40lists.ietf.org From spirits-admin@lists.bell-labs.com Wed Jan 15 11:29:16 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02271 for ; Wed, 15 Jan 2003 11:29:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FGW3230692; Wed, 15 Jan 2003 11:32:03 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FGV7230679 for ; Wed, 15 Jan 2003 11:31:07 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0FGV1hN025362 for ; Wed, 15 Jan 2003 11:31:01 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id CFF29443A5; Wed, 15 Jan 2003 11:30:55 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id A70A3443A4 for ; Wed, 15 Jan 2003 11:30:55 -0500 (EST) Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FGUrY62181 for ; Wed, 15 Jan 2003 11:30:53 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA17533; Wed, 15 Jan 2003 10:30:52 -0600 (CST) Message-ID: <3E258C6A.4060708@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SPIRITS list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [SPIRITS] Subscribing to multiple DPs Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 Jan 2003 10:29:30 -0600 Content-Transfer-Encoding: 7bit Any thoughts on subscribing to multiple DPs in one SUBSCRIBE request? For instance, if I am implementing a presence capability on a black phone, I would typically be interested in the following events: answering calls and attempt to make a call. So far in our discussion in the protocol I-D, we do not explicitly prohibit subscriptions to multiple DPs, nor to we explicitly condone it. However, the examples in the text all have subscriptions to a single DP. Any thoughts and views would be appreciated. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jan 15 12:04:42 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03348 for ; Wed, 15 Jan 2003 12:04:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FH81231047; Wed, 15 Jan 2003 12:08:01 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FH7k231034 for ; Wed, 15 Jan 2003 12:07:46 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0FH7ehN025683 for ; Wed, 15 Jan 2003 12:07:40 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 1621B443A5; Wed, 15 Jan 2003 12:07:35 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id E3660443A4 for ; Wed, 15 Jan 2003 12:07:34 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FH7XI71956 for ; Wed, 15 Jan 2003 12:07:33 -0500 (EST) Received: from pop-3.dnv.wideopenwest.com (gtwy.nap.wideopenwest.com [64.233.207.11] (may be forged)) by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id h0FH5foJ080250 for ; Wed, 15 Jan 2003 12:05:41 -0500 (EST) Received: from ieee.org (d233-144-198.nap.wideopenwest.com [64.233.198.144]) by pop-3.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h0FHFsj29312; Wed, 15 Jan 2003 11:15:54 -0600 Message-ID: <3E25954F.2000200@ieee.org> From: Alec Brusilovsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.1(snapshot 20020919) (pop-3.dnv.wideopenwest.com) Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 Jan 2003 11:07:27 -0600 Content-Transfer-Encoding: 7bit I realize that multiple DP/events subscribe would be a handy thing to have. In my opinion, single DP/event subscription is a much cleaner thing to do. If you need to implement a service that asks for multiple subscribes - just do exactly that: issue multiple SUBSCRIBE loops. Much, much easier to control and lighter on security threats. Drawback: creates more network traffic. It is a good discussion, let's continue it. -Alec Vijay K. Gurbani wrote: > Any thoughts on subscribing to multiple DPs in one SUBSCRIBE request? > For instance, if I am implementing a presence capability on a black > phone, I would typically be interested in the following events: > answering calls and attempt to make a call. > > So far in our discussion in the protocol I-D, we do not explicitly > prohibit subscriptions to multiple DPs, nor to we explicitly condone > it. However, the examples in the text all have subscriptions to a > single DP. > > Any thoughts and views would be appreciated. > > Thanks, > > - vijay -- Alec Brusilovsky abrusilovsky@ieee.org Naperville, IL USA +1.630.369.8196 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jan 15 12:18:47 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03983 for ; Wed, 15 Jan 2003 12:18:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHM6231201; Wed, 15 Jan 2003 12:22:06 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHLK231184 for ; Wed, 15 Jan 2003 12:21:20 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0FHLEhN025803 for ; Wed, 15 Jan 2003 12:21:14 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 03B8A443A5; Wed, 15 Jan 2003 12:21:09 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id D1A91443A4 for ; Wed, 15 Jan 2003 12:21:08 -0500 (EST) Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHL7Y66496 for ; Wed, 15 Jan 2003 12:21:07 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA12383; Wed, 15 Jan 2003 11:21:05 -0600 (CST) Message-ID: <3E25982E.9020706@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alec Brusilovsky Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> <3E25954F.2000200@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 Jan 2003 11:19:42 -0600 Content-Transfer-Encoding: 7bit Alec Brusilovsky wrote: > I realize that multiple DP/events subscribe would be a handy thing to have. > In my opinion, single DP/event subscription is a much cleaner thing to > do. If you need to implement a service that asks for multiple subscribes > - just do exactly that: issue multiple SUBSCRIBE loops. But all these SUBSCRIBEs logically belong to the same service. I think that we should we should physically end up representing the subscription to each such DP in the same SUBSCRIBE request. I would expect one, and only one NOTIFY when any of these events occur. What are my expectations if I send multiple SUBSCRIBEs? Am I getting multiple NOTIFYs? > Much, much > easier to control and lighter on security threats. Drawback: creates > more network traffic. Using a different SUBSCRIBE request for each DP which results in the same service appears (to me, anyway) cumbersome and network and processing intensive. Furthermore, after the NOTIFYs arrive and the subscription expires, it is easy to re-subscribe using the single SUBSCRIBE request instead of sending a flurry of multiple SUBSCRIBEs. Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jan 15 12:38:53 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04612 for ; Wed, 15 Jan 2003 12:38:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHg1231395; Wed, 15 Jan 2003 12:42:01 -0500 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHfp231382 for ; Wed, 15 Jan 2003 12:41:51 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0FHfiLI095352 for ; Wed, 15 Jan 2003 12:41:44 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 6CEE0443A5; Wed, 15 Jan 2003 12:41:39 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 45DCF443A4 for ; Wed, 15 Jan 2003 12:41:39 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHfbY68502 for ; Wed, 15 Jan 2003 12:41:38 -0500 (EST) Received: from pop-3.dnv.wideopenwest.com (gtwy.nap.wideopenwest.com [64.233.207.11] (may be forged)) by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id h0FHdjoJ084851 for ; Wed, 15 Jan 2003 12:39:45 -0500 (EST) Received: from ieee.org (d233-144-198.nap.wideopenwest.com [64.233.198.144]) by pop-3.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h0FHnxj08986; Wed, 15 Jan 2003 11:49:59 -0600 Message-ID: <3E259D4A.7030203@ieee.org> From: Alec Brusilovsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> <3E25954F.2000200@ieee.org> <3E25982E.9020706@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.1(snapshot 20020919) (pop-3.dnv.wideopenwest.com) Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 Jan 2003 11:41:30 -0600 Content-Transfer-Encoding: 7bit So, where is the logical aggregation of the DPs (events) into one service happening? What is the same DP (event) is utilized in multiple servises? Than we are up to a real mess. Sometimes creating extra traffic is the lesser of evils... -Alec Vijay K. Gurbani wrote: > Alec Brusilovsky wrote: > >> I realize that multiple DP/events subscribe would be a handy thing to >> have. >> In my opinion, single DP/event subscription is a much cleaner thing >> to do. If you need to implement a service that asks for multiple >> subscribes - just do exactly that: issue multiple SUBSCRIBE loops. > > > But all these SUBSCRIBEs logically belong to the same service. I think > that we should we should physically end up representing the subscription > to each such DP in the same SUBSCRIBE request. I would expect one, and > only one NOTIFY when any of these events occur. What are my > expectations if I send multiple SUBSCRIBEs? Am I getting multiple > NOTIFYs? > >> Much, much easier to control and lighter on security threats. >> Drawback: creates more network traffic. > > > Using a different SUBSCRIBE request for each DP which results in the > same service appears (to me, anyway) cumbersome and network and > processing intensive. Furthermore, after the NOTIFYs arrive and the > subscription expires, it is easy to re-subscribe using the single > SUBSCRIBE request instead of sending a flurry of multiple SUBSCRIBEs. > > Cheers, > > - vijay -- Alec Brusilovsky abrusilovsky@ieee.org Naperville, IL USA +1.630.369.8196 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jan 15 12:45:45 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04811 for ; Wed, 15 Jan 2003 12:45:44 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHn1231492; Wed, 15 Jan 2003 12:49:01 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHmc231479 for ; Wed, 15 Jan 2003 12:48:38 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0FHmVhN026143 for ; Wed, 15 Jan 2003 12:48:31 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 11BDE443A5; Wed, 15 Jan 2003 12:48:26 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id DC056443A4 for ; Wed, 15 Jan 2003 12:48:25 -0500 (EST) Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0FHmOI75481 for ; Wed, 15 Jan 2003 12:48:24 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA24064; Wed, 15 Jan 2003 11:48:21 -0600 (CST) Message-ID: <3E259E93.4000006@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alec Brusilovsky Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> <3E25954F.2000200@ieee.org> <3E25982E.9020706@lucent.com> <3E259D4A.7030203@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 Jan 2003 11:46:59 -0600 Content-Transfer-Encoding: 7bit Alec Brusilovsky wrote: > So, where is the logical aggregation of the DPs (events) into one > service happening? What is the same DP (event) is utilized in multiple > servises? Than we are up to a real mess. Ah, okay. I see your point... - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jan 16 12:23:53 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16801 for ; Thu, 16 Jan 2003 12:23:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0GHR1208163; Thu, 16 Jan 2003 12:27:01 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0GHQh208150 for ; Thu, 16 Jan 2003 12:26:43 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0GHQbhN036590 for ; Thu, 16 Jan 2003 12:26:37 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id C6F6F443A5; Thu, 16 Jan 2003 12:26:31 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id A0C48443A4 for ; Thu, 16 Jan 2003 12:26:31 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0GHQUI62591 for ; Thu, 16 Jan 2003 12:26:30 -0500 (EST) Received: from pop-1.dnv.wideopenwest.com (gtwy.nap.wideopenwest.com [64.233.207.11] (may be forged)) by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id h0GHOZoJ025179 for ; Thu, 16 Jan 2003 12:24:35 -0500 (EST) Received: from ieee.org (d233-144-198.nap.wideopenwest.com [64.233.198.144]) by pop-1.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h0GHT3D08918; Thu, 16 Jan 2003 11:29:03 -0600 Message-ID: <3E26EB42.50908@ieee.org> From: Alec Brusilovsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> <3E25954F.2000200@ieee.org> <3E25982E.9020706@lucent.com> <3E259D4A.7030203@ieee.org> <3E259E93.4000006@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 16 Jan 2003 11:26:26 -0600 Content-Transfer-Encoding: 7bit Vijay, I also better see your point after our phone chat yesterday: aggregation of multiple DPs into a SET when SUBSCRIBE would open nice options for those SPIRITS services that require logical OR of the DPs. In that case, I would like to propose to limit this option to the DPs, belonging to the same half of the BCSM (i.e., Originating or Terminating). Example: OAA and O_Answer may be in one SUB/NOT; however, OAA and TAA may not. Also, as you pointed, in case of NOTIFY, resulting from a "SET" SUBSCRIBE, the whole "SET" SUBSCRIBE is expired, even though only one of the DPs from the SET has been activated. In the case when the other DPs from the SET are of interest, specific NOTIFY has to be issued for the rest of DPs in the SET. In most cases it is easier to issue simple singular SUB/NOT pairs. How does this sound? -Alec Vijay K. Gurbani wrote: > Alec Brusilovsky wrote: > >> So, where is the logical aggregation of the DPs (events) into one >> service happening? What is the same DP (event) is utilized in >> multiple servises? Than we are up to a real mess. > > > Ah, okay. I see your point... > > - vijay -- Alec Brusilovsky abrusilovsky@ieee.org Naperville, IL USA +1.630.369.8196 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jan 17 00:15:49 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02792 for ; Fri, 17 Jan 2003 00:15:49 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0H5J1212061; Fri, 17 Jan 2003 00:19:01 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0H5Hw212046 for ; Fri, 17 Jan 2003 00:17:58 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0H5HphN041782 for ; Fri, 17 Jan 2003 00:17:51 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 68138443A5; Fri, 17 Jan 2003 00:17:46 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 3C740443A4 for ; Fri, 17 Jan 2003 00:17:46 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0H5HiY04881 for ; Fri, 17 Jan 2003 00:17:45 -0500 (EST) Received: from hindon.hss.co.in ([202.54.26.202]) by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id h0H5FkoJ097885 for ; Fri, 17 Jan 2003 00:15:47 -0500 (EST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0H5GLj19648 for ; Fri, 17 Jan 2003 10:46:21 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h0H5GKM19642 for ; Fri, 17 Jan 2003 10:46:20 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h0H5IRT05568 for ; Fri, 17 Jan 2003 10:48:31 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256CB1.001C653B ; Fri, 17 Jan 2003 10:40:09 +0530 X-Lotus-FromDomain: HSS From: ucbabu@hss.hns.com To: spirits@lists.bell-labs.com Message-ID: <65256CB1.001C63DB.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SPIRITS] Re: SPIRITS digest, Vol 1 #52 - 4 msgs Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 17 Jan 2003 10:42:55 +0530 hi all, I hope that we can have subscription to multiple DPs in a single SUBSCRIBE message. The DPs to be subscribed in a SUBSCRIBE message can be an ARRAY. In this way we can subscribe to mulitple DPs.. and Talking of the Notify ....Notify will be sent only for the DP hit. thanks Uppen spirits-request@lists.bell-labs.com on 01/16/2003 10:31:05 PM Please respond to spirits@lists.bell-labs.com To: spirits@lists.bell-labs.com cc: (bcc: Uppen Babu Chava/HSS) Subject: SPIRITS digest, Vol 1 #52 - 4 msgs Send SPIRITS mailing list submissions to spirits@lists.bell-labs.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.bell-labs.com/mailman/listinfo/spirits or, via email, send a message with subject or body 'help' to spirits-request@lists.bell-labs.com You can reach the person managing the list at spirits-admin@lists.bell-labs.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SPIRITS digest..." Today's Topics: 1. Re: Subscribing to multiple DPs (Alec Brusilovsky) 2. Re: Subscribing to multiple DPs (Vijay K. Gurbani) 3. Re: Subscribing to multiple DPs (Alec Brusilovsky) 4. Re: Subscribing to multiple DPs (Vijay K. Gurbani) Message: 1 Delivered-To: spirits@sunny.research.bell-labs.com Message-ID: <3E25954F.2000200@ieee.org> Date: Wed, 15 Jan 2003 11:07:27 -0600 From: Alec Brusilovsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 MIME-Version: 1.0 To: "Vijay K. Gurbani" Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Precedence: bulk List-Help: List-Post: List-Subscribe: , < mailto:spirits-request@lists.bell-labs.com?subject=subscribe> List-Id: List-Unsubscribe: , < mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe> List-Archive: I realize that multiple DP/events subscribe would be a handy thing to have. In my opinion, single DP/event subscription is a much cleaner thing to do. If you need to implement a service that asks for multiple subscribes - just do exactly that: issue multiple SUBSCRIBE loops. Much, much easier to control and lighter on security threats. Drawback: creates more network traffic. It is a good discussion, let's continue it. -Alec Vijay K. Gurbani wrote: > Any thoughts on subscribing to multiple DPs in one SUBSCRIBE request? > For instance, if I am implementing a presence capability on a black > phone, I would typically be interested in the following events: > answering calls and attempt to make a call. > > So far in our discussion in the protocol I-D, we do not explicitly > prohibit subscriptions to multiple DPs, nor to we explicitly condone > it. However, the examples in the text all have subscriptions to a > single DP. > > Any thoughts and views would be appreciated. > > Thanks, > > - vijay -- Alec Brusilovsky abrusilovsky@ieee.org Naperville, IL USA +1.630.369.8196 Message: 2 Delivered-To: spirits@sunny.research.bell-labs.com Message-ID: <3E25982E.9020706@lucent.com> Date: Wed, 15 Jan 2003 11:19:42 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 MIME-Version: 1.0 To: Alec Brusilovsky Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> <3E25954F.2000200@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Precedence: bulk List-Help: List-Post: List-Subscribe: , < mailto:spirits-request@lists.bell-labs.com?subject=subscribe> List-Id: List-Unsubscribe: , < mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe> List-Archive: Alec Brusilovsky wrote: > I realize that multiple DP/events subscribe would be a handy thing to have. > In my opinion, single DP/event subscription is a much cleaner thing to > do. If you need to implement a service that asks for multiple subscribes > - just do exactly that: issue multiple SUBSCRIBE loops. But all these SUBSCRIBEs logically belong to the same service. I think that we should we should physically end up representing the subscription to each such DP in the same SUBSCRIBE request. I would expect one, and only one NOTIFY when any of these events occur. What are my expectations if I send multiple SUBSCRIBEs? Am I getting multiple NOTIFYs? > Much, much > easier to control and lighter on security threats. Drawback: creates > more network traffic. Using a different SUBSCRIBE request for each DP which results in the same service appears (to me, anyway) cumbersome and network and processing intensive. Furthermore, after the NOTIFYs arrive and the subscription expires, it is easy to re-subscribe using the single SUBSCRIBE request instead of sending a flurry of multiple SUBSCRIBEs. Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Message: 3 Delivered-To: spirits@sunny.research.bell-labs.com Message-ID: <3E259D4A.7030203@ieee.org> Date: Wed, 15 Jan 2003 11:41:30 -0600 From: Alec Brusilovsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 MIME-Version: 1.0 To: "Vijay K. Gurbani" Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> <3E25954F.2000200@ieee.org> <3E25982E.9020706@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Precedence: bulk List-Help: List-Post: List-Subscribe: , < mailto:spirits-request@lists.bell-labs.com?subject=subscribe> List-Id: List-Unsubscribe: , < mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe> List-Archive: So, where is the logical aggregation of the DPs (events) into one service happening? What is the same DP (event) is utilized in multiple servises? Than we are up to a real mess. Sometimes creating extra traffic is the lesser of evils... -Alec Vijay K. Gurbani wrote: > Alec Brusilovsky wrote: > >> I realize that multiple DP/events subscribe would be a handy thing to >> have. >> In my opinion, single DP/event subscription is a much cleaner thing >> to do. If you need to implement a service that asks for multiple >> subscribes - just do exactly that: issue multiple SUBSCRIBE loops. > > > But all these SUBSCRIBEs logically belong to the same service. I think > that we should we should physically end up representing the subscription > to each such DP in the same SUBSCRIBE request. I would expect one, and > only one NOTIFY when any of these events occur. What are my > expectations if I send multiple SUBSCRIBEs? Am I getting multiple > NOTIFYs? > >> Much, much easier to control and lighter on security threats. >> Drawback: creates more network traffic. > > > Using a different SUBSCRIBE request for each DP which results in the > same service appears (to me, anyway) cumbersome and network and > processing intensive. Furthermore, after the NOTIFYs arrive and the > subscription expires, it is easy to re-subscribe using the single > SUBSCRIBE request instead of sending a flurry of multiple SUBSCRIBEs. > > Cheers, > > - vijay -- Alec Brusilovsky abrusilovsky@ieee.org Naperville, IL USA +1.630.369.8196 Message: 4 Delivered-To: spirits@sunny.research.bell-labs.com Message-ID: <3E259E93.4000006@lucent.com> Date: Wed, 15 Jan 2003 11:46:59 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 MIME-Version: 1.0 To: Alec Brusilovsky Cc: SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E258C6A.4060708@lucent.com> <3E25954F.2000200@ieee.org> <3E25982E.9020706@lucent.com> <3E259D4A.7030203@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Precedence: bulk List-Help: List-Post: List-Subscribe: , < mailto:spirits-request@lists.bell-labs.com?subject=subscribe> List-Id: List-Unsubscribe: , < mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe> List-Archive: Alec Brusilovsky wrote: > So, where is the logical aggregation of the DPs (events) into one > service happening? What is the same DP (event) is utilized in multiple > servises? Than we are up to a real mess. Ah, okay. I see your point... - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jan 17 01:29:47 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03687 for ; Fri, 17 Jan 2003 01:29:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0H6X1212603; Fri, 17 Jan 2003 01:33:01 -0500 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0H6Vv212588 for ; Fri, 17 Jan 2003 01:31:57 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0H6VoLI010916 for ; Fri, 17 Jan 2003 01:31:50 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 4A9EA443A5; Fri, 17 Jan 2003 01:31:45 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 246A9443A4 for ; Fri, 17 Jan 2003 01:31:45 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0H6VhY08161 for ; Fri, 17 Jan 2003 01:31:43 -0500 (EST) Received: from e-eihq01.eis.ernet.in (e-eihq01.eis.ernet.in [202.41.97.131]) by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id h0H6TgoJ004228 for ; Fri, 17 Jan 2003 01:29:44 -0500 (EST) Received: from uucp-relay-delhi.ernet.in by e-eihq01.eis.ernet.in (8.10.2/1.1.2.10/13Jul01-0336PM) id h0H74Kb0000025553; Fri, 17 Jan 2003 12:04:21 +0500 (GMT+0500) Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id LAA10823; Fri, 17 Jan 2003 11:56:09 -0500 (GMT) >Received: from earth.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id LAA00064; Fri, 17 Jan 2003 11:44:41 -0500 From: Deepak Gandotra To: Alec Brusilovsky Cc: "Vijay K. Gurbani" , SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs In-Reply-To: <3E26EB42.50908@ieee.org> Message-ID: MIME-Version: 1.0 Received: from cdotd by vikram.eis.ernet.in; Fri, 17 Jan 2003 11:56 GMT Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 17 Jan 2003 11:54:58 +0500 (GMT+0500) Alec, You have proposed to maintain the same half of the BCSM in one SUB message but it may be desired to subscribe to both the OAA and the TAA DPs in one SUB message as may be required for a "centralized charging" kind of service which allows the user to make calls while the charges are maintained/administered centrally. In this service all the incomming call and the outgoing call instances have to be informed to the "server". It would thus be required to allow the SUB message to carry the subscription requests irrespective of the BCSM half. Further I would propose that the "Expires" parameter be sent seperately for all the DPs sent in the SUB message as they would have different meaning to the service and thus may have a different "time to live" span. Another "Expires2" parameter may be sent in the SUB message, which would would "bind" the Expires parameter associated with each DPs, indicating the expiry time of the complete set of subscriptions in the SUB message. This would mean that the DP subscriptions can expire before the "Expires2" parameter and all the DP subscriptions would expire when "Expires2" completes. DG, Research Engineer, CDOT, Delhi. ________________________________________________________________________________ Whatever the mind can conceive and believe, it can achieve. ________________________________________________________________________________ On Thu, 16 Jan 2003, Alec Brusilovsky wrote: > Vijay, > > I also better see your point after our phone chat yesterday: aggregation > of multiple DPs into a SET when SUBSCRIBE would open nice options for > those SPIRITS services that require logical OR of the DPs. > In that case, I would like to propose to limit this option to the DPs, > belonging to the same half of the BCSM (i.e., Originating or Terminating). > Example: OAA and O_Answer may be in one SUB/NOT; however, OAA and TAA > may not. > > Also, as you pointed, in case of NOTIFY, resulting from a "SET" > SUBSCRIBE, the whole "SET" SUBSCRIBE is expired, even though only one of > the DPs from the SET has been activated. In the case when the other DPs > from the SET are of interest, specific NOTIFY has to be issued for the > rest of DPs in the SET. In most cases it is easier to issue simple > singular SUB/NOT pairs. > > How does this sound? > > -Alec > > Vijay K. Gurbani wrote: > > > Alec Brusilovsky wrote: > > > >> So, where is the logical aggregation of the DPs (events) into one > >> service happening? What is the same DP (event) is utilized in > >> multiple servises? Than we are up to a real mess. > > > > > > Ah, okay. I see your point... > > > > - vijay > > > -- > Alec Brusilovsky > abrusilovsky@ieee.org > Naperville, IL USA > +1.630.369.8196 > > > > > _______________________________________________ > SPIRITS mailing list > SPIRITS@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/spirits > > _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jan 17 11:21:54 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27517 for ; Fri, 17 Jan 2003 11:21:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0HGP2216271; Fri, 17 Jan 2003 11:25:02 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0HGOM216252 for ; Fri, 17 Jan 2003 11:24:22 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0HGOFhN046738 for ; Fri, 17 Jan 2003 11:24:15 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 0BC26443A5; Fri, 17 Jan 2003 11:24:10 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id D5455443A4 for ; Fri, 17 Jan 2003 11:24:09 -0500 (EST) Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0HGO8Y44776 for ; Fri, 17 Jan 2003 11:24:08 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA20719; Fri, 17 Jan 2003 10:24:05 -0600 (CST) Message-ID: <3E282DCF.1040506@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Deepak Gandotra Cc: Alec Brusilovsky , SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 17 Jan 2003 10:22:39 -0600 Content-Transfer-Encoding: 7bit Deepak Gandotra wrote: > Alec, > > You have proposed to maintain the same half of the BCSM in one SUB > message but it may be desired to subscribe to both the OAA and the > TAA DPs in one SUB [...] I believe Alec wanted to err on the side of being overly cautious; hence the DPs belonging to one half of the BCSM. While I agree that such a strategy leaves no ambiguity -- after all, as far as I can see it, the DPs naturally follow a OR mechanism; i.e. if the DPs are armed, they trigger sequentially -- I think we can do better. The problem with having DPs from both halves is race condition. Let me illustrate with an example. Let's say that a service provider wants to implement some kind of presence service on a POTS device (i.e. black phone). Thus the events of interest are OAA (caller attempts to make a call, which indicates presence), TA (callee gets a call, which again indicates presence) and T_Busy [TB] (callee already on a call, which indicates presence). So, a SUBS will contain the three DPs: OAA, TA, and TB. Now, let's say that a user picks up the phone and makes a call (thus triggering OAA in O_BCSM), and at the same time, a call arrives for the user, resulting in a T_BCSM being initialized and either TA or, most probably TB firing. Note that the results of the race condition itself are not egregious (certainly not life-threatning), but how the system deals with this is interesting (more on this later). Also note that we would have the same race condition if two different SUBS were sent -- one with OAA and the other with TA and TB. So, we cannot avoid the race condition even if we sent two SUBS. The question now boils down to what is the behavior of the SPIRITS notifier when such a race condition occurs? Should it collate both of these events into one NOTIFY and send it out? Or should it send out separate NOTIFYs for each event? The current SPIRITS protocol I-D states that once a DP fires, the subscription is terminated (it can be resurrected again if desired). Thus this behavior dictates that SPIRITS notifier wait for such race conditions to occur before sending the NOTIFY. Of course, the current I-D does not take in account multiple DPs, so this behavior may be simplistic. This leads us logically to your next point, which basically asks what happens to the remaining DP when a DP from a set of DPs fire? > Further I would propose that the "Expires" parameter be sent seperately > for all the DPs sent in the SUB message as they would have different > meaning to the service and thus may have a different "time to live" span. There are two ways to deal with this; one is as you suggest above. How- ever, the crucial part missing in this is the dialog created by the initial SUBS. To me, it seems logical that I associate a set of DPs with a dialog. When the dialog expires, the set of DPs that have not fired yet should be disarmed. Remember, the SPIRITS subscriber can always re-arm the DPs through another SUBS. If we associate an expiry duration with an individual DP, I think we may run into feature interaction problems where a DP armed for a previous service (but did not fire) now needs to be armed for a new service. Which service gets precedence? Furthermore, if the dialog has expired, does it make sense to keep the DP armed. I belive you have already thought of that scenario as well, and hence: > Another "Expires2" parameter may be sent in the SUB message, which would > would "bind" the Expires parameter associated with each DPs, indicating > the expiry time of the complete set of subscriptions in the SUB > message. This would mean that the DP subscriptions can expire before the > "Expires2" parameter and all the DP subscriptions would expire when > "Expires2" completes. But I believe that this type of mechanism complicates dialog and DP management, not to mention adding a new header to the SIP dictionary. I would like to avoid both of these if I can. If you want the semantics of n-1 DPs from a set being active after one fires, I think multiple SUBS would be the best way to deal with it. So, my proposal is that: (1) We allow subscription to multiple DPs (we can scope it as a MAY). DPs can be drawn from both halves. (2) When any DP from this set fires, a NOTIFY is sent out immediately (3) The NOTIFY serves to terminate the SUBS and dis-arm the remaining DPs that did not fire. The XML for subscription to multiple DPs can look as follows (working from our 'presence' for POTS line example): 16302240216 16302240216 16302240216 Note the salient change is that there can now be more than one element. Any parameters that are part of that DP will now become sub-elements of the element. I think that this is powerful and extensible enough that we can subscribe to 1 DP or multiple DPs. At the same time, we do not proscribe that "for black phone presence, thou shalt use the following DPs..." The selection of DPs is left to the service provider. Comments? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jan 17 11:44:57 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28285 for ; Fri, 17 Jan 2003 11:44:57 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0HGm2216446; Fri, 17 Jan 2003 11:48:02 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0HGlt216428 for ; Fri, 17 Jan 2003 11:47:55 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0HGlmhN046966 for ; Fri, 17 Jan 2003 11:47:48 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 8C982443A6; Fri, 17 Jan 2003 11:47:43 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 60230443A4 for ; Fri, 17 Jan 2003 11:47:43 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0HGlfY47114 for ; Fri, 17 Jan 2003 11:47:41 -0500 (EST) Received: from pop-1.dnv.wideopenwest.com (gtwy.nap.wideopenwest.com [64.233.207.11] (may be forged)) by dusty.research.bell-labs.com (8.12.6/8.12.6) with ESMTP id h0HGjhoJ062798 for ; Fri, 17 Jan 2003 11:45:43 -0500 (EST) Received: from ieee.org (d233-144-198.nap.wideopenwest.com [64.233.198.144]) by pop-1.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h0HGo0D06791; Fri, 17 Jan 2003 10:50:00 -0600 Message-ID: <3E28339A.7070809@ieee.org> From: Alec Brusilovsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: "Vijay K. Gurbani" Cc: Deepak Gandotra , SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E282DCF.1040506@lucent.com> Content-Type: multipart/alternative; boundary="------------040506050706020901090001" Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 17 Jan 2003 10:47:22 -0600 --------------040506050706020901090001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit OK. Let me summarize the discussion that we just had: * It is important to be able to SUBSCRIBE to a SET of DPs and than get NOTIFY when ANY ONE of them becomes activated; * After subsequent NOTIFY the corresponding SUBSCRIBE is spent, regardless of the number of unencountered DPs. The SPIRITS Server needs to issue a new SUBSCRIBE in order to renew the subscription; * The safest way is to issue a single DP SUBSCRIBEs, so we are putting this SET of DPs SUBSCRIBE as a valid option and use MAY in the protocol specs. Did I miss something? Regards, Alec Vijay K. Gurbani wrote: > Deepak Gandotra wrote: > >> Alec, >> >> You have proposed to maintain the same half of the BCSM in one SUB >> message but it may be desired to subscribe to both the OAA and the >> TAA DPs in one SUB > > [...] > > I believe Alec wanted to err on the side of being overly cautious; > hence the DPs belonging to one half of the BCSM. While I agree that > such a strategy leaves no ambiguity -- after all, as far as I can > see it, the DPs naturally follow a OR mechanism; i.e. if the DPs > are armed, they trigger sequentially -- I think we can do better. > > The problem with having DPs from both halves is race condition. Let > me illustrate with an example. Let's say that a service provider > wants to implement some kind of presence service on a POTS device > (i.e. black phone). Thus the events of interest are OAA (caller > attempts to make a call, which indicates presence), TA (callee gets > a call, which again indicates presence) and T_Busy [TB] (callee > already on a call, which indicates presence). So, a SUBS will contain > the three DPs: OAA, TA, and TB. > > Now, let's say that a user picks up the phone and makes a call (thus > triggering OAA in O_BCSM), and at the same time, a call arrives for > the user, resulting in a T_BCSM being initialized and either TA or, most > probably TB firing. Note that the results of the race condition itself > are not egregious (certainly not life-threatning), but how the system > deals with this is interesting (more on this later). Also note that we > would have the same race condition if two different SUBS were sent -- > one with OAA and the other with TA and TB. So, we cannot avoid the race > condition even if we sent two SUBS. > > The question now boils down to what is the behavior of the SPIRITS > notifier when such a race condition occurs? Should it collate both > of these events into one NOTIFY and send it out? Or should it send > out separate NOTIFYs for each event? The current SPIRITS protocol > I-D states that once a DP fires, the subscription is terminated (it > can be resurrected again if desired). Thus this behavior dictates > that SPIRITS notifier wait for such race conditions to occur > before sending the NOTIFY. Of course, the current I-D does not take > in account multiple DPs, so this behavior may be simplistic. > > This leads us logically to your next point, which basically asks what > happens to the remaining DP when a DP from a set of DPs fire? > >> Further I would propose that the "Expires" parameter be sent seperately >> for all the DPs sent in the SUB message as they would have different >> meaning to the service and thus may have a different "time to live" >> span. > > > There are two ways to deal with this; one is as you suggest above. How- > ever, the crucial part missing in this is the dialog created by the > initial SUBS. To me, it seems logical that I associate a set of DPs > with a dialog. When the dialog expires, the set of DPs that have not > fired yet should be disarmed. Remember, the SPIRITS subscriber can > always re-arm the DPs through another SUBS. > > If we associate an expiry duration with an individual DP, I think we > may run into feature interaction problems where a DP armed for a > previous service (but did not fire) now needs to be armed for a new > service. Which service gets precedence? Furthermore, if the dialog > has expired, does it make sense to keep the DP armed. > > I belive you have already thought of that scenario as well, and hence: > >> Another "Expires2" parameter may be sent in the SUB message, which would >> would "bind" the Expires parameter associated with each DPs, indicating >> the expiry time of the complete set of subscriptions in the SUB >> message. This would mean that the DP subscriptions can expire before the >> "Expires2" parameter and all the DP subscriptions would expire when >> "Expires2" completes. > > > But I believe that this type of mechanism complicates dialog and DP > management, not to mention adding a new header to the SIP dictionary. > I would like to avoid both of these if I can. If you want the semantics > of n-1 DPs from a set being active after one fires, I think multiple > SUBS would be the best way to deal with it. > > So, my proposal is that: > > (1) We allow subscription to multiple DPs (we can scope it as a > MAY). DPs can be drawn from both halves. > (2) When any DP from this set fires, a NOTIFY is sent out immediately > (3) The NOTIFY serves to terminate the SUBS and dis-arm the > remaining DPs that did not fire. > > The XML for subscription to multiple DPs can look as follows (working > from our 'presence' for POTS line example): > > > > > 16302240216 > > > 16302240216 > > > 16302240216 > > > Note the salient change is that there can now be more than one > element. Any parameters that are part of that DP will now become > sub-elements of the element. I think that this is powerful and > extensible enough that we can subscribe to 1 DP or multiple DPs. At > the same time, we do not proscribe that "for black phone presence, thou > shalt use the following DPs..." The selection of DPs is left to the > service provider. > > Comments? > > Thanks, > > - vijay --------------040506050706020901090001 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit OK. Let me summarize the discussion that we just had:
  • It is important to be able to SUBSCRIBE to a SET of DPs and than get NOTIFY when ANY ONE of them becomes activated;
  • After subsequent NOTIFY the corresponding SUBSCRIBE is spent, regardless of the number of unencountered DPs. The SPIRITS Server needs to issue a new SUBSCRIBE in order to renew the subscription;
  • The safest way is to issue a single DP SUBSCRIBEs, so we are putting this SET of DPs SUBSCRIBE as a valid option and use MAY in the protocol specs.
Did I miss something?

Regards,
Alec

Vijay K. Gurbani wrote:
Deepak Gandotra wrote:
Alec,

You have proposed to maintain the same half of the BCSM in one SUB message but it may be desired to subscribe to both the OAA and the TAA DPs in one SUB
[...]

I believe Alec wanted to err on the side of being overly cautious;
hence the DPs belonging to one half of the BCSM.  While I agree that
such a strategy leaves no ambiguity -- after all, as far as I can
see it, the DPs naturally follow a OR mechanism; i.e. if the DPs
are armed, they trigger sequentially -- I think we can do better.

The problem with having DPs from both halves is race condition.  Let
me illustrate with an example.  Let's say that a service provider
wants to implement some kind of presence service on a POTS device
(i.e. black phone).  Thus the events of interest are OAA (caller
attempts to make a call, which indicates presence), TA (callee gets
a call, which again indicates presence) and T_Busy [TB] (callee
already on a call, which indicates presence).  So, a SUBS will contain
the three DPs: OAA, TA, and TB.

Now, let's say that a user picks up the phone and makes a call (thus
triggering OAA in O_BCSM), and at the same time, a call arrives for
the user, resulting in a T_BCSM being initialized and either TA or, most
probably TB firing.  Note that the results of the race condition itself
are not egregious (certainly not life-threatning), but how the system
deals with this is interesting (more on this later).  Also note that we
would have the same race condition if two different SUBS were sent --
one with OAA and the other with TA and TB.  So, we cannot avoid the race
condition even if we sent two SUBS.

The question now boils down to what is the behavior of the SPIRITS
notifier when such a race condition occurs?  Should it collate both
of these events into one NOTIFY and send it out?  Or should it send
out separate NOTIFYs for each event?  The current SPIRITS protocol
I-D states that once a DP fires, the subscription is terminated (it
can be resurrected again if desired).  Thus this behavior dictates
that SPIRITS notifier wait for such race conditions to occur
before sending the NOTIFY.  Of course, the current I-D does not take
in account multiple DPs, so this behavior may be simplistic.

This leads us logically to your next point, which basically asks what
happens to the remaining DP when a DP from a set of DPs fire?

Further I would propose that the "Expires" parameter be sent seperately
for all the DPs sent in the SUB message as they would have different
meaning to the service and thus may have a different "time to live" span.

There are two ways to deal with this; one is as you suggest above.  How-
ever, the crucial part missing in this is the dialog created by the
initial SUBS.  To me, it seems logical that I associate a set of DPs
with a dialog.  When the dialog expires, the set of DPs that have not
fired yet should be disarmed.  Remember, the SPIRITS subscriber can
always re-arm the DPs through another SUBS.

If we associate an expiry duration with an individual DP, I think we
may run into feature interaction problems where a DP armed for a
previous service (but did not fire) now needs to be armed for a new
service.  Which service gets precedence?  Furthermore, if the dialog
has expired, does it make sense to keep the DP armed.

I belive you have already thought of that scenario as well, and hence:

Another "Expires2" parameter may be sent in the SUB message, which would
would "bind" the Expires parameter associated with each DPs, indicating
the expiry time of the complete set of subscriptions in the SUB
message. This would mean that the DP subscriptions can expire before the
"Expires2" parameter and all the DP subscriptions would expire when
"Expires2" completes. 

But I believe that this type of mechanism complicates dialog and DP
management, not to mention adding a new header to the SIP dictionary.
I would like to avoid both of these if I can.  If you want the semantics
of n-1 DPs from a set being active after one fires, I think multiple
SUBS would be the best way to deal with it.

So, my proposal is that:

   (1) We allow subscription to multiple DPs (we can scope it as a
       MAY).  DPs can be drawn from both halves.
   (2) When any DP from this set fires, a NOTIFY is sent out immediately
   (3) The NOTIFY serves to terminate the SUBS and dis-arm the
       remaining DPs that did not fire.

The XML for subscription to multiple DPs can look as follows (working
from our 'presence' for POTS line example):

<?xml version="1.0"?>
<spirits-event>
    <DP INDPs="OAA" Mode="N">
      <CallingPartySubaddress>16302240216</CallingPartySubaddress>
    </DP>
    <DP INDPs="TA" Mode="N">
       <CalledPartySubaddress>16302240216</CalledPartySubaddress>
    </DP>
    <DP INDPs="TB" Mode="N">
       <CalledPartySubaddress>16302240216</CalledPartySubaddress>
</spirits-event>

Note the salient change is that there can now be more than one <DP>
element.  Any parameters that are part of that DP will now become
sub-elements of the <DP> element.  I think that this is powerful and
extensible enough that we can subscribe to 1 DP or multiple DPs.  At
the same time, we do not proscribe that "for black phone presence, thou
shalt use the following DPs..."  The selection of DPs is left to the
service provider.

Comments?

Thanks,

- vijay

--------------040506050706020901090001-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Jan 20 14:53:57 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29014 for ; Mon, 20 Jan 2003 14:53:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0KJv7213670; Mon, 20 Jan 2003 14:57:07 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0KJu6213657 for ; Mon, 20 Jan 2003 14:56:06 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0KJtxhN074964 for ; Mon, 20 Jan 2003 14:55:59 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 556F7443A5; Mon, 20 Jan 2003 14:55:54 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 274ED443A4 for ; Mon, 20 Jan 2003 14:55:54 -0500 (EST) Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0KJtqI56597 for ; Mon, 20 Jan 2003 14:55:52 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA05522; Mon, 20 Jan 2003 13:55:49 -0600 (CST) Message-ID: <3E2C53E9.2080309@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ucbabu Cc: SPIRITS list Subject: [SPIRITS] Re: SPIRITS digest, Vol 1 #52 - 4 msgs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 20 Jan 2003 13:54:17 -0600 Content-Transfer-Encoding: 7bit ucbabu@hss.hns.com wrote: > hi all, > I hope that we can have subscription to multiple DPs in a single SUBSCRIBE > message. > The DPs to be subscribed in a SUBSCRIBE message can be an ARRAY. In this > way we can subscribe to mulitple DPs.. > and Talking of the Notify ....Notify will be sent only for the DP hit. Great! We concur on this; please see my last email on this with details on the representation of the DPs and subsequent handling of the NOTIFY. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jan 22 12:39:30 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02016 for ; Wed, 22 Jan 2003 12:39:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0MHg1227612; Wed, 22 Jan 2003 12:42:01 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0MHfI227599 for ; Wed, 22 Jan 2003 12:41:18 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0MHfAhN094473 for ; Wed, 22 Jan 2003 12:41:10 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 7A4C2443A5; Wed, 22 Jan 2003 12:41:05 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id D12DD443A4 for ; Wed, 22 Jan 2003 12:41:02 -0500 (EST) Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0MHf0Y21503 for ; Wed, 22 Jan 2003 12:41:00 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA16301; Wed, 22 Jan 2003 11:40:58 -0600 (CST) Message-ID: <3E2ED7A6.2030604@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alec Brusilovsky Cc: Deepak Gandotra , SPIRITS list Subject: Re: [SPIRITS] Subscribing to multiple DPs References: <3E282DCF.1040506@lucent.com> <3E28339A.7070809@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 Jan 2003 11:40:54 -0600 Content-Transfer-Encoding: 7bit Alec Brusilovsky wrote: > OK. Let me summarize the discussion that we just had: > > * It is important to be able to SUBSCRIBE to a SET of DPs and than > get NOTIFY when ANY ONE of them becomes activated; > * After subsequent NOTIFY the corresponding SUBSCRIBE is spent, > regardless of the number of unencountered DPs. The SPIRITS Server > needs to issue a new SUBSCRIBE in order to renew the subscription; > * The safest way is to issue a single DP SUBSCRIBEs, so we are > putting this SET of DPs SUBSCRIBE as a valid option and use MAY in > the protocol specs. > > Did I miss something? Just to be pedantic one more thing: after the NOTIFY is sent out, the unencountered DPs must be cleared (if they are EDPs of course). Unless I hear otherwise from folks on the list, I will put this behavior in the protocol I-D. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jan 31 16:52:53 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19927 for ; Fri, 31 Jan 2003 16:52:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VLu7208641; Fri, 31 Jan 2003 16:56:07 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VLtv208628 for ; Fri, 31 Jan 2003 16:55:57 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0VLtnhN085147 for ; Fri, 31 Jan 2003 16:55:49 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 61521443A5; Fri, 31 Jan 2003 16:55:44 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 3B1E9443A4 for ; Fri, 31 Jan 2003 16:55:44 -0500 (EST) Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VLtgY84553 for ; Fri, 31 Jan 2003 16:55:42 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA17924; Fri, 31 Jan 2003 15:55:40 -0600 (CST) Message-ID: <3E3AF0CD.9020107@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SPIRITS list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [SPIRITS] Representing non-call related events Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 31 Jan 2003 15:55:25 -0600 Content-Transfer-Encoding: 7bit Folks: I want to start a discussion about how to best represent non-call related events in the SPIRITS XML payload. Non-call related events include those concerned with mobility, location, SMS, etc. Note that no DP is involved here; in fact, SPIRITS has a Event token called 'spirits-user-prof' for these types of events. One way to represent these events to have a specific element called for such SUPplementary services. Thus, in order to transform a SMS into an IM, the SUBSCRIBE payload could conceivably contain: Notify 16302240216 However, that puts us in the dubious position of specifying all the possible supplementary services in SPIRITS -- which is definitely NOT what we want to do. One way to combat that problem is to say that the value of "app" attribute is a token, the details and semantics of which are dependent on the token. How do we handle location? Maybe we can scour geopriv for some answers (see http://www.ietf.org/internet-drafts/draft-daviel-html-geo-tag-05.txt) as well as Daniel Moreno's draft on mobility events management (http://www.ietf.org/internet-drafts/draft-ietf-spirits-mobility-00.txt) Any other ideas? Any thoughts would be appreciated. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jan 31 17:22:23 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20569 for ; Fri, 31 Jan 2003 17:22:23 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VMQ1208947; Fri, 31 Jan 2003 17:26:01 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VMPS208934 for ; Fri, 31 Jan 2003 17:25:28 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0VMPKhN085421 for ; Fri, 31 Jan 2003 17:25:20 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 1A757443A5; Fri, 31 Jan 2003 17:25:15 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id E7B89443A4 for ; Fri, 31 Jan 2003 17:25:14 -0500 (EST) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VMPDI77397 for ; Fri, 31 Jan 2003 17:25:13 -0500 (EST) Received: from grimy.research.bell-labs.com (grimy.research.bell-labs.com [204.178.16.57]) by dusty.research.bell-labs.com (8.12.6/8.12.6) with SMTP id h0VMMcoJ075265 for ; Fri, 31 Jan 2003 17:22:38 -0500 (EST) Received: from mail-blue.research.att.com ([135.207.30.102]) by grimy; Fri Jan 31 17:18:25 EST 2003 Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 144CE4CF0C; Fri, 31 Jan 2003 17:21:17 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id RAA18293; Fri, 31 Jan 2003 17:21:16 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id CD50A7B4D; Fri, 31 Jan 2003 17:21:15 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Vijay K. Gurbani" Cc: SPIRITS list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20030131222115.CD50A7B4D@berkshire.research.att.com> Subject: [SPIRITS] Agenda (Was: Representing non-call related events ) Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 31 Jan 2003 17:21:15 -0500 In message <3E3AF0CD.9020107@lucent.com>, "Vijay K. Gurbani" writes: >Folks: > >I want to start a discussion about how to best represent non-call >related events in the SPIRITS XML payload. Do you want an agenda slot? Are there other topics that should be on the agenda? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jan 31 17:55:28 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21451 for ; Fri, 31 Jan 2003 17:55:27 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VMx6209232; Fri, 31 Jan 2003 17:59:06 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VMwn209219 for ; Fri, 31 Jan 2003 17:58:49 -0500 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h0VMwfhN085706 for ; Fri, 31 Jan 2003 17:58:41 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 301AB443A5; Fri, 31 Jan 2003 17:58:36 -0500 (EST) Delivered-To: spirits@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0A8AB443A4 for ; Fri, 31 Jan 2003 17:58:36 -0500 (EST) Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h0VMwVY89777 for ; Fri, 31 Jan 2003 17:58:32 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA10035; Fri, 31 Jan 2003 16:58:28 -0600 (CST) Message-ID: <3E3AFF85.3090209@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" Cc: SPIRITS list References: <20030131222115.CD50A7B4D@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [SPIRITS] Re: Agenda (Was: Representing non-call related events ) Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-BeenThere: spirits@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 31 Jan 2003 16:58:13 -0600 Content-Transfer-Encoding: 7bit Steven M. Bellovin wrote: > In message <3E3AF0CD.9020107@lucent.com>, "Vijay K. Gurbani" writes: > >>Folks: >> >>I want to start a discussion about how to best represent non-call >>related events in the SPIRITS XML payload. > > > Do you want an agenda slot? Are there other topics that should be on > the agenda? Steve: An agenda slot would be fine since there are a couple of things to discuss on the SPIRITS protocol I-D (including issue of representing non-call related events). Regarding other agenda topics -- we have implemented a portion of a SPIRITS UA based on the current work in progress I-D; I could conceivably write (depending on time) an implementation I-D and discuss that. Also, I would like some time for the ongoing security discussions. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits