From extest-admin@lists.bell-labs.com Wed Nov 1 06:05:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08137 for ; Wed, 1 Nov 2000 06:05:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C25B443E1 for ; Wed, 1 Nov 2000 05:04:57 -0500 (EST) 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.0beta6 Precedence: bulk Message-Id: <20001101100457.9C25B443E1@lists.bell-labs.com> Date: Wed, 1 Nov 2000 05:04:57 -0500 (EST) 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 QMKP http://lists.bell-labs.com/mailman/options/spirits/spirits-archive%40lists.ietf.org From spirits-admin@lists.bell-labs.com Thu Nov 2 16:06:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20510 for ; Thu, 2 Nov 2000 16:06:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 76C0A44337; Thu, 2 Nov 2000 15:07:01 -0500 (EST) Delivered-To: spirits@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id E9C1244336 for ; Thu, 2 Nov 2000 15:06:08 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Nov 2 16:05:27 EST 2000 Received: by lists.bell-labs.com (Postfix) id 4A96044380; Thu, 2 Nov 2000 15:52:18 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 0321D4437D for ; Thu, 2 Nov 2000 15:52:17 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA23936; Thu, 2 Nov 2000 14:52:13 -0600 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA23933; Thu, 2 Nov 2000 14:52:13 -0600 Message-ID: <3A01D41D.64261810@lucent.com> From: Alec Brusilovsky X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: SPIRITS list Content-Type: multipart/mixed; boundary="------------385A1F598F86888081B8098C" Subject: [SPIRITS] WG Last Call Announcement - Architecture Document 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Thu, 02 Nov 2000 14:52:45 -0600 This is a multi-part message in MIME format. --------------385A1F598F86888081B8098C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear members of the SPIRITS WG, The newly published I-D, that can be found at: http://www.ietf.org/internet-drafts/draft-ietf-spirits-architecture-00.txt is a candidate for the SPIRITS Architecture Informational RFC. Both Steve and I are encouraging online discussion of this document. Current Last call status is valid through November 22, 2000. After that date and upon reaching consensus, the resulting document will be submitted to the IESG. Regards, Alec --------------385A1F598F86888081B8098C Content-Type: text/x-vcard; charset=us-ascii; name="abrusilovsky.vcf" Content-Description: Card for Alec Brusilovsky Content-Disposition: attachment; filename="abrusilovsky.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Brusilovsky;Alec tel;fax:+1 630 713 5840 tel;work:+1 630 713 8401 x-mozilla-html:FALSE org:Lucent (jg7290000) version:2.1 email;internet:abrusilovsky@lucent.com title:MTS adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S x-mozilla-cpt:;-29888 fn:Alec Brusilovsky end:vcard --------------385A1F598F86888081B8098C-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Nov 20 05:31:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03628 for ; Mon, 20 Nov 2000 05:31:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 02E624438C; Mon, 20 Nov 2000 04:32:02 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id 7426F44338 for ; Mon, 20 Nov 2000 04:31:31 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 20 Nov 2000 10:31:06 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id KAA05765; Mon, 20 Nov 2000 10:31:05 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025699D.0039BC6D ; Mon, 20 Nov 2000 10:30:37 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Dave Hewins" To: spirits@lists.bell-labs.com Message-ID: <8025699D.0039B4A5.00@marconicomms.com> Subject: Re: [SPIRITS] WG Last Call Announcement - Architecture Document Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Mon, 20 Nov 2000 10:30:29 +0000 Alec, I have a couple of editorials for you and a suggestion. Editorials first: In section 3 numbered item 5 second line replace "SPRITS" with "SPIRITS". In section 3.1 the first sentence will be more readable if the following is used "This interface is used for sending PINT requests to the PINT server." Suggestion - In the July version of the acrchitecture paper there where a number of assumptions made in section 2 the first of which stated that : "The service subscriber has a single telephone line and a PC, which may be via a modem connected to an ISP, using the same telephone line". This assumption should be retained because it is the only real explanation of why a service subscriber needs to use the SPIRITS services because internet users with more than one phone line or who do not use dial-up access will not hit the problems that SPIRITS can solve. All the best Dave. _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Nov 20 06:50:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06053 for ; Mon, 20 Nov 2000 06:50:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEE49443DA; Mon, 20 Nov 2000 05:51:01 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from m2-pasarela3.airtel.es (unknown [212.73.32.197]) by lists.bell-labs.com (Postfix) with ESMTP id E3825443D9 for ; Mon, 20 Nov 2000 05:50:53 -0500 (EST) Subject: Re: [SPIRITS] WG Last Call Announcement - Architecture Document To: spirits@lists.bell-labs.com From: jgato@airtel.es Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.4 |June 8, 2000) at 11/20/2000 12:50:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Mon, 20 Nov 2000 12:41:33 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06053 Hi, I think that Dave's comments about the architecture is right if we just focus on the milestone services. However, I think that SPIRITS can be used for more services. One example could be to apply SPIRITS to one existing service: a web based Call Centre. A web pop up window can be displayed in the PC of a call centre assistant so that (s)he can take a decision about each incoming call (e.g. redirect the call to the desired extension, take the call for assistance, reject the call). This service would apply to subscribers with several phone lines or not using a dial-up access. Therefore, I would not be very specific in regards to the SPIRITS architecture and would leave it as it is. Best Regards, Jorge Gató >Dave's Suggestion - > >In the July version of the acrchitecture paper there where a number of assumptions made in section 2 the first of >which stated that : "The service subscriber has a single telephone line and a PC, which may be via a modem connected >to an ISP, using the same telephone line". This assumption should be retained because it is the only real explanation >of why a service subscriber needs to use the SPIRITS services because internet users with more than one phone line or >who do not use dial-up access will not hit the problems that SPIRITS can solve. _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Nov 20 10:39:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13195 for ; Mon, 20 Nov 2000 10:39:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C64E7443E1; Mon, 20 Nov 2000 09:40:01 -0500 (EST) Delivered-To: spirits@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 510894436B for ; Mon, 20 Nov 2000 09:22:09 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Nov 20 10:20:42 EST 2000 Received: by lists.bell-labs.com (Postfix) id E9D9A44380; Mon, 20 Nov 2000 10:07:32 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id 988444437D for ; Mon, 20 Nov 2000 10:07:32 -0500 (EST) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA05624; Mon, 20 Nov 2000 10:07:30 -0500 Message-ID: <3A193E30.71DBD47F@bell-labs.com> From: Igor Faynberg Reply-To: faynberg@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] WG Last Call Announcement - Architecture Document References: Content-Type: text/plain; charset=iso-8859-1 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Mon, 20 Nov 2000 10:07:28 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA13195 Maybe we could accomodate both Dave and Jorge by explaining that a single-line nuance applies to the milestone services, but is not essential to others? Igor jgato@airtel.es wrote: > > Hi, > > I think that Dave's comments about the architecture is right if we just > focus on the milestone services. > > However, I think that SPIRITS can be used for more services. One example > could be to apply SPIRITS to one existing service: a web based Call Centre. > A web pop up window can be displayed in the PC of a call centre assistant > so that (s)he can take a decision about each incoming call (e.g. redirect > the call to the desired extension, take the call for assistance, reject the > call). This service would apply to subscribers with several phone lines or > not using a dial-up access. > > Therefore, I would not be very specific in regards to the SPIRITS > architecture and would leave it as it is. > > Best Regards, > > Jorge Gató > > >Dave's Suggestion - > > > >In the July version of the acrchitecture paper there where a number of > assumptions made in section 2 the first of >which stated that : "The > service subscriber has a single telephone line and a PC, which may be via a > modem connected >to an ISP, using the same telephone line". This > assumption should be retained because it is the only real explanation >of > why a service subscriber needs to use the SPIRITS services because internet > users with more than one phone line or >who do not use dial-up access will > not hit the problems that SPIRITS can solve. > > _______________________________________________ > 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 Mon Nov 20 13:27:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17886 for ; Mon, 20 Nov 2000 13:27:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E40624435D; Mon, 20 Nov 2000 12:28:01 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from m2-pasarela3.airtel.es (unknown [212.73.32.197]) by lists.bell-labs.com (Postfix) with ESMTP id 5CB9B44349 for ; Mon, 20 Nov 2000 12:27:55 -0500 (EST) Subject: Re: [SPIRITS] WG Last Call Announcement - Architecture Document To: spirits@lists.bell-labs.com From: jgato@airtel.es Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.4 |June 8, 2000) at 11/20/2000 07:27:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Mon, 20 Nov 2000 19:27:21 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17886 Hi Igor, This is OK with me. Best Regards, Jorge Gató Igor Faynberg @lists.bell-labs.com con fecha 20/11/2000 16:07:28 Por favor, responda a faynberg@lucent.com Enviado por: spirits-admin@lists.bell-labs.com Asunto: Re: [SPIRITS] WG Last Call Announcement - Architecture Document Maybe we could accomodate both Dave and Jorge by explaining that a single-line nuance applies to the milestone services, but is not essential to others? Igor jgato@airtel.es wrote: > > Hi, > > I think that Dave's comments about the architecture is right if we just > focus on the milestone services. > > However, I think that SPIRITS can be used for more services. One example > could be to apply SPIRITS to one existing service: a web based Call Centre. > A web pop up window can be displayed in the PC of a call centre assistant > so that (s)he can take a decision about each incoming call (e.g. redirect > the call to the desired extension, take the call for assistance, reject the > call). This service would apply to subscribers with several phone lines or > not using a dial-up access. > > Therefore, I would not be very specific in regards to the SPIRITS > architecture and would leave it as it is. > > Best Regards, > > Jorge Gató > > >Dave's Suggestion - > > > >In the July version of the acrchitecture paper there where a number of > assumptions made in section 2 the first of >which stated that : "The > service subscriber has a single telephone line and a PC, which may be via a > modem connected >to an ISP, using the same telephone line". This > assumption should be retained because it is the only real explanation >of > why a service subscriber needs to use the SPIRITS services because internet > users with more than one phone line or >who do not use dial-up access will > not hit the problems that SPIRITS can solve. > > _______________________________________________ > 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 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Nov 21 04:05:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17522 for ; Tue, 21 Nov 2000 04:05:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14CB6443C9; Tue, 21 Nov 2000 03:06:01 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id 1B6B2443C8 for ; Tue, 21 Nov 2000 03:05:05 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 21 Nov 2000 08:45:33 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id IAA06414; Tue, 21 Nov 2000 08:45:33 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025699E.003014C9 ; Tue, 21 Nov 2000 08:45:10 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Dave Hewins" To: spirits@lists.bell-labs.com Message-ID: <8025699E.0030137A.00@marconicomms.com> Subject: Re: [SPIRITS] WG Last Call Announcement - Architecture Document Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Tue, 21 Nov 2000 08:45:06 +0000 Hi Igor, I like your suggestion, and agree, I could see what Jorge was getting at and was inclined to agree with his suggestion for other services. But for the milestone services the single line telephone user assumption is necessary. Dave. _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Nov 22 09:53:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03083 for ; Wed, 22 Nov 2000 09:53:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7DB3D444A4; Wed, 22 Nov 2000 08:43:01 -0500 (EST) Delivered-To: spirits@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 8C8924447F for ; Wed, 22 Nov 2000 08:30:09 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 22 09:28:52 EST 2000 Received: by lists.bell-labs.com (Postfix) id 58C4344384; Wed, 22 Nov 2000 09:15:43 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id 364464437D for ; Wed, 22 Nov 2000 09:15:38 -0500 (EST) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA13739; Wed, 22 Nov 2000 09:15:35 -0500 Message-ID: <3A1BD4F0.E98659CB@bell-labs.com> From: Igor Faynberg Reply-To: faynberg@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] WG Last Call Announcement - Architecture Document References: <8025699E.0030137A.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Wed, 22 Nov 2000 09:15:12 -0500 Content-Transfer-Encoding: 7bit Dave, Jorge, Thank you for your fast replys. I will update the text to reflect the consensus of the discussion, but, of course, the editor will be unable to submit the draft before the San Diego meeting--the deadline is past... Igor Dave Hewins wrote: > > Hi Igor, > > I like your suggestion, and agree, I could see what Jorge was getting at and > was inclined > to agree with his suggestion for other services. But for the milestone services > the single > line telephone user assumption is necessary. > > Dave. > > _______________________________________________ > 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 Tue Nov 28 09:59:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09088 for ; Tue, 28 Nov 2000 09:58:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EAC7E443A7; Tue, 28 Nov 2000 08:59:01 -0500 (EST) Delivered-To: spirits@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 9D793443A3 for ; Tue, 28 Nov 2000 08:58:59 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Nov 28 09:56:19 EST 2000 Received: by lists.bell-labs.com (Postfix) id D3CCC44380; Tue, 28 Nov 2000 09:43:58 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 29C374437D for ; Tue, 28 Nov 2000 09:43:57 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA06379; Tue, 28 Nov 2000 08:43:53 -0600 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA06376; Tue, 28 Nov 2000 08:43:52 -0600 Message-ID: <3A23C4AB.89139153@lucent.com> From: "John A. Voelker" Reply-To: jvoelker@lucent.com Organization: JG7290000 X-Mailer: Mozilla 4.74 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------3820735CB67A8B5D23156758" Subject: [SPIRITS] ID: SPIRITS Support for Location Services 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Tue, 28 Nov 2000 08:43:55 -0600 This is a multi-part message in MIME format. --------------3820735CB67A8B5D23156758 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://search.ietf.org/internet-drafts/draft-voelker-spirits-locationservice-00.txt --------------3820735CB67A8B5D23156758 Content-Type: text/plain; charset=iso-8859-1; name="draft-voelker-spirits-locationservice-00.txt" Content-Disposition: inline; filename="draft-voelker-spirits-locationservice-00.txt" Content-Transfer-Encoding: quoted-printable = Spirits Working Group J. Voelker = Internet draft Lucent Technologies = Expires June 2001 = SPIRITS Support for Location Services = Status of this Memo = This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. = Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as "work in progress." = The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. = The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. = Abstract = SPIRITS services are those originating in the PSTN and involving interactions between the PSTN and the Internet. This document describes how SPIRITS supports those aspects of location services whereby the PSTN wireless network provides location related events to internet applications requesting them. An example of such an event is a mobile station entering a pre-specified geographic zone. = 1. Introduction = SPIRITS [1] services are those originating in the PSTN and involving interactions between the PSTN and the Internet. This document describes how SPIRITS can support those aspects of location services whereby the PSTN wireless network provides location related events; for example, when a mobile station (MS - aka a cell phone) enters a pre-specified geographic zone. Because the PSTN tracks its MS customers in its conventional role of delivering telephone calls, it can potentially Voelker Internet Draft [Page 1]=0C= Spirits Support for Location Services Expires June 2001 leverage that capability to efficiently assist with certain aspects of providing advanced location services. [2] also addresses the use of SPIRITS/PINT for location. = 2. Location Services = Location services report or utilize the geographic location of one or = more mobile stations (i.e. cell phones). Location can be obtained from the PSTN wireless network (henceforth called the PSTN), from GPS equipped MSs, or via hybrids of these two mechanisms whereby information from the PSTN is delivered to a GPS equipped MS to improve the efficiency of the GPS calculations. = Examples of location services are: = a) Tell party A the location of party B. = b) Determine and deliver to a MS the location of some restaurants nearest its current location. = c) Push advertisements for a particular retail store to all MS subscribed to the service and within a half mile of that store's location. = d) Notify party A of that party B has just landed at a particular airport and turned on his/her cell phone. = e) When party B arrives at a particular airport and turns on his cell phone, ring that phone and play an announcement giving updated hotel reservation and meeting time information. Then notify party A, the source of the announcement, that it has been delivered. = f) Report the identity of every MS entering or leaving a particular specified geographic region. This is hopefully subject to appropriate privacy protections. = g) Periodically report the count of MS entering or leaving a particular = specified geographic region. = h) Track a particular MS. = 3. Wireless PSTN role in providing location services = The wireless PSTN is ideally situated to contribute to location services under certain circumstances which we discuss below. = 3.1 Location Regions Native to the PSTN = In typical cellular PSTN networks, at any given time, a MS with service = available is associated with several PSTN network entities. It is served by a particular cell site. In particular, the MS is served by a particular sector of that cell site indicating which of three Voelker Internet Draft [Page 2]=0C= Spirits Support for Location Services Expires June 2001 directional antennae is used to communicate with the MS. The cell site is served by an mobile switching center (MSC) which does call processing. The MSC is among a set served by a Visitor Location Register (VLR). The Home Location Register(HLR) has an association with the MS independent of the MS's current location. For these entities to work together, there is distributed within the cellular network information to track the MS as it moves across cell-sectors, across MSCs, and across VLRs. This tracking can be leveraged to assist with location services. For example, to recognize when a MS has been turned on at a particular airport (and presuming the MS will be initially turned at the airport after it arrived by plane while turned off), it generally suffices to recognize when that airport's local cell site or MSC begins to serve that MS. So, normal operation of the cellular PSTN provides, as a side effect, a trap for location discovery that can be efficiently used for location services. = Most natural to the PSTN are location regions defined by cell/sector, MSC control area, and VLR control area. SPIRITS interworking has the greatest potential benefit for location services which based on the entry/exit of MS from these natural (i.e. already monitored for MS presence) wireless PSTN regions. (This is not to say that other location services may not also benefit from the use of a SPIRITS interface.) = For completeness, note that the PSTN, when augmented with Mobile Positioning Centers (MPC) and Positioning Determining Equipment (PDE) can locate a MS with great precision not restricted to these "natural" regions. To accomplish this the radio signals received at multiple cell/sectors in the vicinity of the MS are compared. Also, GPS information collected at the MS itself can be used. In addition there are hybrid technologies utilizing cell site's radio reception of the MS's radio transmissions to supplement GPS calculations performed within the MS. = 3.2 Triggered location events vs. polling = If the PSTN is asked (say via PINT mechanism) to notify some entity when one of a set of MS enters a particular cell site, the PSTN need only perform a low overhead check when an MS enters that cell site. That is, it would need to check to see whether the entering MS is on the list of MS that it is monitoring. In contrast, a polling mechanism would need to undertake what is likely to be a relatively more expensive operation. Polling involves querying for the location of each MS on the list at periodic intervals. Most of these polling queries may apply to a MS not powered up, not moving, or distant from the region of interest. So, to identify when an MS enters a cell site or some other region natural to the PSTN, asking the PSTN to provide a trap or trigger based = mechanism may be more efficient than polling the MS. As the number of MS whose entry to region is of interest increases, the relative advantages of a trap mechanism relative to polling increases. = Hybrid usage of trigger and polling methods may sometimes be appropriate. For example, entry of an MS into a region that is not Voelker Internet Draft [Page 3]=0C= Spirits Support for Location Services Expires June 2001 natural to the PSTN could be monitored in a two stage manner. First use a PSTN trigger mechanism to determine when the MS entered one a set of (say) cell sites that together overlay the desired region. When this trigger occurs, use polling to determine when the MS enters the actual target region. Such polling may be controlled from within the PSTN or be controlled from the IP world with the individual polling queries using PINT protocol. = 4. SPIRITS and Location Services = SPIRITS provides a means for the PSTN to signal entities in the IP world that a PSTN monitored trigger has occurred. See Figure 1 in the appendix for the SPIRITS architecture. = Note that what we are here calling triggers are not included among the = the set of triggers conventionally defined for the intelligent network. The conventional triggers are based upon telephone call events whereas entry/exit from a region is a trigger having no necessary relation to a telephone call. = 4.1 Operation = We use the term "application" to refer to the end-user of the location information. The operational sequence would be the following: = a) The application, via PINT mechanisms, registers with the PSTN to be notified when a location trigger is encountered. The location trigger is defined in terms of a location region and some set of MS. (The nature of a location trigger is discussed further below.) = Alternatively, but of likely less utility, the registration information can be provisioned in the PSTN network. = b) The PSTN, using means outside the scope of SPIRITS (and perhaps not yet implemented in real PSTN networks) arranges to test the identity of each MS observed to enter (or perhaps exit from) from the registration defined region against the registration defined set of MS. If the registration permits (see section 4.2), prune MS from the monitored set once they have met the entry/exit criterion. = c) When a MS on the list is observed meeting a trigger criterion, the PSTN transfers the identity of that MS, with a reference to the particular registration, to the SPIRITS client. Note that transfer may be delayed if batch reporting is in effect. = d) The SPIRITS client transfer the identity of the MS, with a reference to the particular registration, to SPIRITS server. = e) The SPIRITS server transfers the identity of the MS, with a reference to the particular registration, to the application that generated the registration. = Note that the application thusly notified that a particular MS has entered the registered region, may next elect to poll for the location Voelker Internet Draft [Page 4]=0C= Spirits Support for Location Services Expires June 2001 of the MS (now known to be in the vicinity of the desired region) to determine when it enters a more tightly defined region. In general, this polling will not involve Spirits. = 4.2 Registration data = Registration data may include = a) Reference to a specification of location region. This must be understood by the PSTN in terms such as cell site or MSC area or a union of such natural regions. If a more general location region is defined, the PSTN would need additional capabilities to map that region to natural regions and to poll once entry to the natural region has been triggered. = b) Set of MS. This can be an explicit list or can be an implicit definition of a set based on specifying some characteristics of the MS to be monitored. Can also reference a provisioned set. = c) Whether the trigger involves entry, exit, or both from the region. = d) Reporting criterion. Batch or single event. If batch, what delimits a batch; e.g. periodic reporting interval, number of accumulated events, = whichever of the above occurs first, etc. = e) For a particular MS, should multiple entry (or exits) from the region be reported. Note that requiring this places extra load on the PSTN trigger monitoring function. Being able to prune the set of monitored MS as they trigger events reduces the cost of matching a triggering MS against the contracting list of monitored MS. = f) Time to live. If the TTL=3D0, then an explicit registration cancellation is needed. If the registration was done via provisioning, cancellation is probably also via provisioning. = 4.3 Returned data = The data returned may be some subset of the following: = a) set of MS (perhaps only a single member in set) meeting the trigger criterion = b) for each reported MS, whether entry or exit event = c) time stamp for each MS trigger event = d) count of MS meeting trigger criterion within some time period. In this case, probably not include the identities of particular MS. Has privacy advantages in some uses. = e) report of audio message (as specified by registration) when that audio message is played in response to the MS entering the target region. E.g. when passenger lands at airport, phone rings and message Voelker Internet Draft [Page 5]=0C= Spirits Support for Location Services Expires June 2001 is played providing updated hotel reservations. The requesting application is then notified via Spirits that the audio message was delivered. = 4.4. Privacy = Privacy is obviously of great importance in location services. It is not clear where in the architecture the Policy Enforcement Point (PEP) should be located. The PEP must permit the location of a user to be delivered only in accordance with the user's (or subscriber's) wishes expressed as a function of the particular application receiving the user's location and whether that application can associate the location with the identity of the user. (In some cases, government requirements or carrier policy may override user/subscriber preference.) = Upon initial processing of a registration by the PSTN, the list of monitored MS should be pruned to conform to privacy policy. In other words, filter for privacy before investing in the work of collecting location information that is not allowed to be delivered to the requesting application. = 5. Services provided by SPIRITS architecture = The following aspects of location services using SPIRITS can and should use the same mechanisms as other kinds of services using SPIRITS: security (including authentication and confidentiality), billing, accounting, transport of messages, binding of trigger firing reports to the associated registered request. = 6. Acknowledgments = Bill Opdyke, Margaret Ervin-Willis, and especially Kumar Vemuri provided helpful feedback on this draft. Jack Kozik suggested location as a potential SPIRITS contribution. = 6. Reference = [1] L. Slutsman (Ed.), I. Faynberg, H. Lu, M. Weissman, "The SPIRITS Architecture". , Work in Progress. = October 2000. = [2] I. Faynberg, J. Gato, H. Lu, "IN and PINT-related Requirements for SPIRITS Protocol", , work in progress. November 2000. = Voelker Internet Draft [Page 6]=0C= Spirits Support for Location Services Expires June 2001 Appendix Subscriber's IP Network IP Host _______________ .................... | _____________ | A . ________________ . | |PINT Client|*******| PINT Server |******** | |___________| | : |______________| : * | ____________ | : * : * | | SPIRITS | | B . _______*________ : * | | Server |*******|SPIRITS Proxy | : * | |___________| | : |______________| : * |_______________| .........*.......... * *C * _________________ ______*________ * | Subscriber | |SPIRITS Client | * | Telephone | | | * |_________________| |_______________| * * * * E * Line * D * ++++++++++*+++++++++++ PSTN +++*+++++++++++++++*++ * * * +-------------------+ +-----------------+ | Service Switching |*****| Service Control | | Function | SS7 | Function | +-------------------+ +-----------------+ Figure 1: SPIRITS Architecture Voelker Internet Draft [Page 7]=0C= Spirits Support for Location Services Expires June 2001 Author's Address John Voelker Lucent Technologies Room 1A-417 263 Shuman Blvd Naperville, Il. 60566-7050 E-mail: jvoelker@lucent.com Telephone: +1 630 713 5538 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph ar= e included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing th= e copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and wil= l not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT= NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WIL= L NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY O= R FITNESS FOR A PARTICULAR PURPOSE. --------------3820735CB67A8B5D23156758-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Nov 28 14:36:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18678 for ; Tue, 28 Nov 2000 14:36:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC5F54435B; Tue, 28 Nov 2000 13:37:01 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from boca-isbu-nt04.boca.unispheresolutions.com (exchange.br-unispheresolutions.com [63.111.211.43]) by lists.bell-labs.com (Postfix) with ESMTP id 1321B4438A for ; Tue, 28 Nov 2000 13:15:53 -0500 (EST) Received: by boca-isbu-nt04.boca.unispheresolutions.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 14:15:35 -0500 Message-ID: <153BDA136259D311859900A0C99B5263FA0B27@boca-isbu-nt04.boca.unispheresolutions.com> From: "Buller, Jeremy" To: "'jvoelker@lucent.com'" , spirits@lists.bell-labs.com Subject: RE: [SPIRITS] ID: SPIRITS Support for Location Services MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Tue, 28 Nov 2000 14:15:33 -0500 John, Maybe I'm confused, but I suspect that I am not. I thought the basic tenet for the differentiation of PINT and SPIRITS services was achieved via consideration of the initiator of a request. IP domain initiates = PINT PSTN domain initiates = SPIRITS I thought this included (in PINT anyway) the SUBS/NOT mechanism. If so, some of the services described would appear to be more PINT than SPIRITS like (more service discussion below). If I may just jump to section 4.1 The description leads me at least to think that this more akin to a PINT client sending a SUBS message to a PINT server. The description covered in b) would then occur in the PINT executive system. There is no need for SPIRITS involvement in this description. Messages (the response notifications) seem to be returned to the PINT client, but these are only responses to the original PINT subscription. Think of it this way, would you call a SUBS from the PSTN to the IP domain, say to inform party N when an email has been read a PINT or SPIRITS SUBS message. To me (and I'm willing to be proved wrong), it's a SPIRITS subscription 'like' mechanism, the notification returned from the IP domain allows the originating SPIRITS client to, for example, phone the subscriber and play an announcement about the email. Location Services - section 2 ----------------------------- I am also a little confused as to why there is a need for IP domain involvement in some of these services unless the intent is to move some of the mobile service data related to location out of the PSTN. If I take a closer look at each of the location services identified in 2 : a) if both party A and B are MS, why is there a need for either PINT or SPIRITS? It seems unlikely that you would propose a SPIRITS query from one MS into the IP domain which only gets 'looped back' to the PSTN domain. The other possibility of course is that your intent is that the location data is stored (probably duplicated) in the IP domain as well as the PSTN domain. i.e. SPIRITS client case - party B REGISTERS location with entity in IP domain or, PINT server case, NOTIFICATION made to IP domain PINT client related to a previous SUBSCRIPTION sent by that client. b) Well I assume the information relayed will be in a useful and intelligible format (not just a list of phone numbers). This would seem to require an IP connection from the MS. Location, I guess, would be provided either by the MS via GPS or by the mobile PSTN domain itself. So I guess I have an IP connection, a mechanism for determining location, so I would need PINT or SPIRITS for what exactly? Well, I can see that if I were the user of this service I might use PINT via my IP connection to connect me to a restaurant whose details I may be viewing (e.g. variant of click to dial). c) Push Advertisements Ouch! the often quoted possibility of spamming the PSTN rears it's ugly head. OK, so this ID states that it is a subscription service from the MS and thereby if I stretched my imagination I would still only call this a 'quasi'-SPIRITS service. Why? Because of what subs/not mechanism implies i.e. tell me when something happens or changes. In the SPIRITS case the subscription for which notifications are sought is in the IP domain but the actual change (i.e. the location) actually occurs in the PSTN domain, even if this is subsequently reported to the IP domain. So if I think about how the service might work a query to locate the adverts requires SPIRITS for what exactly? PINT may have been used to SUBS to an 'MS entering arena' notifications I suppose. d) Similar to a) above. e) Sounds like PINT to me i.e. PINT client subscribes to notification from PSTN regarding cell phone 'turning on'. Then PINT client initiates call connecting party B to an annoucement server. Next, either initiate call to party A using PINT or use some other mechanism to inform party A e.g. email. f), g) & h) Spooky! To what end exactly? I must confess to not knowing a great deal about radio, but I would have thought you could only do this either on a the 'macro' radio cell basis or rely on a GPS enabled MS to tell you where it was, in which case BTW I guess it'd be nice if I could enable and diasble this functionality as I saw fit. I would have thought other mechanisms (other than GPS that is) to more accurately determine location, such as triangulation, might prove somewhat more difficult in say, city environments, with shadows and reflections, but as I say I am no radio expert. In short there is a difference between the requirements for 1) constantly recorded real-time and 2) occasional registration of, or requesting of, location information. In 2) an end point might say 'I'm here, get me... something', or, another party may (using PINT) say, 'tell me when party N gets to here' or 'where is party N?'. The cases and services requiring 1) seem, to me at least, difficult to justify, not to mention the increase in traffic and posible data replication (in the two domains) problems that would appear to be inherent in implementing it. Apologies to all for being so verbose. Regards, Jim Buller _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Nov 29 10:42:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11911 for ; Wed, 29 Nov 2000 10:42:35 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9265744398; Wed, 29 Nov 2000 09:42:16 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from rsys000a.roke.co.uk (unknown [193.118.201.102]) by lists.bell-labs.com (Postfix) with ESMTP id B252C44341 for ; Wed, 29 Nov 2000 09:41:34 -0500 (EST) Received: from rsys002a.roke.co.uk - 193.118.192.251 by rsys000a.roke.co.uk with Microsoft SMTPSVC(5.5.1774.114.11); Wed, 29 Nov 2000 15:41:19 +0000 Received: from [193.118.192.55] (babylon.roke.co.uk [193.118.192.55]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XQS64S53; Wed, 29 Nov 2000 15:41:18 -0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: To: spirits@lists.bell-labs.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SPIRITS] Architecture Document? 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Wed, 29 Nov 2000 15:41:33 +0000 Hi Folks, A few comments on the Architecture document that have been raised by a reference in the recent PLMN location services doc. The mobile doc refers to an Architecture document , version -01. The architecture document I've seen seems to be at version -00. To confuse things slightly, that architecture document has Lev's original title (with version -01) on each page. I guess this is the source of the confusion, but if not, then I'm commenting on an out of date doc, and apologize. However, here goes... ------------ The Architecture (and the diagram it contains) doesn't seem to have changed in light of the discussions in Pittsburgh (and before): (i) It shows the "Subscribers Telephone" in the Internet (i.e. above the horizontal dashed line), even though we aren't talking about Voice over IP phones. (ii) It also shows a PINT Server *in* the Internet. This is not a good place for an Application Level Gateway ->between<- the PSTN and the Internet. It should instead be on the border, arguably level with the SPIRITS Client. (iii) Similarly, the SPIRITS system has a proxy between the client and server, whilst the PINT system doesn't. (iv) Finally, the "Executive System" and the "Initiative System" have been replaced by the SCF (with SSF connected via SS7). These are *examples* of Executives and Initiatives, not the *only possibility*. Check back through the PINT and SPIRITS meetings for statements to that effect. As this diagram is now being reproduced in other drafts (notably the mobile services one), please can this be fixed at last. It appears that the original goal of symmetry and generality that I thought we had for PINT and SPIRITS is less clear than it was; it should be easy to see whether something is a SPIRITS or a PINT service, just by looking at the message sequences; apparently not. Hey ho. ------------ -- All the best, Lawrence ---------------------------------------- | Lawrence Conroy, |50o55'15"N,1o24W| | Roke Manor Research | at home | |- lwc@roke.co.uk ---|+44 23 8023 5950| _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Nov 29 11:59:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10616 for ; Wed, 29 Nov 2000 11:59:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2EBB6443C8; Wed, 29 Nov 2000 10:56:02 -0500 (EST) Delivered-To: spirits@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id D78B94433A for ; Wed, 29 Nov 2000 10:41:00 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 29 11:38:09 EST 2000 Received: by lists.bell-labs.com (Postfix) id EE25D44380; Wed, 29 Nov 2000 11:25:50 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id B28164437D for ; Wed, 29 Nov 2000 11:25:50 -0500 (EST) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA05810; Wed, 29 Nov 2000 11:25:48 -0500 Message-ID: <3A252E0F.DB0D8B96@bell-labs.com> From: Igor Faynberg Reply-To: faynberg@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] Architecture Document? References: Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Wed, 29 Nov 2000 11:25:51 -0500 Content-Transfer-Encoding: 7bit Lawrence Conroy wrote: > > > The Architecture (and the diagram it contains) doesn't seem to have > changed in light of > the discussions in Pittsburgh (and before): Well, the document was supposed to change in view of the discussion on-line. We did NOT finish the Pittsburgh discussion at the meeting.And even if we did, the meetings do NOT make decisions. > > (i) It shows the "Subscribers Telephone" in the Internet (i.e. above > the horizontal dashed line), > even though we aren't talking about Voice over IP phones. We could re-draw that, althought I really don't see how that could cause a confusion. The document very clearly states that it has nothing to do with Voice over IP. > (ii) It also shows a PINT Server *in* the Internet. This is not a > good place for an Application > Level Gateway ->between<- the PSTN and the Internet. It should > instead be on the border, > arguably level with the SPIRITS Client. The PINT server is an Internet end-point. But if Lawrence re-drew the picture to improve the visual statement, I would happily accept. > (iii) Similarly, the SPIRITS system has a proxy between the client > and server, whilst the PINT > system doesn't. That is true. The role of the proxy is well described in the document to explain why. > (iv) Finally, the "Executive System" and the "Initiative System" have > been replaced by the SCF > (with SSF connected via SS7). Actually, nothing has been replaced. We started not with the PINT model, but with the SPIRITS model, in accordance with the SPIRITS charter. But it is true that in PINT we would need a reference to the Executive System; we could add text to that end. > These are *examples* of Executives and Initiatives, not the *only > possibility*. Check back > through the PINT and SPIRITS meetings for statements to that effect. In PINT, yes, but in SPIRITS, no. These are NOT the examples, and the SPIRITS charter makes a very clear statement to that effect. The interface between the SPIRITS client and the SPIRITS proxy is precisely the interface to carry the IN trigger information. For the more abstract things, there is an interface between the SPIRITS proxy and SPIRITS server, which is why Lev placed the SPIRITS proxy and PINT server on the same level. Thus, the "Executive System" would need to be at the level of SPIRITS Proxy. > > As this diagram is now being reproduced in other drafts (notably the > mobile services one), > please can this be fixed at last. We would need to understand WHAT needs to be fixed first. After Lev has published this diagram, at least seven months had passed, and the document was considered stable even before Pittsburgh. > > It appears that the original goal of symmetry and generality that I > thought we had for PINT > and SPIRITS is less clear than it was I respectfully disagree. "Symmetry" perhaps was a goal, but it means nothing to me without a specific context. We are not doing things for the sake of symmetry, we are doing them to make things work. As for "generality," I believe the things ought to be specific, not general. We had an Informational that clearly showed how things were implemented, and Lev came up with the architecture that captured it. But why am I speaking? Because I am stuck with the work for now! I was told that Lev is on a critical assignment right now and cannot get involved, so I sort of picked up things for him for now with the understanding that any change will be made for a solid technical reason. >... it should be easy to see > whether something is a SPIRITS > or a PINT service, just by looking at the message sequences; > apparently not. The architecture document does not address any message sequencing, so I don't see how this argument applies here. But, actually, I don't understand the issue. If a service starts in the PSTN, it is SPIRITS; if it starts in the Internet, it is PINT. Igor _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Nov 29 15:38:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24066 for ; Wed, 29 Nov 2000 15:37:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78E95443A2; Wed, 29 Nov 2000 14:38:02 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from boca-isbu-nt04.boca.unispheresolutions.com (exchange.br-unispheresolutions.com [63.111.211.43]) by lists.bell-labs.com (Postfix) with ESMTP id 3CC1A44392 for ; Wed, 29 Nov 2000 14:29:09 -0500 (EST) Received: by boca-isbu-nt04.boca.unispheresolutions.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 15:28:50 -0500 Message-ID: <153BDA136259D311859900A0C99B5263FA0B28@boca-isbu-nt04.boca.unispheresolutions.com> From: "Buller, Jeremy" To: "'faynberg@lucent.com'" , spirits@lists.bell-labs.com Subject: RE: [SPIRITS] Architecture Document? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Wed, 29 Nov 2000 15:28:45 -0500 Hi Igor, I trust you are well. Lawrence has probably gone for a PINT or two now :) so I'll take on some of these points, as I'm this side of the pond, if I may. > Lawrence Conroy wrote: > > > > > > The Architecture (and the diagram it contains) doesn't seem to have > > changed in light of > > the discussions in Pittsburgh (and before): > > Well, the document was supposed to change in view of the discussion > on-line. We did NOT finish the Pittsburgh discussion at the > meeting.And > even if we did, the meetings do NOT make decisions. I think you'll find that Lawrence was in fact eluding to not only the discussion at Pittsburgh but also prior discussions on this list and ID submissions that, now I've checked, for some reason do not seem to have found there way into the respective IETF WG pages, namely: draft-conroy-pint-acct-00.txt draft-conroy-pint-acct-00.txt draft-buller-spirits-ccib-00.txt Maybe their absense is the cause of confusion, difference of opinion. draft-buller-spirits-ccib-00.txt itself contains a slightly more generic architecture diagram (figure 2) in which one could conceivably foresee some people replacing the generic term 'Initiative system' with 'SCF' if they were so disposed. > > (i) It shows the "Subscribers Telephone" in the Internet (i.e. above > > the horizontal dashed line), > > even though we aren't talking about Voice over IP phones. > > We could re-draw that, althought I really don't see how that > could cause > a confusion. The document very clearly states that it has > nothing to do with Voice over IP. Well, Section 2.1. describing ICW, third '+' bullet point, indicates that the call may in fact be handled using VoIP. Whatever, it's a small point and I think Lawrence was just intending to provide helpful comment to aid reading by a wider audience. > > (ii) It also shows a PINT Server *in* the Internet. This is not a > > good place for an Application > > Level Gateway ->between<- the PSTN and the Internet. It should > > instead be on the border, > > arguably level with the SPIRITS Client. > > The PINT server is an Internet end-point. But if Lawrence re-drew the > picture to improve the visual statement, I would happily accept. As stated above there is another draft with another diagram. Admittedly, it only makes casual reference to the need for a proxy (more on this below). Please feel free to use or modify this as you see appropriate if necessary. Alternatively, as you suggest, perhaps Lawrence may be able to spare some time to redraw said diagram to provide clarification as the co-author of the PINT RFC, I think it might help. > > (iii) Similarly, the SPIRITS system has a proxy between the client > > and server, whilst the PINT > > system doesn't. > > That is true. The role of the proxy is well described in the > document to explain why. Would this be: -- 5. SPIRITS proxy, which is co-located with the PINT Server -- and serves as an intermediary between the SPIRITS Server -- and SPIRITS Client via the B and C interfaces, respectively. Descriptions of the B and C interface seem to imply that the the SPIRITS proxy just forwards requests and responses unless it acts as an endpoint itself or 'virtual server'. More below... > > These are *examples* of Executives and Initiatives, not the *only > > possibility*. Check back > > through the PINT and SPIRITS meetings for statements to that effect. > > In PINT, yes, but in SPIRITS, no. These are NOT the examples, and the > SPIRITS charter makes a very clear statement to that effect. The > interface between the SPIRITS client and the SPIRITS proxy is > precisely > the interface to carry the IN trigger information. For the > more abstract > things, there is an interface between the SPIRITS proxy and SPIRITS > server, which is why Lev placed the SPIRITS proxy and PINT > server on the > same level. Thus, the "Executive System" would need to be at the level > of SPIRITS Proxy. Uh? Wait a minute! My understanding was that interface D carried the IN trigger information and was BTW pretty much outside the scope of the WG. The SPIRITS client was intended to transform this into messages for the SPIRITS server (or Proxy depending on you point of view). Subsequently, this WG was only concerned with the protocol to handle the C interface. This is why I for one could not see an explicit requirement for the B interface or 'explicit' reference to a proxy. The description you've provided above seems to imply a requirement for two protocols; one for the C interface and one for the B interface? Is this correct? > > It appears that the original goal of symmetry and generality > > that I thought we had for PINT and SPIRITS is less clear > > than it was > > I respectfully disagree. "Symmetry" perhaps was a goal, but it means > nothing to me without a specific context. We are not doing things for > the sake of symmetry, we are doing them to make things work. As for > "generality," I believe the things ought to be specific, not > general. We > had an Informational that clearly showed how things were implemented, > and Lev came up with the architecture that captured it. If this is not symetric why include PINT at all? It seems to have been the source of some confusion relating to the identifying the source of specific flows. I personally thought, as Lawrence did, that PINT and SPIRITS were symetric or mirror images of each other. As for 'generality' I think Lawrence is making the point that PINT didn't really care what was in the executive system of PSTN, to all intents and purposes it could have been a text display to an operator who manually made calls or connected parties on behalf of the PINT client. SPIRITS seems to be a different animal, one that requires IN (not just triggers). As I have stated in the past I have no problem with trigger mapping happening 'somewhere' in a service description but I believe its actual implementation should be hidden behind the line that is the PSTN/IP boundary in the same way that PINT is not interested in the 'actual' implementation undertaken in the PINT executive system. It just seems a little odd to include PINT (a protocol that 'requires' no specific implementation in the PSTN) and SPIRITS (which 'requires' IN) in the same discussion. What happens to services that use a little of both?... maybe PINT and SPIRITS are, and should be, considered separately and in isolation? > The architecture document does not address any message > sequencing, so I > don't see how this argument applies here. But, actually, I don't > understand the issue. If a service starts in the PSTN, it is SPIRITS; > if it starts in the Internet, it is PINT. I think the issue is that confusion can still be seen to reign when describing services that may use functionality from PINT and/or SPIRITS. Kind regards and look forward to seeing you in San Diego, Jim Buller ---------------------------------- Unisphere Networks, 7800 Congress Avenue, Suite 100, Boca Raton, FL 33487. USA (+)1 561 981 7011 ---------------------------------- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Nov 29 17:06:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28837 for ; Wed, 29 Nov 2000 17:06:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CD94443A6; Wed, 29 Nov 2000 16:07:01 -0500 (EST) Delivered-To: spirits@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 4E0B344393 for ; Wed, 29 Nov 2000 16:06:10 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Nov 29 17:05:48 EST 2000 Received: by lists.bell-labs.com (Postfix) id CBC7B44384; Wed, 29 Nov 2000 16:52:38 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 7E0224437D for ; Wed, 29 Nov 2000 16:52:38 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA19627; Wed, 29 Nov 2000 15:52:35 -0600 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA19622; Wed, 29 Nov 2000 15:52:34 -0600 Message-ID: <3A257AD3.56B061F3@lucent.com> From: Alec Brusilovsky X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: SPIRITS list Content-Type: multipart/mixed; boundary="------------6110DC54EFAC7DBCBB4D81C5" Subject: [SPIRITS] Publishing I-Ds on this list 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Wed, 29 Nov 2000 15:53:23 -0600 This is a multi-part message in MIME format. --------------6110DC54EFAC7DBCBB4D81C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It is my duty to remind everyone that the right way to alert participants on this list about newly published I-D would be to post a POINTER to the official IETF I-D directory. Attaching the entire I-D text is clearly wrong and is taking too much bandwidth. Regards, Alec --------------6110DC54EFAC7DBCBB4D81C5 Content-Type: text/x-vcard; charset=us-ascii; name="abrusilovsky.vcf" Content-Description: Card for Alec Brusilovsky Content-Disposition: attachment; filename="abrusilovsky.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Brusilovsky;Alec tel;fax:+1 630 713 5840 tel;work:+1 630 713 8401 x-mozilla-html:FALSE org:e-Services Group;Next Generation Evolution and Architecture version:2.1 email;internet:abrusilovsky@lucent.com title:MTS adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S x-mozilla-cpt:;5312 fn:Alec Brusilovsky end:vcard --------------6110DC54EFAC7DBCBB4D81C5-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Nov 29 17:19:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03140 for ; Wed, 29 Nov 2000 17:19:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCD8E443C6; Wed, 29 Nov 2000 16:20:02 -0500 (EST) Delivered-To: spirits@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id BA62F4436C for ; Wed, 29 Nov 2000 16:19:01 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 29 17:17:49 EST 2000 Received: by lists.bell-labs.com (Postfix) id B4E5A44380; Wed, 29 Nov 2000 17:05:30 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 699874437D for ; Wed, 29 Nov 2000 17:05:30 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA24187; Wed, 29 Nov 2000 16:05:27 -0600 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA24184; Wed, 29 Nov 2000 16:05:27 -0600 Message-ID: <3A257DAA.3E10377C@lucent.com> From: "John A. Voelker" Reply-To: jvoelker@lucent.com Organization: JG7290000 X-Mailer: Mozilla 4.74 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] ID: SPIRITS Support for Location Services References: <153BDA136259D311859900A0C99B5263FA0B27@boca-isbu-nt04.boca.unispheresolutions.com> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Wed, 29 Nov 2000 16:05:30 -0600 Content-Transfer-Encoding: 7bit Jim, The main point of the I-D was that certain location services can usefully involve SPIRITS. The list of location services in Section 2 was meant to provide a view of some of the breadth of location services. Some - not all - of these example location services (c, d, e, f, g, and perhaps h) can exploit the fact the PSTN, in the course of its regular (i.e. non-location service focused) operation observes when particular MS enter particular regions (e.g. cell sites or VLR areas). These entries by particular MS into particular already monitored regions can be used like "triggers" by the PSTN. Upon the firing of those triggers, the PSTN can use SPIRITS as a conduit to the appropriate entity in the IP world interested in that event. Of course, the PSTN needs to be informed somehow which "triggers" are active (which MS for which region), and I suggested this can be done via PINT or via provisioning of the PSTN. If done by PINT, you seem to view this as the start of the service - and this is the crux of the issue. I prefer to focus on the core (vs. the "start") of the service which I see as the PSTN monitoring MS "sightings" in various natural regions and resultant trigger firing (MS enterring the region). Note that the trigger firing may follow any registration by months, may occur multiple times per registration, or may never occur despite a registration - a loose coupling. I think the core of the service is the PSTN monitoring for the triggers. The registration, although needed (unless use provsioning which is a kind of registration) seems to me somewhat loosely coupled to the trigger firing and the consequent need to report event to the IP domain. The proximate cause of the report initiation is MS presense detected by certain PSTN equipment (e.g. cell site). I don't claim to have demonstrated your viewpoint wrong, only that I look at the situation differently. What is important is that certain kinds of location tasks can be more efficiently done by this PSTN triggering mechanism than by say periodic polling (every five minutes asking the PSTN: has MS A or B or C enterred Chicago yet?). If we believe trapping or triggering for location is a useful function in some location service situations, then we need protocol mechanisms by which the PSTN can inform the IP domain of those events. The case that SPIRITS as that protocal seems to me reasonable since the core of the service involves PSTN "trigger" firing intiating an action toward the IP world. Some additional minor comments inline. Regards, John "Buller, Jeremy" wrote: > > John, > > Maybe I'm confused, but I suspect that I am not. I thought > the basic tenet for the differentiation of PINT and SPIRITS > services was achieved via consideration of the initiator > of a request. > > IP domain initiates = PINT > PSTN domain initiates = SPIRITS JV: More than one way to interpret "initiates". I tend to see the PSTN initiating a reporting action toward the IP world when the PSTN observes an event. This event may happen months after any registration. Or may never happen. You seem to see the registration as the initiation - a reasonable view, but not my preference. > > I thought this included (in PINT anyway) the SUBS/NOT > mechanism. If so, some of the services described would > appear to be more PINT than SPIRITS like (more service > discussion below). > > If I may just jump to section 4.1 The description leads > me at least to think that this more akin to a PINT client > sending a SUBS message to a PINT server. The description > covered in b) would then occur in the PINT executive system. JV: would occur in the PSTN. No need to attribute this PSTN work to a "PINT executive system." > There is no need for SPIRITS involvement in this description. > Messages (the response notifications) seem to be returned > to the PINT client, but these are only responses to the > original PINT subscription. JV: also are responses to a PSTN trigger firing some time after the registration. Think of it this way, would > you call a SUBS from the PSTN to the IP domain, say to > inform party N when an email has been read a PINT or > SPIRITS SUBS message. To me (and I'm willing to be proved > wrong), it's a SPIRITS subscription 'like' mechanism, the > notification returned from the IP domain allows the > originating SPIRITS client to, for example, phone the > subscriber and play an announcement about the email. > JV: Nice analogy. I prefer to see a SPIRITS registration for a PINT service. When the IP domain eventually observes that the email has been read, it initiates an action toward the PSTN. PINT and SPIRITS can work cooperatively. > Location Services - section 2 > ----------------------------- > I am also a little confused as to why there is a need for > IP domain involvement in some of these services unless the > intent is to move some of the mobile service data related JV: The list of location services, as I mentioned above, was intended only to describe location services per se. I agree that not all necessarily need the involvement of the IP domain. Next version of this I-D will make that clearer. > to location out of the PSTN. If I take a closer look at > each of the location services identified in 2 : > > a) if both party A and B are MS, why is there a need for > either PINT or SPIRITS? JV: I agree. Even if party A is in the IP world, the PSTN is simply providing info in immediate and direct response to a query from an IP entity. So this is not the PSTN trigger firing initiated situation that I think can use SPIRITS. It seems unlikely that you would > propose a SPIRITS query from one MS into the IP domain > which only gets 'looped back' to the PSTN domain. The other > possibility of course is that your intent is that the > location data is stored (probably duplicated) in the IP > domain as well as the PSTN domain. i.e. SPIRITS client > case - party B REGISTERS location with entity in IP > domain or, PINT server case, NOTIFICATION made to IP > domain PINT client related to a previous SUBSCRIPTION > sent by that client. > > b) Well I assume the information relayed will be in a > useful and intelligible format (not just a list of phone > numbers). This would seem to require an IP connection > from the MS. Location, I guess, would be provided either > by the MS via GPS or by the mobile PSTN domain itself. > So I guess I have an IP connection, a mechanism for > determining location, so I would need PINT or SPIRITS > for what exactly? Well, I can see that if I were the > user of this service I might use PINT via my IP > connection to connect me to a restaurant whose details > I may be viewing (e.g. variant of click to dial). > > c) Push Advertisements > Ouch! the often quoted possibility of spamming the PSTN > rears it's ugly head. OK, so this ID states that it is a > subscription service from the MS and thereby if I > stretched my imagination I would still only call this a > 'quasi'-SPIRITS service. Why? Because of what subs/not > mechanism implies i.e. tell me when something happens or > changes. In the SPIRITS case the subscription for which > notifications are sought is in the IP domain but the > actual change (i.e. the location) actually occurs in the > PSTN domain, even if this is subsequently reported to the > IP domain. So if I think about how the service might work > a query to locate the adverts requires SPIRITS for what > exactly? PINT may have been used to SUBS to an 'MS entering > arena' notifications I suppose. > > d) Similar to a) above. > > e) Sounds like PINT to me i.e. PINT client subscribes to > notification from PSTN regarding cell phone 'turning on'. > Then PINT client initiates call connecting party B to an JV: Incidentally, I was thinking of the case whereby the PSTN would automatically place the call and play out the message to party B upon noting his/her arrival. Having an IP entity initiate that call (upon learning from the PSTN on B's arrival) is also an interesting way to provide the service. Whether this ovrerall example is PINT or SPIRITS involves issues discussed above. > annoucement server. Next, either initiate call to party > A using PINT or use some other mechanism to inform party > A e.g. email. > > f), g) & h) Spooky! To what end exactly? I must confess to JV: There are some non-spooky uses for this; e.g. fleet management. > not knowing a great deal about radio, but I would have > thought you could only do this either on a the 'macro' radio > cell basis or rely on a GPS enabled MS to tell you where it > was, in which case BTW I guess it'd be nice if I could enable > and diasble this functionality as I saw fit. I would have > thought other mechanisms (other than GPS that is) to more > accurately determine location, such as triangulation, might > prove somewhat more difficult in say, city environments, > with shadows and reflections, but as I say I am no radio > expert. > > In short there is a difference between the requirements > for 1) constantly recorded real-time and 2) occasional > registration of, or requesting of, location information. > > In 2) an end point might say 'I'm here, get me... something', > or, another party may (using PINT) say, 'tell me when party N > gets to here' or 'where is party N?'. The cases and > services requiring 1) seem, to me at least, difficult to > justify, not to mention the increase in traffic and posible > data replication (in the two domains) problems that would > appear to be inherent in implementing it. > > Apologies to all for being so verbose. > > Regards, > > Jim Buller > > _______________________________________________ > 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 Wed Nov 29 18:29:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26155 for ; Wed, 29 Nov 2000 18:29:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1CEF744362; Wed, 29 Nov 2000 17:30:02 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from boca-isbu-nt04.boca.unispheresolutions.com (exchange.br-unispheresolutions.com [63.111.211.43]) by lists.bell-labs.com (Postfix) with ESMTP id 884444433A for ; Wed, 29 Nov 2000 17:25:11 -0500 (EST) Received: by boca-isbu-nt04.boca.unispheresolutions.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 18:25:03 -0500 Message-ID: <153BDA136259D311859900A0C99B5263FA0B29@boca-isbu-nt04.boca.unispheresolutions.com> From: "Buller, Jeremy" To: "'jvoelker@lucent.com'" , spirits@lists.bell-labs.com Subject: RE: [SPIRITS] ID: SPIRITS Support for Location Services MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Wed, 29 Nov 2000 18:24:56 -0500 John, Thanks for the answers/clarifications. > I don't claim to have demonstrated your viewpoint wrong, only > that I look at the situation differently. Two sides of the same coin? A parallax if you will. Reading through your responses the main point of difference appears to be the terms that we are using to describe essentially similar implementation alternatives, as well as, the broadness and use of the terms REGISTER and SUBS. Seeing as the next step would presumably be to start looking at protocol implementation alternatives perhaps it would be prudent to start thinking about a list of descriptive term definitions in order to reduce the possibility of such confusion in the future? > JV: Incidentally, I was thinking of the case whereby the > PSTN would automatically > place the call and play out the message to party B upon > noting his/her arrival. Having an IP entity initiate > that call (upon learning from the PSTN on B's arrival) > is also an interesting way to provide the service. > Whether this ovrerall example is PINT or SPIRITS involves > issues discussed above. It is indeed likely that components of PINT and SPIRITS services will need to work in a coopertaive manner in order to provide some of the 'cleverer' services. As such there is probably a list of 'things' one might expect each to provide, this is something that Lawrence Conroy and I attempted to capture in the following IDs: http://search.ietf.org/internet-drafts/draft-conroy-spirits-act-00.txt http://search.ietf.org/internet-drafts/draft-conroy-pint-act-00.txt > JV: There are some non-spooky uses for this; e.g. fleet management. What, you mean ships? ;) Kind regards, Jim Buller ---------------------------------- Unisphere Networks, 7800 Congress Avenue, Suite 100, Boca Raton, FL 33487. USA (+)1 561 981 7011 ---------------------------------- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Nov 30 09:38:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01643 for ; Thu, 30 Nov 2000 09:38:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09F4E443DC; Thu, 30 Nov 2000 08:39:01 -0500 (EST) Delivered-To: spirits@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 5177B443C7 for ; Thu, 30 Nov 2000 07:55:00 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Nov 30 08:53:00 EST 2000 Received: by lists.bell-labs.com (Postfix) id 68FD544384; Thu, 30 Nov 2000 08:40:35 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id 39AB94437D for ; Thu, 30 Nov 2000 08:40:35 -0500 (EST) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA12163; Thu, 30 Nov 2000 08:40:31 -0500 Message-ID: <3A2658D0.3C7834EC@bell-labs.com> From: Igor Faynberg Reply-To: faynberg@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Cc: "'faynberg@lucent.com'" Subject: Re: [SPIRITS] Architecture Document? References: <153BDA136259D311859900A0C99B5263FA0B28@boca-isbu-nt04.boca.unispheresolutions.com> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Thu, 30 Nov 2000 08:40:32 -0500 Content-Transfer-Encoding: 7bit Jim, Thanks for your attention and for the note. (I am still on the other side of the pond you have mentioned, typing the response while at a meeting). Anyway, here is the response "Buller, Jeremy" wrote: > > > I think you'll find that Lawrence was in fact eluding to not only > the discussion at Pittsburgh but also prior discussions on this > list and ID submissions that, now I've checked, for some reason > do not seem to have found there way into the respective IETF WG > pages, namely: > > draft-conroy-pint-acct-00.txt > draft-conroy-pint-acct-00.txt > draft-buller-spirits-ccib-00.txt > > Maybe their absense is the cause of confusion, difference of > opinion. Thee drafts are individual submissions (as are mine on PINT/IN requirements), which is why they are not on either PINT or SPIRITS page. (The I-D section of the IETF page explains the conventions of naming drafts.) As for the drafts, I read them and saw no problem with them. If in the first two drafts you change "conroy" to "ietf," I will have no problem accepting them for PINT (if Steve agrees, of course). As for SPIRITS, it is up to SPIRITS chairs to accept. You guys were supposed to work with Lev (the editor) to include what you wanted to include or change what you wanted to change. And if you disagreed, you should have said you did, and it would be better to say it earlier than later. At the meeting, as I recall, Alec and Steve asked if the Architecture document is finished, and no one has raised any objection. The the Last Call was announced, and there were specific on-line proposals made, and an agreement on changes was made. Suddenly "remembering" that you need changes after all that is a somewhat surprising action, but a perfectly legal one from the procedural point of view. It is up to the chairs to re-open a year-old discussion, and postpone the real work or declare the rough consensus and move on. > > draft-buller-spirits-ccib-00.txt itself contains a slightly > more generic architecture diagram (figure 2) in which one could > conceivably foresee some people replacing the generic term > 'Initiative system' with 'SCF' if they were so disposed. Did you discuss that with the editor? Have you proposed to include this diagram before? > Well, Section 2.1. describing ICW, third '+' bullet point, > indicates that the call may in fact be handled using VoIP. > Whatever, it's a small point and I think Lawrence was just > intending to provide helpful comment to aid reading by a > wider audience. I agree. From the agreement made on the list this week you can find that there is going to be specific text explaining the role of the telephone line. I thought this would make things clear. > > As stated above there is another draft with another diagram. > Admittedly, it only makes casual reference to the need for a > proxy (more on this below). Please feel free to use or modify > this as you see appropriate if necessary. Alternatively, as you > suggest, perhaps Lawrence may be able to spare some time to > redraw said diagram to provide clarification as the co-author > of the PINT RFC, I think it might help. As I said, if there is a better diagram, and if the editor agrees with it, I will be happy to include it in my role as a stuckee. But what I still cannot understand is why this had not been worked on with the editor before. (I am a proxy, not the editor.) > > > > (iii) Similarly, the SPIRITS system has a proxy between the client > > > and server, whilst the PINT > > > system doesn't. > > > > That is true. The role of the proxy is well described in the > > document to explain why. > Would this be: > > -- 5. SPIRITS proxy, which is co-located with the PINT Server > -- and serves as an intermediary between the SPIRITS Server > -- and SPIRITS Client via the B and C interfaces, respectively. > > Descriptions of the B and C interface seem to imply that the > the SPIRITS proxy just forwards requests and responses unless > it acts as an endpoint itself or 'virtual server'. Ah, that is an interesting question. We did our best to answer it in the requirements. > > More below... > >... > > server on the > > same level. Thus, the "Executive System" would need to be at the level > > of SPIRITS Proxy. > Uh? Wait a minute! My understanding was that interface D carried > the IN trigger information and was BTW pretty much outside the > scope of the WG. The SPIRITS client was intended to transform > this into messages for the SPIRITS server (or Proxy depending on > you point of view). Subsequently, this WG was only concerned > with the protocol to handle the C interface. This is why I for > one could not see an explicit requirement for the B interface > or 'explicit' reference to a proxy. > > The description you've provided above seems to imply a requirement > for two protocols; one for the C interface and one for the B > interface? Is this correct? Why "Uh?"? Lev's proposal in Adelaide has identified these interfaces, and we have been discussing them since then. Please read the requirements draft, which explicitly says (and has been saying it for a long time) what is happening at which interface. You may also need to re-read the Implementation RFC whence the architecture Lev has been using came. > >... > > and Lev came up with the architecture that captured it. > If this is not symetric why include PINT at all? It seems to > have been the source of some confusion relating to the identifying > the source of specific flows. I personally thought, as Lawrence > did, that PINT and SPIRITS were symetric or mirror images of each > other. The PINT was included for the reasons that have been repeated enough times not to repeat them once more. (I am afraid I will look like a mad cow chewing its mad cud.) Steve Bellovin asked me to write PINT requirements. You may disagree with them or agree with them (but one or the other, please). For sure, we could once more discuss them at the meeting--I would leave it up to the chairmen. Yes, I agree that PINT and SPIRITS are mirror images, and "Symmetric" and "Mirror Images" are good terms, but they are well defined only in the context of Geometry (and, subsequently, Microsoft Power Point). In life and in SPIRITS things are driven by functional needs, which may differ from what looks good on viewgraphs. For example, I have two legs, two arms, but only one head. Had I had two heads, I would have been much more symmetric, but much less functional, I am afraid. (Here I think you would agree with me.) > > As for 'generality' I think Lawrence is making the point that > PINT didn't really care what was in the executive system of PSTN, > to all intents and purposes it could have been a text display to an > operator who manually made calls or connected parties on behalf > of the PINT client. SPIRITS seems to be a different animal, one > that requires IN (not just triggers). Yes, but it is even more complex. In our conversation in September, Soren mentioned that he wishes to recieve a notification from IN and then immediately off-load everything to a SIP network. I strongly believe that this is a valid requirement for SPIRITS. In this case, there is no need for persistent interactions with IN (and not need for PINT). (Incidentally, here is one need for the SPIRITS proxy, which will continue when the client has been forgotten.) And then there are other options, which will require persistent communications with IN. So, we have a full spectrum of things that SPIRITS has to deal with, and this was the main reason--as Lev explained--to have three entities and two interfaces in SPIRITS. But these are two INTERFACES; whether there are two PROTOCOLS is an open question. > As I have stated in the > past I have no problem with trigger mapping happening 'somewhere' > in a service description but I believe its actual implementation > should be hidden behind the line that is the PSTN/IP boundary > in the same way that PINT is not interested in the 'actual' > implementation undertaken in the PINT executive system. > It just seems a little odd to include PINT (a protocol that > 'requires' no specific implementation in the PSTN) and SPIRITS > (which 'requires' IN) in the same discussion. What happens to > services that use a little of both?... maybe PINT and SPIRITS > are, and should be, considered separately and in isolation? First of all, PINT DOES require a specific implementation in the PSTN. It so happened that this implementation exists, as ITU-T has confirmed. Second, the relation between PINT and SPIRITS has been explored in the requirement document. > I think the issue is that confusion can still be seen to reign > when describing services that may use functionality from PINT > and/or SPIRITS. Please read the IN-PINT requirements document and see if the reign of the confusion is over. I also repeat (for the fourth time) an invitation to contribute to the overall requirements document. I asked you and Lawrence to provide the extractions from the drafts you wrote to the overall requirements RFC-to-be and work with the existing de-fact design team to ensure that the document accomodates you. Again, this is best done before the Last Call is announced, and especially before the Last Call has ended. With thanks for the discussion and best regards, Igor _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Nov 30 12:06:52 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08060 for ; Thu, 30 Nov 2000 12:06:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A95944429; Thu, 30 Nov 2000 11:07:01 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from rsys000a.roke.co.uk (unknown [193.118.201.102]) by lists.bell-labs.com (Postfix) with ESMTP id 8A77E44424 for ; Thu, 30 Nov 2000 11:06:10 -0500 (EST) Received: from rsys002a.roke.co.uk - 193.118.192.251 by rsys000a.roke.co.uk with Microsoft SMTPSVC(5.5.1774.114.11); Thu, 30 Nov 2000 17:05:59 +0000 Received: from [193.118.192.55] (babylon.roke.co.uk [193.118.192.55]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XQS644TZ; Thu, 30 Nov 2000 17:05:56 -0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: To: spirits@lists.bell-labs.com, faynberg@lucent.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SPIRITS] Archie 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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Thu, 30 Nov 2000 17:06:17 +0000 Hi folks, This list does not allow .PDF to be included, so herewith: ............. ................ . A.N.Other . .Separate End . . Client . .User Interface. .(e.g. Web . ................ . Browser) . . ............. . . . Protocol A Protocol B . . :...........: :.............: : ALG : : ALG : : e.g. Web : : e.g.Protocol: : Server : : Y Client : ........... ............. ----------- ------------- !PINT Client! ! SPIRITS ! !-----------! ! Server ! ! !-------------! PINT Service ! Protocol SPIRITS Protocol ! ! ............. ............... : optional : : optional : : PINT Proxy: :SPIRITS Proxy: : /Registrar: : /Registrar : :...........: :.............: ! ! PSP SPIRITS Protocol ! ! !-----------! !--------------! !PINT Server! !SPIRITS Client! PSTN- \/! (Gateway) !\/\/\/\/\/\/\/\/\! (Gateway) !\/\/\/ Internet ! ! ! ! Boundary !-----------! !--------------! ? ? Some Protocol Some other Protocol _____?_____ ______?_______ : Executive : : Initiative : : System : : System : :e.g. SSF, : :e.g. SSF, SCF : :SCF, etc. : : etc. : :-----------: :--------------: | | | | 0---0 GSTN Handset 0---0 / \ or MS/UE / \ ----- ----- Note: Protocol A might be used if user interface for PINT service requests is (for example) a Web form. This would be submitted to a Web Server that used an internal PINT Client to initiate a PINT Service request. It is not required (for example, a program could "talk" PSP directly). Protocol B is fairly similar; it MAY be used between an end User Interface and an Application Layer Gateway that included both a SPIRITS Server and an end node for this other program. It is not required; the SPIRITS Server may execute the requested service directly (with any needed end User Interface). Regards, Lawrence _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Nov 30 17:14:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12840 for ; Thu, 30 Nov 2000 17:14:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6821B44438; Thu, 30 Nov 2000 16:15:02 -0500 (EST) Delivered-To: spirits@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 9121644357 for ; Thu, 30 Nov 2000 16:14:55 -0500 (EST) Received: from jbj (213.89.72.157 [213.89.72.157]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKW3X561; Thu, 30 Nov 2000 23:11:33 +0100 From: =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= To: , Subject: RE: [SPIRITS] ID: SPIRITS Support for Location Services Message-ID: <002601c05b1a$b03f7540$9d4859d5@hotsip.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A257DAA.3E10377C@lucent.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.0beta6 Precedence: bulk Reply-To: spirits@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SPIRITS Working Group List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/spirits/ Date: Thu, 30 Nov 2000 23:12:53 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12840 Hi, I agree with John that SPIRITS not necessary have to deal with setting up the triggers, and that was one of my points in the presentation I did in Pittsburgh. In fact the charter clearly states that the WG shall develop an request/response protocol that originates requests in PSTN towards an IP network and expects a response back. How the requests in the "black box" below (I think Steve used this term a few times...) is initiated is clearly out of foce of this WG, and I don't see a need of mixing them up at all. Whne this protocol is finished coul maybe someone write an informational RFC how to use PINT to set up those services, or if any furter developent is needed in that protocol it should be to within a wg that is chartered to focus on that problem. I focused only on the service execution point (or trigger firing), and that is what my I-D was about. This makes sense since setup of triggers could be done in *many* different ways like calling the customer support (and they sets the triggers by magic), entering a web page that uses PINT++ etc... For those new or that didn't read my draft before the Pittsburgh meeting I would like you to have a look at it since it is an actual proposal to how the protocol could be designed, without to have to invent anything new, and to be able to re-use all services currently being developed for the SIP networks for PSTN using SPIRITS. The basic idea is to let a SIP application server also to be a SPIRITS server, without to have to change the state machine of the application server, all needed is to add support for E.164 numbers and maybe a few new headers in the messages. You find the draft at the IETF archives: http://search.ietf.org/internet-drafts/draft-bjorkner-spirits-vsua-00.txt cheers Jörgen > -----Original Message----- > From: spirits-admin@lists.bell-labs.com > [mailto:spirits-admin@lists.bell-labs.com]On Behalf Of John A. Voelker > Sent: den 29 november 2000 23:06 > To: spirits@lists.bell-labs.com > Subject: Re: [SPIRITS] ID: SPIRITS Support for Location Services > > > Jim, > > The main point of the I-D was that certain location services > can usefully > involve SPIRITS. The list of location services in Section 2 > was meant to > provide a view of some of the breadth of location services. > Some - not all - of > these example location services (c, d, e, f, g, and perhaps > h) can exploit the > fact the PSTN, in the course of its regular (i.e. > non-location service focused) > operation observes when particular MS enter particular > regions (e.g. cell sites > or VLR areas). These entries by particular MS into particular > already monitored > regions can be used like "triggers" by the PSTN. Upon the > firing of those > triggers, the PSTN can use SPIRITS as a conduit to the > appropriate entity in the > IP world interested in that event. > > Of course, the PSTN needs to be informed somehow which > "triggers" are active > (which MS for which region), and I suggested this can be done > via PINT or via > provisioning of the PSTN. If done by PINT, you seem to view > this as the start > of the service - and this is the crux of the issue. I prefer > to focus on the > core (vs. the "start") of the service which I see as the PSTN > monitoring MS > "sightings" in various natural regions and resultant trigger > firing (MS > enterring the region). Note that the trigger firing may > follow any registration > by months, may occur multiple times per registration, or may > never occur despite > a registration - a loose coupling. I think the core of the > service is the PSTN > monitoring for the triggers. The registration, although > needed (unless use > provsioning which is a kind of registration) seems to me > somewhat loosely > coupled to the trigger firing and the consequent need to > report event to the IP > domain. The proximate cause of the report initiation is MS > presense detected by > certain PSTN equipment (e.g. cell site). > > I don't claim to have demonstrated your viewpoint wrong, only > that I look at the > situation differently. > > What is important is that certain kinds of location tasks can be more > efficiently done by this PSTN triggering mechanism than by > say periodic polling > (every five minutes asking the PSTN: has MS A or B or C > enterred Chicago yet?). > If we believe trapping or triggering for location is a useful > function in some > location service situations, then we need protocol mechanisms > by which the PSTN > can inform the IP domain of those events. The case that > SPIRITS as that > protocal seems to me reasonable since the core of the service > involves PSTN > "trigger" firing intiating an action toward the IP world. > > Some additional minor comments inline. > > Regards, > > John > > "Buller, Jeremy" wrote: > > > > John, > > > > Maybe I'm confused, but I suspect that I am not. I thought > > the basic tenet for the differentiation of PINT and SPIRITS > > services was achieved via consideration of the initiator > > of a request. > > > > IP domain initiates = PINT > > PSTN domain initiates = SPIRITS > > JV: More than one way to interpret "initiates". I tend to > see the PSTN initiating a reporting action toward the IP > world when the PSTN observes an event. This event may > happen months after any registration. Or may never happen. > You seem to see the registration as the initiation - > a reasonable view, but not my preference. > > > > > I thought this included (in PINT anyway) the SUBS/NOT > > mechanism. If so, some of the services described would > > appear to be more PINT than SPIRITS like (more service > > discussion below). > > > > If I may just jump to section 4.1 The description leads > > me at least to think that this more akin to a PINT client > > sending a SUBS message to a PINT server. The description > > covered in b) would then occur in the PINT executive system. > > JV: would occur in the PSTN. No need to attribute this PSTN > work to a "PINT executive system." > > > There is no need for SPIRITS involvement in this description. > > Messages (the response notifications) seem to be returned > > to the PINT client, but these are only responses to the > > original PINT subscription. > > JV: also are responses to a PSTN trigger firing some time > after the registration. > > Think of it this way, would > > you call a SUBS from the PSTN to the IP domain, say to > > inform party N when an email has been read a PINT or > > SPIRITS SUBS message. To me (and I'm willing to be proved > > wrong), it's a SPIRITS subscription 'like' mechanism, the > > notification returned from the IP domain allows the > > originating SPIRITS client to, for example, phone the > > subscriber and play an announcement about the email. > > > > JV: Nice analogy. I prefer to see a SPIRITS > registration for a PINT service. When the IP domain > eventually observes that the email has been read, it initiates > an action toward the PSTN. PINT and SPIRITS can > work cooperatively. > > > Location Services - section 2 > > ----------------------------- > > I am also a little confused as to why there is a need for > > IP domain involvement in some of these services unless the > > intent is to move some of the mobile service data related > > JV: The list of location services, as I mentioned above, was > intended only to describe location services per se. I agree that not > all necessarily need the involvement of the IP domain. Next > version of this I-D will make that clearer. > > > to location out of the PSTN. If I take a closer look at > > each of the location services identified in 2 : > > > > a) if both party A and B are MS, why is there a need for > > either PINT or SPIRITS? > > JV: I agree. Even if party A is in the IP world, the PSTN is > simply providing info in immediate and direct response to a > query from an IP entity. So this is not the PSTN trigger > firing initiated > situation that I think can use SPIRITS. > > It seems unlikely that you would > > propose a SPIRITS query from one MS into the IP domain > > which only gets 'looped back' to the PSTN domain. The other > > possibility of course is that your intent is that the > > location data is stored (probably duplicated) in the IP > > domain as well as the PSTN domain. i.e. SPIRITS client > > case - party B REGISTERS location with entity in IP > > domain or, PINT server case, NOTIFICATION made to IP > > domain PINT client related to a previous SUBSCRIPTION > > sent by that client. > > > > b) Well I assume the information relayed will be in a > > useful and intelligible format (not just a list of phone > > numbers). This would seem to require an IP connection > > from the MS. Location, I guess, would be provided either > > by the MS via GPS or by the mobile PSTN domain itself. > > So I guess I have an IP connection, a mechanism for > > determining location, so I would need PINT or SPIRITS > > for what exactly? Well, I can see that if I were the > > user of this service I might use PINT via my IP > > connection to connect me to a restaurant whose details > > I may be viewing (e.g. variant of click to dial). > > > > c) Push Advertisements > > Ouch! the often quoted possibility of spamming the PSTN > > rears it's ugly head. OK, so this ID states that it is a > > subscription service from the MS and thereby if I > > stretched my imagination I would still only call this a > > 'quasi'-SPIRITS service. Why? Because of what subs/not > > mechanism implies i.e. tell me when something happens or > > changes. In the SPIRITS case the subscription for which > > notifications are sought is in the IP domain but the > > actual change (i.e. the location) actually occurs in the > > PSTN domain, even if this is subsequently reported to the > > IP domain. So if I think about how the service might work > > a query to locate the adverts requires SPIRITS for what > > exactly? PINT may have been used to SUBS to an 'MS entering > > arena' notifications I suppose. > > > > d) Similar to a) above. > > > > e) Sounds like PINT to me i.e. PINT client subscribes to > > notification from PSTN regarding cell phone 'turning on'. > > Then PINT client initiates call connecting party B to an > > JV: Incidentally, I was thinking of the case whereby the > PSTN would automatically > place the call and play out the message to party B upon > noting his/her arrival. Having an IP entity initiate > that call (upon learning from the PSTN on B's arrival) > is also an interesting way to provide the service. > Whether this ovrerall example is PINT or SPIRITS involves > issues discussed above. > > > annoucement server. Next, either initiate call to party > > A using PINT or use some other mechanism to inform party > > A e.g. email. > > > > f), g) & h) Spooky! To what end exactly? I must confess to > > JV: There are some non-spooky uses for this; e.g. fleet management. > > > not knowing a great deal about radio, but I would have > > thought you could only do this either on a the 'macro' radio > > cell basis or rely on a GPS enabled MS to tell you where it > > was, in which case BTW I guess it'd be nice if I could enable > > and diasble this functionality as I saw fit. I would have > > thought other mechanisms (other than GPS that is) to more > > accurately determine location, such as triangulation, might > > prove somewhat more difficult in say, city environments, > > with shadows and reflections, but as I say I am no radio > > expert. > > > > In short there is a difference between the requirements > > for 1) constantly recorded real-time and 2) occasional > > registration of, or requesting of, location information. > > > > In 2) an end point might say 'I'm here, get me... something', > > or, another party may (using PINT) say, 'tell me when party N > > gets to here' or 'where is party N?'. The cases and > > services requiring 1) seem, to me at least, difficult to > > justify, not to mention the increase in traffic and posible > > data replication (in the two domains) problems that would > > appear to be inherent in implementing it. > > > > Apologies to all for being so verbose. > > > > Regards, > > > > Jim Buller > > > > _______________________________________________ > > 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 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits