From mailman-owner@lists.bell-labs.com Thu Jun 1 05:14:42 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 ESMTP id FAA17940 for ; Thu, 1 Jun 2000 05:14:41 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 86EE744493 for ; Thu, 1 Jun 2000 05:03:34 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: spirits-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000601090334.86EE744493@lists.bell-labs.com> Date: Thu, 1 Jun 2000 05:03:34 -0400 (EDT) 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@lists.ietf.org From spirits-admin@lists.bell-labs.com Tue Jun 6 09:50:50 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 ESMTP id JAA02975 for ; Tue, 6 Jun 2000 09:50:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 734F044336; Tue, 6 Jun 2000 08:45:52 -0400 (EDT) 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 2440144336 for ; Tue, 6 Jun 2000 04:56:58 -0400 (EDT) Received: from cvis03.gpt.co.uk (cvis03.gpt.co.uk) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 6 Jun 2000 10:02:46 +0100 Received: from marconicomms.com by cvis03.gpt.co.uk with SMTP (8.8.8+Sun/cvms-25) id KAA27925; Tue, 6 Jun 2000 10:04:10 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 802568F6.0031CA14 ; Tue, 6 Jun 2000 10:03:49 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Dave Hewins" To: spirits@lists.bell-labs.com Cc: aabrusilovsky@lucent.com Message-ID: <802568F6.0031C91F.00@marconicomms.com> Date: Tue, 6 Jun 2000 10:03:58 +0100 Subject: Re: [SPIRITS] WG Last Call annoncement - Pre-SPIRITS Current Practice Document Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA02975 Hello SPIRITS WG members, I work for Marconi and have been following your SPIRITS work. I have put together a few comments on the Pre-SPIRITS Current Practice Document which may be of interest. Comments on Pre-SPIRITS implementations of PSTN initiated Services. . Comments/ requests for clarification: 1. On page 2 in bullet item 2 mentions an NEC plan to support SIP, but it is not clear if the intention is to support SIP or PINT SIP, or a SPIRITS SIP, could this be clarified. A clarification needs adding to the bullet point on whether a SPIRITS SIP will be an extension of SIP or an extension of the PINT SIP. 2. On page 3 under the bullet item "have the call handled as specified" the original source for the features described would seem to have been the Lucent paper. That paper included "intelligent profiles" and "number withheld" call disposition, however those two features are missing from the ICW service description. Would it be possible to add these two features back in, for completeness. 3. Page 9 is now the only page that has the legends for the KT flow diagrams, there are 5 such flow diagrams. The original legend per diagram was clearer; add these legends back in on a per diagram basis, for clarity during reading. 4. On pages 13 to 15, it is not made clear that the existing internet connection/phone call is cleared down before the new incoming call is connected and hence it is not clear how the modem is dropped out. Add some clarification to the section on the clear down of the original call. 5. On page 31 in bullet items 1 and 2, two messages are described which are dealing with compatibility issues related to client/server software versions. But the way these two items are described it seems that the client software on the PC checking to see if it is more up to date than the software on the server. Could this be clarified, in response to the request it is expected that the server software would be checking the client software. If this is correct perhaps the following wording may be clearer: · VersionInfo (ICW client -> SPIRITS server) Indicate the current version of ICW client software. The SPIRITS server uses this information to determine if the client software is out of date. · VersionInfoAck (SPIRITS server -> ICW client) If the VersionInfo message from an ICW client indicates to a SPIRITS server that it is an out of date version, the URL information is returned within the VersionInfoAck to for use in downloading the newer version. Also if the current version of the ICW client software is up to date what is returned in the VersionInfoAck message, is the message sent even if there is no new client software to down load? Or is the message actually returned as a confirmation that the client software is up to date? Please clarify. 6. On page 31 bullet item 6, the Calling party name is sent in 15 character format, but if not available a 16 character message "Name Unavailable" is sent. How does this work? Please clarify; is an error code specified? 7. On page 33, 1st para. This is marketing and not a technical description. Delete 1st paragraph or reword the 1st sentence as it is to boastful; try "The Telia/Nortel system aims to allow service providers to develop the services mentioned." 8. Page 33 2nd para sentence 2, is there such a word as "disrtibutivity" perhaps a rewording would help? Possibly as follows: "The features of SIP that allow distributed functioning enable these servers to be hosted, ...." 9. Page 33 section 6.2 para 2, last sentence, the original contributed text made more sense, suggest replacing "The specific depends on what service triggers are being used in the GSM network." with " The specific way to behave depends on what service triggers are being used in the GSM network.". 10. Page 35 para 1 sentence 1see comment 7. This is marketing and not a technical description. Suggest delete or reword. 11. General, there seems to be 2 versions or the abbreviation "CSN" used in this RFC, clarity would be improved if an abbreviations section was included and some means of indicating which CSN was being discussed. 12. All 4 pre-SPIRITS implementations talk about SPIRITS servers etc. but if these descriptions are about pre SPIRITS implementations then the servers could not be SPIRITS servers because there is not standardised interface etc yet. So are these implementations really pre SPIRITS implementations or SPIRITS prototypes/experiments based on ideas discussed at the SPIRITS WG and implemented prior to any standardisation. Could we have clarification on the definition of a SPIRITS server or SPIRITS prototype server indicated for each described implementation. Editorial only comments: 1. Page 1, 2nd line of Abstract, replace: "The Services in the PSTN/IN" with " the Services in the PSTN/IN". Also in the 3rd sentence change " SPIRITS-like services are those involved the interactions... " to " SPIRITS-like services are those involved in the interactions ...". 2. Page 7, section 3.4.2 1st bullet point sentence 2 replace: " With the method, the ICW... " with " With this method, the ICW... ". 3. Page 21, para 1, 2nd sentence replace: " ...OCC SCP SPA based on the Termination Attemp Trigger..." with " ...OCC SCP SPA based on the Termination Attempt Trigger.. ". Also on page 24. 4. Page 33, section 6.2, para 1, 2nd sentence replace: "...isnot... " with "...is not... ". Regards, Dave Hewins Marconi NBS Discovery Court Poole Dorset UK _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jun 7 13:06:10 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 ESMTP id NAA16206 for ; Wed, 7 Jun 2000 13:06:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 244FF443BA; Wed, 7 Jun 2000 12:55:54 -0400 (EDT) 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 11D3E44336 for ; Wed, 7 Jun 2000 12:55:52 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jun 7 13:05:45 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 55BD744344; Wed, 7 Jun 2000 12:52:36 -0400 (EDT) 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 231A544341 for ; Wed, 7 Jun 2000 12:52:36 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA15154; Wed, 7 Jun 2000 12:52:35 -0400 Message-ID: <393E7DD3.E0D88CA7@lucent.com> Date: Wed, 07 Jun 2000 12:52:35 -0400 From: Hui-Lan Lu Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; U) X-Accept-Language: zh-TW,zh-CN MIME-Version: 1.0 To: spirits@lists.bell-labs.com Cc: aabrusilovsky@lucent.com Subject: Re: [SPIRITS] WG Last Call annoncement - Pre-SPIRITS CurrentPractice Document References: <802568F6.0031C91F.00@marconicomms.com> Content-Type: text/plain; charset=iso-8859-1 Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16206 Dave, Thanks for reading the draft and commenting. My response to some of your comments follows. > 1. On page 2 in bullet item 2 mentions an NEC plan to support SIP, but it is > not clear if the intention is to support SIP or PINT SIP, or a SPIRITS SIP, > could this be clarified. A clarification needs adding to the bullet point on > whether a SPIRITS SIP will be an extension of SIP or an extension of the PINT > SIP. I would think the version of SIP that NEC plans to support is the one that is enhanced to support SPIRITS services. NEC authors please confirm it. > 2. On page 3 under the bullet item "have the call handled as specified" the > original source for the features described would seem to have been the Lucent > paper. That paper included "intelligent profiles" and "number withheld" call > disposition, however those two features are missing from the ICW service > description. Would it be possible to add these two features back in, for > completeness. The bullet on "automatic incoming call disposition" is meant to cover the two features described in Lucent's OCC draft. I guess it is not detailed enough and would be happy to expand it. > 3. Page 9 is now the only page that has the legends for the KT flow diagrams, > there are 5 such flow diagrams. The original legend per diagram was clearer; > add these legends back in on a per diagram basis, for clarity during reading. There is a slight complication. Ms. Rhim requested to delete Section 3.5 in the revised version. I would be happy to include the legend in all the flow diagrams if Ms. Rhim agrees to keep that section. Personally I find them very useful. > 5. On page 31 in bullet items 1 and 2, two messages are described which are > dealing with compatibility issues related to client/server software versions. > But the way these two items are described it seems that the client software on > the PC checking to see if it is more up to date than the software on the server. > Could this be clarified, in response to the request it is expected that the > server software would be checking the client software. If this is correct > perhaps the following wording may be clearer: > > · VersionInfo (ICW client -> SPIRITS server) > > Indicate the current version of ICW client software. The SPIRITS server > uses this information to determine if the client software is out of date. > > · VersionInfoAck (SPIRITS server -> ICW client) > > If the VersionInfo message from an ICW client indicates to a SPIRITS > server that it is an out of date version, the URL information is returned > within the VersionInfoAck to for use in downloading the newer version. > > Also if the current version of the ICW client software is up to date what is > returned in the VersionInfoAck message, is the message sent even if there is > no new client software to down load? Or is the message actually returned as > a confirmation that the client software is up to date? Please clarify. NEC, please comment. > 6. On page 31 bullet item 6, the Calling party name is sent in 15 character > format, but if not available a 16 character message "Name Unavailable" is sent. > How does this work? Please clarify; is an error code specified? NEC, please comment. > 7. On page 33, 1st para. This is marketing and not a technical description. > Delete 1st paragraph or reword the 1st sentence as it is to boastful; try "The > Telia/Nortel system aims to allow service providers to develop the services > mentioned." Telia/Nortel, please comment. > 8. Page 33 2nd para sentence 2, is there such a word as "disrtibutivity" > perhaps a rewording would help? Possibly as follows: "The features of SIP that > allow distributed functioning enable these servers to be hosted, ...." Telia/Nortel, please comment. > 9. Page 33 section 6.2 para 2, last sentence, the original contributed text > made more sense, suggest replacing "The specific depends on what service > triggers are being used in the GSM network." with " The specific way to behave > depends on what service triggers are being used in the GSM network.". Point taken. > 10. Page 35 para 1 sentence 1see comment 7. This is marketing and not a > technical description. Suggest delete or reword. Telia/Nortel, please comment. > 11. General, there seems to be 2 versions or the abbreviation "CSN" used in > this RFC, clarity would be improved if an abbreviations section was included and > some means of indicating which CSN was being discussed. I will add a section on abbreviations in the revised version. > 12. All 4 pre-SPIRITS implementations talk about SPIRITS servers etc. but if > these descriptions are about pre SPIRITS implementations then the servers could > not be SPIRITS servers because there is not standardised interface etc yet. So > are these implementations really pre SPIRITS implementations or SPIRITS > prototypes/experiments based on ideas discussed at the SPIRITS WG and > implemented prior to any standardisation. Could we have clarification on the > definition of a SPIRITS server or SPIRITS prototype server indicated for each > described implementation. The definition of a SPIRITS server is yet to be defined by the SPIRITS WG. In this draft the term should be read with the context where it is used. I can add this clarification in the beginning of the draft if it helps. Regards, Hui-Lan Lu _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jun 8 10:16:33 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 ESMTP id KAA08215 for ; Thu, 8 Jun 2000 10:16:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06891443FB; Thu, 8 Jun 2000 10:05:47 -0400 (EDT) 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 9B39D44336 for ; Thu, 8 Jun 2000 10:05:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 8 10:15:32 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 38BD544344; Thu, 8 Jun 2000 10:02:23 -0400 (EDT) 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 0673844341 for ; Thu, 8 Jun 2000 10:02:23 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA19458; Thu, 8 Jun 2000 10:02:22 -0400 Message-ID: <393FA76E.44F7AFDD@lucent.com> Date: Thu, 08 Jun 2000 10:02:22 -0400 From: Hui-Lan Lu Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; U) X-Accept-Language: zh-TW,zh-CN MIME-Version: 1.0 To: spirits@lists.bell-labs.com Cc: aabrusilovsky@lucent.com Subject: Re: [SPIRITS] WG Last Call annoncement - Pre-SPIRITS CurrentPractice Document References: <802568F6.0031C91F.00@marconicomms.com> <393E7DD3.E0D88CA7@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 7bit There is no complication as mentioned earlier after all. I misunderstood Ms. Rhim's original request, which is to delete just the detail on SIP exchanges in Section 3.5. So all flow diagrams should have a legend in the revised version of the draft. Hui-Lan Hui-Lan Lu wrote: > > 3. Page 9 is now the only page that has the legends for the KT flow diagrams, > > there are 5 such flow diagrams. The original legend per diagram was clearer; > > add these legends back in on a per diagram basis, for clarity during reading. > > There is a slight complication. Ms. Rhim requested to delete Section 3.5 in the > revised version. I would be happy to include the legend in all the flow diagrams > if Ms. Rhim agrees to keep that section. Personally I find them very useful. _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 9 03:35:25 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 ESMTP id DAA07083 for ; Fri, 9 Jun 2000 03:35:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 17BB44433A; Fri, 9 Jun 2000 03:24:59 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from TYO9.gate.nec.co.jp (TYO9-2.gate.nec.co.jp [202.247.6.44]) by lists.bell-labs.com (Postfix) with ESMTP id A374244339 for ; Fri, 9 Jun 2000 03:24:56 -0400 (EDT) Received: from mailsv.nec.co.jp (mailsv-le1 [192.168.1.90]) by TYO9.gate.nec.co.jp (8.9.3/3.7W00052210) with ESMTP id QAA22058; Fri, 9 Jun 2000 16:35:16 +0900 (JST) Received: from ssfs01.ssf.sws.abk.nec.co.jp (ssfs01.ssf.abk.nec.co.jp [10.41.130.1]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP id QAA09239; Fri, 9 Jun 2000 16:35:15 +0900 (JST) Received: from ssfis87.ssf.sws.abk.nec.co.jp (ssfis87 [10.41.140.87]) by ssfs01.ssf.sws.abk.nec.co.jp (8.9.2/3.7W/00020410) with ESMTP id QAA28382; Fri, 9 Jun 2000 16:35:15 +0900 (JST) Received: from ssf.abk.nec.co.jp (localhost [127.0.0.1]) by ssfis87.ssf.sws.abk.nec.co.jp (8.8.8+Sun/3.7W/00020411) with ESMTP id QAA00919; Fri, 9 Jun 2000 16:33:58 +0900 (JST) Message-Id: <200006090733.QAA00919@ssfis87.ssf.sws.abk.nec.co.jp> To: spirits@lists.bell-labs.com, huilanlu@lucent.com Cc: aabrusilovsky@lucent.com Subject: Re: [SPIRITS] WG Last Call annoncement - Pre-SPIRITS CurrentPractice Document From: Shinji Ago In-Reply-To: Your message of "Wed, 07 Jun 2000 12:52:35 -0400" References: <393E7DD3.E0D88CA7@lucent.com> X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Date: Fri, 09 Jun 2000 16:33:58 +0900 Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA07083 "Hui-Lan" == Hui-Lan Lu writes: |Dave, |Thanks for reading the draft and commenting. My response to some of your |comments follows. ||1. On page 2 in bullet item 2 mentions an NEC plan to support SIP, but it is ||not clear if the intention is to support SIP or PINT SIP, or a SPIRITS SIP, ||could this be clarified. A clarification needs adding to the bullet point on ||whether a SPIRITS SIP will be an extension of SIP or an extension of the PINT ||SIP. |I would think the version of SIP that NEC plans to support is the one that is |enhanced to support SPIRITS services. NEC authors please confirm it. Yes. My intention is to support a SPIRITS SIP which is enhanced and extended to support SPIRITS services by NEC. ||5. On page 31 in bullet items 1 and 2, two messages are described which are ||dealing with compatibility issues related to client/server software versions. ||But the way these two items are described it seems that the client software on ||the PC checking to see if it is more up to date than the software on the server. ||Could this be clarified, in response to the request it is expected that the ||server software would be checking the client software. If this is correct ||perhaps the following wording may be clearer: || ||,A7(B VersionInfo (ICW client -> SPIRITS server) || ||Indicate the current version of ICW client software. The SPIRITS server ||uses this information to determine if the client software is out of date. || ||,A7(B VersionInfoAck (SPIRITS server -> ICW client) || ||If the VersionInfo message from an ICW client indicates to a SPIRITS ||server that it is an out of date version, the URL information is returned ||within the VersionInfoAck to for use in downloading the newer version. || Thank you for your rewriting which is more clearer. I accept these replacement. ||Also if the current version of the ICW client software is up to date what is ||returned in the VersionInfoAck message, is the message sent even if there is ||no new client software to down load? Or is the message actually returned as ||a confirmation that the client software is up to date? Please clarify. |NEC, please comment. VersionInfoAck will be returned even if there is no new client software. In this case, the message includes the indication which the client software is up to date, and no URL information is included. ||6. On page 31 bullet item 6, the Calling party name is sent in 15 character ||format, but if not available a 16 character message "Name Unavailable" is sent. ||How does this work? Please clarify; is an error code specified? |NEC, please comment. This 15 character limitation derived from existing database scheme which is defined in the SPIRITS server. This does not mean the limitation for the CallingName message length between the SPIRITS server and the ICW client software. So if the CallingName is available, the SPIRITS server should send to the ICW Client with 15 character length. The client software will compare the the Callingname with "Name Unavailable" and "" to identify whether the Calling Name is available or not. *** Shinji Ago *** 1st Software Development Department *** Fundamental Software Engineering Division *** NEC Corporation *** ago@bp.jp.nec.com (Office Address) *** (Tel)+81-471-85-7412 (Fax)+81-471-85-7930 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 9 09:51:10 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 ESMTP id JAA11632 for ; Fri, 9 Jun 2000 09:51:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5063344337; Fri, 9 Jun 2000 09:40:43 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id 3930E443FD for ; Fri, 9 Jun 2000 03:43:36 -0400 (EDT) Received: from cvis01.gpt.co.uk (cvis01.gpt.co.uk) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 9 Jun 2000 08:52:19 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-25) id IAA11286; Fri, 9 Jun 2000 08:48:52 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 802568F9.002ADA7C ; Fri, 9 Jun 2000 08:48:04 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Dave Hewins" To: spirits@lists.bell-labs.com Message-ID: <802568F9.002AD8EC.00@marconicomms.com> Date: Fri, 9 Jun 2000 08:48:09 +0100 Subject: Re: [SPIRITS] WG Last Call annoncement - Pre-SPIRITS CurrentPractice Document Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Hi Shinji , Thank you for your answers. They make the NEC implementation far clearer. Dave. _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 9 09:51:43 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 ESMTP id JAA11659 for ; Fri, 9 Jun 2000 09:51:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9E1BB4433E; Fri, 9 Jun 2000 09:41:06 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id 68900443FD for ; Fri, 9 Jun 2000 03:46:48 -0400 (EDT) Received: from cvis01.gpt.co.uk (cvis01.gpt.co.uk) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 9 Jun 2000 08:55:35 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-25) id IAA13249; Fri, 9 Jun 2000 08:52:09 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 802568F9.002B3074 ; Fri, 9 Jun 2000 08:51:44 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Dave Hewins" To: spirits@lists.bell-labs.com Message-ID: <802568F9.002B2D54.00@marconicomms.com> Date: Fri, 9 Jun 2000 08:51:45 +0100 Subject: Re: [SPIRITS] WG Last Call annoncement - Pre-SPIRITS CurrentPractice Document Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Hi Hui-Lan, thanks for your responses to my comments, especially the second prompt response. Dave. _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 9 15:42:16 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 ESMTP id PAA18035 for ; Fri, 9 Jun 2000 15:42:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCF554433B; Fri, 9 Jun 2000 15:31:38 -0400 (EDT) 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 A21AF44338 for ; Fri, 9 Jun 2000 15:31:34 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 9 15:40:03 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1DA8444347; Fri, 9 Jun 2000 15:26:53 -0400 (EDT) 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 A0FD744345; Fri, 9 Jun 2000 15:26:52 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA02557; Fri, 9 Jun 2000 14:26:48 -0500 Cc: Lawrence Conroy , pint@lists.research.bell-labs.com, SPIRITS list Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA02553; Fri, 9 Jun 2000 14:26:47 -0500 Message-ID: <39414575.C030AC3C@lucent.com> Date: Fri, 09 Jun 2000 14:28:53 -0500 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: sip@lists.bell-labs.com Original-CC: Lawrence Conroy , pint@lists.research.bell-labs.com, SPIRITS list References: Content-Type: multipart/mixed; boundary="------------47E8D138D00E5CB71F3B136B" Subject: [SPIRITS] Re: [PINT] UDP support changed from SHOULD to MUST Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com This is a multi-part message in MIME format. --------------47E8D138D00E5CB71F3B136B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please see my comments inline. Regards, Alec Lawrence Conroy wrote: > * UDP support changed from SHOULD to MUST in SIP 2453 bis draft. > It looks like support for UDP is gradually moving from a SHOULD to a > MUST in SIP. > > In PINT we may not have that assumption. We can have a good reason > for using TCP only (inline content, security using TLS, ...), so *for > PINT* I'd prefer to leave this as a SHOULD. > I would like to add to what Lawrence is saying that some SIP applications might need a more flexible and rapid session set up than others. PINT is a good example, SPIRITS might as well be another one, assuming that the WG will decide to use SIP. > > I wonder if the move to a MUST in the core spec will cause grief for > any other extension or application. > > The key point here is ->in the core spec<- Looks like the core spec. needs to be more accommodating to the needs of extensions (PINT). SHOULD is just fine. Why break something that actually works? > > > I had the same feeling at the Interim meeting in D.C. when the > subject of "Busy Line Verification" was raised - there's a lot of > focus on VoIP, when I can easily imagine SIP being used for a much > wider set of applications even for "straight" conferences; for > example, Quake, as Dean suggests. > Let's imagine an Operator listening in on the sampled Quake audio > track that I'm conferencing. How long before the Police arrive? An > over-emphasis on VoIP can lead to bad assumptions, IMHO - SIP is much > wider than that. > -- > lwc@roke.co.uk -- +44 1794 833666 > ------------------------------------------------------------- > Herewith a pointless waste of a few lines, stating that > Roke Manor Research Limited is NOT responsible for my rantings > and that they would very much like people to sue me rather than > them if this email contains racist or sexist comments, please. > Also, I can't do anything; only our lawyers can, so speak to them. > Oh, and by the way, if our I.T. department has so mangled our > email system that this has been misdirected, beware that having > read this far, your eyes are about to fall out from reading > this highly sensitive information, unless you immediately > forget that this ever darkened your mailbox. Do it now. > ------------------------------------------------------------- > > _______________________________________________ > PINT mailing list > PINT@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/pint --------------47E8D138D00E5CB71F3B136B 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 --------------47E8D138D00E5CB71F3B136B-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Sun Jun 11 11:23:37 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 ESMTP id LAA07782 for ; Sun, 11 Jun 2000 11:23:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 401B544361; Sun, 11 Jun 2000 11:11:13 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5616144336; Sat, 10 Jun 2000 00:18:11 -0400 (EDT) Received: from dynamicsoft.com (1Cust37.tnt2.freehold.nj.da.uu.net [63.17.114.37]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA17842; Sat, 10 Jun 2000 00:29:50 -0400 (EDT) Message-ID: <3941C415.C9995130@dynamicsoft.com> Date: Sat, 10 Jun 2000 00:29:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alec Brusilovsky Cc: sip@lists.bell-labs.com, Lawrence Conroy , pint@lists.research.bell-labs.com, SPIRITS list References: <39414575.C030AC3C@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SPIRITS] Re: [SIP] Re: [PINT] UDP support changed from SHOULD to MUST Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 7bit Alec Brusilovsky wrote: > > Please see my comments inline. > > Regards, > Alec > > Lawrence Conroy wrote: > > > * UDP support changed from SHOULD to MUST in SIP 2453 bis draft. > > It looks like support for UDP is gradually moving from a SHOULD to a > > MUST in SIP. > > > > In PINT we may not have that assumption. We can have a good reason > > for using TCP only (inline content, security using TLS, ...), so *for > > PINT* I'd prefer to leave this as a SHOULD. > > > > I would like to add to what Lawrence is saying that some SIP applications > might need a more flexible and rapid session set up than others. PINT is a > good example, SPIRITS might as well be another one, assuming that the WG > will decide to use SIP. Right; both UDP and TCP are still there. You can still do TCP if you want, or just UDP, but just not ONLY TCP. > > > > > I wonder if the move to a MUST in the core spec will cause grief for > > any other extension or application. > > > > The key point here is ->in the core spec<- > > Looks like the core spec. needs to be more accommodating to the needs of > extensions (PINT). SHOULD is just fine. Why break something that actually > works? Because it doesn't - thats the problem. UA to UA interoperability is not possible in all cases unless there is a baseline transport. The "core spec" must be a workable protocol in its own right, without clarifications and specifics being defined only in extensions, as pint is. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jun 13 08:26:39 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 ESMTP id IAA04916 for ; Tue, 13 Jun 2000 08:26:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 102BC44348; Tue, 13 Jun 2000 08:15:40 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 52E394435C for ; Tue, 13 Jun 2000 08:15:38 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 13 Jun 2000 07:21:56 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 07:24:58 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1163EC32@zcard00g.ca.nortel.com> From: "Lewis Robart" To: "'spirits@lists.bell-labs.com'" Cc: aabrusilovsky@lucent.com, "'huilanlu@lucent.com'" Subject: RE: [SPIRITS] WG Last Call annoncement - Pre-SPIRITS CurrentPract ice Document Date: Tue, 13 Jun 2000 07:24:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD532.627ACF80" X-Orig: Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD532.627ACF80 Content-Type: text/plain; charset="ISO-8859-1" Thanks to Dave for his original comments and thanks to Hui-Lan for her response. Telia/Nortel are comfortable with the changes proposed as follows: * Comment 7: agree with the proposed word change; * Comment 8: agree with the proposed word change; * Comment 9: agree with the comment and Hui-Lan's response; * Comment 10: agree to reword as follows: "..., the Telia/Nortel system aims to allow the introduction of multi-network services without requiring multi-protocol support." To align with the language of comment 7; Regards, Lewis -----Original Message----- > 7. On page 33, 1st para. This is marketing and not a technical description. > Delete 1st paragraph or reword the 1st sentence as it is to boastful; try "The > Telia/Nortel system aims to allow service providers to develop the services > mentioned." Telia/Nortel, please comment. > 8. Page 33 2nd para sentence 2, is there such a word as "disrtibutivity" > perhaps a rewording would help? Possibly as follows: "The features of SIP that > allow distributed functioning enable these servers to be hosted, ...." Telia/Nortel, please comment. > 9. Page 33 section 6.2 para 2, last sentence, the original contributed text > made more sense, suggest replacing "The specific depends on what service > triggers are being used in the GSM network." with " The specific way to behave > depends on what service triggers are being used in the GSM network.". Point taken. > 10. Page 35 para 1 sentence 1see comment 7. This is marketing and not a > technical description. Suggest delete or reword. Telia/Nortel, please comment. ------_=_NextPart_001_01BFD532.627ACF80 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SPIRITS] WG Last Call annoncement - Pre-SPIRITS = CurrentPractice Document

Thanks to Dave for his original = comments and thanks to Hui-Lan for her response. Telia/Nortel are = comfortable with the changes = proposed as follows:

  • Comment 7: agree with the = proposed word change;
  • Comment 8: agree with the proposed word change;
  • Comment 9: agree with the comment and = Hui-Lan's response;
  • Comment 10: agree to reword as = follows: "..., the Telia/Nortel system aims to allow the introduction = of multi-network services without requiring multi-protocol = support." To align with the = language of comment 7;

Regards,
Lewis

      -----Original = Message-----

      > 7.   On page 33, 1st = para. This is marketing and not a technical description.
      > Delete 1st paragraph or reword = the 1st sentence as it is to boastful; try "The
      > Telia/Nortel system aims to = allow service providers to develop the services
      > mentioned."

      Telia/Nortel, please comment.

      > 8.   Page 33 2nd para = sentence 2, is there such a word as "disrtibutivity"
      > perhaps a rewording would help? = Possibly as follows:  "The features of SIP that
      > allow distributed functioning = enable these servers to be hosted, ...."

      Telia/Nortel, please comment.
       
      > 9.   Page 33 section = 6.2 para 2, last sentence, the original contributed text
      > made more sense, suggest = replacing "The specific depends on what service
      > triggers are being used in the = GSM network." with " The specific way to behave
      > depends on what service triggers = are being used in the GSM network.".

      Point taken.

      > 10.  Page 35 para 1 sentence = 1see comment 7. This is marketing and not a
      > technical description. Suggest = delete or reword.

      Telia/Nortel, please comment.
       

------_=_NextPart_001_01BFD532.627ACF80-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jun 15 01:14:20 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 ESMTP id BAA13048 for ; Thu, 15 Jun 2000 01:14:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5ED5844377; Thu, 15 Jun 2000 01:03:04 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from rcunix.kotel.co.kr (rcunix.kotel.co.kr [147.6.3.40]) by lists.bell-labs.com (Postfix) with ESMTP id CA36944336 for ; Thu, 15 Jun 2000 01:03:00 -0400 (EDT) Received: from kt.co.kr (romeo.kotel.co.kr [147.6.18.214]) by rcunix.kotel.co.kr (8.8.8H2/8.8.8) with ESMTP id OAA04305 for ; Thu, 15 Jun 2000 14:19:09 +0900 (KST) Message-ID: <39486620.6BA2095@kt.co.kr> Date: Thu, 15 Jun 2000 14:14:08 +0900 From: ȲÁø°æ Organization: =?EUC-KR?B?x9GxucXrvcU=?= X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com References: <802568F6.0031C91F.00@marconicomms.com> <393E7DD3.E0D88CA7@lucent.com> <393FA76E.44F7AFDD@lucent.com> Content-Type: multipart/mixed; boundary="------------0AC31DF15AD9D531A003A799" Subject: [SPIRITS] ASTAP session Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com This is a multi-part message in MIME format. --------------0AC31DF15AD9D531A003A799 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Dear chairman of Multimedia coordination group of Internet related session in ASTAP forum, Good afternoon ! I would like to know the session schedule and how much time is arranged for each presentation of contributor. Is it reasonable for 5~10 minutes presentation of transparencies (O.H.P) ? I hope to get your responses. Thank you, Best regards, Jinkyung Hwang Korea Telecom --------------0AC31DF15AD9D531A003A799 Content-Type: text/x-vcard; charset=EUC-KR; name="jkhwang.vcf" Content-Description: Card for ȲÁø°æ Content-Disposition: attachment; filename="jkhwang.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:;Ms. Jinkyung Hwang tel;fax:+82-2-526-6118 tel;work:+82-2-526-6830 x-mozilla-html:TRUE org:Korea Telecom;Intelligent Network Team version:2.1 email;internet:jkhwang@kt.co.kr title:Technical Staff adr;quoted-printable:;;17 Woomyun-dong Seocho-gu=0D=0ASeoul Korea;;;; x-mozilla-cpt:;-23600 fn:Ms. Jinkyung Hwang end:vcard --------------0AC31DF15AD9D531A003A799-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jun 15 01:32:36 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 ESMTP id BAA15947 for ; Thu, 15 Jun 2000 01:32:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A344A4438F; Thu, 15 Jun 2000 01:21:19 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from rcunix.kotel.co.kr (rcunix.kotel.co.kr [147.6.3.40]) by lists.bell-labs.com (Postfix) with ESMTP id E343E44338 for ; Thu, 15 Jun 2000 01:21:15 -0400 (EDT) Received: from kt.co.kr (romeo.kotel.co.kr [147.6.18.214]) by rcunix.kotel.co.kr (8.8.8H2/8.8.8) with ESMTP id OAA04612 for ; Thu, 15 Jun 2000 14:37:40 +0900 (KST) Message-ID: <39486A77.D025ED90@kt.co.kr> Date: Thu, 15 Jun 2000 14:32:39 +0900 From: ȲÁø°æ Organization: =?EUC-KR?B?x9GxucXrvcU=?= X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] ASTAP session References: <802568F6.0031C91F.00@marconicomms.com> <393E7DD3.E0D88CA7@lucent.com> <393FA76E.44F7AFDD@lucent.com> <39486620.6BA2095@kt.co.kr> Content-Type: multipart/mixed; boundary="------------EF40ECAD64C483E875E8A818" Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com This is a multi-part message in MIME format. --------------EF40ECAD64C483E875E8A818 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit I am terribly sorry for the following mis-destined mail. Please ignore it. I am sorry again.. Jinkyung Hwang "ȲÁø°æ" wrote: > Dear chairman of Multimedia coordination group of Internet related session in ASTAP > forum, > > Good afternoon ! > > I would like to know the session schedule and how much time is arranged for each > presentation of contributor. > > Is it reasonable for 5~10 minutes presentation of transparencies (O.H.P) ? > > I hope to get your responses. > > Thank you, > > Best regards, > > Jinkyung Hwang > Korea Telecom --------------EF40ECAD64C483E875E8A818 Content-Type: text/x-vcard; charset=EUC-KR; name="jkhwang.vcf" Content-Description: Card for ȲÁø°æ Content-Disposition: attachment; filename="jkhwang.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:;Ms. Jinkyung Hwang tel;fax:+82-2-526-6118 tel;work:+82-2-526-6830 x-mozilla-html:TRUE org:Korea Telecom;Intelligent Network Team version:2.1 email;internet:jkhwang@kt.co.kr title:Technical Staff adr;quoted-printable:;;17 Woomyun-dong Seocho-gu=0D=0ASeoul Korea;;;; x-mozilla-cpt:;-23600 fn:Ms. Jinkyung Hwang end:vcard --------------EF40ECAD64C483E875E8A818-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jun 29 22:18:07 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 ESMTP id WAA25530 for ; Thu, 29 Jun 2000 22:18:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B5D84434F; Thu, 29 Jun 2000 22:18:04 -0400 (EDT) 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 EE6BD44336 for ; Thu, 29 Jun 2000 22:18:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun 29 22:17:52 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A33E444348; Thu, 29 Jun 2000 22:04:42 -0400 (EDT) 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 7272444347 for ; Thu, 29 Jun 2000 22:04:42 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA20111; Thu, 29 Jun 2000 22:04:42 -0400 Message-ID: <395C0039.8D9FC578@bell-labs.com> Date: Thu, 29 Jun 2000 22:04:41 -0400 From: faynberg@bell-labs.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: SPIRITS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SPIRITS] On Joint PINT/SPIRITS Architecture Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 7bit To all in good SPIRITS: Following up on the architecture discussion led by Lev in Adelaide and, particularly, on the request from the chairmen ("esteemed chairmen!"--as Lawrence would immediately correct me) to produce the protocol requirements for the IN and PINT points of view, respectively, I have tweaked a bit the original architectural picture so as to juxtapose PINT and SPIRITS and try to fit them within the same framework. It appeared to come fairly naturally while reviewing the pre-SPIRITS implementations report. Much inspiration for what I did came from Sung-Yurn Rhim's and Jinkyung Hwang's material (which explicitly mentions PINT), but I also see it immediately consistent with what Shinji Ago, S. Moeenuddin, and S. Hadvani described (and they explicitly mention SPIRITS). The OCC material also fits perfectly well here. As for the rest, it is even easier to fit, I believe, because no specific function (PINT or SPIRITS) has been identified in that architecture. So, in the picture below, only PINT Client is seating on the User's PC (or appliance). The Interface A is what PINT has been doing (and what, in fact, has been done for PINT 1.0). Now, both PINT Server and SPIRITS Client are connected to the PSTN Service Control through the means outside of either PINT or SPIRITS scope. The PINT Server and SPIRITS Server are colocated. (Again, this is consistent with the existing implementations.) Now, this is an issue that we have never discussed, but I submit that the interface between PINT Server and SPIRITS Servers are of no interest to us. (If someone disagrees, I am ready to elaborate on this point). This leaves only one interface, B, for the SPIRITS protocol (I am not addressing the SMS and MIB-related issues). Hui-Lan and I are in the process of writing the requirements for the relation of actions on A and C, and Lev is working on the architecture, so this is an important check-point. Does anyone see anything wrong with this? Note that the only real change (comparing with the crude combination of SPIRITS and PINT architecture) is the elimination of the SPIRITS element presence at the end-user's appliance, but the PINT Client should be able to take care of whatever is needed. One question to ask here, is HOW would the PINT Client be invoked on executing the SPIRITS Server. Answering it, I understood why Christian Huitema and Lawrence Conroy have made Service Subscription a high priority item. (They brought this item up twice at the first and second SPIRITS BOF, and I remember no objection, nor did I object, although I did not fully understood the importance of it until now.) So the answer is that the PINT Client would need to explicitly subscribe or register for SPIRITS service. This is an essential requirement, indeed, and it significantly simplifies the architecture and cuts on the protocol effort. Well, enough said. The picture follows. With thanks for your attention, Igor .................. |-----------| . |-----------| . C |PINT Client| <---- A ------>. |PINT Server| <------------> PSTN |-----------| . |-----------| . Service . | . Control . |---------| . D ^ . | SPIRITS | . |-----|-----| . | Server | <---- B ---->| SPIRITS | . |---------| . | Client | .................. |-----------| _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jun 29 23:32: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 ESMTP id XAA27408 for ; Thu, 29 Jun 2000 23:32:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B352D44341; Thu, 29 Jun 2000 23:32:58 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by lists.bell-labs.com (Postfix) with ESMTP id CFBED44336 for ; Thu, 29 Jun 2000 23:32:54 -0400 (EDT) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id MAA18053 for ; Fri, 30 Jun 2000 12:32:50 +0900 (JST) (envelope-from makinae.naoto@lab.ntt.co.jp) Received: from ima.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/06/05/00) with ESMTP id MAA18865 for ; Fri, 30 Jun 2000 12:32:46 +0900 (JST) (envelope-from makinae.naoto@lab.ntt.co.jp) Received: from idc (ksk-p22.pflab.ecl.ntt.co.jp [129.60.18.196]) by ima.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id MAA16680 for ; Fri, 30 Jun 2000 12:32:45 +0900 (JST) From: "Naoto MAKINAE" To: Subject: RE: [SPIRITS] On Joint PINT/SPIRITS Architecture Date: Fri, 30 Jun 2000 12:34:44 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <395C0039.8D9FC578@bell-labs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor and All, > To all in good SPIRITS: <> > So, in the picture below, only PINT Client is seating on the User's PC (or > appliance). The Interface A is what PINT has been doing (and what, in fact, has > been done for PINT 1.0). Now, both PINT Server and SPIRITS Client are connected > to the PSTN Service Control through the means outside of either PINT or SPIRITS > scope. > The PINT Server and SPIRITS Server are colocated. (Again, this is consistent > with the existing implementations.) I see some problems with the proposed picture: - The interface C, which connects a PINT server and PSTN/IN, is outside the scope of PINT. PINT does not specifiy the interface C. - A SPIRITS client may co-reside with PSTN/IN. The interface B and D are not necessarily distinct. - A PINT client is defined to be an "Internet host that sends requests for invocation of a PINT Service." Since a SPIRITS service such as ICW is not a PINT service, the PINT client is not supposed to support SPIRITS services. There must be another user PC that can communicate with the SPIRITS server and handle SPIRITS services. Or "PINT client" must be changed to a more generic term such as "User PC." I assume the latter would be better. > Now, this is an issue that we have never discussed, but I submit that the > interface between PINT Server and SPIRITS Servers are of no interest to us. (If Agreed. The interface between PINT Server and SPIRITS Server is of no interest. > someone disagrees, I am ready to elaborate on this point). This leaves only one > interface, B, for the SPIRITS protocol (I am not addressing the SMS and > MIB-related > issues). The interface A between PINT Client and PINT Server is defined in RFC2848 ("The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services"), and does not support SPIRITS services. The interface A needs enhancement. > Hui-Lan and I are in the process of writing the requirements for the relation > of actions on A and C, and Lev is working on the architecture, so this is an > important check-point. Does anyone see anything wrong with this? Since "C" is between PINT Server and PSTN/IN, you are going to specify the interface for the PINT services. Is it right? > Note that the only real change (comparing with the crude combination of SPIRITS > and PINT architecture) is the elimination of the SPIRITS element presence at the > end-user's appliance, but the PINT Client should be able to take care of > whatever is needed. One question to ask here, is HOW would the PINT Client be > invoked on executing the SPIRITS Server. > > Answering it, I understood why Christian Huitema and Lawrence Conroy have made > Service Subscription a high priority item. (They brought this item up twice at > the first and second SPIRITS BOF, and I remember no objection, nor did I object, > although I did not fully understood the importance of it until now.) So the > answer is that the PINT Client would need to explicitly subscribe or register > for SPIRITS service. This is an essential requirement, indeed, and it > significantly simplifies the architecture and cuts on the protocol effort. Agreed. Harmonization of PINT and SPIRITS would be beneficial. Unification would be much better, if possible. naoto -- Naoto MAKINAE Information Sharing Platform Laboratories Nippon Telegraph and Telephone Corporation Email:makinae.naoto@lab.ntt.co.jp Phone:+81-422-59-4167 Fax:+81-422-37-7441 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 30 05:03:18 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 ESMTP id FAA11790 for ; Fri, 30 Jun 2000 05:03:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14E3344341; Fri, 30 Jun 2000 05:03:16 -0400 (EDT) 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 CBF8744336 for ; Fri, 30 Jun 2000 05:03:13 -0400 (EDT) Received: from jbj (212.28.214.214 [212.28.214.214]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NAVVYQZX; Fri, 30 Jun 2000 10:58:43 +0200 From: =?iso-8859-1?B?SvZyZ2VuIEJq9nJrbmVy?= To: Subject: RE: [SPIRITS] On Joint PINT/SPIRITS Architecture Date: Fri, 30 Jun 2000 11:02:10 +0200 Message-ID: <001001bfe271$e0c74200$d6d61cd4@swipnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.00.2314.1300 Importance: Normal In-Reply-To: <395C0039.8D9FC578@bell-labs.com> Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi, To allow for the user client (referred to as PINT client in Igor's mail) to be able to deal with the event notifications generated from the Spirits server must there probably be some extensions to PINT. Therefore would it probably be appropriate to call this entity something else, so people don't lock their mind's to certain functionality. Maybe will we end up with something like PINT V2... I am not sure that someone implementing a SPIRITS service wants to implement everything described in the PINT RFC, but nothing prevents a SPIRITS user agent (more neutral name, for the entity the user is having installed on his device) to be co-located with a PINT client in a end users device (note that I am not restricting it to be a computer to avoid a certain service focus). I think that the new subscribe/notify extensions to SIP should be reviewed if they could be used for this purpose. Therefore might there be appropriate to define a SPIRITS extension to SIP, which reuses the expertise and experiences from PINT. Otherwise would it be need for an extension to PINT, since for example addition of hove to pass back information to the SPRITS server has to be extended. For example an event notifying a SPIRITS user agent that a call is being set up might want let the user to redirect the call before instead of answering. This information must be sent back to the SPIRITS server in either the SDP of a 200, or maybe more appropriate in a 302 moved temporarily. I also think that the D interface is dependent of the voice network which the SPIRITS server is connected to, and is an implementation issue, or a question for those who is developing voice network standards (read ITU for the PSTN case, 3GPP for 3G networks). What do you think of the following comparison with SIP, the SPIRITS user agent is similar to a SIP user agent, which will need some user feedback. Some logic, acting on a users behalf, could be place in a SIP server, which the user belongs to. In the SPIRITS case would this be the SPIRITS server. Maybe I should take some time to write down my ideas in a draft? /Jörgen -----Original Message----- From: spirits-admin@lists.bell-labs.com [mailto:spirits-admin@lists.bell-labs.com]On Behalf Of faynberg@bell-labs.com Sent: den 30 juni 2000 04:05 To: SPIRITS Subject: [SPIRITS] On Joint PINT/SPIRITS Architecture To all in good SPIRITS: Following up on the architecture discussion led by Lev in Adelaide and, particularly, on the request from the chairmen ("esteemed chairmen!"--as Lawrence would immediately correct me) to produce the protocol requirements for the IN and PINT points of view, respectively, I have tweaked a bit the original architectural picture so as to juxtapose PINT and SPIRITS and try to fit them within the same framework. It appeared to come fairly naturally while reviewing the pre-SPIRITS implementations report. Much inspiration for what I did came from Sung-Yurn Rhim's and Jinkyung Hwang's material (which explicitly mentions PINT), but I also see it immediately consistent with what Shinji Ago, S. Moeenuddin, and S. Hadvani described (and they explicitly mention SPIRITS). The OCC material also fits perfectly well here. As for the rest, it is even easier to fit, I believe, because no specific function (PINT or SPIRITS) has been identified in that architecture. So, in the picture below, only PINT Client is seating on the User's PC (or appliance). The Interface A is what PINT has been doing (and what, in fact, has been done for PINT 1.0). Now, both PINT Server and SPIRITS Client are connected to the PSTN Service Control through the means outside of either PINT or SPIRITS scope. The PINT Server and SPIRITS Server are colocated. (Again, this is consistent with the existing implementations.) Now, this is an issue that we have never discussed, but I submit that the interface between PINT Server and SPIRITS Servers are of no interest to us. (If someone disagrees, I am ready to elaborate on this point). This leaves only one interface, B, for the SPIRITS protocol (I am not addressing the SMS and MIB-related issues). Hui-Lan and I are in the process of writing the requirements for the relation of actions on A and C, and Lev is working on the architecture, so this is an important check-point. Does anyone see anything wrong with this? Note that the only real change (comparing with the crude combination of SPIRITS and PINT architecture) is the elimination of the SPIRITS element presence at the end-user's appliance, but the PINT Client should be able to take care of whatever is needed. One question to ask here, is HOW would the PINT Client be invoked on executing the SPIRITS Server. Answering it, I understood why Christian Huitema and Lawrence Conroy have made Service Subscription a high priority item. (They brought this item up twice at the first and second SPIRITS BOF, and I remember no objection, nor did I object, although I did not fully understood the importance of it until now.) So the answer is that the PINT Client would need to explicitly subscribe or register for SPIRITS service. This is an essential requirement, indeed, and it significantly simplifies the architecture and cuts on the protocol effort. Well, enough said. The picture follows. With thanks for your attention, Igor .................. |-----------| . |-----------| . C |PINT Client| <---- A ------>. |PINT Server| <------------> PSTN |-----------| . |-----------| . Service . | . Control . |---------| . D ^ . | SPIRITS | . |-----|-----| . | Server | <---- B ---->| SPIRITS | . |---------| . | Client | .................. |-----------| _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 30 10:38:05 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 ESMTP id KAA18424 for ; Fri, 30 Jun 2000 10:38:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 951F54434F; Fri, 30 Jun 2000 10:38:04 -0400 (EDT) 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 87B9344336 for ; Fri, 30 Jun 2000 10:38:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 30 10:37:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2189F44348; Fri, 30 Jun 2000 10:23:57 -0400 (EDT) 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 E797E44347 for ; Fri, 30 Jun 2000 10:23:56 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA17514; Fri, 30 Jun 2000 10:23:56 -0400 Message-ID: <395CAD7A.E27E5B84@bell-labs.com> Date: Fri, 30 Jun 2000 10:23:54 -0400 From: faynberg@bell-labs.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [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] On Joint PINT/SPIRITS Architecture References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 7bit Naoto, This was a quick and detailed response! My replies are in-line, and I am happy to observe that we seem to be in full agreement so far, as far as I can see. I am very glad you are back! Igor Naoto MAKINAE wrote: > > Igor and All, > > > To all in good SPIRITS: > > <> > > > So, in the picture below, only PINT Client is seating on the User's PC (or > > appliance). The Interface A is what PINT has been doing (and what, in fact, has > > been done for PINT 1.0). Now, both PINT Server and SPIRITS Client are connected > > to the PSTN Service Control through the means outside of either PINT or SPIRITS > > scope. > > The PINT Server and SPIRITS Server are colocated. (Again, this is consistent > > with the existing implementations.) > > I see some problems with the proposed picture: > > - The interface C, which connects a PINT server and PSTN/IN, is outside the > scope of PINT. PINT does not specifiy the interface C. Absolutely. I guess there was a misunderstanding? (I never said C was PINT's, only A). > - A SPIRITS client may co-reside with PSTN/IN. The interface B and D are not > necessarily distinct. I think you mean C and D? If so, we are in absolute agreement again. (Especially, regarding the point of SPIRITS client co-residing with Service Control.) > - A PINT client is defined to be an "Internet host that sends requests for > invocation of a PINT Service." Since a SPIRITS service such as ICW is > not a PINT service, the PINT client is not supposed to support > SPIRITS services. Yes, that is true, and it is not PINT 1.0 that is being mentioned here. If anything, it is the future PINT that is referred to. The idea of service subscription has been brought up by Christian more than a year ago, and in private discussions we thought this would be a new PINT service (or rather building block). >There must be another user PC that can communicate with the SPIRITS > server and handle SPIRITS services. Or "PINT client" must be changed to a more > generic term such as "User PC." I assume the latter would be better. I would not argue with the terminology here. Yes, we can change it. But then we will need to consider two interfaces in SPIRITS, and the issue of PINT/SPIRITS interworking would become convoluted. For me, to whom the esteemed chairmen entrusted the first shot at the PINT-to-SPIRITS interworking requirements, it is much easier to get at this chicken-and-egg problem by dividing it into independent pieces. > > > ... > > The interface A between PINT Client and PINT Server is defined in RFC2848 > ("The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone > Call Services"), and does not support SPIRITS services. The interface A needs > enhancement. Right. This is the future interface "A" I am talking about. > > Since "C" is between PINT Server and PSTN/IN, you are going to specify > the interface for the PINT services. Is it right? I am afraid I did not understand this question. "C" is out of scope of the IETF (and, I suspect, you would agree with me that PINT server should be co-located with Service Control). > > > > > Agreed. Harmonization of PINT and SPIRITS would be beneficial. > Unification would be much better, if possible. Well, PINT building blocks deal with what starts on the IP side, SPIRITS ones with what starts at the PSTN side. Put together... This is why I attempted to sort out things the way I did. Respectfully, Igor _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 30 11:00:11 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 ESMTP id LAA18782 for ; Fri, 30 Jun 2000 11:00:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D07A44363; Fri, 30 Jun 2000 11:00:05 -0400 (EDT) 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 3979F44336 for ; Fri, 30 Jun 2000 11:00:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 30 10:58:33 EDT 2000 Received: by lists.bell-labs.com (Postfix) id B964944348; Fri, 30 Jun 2000 10:45:23 -0400 (EDT) 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 6F01444347 for ; Fri, 30 Jun 2000 10:45:23 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA12616; Fri, 30 Jun 2000 09:45:20 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA12593; Fri, 30 Jun 2000 09:45:19 -0500 Message-ID: <395CB309.19E888FE@lucent.com> Date: Fri, 30 Jun 2000 09:47:37 -0500 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@lists.bell-labs.com Subject: Re: [SPIRITS] On Joint PINT/SPIRITS Architecture References: Content-Type: multipart/mixed; boundary="------------1083ED78C2A924604A1F323E" Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com This is a multi-part message in MIME format. --------------1083ED78C2A924604A1F323E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Naoto MAKINAE wrote: ... > - A SPIRITS client may co-reside with PSTN/IN. The interface B and D are not > necessarily distinct. True. However, the resulting architecture is much cleaner this way - and more scalable. > ... > Harmonization of PINT and SPIRITS would be beneficial. > Unification would be much better, if possible. I see interworking with PINT as one of the SPIRITS requirements. A number of "real life" services are possible only by combining PINT and SPIRITS building blocks. PINT is slightly ahead of us. This means that we have to intensify our efforts. Regards, Alec --------------1083ED78C2A924604A1F323E 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 --------------1083ED78C2A924604A1F323E-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 30 15:52:06 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 ESMTP id PAA25264 for ; Fri, 30 Jun 2000 15:52:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B71744363; Fri, 30 Jun 2000 15:52:04 -0400 (EDT) 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 2CA5B44336 for ; Fri, 30 Jun 2000 15:52:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Jun 30 15:51:38 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 488F144348; Fri, 30 Jun 2000 15:38:29 -0400 (EDT) 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 11CAF44347 for ; Fri, 30 Jun 2000 15:38:29 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA10344; Fri, 30 Jun 2000 15:38:28 -0400 Message-ID: <395CF732.90FD21FD@bell-labs.com> Date: Fri, 30 Jun 2000 15:38:26 -0400 From: faynberg@bell-labs.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [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] On Joint PINT/SPIRITS Architecture References: <001001bfe271$e0c74200$d6d61cd4@swipnet.se> Content-Type: text/plain; charset=iso-8859-1 Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA25264 Jörgen Björkner wrote: > > Hi, > To allow for the user client (referred to as PINT client in Igor's mail) to > be able to deal with the event notifications generated from the Spirits > server must there probably be some extensions to PINT. > Therefore would it probably be appropriate to call this entity something > else, so people don't lock their mind's to certain functionality. Maybe will > we end up with something like PINT V2... Yes, when the draft is out, we will make sure that is clear. > I am not sure that someone implementing a SPIRITS service wants to implement > everything described in the PINT RFC, A good point. Based on the SPIRITS experience (and SPIRITS's charter is a great improvement on the PINT one), the way to think about the PINT-work-to-be is definining mutually-independent buidling blocks, so that an implementor can mix and match them. >but nothing prevents a SPIRITS user > agent (more neutral name, for the entity the user is having installed on his > device) to be co-located with a PINT client in a end users device Yes, but if we define that as an independent entity architecturally, we will need one more protocol. I so far belive that we can avoid that, but may be we cannot. This is precisely why I wanted to discuss it (and I am happy that the discussion started). > I am not restricting it to be a computer to avoid a certain service focus). Precisely. We've been trying to call it a "PC or Internet appliance," following Vint Cerf's recommendation. > I think that the new s[...]be/notify extensions to SIP should be >reviewed > if they could be used for this purpose. Yes, and we are putting this in the requirements. S[..]BE/NOTIFY will play central place in SPIRITS/PINT-to-be as the mechanism for setting DPs dynamically. (Note: The Lucent OCC implementation has used tbe [vanilla] SIP REGISTER method for the initial Client registration. But back then there was no PINT standard. (We are implementing it now.)] > > Therefore might there be appropriate to define a SPIRITS extension to >SIP, > which reuses the expertise and experiences from PINT. Otherwise would it be > need for an extension to PINT, since for example addition of hove to pass > back information to the SPRITS server has to be extended. For example an > event notifying a SPIRITS user agent that a call is being set up might want > let the user to redirect the call before instead of answering. This > information must be sent back to the SPIRITS server in either the SDP of a > 200, or maybe more appropriate in a 302 moved temporarily. This is precisely what we have been trying to address, although we try to be abstract. (Remember, we have not decided what the protocol will be... We are just producing requirements. > > I also think that the D interface is dependent of the voice network which > the SPIRITS server is connected to, and is an implementation issue, or a > question for those who is developing voice network standards (read ITU for > the PSTN case, 3GPP for 3G networks). 100% agreed. (Incidentally, I am glad you mentioned Wireless; it is obvious now that Wireless IN is a thing that will have to interwork with SPIRITS.) > > What do you think of the following comparison with SIP, the SPIRITS user > agent is similar to a SIP user agent, which will need some user feedback. > Some logic, acting on a users behalf, could be place in a SIP server, which > the user belongs to. In the SPIRITS case would this be the SPIRITS server. I think you are mentioning the SIP/CPL thing? Sure! I am so happy I am not a chair in this group so I can talk about things we are not supposed to be talking about (yet)! > > Maybe I should take some time to write down my ideas in a draft? I personally would very much like to read it. And this is the way to get the work going! Igor > _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jun 30 17:28:09 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 ESMTP id RAA26889 for ; Fri, 30 Jun 2000 17:28:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94BCB44349; Fri, 30 Jun 2000 17:28:04 -0400 (EDT) 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 9934644336 for ; Fri, 30 Jun 2000 17:28:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jun 30 17:27:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id D3A8944348; Fri, 30 Jun 2000 17:13:56 -0400 (EDT) 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 92E8244347 for ; Fri, 30 Jun 2000 17:13:56 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA26480; Fri, 30 Jun 2000 16:13:54 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA26476; Fri, 30 Jun 2000 16:13:54 -0500 Message-ID: <395D0E1A.376E6D60@lucent.com> Date: Fri, 30 Jun 2000 16:16:10 -0500 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@lists.bell-labs.com Subject: Re: [SPIRITS] On Joint PINT/SPIRITS Architecture References: <001001bfe271$e0c74200$d6d61cd4@swipnet.se> Content-Type: multipart/mixed; boundary="------------FED16878673A07338C4C1C4E" Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com This is a multi-part message in MIME format. --------------FED16878673A07338C4C1C4E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jörgen, I knew that this discussion will get you going. Please see my comments inline. Regards, Alec Jörgen Björkner wrote: ... > I am not sure that someone implementing a SPIRITS service wants to implement > everything described in the PINT RFC, but nothing prevents a SPIRITS user > agent (more neutral name, for the entity the user is having installed on his > device) to be co-located with a PINT client in a end users device (note that > I am not restricting it to be a computer to avoid a certain service focus). Lev proposed to use "IP Host" terminology at some point. > > I think that the new subscribe/notify extensions to SIP should be reviewed > if they could be used for this purpose. > > Therefore might there be appropriate to define a SPIRITS extension to SIP, > which reuses the expertise and experiences from PINT. Jörgen, please wait. Without requirements in place, we are not set on any particular protocol. ... > What do you think of the following comparison with SIP, the SPIRITS user > agent is similar to a SIP user agent, which will need some user feedback. > Some logic, acting on a users behalf, could be place in a SIP server, which > the user belongs to. In the SPIRITS case would this be the SPIRITS server. Please see my previous comment about requirements preceding protocol selection. > > > Maybe I should take some time to write down my ideas in a draft? Jörgen, that is a wonderful idea. After all, that is the best way to participate in this WG's work. > > > /Jörgen > -----Original Message----- > From: spirits-admin@lists.bell-labs.com > [mailto:spirits-admin@lists.bell-labs.com]On Behalf Of > faynberg@bell-labs.com > Sent: den 30 juni 2000 04:05 > To: SPIRITS > Subject: [SPIRITS] On Joint PINT/SPIRITS Architecture > > To all in good SPIRITS: > > Following up on the architecture discussion led by Lev in Adelaide and, > particularly, on the request from the chairmen ("esteemed chairmen!"--as > Lawrence would immediately correct me) to produce the protocol requirements > for > the IN and PINT points of view, respectively, > > I have tweaked a bit the original architectural picture so as to juxtapose > PINT > and SPIRITS and try to fit them within the same framework. It appeared to > come > fairly naturally while reviewing the pre-SPIRITS implementations report. > Much > inspiration for what I did came from Sung-Yurn Rhim's and Jinkyung Hwang's > material (which explicitly mentions PINT), but I also see it immediately > consistent with what Shinji Ago, S. Moeenuddin, and S. Hadvani described > (and > they explicitly mention SPIRITS). The OCC material also fits perfectly well > here. As for the rest, it is even easier to fit, I believe, because no > specific > function (PINT or SPIRITS) has been identified in that architecture. > > So, in the picture below, only PINT Client is seating on the User's PC (or > appliance). The Interface A is what PINT has been doing (and what, in fact, > has > been done for PINT 1.0). Now, both PINT Server and SPIRITS Client are > connected > to the PSTN Service Control through the means outside of either PINT or > SPIRITS > scope. > The PINT Server and SPIRITS Server are colocated. (Again, this is consistent > with the existing implementations.) > > Now, this is an issue that we have never discussed, but I submit that the > interface between PINT Server and SPIRITS Servers are of no interest to us. > (If > someone disagrees, I am ready to elaborate on this point). This leaves only > one > interface, B, for the SPIRITS protocol (I am not addressing the SMS and > MIB-related > issues). > > Hui-Lan and I are in the process of writing the requirements for the > relation > of actions on A and C, and Lev is working on the architecture, so this is an > important check-point. Does anyone see anything wrong with this? > > Note that the only real change (comparing with the crude combination of > SPIRITS > and PINT architecture) is the elimination of the SPIRITS element presence at > the > end-user's appliance, but the PINT Client should be able to take care of > whatever is needed. One question to ask here, is HOW would the PINT Client > be > invoked on executing the SPIRITS Server. > > Answering it, I understood why Christian Huitema and Lawrence Conroy have > made > Service Subscription a high priority item. (They brought this item up twice > at > the first and second SPIRITS BOF, and I remember no objection, nor did I > object, > although I did not fully understood the importance of it until now.) So the > answer is that the PINT Client would need to explicitly subscribe or > register > for SPIRITS service. This is an essential requirement, indeed, and it > significantly simplifies the architecture and cuts on the protocol effort. > > Well, enough said. The picture follows. > > With thanks for your attention, > > Igor > > .................. > |-----------| . |-----------| . C > |PINT Client| <---- A ------>. |PINT Server| <------------> PSTN > |-----------| . |-----------| . Service > . | . Control > . |---------| . D ^ > . | SPIRITS | . |-----|-----| > . | Server | <---- B ---->| SPIRITS > | . > |---------| . | Client | > .................. |-----------| > > _______________________________________________ > 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 --------------FED16878673A07338C4C1C4E 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 --------------FED16878673A07338C4C1C4E-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits