From mailnull@www1.ietf.org Sun Sep 1 07:33:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15530 for ; Sun, 1 Sep 2002 07:33:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g81BZ3L16860 for speechsc-archive@odin.ietf.org; Sun, 1 Sep 2002 07:35:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81BZ3o16857 for ; Sun, 1 Sep 2002 07:35:03 -0400 From: sip-admin@ietf.org Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15490 for ; Sun, 1 Sep 2002 07:33:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81BYXo16741 for ; Sun, 1 Sep 2002 07:34:33 -0400 Date: Sun, 01 Sep 2002 07:34:32 -0400 Message-ID: <20020901113432.1916.53325.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: speechsc-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org 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, speechsc-request@ietf.org) 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@. Thanks! Passwords for speechsc-web-archive@ietf.org: List Password // URL ---- -------- speechsc@ietf.org mHtT https://www1.ietf.org/mailman/options/speechsc/speechsc-web-archive%40ietf.org From mailnull@www1.ietf.org Tue Sep 3 17:38:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15132 for ; Tue, 3 Sep 2002 17:38:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83LdkF26238 for speechsc-archive@odin.ietf.org; Tue, 3 Sep 2002 17:39:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Ldko26235 for ; Tue, 3 Sep 2002 17:39:46 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15127 for ; Tue, 3 Sep 2002 17:38:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Ld7o26206; Tue, 3 Sep 2002 17:39:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83LcKo26179 for ; Tue, 3 Sep 2002 17:38:20 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15074 for ; Tue, 3 Sep 2002 17:36:38 -0400 (EDT) Received: from OranLT.cisco.com ([161.44.238.47]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g83Lbhds026438 for ; Tue, 3 Sep 2002 14:37:43 -0700 (PDT) Date: Tue, 03 Sep 2002 17:32:58 -0400 From: "David R. Oran" To: speechsc@ietf.org Message-ID: <368216497.1031074378@OranLT.cisco.com> X-Mailer: Mulberry/3.0.0b1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Speechsc] WGLC for Requirements draft Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'd like to begin Working Group Last Call for draft-ietf-speechsc-reqts-00.txt. Last call will close on Sept 20th. Comments to the list, as usual. Thanks. Your chairs, Dave and Eric. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sat Sep 7 17:27:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19093 for ; Sat, 7 Sep 2002 17:27:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g87LSge09912 for speechsc-archive@odin.ietf.org; Sat, 7 Sep 2002 17:28:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g87LSgX09909 for ; Sat, 7 Sep 2002 17:28:42 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19090 for ; Sat, 7 Sep 2002 17:26:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g87LS9X09871; Sat, 7 Sep 2002 17:28:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g87LRQX09839 for ; Sat, 7 Sep 2002 17:27:26 -0400 Received: from ahuumrelay1.ams.ops.eu.uu.net (ahuumrelay1.ams.ops.eu.uu.net [195.129.70.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19086 for ; Sat, 7 Sep 2002 17:25:41 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay1.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g87LQYT12015; Sat, 7 Sep 2002 21:26:35 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 5E6E43B6BC; Sat, 7 Sep 2002 17:26:01 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'David R. Oran'" , Cc: "Brian Wyld (E-mail)" Subject: RE: [Speechsc] WGLC for Requirements draft Date: Sat, 7 Sep 2002 23:25:46 +0200 Message-ID: <014301c256b5$2209c490$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <368216497.1031074378@OranLT.cisco.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, My comments on the requirements draft are below. If they cover discussions already hashed to death at the IETF meeting, my apologies - no doubt someone will set me straight.... Document general: - it would be nice to number the requirements within the sections (as it done in section 5 but not in 6/7/8/9 to allow for easy reference. Section 4. Framework What is mechanism by which RTP sessions are identified by the speechsc server and related to the speechsc session? Is it purely by IP/port or by some RTP session id? In the diagram, the entities that can initiate a speechsc session with a server are shown as the AS and MRE. However, it is also noted in the text that the MRE can be further decomposed into a MG/MGC type pair. I believe this would be useful to show, as it seems to me that the session/RTP identification point above may be further complicated by such a decomposition. Section 5 : General requirements - propose to add a requirement "SPEECHSC framework MUST define a single protocol for all of its MUST requirements ie cannot define to use existing protocol A for TTS, and a new protocol B for ASR or SR". The aim of such a requirement is to ensure that a speechsc implementor does not have to create/purchase multiple protocols for speechsc support. To achieve this, the requirement of 5.3 (no existing protocol duplication) may be broken for TTS in order to ensure a unified protocol for ASR/SR operation. (but its already a SHOULD NOT rather than a MUST....) - add new sub-section in 5 that covers all control channel/session/operation requirements (including and extending the paragraph about sessions in section 6). - explicitly define that SPEECHSC protocol : MUST allow a 1:N mapping between session and RTP channels ie a single session may include an outbound RTP channel for TTS, an inbound for ASR and a different inbound for SR (eg if processed by different elements on the MRE). MUST define how RTP sessions included in a speechsc session are identified MUST be capable of using a single control channel during : - a single session - multiple sessions serially - multiple sessions in parallel MUST be capable of using a single session for - a single operation of a single type (single utterance recognition) - multiple operations of the same type (use of TTS channel during a call) - multiple operations of different types (TTS/ASR server, ASR/SR server) - a speechsc server MUST allow all of the above possibilities except the last (ie a TTS only speechsc server is ok). - propose to add a requirement that SPEECHSC MUST define a mechanism to allow a speechsc server to be interrogated by a client about its capablilities. The set of capabilities that can be verified MUST include: - server type : TTS or ASR or SR or combo - hint about relationship with other servers (load balancing, multi-vendor compatibility, etc) - languages supported - implementation or not of the SHOULD items in the protocol NOTE: this might be redundant with 5.5 if these capabilities form part of the search requirements for a service location request. Section 7 : ASR requirements - add requirement that speechsc provides a way to convey the grammar language(s) explicitly without requiring parsing of the grammar itself (required to be able to create a generic speechsc server module that passes the actual ASR processing to another element, based on the language required) - change SHOULD to MUST for the requirement for SPEECHSC to have a method to instruct the capture of the media stream by the ASR server, and add that the ASR server SHOULD implement it (it may communicate its non-implementation to a client) [ie the protocol must define the mechanism, but the server may not implement it] - (last para in seciotn 7) change "The ASR Server SHOULD support sharing grammars across sessions...." to "The SPEECHSC framework MUST support a means of requesting the sharing of grammars across sessions....", and add that "ASR server SHOULD support this functionality". [ie the protocol must define the mechanism, but the server may not implement it] Section 9 : Dual-Mode Requirements I think that this section could be generalised to state that: - SPEECHSC MUST support multiple simultaneous operations on the same session to the same server [eg case of "speaking detection" and ASR functions on same server, or SR and ASR on the same server, or ASR and TTS on the same server] - SPEECHSC MUST support duplication of RTP streams to servers and MUST support multiple simultaneous operations on the same session to different servers using these duplicated RTP streams [eg case of SR and ASR which are on different servers, to support the dynamic challenge example given] Section 10 : Thoughts... Just a comment on the item about TTS being likely to be coverable by RTSP++ or a SIP NA type spec and ASR/SR being the focus of protocol work - this is why I think we need an explicit requirement that the speechsc result protocol is a single protocol and not 2 or 3. Even if RTSP is "almost" right for TTS, if it cannot be extended in a reasonable way for ASR/SR then I think it cannot be used for TTS. Duplication of "almost right" type protocol functionalities is ok if it achieves a "higher" purpose (unified protocol for speechsc) (ok, more of a religous point here but lets remember the poor folks who have to implement this....) Anyway, thats enough for now..... Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] -----Message d'origine----- De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part de David R. Oran Envoye : Tuesday, September 03, 2002 23:33 A : speechsc@ietf.org Objet : [Speechsc] WGLC for Requirements draft I'd like to begin Working Group Last Call for draft-ietf-speechsc-reqts-00.txt. Last call will close on Sept 20th. Comments to the list, as usual. Thanks. Your chairs, Dave and Eric. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Sep 11 11:31:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13131 for ; Wed, 11 Sep 2002 11:31:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8BFWpb23045 for speechsc-archive@odin.ietf.org; Wed, 11 Sep 2002 11:32:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BFWpv23042 for ; Wed, 11 Sep 2002 11:32:51 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13122 for ; Wed, 11 Sep 2002 11:31:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BFWGv23025; Wed, 11 Sep 2002 11:32:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BFTuv22930 for ; Wed, 11 Sep 2002 11:29:56 -0400 Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13013 for ; Wed, 11 Sep 2002 11:28:11 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g8BFTOp20502; Wed, 11 Sep 2002 11:29:30 -0400 (EDT) Reply-To: From: "Eric Burger" To: , "'David R. Oran'" Cc: Subject: RE: [Speechsc] WGLC for Requirements draft Date: Wed, 11 Sep 2002 11:29:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <014301c256b5$2209c490$8300a8c0@hq.eloquant.com> Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit in-line > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf > Of Brian Wyld [snip] > Document general: > - it would be nice to number the requirements within the sections (as it > done in section 5 but not in 6/7/8/9 to allow for easy reference. Good idea. > Section 4. Framework > > What is mechanism by which RTP sessions are identified by the speechsc > server and related to the speechsc session? Is it purely by IP/port or by > some RTP session id? The requirement is that it is identified. We're not up to specifying how, yet. > In the diagram, the entities that can initiate a speechsc session with a > server are shown as the AS and MRE. However, it is also noted in the text > that the MRE can be further decomposed into a MG/MGC type pair. I believe > this would be useful to show, as it seems to me that the session/RTP > identification point above may be further complicated by such a > decomposition. I don't see the complication -- an end-point is an end-point. There is nothing to say that it has to have the same IP address as the signaling end-point. > Section 5 : General requirements > > - propose to add a requirement "SPEECHSC framework MUST define a single > protocol for all of its MUST requirements ie cannot define to use existing > protocol A for TTS, and a new protocol B for ASR or SR". > > The aim of such a requirement is to ensure that a speechsc > implementor does > not have to create/purchase multiple protocols for speechsc support. This has been beat a bit: ASR and SV have pretty much the same needs; TTS has very different needs. I might live with an "it would be nice if there was a single protocol", but I wouldn't even elevate it to a SHOULD. By the logic given above, the protocol also should encompass session invocation (SIP), data transfer (HTTP), and system monitoring (SNMP). Rather than standing at the precipice of the slippery slope, I would leave this one alone. > To achieve this, the requirement of 5.3 (no existing protocol duplication) > may be broken for TTS in order to ensure a unified protocol for ASR/SR > operation. (but its already a SHOULD NOT rather than a MUST....) > > - add new sub-section in 5 that covers all control > channel/session/operation requirements (including and extending the > paragraph about sessions in section 6). Can you give examples? > - explicitly define that SPEECHSC protocol : > MUST allow a 1:N mapping between session and RTP channels ie a single > session may include an outbound RTP channel for TTS, an inbound > for ASR and > a different inbound for SR (eg if processed by different elements on the > MRE). Probably OK. > MUST define how RTP sessions included in a speechsc session are > identified Out of scope: that's an implementation detail. *That* we MUST identify RTP sessions is a requirement. > MUST be capable of using a single control channel during : > - a single session Agreed. > - multiple sessions serially > - multiple sessions in parallel These were beaten to death in Minneapolis. The short answer is that if we get there, great, but it is so unlikely to be sensibly done in practice, we're not going to focus (or rat-hole) on it. > MUST be capable of using a single session for > - a single operation of a single type (single utterance recognition) > - multiple operations of the same type (use of TTS channel during a > call) > - multiple operations of different types (TTS/ASR server, > ASR/SR server) Does section 9 cover this? > - a speechsc server MUST allow all of the above possibilities except the > last (ie a TTS only speechsc server is ok). What's wrong with an ASR-only or SV-only server? > - propose to add a requirement that SPEECHSC MUST define a mechanism to > allow a speechsc server to be interrogated by a client about its > capablilities. The set of capabilities that can be verified MUST include: > - server type : TTS or ASR or SR or combo > - hint about relationship with other servers (load balancing, > multi-vendor compatibility, etc) > - languages supported > - implementation or not of the SHOULD items in the protocol > NOTE: this might be redundant with 5.5 if these capabilities > form part of > the search requirements for a service location request. I think section 5.5 covers this. > Section 7 : ASR requirements > > - add requirement that speechsc provides a way to convey the grammar > language(s) explicitly without requiring parsing of the grammar itself > (required to be able to create a generic speechsc server module > that passes > the actual ASR processing to another element, based on the language > required) Hmmm. Need to hear from others on this one. > - change SHOULD to MUST for the requirement for SPEECHSC to have a method > to instruct the capture of the media stream by the ASR server, > and add that > the ASR server SHOULD implement it (it may communicate its > non-implementation to a client) [ie the protocol must define the > mechanism, > but the server may not implement it] Need to hear from others, especially the ASR vendors. I like the idea. > - (last para in seciotn 7) change "The ASR Server SHOULD support sharing > grammars across sessions...." to "The SPEECHSC framework MUST support a > means of requesting the sharing of grammars across sessions....", and add > that "ASR server SHOULD support this functionality". [ie the protocol must > define the mechanism, but the server may not implement it] Other votes? > Section 9 : Dual-Mode Requirements > > I think that this section could be generalised to state that: > - SPEECHSC MUST support multiple simultaneous operations on the same > session to the same server > [eg case of "speaking detection" and ASR functions on same > server, or SR > and ASR on the same server, or ASR and TTS on the same server] This isn't already there? > - SPEECHSC MUST support duplication of RTP streams to servers and MUST > support multiple simultaneous operations on the same session to different > servers using these duplicated RTP streams > [eg case of SR and ASR which are on different servers, to support the > dynamic challenge example given] Implementation; beyond requirements. > Section 10 : Thoughts... > > Just a comment on the item about TTS being likely to be coverable > by RTSP++ > or a SIP NA type spec and ASR/SR being the focus of protocol work > - this is > why I think we need an explicit requirement that the speechsc result > protocol is a single protocol and not 2 or 3. Even if RTSP is > "almost" right > for TTS, if it cannot be extended in a reasonable way for ASR/SR then I > think it cannot be used for TTS. Duplication of "almost right" > type protocol > functionalities is ok if it achieves a "higher" purpose (unified protocol > for speechsc) (ok, more of a religous point here but lets > remember the poor > folks who have to implement this....) The problem is that we would be reinventing almost all of RTSP to support TTS. Let's leave it to the protocol analysis document to delve in to what can work where. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Sep 11 14:35:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20628 for ; Wed, 11 Sep 2002 14:35:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8BIajV02465 for speechsc-archive@odin.ietf.org; Wed, 11 Sep 2002 14:36:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BIajv02462 for ; Wed, 11 Sep 2002 14:36:45 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20595 for ; Wed, 11 Sep 2002 14:34:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BIaCv02442; Wed, 11 Sep 2002 14:36:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BIZpv02403 for ; Wed, 11 Sep 2002 14:35:51 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20578 for ; Wed, 11 Sep 2002 14:34:05 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8BIZDds001729; Wed, 11 Sep 2002 11:35:13 -0700 (PDT) Received: from cisco.com (dhcp-128-107-139-27.cisco.com [128.107.139.27]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFC03133; Wed, 11 Sep 2002 11:31:11 -0700 (PDT) Message-ID: <3D7F8CDC.18109324@cisco.com> Date: Wed, 11 Sep 2002 11:35:08 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brian.wyld@eloquant.com CC: "'David R. Oran'" , speechsc@ietf.org Subject: Re: [Speechsc] WGLC for Requirements draft References: <014301c256b5$2209c490$8300a8c0@hq.eloquant.com> Content-Type: multipart/mixed; boundary="------------43835568A5DAD38A3E4204D3" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------43835568A5DAD38A3E4204D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit some responses inline. Brian Wyld wrote: > Hi, > > My comments on the requirements draft are below. If they cover discussions > already hashed to death at the IETF meeting, my apologies - no doubt someone > will set me straight.... > > Document general: > - it would be nice to number the requirements within the sections (as it > done in section 5 but not in 6/7/8/9 to allow for easy reference. > > Section 4. Framework > > What is mechanism by which RTP sessions are identified by the speechsc > server and related to the speechsc session? Is it purely by IP/port or by > some RTP session id? > I believe this would be part of the protocol identification/definition which would be the next phase of the process. But I would venture to suggest that it wouldd be nice to use something like SDP to describe the RTP pipe to/from the client to the speechsc server. > > In the diagram, the entities that can initiate a speechsc session with a > server are shown as the AS and MRE. However, it is also noted in the text > that the MRE can be further decomposed into a MG/MGC type pair. I believe > this would be useful to show, as it seems to me that the session/RTP > identification point above may be further complicated by such a > decomposition. > > Section 5 : General requirements > > - propose to add a requirement "SPEECHSC framework MUST define a single > protocol for all of its MUST requirements ie cannot define to use existing > protocol A for TTS, and a new protocol B for ASR or SR". > > The aim of such a requirement is to ensure that a speechsc implementor does > not have to create/purchase multiple protocols for speechsc support. Though I would love to see that too for simplicity sake, I don't think that should be made a MUST or a SHOULD. > > > To achieve this, the requirement of 5.3 (no existing protocol duplication) > may be broken for TTS in order to ensure a unified protocol for ASR/SR > operation. (but its already a SHOULD NOT rather than a MUST....) > > - add new sub-section in 5 that covers all control > channel/session/operation requirements (including and extending the > paragraph about sessions in section 6). > - explicitly define that SPEECHSC protocol : > MUST allow a 1:N mapping between session and RTP channels ie a single > session may include an outbound RTP channel for TTS, an inbound for ASR and > a different inbound for SR (eg if processed by different elements on the > MRE). This should not be a MUST. In fact if anything, I would suggest that SPEECHSC server should have to receive only 1 incoming RTP stream for ASR and/or SV and one outgoing RTP channel for TTS. If at all, we want to allow this as an option, and the SPEECHSC server wanted the same incoming RTP stream forked to 2 different points(ASR & TTS), this may be achieved with something like an SDP with 2 different m-lines. But I' would consider this as a MAY/option. > > MUST define how RTP sessions included in a speechsc session are identified > MUST be capable of using a single control channel during : > - a single session > - multiple sessions serially > - multiple sessions in parallel Not sure what you mean by single control channel during multiple sessions serially or parallely. Could you please elaborate. > > MUST be capable of using a single session for > - a single operation of a single type (single utterance recognition) > - multiple operations of the same type (use of TTS channel during a > call) > - multiple operations of different types (TTS/ASR server, ASR/SR server) > Within a single session established to a SpeechSC server(meaning a single control session with an established RTP pipe), I agree we should be able to allocate a recognition resource and do multiple ASR operations one after the other. Within the the same session, we should also be able allocate a SV and do one or more SV operations in sequence. When you are talk about parallely, if you are refering to the case of having a SV and an ASR operation active parallely in the same session. I agree. With TTS I would agree, parallel operation should be possible, IF we do end up with a single protocol for ASR, TTS and SV. > > - a speechsc server MUST allow all of the above possibilities except the > last (ie a TTS only speechsc server is ok). > > - propose to add a requirement that SPEECHSC MUST define a mechanism to > allow a speechsc server to be interrogated by a client about its > capablilities. The set of capabilities that can be verified MUST include: > - server type : TTS or ASR or SR or combo > - hint about relationship with other servers (load balancing, > multi-vendor compatibility, etc) > - languages supported > - implementation or not of the SHOULD items in the protocol > NOTE: this might be redundant with 5.5 if these capabilities form part of > the search requirements for a service location request. Agreed. I believe this covered in the requirements doc. > > > Section 7 : ASR requirements > > - add requirement that speechsc provides a way to convey the grammar > language(s) explicitly without requiring parsing of the grammar itself > (required to be able to create a generic speechsc server module that passes > the actual ASR processing to another element, based on the language > required) If this is setting some sort of default language, if the grammar doess not contain a language, I would agree. But if a grammar markup does specify a language it will always take precedence. In any case, this should be a protocol design detail. > > > - change SHOULD to MUST for the requirement for SPEECHSC to have a method > to instruct the capture of the media stream by the ASR server, and add that > the ASR server SHOULD implement it (it may communicate its > non-implementation to a client) [ie the protocol must define the mechanism, > but the server may not implement it] I Agree > > > - (last para in seciotn 7) change "The ASR Server SHOULD support sharing > grammars across sessions...." to "The SPEECHSC framework MUST support a > means of requesting the sharing of grammars across sessions....", and add > that "ASR server SHOULD support this functionality". [ie the protocol must > define the mechanism, but the server may not implement it] > Is this for efficiency in a downloading and compiling large grammars? Wouldn't caching fetched/compiledd grammars addrerss the problem. Would we still need global or shared grammars, if we had caching and ways of controlling caching of grammars on the speechsc server??? > > Section 9 : Dual-Mode Requirements > > I think that this section could be generalised to state that: > - SPEECHSC MUST support multiple simultaneous operations on the same > session to the same server > [eg case of "speaking detection" and ASR functions on same server, or SR > and ASR on the same server, or ASR and TTS on the same server] Are these different from previous comments in thiss email. I believe this covered. > > > - SPEECHSC MUST support duplication of RTP streams to servers and MUST > support multiple simultaneous operations on the same session to different > servers using these duplicated RTP streams > [eg case of SR and ASR which are on different servers, to support the > dynamic challenge example given] I believe this to be protocol definition detail. > > > Section 10 : Thoughts... > > Just a comment on the item about TTS being likely to be coverable by RTSP++ > or a SIP NA type spec and ASR/SR being the focus of protocol work - this is > why I think we need an explicit requirement that the speechsc result > protocol is a single protocol and not 2 or 3. Even if RTSP is "almost" right > for TTS, if it cannot be extended in a reasonable way for ASR/SR then I > think it cannot be used for TTS. Duplication of "almost right" type protocol > functionalities is ok if it achieves a "higher" purpose (unified protocol > for speechsc) (ok, more of a religous point here but lets remember the poor > folks who have to implement this....) Lets shoot to have a unified protocol, but not tie us down with a MUST. atleast not yet. Sarvi > > > Anyway, thats enough for now..... > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > -----Message d'origine----- > De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part > de David R. Oran > Envoye : Tuesday, September 03, 2002 23:33 > A : speechsc@ietf.org > Objet : [Speechsc] WGLC for Requirements draft > > I'd like to begin Working Group Last Call for > draft-ietf-speechsc-reqts-00.txt. Last call will close on Sept 20th. > > Comments to the list, as usual. Thanks. > > Your chairs, > Dave and Eric. > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc --------------43835568A5DAD38A3E4204D3 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Sarvi tel;work:408-527-4875 x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Group adr:;;;;;; version:2.1 email;internet:sarvi@cisco.com title:Technical Leader fn:Sarvi Shanmugham end:vcard --------------43835568A5DAD38A3E4204D3-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Sep 11 18:58:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27761 for ; Wed, 11 Sep 2002 18:58:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8BMxcr17143 for speechsc-archive@odin.ietf.org; Wed, 11 Sep 2002 18:59:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BMxcv17129 for ; Wed, 11 Sep 2002 18:59:38 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27750 for ; Wed, 11 Sep 2002 18:57:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BMx4v17093; Wed, 11 Sep 2002 18:59:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BMwfv17048 for ; Wed, 11 Sep 2002 18:58:41 -0400 Received: from ahuumrelay0.ams.ops.eu.uu.net (ahuumrelay0.ams.ops.eu.uu.net [195.129.70.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27731 for ; Wed, 11 Sep 2002 18:56:52 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay0.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8BMvrX12660; Wed, 11 Sep 2002 22:57:54 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id E613B3B6BE; Wed, 11 Sep 2002 18:57:16 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'Sarvi Shanmugham'" Cc: "'David R. Oran'" , Subject: RE: [Speechsc] WGLC for Requirements draft Date: Thu, 12 Sep 2002 00:56:31 +0200 Message-ID: <001a01c259e6$8e735b30$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3D7F8CDC.18109324@cisco.com> Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sarvi, Some of your points are covered (I think) by my reply to Eric - other responses below... [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Sarvi Shanmugham > Envoye : Wednesday, September 11, 2002 20:35 > A : brian.wyld@eloquant.com > Cc : 'David R. Oran'; speechsc@ietf.org > Objet : Re: [Speechsc] WGLC for Requirements draft > > > some responses inline. > [snip] > > Section 5 : General requirements > > > > - propose to add a requirement "SPEECHSC framework MUST > define a single > > protocol for all of its MUST requirements ie cannot define > to use existing > > protocol A for TTS, and a new protocol B for ASR or SR". > > > > The aim of such a requirement is to ensure that a speechsc > implementor does > > not have to create/purchase multiple protocols for speechsc support. > > Though I would love to see that too for simplicity sake, I > don't think that > should be made a MUST or a SHOULD. I'm ok to wait till we do the existing protocol comparison doc and see how it comes out.... > > - add new sub-section in 5 that covers all control > > channel/session/operation requirements (including and extending the > > paragraph about sessions in section 6). > > - explicitly define that SPEECHSC protocol : > > MUST allow a 1:N mapping between session and RTP channels > ie a single > > session may include an outbound RTP channel for TTS, an > inbound for ASR and > > a different inbound for SR (eg if processed by different > elements on the > > MRE). > > This should not be a MUST. > In fact if anything, I would suggest that SPEECHSC server > should have to receive > only 1 incoming RTP stream for ASR and/or SV and one outgoing > RTP channel for > TTS. > If at all, we want to allow this as an option, and the > SPEECHSC server wanted > the same incoming RTP stream forked to 2 different points(ASR > & TTS), this may > be achieved with something like an SDP with 2 different > m-lines. But I' would > consider this as a MAY/option. True it might be a marginal case. > > > > MUST define how RTP sessions included in a speechsc > session are identified > > MUST be capable of using a single control channel during : > > - a single session > > - multiple sessions serially > > - multiple sessions in parallel > > Not sure what you mean by single control channel during > multiple sessions > serially or parallely. Could you please elaborate. Multiple serial use - Open a control channel client->server - setup session A - execute 1-N operations (eg TTS generation) - close session A - setup session B - execute 1-N operations (eg TTS generation) - close session B - etc - close control channel Multiple parallel use - Open a control channel client->server - setup session A - setup session B (C, D etc) - execute operation on A (eg TTS generation) - execute operation on B(eg TTS generation) - repeat until done - close session A - close session B - close control channel > > > > MUST be capable of using a single session for > > - a single operation of a single type (single utterance > recognition) > > - multiple operations of the same type (use of TTS > channel during a > > call) > > - multiple operations of different types (TTS/ASR > server, ASR/SR server) > > > > Within a single session established to a SpeechSC > server(meaning a single > control session with an established RTP pipe), I agree we > should be able to > allocate a recognition resource and do multiple ASR > operations one after the > other. Within the the same session, we should also be able > allocate a SV and do > one or more SV operations in sequence. When you are talk > about parallely, if you > are refering to the case of having a SV and an ASR operation > active parallely in > the same session. I agree. > With TTS I would agree, parallel operation should be > possible, IF we do end up > with a single protocol for ASR, TTS and SV. Yup, thats what I meant. [snip] > > - (last para in seciotn 7) change "The ASR Server SHOULD > support sharing > > grammars across sessions...." to "The SPEECHSC framework > MUST support a > > means of requesting the sharing of grammars across > sessions....", and add > > that "ASR server SHOULD support this functionality". [ie > the protocol must > > define the mechanism, but the server may not implement it] > > > > Is this for efficiency in a downloading and compiling large grammars? > Wouldn't caching fetched/compiledd grammars addrerss the > problem. Would we still > need global or shared grammars, if we had caching and ways of > controlling > caching of grammars on the speechsc server??? Caching achieves the same goal but the first user of the grammar pays the compilation latency. Otherwise yes, I'm just requesting a means of providing caching hints to the server. > > > > Anyway, thats enough for now..... And again, bedtime... Brian > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Sep 11 19:56:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27760 for ; Wed, 11 Sep 2002 18:58:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8BMxcY17132 for speechsc-archive@odin.ietf.org; Wed, 11 Sep 2002 18:59:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BMxcv17127 for ; Wed, 11 Sep 2002 18:59:38 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27749 for ; Wed, 11 Sep 2002 18:57:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BMx4v17077; Wed, 11 Sep 2002 18:59:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BMwev17044 for ; Wed, 11 Sep 2002 18:58:40 -0400 Received: from ahuumrelay3.ams.ops.eu.uu.net (ahuumrelay3.ams.ops.eu.uu.net [195.129.70.156]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27729 for ; Wed, 11 Sep 2002 18:56:51 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay3.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8BMvpH16953; Wed, 11 Sep 2002 22:57:51 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 6B7163B6BC; Wed, 11 Sep 2002 18:57:14 -0400 (EDT) Reply-To: From: "Brian Wyld" To: , "'David R. Oran'" Cc: Subject: RE: [Speechsc] WGLC for Requirements draft Date: Thu, 12 Sep 2002 00:45:33 +0200 Message-ID: <001901c259e6$8cb9c450$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit comments on Eric's comments where appropriate below.... [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : Eric Burger [mailto:eburger@snowshore.com] > Envoye : Wednesday, September 11, 2002 17:29 > A : brian.wyld@eloquant.com; 'David R. Oran' > Cc : speechsc@ietf.org > Objet : RE: [Speechsc] WGLC for Requirements draft > > > in-line > [snip] > > Section 4. Framework > > > > What is mechanism by which RTP sessions are identified by > the speechsc > > server and related to the speechsc session? Is it purely by > IP/port or by > > some RTP session id? > > The requirement is that it is identified. We're not up to > specifying how, > yet. Ok, fine. > > In the diagram, the entities that can initiate a speechsc > session with a > > server are shown as the AS and MRE. However, it is also > noted in the text > > that the MRE can be further decomposed into a MG/MGC type > pair. I believe > > this would be useful to show, as it seems to me that the session/RTP > > identification point above may be further complicated by such a > > decomposition. > > I don't see the complication -- an end-point is an end-point. > There is > nothing to say that it has to have the same IP address as the > signaling > end-point. Ok, it was just to be able to reinforce this point in the diagram. > > Section 5 : General requirements > > > > - propose to add a requirement "SPEECHSC framework MUST > define a single > > protocol for all of its MUST requirements ie cannot define > to use existing > > protocol A for TTS, and a new protocol B for ASR or SR". > > > > The aim of such a requirement is to ensure that a speechsc > > implementor does > > not have to create/purchase multiple protocols for speechsc support. > > This has been beat a bit: ASR and SV have pretty much the > same needs; TTS > has very different needs. I might live with an "it would be > nice if there > was a single protocol", but I wouldn't even elevate it to a > SHOULD. By the > logic given above, the protocol also should encompass session > invocation > (SIP), data transfer (HTTP), and system monitoring (SNMP). > Rather than > standing at the precipice of the slippery slope, I would > leave this one > alone. In some ways the resulting protocol will encompass elements from others - I don't think its the case that all protocols must be orthoganal (sp?) to each other (and certainly not the case that they are currently....) However, probably verging on a religous war here, so I'm content to leave that till we're further on.... > > - add new sub-section in 5 that covers all control > > channel/session/operation requirements (including and extending the > > paragraph about sessions in section 6). > > Can you give examples? Well, the requirements that followed were my examples... [snip] > > MUST define how RTP sessions included in a speechsc session are > > identified > > Out of scope: that's an implementation detail. *That* we > MUST identify RTP > sessions is a requirement. Fair enough. > > MUST be capable of using a single control channel during : > > - a single session > > Agreed. > > > - multiple sessions serially > > - multiple sessions in parallel > > These were beaten to death in Minneapolis. The short answer > is that if we > get there, great, but it is so unlikely to be sensibly done > in practice, > we're not going to focus (or rat-hole) on it. Hmmm. Not to drag pre-existing protocol implementations into it, but I know of at least one implementation that opens its control channel (==TCP socket) at startup to each server configured, and uses this same channel for ALL session messages to that server (ie, single control channel for multiple sessions in parallel). IMHO there are interesting efficiency gains to be made over open/close of the control channel for each session..... > > MUST be capable of using a single session for > > - a single operation of a single type (single utterance > recognition) > > - multiple operations of the same type (use of TTS > channel during a > > call) > > - multiple operations of different types (TTS/ASR server, > > ASR/SR server) > > Does section 9 cover this? Effectively, but I wanted a re-grouping of all session lifecycle related items in a single section.... > > - a speechsc server MUST allow all of the above > possibilities except the > > last (ie a TTS only speechsc server is ok). > > What's wrong with an ASR-only or SV-only server? Nothing, the TTS was just an example of a single mode server.... > > - propose to add a requirement that SPEECHSC MUST define a > mechanism to > > allow a speechsc server to be interrogated by a client about its > > capablilities. The set of capabilities that can be verified > MUST include: > > - server type : TTS or ASR or SR or combo > > - hint about relationship with other servers (load balancing, > > multi-vendor compatibility, etc) > > - languages supported > > - implementation or not of the SHOULD items in the protocol > > NOTE: this might be redundant with 5.5 if these capabilities > > form part of > > the search requirements for a service location request. > > I think section 5.5 covers this. Ok. Maybe just needs a specific clarification? > > Section 7 : ASR requirements > > > > - add requirement that speechsc provides a way to convey > the grammar > > language(s) explicitly without requiring parsing of the > grammar itself > > (required to be able to create a generic speechsc server module > > that passes > > the actual ASR processing to another element, based on the language > > required) > > Hmmm. Need to hear from others on this one. Ok. It's a minorish point.... > > - change SHOULD to MUST for the requirement for SPEECHSC > to have a method > > to instruct the capture of the media stream by the ASR server, > > and add that > > the ASR server SHOULD implement it (it may communicate its > > non-implementation to a client) [ie the protocol must define the > > mechanism, > > but the server may not implement it] > > Need to hear from others, especially the ASR vendors. I like > the idea. Ok. Note that I make the difference between what the speechsc protocol MUST cover (ie what this WG has to do) and what a particular implementation of an ASR server must do to be complient.... > > - (last para in seciotn 7) change "The ASR Server SHOULD > support sharing > > grammars across sessions...." to "The SPEECHSC framework > MUST support a > > means of requesting the sharing of grammars across > sessions....", and add > > that "ASR server SHOULD support this functionality". [ie > the protocol must > > define the mechanism, but the server may not implement it] > > Other votes? Point is same as above - I want protocol support for the feature but am willing to see it as a "plus" for a specific ASR vendor.... > > Section 9 : Dual-Mode Requirements > > > > I think that this section could be generalised to state that: > > - SPEECHSC MUST support multiple simultaneous operations > on the same > > session to the same server > > [eg case of "speaking detection" and ASR functions on same > > server, or SR > > and ASR on the same server, or ASR and TTS on the same server] > > This isn't already there? Yes, I was just trying to generalise from the "dual" mode to say we might have "n-mode" servers (n 1-3 I guess...) > > - SPEECHSC MUST support duplication of RTP streams to > servers and MUST > > support multiple simultaneous operations on the same > session to different > > servers using these duplicated RTP streams > > [eg case of SR and ASR which are on different servers, > to support the > > dynamic challenge example given] > > Implementation; beyond requirements. Is there no impact on the protocol? I thought there might be some sync required? Maybe leave until the detail emerges. > > Section 10 : Thoughts... > > > > Just a comment on the item about TTS being likely to be coverable > > by RTSP++ > > or a SIP NA type spec and ASR/SR being the focus of protocol work > > - this is > > why I think we need an explicit requirement that the speechsc result > > protocol is a single protocol and not 2 or 3. Even if RTSP is > > "almost" right > > for TTS, if it cannot be extended in a reasonable way for > ASR/SR then I > > think it cannot be used for TTS. Duplication of "almost right" > > type protocol > > functionalities is ok if it achieves a "higher" purpose > (unified protocol > > for speechsc) (ok, more of a religous point here but lets > > remember the poor > > folks who have to implement this....) > > The problem is that we would be reinventing almost all of > RTSP to support > TTS. Let's leave it to the protocol analysis document to > delve in to what > can work where. Fair enough, it was just my 2c anyway.... Brian _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Sep 11 20:51:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29770 for ; Wed, 11 Sep 2002 20:51:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8C0qeI22664 for speechsc-archive@odin.ietf.org; Wed, 11 Sep 2002 20:52:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8C0qdv22660 for ; Wed, 11 Sep 2002 20:52:39 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29758 for ; Wed, 11 Sep 2002 20:50:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8C0q4v22633; Wed, 11 Sep 2002 20:52:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8C0p9v22605 for ; Wed, 11 Sep 2002 20:51:09 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29731 for ; Wed, 11 Sep 2002 20:49:21 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8C0oTds019760; Wed, 11 Sep 2002 17:50:29 -0700 (PDT) Received: from cisco.com (sjc-vpn2-515.cisco.com [10.21.114.3]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFC17822; Wed, 11 Sep 2002 17:46:30 -0700 (PDT) Message-ID: <3D7FE4D2.8DB9DA71@cisco.com> Date: Wed, 11 Sep 2002 17:50:26 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brian.wyld@eloquant.com CC: "'David R. Oran'" , speechsc@ietf.org Subject: Re: [Speechsc] WGLC for Requirements draft References: <001a01c259e6$8e735b30$8300a8c0@hq.eloquant.com> Content-Type: multipart/mixed; boundary="------------161B33DC27F0715592C5690D" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------161B33DC27F0715592C5690D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian Wyld wrote: > > > > > > MUST define how RTP sessions included in a speechsc > > session are identified > > > MUST be capable of using a single control channel during : > > > - a single session > > > - multiple sessions serially > > > - multiple sessions in parallel > > > > Not sure what you mean by single control channel during > > multiple sessions > > serially or parallely. Could you please elaborate. > > Multiple serial use > - Open a control channel client->server > - setup session A > - execute 1-N operations (eg TTS generation) > - close session A > - setup session B > - execute 1-N operations (eg TTS generation) > - close session B > - etc > - close control channel > > Multiple parallel use > - Open a control channel client->server > - setup session A > - setup session B (C, D etc) > - execute operation on A (eg TTS generation) > - execute operation on B(eg TTS generation) > - repeat until done > - close session A > - close session B > - close control channel By Control channel, if you are refering to a TCP connection, where by multiple Speechsc sessions are setup and executed over single TCP session between the client and the server. I would agree. > > > > > > > > MUST be capable of using a single session for > > > - a single operation of a single type (single utterance > > recognition) > > > - multiple operations of the same type (use of TTS > > channel during a > > > call) > > > - multiple operations of different types (TTS/ASR > > server, ASR/SR server) > > > > > > > Within a single session established to a SpeechSC > > server(meaning a single > > control session with an established RTP pipe), I agree we > > should be able to > > allocate a recognition resource and do multiple ASR > > operations one after the > > other. Within the the same session, we should also be able > > allocate a SV and do > > one or more SV operations in sequence. When you are talk > > about parallely, if you > > are refering to the case of having a SV and an ASR operation > > active parallely in > > the same session. I agree. > > With TTS I would agree, parallel operation should be > > possible, IF we do end up > > with a single protocol for ASR, TTS and SV. > > Yup, thats what I meant. > > [snip] > > > - (last para in seciotn 7) change "The ASR Server SHOULD > > support sharing > > > grammars across sessions...." to "The SPEECHSC framework > > MUST support a > > > means of requesting the sharing of grammars across > > sessions....", and add > > > that "ASR server SHOULD support this functionality". [ie > > the protocol must > > > define the mechanism, but the server may not implement it] > > > > > > > Is this for efficiency in a downloading and compiling large grammars? > > Wouldn't caching fetched/compiledd grammars addrerss the > > problem. Would we still > > need global or shared grammars, if we had caching and ways of > > controlling > > caching of grammars on the speechsc server??? > > Caching achieves the same goal but the first user of the grammar pays the > compilation latency. Otherwise yes, I'm just requesting a means of providing > caching hints to the server. I agree. Please refer to draft-shanmugham-mrcp-02.txt for how MRCP provides caching hints to the server. Thx, Sarvi > > > > > > > > Anyway, thats enough for now..... > > And again, bedtime... > > Brian > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc --------------161B33DC27F0715592C5690D Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Sarvi tel;work:408-527-4875 x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Group adr:;;;;;; version:2.1 email;internet:sarvi@cisco.com title:Technical Leader fn:Sarvi Shanmugham end:vcard --------------161B33DC27F0715592C5690D-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Sep 12 03:40:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15446 for ; Thu, 12 Sep 2002 03:40:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8C7flo19618 for speechsc-archive@odin.ietf.org; Thu, 12 Sep 2002 03:41:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8C7fkv19615 for ; Thu, 12 Sep 2002 03:41:46 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15422 for ; Thu, 12 Sep 2002 03:39:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8C7f9v19575; Thu, 12 Sep 2002 03:41:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8C7dvv19486 for ; Thu, 12 Sep 2002 03:39:57 -0400 Received: from ahuumrelay1.ams.ops.eu.uu.net (ahuumrelay1.ams.ops.eu.uu.net [195.129.70.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15364 for ; Thu, 12 Sep 2002 03:38:05 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay1.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8C7d4T26564; Thu, 12 Sep 2002 07:39:04 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 80F6F3B6BC; Thu, 12 Sep 2002 03:38:28 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'Sarvi Shanmugham'" Cc: "'David R. Oran'" , Subject: RE: [Speechsc] WGLC for Requirements draft Date: Thu, 12 Sep 2002 09:38:20 +0200 Message-ID: <001f01c25a2f$5e48d770$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3D7FE4D2.8DB9DA71@cisco.com> Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sarvi, > By Control channel, if you are refering to a TCP connection, > where by multiple > Speechsc sessions are setup and executed over single TCP > session between the > client and the server. > I would agree. I didn't want to prejudge the use of TCP :-), but yes. > > Caching achieves the same goal but the first user of the > grammar pays the > > compilation latency. Otherwise yes, I'm just requesting a > means of providing > > caching hints to the server. > > I agree. > Please refer to draft-shanmugham-mrcp-02.txt for how MRCP > provides caching hints > to the server. Indeed, MRCP covers this point, I just wanted to ensure the requirements doc captured the need. (in fact I was thinking about the requirement being to have perhaps an explicit "pre-define this grammar" method as MRCP proposed) Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : Sarvi Shanmugham [mailto:sarvi@cisco.com] > Envoye : Thursday, September 12, 2002 02:50 > A : brian.wyld@eloquant.com > Cc : 'David R. Oran'; speechsc@ietf.org > Objet : Re: [Speechsc] WGLC for Requirements draft > > > > > Brian Wyld wrote: > > > > > > > > > MUST define how RTP sessions included in a speechsc > > > session are identified > > > > MUST be capable of using a single control channel during : > > > > - a single session > > > > - multiple sessions serially > > > > - multiple sessions in parallel > > > > > > Not sure what you mean by single control channel during > > > multiple sessions > > > serially or parallely. Could you please elaborate. > > > > Multiple serial use > > - Open a control channel client->server > > - setup session A > > - execute 1-N operations (eg TTS generation) > > - close session A > > - setup session B > > - execute 1-N operations (eg TTS generation) > > - close session B > > - etc > > - close control channel > > > > Multiple parallel use > > - Open a control channel client->server > > - setup session A > > - setup session B (C, D etc) > > - execute operation on A (eg TTS generation) > > - execute operation on B(eg TTS generation) > > - repeat until done > > - close session A > > - close session B > > - close control channel > > By Control channel, if you are refering to a TCP connection, > where by multiple > Speechsc sessions are setup and executed over single TCP > session between the > client and the server. > I would agree. > > > > > > > > > > > > > MUST be capable of using a single session for > > > > - a single operation of a single type (single utterance > > > recognition) > > > > - multiple operations of the same type (use of TTS > > > channel during a > > > > call) > > > > - multiple operations of different types (TTS/ASR > > > server, ASR/SR server) > > > > > > > > > > Within a single session established to a SpeechSC > > > server(meaning a single > > > control session with an established RTP pipe), I agree we > > > should be able to > > > allocate a recognition resource and do multiple ASR > > > operations one after the > > > other. Within the the same session, we should also be able > > > allocate a SV and do > > > one or more SV operations in sequence. When you are talk > > > about parallely, if you > > > are refering to the case of having a SV and an ASR operation > > > active parallely in > > > the same session. I agree. > > > With TTS I would agree, parallel operation should be > > > possible, IF we do end up > > > with a single protocol for ASR, TTS and SV. > > > > Yup, thats what I meant. > > > > [snip] > > > > - (last para in seciotn 7) change "The ASR Server SHOULD > > > support sharing > > > > grammars across sessions...." to "The SPEECHSC framework > > > MUST support a > > > > means of requesting the sharing of grammars across > > > sessions....", and add > > > > that "ASR server SHOULD support this functionality". [ie > > > the protocol must > > > > define the mechanism, but the server may not implement it] > > > > > > > > > > Is this for efficiency in a downloading and compiling > large grammars? > > > Wouldn't caching fetched/compiledd grammars addrerss the > > > problem. Would we still > > > need global or shared grammars, if we had caching and ways of > > > controlling > > > caching of grammars on the speechsc server??? > > > > Caching achieves the same goal but the first user of the > grammar pays the > > compilation latency. Otherwise yes, I'm just requesting a > means of providing > > caching hints to the server. > > I agree. > Please refer to draft-shanmugham-mrcp-02.txt for how MRCP > provides caching hints > to the server. > > Thx, > Sarvi > > > > > > > > > > > > > Anyway, thats enough for now..... > > > > And again, bedtime... > > > > Brian > > > > > _______________________________________________ > > > Speechsc mailing list > > > Speechsc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 13 13:58:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13939 for ; Fri, 13 Sep 2002 13:58:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8DHxiQ07001 for speechsc-archive@odin.ietf.org; Fri, 13 Sep 2002 13:59:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DHxiv06998 for ; Fri, 13 Sep 2002 13:59:44 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13913 for ; Fri, 13 Sep 2002 13:57:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DHx6v06954; Fri, 13 Sep 2002 13:59:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DHujv06868 for ; Fri, 13 Sep 2002 13:56:45 -0400 Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13833 for ; Fri, 13 Sep 2002 13:54:57 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g8DHufS25132 for ; Fri, 13 Sep 2002 13:56:41 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF SPEECHSC" Date: Fri, 13 Sep 2002 13:56:41 -0400 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Speechsc] Call for Document Contributors Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One of our milestones is to deliver an analysis of existing protocols and to what extent they meet the requirements set out in the requirements draft. A model document from another work group would be http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-05.txt Brian Wyld will be the document editor. We need writers for the following sections: RTSP Web Services (HTTP/SOAP) BEEP SIP If you have a favorite protocol that you think should be on the list, please write the section! Please contact Brian directly or one of the co-chairs if you are able to work on a section or two. -- - Eric _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 13 14:56:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15695 for ; Fri, 13 Sep 2002 14:56:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8DIvdp10213 for speechsc-archive@odin.ietf.org; Fri, 13 Sep 2002 14:57:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DIvdv10210 for ; Fri, 13 Sep 2002 14:57:39 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15689 for ; Fri, 13 Sep 2002 14:55:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DIv4v10198; Fri, 13 Sep 2002 14:57:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DIurv10182 for ; Fri, 13 Sep 2002 14:56:53 -0400 Received: from server1.omnistarinc.com (omnistarinc.com [209.61.189.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15666 for ; Fri, 13 Sep 2002 14:55:05 -0400 (EDT) Received: from xcelcorp.com (gsine04.ny.us.ibm.com [32.97.182.44]) (authenticated) by server1.omnistarinc.com (8.11.6/8.11.6) with ESMTP id g8DIuiX01647; Fri, 13 Sep 2002 14:56:44 -0400 Message-ID: <3D8234E6.C956BE7F@xcelcorp.com> Date: Fri, 13 Sep 2002 14:56:38 -0400 From: Jiten Goel X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: eburger@snowshore.com CC: IETF SPEECHSC , brian.wyld@eloquant.com Subject: Re: [Speechsc] Call for Document Contributors References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, Brian I can volunteer for one of the protocol RTSP or SIP. -Jiten Eric Burger wrote: > One of our milestones is to deliver an analysis of existing protocols and to > what extent they meet the requirements set out in the requirements draft. A > model document from another work group would be > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-05.txt > > Brian Wyld will be the document editor. We need > writers for the following sections: > RTSP > Web Services (HTTP/SOAP) > BEEP > SIP > If you have a favorite protocol that you think should be on the list, please > write the section! > > Please contact Brian directly or one of the co-chairs if you are able to > work on a section or two. > > -- > - Eric > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 13 15:01:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15853 for ; Fri, 13 Sep 2002 15:01:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8DJ2bw10404 for speechsc-archive@odin.ietf.org; Fri, 13 Sep 2002 15:02:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DJ2bv10401 for ; Fri, 13 Sep 2002 15:02:37 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15807 for ; Fri, 13 Sep 2002 15:00:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DJ23v10372; Fri, 13 Sep 2002 15:02:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DJ14v10339 for ; Fri, 13 Sep 2002 15:01:04 -0400 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15738 for ; Fri, 13 Sep 2002 14:59:16 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8DJ0RvI023252; Fri, 13 Sep 2002 15:00:27 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8DJ0Oog017350; Fri, 13 Sep 2002 15:00:24 -0400 Subject: Re: [Speechsc] Call for Document Contributors To: Jiten Goel Cc: brian.wyld@eloquant.com, eburger@snowshore.com, IETF SPEECHSC , speechsc-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Stephane Maes Date: Fri, 13 Sep 2002 15:00:19 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09042002A|September 04, 2002) at 09/13/2002 15:00:24 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8DJ14v10340 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I volunteer to contribute; in particular on web service and SOAP Stephane ___ Dr. Stéphane H. Maes, smaes@us.ibm.com Mobile Architecture and Standards - PvC Division, IBM T.J. Watson Research Center, 1101 Kitchawan Road / PO BOX 218, Yorktown Heights, NY 10598, USA. Ph: (914)-945-2908; TL: 862; Fax: (914)-945-4490 Jiten Goel cc: IETF SPEECHSC , brian.wyld@eloquant.com Sent by: Subject: Re: [Speechsc] Call for Document Contributors speechsc-admin@ie tf.org 09/13/2002 02:56 PM Eric, Brian I can volunteer for one of the protocol RTSP or SIP. -Jiten Eric Burger wrote: > One of our milestones is to deliver an analysis of existing protocols and to > what extent they meet the requirements set out in the requirements draft. A > model document from another work group would be > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-05.txt > > Brian Wyld will be the document editor. We need > writers for the following sections: > RTSP > Web Services (HTTP/SOAP) > BEEP > SIP > If you have a favorite protocol that you think should be on the list, please > write the section! > > Please contact Brian directly or one of the co-chairs if you are able to > work on a section or two. > > -- > - Eric > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sun Sep 15 17:31:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11413 for ; Sun, 15 Sep 2002 17:31:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8FLWgh14326 for speechsc-archive@odin.ietf.org; Sun, 15 Sep 2002 17:32:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8FLWgv14323 for ; Sun, 15 Sep 2002 17:32:42 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11396 for ; Sun, 15 Sep 2002 17:30:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8FLWAv14309; Sun, 15 Sep 2002 17:32:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8FLViv14294 for ; Sun, 15 Sep 2002 17:31:44 -0400 Received: from ahuumrelay0.ams.ops.eu.uu.net (ahuumrelay0.ams.ops.eu.uu.net [195.129.70.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11379 for ; Sun, 15 Sep 2002 17:29:54 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay0.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8FLV6X21582; Sun, 15 Sep 2002 21:31:07 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 290A13B6BC; Sun, 15 Sep 2002 17:30:26 -0400 (EDT) Reply-To: From: "Brian Wyld" To: , "'IETF SPEECHSC'" Subject: RE: [Speechsc] Call for Document Contributors Date: Sun, 15 Sep 2002 23:29:58 +0200 Message-ID: <007401c25cff$0b445a40$8300a8c0@hq.eloquant.com> 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Thanks Eric for the kickoff. So far I have volunteers as follows: RTSP : Jiten Goel SIP : Brian Marquette, Jiten Goel Web Services : Stephane Maes I still need someone for BEEP (anyone?). No-one has yet suggested other candidate protocols..... I will be aiming to use the example doc that Eric pointed to as the framework - I will send out the basic doc in the next week. For info, I am in Europe (WET = GMT+1) so email is your best bet.... Thanks Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Eric Burger > Envoyé : Friday, September 13, 2002 19:57 > À : IETF SPEECHSC > Objet : [Speechsc] Call for Document Contributors > > > One of our milestones is to deliver an analysis of existing > protocols and to > what extent they meet the requirements set out in the > requirements draft. A > model document from another work group would be > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > -eval-05.txt > > Brian Wyld will be the document > editor. We need > writers for the following sections: > RTSP > Web Services (HTTP/SOAP) > BEEP > SIP > If you have a favorite protocol that you think should be on > the list, please > write the section! > > Please contact Brian directly or one of the co-chairs if you > are able to > work on a section or two. > > -- > - Eric > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Sep 16 08:21:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01885 for ; Mon, 16 Sep 2002 08:21:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GCMeV26991 for speechsc-archive@odin.ietf.org; Mon, 16 Sep 2002 08:22:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GCMev26988 for ; Mon, 16 Sep 2002 08:22:40 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01855 for ; Mon, 16 Sep 2002 08:20:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GCM6v26944; Mon, 16 Sep 2002 08:22:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GCKav26843 for ; Mon, 16 Sep 2002 08:20:36 -0400 Received: from speechworks.com (valmiki.speechworks.com [63.113.17.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01764 for ; Mon, 16 Sep 2002 08:18:49 -0400 (EDT) Received: from vishnu.speechworks.com (mailhost.speechworks.com [206.234.64.17]) by speechworks.com (8.10.2+Sun/8.9.3) with ESMTP id g8GCPjF19191; Mon, 16 Sep 2002 08:25:45 -0400 (EDT) Received: from whitney (localhost [127.0.0.1]) by vishnu.speechworks.com (8.10.2+Sun/8.9.3) with SMTP id g8GCKWC12121; Mon, 16 Sep 2002 08:20:32 -0400 (EDT) From: "Brian Eberman" To: , , "'IETF SPEECHSC'" Subject: RE: [Speechsc] Call for Document Contributors Date: Mon, 16 Sep 2002 08:20:31 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <007401c25cff$0b445a40$8300a8c0@hq.eloquant.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I can handle BEEP. -Brian Eberman Director Development Product Management and Services SpeechWorks International 695 Atlantic Avenue Boston, MA 02111 617 428 4444 -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Brian Wyld Sent: Sunday, September 15, 2002 5:30 PM To: eburger@snowshore.com; 'IETF SPEECHSC' Subject: RE: [Speechsc] Call for Document Contributors Hi, Thanks Eric for the kickoff. So far I have volunteers as follows: RTSP : Jiten Goel SIP : Brian Marquette, Jiten Goel Web Services : Stephane Maes I still need someone for BEEP (anyone?). No-one has yet suggested other candidate protocols..... I will be aiming to use the example doc that Eric pointed to as the framework - I will send out the basic doc in the next week. For info, I am in Europe (WET = GMT+1) so email is your best bet.... Thanks Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Eric Burger > Envoyé : Friday, September 13, 2002 19:57 > À : IETF SPEECHSC > Objet : [Speechsc] Call for Document Contributors > > > One of our milestones is to deliver an analysis of existing > protocols and to > what extent they meet the requirements set out in the > requirements draft. A > model document from another work group would be > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > -eval-05.txt > > Brian Wyld will be the document > editor. We need > writers for the following sections: > RTSP > Web Services (HTTP/SOAP) > BEEP > SIP > If you have a favorite protocol that you think should be on > the list, please > write the section! > > Please contact Brian directly or one of the co-chairs if you > are able to > work on a section or two. > > -- > - Eric > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Sep 16 15:16:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14766 for ; Mon, 16 Sep 2002 15:16:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GJHhq18532 for speechsc-archive@odin.ietf.org; Mon, 16 Sep 2002 15:17:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GJHgv18529 for ; Mon, 16 Sep 2002 15:17:42 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14755 for ; Mon, 16 Sep 2002 15:15:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GJH7v18493; Mon, 16 Sep 2002 15:17:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GJG7v18442 for ; Mon, 16 Sep 2002 15:16:07 -0400 Received: from server1.omnistarinc.com (omnistarinc.com [209.61.189.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14699 for ; Mon, 16 Sep 2002 15:14:16 -0400 (EDT) Received: from xcelcorp.com (gsine04.ny.us.ibm.com [32.97.182.44]) (authenticated) by server1.omnistarinc.com (8.11.6/8.11.6) with ESMTP id g8GJFsU02427; Mon, 16 Sep 2002 15:15:55 -0400 Message-ID: <3D862DE1.CA6DF94@xcelcorp.com> Date: Mon, 16 Sep 2002 15:15:46 -0400 From: Jiten Goel X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: brian.wyld@eloquant.com CC: Brian Eberman , eburger@snowshore.com, "'IETF SPEECHSC'" Subject: Re: [Speechsc] Call for Document Contributors References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Brian W, Did u look into the legal issues for the RTSP content you have for me? I have started working on the RTSP for the framework. Brain M: Please let me know whatever is good for you. I can help you on couple of sections for SIP. -Jiten Brian Eberman wrote: > I can handle BEEP. > -Brian Eberman > Director Development Product Management and Services > SpeechWorks International > 695 Atlantic Avenue > Boston, MA 02111 > 617 428 4444 > > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf > Of Brian Wyld > Sent: Sunday, September 15, 2002 5:30 PM > To: eburger@snowshore.com; 'IETF SPEECHSC' > Subject: RE: [Speechsc] Call for Document Contributors > > Hi, > > Thanks Eric for the kickoff. So far I have volunteers as follows: > RTSP : Jiten Goel > SIP : Brian Marquette, Jiten Goel > Web Services : Stephane Maes > > I still need someone for BEEP (anyone?). > > No-one has yet suggested other candidate protocols..... > > I will be aiming to use the example doc that Eric pointed to as the > framework - I will send out the basic doc in the next week. > > For info, I am in Europe (WET = GMT+1) so email is your best bet.... > > Thanks > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > > -----Message d'origine----- > > De : speechsc-admin@ietf.org > > [mailto:speechsc-admin@ietf.org]De la part > > de Eric Burger > > Envoyé : Friday, September 13, 2002 19:57 > > À : IETF SPEECHSC > > Objet : [Speechsc] Call for Document Contributors > > > > > > One of our milestones is to deliver an analysis of existing > > protocols and to > > what extent they meet the requirements set out in the > > requirements draft. A > > model document from another work group would be > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > > -eval-05.txt > > > > Brian Wyld will be the document > > editor. We need > > writers for the following sections: > > RTSP > > Web Services (HTTP/SOAP) > > BEEP > > SIP > > If you have a favorite protocol that you think should be on > > the list, please > > write the section! > > > > Please contact Brian directly or one of the co-chairs if you > > are able to > > work on a section or two. > > > > -- > > - Eric > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Sep 16 17:10:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17523 for ; Mon, 16 Sep 2002 17:10:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GLBcS24505 for speechsc-archive@odin.ietf.org; Mon, 16 Sep 2002 17:11:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GLBcv24502 for ; Mon, 16 Sep 2002 17:11:38 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17506 for ; Mon, 16 Sep 2002 17:09:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GLB6v24480; Mon, 16 Sep 2002 17:11:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GLAYv24454 for ; Mon, 16 Sep 2002 17:10:34 -0400 Received: from ahuumrelay3.ams.ops.eu.uu.net (ahuumrelay3.ams.ops.eu.uu.net [195.129.70.156]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17458 for ; Mon, 16 Sep 2002 17:08:43 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay3.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8GL9uH07917; Mon, 16 Sep 2002 21:09:56 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id D250A3B6BC; Mon, 16 Sep 2002 17:09:14 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'Brian Eberman'" , , "'IETF SPEECHSC'" Subject: RE: [Speechsc] Call for Document Contributors Date: Mon, 16 Sep 2002 21:28:48 +0200 Message-ID: <00a801c25dc5$4b3bb5a0$8300a8c0@hq.eloquant.com> 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Thanks Brian, that's great. I see that its going to be a rule that all contributors change their name to Brian.... BrianW [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : Brian Eberman [mailto:bse@speechworks.com] > Envoyé : Monday, September 16, 2002 14:21 > À : brian.wyld@eloquant.com; eburger@snowshore.com; 'IETF SPEECHSC' > Objet : RE: [Speechsc] Call for Document Contributors > > > I can handle BEEP. > -Brian Eberman > Director Development Product Management and Services > SpeechWorks International > 695 Atlantic Avenue > Boston, MA 02111 > 617 428 4444 > > > -----Original Message----- > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]On Behalf > Of Brian Wyld > Sent: Sunday, September 15, 2002 5:30 PM > To: eburger@snowshore.com; 'IETF SPEECHSC' > Subject: RE: [Speechsc] Call for Document Contributors > > > Hi, > > Thanks Eric for the kickoff. So far I have volunteers as follows: > RTSP : Jiten Goel > SIP : Brian Marquette, Jiten Goel > Web Services : Stephane Maes > > I still need someone for BEEP (anyone?). > > No-one has yet suggested other candidate protocols..... > > I will be aiming to use the example doc that Eric pointed to as the > framework - I will send out the basic doc in the next week. > > For info, I am in Europe (WET = GMT+1) so email is your best bet.... > > Thanks > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > > -----Message d'origine----- > > De : speechsc-admin@ietf.org > > [mailto:speechsc-admin@ietf.org]De la part > > de Eric Burger > > Envoyé : Friday, September 13, 2002 19:57 > > À : IETF SPEECHSC > > Objet : [Speechsc] Call for Document Contributors > > > > > > One of our milestones is to deliver an analysis of existing > > protocols and to > > what extent they meet the requirements set out in the > > requirements draft. A > > model document from another work group would be > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > > -eval-05.txt > > > > Brian Wyld will be the document > > editor. We need > > writers for the following sections: > > RTSP > > Web Services (HTTP/SOAP) > > BEEP > > SIP > > If you have a favorite protocol that you think should be on > > the list, please > > write the section! > > > > Please contact Brian directly or one of the co-chairs if you > > are able to > > work on a section or two. > > > > -- > > - Eric > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Sep 16 17:40:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18067 for ; Mon, 16 Sep 2002 17:40:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GLfcE25752 for speechsc-archive@odin.ietf.org; Mon, 16 Sep 2002 17:41:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GLfcv25749 for ; Mon, 16 Sep 2002 17:41:38 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18051 for ; Mon, 16 Sep 2002 17:39:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GLf4v25737; Mon, 16 Sep 2002 17:41:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GLeVv25709 for ; Mon, 16 Sep 2002 17:40:31 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18031 for ; Mon, 16 Sep 2002 17:38:38 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8GLdqW4022954; Mon, 16 Sep 2002 14:39:52 -0700 (PDT) Received: from cisco.com (dhcp-128-107-139-27.cisco.com [128.107.139.27]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFD39125; Mon, 16 Sep 2002 14:35:54 -0700 (PDT) Message-ID: <3D864FA5.CBEB56D4@cisco.com> Date: Mon, 16 Sep 2002 14:39:49 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brian.wyld@eloquant.com CC: eburger@snowshore.com, "'IETF SPEECHSC'" Subject: Re: [Speechsc] Call for Document Contributors References: <007401c25cff$0b445a40$8300a8c0@hq.eloquant.com> Content-Type: multipart/mixed; boundary="------------A7C549FF16B0913689955A4C" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------A7C549FF16B0913689955A4C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit MRCP is still a candidate for evaluation, and I offer to do it. Even if not as is, there is value in looking into how it can be evolved to meet the requirement or what can be leveraged. Sarvi Brian Wyld wrote: > Hi, > > Thanks Eric for the kickoff. So far I have volunteers as follows: > RTSP : Jiten Goel > SIP : Brian Marquette, Jiten Goel > Web Services : Stephane Maes > > I still need someone for BEEP (anyone?). > > No-one has yet suggested other candidate protocols..... > > I will be aiming to use the example doc that Eric pointed to as the > framework - I will send out the basic doc in the next week. > > For info, I am in Europe (WET = GMT+1) so email is your best bet.... > > Thanks > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > > -----Message d'origine----- > > De : speechsc-admin@ietf.org > > [mailto:speechsc-admin@ietf.org]De la part > > de Eric Burger > > Envoyé : Friday, September 13, 2002 19:57 > > À : IETF SPEECHSC > > Objet : [Speechsc] Call for Document Contributors > > > > > > One of our milestones is to deliver an analysis of existing > > protocols and to > > what extent they meet the requirements set out in the > > requirements draft. A > > model document from another work group would be > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > > -eval-05.txt > > > > Brian Wyld will be the document > > editor. We need > > writers for the following sections: > > RTSP > > Web Services (HTTP/SOAP) > > BEEP > > SIP > > If you have a favorite protocol that you think should be on > > the list, please > > write the section! > > > > Please contact Brian directly or one of the co-chairs if you > > are able to > > work on a section or two. > > > > -- > > - Eric > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc --------------A7C549FF16B0913689955A4C Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Sarvi tel;work:408-527-4875 x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Group adr:;;;;;; version:2.1 email;internet:sarvi@cisco.com title:Technical Leader fn:Sarvi Shanmugham end:vcard --------------A7C549FF16B0913689955A4C-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Sep 16 18:09:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18623 for ; Mon, 16 Sep 2002 18:09:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GMAb126986 for speechsc-archive@odin.ietf.org; Mon, 16 Sep 2002 18:10:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GMAbv26983 for ; Mon, 16 Sep 2002 18:10:37 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18615 for ; Mon, 16 Sep 2002 18:08:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GMA5v26971; Mon, 16 Sep 2002 18:10:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GM9av26947 for ; Mon, 16 Sep 2002 18:09:36 -0400 Received: from teleramail.telera.com (teleramail.telera.com [63.113.16.132] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18589 for ; Mon, 16 Sep 2002 18:07:42 -0400 (EDT) Received: by mail.telera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Sep 2002 15:08:46 -0700 Message-ID: <78993285C0CAD3118B42009027E505BC05F1BFD3@mail.telera.com> From: Rajiv Dharmadhikari To: brian.wyld@eloquant.com Cc: eburger@snowshore.com, "'IETF SPEECHSC'" Subject: RE: [Speechsc] Call for Document Contributors Date: Mon, 16 Sep 2002 15:08:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8GM9av26948 Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Brian, I would like to volunteer for RTSP and SIP. -Rajiv > -----Original Message----- > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > Sent: Monday, September 16, 2002 2:40 PM > To: brian.wyld@eloquant.com > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > Subject: Re: [Speechsc] Call for Document Contributors > > > MRCP is still a candidate for evaluation, and I offer to do it. > Even if not as is, there is value in looking into how it can > be evolved > to meet the requirement or what can be leveraged. > > Sarvi > > Brian Wyld wrote: > > > Hi, > > > > Thanks Eric for the kickoff. So far I have volunteers as follows: > > RTSP : Jiten Goel > > SIP : Brian Marquette, Jiten Goel > > Web Services : Stephane Maes > > > > I still need someone for BEEP (anyone?). > > > > No-one has yet suggested other candidate protocols..... > > > > I will be aiming to use the example doc that Eric pointed to as the > > framework - I will send out the basic doc in the next week. > > > > For info, I am in Europe (WET = GMT+1) so email is your best bet.... > > > > Thanks > > > > Brian > > > > [Brian Wyld] [brian.wyld@eloquant.com] > > [Directeur General R&D] > > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > > [advanced solutions for telecoms and IT services] > > > > > -----Message d'origine----- > > > De : speechsc-admin@ietf.org > > > [mailto:speechsc-admin@ietf.org]De la part > > > de Eric Burger > > > Envoyé : Friday, September 13, 2002 19:57 > > > À : IETF SPEECHSC > > > Objet : [Speechsc] Call for Document Contributors > > > > > > > > > One of our milestones is to deliver an analysis of existing > > > protocols and to > > > what extent they meet the requirements set out in the > > > requirements draft. A > > > model document from another work group would be > > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > > > -eval-05.txt > > > > > > Brian Wyld will be the document > > > editor. We need > > > writers for the following sections: > > > RTSP > > > Web Services (HTTP/SOAP) > > > BEEP > > > SIP > > > If you have a favorite protocol that you think should be on > > > the list, please > > > write the section! > > > > > > Please contact Brian directly or one of the co-chairs if you > > > are able to > > > work on a section or two. > > > > > > -- > > > - Eric > > > > > > _______________________________________________ > > > Speechsc mailing list > > > Speechsc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 17 03:25:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06464 for ; Tue, 17 Sep 2002 03:25:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8H7Qh627527 for speechsc-archive@odin.ietf.org; Tue, 17 Sep 2002 03:26:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H7Qgv27524 for ; Tue, 17 Sep 2002 03:26:42 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06461 for ; Tue, 17 Sep 2002 03:24:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H7QAv27515; Tue, 17 Sep 2002 03:26:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H7P6v27448 for ; Tue, 17 Sep 2002 03:25:06 -0400 Received: from ahuumrelay1.ams.ops.eu.uu.net (ahuumrelay1.ams.ops.eu.uu.net [195.129.70.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06437 for ; Tue, 17 Sep 2002 03:23:09 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay1.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8H7OGT06551; Tue, 17 Sep 2002 07:24:16 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 0EF363B6BC; Tue, 17 Sep 2002 03:23:35 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'Rajiv Dharmadhikari'" Cc: , "'IETF SPEECHSC'" Subject: RE: [Speechsc] Call for Document Contributors Date: Tue, 17 Sep 2002 09:23:27 +0200 Message-ID: <00bc01c25e1b$1e4288c0$8300a8c0@hq.eloquant.com> 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <78993285C0CAD3118B42009027E505BC05F1BFD3@mail.telera.com> Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Ok Rajiv, can you organise that with Jiten (RTSP/SIP) and BrianM (SIP)? Perhaps arrange with them to each look at a different aspect of the protocol with the match to the requirements? A+ BrianW [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : Rajiv Dharmadhikari [mailto:rajiv@telera.com] > Envoyé : Tuesday, September 17, 2002 00:09 > À : brian.wyld@eloquant.com > Cc : eburger@snowshore.com; 'IETF SPEECHSC' > Objet : RE: [Speechsc] Call for Document Contributors > > > Brian, > > I would like to volunteer for RTSP and SIP. > > -Rajiv > > > -----Original Message----- > > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > > Sent: Monday, September 16, 2002 2:40 PM > > To: brian.wyld@eloquant.com > > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > > Subject: Re: [Speechsc] Call for Document Contributors > > > > > > MRCP is still a candidate for evaluation, and I offer to do it. > > Even if not as is, there is value in looking into how it can > > be evolved > > to meet the requirement or what can be leveraged. > > > > Sarvi > > > > Brian Wyld wrote: > > > > > Hi, > > > > > > Thanks Eric for the kickoff. So far I have volunteers as follows: > > > RTSP : Jiten Goel > > > SIP : Brian Marquette, Jiten Goel > > > Web Services : Stephane Maes > > > > > > I still need someone for BEEP (anyone?). > > > > > > No-one has yet suggested other candidate protocols..... > > > > > > I will be aiming to use the example doc that Eric pointed > to as the > > > framework - I will send out the basic doc in the next week. > > > > > > For info, I am in Europe (WET = GMT+1) so email is your > best bet.... > > > > > > Thanks > > > > > > Brian > > > > > > [Brian Wyld] [brian.wyld@eloquant.com] > > > [Directeur General R&D] > > > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > > > [advanced solutions for telecoms and IT services] > > > > > > > -----Message d'origine----- > > > > De : speechsc-admin@ietf.org > > > > [mailto:speechsc-admin@ietf.org]De la part > > > > de Eric Burger > > > > Envoyé : Friday, September 13, 2002 19:57 > > > > À : IETF SPEECHSC > > > > Objet : [Speechsc] Call for Document Contributors > > > > > > > > > > > > One of our milestones is to deliver an analysis of existing > > > > protocols and to > > > > what extent they meet the requirements set out in the > > > > requirements draft. A > > > > model document from another work group would be > > > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > > > > -eval-05.txt > > > > > > > > Brian Wyld will be the document > > > > editor. We need > > > > writers for the following sections: > > > > RTSP > > > > Web Services (HTTP/SOAP) > > > > BEEP > > > > SIP > > > > If you have a favorite protocol that you think should be on > > > > the list, please > > > > write the section! > > > > > > > > Please contact Brian directly or one of the co-chairs if you > > > > are able to > > > > work on a section or two. > > > > > > > > -- > > > > - Eric > > > > > > > > _______________________________________________ > > > > Speechsc mailing list > > > > Speechsc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > _______________________________________________ > > > Speechsc mailing list > > > Speechsc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 17 03:28:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06512 for ; Tue, 17 Sep 2002 03:28:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8H7TXx27623 for speechsc-archive@odin.ietf.org; Tue, 17 Sep 2002 03:29:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H7TXv27620 for ; Tue, 17 Sep 2002 03:29:33 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06509 for ; Tue, 17 Sep 2002 03:27:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H7T1v27602; Tue, 17 Sep 2002 03:29:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H7S4v27565 for ; Tue, 17 Sep 2002 03:28:04 -0400 Received: from ahuumrelay1.ams.ops.eu.uu.net (ahuumrelay1.ams.ops.eu.uu.net [195.129.70.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06493 for ; Tue, 17 Sep 2002 03:26:08 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay1.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8H7RDT06922; Tue, 17 Sep 2002 07:27:13 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 6DE233B6BC; Tue, 17 Sep 2002 03:26:32 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'Sarvi Shanmugham'" Cc: , "'IETF SPEECHSC'" Subject: RE: [Speechsc] Call for Document Contributors Date: Tue, 17 Sep 2002 09:26:24 +0200 Message-ID: <00bd01c25e1b$88112c70$8300a8c0@hq.eloquant.com> 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3D864FA5.CBEB56D4@cisco.com> Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Sounds good to me Sarvi. I think specifically for MRCP it would be good to have a list of points at which it _doesn't_ meet the speechsc requirements (since functionally it works :-) so that the possibilities of convergance (or not) are clear. A+ Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : Sarvi Shanmugham [mailto:sarvi@cisco.com] > Envoyé : Monday, September 16, 2002 23:40 > À : brian.wyld@eloquant.com > Cc : eburger@snowshore.com; 'IETF SPEECHSC' > Objet : Re: [Speechsc] Call for Document Contributors > > > MRCP is still a candidate for evaluation, and I offer to do it. > Even if not as is, there is value in looking into how it can > be evolved > to meet the requirement or what can be leveraged. > > Sarvi > > Brian Wyld wrote: > > > Hi, > > > > Thanks Eric for the kickoff. So far I have volunteers as follows: > > RTSP : Jiten Goel > > SIP : Brian Marquette, Jiten Goel > > Web Services : Stephane Maes > > > > I still need someone for BEEP (anyone?). > > > > No-one has yet suggested other candidate protocols..... > > > > I will be aiming to use the example doc that Eric pointed to as the > > framework - I will send out the basic doc in the next week. > > > > For info, I am in Europe (WET = GMT+1) so email is your best bet.... > > > > Thanks > > > > Brian > > > > [Brian Wyld] [brian.wyld@eloquant.com] > > [Directeur General R&D] > > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > > [advanced solutions for telecoms and IT services] > > > > > -----Message d'origine----- > > > De : speechsc-admin@ietf.org > > > [mailto:speechsc-admin@ietf.org]De la part > > > de Eric Burger > > > Envoyé : Friday, September 13, 2002 19:57 > > > À : IETF SPEECHSC > > > Objet : [Speechsc] Call for Document Contributors > > > > > > > > > One of our milestones is to deliver an analysis of existing > > > protocols and to > > > what extent they meet the requirements set out in the > > > requirements draft. A > > > model document from another work group would be > > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > > > -eval-05.txt > > > > > > Brian Wyld will be the document > > > editor. We need > > > writers for the following sections: > > > RTSP > > > Web Services (HTTP/SOAP) > > > BEEP > > > SIP > > > If you have a favorite protocol that you think should be on > > > the list, please > > > write the section! > > > > > > Please contact Brian directly or one of the co-chairs if you > > > are able to > > > work on a section or two. > > > > > > -- > > > - Eric > > > > > > _______________________________________________ > > > Speechsc mailing list > > > Speechsc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 17 10:57:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17771 for ; Tue, 17 Sep 2002 10:57:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HEwh119014 for speechsc-archive@odin.ietf.org; Tue, 17 Sep 2002 10:58:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HEwhv19011 for ; Tue, 17 Sep 2002 10:58:43 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17764 for ; Tue, 17 Sep 2002 10:56:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HEwCv18975; Tue, 17 Sep 2002 10:58:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HEvev18954 for ; Tue, 17 Sep 2002 10:57:40 -0400 Received: from server1.omnistarinc.com (omnistarinc.com [209.61.189.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17708 for ; Tue, 17 Sep 2002 10:55:50 -0400 (EDT) Received: from xcelcorp.com (gsine04.ny.us.ibm.com [32.97.182.44]) (authenticated) by server1.omnistarinc.com (8.11.6/8.11.6) with ESMTP id g8HEvSY14365; Tue, 17 Sep 2002 10:57:29 -0400 Message-ID: <3D8742D0.7DE0BBA@xcelcorp.com> Date: Tue, 17 Sep 2002 10:57:20 -0400 From: Jiten Goel X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: brian.wyld@eloquant.com CC: "'Rajiv Dharmadhikari'" , eburger@snowshore.com, "'IETF SPEECHSC'" Subject: Re: [Speechsc] Call for Document Contributors References: <00bc01c25e1b$1e4288c0$8300a8c0@hq.eloquant.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Brain, Rajiv Thanks for your interest. I don't think its a big deal for evaluation for RTSP. Let me come up with the draft and have your inputs for improvements. Pl let me know if that's okay with you. tnr /j Brian Wyld wrote: > Hi, > > Ok Rajiv, can you organise that with Jiten (RTSP/SIP) and BrianM (SIP)? > Perhaps arrange with them to each look at a different aspect of the protocol > with the match to the requirements? > > A+ > > BrianW > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > > -----Message d'origine----- > > De : Rajiv Dharmadhikari [mailto:rajiv@telera.com] > > Envoyé : Tuesday, September 17, 2002 00:09 > > À : brian.wyld@eloquant.com > > Cc : eburger@snowshore.com; 'IETF SPEECHSC' > > Objet : RE: [Speechsc] Call for Document Contributors > > > > > > Brian, > > > > I would like to volunteer for RTSP and SIP. > > > > -Rajiv > > > > > -----Original Message----- > > > From: Sarvi Shanmugham [mailto:sarvi@cisco.com] > > > Sent: Monday, September 16, 2002 2:40 PM > > > To: brian.wyld@eloquant.com > > > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > > > Subject: Re: [Speechsc] Call for Document Contributors > > > > > > > > > MRCP is still a candidate for evaluation, and I offer to do it. > > > Even if not as is, there is value in looking into how it can > > > be evolved > > > to meet the requirement or what can be leveraged. > > > > > > Sarvi > > > > > > Brian Wyld wrote: > > > > > > > Hi, > > > > > > > > Thanks Eric for the kickoff. So far I have volunteers as follows: > > > > RTSP : Jiten Goel > > > > SIP : Brian Marquette, Jiten Goel > > > > Web Services : Stephane Maes > > > > > > > > I still need someone for BEEP (anyone?). > > > > > > > > No-one has yet suggested other candidate protocols..... > > > > > > > > I will be aiming to use the example doc that Eric pointed > > to as the > > > > framework - I will send out the basic doc in the next week. > > > > > > > > For info, I am in Europe (WET = GMT+1) so email is your > > best bet.... > > > > > > > > Thanks > > > > > > > > Brian > > > > > > > > [Brian Wyld] [brian.wyld@eloquant.com] > > > > [Directeur General R&D] > > > > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > > > > [advanced solutions for telecoms and IT services] > > > > > > > > > -----Message d'origine----- > > > > > De : speechsc-admin@ietf.org > > > > > [mailto:speechsc-admin@ietf.org]De la part > > > > > de Eric Burger > > > > > Envoyé : Friday, September 13, 2002 19:57 > > > > > À : IETF SPEECHSC > > > > > Objet : [Speechsc] Call for Document Contributors > > > > > > > > > > > > > > > One of our milestones is to deliver an analysis of existing > > > > > protocols and to > > > > > what extent they meet the requirements set out in the > > > > > requirements draft. A > > > > > model document from another work group would be > > > > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > > > > > -eval-05.txt > > > > > > > > > > Brian Wyld will be the document > > > > > editor. We need > > > > > writers for the following sections: > > > > > RTSP > > > > > Web Services (HTTP/SOAP) > > > > > BEEP > > > > > SIP > > > > > If you have a favorite protocol that you think should be on > > > > > the list, please > > > > > write the section! > > > > > > > > > > Please contact Brian directly or one of the co-chairs if you > > > > > are able to > > > > > work on a section or two. > > > > > > > > > > -- > > > > > - Eric > > > > > > > > > > _______________________________________________ > > > > > Speechsc mailing list > > > > > Speechsc@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > > > _______________________________________________ > > > > Speechsc mailing list > > > > Speechsc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 17 16:07:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28448 for ; Tue, 17 Sep 2002 16:07:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HK8fG05933 for speechsc-archive@odin.ietf.org; Tue, 17 Sep 2002 16:08:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HK8fv05930 for ; Tue, 17 Sep 2002 16:08:41 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28438 for ; Tue, 17 Sep 2002 16:06:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HK85v05912; Tue, 17 Sep 2002 16:08:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HK7iv05895 for ; Tue, 17 Sep 2002 16:07:44 -0400 Received: from ahuumrelay2.ams.ops.eu.uu.net (ahuumrelay2.ams.ops.eu.uu.net [195.129.70.155]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28427 for ; Tue, 17 Sep 2002 16:05:53 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay2.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8HK77f09058 for ; Tue, 17 Sep 2002 20:07:07 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 99CEF3B6BC for ; Tue, 17 Sep 2002 16:06:25 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "Speechsc (E-mail)" Date: Tue, 17 Sep 2002 22:06:16 +0200 Message-ID: <00d301c25e85$af1bef20$8300a8c0@hq.eloquant.com> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Updated list of contributors Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Updated list: RTSP : Jiten Goel, Rajiv Dharmadhikari SIP : Brian Marquette, Jiten Goel Web Services : Stephane Maes MRCP draft : Sarvi Shanmugham BEEP : Brian Eberman Cutoff date for the draft is apparently 10/27. I suggest we try to have first draft sections for review sent to the list by end Sept, to allow for comments/re-work and then integration into a whole. Does this sound doable? Thanks guys, Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 17 17:49:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01768 for ; Tue, 17 Sep 2002 17:49:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HLoh112058 for speechsc-archive@odin.ietf.org; Tue, 17 Sep 2002 17:50:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HLohv12055 for ; Tue, 17 Sep 2002 17:50:43 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01752 for ; Tue, 17 Sep 2002 17:48:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HLoBv12029; Tue, 17 Sep 2002 17:50:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HLn3v11971 for ; Tue, 17 Sep 2002 17:49:03 -0400 Received: from ahuumrelay1.ams.ops.eu.uu.net (ahuumrelay1.ams.ops.eu.uu.net [195.129.70.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01695 for ; Tue, 17 Sep 2002 17:47:10 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay1.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8HLmQT09977 for ; Tue, 17 Sep 2002 21:48:26 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 9CDDD3B6BC; Tue, 17 Sep 2002 17:47:43 -0400 (EDT) Reply-To: From: "Brian Wyld" To: , "'Speechsc (E-mail)'" Subject: RE: [Speechsc] Updated list of contributors Date: Tue, 17 Sep 2002 22:29:26 +0200 Message-ID: <00e601c25e93$c6bf6270$8300a8c0@hq.eloquant.com> 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <00d301c25e85$af1bef20$8300a8c0@hq.eloquant.com> Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Correction : Rajiv is also interested in contributing on the SIP investigation. Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Brian Wyld > Envoyé : Tuesday, September 17, 2002 22:06 > À : Speechsc (E-mail) > Objet : [Speechsc] Updated list of contributors > > > Hi, > > Updated list: > > RTSP : Jiten Goel, Rajiv Dharmadhikari > SIP : Brian Marquette, Jiten Goel > Web Services : Stephane Maes > MRCP draft : Sarvi Shanmugham > BEEP : Brian Eberman > > Cutoff date for the draft is apparently 10/27. I suggest we > try to have > first draft sections for review sent to the list by end Sept, > to allow for > comments/re-work and then integration into a whole. > > Does this sound doable? > > Thanks guys, > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 17 17:59:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01975 for ; Tue, 17 Sep 2002 17:59:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HM0bD12367 for speechsc-archive@odin.ietf.org; Tue, 17 Sep 2002 18:00:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HM0av12364 for ; Tue, 17 Sep 2002 18:00:36 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01964 for ; Tue, 17 Sep 2002 17:58:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HM03v12325; Tue, 17 Sep 2002 18:00:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HLnJv11975 for ; Tue, 17 Sep 2002 17:49:19 -0400 Received: from ahuumrelay0.ams.ops.eu.uu.net (ahuumrelay0.ams.ops.eu.uu.net [195.129.70.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01702 for ; Tue, 17 Sep 2002 17:47:25 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay0.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8HLmaX26920; Tue, 17 Sep 2002 21:48:36 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id C61D93B6BC; Tue, 17 Sep 2002 17:47:47 -0400 (EDT) Reply-To: From: "Brian Wyld" To: , "'Speechsc (E-mail)'" Cc: "Mary Barnes (E-mail)" Subject: RE: [Speechsc] Protocol evaluation process Date: Tue, 17 Sep 2002 23:35:11 +0200 Message-ID: <00e801c25e93$d8070f60$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E9_01C25EA4.9B8FDF60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <00d301c25e85$af1bef20$8300a8c0@hq.eloquant.com> Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_00E9_01C25EA4.9B8FDF60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi, I have received from Mary Barnes (editor of the midcom protocol comparison doc) pointers to the templates and processes they used for the midcom WG. These seem an excellent basis for our work (thanks Mary). I therefore propose we use an evolution of her templates, and of the process. The process/timelines etc they used are documented in the slides used at the IETF 53 meeting: http://www.ietf.org/proceedings/02mar/slides/midcom-2/index.html Please all try to have a look at this, and indicate if there is any problem using the process defined. As for dates: 20th Sept - close of contributor intentions/protocols. Note that where there is more than one contributer / protocol, this is for collaberation, not for N individual drafts.... 30th Sept - first drafts per protocol : a first draft should be submitted to the list using the attached template (section 4 to be completed per protocol). Note the points in Mary's slides about "objectivity" and "completeness" of the evaluation.... 15th Oct - discussion and revision of drafts on list : all open issues raised to be thrashed to death and new drafts available 20th Oct - revised drafts incorporated into the final comparison doc for list review 27th Oct - final draft These are pretty close dates - the first drafts will need to be pretty complete (to avoid a lot of review or open issues) to meet them guys.... Just a note on document formats/editor: I hope Word2000 format doesn't cause a problem for anyone to create in. Output doc must be plain ASCII following the recommendations of RFC 3285 to convert to text from Word (I haven't actually read this RFC yet....) Comments? Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Brian Wyld > Envoyé : Tuesday, September 17, 2002 22:06 > À : Speechsc (E-mail) > Objet : [Speechsc] Updated list of contributors > > > Hi, > > Updated list: > > RTSP : Jiten Goel, Rajiv Dharmadhikari > SIP : Brian Marquette, Jiten Goel > Web Services : Stephane Maes > MRCP draft : Sarvi Shanmugham > BEEP : Brian Eberman > > Cutoff date for the draft is apparently 10/27. I suggest we > try to have > first draft sections for review sent to the list by end Sept, > to allow for > comments/re-work and then integration into a whole. > > Does this sound doable? > > Thanks guys, > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_00E9_01C25EA4.9B8FDF60 Content-Type: application/msword; name="protocol-evaluation-template-v0-1-w2K.doc" Content-Disposition: attachment; filename="protocol-evaluation-template-v0-1-w2K.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAVgAAAAAAAAAA EAAAWAAAAAEAAAD+////AAAAAFUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEATSAJBAAA+BK/AAAAAAAAEAAAAAAABAAAIyQAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA AAAJBBYAMkUAAIBXAACAVwAAaR0AAAAAAAC5AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAPQJAAAAAAAA9AkAAPQJ AAAAAAAA9AkAAAAAAAD0CQAAAAAAAPQJAAAAAAAA9AkAABQAAAAAAAAAAAAAAAgKAAAAAAAAABkA AAAAAAAAGQAAAAAAAAAZAAA4AAAAOBkAACwAAABkGQAARAAAAAgKAAAAAAAANi8AACoBAAC0GQAA VAEAAAgbAAAAAQAACBwAAAAAAAAIHAAAAAAAAAgcAAAAAAAACBwAANIBAADaHQAAlAAAAG4eAABM AAAAyCcAAAIAAADKJwAAAAAAAMonAAAAAAAAyicAAC0AAAD3JwAAYAMAAFcrAABgAwAAty4AACQA AABgMAAAIAIAAIAyAAByAAAA2y4AABUAAAAAAAAAAAAAAAAAAAAAAAAA9AkAAAAAAAC6HgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAIHAAAAAAAAAgcAAAAAAAAuh4AAAAAAAC6HgAAAAAAANsuAAAAAAAA TCAAAAAAAAD0CQAAAAAAAPQJAAAAAAAACBwAAAAAAAAAAAAAAAAAAAgcAAAAAAAA8C4AABYAAABM IAAAAAAAAEwgAAAAAAAATCAAAAAAAAC6HgAApgAAAPQJAAAAAAAACBwAAAAAAAD0CQAAAAAAAAgc AAAAAAAAyCcAAAAAAAAAAAAAAAAAAEwgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAuh4AAAAAAADIJwAAAAAAAEwgAADWAgAATCAAAAAAAAAiIwAA OgAAAAwnAAAsAAAA9AkAAAAAAAD0CQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATCcAAAAAAAAIHAAAAAAAAKgZAAAMAAAAENoeeI5e wgEICgAA+A4AAAAZAAAAAAAAYB8AAMoAAAA4JwAACgAAAAAAAAAAAAAATCcAAHwAAAAGLwAAMAAA ADYvAAAAAAAAQicAAAoAAADyMgAAAAAAACogAAAiAAAA8jIAAAAAAABMJwAAAAAAAEwgAAAAAAAA CAoAAAAAAAAICgAAAAAAAPQJAAAAAAAA9AkAAAAAAAD0CQAAAAAAAPQJAAAAAAAAAgDZAAAASW50 ZXJuZXQgRHJhZnQHQi4gV3lsZAcHRG9jdW1lbnQ6IGRyYWZ0LXNwZWVjaHNjLXByb3RvY29sLWV2 YWwtdGVtcGxhdGUudHh0B0VkaXRvcgcHRXhwaXJlczogRGVjZW1iZXIgEyBJRiATIFNBVkVEQVRF IFxAICJNIiBcKiBNRVJHRUZPUk1BVCAUMRUgPCA3IBMgU0FWRURBVEUgXEAgIllZWVkiIFwqIE1F UkdFRk9STUFUIBQyMDAyFSATIElGIBMgU0FWRURBVEUgXEAgIk0iIFwqIE1FUkdFRk9STUFUIBQx FSA+IDYgEyA9IFNBVkVEQVRFIFxAICJZWVlZIiBcKiBNRVJHRUZPUk1BVCAUMjAwMhUgKyAxIFwq IE1FUkdFRk9STUFUIBRFcnJvciEgTWlzc2luZyB0ZXN0IGNvbmRpdGlvbi4VICIiXCogTUVSR0VG T1JNQVQgFDIwMDIVEyBBU0sgIFwqIE1FUkdFRk9STUFUIBUHRWxvcXVhbnQHBwcTIFNBVkVEQVRF IFxAICJNTU1NIHl5eXkiIFwqIE1FUkdFRk9STUFUIBRTZXB0ZW1iZXIgMjAwMhUHBw1TUEVFQ0hT QyBQcm90b2NvbCBFdmFsdWF0aW9uIFRlbXBsYXRlDSANU3RhdHVzIG9mIHRoaXMgTWVtbyANDVRo aXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFu Y2Ugd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuIA0gICAgDUlu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91 cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBk b2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiANICAgIA1JbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bnkgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJl ZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iIA0gICAgDVRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBi ZSBhY2Nlc3NlZCBhdCANICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0 cy50eHQgDVRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4g YmUgYWNjZXNzZWQgYXQgDSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0gICAg DUFic3RyYWN0IA0NVGhpcyBkb2N1bWVudCBwcm92aWRlcyB0aGUgdGVtcGxhdGUgZm9yIHRoZSBj b250ZW50IHRvIGJlIGNvbnRhaW5lZCBpbiB0aGUgU1BFRUNIU0MgUHJvdG9jb2wgRXZhbHVhdGlv biBEb2N1bWVudC4gIFNlY3Rpb24gNCBwcm92aWRlcyB0aGUgcHJvcG9zZWQgY29udGVudCBmb3Ig dGhlIGJhc2lzIG9mIHRoZSBpbmRpdmlkdWFsIHByb3RvY29sIGNvbXBhcmlzb25zIGFnYWluc3Qg dGhlIFNQRUVDSFNDIHJlcXVpcmVtZW50cyBbMV0uDSANVGFibGUgb2YgQ29udGVudHMNDRMgVE9D IFxvICIyLTMiIFxoIFx6IFx0ICJSRkMgSGVhZGluZzEsMSxSRkMgSGVhZGluZzIsMiIgFDEuCU92 ZXJ2aWV3CRMgUEFHRVJFRiBfVG9jNDk5MDIxNSBcaCABFDEVDTIuCVByb3RvY29sIFByb3Bvc2Fs cwkTIFBBR0VSRUYgX1RvYzQ5OTAyMTYgXGggARQyFQ0zLglJdGVtIExldmVsIENvbXBsaWFuY2Ug RXZhbHVhdGlvbgkTIFBBR0VSRUYgX1RvYzQ5OTAyMTcgXGggARQyFQ0zLjEJUHJvdG9jb2wgbWFj aGluZXJ5CRMgUEFHRVJFRiBfVG9jNDk5MDIxOCBcaCABFDIVDTMuMglQcm90b2NvbCBzZW1hbnRp Y3MJEyBQQUdFUkVGIF9Ub2M0OTkwMjE5IFxoIAEUMhUNMy4zCUdlbmVyYWwgU2VjdXJpdHkgUmVx dWlyZW1lbnRzCRMgUEFHRVJFRiBfVG9jNDk5MDIyMCBcaCABFDIVDTQuCVByb3RvY29sIEV2YWx1 YXRpb24gU3VtbWFyaWVzCRMgUEFHRVJFRiBfVG9jNDk5MDIyMSBcaCABFDMVDTQuMQlQcm90b2Nv bCB4CRMgUEFHRVJFRiBfVG9jNDk5MDIyMiBcaCABFDMVDTUuCVNlY3VyaXR5IENvbnNpZGVyYXRp b25zCRMgUEFHRVJFRiBfVG9jNDk5MDIyMyBcaCABFDMVDTYuCVJlZmVyZW5jZXMJEyBQQUdFUkVG IF9Ub2M0OTkwMjI0IFxoIAEUNBUNFQ1PdmVydmlldyANICAgIA1UaGlzIGRvY3VtZW50IHByb3Zp ZGVzIHRoZSB0ZW1wbGF0ZSBmb3IgdGhlIGNvbnRlbnQgZm9yIHRoZSBTUEVFQ0hTQyBQcm90b2Nv bCBFdmFsdWF0aW9uIGRvY3VtZW50LiAgIA0gICAgDVRoaXMgc2VjdGlvbiB3aWxsIGNvbnRhaW4g YW4gb3ZlcnZpZXcgb2YgdGhlIHByb2Nlc3MuDQ1TZWN0aW9uIDIgY29udGFpbnMgYSBsaXN0IG9m IHRoZSBwcm9wb3NlZCBwcm90b2NvbHMgc3VibWl0dGVkIHRvIFdHLg0NU2VjdGlvbiAzIHByb3Zp ZGVzIGEgc3VtbWFyeSBvZiB0aGUgcHJvcG9zZWQgcHJvdG9jb2xzIGFnYWluc3QgdGhlIFJlcXVp cmVtZW50cyBhbmQgZnJhbWV3b3JrLiANDVNlY3Rpb24gNCBwcm92aWRlcyB0aGUgcHJvcG9zZWQg Y29udGVudCBmb3IgdGhlIGJhc2lzIG9mIHRoZSBpbmRpdmlkdWFsIHByb3RvY29sIGNvbXBhcmlz b25zIGFnYWluc3QgdGhlIFNQRUVDSFNDIHJlcXVpcmVtZW50cyBbMV0uICAgIA0gICAgDVByb3Rv Y29sIFByb3Bvc2Fscw0NVGhpcyBzZWN0aW9uIHdpbGwgY29udGFpbiBhIGxpc3Qgb2YgdGhlIHBy b3Bvc2VkIHByb3RvY29scyBzdWJtaXR0ZWQgdG8gdGhlIFNQRUVDSFNDIFdHIGZvciBjb25zaWRl cmF0aW9uIGJ5IHRoZSBkZWFkbGluZS4gDQ1JdGVtIExldmVsIENvbXBsaWFuY2UgRXZhbHVhdGlv bg0NVGhpcyBzZWN0aW9uIGNvbnRhaW5zIGEgcmV2aWV3IG9mIHRoZSBwcm90b2NvbJJzIGxldmVs IG9mIGNvbXBsaWFuY2UgdG8gZWFjaCBvZiB0aGUgU1BFRUNIU0MgUmVxdWlyZW1lbnRzIFsxXSBh cyBkZXJpdmVkIGZyb20gdGhlIHByb3Bvc2VkIHByb3RvY29sIGRvY3VtZW50cy4gVGhlIGZvbGxv d2luZyBrZXkgd2lsbCBiZSB1c2VkIHRvIGlkZW50aWZ5IHRoZSBsZXZlbCBvZiBjb21wbGlhbmN5 IG9mIGVhY2ggb2YgdGhlIGluZGl2aWR1YWwgcHJvdG9jb2xzOg0NVCA9IFRvdGFsIENvbXBsaWFu Y2UuICBNZWV0cyB0aGUgcmVxdWlyZW1lbnQgZnVsbHkuDVAgPSBQYXJ0aWFsIENvbXBsaWFuY2Uu ICBNZWV0cyBzb21lIGFzcGVjdCBvZiB0aGUgcmVxdWlyZW1lbnQuDVArID0gQ29tcGxpZW5jZSBw b3NzaWJsZS4gQ291bGQgbWVldCB0aGUgcmVxdWlyZW1lbnQgd2l0aCCTbmF0dXJhbJQgZXZvbHV0 aW9uIG9mIHRoZSBwcm90b2NvbC4gDUYgPSBGYWlsZWQgQ29tcGxpYW5jZS4gIERvZXMgbm90IG1l ZXQgdGhlIHJlcXVpcmVtZW50LiANDQ1Qcm90b2NvbCBtYWNoaW5lcnkNDVRoaXMgc2VjdGlvbiB3 aWxsIGNvbnRhaW4gdGhlIHJlcXVpcmVtZW50cyBzdW1tYXJ5IGZyb20gc2VjdGlvbiBYLnggb2Yg dGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBbMV0uDTMuMS4xCSA8IHRvIGJlIGNvbXBsZXRlZCA+ IA0NUHJvdG9jb2wgc2VtYW50aWNzDQ1UaGlzIHNlY3Rpb24gd2lsbCBjb250YWluIHRoZSByZXF1 aXJlbWVudHMgZnJvbSBzZWN0aW9uIFgueCBvZiB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IFsx XS4NDTMuMi4xCSA8IHRvIGJlIGNvbXBsZXRlZCA+DQ1HZW5lcmFsIFNlY3VyaXR5IFJlcXVpcmVt ZW50cw0NVGhpcyBzZWN0aW9uIHdpbGwgY29udGFpbiB0aGUgcmVxdWlyZW1lbnRzIGZyb20gc2Vj dGlvbiBYLnggb2YgdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBbMV0uDTMuMy4xCSA8IHRvIGJl IGNvbXBsZXRlZCA+DQ0gIA1Qcm90b2NvbCBFdmFsdWF0aW9uIFN1bW1hcmllcyANICAgIA1UbyBw cm92aWRlIHN0YW5kYWxvbmUgY29tcGxldGVuZXNzIGZvciB0aGlzIGRvY3VtZW50LCB0aGlzIHNl Y3Rpb24gY29udGFpbnMgYSBzdW1tYXJ5IG9mIGVhY2ggb2YgdGhlIHByb3RvY29sIGNvbXBhcmlz b25zLiBUaGUgY29tcGFyaXNvbnMgc2hvdWxkIGV4cGxpY2l0bHkgcmVmZXJlbmNlIHRoZSByZXF1 aXJlbWVudHMgYXMgZGVmaW5lZCBpbiBbMV0uIERlcGVuZGluZyB1cG9uIHRoZSBkZXRhaWwgcHJv dmlkZWQgaW4gZWFjaCBvZiB0aGUgY29tcGFyaXNvbnMsIHNvbWUgb2YgdGhpcyBpbmZvcm1hdGlv biBtYXkgYmUgaW5jbHVkZWQgaW4gYW4gYXBwZW5kaXguDQ1Qcm90b2NvbCB4IA0NNC4xLjEJIFBy b3RvY29sIHggQXJjaGl0ZWN0dXJhbCBNb2RlbCBhcyBjb21wYXJlZCB0byB0aGUgU1BFRUNIU0Mg QXJjaGl0ZWN0dXJhbCBGcmFtZXdvcmsNDVRoaXMgc2VjdGlvbiB3b3VsZCBjb250YWluIGEgZGVz Y3JpcHRpb24gb2YgdGhlIGtleSBhc3BlY3RzIG9mIHRoZSBhcmNoaXRlY3R1cmFsIG1vZGVsIG9m IHByb3RvY29sIFggYW5kIGEgY29tcGFyaXNvbiBvZiB0aGlzIG1vZGVsIGFnYWluc3QgdGhlIFNQ RUVDSFNDIGZyYW1ld29yaywgaGlnaGxpZ2h0aW5nIHRoZSBwcm9zL2NvbnMgb2YgdGhlIGFwcGxp Y2FiaWxpdHkgb2YgcHJvdG9jb2wgeCB0byBTUEVFQ0hTQy4NDTQuMS4yCSBTUEVFQ0hTQyByZXF1 aXJlbWVudHMgbWV0IGJ5IHByb3RvY29sIFguDQ1UaGlzIHNlY3Rpb24gY29udGFpbnMgYSBkZXNj cmlwdGlvbiBvZiB0aGUgU1BFRUNIU0MgcmVxdWlyZW1lbnRzIG1ldCBieSBwcm90b2NvbCBYLg0N NC4xLjMJIFNQRUVDSFNDIHJlcXVpcmVtZW50cyBwYXJ0aWFsbHkgbWV0IGJ5IHByb3RvY29sIFgu DQ1UaGlzIHNlY3Rpb24gY29udGFpbnMgYSBkZXNjcmlwdGlvbiBvZiB0aGUgU1BFRUNIU0MgcmVx dWlyZW1lbnRzIHBhcnRpYWxseSBtZXQgYnkgcHJvdG9jb2wgWC4gW05vdGU6IGlkZWFsbHksIHRo ZXJlIHdvdWxkIGJlIGZldyBvciBOT05FIG9mIHRoZXNlIHByb3ZpZGVkIHRoZSBTUEVFQ0hTQyBy ZXF1aXJlbWVudHMgaGF2ZSBiZWVuIGRlZmluZWQgYXQgdGhlIGFwcHJvcHJpYXRlIGxldmVsXS4g DQk0LjEuNAkgU1BFRUNIU0MgcmVxdWlyZW1lbnRzIGNhbiBiZSBtZXQgYnkgcHJvdG9jb2wgWCB3 aXRoIJNuYXR1cmFslCBldm9sdXRpb25zLg0NVGhpcyBzZWN0aW9uIGNvbnRhaW5zIGEgZGVzY3Jp cHRpb24gb2YgdGhlIFNQRUVDSFNDIHJlcXVpcmVtZW50cyBub3QgY3VycmVudGx5IG1ldCBieSBw cm90b2NvbCBYIGJ1dCB0aGF0IGNvdWxkIGJlIG1ldCBhc3N1bWluZyBzb21lIGV2b2x1dGlvbnMu IFtOb3RlOiB0aGUgZGVmaW5pdGlvbiBvZiCTbmF0dXJhbJQgZXZvbHV0aW9uIHdpbGwgbm8gZG91 YnQgYmUgZm9yIGRpc2N1c3Npb25dLiANDTQuMS41CSBTUEVFQ0hTQyByZXF1aXJlbWVudHMgTk9U IG1ldCBieSBwcm90b2NvbCBYLiANDVRoaXMgc2VjdGlvbiBjb250YWlucyBhIGRlc2NyaXB0aW9u IG9mIHRoZSBTUEVFQ0hTQyByZXF1aXJlbWVudHMgdGhhdCBhcmUgTk9UIG1ldCBieSBwcm90b2Nv bCBYLiBbTm90ZTogYW4gaW1wb3J0YW50IGFzcGVjdCB0byBoaWdobGlnaHQgaW4gdGhlIGluZGl2 aWR1YWwgcHJvdG9jb2wgY29tcGFyaXNvbnMgd291bGQgYmUgdGhlIHdvcmsgcmVxdWlyZWQgdG8g ZXh0ZW5kIHByb3RvY29sIFggdG8gYmUgYWJsZSB0byBzdXBwb3J0IHRoaXMgcmVxdWlyZW1lbnQu XQ0NICAgIA1TZWN1cml0eSBDb25zaWRlcmF0aW9ucyANIA1TZWN1cml0eSBjb25zaWRlcmF0aW9u cyBmb3IgdGhlIFNQRUVDSFNDIHByb3RvY29sIGFyZSBjb3ZlcmVkIGJ5IHRoZSBjb21wYXJpc29u IGFnYWluc3QgdGhlIHNwZWNpZmljIFNlY3VyaXR5IHJlcXVpcmVtZW50cyBpbiB0aGUgU1BFRUNI U0MgcmVxdWlyZW1lbnRzIGRvY3VtZW50IFsxXS4gDSAgICANUmVmZXJlbmNlcyANDVsxXSBFLiBC dXJnZXIsIJNSZXF1aXJlbWVudHMgZm9yIERpc3RyaWJ1dGVkIENvbnRyb2wgb2YgQVNSLCBTUiBh bmQgVFRTIFJlc291cmNlcyIgZHJhZnQtaWV0Zi1zcGVlY2hzYy1yZXF0cy0wMC50eHQsIEp1bHkg MzEsIDIwMDIuDQ0NDUF1dGhvcpJzIEFkZHJlc3MNICAgIA1CcmlhbiBXeWxkIA1FbG9xdWFudCBT QQ1aQSBNYWx2YWlzaW4JCQkJCQkgUGhvbmU6ICArMzMgNDc2IDc3IDQ2IDkyIA1MZSBWZXJzb3Vk LCBGcmFuY2UgICAgICAgICAgICAgRW1haWw6ICBicmlhbi53eWxkQGVsb3F1YW50LmNvbSANICAg IA0gDUZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0gICANQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwMikuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0gICANVGhpcyBkb2N1bWVu dCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0bw1v dGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2Ug ZXhwbGFpbiBpdA1vciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJl ZCwgY29waWVkLCBwdWJsaXNoZWQNYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0 LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueQ1raW5kLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92 ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaA1hcmUgaW5jbHVkZWQgb24gYWxs IHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiAgSG93ZXZlciwgdGhpcw1kb2N1bWVu dCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92 aW5nDXRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNv Y2lldHkgb3Igb3RoZXINSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBm b3IgdGhlIHB1cnBvc2Ugb2YNZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2gg Y2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5l dCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlDWZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0 cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbg1FbmdsaXNoLiAgVGhlIGxpbWl0 ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZA13aWxsIG5vdCBi ZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yDWFz c2lnbnMuICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkDWhlcmVp biBpcyBwcm92aWRlZCBvbiBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVU WSBBTkQNVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBX QVJSQU5USUVTLA1FWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQg VE8gQU5ZIFdBUlJBTlRZIFRIQVQNVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJ TEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1INQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiBN RVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQQ1QQVJUSUNVTEFSIFBVUlBPU0UuIg0NDQ0N DQ0JU1BFRUNIU0MgUHJvdG9jb2wgRXZhbHVhdGlvbiBUZW1wbGF0ZSAJEyBTQVZFREFURSBcQCAi TU1NTSB5eXl5IiBcKiBNRVJHRUZPUk1BVCAUU2VwdGVtYmVyIDIwMDIVDQ0NDQ0NV3lsZAlFeHBp cmVzIC0gRGVjZW1iZXIgEyBJRiATIFNBVkVEQVRFIFxAICJNIiBcKiBNRVJHRUZPUk1BVCAUMxUg PCA3IBMgU0FWRURBVEUgXEAgIllZWVkiIFwqIE1FUkdFRk9STUFUIBQyMDAyFSATIElGIBMgU0FW RURBVEUgXEAgIk0iIFwqIE1FUkdFRk9STUFUIBQxFSA+IDYgEyA9IFNBVkVEQVRFIFxAICJZWVlZ IiBcKiBNRVJHRUZPUk1BVCAUMjAwMhUgKyAxIFwqIE1FUkdFRk9STUFUIBRFcnJvciEgTWlzc2lu ZyB0ZXN0IGNvbmRpdGlvbi4VICIiIFwqIE1FUkdFRk9STUFUIBQyMDAyFQlbUGFnZSATIFBBR0Ug FDIVXQ0NDQ1XeWxkIAlFeHBpcmVzIC0gRGVjZW1iZXIgEyBJRiATIFNBVkVEQVRFIFxAICJNIiBc KiBNRVJHRUZPUk1BVCAUMxUgPCA3IBMgU0FWRURBVEUgXEAgIllZWVkiIFwqIE1FUkdFRk9STUFU IBQyMDAyFSATIElGIBMgU0FWRURBVEUgXEAgIk0iIFwqIE1FUkdFRk9STUFUIBQxFSA+IDYgEyA9 IFNBVkVEQVRFIFxAICJZWVlZIiBcKiBNRVJHRUZPUk1BVCAUMjAwMhUgKyAxIFwqIE1FUkdFRk9S TUFUIBRFcnJvciEgTWlzc2luZyB0ZXN0IGNvbmRpdGlvbi4VICIiXCogTUVSR0VGT1JNQVQgFDIw MDIVCVtQYWdlIDFdDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAA4EAAAPBAAASwQAAEwEAABm BAAAZwQAAGsEAABsBAAAjAQAAI0EAACOBAAAjwQAAJQEAACVBAAAuAQAALkEAAC9BAAAvgQAAL8E AADABAAAxAQAAMUEAADlBAAA5gQAAOcEAADoBAAA7QQAAO4EAAATBQAAFAUAABgFAAAZBQAALQUA AC4FAABMBQAATQUAAF8FAABgBQAAZAUAAGYFAAB7BQAAfAUAAH0FAACHBQAAiAUAAIkFAACxBQAA sgUAAMAFAADBBQAAwgUAAMMFAADEBQAA6wUAAOwFAAAABgAAAgYAALYIAAC3CAAALAkAAC4JAAAk CgAAJQoAADgKAAA6CgAAOwoAAHIKAABzCgAAdQoAAHYKAAB+CgAAfwoAAIAKAACYCgAAmQoAAJoK AACbCgAAnAoAAJ0KAACfCgAAoAoAALIKAACzCgAAtAoAAMwKAADNCgAAzgoAAM8KAAAA+wD7APYA 9gD2APYA9gD2APYA9gD2APYA9gD2APYA9gD2APYA9gD2APb7APv2APYA9vsA+wD7APsA+wD7APsA +/YA9vP78wD2AOn2APb78/vzAPYA3/YAAAATAgiBA2p6AAAABggBQ0oUAFUIARMCCIEDagAAAAAG CAFDShQAVQgBBDBKHgAACQNqAAAAAFUIAQhPSgAAUUoAAFgABAAADwQAABcEAAAYBAAATAQAAFME AABUBAAAfQUAAIYFAACHBQAAiAUAAMIFAADDBQAAxAUAAOoFAADsBQAAAQYAAAIGAABvBgAA+QAA AAAAAAAAAAAAAPAAAAAAAAAAAAAAAACr8AAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPAAAAAAAAAA AAAAAACrzAQAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAACr8AAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAACrAAAAAAAAAAAAAAAApQAAAAAAAAAAAAAAAKAAAAAA AAAAAAAAAACeAAAAAAAAAAAAAAAAnAAAAAAAAAAAAAAAAJ4AAAAAAAAAAAAAAACeAAAAAAAAAAAA AAAAAAAAASAAAAERAAAEEQADJAFhJAEABREAD4QAAF6EAAAARAAAFiQBFyQBSWYBAAAAApZsAAeU EP8I1jAAApT/PB7pJwAGqB4AAAAAAAAAAAAAAAAAAAAAAAatCQAAAAAAAAAAAAAAAAAAAAAU9gEA ABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEKA2wAYfYD AAAJIAADJAIWJAFJZgEAAABhJAIGIAAWJAFJZgEAAAAAEgAEAABpIQAAIiQAAP39AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQECbwYAAHQGAAA/BwAARAcAAEkIAABOCAAA hggAALcIAAD5CAAAHgkAACMJAAAtCQAALgkAACUKAAAnCgAAOQoAADoKAACdCgAA0QoAABMLAABI CwAAfQsAAL0LAAD8CwAAKQwAAGIMAACODAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAA AADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA7QAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUVAA3GBQABkAYAAAUUAA3G BQABsAQAAAEXAAABIAAABREAEYQgAWCEIAEAAREAABrPCgAA0AoAANEKAADTCgAA1AoAAPQKAAD1 CgAA9goAAA4LAAAPCwAAEAsAABELAAASCwAAEwsAABYLAAAXCwAAKQsAACoLAAArCwAAQwsAAEQL AABFCwAARgsAAEcLAABICwAASwsAAEwLAABeCwAAXwsAAGALAAB4CwAAeQsAAHoLAAB7CwAAfAsA AH0LAACACwAAgQsAAJ4LAACfCwAAoAsAALgLAAC5CwAAugsAALsLAAC8CwAAvQsAAL8LAADACwAA 3QsAAN4LAADfCwAA9wsAAPgLAAD5CwAA+vXy9fIA+gDo+gD69eDW4NDF0LXF0MXW4Nbg0MXQpcXQ xdbg1uDQxdCVxdDF1vL18gD6AIv6AAAAABMCCIEDatwCAAAGCAFDShQAVQgBHgIIgQNqYgIAAAYI AUNKFABVCAFtSAAEbkgABHUIAQAeAgiBA2roAQAABggBQ0oUAFUIAW1IAARuSAAEdQgBAB4CCIED am4BAAAGCAFDShQAVQgBbUgABG5IAAR1CAEAFANqAAAAAFUIAW1IAARuSAAEdQgBAAttSAAEbkgA BHUIARNPSgAAUUoAAG1IAARuSAAEdQgBDzBKHgBtSAAEbkgABHUIARMCCIEDavQAAAAGCAFDShQA VQgBBDBKHgAACE9KAABRSgAAAAkDagAAAABVCAEANvkLAAD6CwAA+wsAAPwLAAD/CwAAAAwAAAoM AAALDAAADAwAACQMAAAlDAAAJgwAACcMAAAoDAAAKQwAACsMAAAsDAAAQwwAAEQMAABFDAAAXQwA AF4MAABfDAAAYAwAAGEMAABiDAAAZAwAAGUMAABvDAAAcAwAAHEMAACJDAAAigwAAIsMAACMDAAA jQwAAI4MAACPDAAAkAwAAAkNAAAKDQAAiA4AAIkOAAAEDwAABg8AACcPAAAoDwAAMBAAAEcQAACj EAAAvRAAAFARAABREQAA0xEAANQRAADnEQAA6BEAAGISAABjEgAAgRIAAIISAAD7EgAA/BIAAP4S AAD/EgAAIhMAAAD69e3j7d3S3cLS3dLjv/W/APoAtfoA+vW/9b8A+gCr+gD69fr1APUA9QD1APUA pgCmAPUA9QD1APUA9QD1APUAAAAACG1IDARzSAwEABMCCIEDakoEAAAGCAFDShQAVQgBEwIIgQNq 0AMAAAYIAUNKFABVCAEEMEoeAAAeAgiBA2pWAwAABggBQ0oUAFUIAW1IAARuSAAEdQgBABQDagAA AABVCAFtSAAEbkgABHUIAQALbUgABG5IAAR1CAETT0oAAFFKAABtSAAEbkgABHUIAQ8wSh4AbUgA BG5IAAR1CAEIT0oAAFFKAAAACQNqAAAAAFUIAQBBjgwAAJAMAACaDAAAnwwAAAUNAAAKDQAAQA0A AEENAACGDQAAhw0AAOcNAADoDQAAcA4AAHUOAACIDgAAiQ4AAAUPAAAGDwAAJw8AACgPAAAvEAAA MBAAAGQQAACjEAAAAxEAADsRAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA AADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAA AAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA0QAAomDAtGAAAPhLABEYRQ/l6EsAFghFD+BRAACiYMC0YAAAkRAAom DAtGAAAPhLABXoSwAQUQAAomAAtGAgAAARUAABk7EQAAPBEAAD0RAABQEQAAUREAALcRAADTEQAA 1BEAAOcRAADoEQAARhIAAEcSAABiEgAAYxIAAIESAACCEgAA4BIAAPsSAAD8EgAA/xIAAB4TAAAj EwAAZhQAAGcUAABzFAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPEAAAAAAAAA AAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA 3wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOQAAAAA AAAAAAAAAADaAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF EAAKJgALRgIABSYACiYMC0YAAAURAAomDAtGAAANJwAKJgwLRgAAD4TQAhGEMP1ehNACYIQw/QUm AAomAQtGAgAJEQAKJgwLRgAAD4SwAV6EsAEAGCITAAAjEwAAcxQAAHQUAADOFAAAzxQAAO8VAADw FQAAfxYAAIAWAAC1FwAAthcAAM0YAADOGAAA1xkAANgZAAD3GQAA+BkAALAaAACxGgAATRsAAE4b AABmGwAAkxsAANkbAADaGwAA8xsAAPcbAABjIQAAZCEAAGohAACRIQAAkiEAALohAAC7IQAAySEA AMohAADNIQAAziEAANAhAADoIQAA6SEAAO0hAADuIQAADiIAAA8iAAAQIgAAESIAABYiAAAXIgAA OiIAADsiAAA/IgAAQCIAAEEiAABCIgAARiIAAEciAABnIgAAaCIAAGkiAABqIgAAbyIAAHAiAACV IgAAliIAAJoiAACbIgAAryIAALAiAADOIgAAzyIAAOIiAADjIgAA5yIAAOgiAADpIgAA7yIAAPAi AAD2IgAA9yIAAPsA+wD7APsA+wD7APsA+wD7APsA+/YA9u0A6gDj+wDeAN7Y3vsA+wDeAN4A3tje AN4A3tjeAN4A3gDeAN4A3gDeAN4A3gDeAN7Y3vsA0c7RAAAAAAAAAAAEMEoPAAANA2oAAAAAMEoP AFUIAQttSAAEbkgABHUIAQkDagAAAABVCAEMQ0oYAE9KAABRSgAAAARDShgAABBPSgAAUUoAAG1I DARzSAwEAAhtSAwEc0gMBAAIT0oAAFFKAABQcxQAAHQUAADOFAAAzxQAAL4VAAC/FQAA7xUAAPAV AABEFgAARRYAAH8WAACAFgAAYxcAALUXAAC2FwAAlxgAAJgYAADNGAAAzhgAANcZAADYGQAA3RkA APYZAAD4GQAAnxoAAKQaAAD2AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPYAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AADnAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA6QAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAUQAAomAAtGAgAFEQAKJgwLRgAAAAEnAA0nAAomDAtGAAAPhNACEYQw/V6E 0AJghDD9CREACiYMC0YAAA+EsAFehLABABmkGgAAsBoAALEaAAA1GwAANhsAADcbAAA4GwAASRsA AE4bAABaGwAAZhsAAJMbAADTGwAA2BsAANobAADzGwAA9xsAADgcAAA8HAAAgBwAAMUcAAAIHQAA SR0AAIsdAADQHQAAFB4AAFgeAAD6AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA AADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAA AAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA 7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAA AAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAA AAAA7gAAAAAAAAAAAAAAAAAAAAAAARcABSUACiYAC0YAAAAFEQAPhAAAXoQAAAABEQAACRAAD4QA ABGEAABehAAAYIQAAAUQAAomAAtGAgAAGlgeAACUHgAA0x4AABAfAABTHwAAlR8AANYfAAAMIAAA UCAAAI4gAADRIAAAEyEAAE4hAABjIQAAZCEAAGUhAABmIQAAZyEAAGghAABpIQAAyyEAAMwhAADN IQAAziEAAM8hAADQIQAA+yIAAPwiAAD9IgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAARMAAAEAAAABEgAAARcAAAERAAAc9yIAAPgiAAD5IgAA/CIAAP4iAAAXIwAAGCMAABwjAAAd IwAAPSMAAD4jAAA/IwAAQCMAAEUjAABGIwAAaSMAAGojAABuIwAAbyMAAHAjAABxIwAAdSMAAHYj AACWIwAAlyMAAJgjAACZIwAAniMAAJ8jAADEIwAAxSMAAMkjAADKIwAA3iMAAN8jAAD9IwAA/iMA ABAkAAARJAAAFSQAABYkAAAXJAAAIiQAACMkAAD38ADrAOYA5gDm4OYA5gDm4OYA5gDmAOYA5gDm AOYA5gDmAOYA5uDm6wDrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAttSAAEbkgABHUIAQkDagAAAABVCAEIT0oAAFFKAAAADQNqAAAAADBK DwBVCAEPMEoPAG1IAARuSAAEdQgBACv9IgAA/iIAACAkAAAhJAAAIiQAACMkAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAREAAAEAAAABEwAABTABAtLUAAABAAAA//8AAAEAAAAAAAAAAAQAAP//AAABAAAA AAAAAQAEAAD//wAAAQAAAAAAAAEABAAA//8AAAEAAAAAAAABAAQAAP//AAABAAAAAAAAAQAEAAD/ /wAAAQAAAAAAAAEABAAA//8AAAEAAAAAAAABAAQAAP//AAABAAAAAAAAAQAMAAD//wAAAQAwBngA AAAAAC4ALgAuAC4ALgAuAC4ALgAAAAAAggAAAAAAAAAoLwQHggAAAAAAAAAAAAAAAAAAACgvBAcA AQAAAAAAACArBAcKMAEUMComUAEAHFABAB+w0C8gsOA9IbADASKwUAcjkNsBJJADASWwAAAXsAAA GLAAADjSJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAegAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAA DAAAAF8AVABvAGMANAA5ADkAMAAyADEANQAAAAB6AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kL AgAAAAgAAAAMAAAAXwBUAG8AYwA0ADkAOQAwADIAMQA2AAAAAHoAAABEAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4R jIIAqgBLqQsCAAAACAAAAAwAAABfAFQAbwBjADQAOQA5ADAAMgAxADcAAAAAegAAAEQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI 0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADAAAAF8AVABvAGMANAA5ADkAMAAyADEAOAAAAAB6AAAA RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAMAAAAXwBUAG8AYwA0ADkAOQAwADIAMQA5 AAAAAHoAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAAwAAABfAFQAbwBjADQAOQA5 ADAAMgAyADAAAAAAegAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADAAAAF8AVABv AGMANAA5ADkAMAAyADIAMQAAAAB6AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAM AAAAXwBUAG8AYwA0ADkAOQAwADIAMgAyAAAAAHoAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsC AAAACAAAAAwAAABfAFQAbwBjADQAOQA5ADAAMgAyADMAAAAAegAAAEQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGM ggCqAEupCwIAAAAIAAAADAAAAF8AVABvAGMANAA5ADkAMAAyADIANAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABQAKAAKAAEAaQAPAAMAAAAAAAAAAABEAABA8f8CAEQADAAGAE4AbwByAG0A YQBsAAAAEgAAADUkADckADgkADlEAgBIJAAUAENKGABfSAEEbUgJBHNICQR0SAkESAABQAEAAgBI AAwACQBIAGUAYQBkAGkAbgBnACAAMQAAABAAAQAGJAETpPAAFKQ8AEAmABMANQiBQ0ogAEtIIABP SgIAUUoCAABGAAJAAQACAEYADAAJAEgAZQBhAGQAaQBuAGcAIAAyAAAAEAACAAYkAROk8AAUpDwA QCYBEgA1CIE2CIFDShwAT0oCAFFKAgBUAANgAQACAFQADAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAA HwADAAYkAQomAgtGAQANxgUAAdACABOk8AAUpDwAQCYCAA8ANQiBQ0oaAE9KAgBRSgIAAEwABGAB AAIATAAMAAkASABlAGEAZABpAG4AZwAgADQAAAAfAAQABiQBCiYDC0YBAA3GBQABYAMAE6TwABSk PABAJgMABwA1CIFDShwAAEoABWABAAIASgAMAAkASABlAGEAZABpAG4AZwAgADUAAAAcAAUACiYE C0YBAA3GBQAB8AMAE6TwABSkPABAJgQKADUIgTYIgUNKGgBIAAZgAQACAEgADAAJAEgAZQBhAGQA aQBuAGcAIAA2AAAAHAAGAAomBQtGAQANxgUAAYAEABOk8AAUpDwAQCYFBwA1CIFDShYAAEAAB2AB AAIAQAAMAAkASABlAGEAZABpAG4AZwAgADcAAAAcAAcACiYGC0YBAA3GBQABEAUAE6TwABSkPABA JgYAAEQACGABAAIARAAMAAkASABlAGEAZABpAG4AZwAgADgAAAAcAAgACiYHC0YBAA3GBQABoAUA E6TwABSkPABAJgcDADYIgQBMAAlgAQACAEwADAAJAEgAZQBhAGQAaQBuAGcAIAA5AAAAHAAJAAom CAtGAQANxgUAATAGABOk8AAUpDwAQCYIDABDShYAT0oCAFFKAgA8AEFA8v+hADwADAAWAEQAZQBm AGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAJgApQKIA 8QAmAAwACwBQAGEAZwBlACAATgB1AG0AYgBlAHIAAAAAAF4A/m8RAAIBXgAMAAwAUgBGAEMAIABI AGUAYQBkAGkAbgBnADEAAAAjABAAD4SwARGEUP4SZBD/AAATpAAAFKQAAEAmCV6EsAFghFD+AA8A NQiBQ0oYAE9KAwBRSgMAAIQA/k8BABIBhAAMAAgAUgBGAEMAIABUAGUAeAB0AAAAWgARAA3GRwAX sAFgAxAFwAZwCCAK0AuADTAP4BCQEkAU8BWgF1AZABuwHGAeECDAIXAjICXQJgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAD4SwARJkEP8AAF6EsAEIAE9KAwBRSgMAOgAfQAEAIgE6AAwABgBIAGUAYQBk AGUAcgAAABMAEgANxggAArATYCcBAhJkEP8AAAAIAE9KAwBRSgMAOgAgQAEAMgE6AAwABgBGAG8A bwB0AGUAcgAAABMAEwANxggAArATYCcBAhJkEP8AAAAIAE9KAwBRSgMAYAATQBEBAgBgAAQABQBU AE8AQwAgADEAAAA4ABQADcYzF7ABYAMQBcAGcAggCtALgA0wD+AQkBJAFPAVoBdQGQAbsBxgHhAg wCFwIyAl0CYBYCcKCwBtSAAEbkgABHUIAQBcABRAEQECAFwADAAFAFQATwBDACAAMgAAAEAAFQAN xjMXsAFgAxAFwAZwCCAK0AuADTAP4BCQEkAU8BWgF1AZABuwHGAeECDAIXAjICXQJgFgJwoPhGAD XoRgAwAAJgAVQBEBAgAmAAwABQBUAE8AQwAgADMAAAAKABYAD4QAAF6EAAAAADQAWkABAHIBNAAM AAoAUABsAGEAaQBuACAAVABlAHgAdAAAAAIAFwAMAENKFABPSgMAUUoDACYAFkABAAIAJgAMAAUA VABPAEMAIAA0AAAACgAYAA+E0AJehNACAAAmABdAAQACACYADAAFAFQATwBDACAANQAAAAoAGQAP hMADXoTAAwAAJgAYQAEAAgAmAAwABQBUAE8AQwAgADYAAAAKABoAD4SwBF6EsAQAACYAGUABAAIA JgAMAAUAVABPAEMAIAA3AAAACgAbAA+EoAVehKAFAAAmABpAAQACACYADAAFAFQATwBDACAAOAAA AAoAHAAPhJAGXoSQBgAAJgAbQAEAAgAmAAwABQBUAE8AQwAgADkAAAAKAB0AD4SAB16EgAcAACgA VUCiAOEBKAAMAAkASAB5AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIqAjgAVkCiAPEBOAAMABEARgBv AGwAbABvAHcAZQBkAEgAeQBwAGUAcgBsAGkAbgBrAAAABgA+KgFCKgxwAP5vEQACAnAABAAUAFIA RgBDACAASABlAGEAZABpAG4AZwAgAC0AIABOAG8AIABUAE8AQwAAABsAIAANxgUAAXMnChJkEP8A ABOkAAAUpAAAQCYJABoANQiBQ0oYAE9KAwBRSgMAbUgABG5IAAR1CAEyAB1AAQASAjIADAANAEYA bwBvAHQAbgBvAHQAZQAgAFQAZQB4AHQAAAACACEABABDShQANgAqQKIAIQI2AAwAEQBFAG4AZABu AG8AdABlACAAUgBlAGYAZQByAGUAbgBjAGUAAAADAEgqAAA8ACtAEQEyAjwADAAMAEUAbgBkAG4A bwB0AGUAIABUAGUAeAB0AAAAEgAjAA+EYAMRhFD+XoRgA2CEUP4AADgAJkCiAEECOAAMABIARgBv AG8AdABuAG8AdABlACAAUgBlAGYAZQByAGUAbgBjAGUAAAADAEgqAQDKAP5vEQBSAsoADAALAFIA RgBDACAASABlAGEAZABpAG4AZwAAAJIAJQAKJgsLRv8HDcYIAAJoAbABAAAPhLABEYRQ/hJkEP8A ABOkAAAUpAAAPsZUAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQCYJVGYAAAD/XoSwAWCEUP4P ADUIgUNKGABPSgMAUUoDAAA8AP5PAQESATwADAAMAFIARgBDACAASABlAGEAZABpAG4AZwAyAAAA EgAmAA+EQAIRhMD9XoRAAmCEwP0AAFYA/m8xAGICVgAMAAwAUgBGAEMAIABIAGUAYQBkAGkAbgBn ADMAAAAcACcACiYAC0YAAA+E0AIRhDD9QCYJXoTQAmCEMP0PADUIgUNKGABPSgMAUUoDAAAAAAAA IyAAAAgAAEQAAAkA/////wAAAAAPAAAAFwAAABgAAABMAAAAUwAAAFQAAAB9AQAAhgEAAIcBAACI AQAAwgEAAMMBAADEAQAA6gEAAOwBAAABAgAAAgIAAG8CAAB0AgAAPwMAAEQDAABJBAAATgQAAIYE AAC3BAAA+QQAAB4FAAAjBQAALQUAAC4FAAAlBgAAJwYAADkGAAA6BgAAnQYAANEGAAATBwAASAcA AH0HAAC9BwAA/AcAACkIAABiCAAAjggAAJAIAACaCAAAnwgAAAUJAAAKCQAAQAkAAEEJAACGCQAA hwkAAOcJAADoCQAAcAoAAHUKAACICgAAiQoAAAULAAAGCwAAJwsAACgLAAAvDAAAMAwAAGQMAACj DAAAAw0AADsNAAA8DQAAPQ0AAFANAABRDQAAtw0AANMNAADUDQAA5w0AAOgNAABGDgAARw4AAGIO AABjDgAAgQ4AAIIOAADgDgAA+w4AAPwOAAD/DgAAHg8AACMPAABmEAAAZxAAAHMQAAB0EAAAzhAA AM8QAAC+EQAAvxEAAO8RAADwEQAARBIAAEUSAAB/EgAAgBIAAGMTAAC1EwAAthMAAJcUAACYFAAA zRQAAM4UAADXFQAA2BUAAN0VAAD2FQAA+BUAAJ8WAACkFgAAsBYAALEWAAA1FwAANhcAADcXAAA4 FwAASRcAAE4XAABaFwAAZhcAAJMXAADTFwAA2BcAANoXAADzFwAA9xcAADgYAAA8GAAAgBgAAMUY AAAIGQAASRkAAIsZAADQGQAAFBoAAFgaAACUGgAA0xoAABAbAABTGwAAlRsAANYbAAAMHAAAUBwA AI4cAADRHAAAEx0AAE4dAABjHQAAZB0AAGUdAABmHQAAZx0AAGgdAABpHQAAyx0AAMwdAADNHQAA zx0AANAdAAD7HgAA/B4AAP0eAAD+HgAAICAAACQgAACpAAAAIDAAAAAAAAAAgAAAAICpAAAAIDAA AAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICpAAAAIDAAAAAA AAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAA gAAAAICZAAAAADAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAA AICZAAAAADAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICY AAAAETAAAAAAAAAAgAAAAICYAAAAIDAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAA ETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAA AAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAA AAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAA gAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAIDAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAA AICYAAAAETAAAAAAAAAAgAAAAICYAAAAFzAAAAAAAAAAgAAAAICYAAAAIDAAAAAAAAAAgAAAAICY AAAAETAAAAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAA FDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA AAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFDAAAAAA AAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAIgEDAAAAAAAAAA gAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAA AICYDAAgETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICY DAAgETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAA ETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYAAIgEDABAAAAAAAAgAAAAICYDAAgEDAA AAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYAAIgEDACAAAA AAAAgAAAAICYDAAgEDAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAA gAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAA AICYDAAgETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICY AQIgJjAAAAAABgsAAAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAA JzAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYAQIgJjABAAAABgsAAAAAAICYDAAgETAA AAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAgJzAAAAAA AAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYAQIgJjACAAAABgsAAAAAAICYDAAgETAAAAAAAAAA gAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAAJzAAAAAAAAAAgAAAAICYDAAgJjAAAAAAAAAAgAAA AICYDAAgETAAAAAAAAAAgAAAAICYAAIgEDADAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICY DAAgETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYAQIgJjAAAAAA/w4AAAAAAICYDAAg ETAAAAAAAAAAgAAAAICYDAAAJzAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAAETAA AAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAAJzAAAAAAAAAAgAAAAICYDAAgETAAAAAA AAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAAJzAAAAAAAAAA gAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYAAAAJzAAAAAAAAAAgAAA AICYTAAgETAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICY DAAAJzAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAg ETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYAAIgEDAEAAAAAAAAgAAAAICYDAAgETAA AAAAAAAAgAAAAICYDAAAETAAAAAAAAAAgAAAAICYDAAgETAAAAAAAAAAgAAAAICYAAIgEDAFAAAA AAAAgAAAAICYAAAAEDAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYQAAAETAAAAAAAAAA gAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAA AICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICY AAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAA ETAAAAAAAAAAgAAAAICYAAAgJTAAAAAAAAAAgAAAAICYAAAAFzAAAAAAAAAAgAAAAICYAAAAETAA AAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAA AAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAA gAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAA AICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICY AAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAA ETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAA AAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAA AAAAgAAAAICYAAAAFzAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAA gAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAA AICaQAAAEjAAAAAAAAAAgAAAAICYQAAAEjAAAAAAAAAAgAAAAICYQAAAEjAAAAAAAAAAgAAAAICa QAAAEzAAAAAAAAAAgAAAAICYQAAAEzAAAAAAAAAAgAAAAICaQAAAEzAAAAAAAAAAgAAAAICaQAAA ADAAAAAAAAAAgAAAAICaQAAAEzAAAAAAAAAAgAAAAICYQAAAEzAAAAAAAAAAgAAAAICaQAAAEzAA AAAAAAAAgAAAAIAKAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGUAAABlAAAAkwEAAJMBAAC4AgAAuwIAAAAEAADPCgAA+QsAACITAAD3IgAAIyQAABQAAAAY AAAAGQAAABwAAAAgAAAAAAQAAG8GAACODAAAOxEAAHMUAACkGgAAWB4AAP0iAAAjJAAAFQAAABcA AAAaAAAAGwAAAB0AAAAeAAAAHwAAACEAAAAABAAAIiQAABYAAABmAAAAawAAAIwAAACOAAAAlAAA ALgAAAC9AAAAvwAAAMQAAADlAAAA5wAAAO0AAAATAQAAGAEAAC0BAABMAQAAXwEAAGQBAABlAQAA ewEAAIgBAACxAQAAwAEAADoGAAByBgAAfwYAAJkGAACbBgAAswYAAM0GAADPBgAA9QYAAA8HAAAR BwAAKgcAAEQHAABGBwAAXwcAAHkHAAB7BwAAnwcAALkHAAC7BwAA3gcAAPgHAAD6BwAACwgAACUI AAAnCAAARAgAAF4IAABgCAAAcAgAAIoIAACMCAAAjggAACMgAAATBxMWlP+VxBMWlP+VxBMHExaU /5XEEyKU/5XElP+VxJT/lYATJpUAExaU/5WAEw2U/xMllP+VwBMllP+VwBMllP+VwBMllP+VwBMl lP+VwBMllP+VwBMllP+VwBMllP+VwBMllP+VwBMllP+VwJWMKAAAAFEAAABgAAAAfwAAAIQAAACl AAAApwAAAK0AAADRAAAA1gAAANgAAADdAAAA/gAAAAABAAAGAQAALAEAADEBAABGAQAAZQEAAHkB AAB+AQAAhgEAAI0BAACPAQAArgEAALMBAADUAQAA1gEAANwBAAAAAgAABQIAAAcCAAAMAgAALQIA AC8CAAA1AgAAWwIAAGACAAB1AgAAlAIAAKcCAACsAgAAuwIAABMWlP+VgBMHExaU/5XAExaU/5XA EwcTFpT/lcQTIpT/lcSU/5XElP+VgBMhlP+VgBMHExaU/5XAExaU/5XAEwcTFpT/lcQTIpT/lcSU /5XElP+VgP//EgAAAA0AXwBUAG8AYwA1ADMANQA3ADQAMgA4ADUANAANAF8AVABvAGMANQAzADUA NwA0ADIAOAA1ADUADQBfAFQAbwBjADUAMwA1ADcANAAyADgANQA2AA0AXwBUAG8AYwA1ADMANQA3 ADQAMgA4ADUANwALAF8AVABvAGMANAA5ADkAMAAyADEANQALAF8AVABvAGMANAA5ADkAMAAyADEA NgALAF8AVABvAGMANAA5ADkAMAAyADEANwALAF8AVABvAGMANAA5ADkAMAAyADEAOAALAF8AVABv AGMANAA5ADkAMAAyADEAOQALAF8AVABvAGMANAA5ADkAMAAyADIAMAALAF8AVABvAGMANAA5ADkA MAAyADIAMQALAF8AVABvAGMANAA5ADkAMAAyADIAMgANAF8AVABvAGMANQAzADUANwA0ADIAOAA2 ADYACwBfAFQAbwBjADQAOQA5ADAAMgAyADMADQBfAFQAbwBjADUAMwA1ADcANAAyADgANgA3AAsA XwBUAG8AYwA0ADkAOQAwADIAMgA0AA0AXwBUAG8AYwA1ADMAMAAyADAANgAzADcAOQALAF8AVABv AGMAMQA5ADcANwAxADkAMgDsAQAAIwUAACcGAAA6BgAAkAgAAHUKAAAGCwAAPQ0AANQNAABjDgAA /w4AAGcQAADdFQAA3RUAAKQWAACkFgAA2hcAANoXAAAkIAAAAAAAAAEAAAACAAAAAwAAAAQAAAAF AAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA/wEAACsF AAA4BgAAmAgAAJgIAACHCgAAJgsAAE8NAADmDQAAgA4AABwPAABxEAAA9BUAAPQVAACuFgAArhYA APIXAADyFwAAJCAAAAAAAACrAwAAtAMAADoMAABEDAAAqAwAALIMAACRDQAAlA0AACAOAAAjDgAA ug4AAL0OAABOFwAAUxcAAFQXAABYFwAAaRcAAHIXAACWFwAAnRcAAGkdAADQHQAA1B0AAP4eAAAC HwAAISAAACQgAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAHABwA BwAcAAcAAgAAAAAAghQAAIQUAAD3FwAAIRgAAIAYAACGGAAAxRgAAMcYAAAIGQAACxkAAEkZAABN GQAAixkAAI4ZAADQGQAA2BkAABQaAAAXGgAAlBoAAJ4aAADTGgAA3RoAABAbAAAYGwAAlRsAAJkb AADWGwAA3RsAAAwcAAASHAAAaR0AACEgAAAkIAAABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAHAAIAAAAAAE4dAABoHQAAaR0AACEg AAAkIAAABwAFAAcABwACAP//BgAAAAoAQgByAGkAYQBuACAAVwB5AGwAZABIAEQAOgBcAHcAbwBy AGsAXABzAHAAZQBlAGMAaABzAGMAXABwAHIAbwB0AG8AYwBvAGwAXwBlAHYAYQBsAFwAcAByAG8A dABvAGMAbwBsAC0AZQB2AGEAbAB1AGEAdABpAG8AbgAtAHQAZQBtAHAAbABhAHQAZQAtAHYAMAAt ADEALQB3ADIASwAuAGQAbwBjAAoAQgByAGkAYQBuACAAVwB5AGwAZAB+AEMAOgBcAEQAbwBjAHUA bQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABiAHIAaQBhAG4AXABBAHAAcABs AGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwA QQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAcAByAG8AdABvAGMAbwBs AC0AZQB2AGEAbAB1AGEAdABpAG8AbgAtAHQAZQBtAHAAbABhAHQAZQAtAHYAMAAtADEALQB3ADIA SwAuAGEAcwBkAAoAQgByAGkAYQBuACAAVwB5AGwAZAB+AEMAOgBcAEQAbwBjAHUAbQBlAG4AdABz ACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABiAHIAaQBhAG4AXABBAHAAcABsAGkAYwBhAHQA aQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBS AGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAcAByAG8AdABvAGMAbwBsAC0AZQB2AGEA bAB1AGEAdABpAG8AbgAtAHQAZQBtAHAAbABhAHQAZQAtAHYAMAAtADEALQB3ADIASwAuAGEAcwBk AAIA+/////hjXAH/D/8PAwAEAAUABgAHAAgACQAAAC493k82LUR4/w//D/8P/w//D/8P/w//D/8P AAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAAAEACAAAAAAAAAAAAeAAAANACAAAAEAAAD4TQAhGEMP1ehNACYIQw/QIALgACAAEA AAAAQAIEAAAAAAAAAAB4AAAAYAMAAAAQAAAPhGADEYSg/F6EYANghKD8BAAuAAIALgADAAEAAAAA QAIEBgAAAAAAAAB4AAAA8AMAAAAQAAAPhPADEYQQ/F6E8ANghBD8BgAuAAIALgADAC4ABAABAAAA AEACBAYIAAAAAAAAeAAAAIAEAAAAEAAAD4SABBGEgPtehIAEYISA+wgALgACAC4AAwAuAAQALgAF AAEAAAAAQAIEBggKAAAAAAB4AAAAEAUAAAAQAAAPhBAFEYTw+l6EEAVghPD6CgAuAAIALgADAC4A BAAuAAUALgAGAAEAAAAAQAIEBggKDAAAAAB4AAAAoAUAAAAQAAAPhKAFEYRg+l6EoAVghGD6DAAu AAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAEACBAYICgwOAAAAeAAAADAGAAAAEAAAD4QwBhGE 0PlehDAGYITQ+Q4ALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAAQAEAAAAAAAAAAAAA AAAAAAAAAAAAAAACAAAALgABAAAAAEABAwAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAC4AAQABAAAA AEABAwUAAAAAAAAAAAAAAAAAAAAAAAAABQAAAC4AAQAuAAIAAQAAAABAAQMFBwAAAAAAAAAAAAAA AAAAAAAAAAcAAAAuAAEALgACAC4AAwABAAAAAEABAwUHCQAAAAAAAAAAAAAAAAAAAAAACQAAAC4A AQAuAAIALgADAC4ABAABAAAAAEABAwUHCQsAAAAAAAAAAAAAAAAAAAAACwAAAC4AAQAuAAIALgAD AC4ABAAuAAUAAQAAAABAAQMFBwkLDQAAAAAAAAAAAAAAAAAAAA0AAAAuAAEALgACAC4AAwAuAAQA LgAFAC4ABgABAAAAAEABAwUHCQsNDwAAAAAAAAAAAAAAAAAADwAAAC4AAQAuAAIALgADAC4ABAAu AAUALgAGAC4ABwABAAAAAEABAwUHCQsNDxEAeAAAADAGAAAAEAAAD4QwBhGE0PlehDAGYITQ+REA AAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAIAAAD7////AAAAAAAAAAAAAAAALj3e TwAAAAAAAAAAAAAAAP////////////8CAAAAAAAAAP//AgAAAAAAAAAAAAAADwAAABcAAAAYAAAA TAAAAFMAAABUAAAAfQEAAIYBAACHAQAAiAEAAMIBAADDAQAAaR0AACEgAAAkIAAAAAAAAAIBAAAC AQAAngEAAAIBAAACAQAAngEAAAIBAAACAQAAngEAAAIBAAACAQAAlgEAAAAAAAABAAAA/0BsajQA TmUwMToAd2luc3Bvb2wASFAgTGFzZXJKZXQgNFNpLzRTaSBNWCBQUwBsajQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEEAQWcAMQCU/8AAAEACQCaCzQIZAABAA8AWAIBAAEAWAIDAAEAQTQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAIA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW4jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAAADEAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAA AAAAAAAQAFA0AwAoiAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFnos04IAAAAAQAAAAAA /wABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsajQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAQWcAMQCU/8AAAEACQCaCzQIZAABAA8AWAIBAAEA WAIDAAEAQTQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAQAAAAIAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW4jAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAAADEAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAIAAAAAAAAAAAAQAFA0AwAoiAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFnos04I AAAAAQAAAAAA/wABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABgAEAAhcAAAIXAAAMKdIGAQABAAIXAAAAAAAAAhcAAJT/PB4CEAAAAAAAAAAjIAAAgAAACABA AAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA//8A AAAA//8AAAIA//8AAAAABQAAAEcWkAEAAAICBgMFBAUCAwSHegAgAAAAgAgAAAAAAAAA/wEAAAAA AABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAA EAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHegAgAAAAgAgA AAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA/NZABAAACBwMJAgIFAgQEh3oAIAAAAIAIAAAAAAAA AP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAMxKQAQAAAgIGAwUEBQIDBAMAAAAAAAAA AAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAAACIABABBAIgYAPDQAgAAaAEAAAAAsI1pRsmNaUbD 2mNmBQAeAAAAUAQAACgYAAABAGgAAAAEAAAQ3AAAADUEAACQFwAAAQBmAAAA1wAAAAAAAAAhAwDw EIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHeAB4AIABMjAAAAAAAAAAAAAAAAAAADIe AADFGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwFgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEyg1EA8BCE/wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD//xIAAAAAAAAAFgBTAHAAZQBlAGMAaABTAEMAIABXAG8AcgBrAGkAbgBnACAARwByAG8AdQBw AAAAAAAAAAQAVwB5AGwAZAAKAEIAcgBpAGEAbgAgAFcAeQBsAGQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAA AAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACUAQAAEgAAAAEAAACYAAAAAgAAAKAA AAADAAAAwAAAAAQAAADMAAAABQAAANwAAAAGAAAA6AAAAAcAAAD0AAAACAAAAAgBAAAJAAAAHAEA ABIAAAAoAQAACgAAAEQBAAALAAAAUAEAAAwAAABcAQAADQAAAGgBAAAOAAAAdAEAAA8AAAB8AQAA EAAAAIQBAAATAAAAjAEAAAIAAADkBAAAHgAAABcAAABTcGVlY2hTQyBXb3JraW5nIEdyb3VwAAAe AAAAAQAAAABwZWUeAAAABQAAAFd5bGQAaFNDHgAAAAEAAAAAeWxkHgAAAAEAAAAAeWxkHgAAAAsA AABOb3JtYWwuZG90AHIeAAAACwAAAEJyaWFuIFd5bGQAch4AAAACAAAANQBpYR4AAAATAAAATWlj cm9zb2Z0IFdvcmQgOS4wAG9AAAAAADTiMAQAAABAAAAAALqyMW7VwQFAAAAAAABXgotewgFAAAAA AL5bcY5ewgEDAAAAAQAAAAMAAABQBAAAAwAAACgYAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAA AAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAACAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIQA AAAGAAAAjAAAABEAAACUAAAAFwAAAJwAAAALAAAApAAAABAAAACsAAAAEwAAALQAAAAWAAAAvAAA AA0AAADEAAAADAAAAOcAAAACAAAA5AQAAB4AAAAJAAAARWxvcXVhbnQAAFcAAwAAANwAAAADAAAA aAAAAAMAAAAyHgAAAwAAAO0OCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAB AAAAFwAAAFNwZWVjaFNDIFdvcmtpbmcgR3JvdXAADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAI AAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYA AAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAD+////JAAA ACUAAAAmAAAAJwAAACgAAAApAAAAKgAAAP7///8sAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAA MwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABB AAAAQgAAAEMAAABEAAAA/v///0YAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAAD+////TgAAAE8A AABQAAAAUQAAAFIAAABTAAAAVAAAAP7////9////VwAAAP7////+/////v////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAA AMAAAAAAAABGAAAAAAAAAAAAAAAA8KIveI5ewgFZAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMAAAAAEAAAAAAAADEA VABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAOAAIAAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KwAAAPIyAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABoAAgEGAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMkUAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEUAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATQAAAAAQAAAAAAAAAQBD AG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABIAAgECAAAABwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA8KIv eI5ewgHwoi94jl7CAQAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABN aWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA 9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_00E9_01C25EA4.9B8FDF60-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 17 18:44:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02963 for ; Tue, 17 Sep 2002 18:44:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HMjeJ14743 for speechsc-archive@odin.ietf.org; Tue, 17 Sep 2002 18:45:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HMjdv14740 for ; Tue, 17 Sep 2002 18:45:39 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02944 for ; Tue, 17 Sep 2002 18:43:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HMj5v14703; Tue, 17 Sep 2002 18:45:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HMiZv14680 for ; Tue, 17 Sep 2002 18:44:35 -0400 Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02933 for ; Tue, 17 Sep 2002 18:42:41 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g8HMiMS22113; Tue, 17 Sep 2002 18:44:22 -0400 (EDT) Reply-To: From: "Eric Burger" To: , "Speechsc \(E-mail\)" Subject: RE: [Speechsc] Updated list of contributors Date: Tue, 17 Sep 2002 18:44:21 -0400 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00d301c25e85$af1bef20$8300a8c0@hq.eloquant.com> Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The timing is exactly correct. Having a draft out by the end of September gives us 3 weeks of list discussion and 1 week for revision. The key point is to have the document available for discussion in Atlanta. Also note that we cannot update a new -00 document to -01 after 10/27. -- Signed, "Brian" Burger :-) > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf > Of Brian Wyld > Sent: Tuesday, September 17, 2002 4:06 PM > To: Speechsc (E-mail) > Subject: [Speechsc] Updated list of contributors > > > Hi, > > Updated list: > > RTSP : Jiten Goel, Rajiv Dharmadhikari > SIP : Brian Marquette, Jiten Goel > Web Services : Stephane Maes > MRCP draft : Sarvi Shanmugham > BEEP : Brian Eberman > > Cutoff date for the draft is apparently 10/27. I suggest we try to have > first draft sections for review sent to the list by end Sept, to allow for > comments/re-work and then integration into a whole. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 17 18:44:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02975 for ; Tue, 17 Sep 2002 18:44:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HMjeJ14758 for speechsc-archive@odin.ietf.org; Tue, 17 Sep 2002 18:45:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HMjev14755 for ; Tue, 17 Sep 2002 18:45:40 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02947 for ; Tue, 17 Sep 2002 18:43:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HMj5v14719; Tue, 17 Sep 2002 18:45:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HMiZv14681 for ; Tue, 17 Sep 2002 18:44:35 -0400 Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02932 for ; Tue, 17 Sep 2002 18:42:41 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g8HMiLS22110; Tue, 17 Sep 2002 18:44:21 -0400 (EDT) Reply-To: From: "Eric Burger" To: Cc: Subject: RE: [Speechsc] WGLC for Requirements draft Date: Tue, 17 Sep 2002 18:44:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <001f01c25a2f$5e48d770$8300a8c0@hq.eloquant.com> Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Now I get it: said colloquially, "Don't make the mistakes of HTTP 1.0". Do we need to explicitly state the protocol MUST/SHOULD allow for multiplexing sessions on a persistent, reliable connection, or is it covered by the "protocol should be efficient" requirement? > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf > Of Brian Wyld > Sent: Thursday, September 12, 2002 3:38 AM > To: 'Sarvi Shanmugham' > Cc: 'David R. Oran'; speechsc@ietf.org > Subject: RE: [Speechsc] WGLC for Requirements draft > > > Hi Sarvi, > > By Control channel, if you are refering to a TCP connection, > > where by multiple > > Speechsc sessions are setup and executed over single TCP > > session between the > > client and the server. > > I would agree. > > I didn't want to prejudge the use of TCP :-), but yes. > > > > Caching achieves the same goal but the first user of the > > grammar pays the > > > compilation latency. Otherwise yes, I'm just requesting a > > means of providing > > > caching hints to the server. > > > > I agree. > > Please refer to draft-shanmugham-mrcp-02.txt for how MRCP > > provides caching hints > > to the server. > > Indeed, MRCP covers this point, I just wanted to ensure the > requirements doc > captured the need. (in fact I was thinking about the requirement being to > have perhaps an explicit "pre-define this grammar" method as MRCP > proposed) > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > > -----Message d'origine----- > > De : Sarvi Shanmugham [mailto:sarvi@cisco.com] > > Envoye : Thursday, September 12, 2002 02:50 > > A : brian.wyld@eloquant.com > > Cc : 'David R. Oran'; speechsc@ietf.org > > Objet : Re: [Speechsc] WGLC for Requirements draft > > > > > > > > > > Brian Wyld wrote: > > > > > > > > > > > > MUST define how RTP sessions included in a speechsc > > > > session are identified > > > > > MUST be capable of using a single control channel during : > > > > > - a single session > > > > > - multiple sessions serially > > > > > - multiple sessions in parallel > > > > > > > > Not sure what you mean by single control channel during > > > > multiple sessions > > > > serially or parallely. Could you please elaborate. > > > > > > Multiple serial use > > > - Open a control channel client->server > > > - setup session A > > > - execute 1-N operations (eg TTS generation) > > > - close session A > > > - setup session B > > > - execute 1-N operations (eg TTS generation) > > > - close session B > > > - etc > > > - close control channel > > > > > > Multiple parallel use > > > - Open a control channel client->server > > > - setup session A > > > - setup session B (C, D etc) > > > - execute operation on A (eg TTS generation) > > > - execute operation on B(eg TTS generation) > > > - repeat until done > > > - close session A > > > - close session B > > > - close control channel > > > > By Control channel, if you are refering to a TCP connection, > > where by multiple > > Speechsc sessions are setup and executed over single TCP > > session between the > > client and the server. > > I would agree. > > > > > > > > > > > > > > > > > > MUST be capable of using a single session for > > > > > - a single operation of a single type (single utterance > > > > recognition) > > > > > - multiple operations of the same type (use of TTS > > > > channel during a > > > > > call) > > > > > - multiple operations of different types (TTS/ASR > > > > server, ASR/SR server) > > > > > > > > > > > > > Within a single session established to a SpeechSC > > > > server(meaning a single > > > > control session with an established RTP pipe), I agree we > > > > should be able to > > > > allocate a recognition resource and do multiple ASR > > > > operations one after the > > > > other. Within the the same session, we should also be able > > > > allocate a SV and do > > > > one or more SV operations in sequence. When you are talk > > > > about parallely, if you > > > > are refering to the case of having a SV and an ASR operation > > > > active parallely in > > > > the same session. I agree. > > > > With TTS I would agree, parallel operation should be > > > > possible, IF we do end up > > > > with a single protocol for ASR, TTS and SV. > > > > > > Yup, thats what I meant. > > > > > > [snip] > > > > > - (last para in seciotn 7) change "The ASR Server SHOULD > > > > support sharing > > > > > grammars across sessions...." to "The SPEECHSC framework > > > > MUST support a > > > > > means of requesting the sharing of grammars across > > > > sessions....", and add > > > > > that "ASR server SHOULD support this functionality". [ie > > > > the protocol must > > > > > define the mechanism, but the server may not implement it] > > > > > > > > > > > > > Is this for efficiency in a downloading and compiling > > large grammars? > > > > Wouldn't caching fetched/compiledd grammars addrerss the > > > > problem. Would we still > > > > need global or shared grammars, if we had caching and ways of > > > > controlling > > > > caching of grammars on the speechsc server??? > > > > > > Caching achieves the same goal but the first user of the > > grammar pays the > > > compilation latency. Otherwise yes, I'm just requesting a > > means of providing > > > caching hints to the server. > > > > I agree. > > Please refer to draft-shanmugham-mrcp-02.txt for how MRCP > > provides caching hints > > to the server. > > > > Thx, > > Sarvi > > > > > > > > > > > > > > > > > > Anyway, thats enough for now..... > > > > > > And again, bedtime... > > > > > > Brian > > > > > > > _______________________________________________ > > > > Speechsc mailing list > > > > Speechsc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Sep 18 06:57:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08076 for ; Wed, 18 Sep 2002 06:57:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8IAwfM26284 for speechsc-archive@odin.ietf.org; Wed, 18 Sep 2002 06:58:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IAwfv26281 for ; Wed, 18 Sep 2002 06:58:41 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08073 for ; Wed, 18 Sep 2002 06:56:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IAw8v26265; Wed, 18 Sep 2002 06:58:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IAvov26251 for ; Wed, 18 Sep 2002 06:57:50 -0400 Received: from ahuumrelay2.ams.ops.eu.uu.net (ahuumrelay2.ams.ops.eu.uu.net [195.129.70.155]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08034 for ; Wed, 18 Sep 2002 06:56:02 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay2.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8IAvIf26314; Wed, 18 Sep 2002 10:57:18 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id DD12F3B6BC; Wed, 18 Sep 2002 06:56:35 -0400 (EDT) Reply-To: From: "Brian Wyld" To: Cc: Subject: RE: [Speechsc] WGLC for Requirements draft Date: Wed, 18 Sep 2002 12:56:28 +0200 Message-ID: <00fa01c25f02$0ab2ab90$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Indeed, I should have used the HTTP1.0 example. I think its good to make it explicit (one can never be TOO clear...) When do you anticipate a revised requirements doc? Particularly for the protocol comparisons, its good to have each req with a specific label.... A+ Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Eric Burger > Envoye : Wednesday, September 18, 2002 00:44 > A : brian.wyld@eloquant.com > Cc : speechsc@ietf.org > Objet : RE: [Speechsc] WGLC for Requirements draft > > > Now I get it: said colloquially, "Don't make the mistakes of > HTTP 1.0". Do > we need to explicitly state the protocol MUST/SHOULD allow > for multiplexing > sessions on a persistent, reliable connection, or is it covered by the > "protocol should be efficient" requirement? > > > -----Original Message----- > > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]On Behalf > > Of Brian Wyld > > Sent: Thursday, September 12, 2002 3:38 AM > > To: 'Sarvi Shanmugham' > > Cc: 'David R. Oran'; speechsc@ietf.org > > Subject: RE: [Speechsc] WGLC for Requirements draft > > > > > > Hi Sarvi, > > > By Control channel, if you are refering to a TCP connection, > > > where by multiple > > > Speechsc sessions are setup and executed over single TCP > > > session between the > > > client and the server. > > > I would agree. > > > > I didn't want to prejudge the use of TCP :-), but yes. > > > > > > Caching achieves the same goal but the first user of the > > > grammar pays the > > > > compilation latency. Otherwise yes, I'm just requesting a > > > means of providing > > > > caching hints to the server. > > > > > > I agree. > > > Please refer to draft-shanmugham-mrcp-02.txt for how MRCP > > > provides caching hints > > > to the server. > > > > Indeed, MRCP covers this point, I just wanted to ensure the > > requirements doc > > captured the need. (in fact I was thinking about the > requirement being to > > have perhaps an explicit "pre-define this grammar" method as MRCP > > proposed) > > > > Brian > > > > [Brian Wyld] [brian.wyld@eloquant.com] > > [Directeur General R&D] > > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > > [advanced solutions for telecoms and IT services] > > > > > -----Message d'origine----- > > > De : Sarvi Shanmugham [mailto:sarvi@cisco.com] > > > Envoye : Thursday, September 12, 2002 02:50 > > > A : brian.wyld@eloquant.com > > > Cc : 'David R. Oran'; speechsc@ietf.org > > > Objet : Re: [Speechsc] WGLC for Requirements draft > > > > > > > > > > > > > > > Brian Wyld wrote: > > > > > > > > > > > > > > > MUST define how RTP sessions included in a speechsc > > > > > session are identified > > > > > > MUST be capable of using a single control channel during : > > > > > > - a single session > > > > > > - multiple sessions serially > > > > > > - multiple sessions in parallel > > > > > > > > > > Not sure what you mean by single control channel during > > > > > multiple sessions > > > > > serially or parallely. Could you please elaborate. > > > > > > > > Multiple serial use > > > > - Open a control channel client->server > > > > - setup session A > > > > - execute 1-N operations (eg TTS generation) > > > > - close session A > > > > - setup session B > > > > - execute 1-N operations (eg TTS generation) > > > > - close session B > > > > - etc > > > > - close control channel > > > > > > > > Multiple parallel use > > > > - Open a control channel client->server > > > > - setup session A > > > > - setup session B (C, D etc) > > > > - execute operation on A (eg TTS generation) > > > > - execute operation on B(eg TTS generation) > > > > - repeat until done > > > > - close session A > > > > - close session B > > > > - close control channel > > > > > > By Control channel, if you are refering to a TCP connection, > > > where by multiple > > > Speechsc sessions are setup and executed over single TCP > > > session between the > > > client and the server. > > > I would agree. > > > > > > > > > > > > > > > > > > > > > > > MUST be capable of using a single session for > > > > > > - a single operation of a single type (single utterance > > > > > recognition) > > > > > > - multiple operations of the same type (use of TTS > > > > > channel during a > > > > > > call) > > > > > > - multiple operations of different types (TTS/ASR > > > > > server, ASR/SR server) > > > > > > > > > > > > > > > > Within a single session established to a SpeechSC > > > > > server(meaning a single > > > > > control session with an established RTP pipe), I agree we > > > > > should be able to > > > > > allocate a recognition resource and do multiple ASR > > > > > operations one after the > > > > > other. Within the the same session, we should also be able > > > > > allocate a SV and do > > > > > one or more SV operations in sequence. When you are talk > > > > > about parallely, if you > > > > > are refering to the case of having a SV and an ASR operation > > > > > active parallely in > > > > > the same session. I agree. > > > > > With TTS I would agree, parallel operation should be > > > > > possible, IF we do end up > > > > > with a single protocol for ASR, TTS and SV. > > > > > > > > Yup, thats what I meant. > > > > > > > > [snip] > > > > > > - (last para in seciotn 7) change "The ASR Server SHOULD > > > > > support sharing > > > > > > grammars across sessions...." to "The SPEECHSC framework > > > > > MUST support a > > > > > > means of requesting the sharing of grammars across > > > > > sessions....", and add > > > > > > that "ASR server SHOULD support this functionality". [ie > > > > > the protocol must > > > > > > define the mechanism, but the server may not implement it] > > > > > > > > > > > > > > > > Is this for efficiency in a downloading and compiling > > > large grammars? > > > > > Wouldn't caching fetched/compiledd grammars addrerss the > > > > > problem. Would we still > > > > > need global or shared grammars, if we had caching and ways of > > > > > controlling > > > > > caching of grammars on the speechsc server??? > > > > > > > > Caching achieves the same goal but the first user of the > > > grammar pays the > > > > compilation latency. Otherwise yes, I'm just requesting a > > > means of providing > > > > caching hints to the server. > > > > > > I agree. > > > Please refer to draft-shanmugham-mrcp-02.txt for how MRCP > > > provides caching hints > > > to the server. > > > > > > Thx, > > > Sarvi > > > > > > > > > > > > > > > > > > > > > > > Anyway, thats enough for now..... > > > > > > > > And again, bedtime... > > > > > > > > Brian > > > > > > > > > _______________________________________________ > > > > > Speechsc mailing list > > > > > Speechsc@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Sep 18 10:46:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16010 for ; Wed, 18 Sep 2002 10:46:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8IEldi22230 for speechsc-archive@odin.ietf.org; Wed, 18 Sep 2002 10:47:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IEldv22227 for ; Wed, 18 Sep 2002 10:47:39 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15980 for ; Wed, 18 Sep 2002 10:45:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IEl6v22203; Wed, 18 Sep 2002 10:47:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IEj4v22098 for ; Wed, 18 Sep 2002 10:45:04 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15867 for ; Wed, 18 Sep 2002 10:43:15 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8IEiTKB026944; Wed, 18 Sep 2002 07:44:29 -0700 (PDT) Received: from ORANLT.cisco.com ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id AEA99734; Wed, 18 Sep 2002 07:44:33 -0700 (PDT) Date: Wed, 18 Sep 2002 10:45:49 -0400 From: "David R. Oran" To: brian.wyld@eloquant.com, eburger@snowshore.com cc: speechsc@ietf.org Subject: RE: [Speechsc] WGLC for Requirements draft Message-ID: <180920299.1032345949@ORANLT.cisco.com> In-Reply-To: <00fa01c25f02$0ab2ab90$8300a8c0@hq.eloquant.com> References: <00fa01c25f02$0ab2ab90$8300a8c0@hq.eloquant.com> X-Mailer: Mulberry/3.0.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Wednesday, September 18, 2002 12:56 PM +0200 Brian Wyld wrote: > Hi, > > Indeed, I should have used the HTTP1.0 example. I think its good to make > it explicit (one can never be TOO clear...) > Good. > When do you anticipate a revised requirements doc? Particularly for the > protocol comparisons, its good to have each req with a specific label.... > I plan to wait for last call to close on the 20th, go through the comments, address each, and have a revised draft within 2-3 days. Depending on whether any of the comments are deemed controversial enough to require further discussion (so far none are in that category IMO), I will either just restart last call, or send the revised draft to the IESG for approval and publication. That plan sound good? > A+ > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > >> -----Message d'origine----- >> De : speechsc-admin@ietf.org >> [mailto:speechsc-admin@ietf.org]De la part >> de Eric Burger >> Envoye : Wednesday, September 18, 2002 00:44 >> A : brian.wyld@eloquant.com >> Cc : speechsc@ietf.org >> Objet : RE: [Speechsc] WGLC for Requirements draft >> >> >> Now I get it: said colloquially, "Don't make the mistakes of >> HTTP 1.0". Do >> we need to explicitly state the protocol MUST/SHOULD allow >> for multiplexing >> sessions on a persistent, reliable connection, or is it covered by the >> "protocol should be efficient" requirement? >> >> > -----Original Message----- >> > From: speechsc-admin@ietf.org >> [mailto:speechsc-admin@ietf.org]On Behalf >> > Of Brian Wyld >> > Sent: Thursday, September 12, 2002 3:38 AM >> > To: 'Sarvi Shanmugham' >> > Cc: 'David R. Oran'; speechsc@ietf.org >> > Subject: RE: [Speechsc] WGLC for Requirements draft >> > >> > >> > Hi Sarvi, >> > > By Control channel, if you are refering to a TCP connection, >> > > where by multiple >> > > Speechsc sessions are setup and executed over single TCP >> > > session between the >> > > client and the server. >> > > I would agree. >> > >> > I didn't want to prejudge the use of TCP :-), but yes. >> > >> > > > Caching achieves the same goal but the first user of the >> > > grammar pays the >> > > > compilation latency. Otherwise yes, I'm just requesting a >> > > means of providing >> > > > caching hints to the server. >> > > >> > > I agree. >> > > Please refer to draft-shanmugham-mrcp-02.txt for how MRCP >> > > provides caching hints >> > > to the server. >> > >> > Indeed, MRCP covers this point, I just wanted to ensure the >> > requirements doc >> > captured the need. (in fact I was thinking about the >> requirement being to >> > have perhaps an explicit "pre-define this grammar" method as MRCP >> > proposed) >> > >> > Brian >> > >> > [Brian Wyld] [brian.wyld@eloquant.com] >> > [Directeur General R&D] >> > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] >> > [advanced solutions for telecoms and IT services] >> > >> > > -----Message d'origine----- >> > > De : Sarvi Shanmugham [mailto:sarvi@cisco.com] >> > > Envoye : Thursday, September 12, 2002 02:50 >> > > A : brian.wyld@eloquant.com >> > > Cc : 'David R. Oran'; speechsc@ietf.org >> > > Objet : Re: [Speechsc] WGLC for Requirements draft >> > > >> > > >> > > >> > > >> > > Brian Wyld wrote: >> > > >> > > > > > >> > > > > > MUST define how RTP sessions included in a speechsc >> > > > > session are identified >> > > > > > MUST be capable of using a single control channel during : >> > > > > > - a single session >> > > > > > - multiple sessions serially >> > > > > > - multiple sessions in parallel >> > > > > >> > > > > Not sure what you mean by single control channel during >> > > > > multiple sessions >> > > > > serially or parallely. Could you please elaborate. >> > > > >> > > > Multiple serial use >> > > > - Open a control channel client->server >> > > > - setup session A >> > > > - execute 1-N operations (eg TTS generation) >> > > > - close session A >> > > > - setup session B >> > > > - execute 1-N operations (eg TTS generation) >> > > > - close session B >> > > > - etc >> > > > - close control channel >> > > > >> > > > Multiple parallel use >> > > > - Open a control channel client->server >> > > > - setup session A >> > > > - setup session B (C, D etc) >> > > > - execute operation on A (eg TTS generation) >> > > > - execute operation on B(eg TTS generation) >> > > > - repeat until done >> > > > - close session A >> > > > - close session B >> > > > - close control channel >> > > >> > > By Control channel, if you are refering to a TCP connection, >> > > where by multiple >> > > Speechsc sessions are setup and executed over single TCP >> > > session between the >> > > client and the server. >> > > I would agree. >> > > >> > > > >> > > > >> > > > > > >> > > > > > MUST be capable of using a single session for >> > > > > > - a single operation of a single type (single utterance >> > > > > recognition) >> > > > > > - multiple operations of the same type (use of TTS >> > > > > channel during a >> > > > > > call) >> > > > > > - multiple operations of different types (TTS/ASR >> > > > > server, ASR/SR server) >> > > > > > >> > > > > >> > > > > Within a single session established to a SpeechSC >> > > > > server(meaning a single >> > > > > control session with an established RTP pipe), I agree we >> > > > > should be able to >> > > > > allocate a recognition resource and do multiple ASR >> > > > > operations one after the >> > > > > other. Within the the same session, we should also be able >> > > > > allocate a SV and do >> > > > > one or more SV operations in sequence. When you are talk >> > > > > about parallely, if you >> > > > > are refering to the case of having a SV and an ASR operation >> > > > > active parallely in >> > > > > the same session. I agree. >> > > > > With TTS I would agree, parallel operation should be >> > > > > possible, IF we do end up >> > > > > with a single protocol for ASR, TTS and SV. >> > > > >> > > > Yup, thats what I meant. >> > > > >> > > > [snip] >> > > > > > - (last para in seciotn 7) change "The ASR Server SHOULD >> > > > > support sharing >> > > > > > grammars across sessions...." to "The SPEECHSC framework >> > > > > MUST support a >> > > > > > means of requesting the sharing of grammars across >> > > > > sessions....", and add >> > > > > > that "ASR server SHOULD support this functionality". [ie >> > > > > the protocol must >> > > > > > define the mechanism, but the server may not implement it] >> > > > > > >> > > > > >> > > > > Is this for efficiency in a downloading and compiling >> > > large grammars? >> > > > > Wouldn't caching fetched/compiledd grammars addrerss the >> > > > > problem. Would we still >> > > > > need global or shared grammars, if we had caching and ways of >> > > > > controlling >> > > > > caching of grammars on the speechsc server??? >> > > > >> > > > Caching achieves the same goal but the first user of the >> > > grammar pays the >> > > > compilation latency. Otherwise yes, I'm just requesting a >> > > means of providing >> > > > caching hints to the server. >> > > >> > > I agree. >> > > Please refer to draft-shanmugham-mrcp-02.txt for how MRCP >> > > provides caching hints >> > > to the server. >> > > >> > > Thx, >> > > Sarvi >> > > >> > > > >> > > > >> > > > > > >> > > > > > Anyway, thats enough for now..... >> > > > >> > > > And again, bedtime... >> > > > >> > > > Brian >> > > > >> > > > > _______________________________________________ >> > > > > Speechsc mailing list >> > > > > Speechsc@ietf.org >> > > > > https://www1.ietf.org/mailman/listinfo/speechsc >> > > >> > >> > _______________________________________________ >> > Speechsc mailing list >> > Speechsc@ietf.org >> > https://www1.ietf.org/mailman/listinfo/speechsc >> > >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Sep 19 20:26:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27280 for ; Thu, 19 Sep 2002 20:26:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8K0Rk316020 for speechsc-archive@odin.ietf.org; Thu, 19 Sep 2002 20:27:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8K0Rkv16017 for ; Thu, 19 Sep 2002 20:27:46 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27272 for ; Thu, 19 Sep 2002 20:25:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8K0RDv16002; Thu, 19 Sep 2002 20:27:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8K0Quv15983 for ; Thu, 19 Sep 2002 20:26:56 -0400 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27249 for ; Thu, 19 Sep 2002 20:25:00 -0400 (EDT) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.5255); Thu, 19 Sep 2002 17:26:51 -0700 Received: from 10.197.0.60 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Sep 2002 17:26:13 -0700 Received: from DF-MAX.platinum.corp.microsoft.com ([10.197.1.8]) by DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Thu, 19 Sep 2002 17:26:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Sep 2002 17:26:10 -0700 Message-ID: <2A499EF0C1943544B1350C6D2593897E01196CB0@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: Comments on draft-ietf-speechsc-reqts-00.txt thread-index: AcJgPE+TOeKfD9ltRnyzb0AV6fFA6g== From: "Salvador Neto" To: "David R. Oran" , "Eric Burger" , Cc: "Hsiao-Wuen Hon" , "Stephen Potter" X-OriginalArrivalTime: 20 Sep 2002 00:26:12.0714 (UTC) FILETIME=[53081CA0:01C2603C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8K0Quv15984 Subject: [Speechsc] Comments on draft-ietf-speechsc-reqts-00.txt Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit A number of people in Microsoft's speech group have reviewed the SpeechSC requirements draft in detail, and would like to raise the following comments and questions. Please forgive us if these have been discussed in the group already, as we approach this document as relative newcomers to the group. And also, please make sure you include Hsiao-Wuen-Hon (hon@microsoft.com) and Stephen Potter (spotter@microsoft.com) in your replies, as they are still in the process of adding themselves to the list. Thanks, Salvador Assumpcao Neto Program Manager - .Net Speech group Microsoft Corporation Comments follow... Section 3 (and throughout) 1. The requirements document is clearly focused on telephony gateway scenarios. We suggest that an equally compelling scenario is mobile multimodal scenarios where wireless mobile devices can attain ASR/SR/TTS services via network. If the group agrees that this is an important scenario to address, we would suggest modification or addition of the requirements to reflect this. Specifically, we are concerned that saying SpeechSC depends on RTP may mean that it depends on UDP. If so, we believe that for ASR and SR services guarantee of delivery, such as provided by TCP, may be better suited (rather than real-time requirement), especially in the case of mobile multimodal scenarios. So we hope SpeechSC will be open to contemplate such alternatives. 2. The term 'speaker recognition' and its acronym SR are rather confusing, given the widespread use of SR to mean 'speech recognition' (i.e. ASR), and the use of the word 'recognition' in both concepts. We understand the meaning of the term to embrace both 'speaker verification' and 'speaker identification'. We would therefore suggest a different phrase for these capabilities: Speaker Identification/Verification (SIV). Section 4 3. Reference is made to VoiceXML as an example platform - we would also suggest naming a SALT platform for the same purposes - particularly in a mobile architecture - and we can suggest some wording here if you would like. Section 5.4 4. The requirement to be compatible with the IAB OPES framework is somewhat unspecific, and appears to require more digestion of a third party document which many readers will not undertake. Is is possible to make this requirement more tangible without sending the reader off to the OPES specification? Section 5.5 5. It's unclear whether this requirement implies that SpeechSC needs to be aware of Load Balancing mechanisms in order to perform Load Balancing or not. We hope this is not the case. Section 5.6 6. The MUST requirement to permit multiple operations on a single stream may significantly affect SpeechSC design, but we do not believe the scenarios which are enabled by this are sufficiently compelling to make it a must-have. So we suggest this requirement should be a SHOULD. Section 6 7. It is unclear what 'voicing' means in this section (in the world of phonology it refers to a specific phenomenon of pronunciation which is clearly not intended). Does it mean something along the lines of 'output voice selection'? 8. Also the term 'reading' is somewhat confusing in this section. How about 'playback' or 'synthesis'? 9. The case of mixed TTS and audio files in the same output is not addressed explicitly anywhere in this section. This is a common use case (eg 'please speak after the beep ', or 'here's your voice mail , what do you want to do now?'). The text seems to assume a disjunction, but especially since SSML can carry references to remote audio files, it may be useful to address this scenario more explicitly. 10. (paras 2, 3, 4) The subtle switch to explicit requirements on the TTS server is confusing. Surely we should be defining requirements only on the framework. The abilities of the components of the framework should be called out separately either as (a) conformance issues, or (b) assumptions on individual component capabilities. They should certainly be in a different section. In any case, we believe the requirements in these paragraphs should be requirements on the framework itself. 11. (para 6) The loose definitions in this paragraph render it hard to understand. We do not understand what is actually intended by the SHOULD and MAY capabilities here. 12. (para 7) Again, point 10 on the TTS Server requirements. We also believe that such capabilities are not MUSTs in either case, but rather SHOULD for the framework (and correspondingly MAY for Server conformance). 13. (penultimate para) The term 'prosody' is not defined, but this is a crucial requirement on the framework (see also point 7 on 'voicing'). Section 7 14. Again, TCP seems to be ruled out in this section. A useful requirement may be to address 'guarantee of delivery' for ASR. 15. (para 5) The requirement to accommodate "all of the protocol parameters" of MRCP needs to be justified. We believe it is too strong, since it assumes that MRCP is an exact fit to SpeechSC, whereas we believe MRCP may be over-specialized for use in VoiceXML environments. This paragraph is also another case where crucial requirements are made by reference to another spec; we think these should be explicit in this document. 16. (para 7) Again, this is a requirements on a component, and it is unclear what it adds to the requirement on the framework in para 3. Section 8 17. (para 1) Again, assumption of RTP only. 18. (para 3) It is unclear what burden this requirement places on the framework. Section 9 19. It took a couple of readings to decipher that there are two very different definitions of 'dual mode' at play here. Suggest they are called out in advance of the rationale. Section 10 20. (para 2) "Investigating' is a rather vague term for a non-requirement. Is the intention to say that the WG will not be 'defining' DSR coding schemes? _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 07:33:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18607 for ; Fri, 20 Sep 2002 07:33:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KBYde24180 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 07:34:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KBYdv24177 for ; Fri, 20 Sep 2002 07:34:39 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18602 for ; Fri, 20 Sep 2002 07:32:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KBY4v24164; Fri, 20 Sep 2002 07:34:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KBXSv24146 for ; Fri, 20 Sep 2002 07:33:28 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18586 for ; Fri, 20 Sep 2002 07:31:38 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8KBWo3x008284 for ; Fri, 20 Sep 2002 04:32:50 -0700 (PDT) Received: from ORANLT.cisco.com ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC05911; Fri, 20 Sep 2002 04:33:13 -0700 (PDT) Date: Fri, 20 Sep 2002 07:34:20 -0400 From: "David R. Oran" To: speechsc@ietf.org Message-ID: <141374876.1032507260@ORANLT.cisco.com> X-Mailer: Mulberry/3.0.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Speechsc] Gentle reminder: WGLC closes today on draft-ietf-speechsc-reqmts-00.txt Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit please get your comments in if you haven't already. Discussion on the list is obviously encouraged, as that's what I'll use as a guide for consensus on changes. Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 09:17:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21318 for ; Fri, 20 Sep 2002 09:17:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KDIYj29618 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 09:18:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KDIYv29615 for ; Fri, 20 Sep 2002 09:18:34 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21292 for ; Fri, 20 Sep 2002 09:16:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KDI1v29545; Fri, 20 Sep 2002 09:18:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KDHTv29525 for ; Fri, 20 Sep 2002 09:17:29 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21274 for ; Fri, 20 Sep 2002 09:15:23 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8KDGa3x001099; Fri, 20 Sep 2002 06:16:36 -0700 (PDT) Received: from ORANLT.cisco.com ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC06883; Fri, 20 Sep 2002 06:16:58 -0700 (PDT) Date: Fri, 20 Sep 2002 09:18:05 -0400 From: "David R. Oran" To: qzhou@research.bell-labs.com cc: speechsc@ietf.org Subject: Re: Comments on [Speechsc] WGLC for Requirements draft Message-ID: <147600488.1032513485@ORANLT.cisco.com> In-Reply-To: <3D8AE8D4.99406EE8@research.bell-labs.com> References: <368216497.1031074378@OranLT.cisco.com> <3D8AE8D4.99406EE8@research.bell-labs.com> X-Mailer: Mulberry/3.0.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your comprehensive and detailed review of the requirements draft. This is exactly the kind of feedback we want for last call (although earlier would have been even better :-) ) Responses and comments inline. --On Friday, September 20, 2002 5:22 AM -0400 Qiru Zhou wrote: > Hi, speechsc WG, > > My comments on the SPEECHSC requirements draft. Also I am interested in > to volunteer for MRCP if needed. > > -- Qiru > > 1. Abstract > > Speaker identification and speaker verification are quite different > technologies. They require significant different application > implementations. > > Suggestion: > > change > automatic speech recognition, speaker recognition (which includes > both speaker identification and speaker verification) and > text-to-speech. to > speech recognition, speaker identification, speaker verification, and > text-to-speech. > The text is the way it is because throughout the rest of the draft we use the term "speaker recognition" to apply to both. I am averse to changing this unless we also decide to have separate sections with separate requirements for the two. If there are in fact a different set of protocol requirements for the two applciations (as opposed to just the different implementations you cite above) I am happy to do that if someone will enumerae the differences in the requirements. > 3. Introduction > text "Automated Speech Recognition (ASR), speaker recognition (SR)" is > confusing since in lot of literature SR means speech recognition. > > Suggestioin: > change to "Speech Recognition (SR), speaker identification (SI) and > speaker verification (SV)". > This is closely related to the issue above. Let's deal with them together. If we decide to not change the wording, we could decide to just change the acronym from SR to something else, such as SPR for "SPeaker Recognition". > 4. SPEECHSC Framework > It is not clear to me what the relation of speechsc to MRCP is. From > document "draft-shanmugham-mrcp-02", speech components (SR, SI, SV, TTS, > etc.) are plug-in components to MRCP. And MRCP provides underlining > control carrier protocol to make speech components distributed. Is this > picture still hold? In my opinion, this framework is good and it > reduces many redundancy between speechsc and MRCP. > Yes, the framework still holds (and the WG seems to have consensus that it is the appropriate framework). What you may be missing is that this draft is meant to be input to the evaluation of existing protocols and based on that, either the selection of an existing protocol, the modification of an existing protocol, or the design of a new protocol. MRCP is obviously one candidate as the starting point. So the redundancy between the framework which produced MRCP and the SPEECHSC framework is not coincidental. That said, the idea of having the various types of services as "plug-ins" to a general-purpose protocol is a very good one, and such a protocol structure would IMO be a plus to be noted in the protocol evaluations. I'm not sure this addresses completely the thrust of your comment. If not, please elaborate, or even better SEND CANDIDATE REPLACEMENT TEXT. > Also I believe that specify speech components deal RTP streams only > restricts the usability of speechsc protocol. In many none telephony > or VoIP applications, speech input/output many not need to be send > via UDP, or they are more efficient to be send via other means of > network transport, such as TCP, or even a whole utterance at once. > Examples are wireless PDA speech dialogues, speaker verification > enrollment and verification, internal network stream transport such > as speech server to internal media servers and media gateways. > We did not consider media transport protocols other than RTP. This was intentional. It seems you are asking us to revisit this. What does the WG think, keeping in mind that RTP can be sent over TCP as well as UDP for the kinds of environments Qiro cites. > In general, most of the current speech engines deal only buffered > audio blocks. It will be easier to specify RTP pack/unpack process > outside speech components as a separated module which deal general > audio streams. RTP pack/unpack module is also reusable for other > media processing, such as voice/audio recording/playback, etc.) > This seems like a good way to build your speech server, but (a)what is the requirement behind this, and (b)isn't this an implementation detail independent of the protocol? > 5. General Requirements > > 5.4. Explicit invocation of services > It will be good to have an use case here to explain the IAB OPES > compliance. It is hard to me to understand the implication here. > Did you read the OPES documents? We can certainly add an example of what would be non-compliant; such examples are relatively easy to construct (all you need is a stateful intermediary that neither the client nor the server wanted in the path). > 5.5. Server Location and Load Balancing > I'd like to specify here the speechsc framework SHOULD be aware > of server location and load balancing, instead perform these > itself. The actual server location and load balancing should > be out of the speechsc scope. > I'm not sure exactly what you're saying here that is different from what is in the text. Could you say exactly what you think is different, or even better SEND CANDIDATE REPLACEMENT TEXT. > 5.6. Simultaneous services > Ths requirement implicates the following cases: > 1. one input voice stream can be consumed by several speechsc > devices, such as SR, SI and SV, recording, etc. All these > processing are independent to each other. > > 2. A single speechsc device can do SR, SI, SV, etc. on same > audio input. And SI/SV may depend on SR results. > > Simultaneous or parallel are proper words here. It is application > dependent. I suggest change ?5.6 Simultaneous services? to > ?Media stream multiprocessing? and remove ?in parallel.? > I'm afraid I'm not following you completely here. The requirement clearly states the need to be able to perform multiple services in parallel. Given that you can always do this with separate instances of the protocol emanating from one client, the implication of the requirement is beyond that, to allow one instance of the protocol to express multiple services be preformed on the same RTP stream. Is that what you're getting at? If so, we can try to be more explicit in the text. > 6. TTS Requirements > Suggest change ?to playback text as voice in an RTP stream.? To > ?to synthesis text as speech in a packetized audio stream.? > I'm not enthusiastic about this change, for two reasons: (a)the discussion above on RTP versus being agnostic about the media transport, and (b)The requirement to "synthesis"[sic] is a requirement on the server and not the protocol/framework. The protocol doesn't much care if you actually do synthesis or just match the input text to a canned audio file. > ?reading? is not a good word to describe TTS synthesis. > ?synthesis? is more accurate. Also ?playback? or ?output? > are acceptable. > I like "playback". I'll make this change as "The TTS Server MUST support the playback of plain text as speech. For playing back..." > What is the definition of ?document type of the text to > be processed? here? The document encoding, format, or language? > I believe we are just re-using W3C terminology here. Brian(s), Stephane, could one of you help out here? > I am not sure why a TTS server needs "VCR Controls" functions. The glib answer is because the WG thinks so. > Is this refer to the audio stream already produced by a TTS > server, Or the text before input to a TTS server. How the server does this is an implementation detail. From the point of view of the protocol, the control is via markers in the markup. > I don't > know how do you specify ?time mark? accurately on the input > text. If you have both the input and the output this would appear (at least to me) to be pretty strightforward). > If the text is already produced by TTS, it seems to be > more logical to use an audio player to provide ?VCR? or > tape player functions. These functions can be used for other > audio source as well. It is more complicate and impractical > to implement the ?VCR? functions redundantly. > I'm not following you here. The client of the speechsc protocol might very well BE an audio player. The model here is very much like the RTSP control model, where the media processing is in the client and the media generation/storage is on the server. Clearly, unless you can cache all output at the client some control mechanism is needed in the protocol to control playback. Caching at the client (or alternatively, in a separate "audio server" is infeasible in many cases - you may have just told the TTS server to read you War and Peace. > 7. ASR Requirements > > Reference [15] means: ?The ASR Server MUST support the VoiceXML > Speech grammar specification for speech recognition [15].? Is > XML specification means that we only want to support XML format > of SRGS, not ABNF? > No, I think is says we MUST support SRGS, not that we only want to support that. Another requirement is for extensibility to other forms. The purpose of the requirement is to ensure a non-null intersection of capabilities between clients and servers, while keeping the set of mandatory-to-implement things as small as feasible. Does this address our concern? > In server based speech applications, many grammars (especially > Large grammars) are provided by the application server instead > of a client. For example, it is impractical to require a client > Provide a company name dialing list via network connections. > Also this may create security issues. > We require the ABILITY to specify the grammar by either value (the cas eyou cite here), or by reference. If the "by reference" mode does not address your concern here, could you elaborate a bit on why? > If SPEECHSC is inter operable with VoiceXML or a new coming > multimodal markup language (SALT, XHTML+VXML, etc.), Should > we need to support all MUST parameters from VXML, etc.? > See above on minimal but non-null intersection. Clearly if we put a MUST in here with a normative reference to some other document, and that document in turn has MUST statements, those requirements are recursively incorporated into ours. Or do I misunderstand you here? > ?capture the input media stream? is not a function of an > ASR server. It should be achieved by a audio recorder and > media database support. The idea here is twofold: a)that you do not have to send a separate copy of the RTP stream somewhere else b)that you can tell the speechsc server via the control channel to do this, so that it can annotate and corellate the captured audio with its own actions. ?later analysis and tuning? are > functions outside of a runtime ASR engine. Agreed, but where do you get that the actual analysis and tuning functions are requirements of the protocol. Could you suggest replacement text that is clearer? > ?grammar sharing? is a speech engine implementation and performance issue > which may not be necessary to specify in SPEECHSC. Agreed. However, some WG members argued persuasively that this requirement does have implications on the protocol design (e.g. ability to remember grammar sets across sessions) and I tend to agree. > Also a VoiceXML > compliant SR engine need to support rule import/export, multi-grammar > in session as well. > Good point about multiple grammars. On a quick scan I didn't see anything explicit about specifying multiple grammars at once, although I believe the WG intended such. How about a requirement along the lines of "The SPEECHSC framework must allow multiple grammars to be specified to be applied to the same input RTP stream." > 8. Speaker Recognition Requirements > Again, it is more proper to separate speaker verification (SV) and > speaker identification (SI). > Please specify what speechsc reqirements differ between the two and then we can address the desirability of making the separation. > Both SV and SI needs voice print database that is external to the > engine (a speech engine should not carry a gigabyte or terabyte > media database with it. If SPEECHSC supports SV and SI, a voiceprint > database interface MUST be specified. > I don't think this is within the charter of SPEECHSC. I tend to agree that a standardized database interface for voiceprints is something quite desirable, but I suspect that the IETF would eschew work in this area due to lack of expertise in database interfaces/protocols. > Also there is an ANSI BioAPI that address the SV and SI interface > issues has been followed by biometric companies. We need to look > into this to make SPEECHSC compatible with it. BioAPI also address > other means of biometric identifications that are MRCP related. > Good idea to look at this. Can you give me a reference to put in the references section? > I don't think the last two paragraphs are necessary since these > are application specific. Again, audio recording should not be a > speech engine function. > In the case of multi-utterance, I believe the WG consensus was otherwise. The feeling was that while the functions themselves are application and implentation specific, the protocol design can make this easy, hard, or impossible depending on what state is kept, whether the state is kept on the client or server or both, and whether that state is externalizable or opaque. In the case of audio recording, the intention is that the CONTROL of audio recording be required of the speechsc protocol, because of the need for the server (as opposed to just the client) to corellate the recorded stream with its own SV/SR actions. If you still feel this is misguided, try again to make that case and we'll see whether this view persuades the WG to change or eliminate the requirement. > 9. Dual-Mode Requirements > It is clearer to say ?full duplex speech processing requirements?, > instead of ?dual-mode?. > This strikes me as a good change. "Dual mode" never put the right image in my mind, whereas "Full duplex" seems to capture it. Any objections to this change? > Full duplex speech processing requires precise in/out audio > Synchronization, audio play interrupt, echo cancellation, speech > recognition engine part of speech event generation, etc. These > should be addressed in SPEECHSC to support these advanced speech > processing functions. > I follow the need for precision in all of these except echo cancellation. I think that in fact they are covered in the text. If you don't see this, could you PROVUDE TEXT? (The reason I disagree about precise synchronization of ecan is because in general it is infeasible due to the 1-3 second convergence time of state-of-the-art echo cancellation algorithms. You can't maintain real-time responsiveness with 1-3 seconds added to the control loop). > 11. Security Considerations > For speaker verification/identification in a distributed environment, > voiceprint database security and integrity MUST be addressed to > support commercial applications. > Agree, however doesn't the existing text cover this? It says: "speaker verification and identification employs voiceprints whose privacy and integrity must be maintained. While strictly speaking out of scope of the protocol itself, such considerations will be carefully considered and accommodated during protocol design, and will be called out as part of the applicability statement accompanying the protocol specification(s)." > Other comments and thoughts outside the sections: > > 1. Does SPEECHSC need to address speech transcoding and rate > conversions? > Good question. What do others think? My inclination is to put these on the list of things to think about after finishing the stuff on our plate at the moment. On consideration that might mitigate against trying to deal with these in speechsc is that speecsc is client-server whereas these two application are generally peer-to-peer. Viewed from another perspective, TTS/ASR/SR all send results back to the source of the input stream, whereas transcoding and rate adaptation take input from A and send it to B. This is an absolute though, as I could easily envision a service for hearing-impaired users which accomplishes this using speechsc machinery. > 2. SPEECHSC MUST aware of distributed environment OA&M. > Other than a MIB, what do you have in mind? Note to chairs and ADs: perhaps we need to add milestone to produce a MIB for the protocol. In general the IETF does not do OA&M standards. > 3. Support of new generation of smart communication devices, such > as networked PDAs and smart phones. Speech, GUI and other user > interface interactions need to be addressed in SPEECHSC to support > multimodality. > Agree. If you can come up with concrete technical requirements derived for the need to support such things, we'll be very happy to add them! > ========================================================================= > ===== Qiru Zhou > (http://www.multimedia.bell-labs.com) Dialogue Systems Research > Department, Bell Laboratories, Lucent Technologies 600 Mountain Avenue, > 2D428, Murray Hill, NJ 07974, USA > tel +1 908 582 4562 | fax +1 908 582 7308 | > qzhou@research.bell-labs.com > ========================================================================= > ===== Dave. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 11:22:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25897 for ; Fri, 20 Sep 2002 11:22:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KFNX505119 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 11:23:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KFNXv05116 for ; Fri, 20 Sep 2002 11:23:33 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25874 for ; Fri, 20 Sep 2002 11:21:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KFN1v05071; Fri, 20 Sep 2002 11:23:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KFMPv05039 for ; Fri, 20 Sep 2002 11:22:25 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25835 for ; Fri, 20 Sep 2002 11:20:34 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8KFLp1X019799; Fri, 20 Sep 2002 08:21:51 -0700 (PDT) Received: from ORANLT.cisco.com ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC08854; Fri, 20 Sep 2002 08:22:07 -0700 (PDT) Date: Fri, 20 Sep 2002 11:23:14 -0400 From: "David R. Oran" To: Salvador Neto , Eric Burger , speechsc@ietf.org cc: Hsiao-Wuen Hon , Stephen Potter Message-ID: <155109385.1032520994@ORANLT.cisco.com> In-Reply-To: <2A499EF0C1943544B1350C6D2593897E01196CB0@DF-BOWWOW.platinum.corp.microsoft.com> References: <2A499EF0C1943544B1350C6D2593897E01196CB0@DF-BOWWOW.platinum.cor p.microsoft.com> X-Mailer: Mulberry/3.0.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your careful and comprehensive review. This is exactly the kind of feedback and discussion that last call is intended for (although earlier would have been better :-) Responses, comments, and requests embedded. WG - please continue this discussion on the list - we want to see if we can reach closure quickly and get this to the IESG so as to not hold up the protocol analysis work. --On Thursday, September 19, 2002 5:26 PM -0700 Salvador Neto wrote: > A number of people in Microsoft's speech group have reviewed the > SpeechSC requirements draft in detail, and would like to raise the > following comments and questions. > > Please forgive us if these have been discussed in the group already, as > we approach this document as relative newcomers to the group. > > And also, please make sure you include Hsiao-Wuen-Hon > (hon@microsoft.com) and Stephen Potter (spotter@microsoft.com) in your > replies, as they are still in the process of adding themselves to the > list. > Done. > Thanks, > Salvador Assumpcao Neto > Program Manager - .Net Speech group > Microsoft Corporation > > Comments follow... > > Section 3 (and throughout) > 1. The requirements document is clearly focused on telephony gateway > scenarios. We suggest that an equally compelling scenario is mobile > multimodal scenarios where wireless mobile devices can attain ASR/SR/TTS > services via network. If the group agrees that this is an important > scenario to address, we would suggest modification or addition of the > requirements to reflect this. I, for one agree, and suspect the Wg would not have any problem with this. > Specifically, we are concerned that saying > SpeechSC depends on RTP may mean that it depends on UDP. My understanding is that it does not. It is my understanding that RTP can be carried over TCP. The concern over broadening the coverage beyond RTP is that RTP is *the* media carriage standard of the IETF and we are producing an IETF standard here. In particular, we may wish to depend on control <->media protocol corellation and synchronization based on RTP timestamps and SSRCs. If we were to incorporate other media carriage protocols this might substantially complicate the protocol. There is also the issue of barge-in and whether we can depend on the media protocol to have machinery that prevents or at least mitigates head-of-line blocking. We could conceivably just write requirements that any media carriage protocol have certain characteristics, but I would be inclined to retain the RTP dependency for the reasons cited above. Rapid WG and AD feedback on this particular issue is important, I think. > If so, we > believe that for ASR and SR services guarantee of delivery, such as > provided by TCP, may be better suited (rather than real-time > requirement), especially in the case of mobile multimodal scenarios. So > we hope SpeechSC will be open to contemplate such alternatives. > > 2. The term 'speaker recognition' and its acronym SR are rather > confusing, given the widespread use of SR to mean 'speech recognition' > (i.e. ASR), and the use of the word 'recognition' in both concepts. We > understand the meaning of the term to embrace both 'speaker > verification' and 'speaker identification'. We would therefore suggest a > different phrase for these capabilities: Speaker > Identification/Verification (SIV). > I like this suggestion (despite my proposing a different acronym in my note responding to anohter set of comments). If there are no objections, I will adopt this acronym in the next revision of the draft. > Section 4 > 3. Reference is made to VoiceXML as an example platform - we would also > suggest naming a SALT platform for the same purposes - particularly in a > mobile architecture - and we can suggest some wording here if you would > like. > Please do. ASAP. > Section 5.4 > 4. The requirement to be compatible with the IAB OPES framework is > somewhat unspecific, and appears to require more digestion of a third > party document which many readers will not undertake. Is is possible to > make this requirement more tangible without sending the reader off to > the OPES specification? > Another comment asked for an example of how one might run afoul of OPES. Would be satisfactory? On a more philosophical note, these requirements are meant primarily to be consumed by the people undertaking the analysys of existing protocols, and as a measure against which to evaluate any protocol the WG proposes to the IETF for adoption as a standard. As WG chair I would expect and indeed demand that at least those folks in fact read and absorb the OPES documents since they are relevant to the design of a SPEECHSC protocol and point out many pits others have fallen into. > Section 5.5 > 5. It's unclear whether this requirement implies that SpeechSC needs to > be aware of Load Balancing mechanisms in order to perform Load Balancing > or not. We hope this is not the case. > Could you restate this comment, please? If speechsc itself performs load balancing it by definition needs to be aware of load balancing mechanisms. If it does not perform load balancing itself, it may still need to be aware that load balancing may occur, because there are known cases in which protocols break, or perform in a highly suboptimal way when load balanced, unless this was considered in the design. The intent of the requirement is to say that Speechsc my take into account load balancing, but not replicate the functions of load balancing protocols as part of its design. We'd appreciate any attempt you could make to capture this better than the existing text. > Section 5.6 > 6. The MUST requirement to permit multiple operations on a single stream > may significantly affect SpeechSC design, but we do not believe the > scenarios which are enabled by this are sufficiently compelling to make > it a must-have. So we suggest this requirement should be a SHOULD. > In earlier list discussion and at the Yokohmam IETF meeting, the consensus was this is a MUST requirement. Let's revisit this given we have a counter view. WG members, please weigh in here. > Section 6 > 7. It is unclear what 'voicing' means in this section (in the world of > phonology it refers to a specific phenomenon of pronunciation which is > clearly not intended). Does it mean something along the lines of 'output > voice selection'? > In fact my understanding it was precisely the pronunciation details in addition to the gross aspect of selecting a particular speakers' voice which were intended. I could of course be wrong. WG - help us out here - which do you think was intended. I'll reword as needed once we have consensus. > 8. Also the term 'reading' is somewhat confusing in this section. How > about 'playback' or 'synthesis'? > Agree, and another set of comments pointed this out. I will change to "playback", and note that "synthesis" is not quite right either because the output my be just the result of matching a work or phrase in text to a pre-canned audio file rather than actually doing synthesis. > 9. The case of mixed TTS and audio files in the same output is not > addressed explicitly anywhere in this section. This is a common use case > (eg 'please speak after the beep ', or 'here's your voice mail > , what do you want to do now?'). The text seems to assume a > disjunction, but especially since SSML can carry references to remote > audio files, it may be useful to address this scenario more explicitly. > Agree. Could you please SUPPLY TEXT. Thanks. > 10. (paras 2, 3, 4) The subtle switch to explicit requirements on the > TTS server is confusing. Surely we should be defining requirements only > on the framework. The abilities of the components of the framework > should be called out separately either as (a) conformance issues, or (b) > assumptions on individual component capabilities. They should certainly > be in a different section. In any case, we believe the requirements in > these paragraphs should be requirements on the framework itself. > Hmmm, I suppose we could do a better job here. The intent is to highlight how requirments on the protocol relate to things the servers are assumed to be doing or not doing. While separating these out lexically might ameliorate this problem it might cause other problems in understanding how the various requirements relate to one another. I could go either way on this. How strongly do you feel that the existing text/structure needs to change? > 11. (para 6) The loose definitions in this paragraph render it hard to > understand. We do not understand what is actually intended by the SHOULD > and MAY capabilities here. > Ouch. You'll have to help me figure out what is wrong, since it's crystal clear to me (I know this isn't too helpful). What we are trying to say is that it is pretty important (SHOULD) that the protocol be able to keep its control channel, and hence its basic control synchronization state, over longer than one session (where session is loosely corellated with a "call", SIP dialog, or session state of the associated voice application). We then say that it would be perfectly OK but not required (MAY) if the protocol was capable of a complete {setup/do work/shut down} cycle on shorter scale, down to a single interaction for one utterance. > 12. (para 7) Again, point 10 on the TTS Server requirements. We also > believe that such capabilities are not MUSTs in either case, but rather > SHOULD for the framework (and correspondingly MAY for Server > conformance). > The WG consensus was otherwise, but now you are the second set of folks commenting that we ought to water this down to SHOULD. I am personally inclined to keep this as a MUST, since adding this to the protocol later if not accommodated in the design up front could be very difficult. On apractical basis, a number of the candidate protocols (MRCP, RTSP) already do this, so meeting the MUST may not in practice be all that difficult. Need WG feedback on this point so we can reach closure! > 13. (penultimate para) > The term 'prosody' is not defined, but this is a crucial requirement on > the framework (see also point 7 on 'voicing'). > Good point. Could you please SUPPLY TEXT. > Section 7 > 14. Again, TCP seems to be ruled out in this section. A useful > requirement may be to address 'guarantee of delivery' for ASR. > Where do you think TCP is ruled out in section 7? I can't find it, sorry. > 15. (para 5) The requirement to accommodate "all of the protocol > parameters" of MRCP needs to be justified. We believe it is too strong, > since it assumes that MRCP is an exact fit to SpeechSC, whereas we > believe MRCP may be over-specialized for use in VoiceXML environments. Au contraire. If MRCP met the requirements we likely would not even be having this WG or this discussion; we would be having an MRCP WG or just asking the IESG to bless MRCP as a proposed standard. To address the substance of your comment, there was WG consensus that none of the parameters in MRCP could be eliminated without losing some functionality that was deemed essential. This is not to say that the set in MRCP is complete by any means. We know it's not. It would be helpful if you could enumerate that parameters in MRCP that you do not believe are essential, keeping in mind that we want the speechsc protocol to have wide applicability which *includes* but is *not limited to* VoiceXML environments. > This paragraph is also another case where crucial requirements are made > by reference to another spec; we think these should be explicit in this > document. > Would you suggest we do the same for everything in SMIL as well, which we incorporate by reference. I'm sympathetic to the pain it causes a reader to have to chase separate documents, but am reluctant to mass import text that is easily available and be more understandable in context. If the WG wants to import this, I'll do it. > 16. (para 7) Again, this is a requirements on a component, and it is > unclear what it adds to the requirement on the framework in para 3. > I'm somewhat sympathetic to this view, but on balance I'm inclined to keep these things because the do very much inform the protocol design, in this case how important it is to presume caching of grammar definitions when there is a long-lived control channel. > Section 8 > 17. (para 1) Again, assumption of RTP only. > > 18. (para 3) It is unclear what burden this requirement places on the > framework. > It says that if the protocol is purely transactional with no cross-transaction state it may run afoul of SV servers who fail to work right if the protocol resets their state on each interaction. The requirement is stated this way so that the protocol evaluators/designers think about the underlying operation of the SV servers when considering the interaction models that the protcol needs to support. Would you like to take a crack at expressing this better than the existing text? > Section 9 > 19. It took a couple of readings to decipher that there are two very > different definitions of 'dual mode' at play here. Suggest they are > called out in advance of the rationale. > Right. We'll to take a crack at this based on this comment and a similar comment from someone else. One good suggestion is to pitch the term "dual-mode" and say "full-duplex" instead, which may go a long way to helping get across the substance. > Section 10 > 20. (para 2) "Investigating' is a rather vague term for a > non-requirement. Is the intention to say that the WG will not be > 'defining' DSR coding schemes? > Yes. In addition we won't even discuss them or do any investigation/evaluation of various DSR schemes. They're just anohter codec to us :-) [fin] Dave. ------------------------ David R. Oran 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 12:40:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28898 for ; Fri, 20 Sep 2002 12:40:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KGfb609835 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 12:41:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KGfbv09832 for ; Fri, 20 Sep 2002 12:41:37 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28878 for ; Fri, 20 Sep 2002 12:39:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KGf5v09818; Fri, 20 Sep 2002 12:41:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KGe1v09696 for ; Fri, 20 Sep 2002 12:40:01 -0400 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28797 for ; Fri, 20 Sep 2002 12:38:08 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8KGdJIV312096; Fri, 20 Sep 2002 12:39:19 -0400 Received: from d27mc601.rchland.ibm.com (d27mc601.rchland.ibm.com [9.10.226.32]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8KGdG6w086390; Fri, 20 Sep 2002 12:39:17 -0400 In-Reply-To: <155109385.1032520994@ORANLT.cisco.com> To: "David R. Oran" Cc: Eric Burger , Hsiao-Wuen Hon , Salvador Neto , speechsc@ietf.org, speechsc-admin@ietf.org, Stephen Potter MIME-Version: 1.0 Subject: Re: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt X-Mailer: Lotus Notes Build V60_M14_08012002 Release Candidate August 01, 2002 From: "Jeff Kusnitz" Message-ID: Date: Fri, 20 Sep 2002 09:39:14 -0700 X-MIMETrack: Serialize by Router on d27mc601/27/M/IBM(Release 5.0.11 |July 24, 2002) at 09/20/2002 11:39:17 AM, Serialize complete at 09/20/2002 11:39:17 AM Content-Type: text/html; charset="US-ASCII" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: ,
With respect to SR vs SIV, as the industry understands that Speaker Recognition means speaker identification and verification, I don't see the motivation to coin a new phrase for it.  The fact that it's acronym is misleading is a separate issue (which I tend to agree with).

Jeff



"David R. Oran" <oran@cisco.com>
Sent by: speechsc-admin@ietf.org

09/20/2002 08:23 AM

       
        To:        Salvador Neto <salvadon@exchange.microsoft.com>, Eric Burger <eburger@snowshore.com>, speechsc@ietf.org
        cc:        Hsiao-Wuen Hon <hon@microsoft.com>, Stephen Potter <spotter@microsoft.com>
        Subject:        [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt

       


Thanks for your careful and comprehensive review. This is exactly the kind
of feedback and discussion that last call is intended for (although earlier
would have been better :-)

Responses, comments, and requests embedded.

WG - please continue this discussion on the list - we want to see if we can
reach closure quickly and get this to the IESG so as to not hold up the
protocol analysis work.


--On Thursday, September 19, 2002 5:26 PM -0700 Salvador Neto
<salvadon@Exchange.Microsoft.com> wrote:

> A number of people in Microsoft's speech group have reviewed the
> SpeechSC requirements draft in detail, and would like to raise the
> following comments and questions.
>
> Please forgive us if these have been discussed in the group already, as
> we approach this document as relative newcomers to the group.
>
> And also, please make sure you include Hsiao-Wuen-Hon
> (hon@microsoft.com) and Stephen Potter (spotter@microsoft.com) in your
> replies, as they are still in the process of adding themselves to the
> list.
>
Done.

> Thanks,
> Salvador Assumpcao Neto
> Program Manager - .Net Speech group
> Microsoft Corporation
>
> Comments follow...
>
> Section 3 (and throughout)
> 1. The requirements document is clearly focused on telephony gateway
> scenarios. We suggest that an equally compelling scenario is mobile
> multimodal scenarios where wireless mobile devices can attain ASR/SR/TTS
> services via network. If the group agrees that this is an important
> scenario to address, we would suggest modification or addition of the
> requirements to reflect this.
I, for one agree, and suspect the Wg would not have any problem with this.

> Specifically, we are concerned that saying
> SpeechSC depends on RTP may mean that it depends on UDP.
My understanding is that it does not. It is my understanding that RTP can
be carried over TCP. The concern over broadening the coverage beyond RTP is
that RTP is *the* media carriage standard of the IETF and we are producing
an IETF standard here. In particular, we may wish to depend on control
<->media protocol corellation and synchronization based on RTP timestamps
and SSRCs. If we were to incorporate other media carriage protocols this
might substantially complicate the protocol.

There is also the issue of barge-in and whether we can depend on the media
protocol to have machinery that prevents or at least mitigates head-of-line
blocking.

We could conceivably just write requirements that any media carriage
protocol have certain characteristics, but I would be inclined to retain
the RTP dependency for the reasons cited above.

Rapid WG and AD feedback on this particular issue is important, I think.

> If so, we
> believe that for ASR and SR services guarantee of delivery, such as
> provided by TCP, may be better suited (rather than real-time
> requirement), especially in the case of mobile multimodal scenarios. So
> we hope SpeechSC will be open to contemplate such alternatives.
>
> 2. The term 'speaker recognition' and its acronym SR are rather
> confusing, given the widespread use of SR to mean 'speech recognition'
> (i.e. ASR), and the use of the word 'recognition' in both concepts. We
> understand the meaning of the term to embrace both 'speaker
> verification' and 'speaker identification'. We would therefore suggest a
> different phrase for these capabilities: Speaker
> Identification/Verification (SIV).
>
I like this suggestion (despite my proposing a different acronym in my note
responding to anohter set of comments). If there are no objections, I will
adopt this acronym in the next revision of the draft.

> Section 4
> 3. Reference is made to VoiceXML as an example platform - we would also
> suggest naming a SALT platform for the same purposes - particularly in a
> mobile architecture - and we can suggest some wording here if you would
> like.
>
Please do. ASAP.

> Section 5.4
> 4. The requirement to be compatible with the IAB OPES framework is
> somewhat unspecific, and appears to require more digestion of a third
> party document which many readers will not undertake. Is is possible to
> make this requirement more tangible without sending the reader off to
> the OPES specification?
>
Another comment asked for an example of how one might run afoul of OPES.
Would be satisfactory?

On a more philosophical note, these requirements are meant primarily to be
consumed by the people undertaking the analysys of existing protocols, and
as a measure against which to evaluate any protocol the WG proposes to the
IETF for adoption as a standard. As WG chair I would expect and indeed
demand that at least those folks in fact read and absorb the OPES documents
since they are relevant to the design of a SPEECHSC protocol and point out
many pits others have fallen into.

> Section 5.5
> 5. It's unclear whether this requirement implies that SpeechSC needs to
> be aware of Load Balancing mechanisms in order to perform Load Balancing
> or not. We hope this is not the case.
>
Could you restate this comment, please? If speechsc itself performs load
balancing it by definition needs to be aware of load balancing mechanisms.
If it does not perform load balancing itself, it may still need to be aware
that load balancing may occur, because there are known cases in which
protocols break, or perform in a highly suboptimal way when load balanced,
unless this was considered in the design. The intent of the requirement is
to say that Speechsc my take into account load balancing, but not replicate
the functions of load balancing protocols as part of its design.

We'd appreciate any attempt you could make to capture this better than the
existing text.

> Section 5.6
> 6. The MUST requirement to permit multiple operations on a single stream
> may significantly affect SpeechSC design, but we do not believe the
> scenarios which are enabled by this are sufficiently compelling to make
> it a must-have. So we suggest this requirement should be a SHOULD.
>
In earlier list discussion and at the Yokohmam IETF meeting, the consensus
was this is a MUST requirement. Let's revisit this given we have a counter
view.

WG members, please weigh in here.

> Section 6
> 7. It is unclear what 'voicing' means in this section (in the world of
> phonology it refers to a specific phenomenon of pronunciation which is
> clearly not intended). Does it mean something along the lines of 'output
> voice selection'?
>
In fact my understanding it was precisely the pronunciation details in
addition to the gross aspect of selecting a particular speakers' voice
which were intended. I could of course be wrong. WG - help us out here -
which do you think was intended. I'll reword as needed once we have
consensus.

> 8. Also the term 'reading' is somewhat confusing in this section. How
> about 'playback' or 'synthesis'?
>
Agree, and another set of comments pointed this out. I will change to
"playback", and note that "synthesis" is not quite right either because the
output my be just the result of matching a work or phrase in text to a
pre-canned audio file rather than actually doing synthesis.

> 9. The case of mixed TTS and audio files in the same output is not
> addressed explicitly anywhere in this section. This is a common use case
> (eg 'please speak after the beep <beep>', or 'here's your voice mail
> <message>, what do you want to do now?'). The text seems to assume a
> disjunction, but especially since SSML can carry references to remote
> audio files, it may be useful to address this scenario more explicitly.
>
Agree. Could you please SUPPLY TEXT. Thanks.

> 10. (paras 2, 3, 4) The subtle switch to explicit requirements on the
> TTS server is confusing. Surely we should be defining requirements only
> on the framework. The abilities of the components of the framework
> should be called out separately either as (a) conformance issues, or (b)
> assumptions on individual component capabilities. They should certainly
> be in a different section. In any case, we believe the requirements in
> these paragraphs should be requirements on the framework itself.
>
Hmmm, I suppose we could do a better job here. The intent is to highlight
how requirments on the protocol relate to things the servers are assumed to
be doing or not doing. While separating these out lexically might
ameliorate this problem it might cause other problems in understanding how
the various requirements relate to one another. I could go either way on
this. How strongly do you feel that the existing text/structure needs to
change?

> 11. (para 6) The loose definitions in this paragraph render it hard to
> understand. We do not understand what is actually intended by the SHOULD
> and MAY capabilities here.
>
Ouch. You'll have to help me figure out what is wrong, since it's crystal
clear to me (I know this isn't too  helpful). What we are trying to say is
that it is pretty important (SHOULD) that the protocol be able to keep its
control channel, and hence its basic control synchronization state, over
longer than one session (where session is loosely corellated with a "call",
SIP dialog, or session state of the associated voice application). We then
say that it would be perfectly OK but not required (MAY) if the protocol
was capable of a complete {setup/do work/shut down} cycle on shorter scale,
down to a single interaction for one utterance.

> 12. (para 7) Again, point 10 on the TTS Server requirements. We also
> believe that such capabilities are not MUSTs in either case, but rather
> SHOULD for the framework (and correspondingly MAY for Server
> conformance).
>
The WG consensus was otherwise, but now you are the second set of folks
commenting that we ought to water this down to SHOULD. I am personally
inclined to keep this as a MUST, since adding this to the protocol later if
not accommodated in the design up front could be very difficult. On
apractical basis, a number of the candidate protocols (MRCP, RTSP) already
do this, so meeting the MUST may not in practice be all that difficult.

Need WG feedback on this point so we can reach closure!

> 13. (penultimate para)
> The term 'prosody' is not defined, but this is a crucial requirement on
> the framework (see also point 7 on 'voicing').
>
Good point. Could you please SUPPLY TEXT.

> Section 7
> 14. Again, TCP seems to be ruled out in this section. A useful
> requirement may be to address 'guarantee of delivery' for ASR.
>
Where do you think TCP is ruled out in section 7?  I can't find it, sorry.

> 15. (para 5) The requirement to accommodate "all of the protocol
> parameters" of MRCP needs to be justified. We believe it is too strong,
> since it assumes that MRCP is an exact fit to SpeechSC, whereas we
> believe MRCP may be over-specialized for use in VoiceXML environments.
Au contraire. If MRCP met the requirements we likely would not even be
having this WG or this discussion; we would be having an MRCP WG or just
asking the IESG to bless MRCP as a proposed standard.

To address the substance of your comment, there was WG consensus that none
of the parameters in MRCP could be eliminated without losing some
functionality that was deemed essential. This is not to say that the set in
MRCP is complete by any means. We know it's not. It would be helpful if you
could enumerate that parameters in MRCP that you do not believe are
essential, keeping in mind that we want the speechsc protocol to have wide
applicability which *includes* but is *not limited to* VoiceXML
environments.

> This paragraph is also another case where crucial requirements are made
> by reference to another spec; we think these should be explicit in this
> document.
>
Would you suggest we do the same for everything in SMIL as well, which we
incorporate by reference. I'm sympathetic to the pain it causes a reader to
have to chase separate documents, but am reluctant to mass import text that
is easily available and be more understandable in context.

If the WG wants to import this, I'll do it.

> 16. (para 7) Again, this is a requirements on a component, and it is
> unclear what it adds to the requirement on the framework in para 3.
>
I'm somewhat sympathetic to this view, but on balance I'm inclined to keep
these things because the do very much inform the protocol design, in this
case how important it is to presume caching of grammar definitions when
there is a long-lived control channel.

> Section 8
> 17. (para 1) Again, assumption of RTP only.
>
> 18. (para 3) It is unclear what burden this requirement places on the
> framework.
>
It says that if the protocol is purely transactional with no
cross-transaction state it may run afoul of SV servers who fail to work
right if the protocol resets their state on each interaction. The
requirement is stated this way so that the protocol evaluators/designers
think about the underlying operation of the SV servers when considering the
interaction models that the protcol needs to support.

Would you like to take a crack at expressing this better than the existing
text?

> Section 9
> 19. It took a couple of readings to decipher that there are two very
> different definitions of 'dual mode' at play here. Suggest they are
> called out in advance of the rationale.
>
Right. We'll to take a crack at this based on this comment and a similar
comment from someone else. One good suggestion is to pitch the term
"dual-mode" and say "full-duplex" instead, which may go a long way to
helping get across the substance.

> Section 10
> 20. (para 2) "Investigating' is a rather vague term for a
> non-requirement. Is the intention to say that the WG will not be
> 'defining' DSR coding schemes?
>
Yes. In addition we won't even discuss them or do any
investigation/evaluation of various DSR schemes. They're just anohter codec
to us :-)

[fin]
Dave.
------------------------
David R. Oran
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: oran@cisco.com
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 12:48:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29300 for ; Fri, 20 Sep 2002 12:48:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KGnXc10041 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 12:49:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KGnXv10038 for ; Fri, 20 Sep 2002 12:49:33 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29280 for ; Fri, 20 Sep 2002 12:47:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KGn1v09998; Fri, 20 Sep 2002 12:49:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KGmbv09979 for ; Fri, 20 Sep 2002 12:48:37 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29230 for ; Fri, 20 Sep 2002 12:46:44 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8KGmVhN048670 for ; Fri, 20 Sep 2002 12:48:31 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8KGmOk76967 for ; Fri, 20 Sep 2002 12:48:25 -0400 (EDT) Received: from research.bell-labs.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id MAA2414214; Fri, 20 Sep 2002 12:48:24 -0400 (EDT) Message-ID: <3D8B5158.CB25C92A@research.bell-labs.com> Date: Fri, 20 Sep 2002 12:48:24 -0400 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: speechsc@ietf.org Subject: resubmit: Comments on [Speechsc] WGLC for Requirements draft References: <368216497.1031074378@OranLT.cisco.com> <3D8AE8D4.99406EE8@research.bell-labs.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sorry for resubmit this comments. It was bounced back due to different e-mail reply address was used. -- QZ Hi, speechsc WG, My comments on the SPEECHSC requirements draft. Also I am interested in to volunteer for MRCP if needed. -- Qiru 1. Abstract Speaker identification and speaker verification are quite different technologies. They require significant different application implementations. Suggestion: change automatic speech recognition, speaker recognition (which includes both speaker identification and speaker verification) and text-to-speech. to speech recognition, speaker identification, speaker verification, and text-to-speech. 3. Introduction text "Automated Speech Recognition (ASR), speaker recognition (SR)" is confusing since in lot of literature SR means speech recognition. Suggestioin: change to "Speech Recognition (SR), speaker identification (SI) and speaker verification (SV)". 4. SPEECHSC Framework It is not clear to me what the relation of speechsc to MRCP is. From document "draft-shanmugham-mrcp-02", speech components (SR, SI, SV, TTS, etc.) are plug-in components to MRCP. And MRCP provides underlining control carrier protocol to make speech components distributed. Is this picture still hold? In my opinion, this framework is good and it reduces many redundancy between speechsc and MRCP. Also I believe that specify speech components deal RTP streams only restricts the usability of speechsc protocol. In many none telephony or VoIP applications, speech input/output many not need to be send via UDP, or they are more efficient to be send via other means of network transport, such as TCP, or even a whole utterance at once. Examples are wireless PDA speech dialogues, speaker verification enrollment and verification, internal network stream transport such as speech server to internal media servers and media gateways. In general, most of the current speech engines deal only buffered audio blocks. It will be easier to specify RTP pack/unpack process outside speech components as a separated module which deal general audio streams. RTP pack/unpack module is also reusable for other media processing, such as voice/audio recording/playback, etc.) 5. General Requirements 5.4. Explicit invocation of services It will be good to have an use case here to explain the IAB OPES compliance. It is hard to me to understand the implication here. 5.5. Server Location and Load Balancing I'd like to specify here the speechsc framework SHOULD be aware of server location and load balancing, instead perform these itself. The actual server location and load balancing should be out of the speechsc scope. 5.6. Simultaneous services Ths requirement implicates the following cases: 1. one input voice stream can be consumed by several speechsc devices, such as SR, SI and SV, recording, etc. All these processing are independent to each other. 2. A single speechsc device can do SR, SI, SV, etc. on same audio input. And SI/SV may depend on SR results. Simultaneous or parallel are proper words here. It is application dependent. I suggest change “5.6 Simultaneous services” to “Media stream multiprocessing” and remove “in parallel.” 6. TTS Requirements Suggest change “to playback text as voice in an RTP stream.” To “to synthesis text as speech in a packetized audio stream.” “reading” is not a good word to describe TTS synthesis. “synthesis” is more accurate. Also “playback” or “output” are acceptable. What is the definition of “document type of the text to be processed” here? The document encoding, format, or language? I am not sure why a TTS server needs "VCR Controls" functions. Is this refer to the audio stream already produced by a TTS server, Or the text before input to a TTS server. I don't know how do you specify “time mark” accurately on the input text. If the text is already produced by TTS, it seems to be more logical to use an audio player to provide “VCR” or tape player functions. These functions can be used for other audio source as well. It is more complicate and impractical to implement the “VCR” functions redundantly. 7. ASR Requirements Reference [15] means: “The ASR Server MUST support the VoiceXML Speech grammar specification for speech recognition [15].” Is XML specification means that we only want to support XML format of SRGS, not ABNF? In server based speech applications, many grammars (especially Large grammars) are provided by the application server instead of a client. For example, it is impractical to require a client Provide a company name dialing list via network connections. Also this may create security issues. If SPEECHSC is inter operable with VoiceXML or a new coming multimodal markup language (SALT, XHTML+VXML, etc.), Should we need to support all MUST parameters from VXML, etc.? “capture the input media stream” is not a function of an ASR server. It should be achieved by a audio recorder and media database support. “later analysis and tuning” are functions outside of a runtime ASR engine. “grammar sharing” is a speech engine implementation and performance issue which may not be necessary to specify in SPEECHSC. Also a VoiceXML compliant SR engine need to support rule import/export, multi-grammar in session as well. 8. Speaker Recognition Requirements Again, it is more proper to separate speaker verification (SV) and speaker identification (SI). Both SV and SI needs voice print database that is external to the engine (a speech engine should not carry a gigabyte or terabyte media database with it. If SPEECHSC supports SV and SI, a voiceprint database interface MUST be specified. Also there is an ANSI BioAPI that address the SV and SI interface issues has been followed by biometric companies. We need to look into this to make SPEECHSC compatible with it. BioAPI also address other means of biometric identifications that are MRCP related. I don't think the last two paragraphs are necessary since these are application specific. Again, audio recording should not be a speech engine function. 9. Dual-Mode Requirements It is clearer to say “full duplex speech processing requirements”, instead of “dual-mode”. Full duplex speech processing requires precise in/out audio Synchronization, audio play interrupt, echo cancellation, speech recognition engine part of speech event generation, etc. These should be addressed in SPEECHSC to support these advanced speech processing functions. 11. Security Considerations For speaker verification/identification in a distributed environment, voiceprint database security and integrity MUST be addressed to support commercial applications. Other comments and thoughts outside the sections: 1. Does SPEECHSC need to address speech transcoding and rate conversions? 2. SPEECHSC MUST aware of distributed environment OA&M. 3. Support of new generation of smart communication devices, such as networked PDAs and smart phones. Speech, GUI and other user interface interactions need to be addressed in SPEECHSC to support multimodality. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "David R. Oran" wrote: > > I'd like to begin Working Group Last Call for > draft-ietf-speechsc-reqts-00.txt. Last call will close on Sept 20th. > > Comments to the list, as usual. Thanks. > > Your chairs, > Dave and Eric. > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc ============================================================================== Qiru Zhou ( http://www.multimedia.bell-labs.com) Dialogue Systems Research Department, Bell Laboratories, Lucent Technologies 600 Mountain Avenue, 2D428, Murray Hill, NJ 07974, USA tel +1 908 582 4562 | fax +1 908 582 7308 | qzhou@research.bell-labs.com ============================================================================== _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 13:37:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01339 for ; Fri, 20 Sep 2002 13:37:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KHcZ513313 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 13:38:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KHcZv13310 for ; Fri, 20 Sep 2002 13:38:35 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01302 for ; Fri, 20 Sep 2002 13:36:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KHc3v13293; Fri, 20 Sep 2002 13:38:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KHbVv13268 for ; Fri, 20 Sep 2002 13:37:31 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01278 for ; Fri, 20 Sep 2002 13:35:38 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8KHatW4004027; Fri, 20 Sep 2002 10:36:55 -0700 (PDT) Received: from cisco.com (dhcp-128-107-139-27.cisco.com [128.107.139.27]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFE79002; Fri, 20 Sep 2002 10:32:57 -0700 (PDT) Message-ID: <3D8B5CB5.EC1C14C2@cisco.com> Date: Fri, 20 Sep 2002 10:36:53 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Salvador Neto CC: "David R. Oran" , Eric Burger , speechsc@ietf.org, Hsiao-Wuen Hon , Stephen Potter Subject: Re: [Speechsc] Comments on draft-ietf-speechsc-reqts-00.txt References: <2A499EF0C1943544B1350C6D2593897E01196CB0@DF-BOWWOW.platinum.corp.microsoft.com> Content-Type: multipart/mixed; boundary="------------E2C3210D8454B387A36CD276" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------E2C3210D8454B387A36CD276 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit comments inline. Salvador Neto wrote: > A number of people in Microsoft's speech group have reviewed the > SpeechSC requirements draft in detail, and would like to raise the > following comments and questions. > > Please forgive us if these have been discussed in the group already, as > we approach this document as relative newcomers to the group. > > And also, please make sure you include Hsiao-Wuen-Hon > (hon@microsoft.com) and Stephen Potter (spotter@microsoft.com) in your > replies, as they are still in the process of adding themselves to the > list. > > Thanks, > Salvador Assumpcao Neto > Program Manager - .Net Speech group > Microsoft Corporation > > Comments follow... > > Section 3 (and throughout) > 1. The requirements document is clearly focused on telephony gateway > scenarios. We suggest that an equally compelling scenario is mobile > multimodal scenarios where wireless mobile devices can attain ASR/SR/TTS > services via network. If the group agrees that this is an important > scenario to address, we would suggest modification or addition of the > requirements to reflect this. Specifically, we are concerned that saying > SpeechSC depends on RTP may mean that it depends on UDP. If so, we > believe that for ASR and SR services guarantee of delivery, such as > provided by TCP, may be better suited (rather than real-time > requirement), especially in the case of mobile multimodal scenarios. So > we hope SpeechSC will be open to contemplate such alternatives. Though RTP is used extensively, Section10 says: "The protocol assumes RTP carriage of media. Assuming session- oriented media transport, the protocol will use SDP to describe the session. " So I believe we would be using something like SDP to describe media and hence does not necessarily tie us to RTP. > > > 2. The term 'speaker recognition' and its acronym SR are rather > confusing, given the widespread use of SR to mean 'speech recognition' > (i.e. ASR), and the use of the word 'recognition' in both concepts. We > understand the meaning of the term to embrace both 'speaker > verification' and 'speaker identification'. We would therefore suggest a > different phrase for these capabilities: Speaker > Identification/Verification (SIV). I agree > > > Section 4 > 3. Reference is made to VoiceXML as an example platform - we would also > suggest naming a SALT platform for the same purposes - particularly in a > mobile architecture - and we can suggest some wording here if you would > like. > > Section 5.4 > 4. The requirement to be compatible with the IAB OPES framework is > somewhat unspecific, and appears to require more digestion of a third > party document which many readers will not undertake. Is is possible to > make this requirement more tangible without sending the reader off to > the OPES specification? > > Section 5.5 > 5. It's unclear whether this requirement implies that SpeechSC needs to > be aware of Load Balancing mechanisms in order to perform Load Balancing > or not. We hope this is not the case. > > Section 5.6 > 6. The MUST requirement to permit multiple operations on a single stream > may significantly affect SpeechSC design, but we do not believe the > scenarios which are enabled by this are sufficiently compelling to make > it a must-have. So we suggest this requirement should be a SHOULD. The basis for this is that when a client is dealing with a single server entity for ASR/SIV etc. the client should not have to send it 2 separate streams. I believe this is a MUST and this option is required. But the client, if it chooses to, can make open separate sessions to the same server for ASR and SIV. > > > Section 6 > 7. It is unclear what 'voicing' means in this section (in the world of > phonology it refers to a specific phenomenon of pronunciation which is > clearly not intended). Does it mean something along the lines of 'output > voice selection'? > > 8. Also the term 'reading' is somewhat confusing in this section. How > about 'playback' or 'synthesis'? > > 9. The case of mixed TTS and audio files in the same output is not > addressed explicitly anywhere in this section. This is a common use case > (eg 'please speak after the beep ', or 'here's your voice mail > , what do you want to do now?'). The text seems to assume a > disjunction, but especially since SSML can carry references to remote > audio files, it may be useful to address this scenario more explicitly. SSML allows the interleaving of text and audio and hence in my mind it is an already implied SHOULD requirement. > > > 10. (paras 2, 3, 4) The subtle switch to explicit requirements on the > TTS server is confusing. Surely we should be defining requirements only > on the framework. The abilities of the components of the framework > should be called out separately either as (a) conformance issues, or (b) > assumptions on individual component capabilities. They should certainly > be in a different section. In any case, we believe the requirements in > these paragraphs should be requirements on the framework itself. > > 11. (para 6) The loose definitions in this paragraph render it hard to > understand. We do not understand what is actually intended by the SHOULD > and MAY capabilities here. > > 12. (para 7) Again, point 10 on the TTS Server requirements. We also > believe that such capabilities are not MUSTs in either case, but rather > SHOULD for the framework (and correspondingly MAY for Server > conformance). > > 13. (penultimate para) > The term 'prosody' is not defined, but this is a crucial requirement on > the framework (see also point 7 on 'voicing'). > > Section 7 > 14. Again, TCP seems to be ruled out in this section. A useful > requirement may be to address 'guarantee of delivery' for ASR. > > 15. (para 5) The requirement to accommodate "all of the protocol > parameters" of MRCP needs to be justified. We believe it is too strong, > since it assumes that MRCP is an exact fit to SpeechSC, whereas we > believe MRCP may be over-specialized for use in VoiceXML environments. > This paragraph is also another case where crucial requirements are made > by reference to another spec; we think these should be explicit in this > document. > > 16. (para 7) Again, this is a requirements on a component, and it is > unclear what it adds to the requirement on the framework in para 3. > > Section 8 > 17. (para 1) Again, assumption of RTP only. > > 18. (para 3) It is unclear what burden this requirement places on the > framework. > > Section 9 > 19. It took a couple of readings to decipher that there are two very > different definitions of 'dual mode' at play here. Suggest they are > called out in advance of the rationale. > > Section 10 > 20. (para 2) "Investigating' is a rather vague term for a > non-requirement. Is the intention to say that the WG will not be > 'defining' DSR coding schemes? Yes. The WG will not be defining new codecs. But the SpeechSC protocol should be able to work with differnt codecs including the DSR codec(s) being defined by the various other groups. Here to, choice to use a generic descrption mechanism such as SDP to describe the audio covers bothe the treansmission media and the data/codec types of the media. Thx, Sarvi > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc --------------E2C3210D8454B387A36CD276 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Sarvi tel;work:408-527-4875 x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Group adr:;;;;;; version:2.1 email;internet:sarvi@cisco.com title:Technical Leader fn:Sarvi Shanmugham end:vcard --------------E2C3210D8454B387A36CD276-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 14:07:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02671 for ; Fri, 20 Sep 2002 14:07:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KI8fO15074 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 14:08:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KI8ev15071 for ; Fri, 20 Sep 2002 14:08:40 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02666 for ; Fri, 20 Sep 2002 14:06:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KI86v15057; Fri, 20 Sep 2002 14:08:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KI7sv15043 for ; Fri, 20 Sep 2002 14:07:54 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02657 for ; Fri, 20 Sep 2002 14:06:01 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8KI7IW4024498; Fri, 20 Sep 2002 11:07:18 -0700 (PDT) Received: from cisco.com (dhcp-128-107-139-27.cisco.com [128.107.139.27]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFE80310; Fri, 20 Sep 2002 11:03:20 -0700 (PDT) Message-ID: <3D8B63D3.7A6838D8@cisco.com> Date: Fri, 20 Sep 2002 11:07:15 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "David R. Oran" CC: Salvador Neto , Eric Burger , speechsc@ietf.org, Hsiao-Wuen Hon , Stephen Potter Subject: Re: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt References: <2A499EF0C1943544B1350C6D2593897E01196CB0@DF-BOWWOW.platinum.cor p.microsoft.com> <155109385.1032520994@ORANLT.cisco.com> Content-Type: multipart/mixed; boundary="------------F842077DC5616B196D38BFB0" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------F842077DC5616B196D38BFB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "David R. Oran" wrote: > Thanks for your careful and comprehensive review. This is exactly the kind > of feedback and discussion that last call is intended for (although earlier > would have been better :-) > > Responses, comments, and requests embedded. > > WG - please continue this discussion on the list - we want to see if we can > reach closure quickly and get this to the IESG so as to not hold up the > protocol analysis work. > > --On Thursday, September 19, 2002 5:26 PM -0700 Salvador Neto > wrote: > > > A number of people in Microsoft's speech group have reviewed the > > SpeechSC requirements draft in detail, and would like to raise the > > following comments and questions. > > > > Please forgive us if these have been discussed in the group already, as > > we approach this document as relative newcomers to the group. > > > > And also, please make sure you include Hsiao-Wuen-Hon > > (hon@microsoft.com) and Stephen Potter (spotter@microsoft.com) in your > > replies, as they are still in the process of adding themselves to the > > list. > > > Done. > > > Thanks, > > Salvador Assumpcao Neto > > Program Manager - .Net Speech group > > Microsoft Corporation > > > > Comments follow... > > > > Section 3 (and throughout) > > 1. The requirements document is clearly focused on telephony gateway > > scenarios. We suggest that an equally compelling scenario is mobile > > multimodal scenarios where wireless mobile devices can attain ASR/SR/TTS > > services via network. If the group agrees that this is an important > > scenario to address, we would suggest modification or addition of the > > requirements to reflect this. > I, for one agree, and suspect the Wg would not have any problem with this. > Agreed > > > Specifically, we are concerned that saying > > SpeechSC depends on RTP may mean that it depends on UDP. > My understanding is that it does not. It is my understanding that RTP can > be carried over TCP. The concern over broadening the coverage beyond RTP is > that RTP is *the* media carriage standard of the IETF and we are producing > an IETF standard here. In particular, we may wish to depend on control > <->media protocol corellation and synchronization based on RTP timestamps > and SSRCs. If we were to incorporate other media carriage protocols this > might substantially complicate the protocol. > > There is also the issue of barge-in and whether we can depend on the media > protocol to have machinery that prevents or at least mitigates head-of-line > blocking. > > We could conceivably just write requirements that any media carriage > protocol have certain characteristics, but I would be inclined to retain > the RTP dependency for the reasons cited above. > > Rapid WG and AD feedback on this particular issue is important, I think. As I mentioned in an earlier email. Though RTP would be the prefered way of transmitting media and hence may be extensively refered to the documents and hence a SHOULD requirement, the fact that we would be using generic mechanism such as SDP allows the client and servers which MAY support other mechanism such as TCP to work as well. So I am inclined to leave RTP as a MUST and other mechanism to carry media and described through SDP as a MAY. > > > > If so, we > > believe that for ASR and SR services guarantee of delivery, such as > > provided by TCP, may be better suited (rather than real-time > > requirement), especially in the case of mobile multimodal scenarios. So > > we hope SpeechSC will be open to contemplate such alternatives. > > > > 2. The term 'speaker recognition' and its acronym SR are rather > > confusing, given the widespread use of SR to mean 'speech recognition' > > (i.e. ASR), and the use of the word 'recognition' in both concepts. We > > understand the meaning of the term to embrace both 'speaker > > verification' and 'speaker identification'. We would therefore suggest a > > different phrase for these capabilities: Speaker > > Identification/Verification (SIV). > > > I like this suggestion (despite my proposing a different acronym in my note > responding to anohter set of comments). If there are no objections, I will > adopt this acronym in the next revision of the draft. Agreed. > > > > Section 4 > > 3. Reference is made to VoiceXML as an example platform - we would also > > suggest naming a SALT platform for the same purposes - particularly in a > > mobile architecture - and we can suggest some wording here if you would > > like. > > > Please do. ASAP. > > > Section 5.4 > > 4. The requirement to be compatible with the IAB OPES framework is > > somewhat unspecific, and appears to require more digestion of a third > > party document which many readers will not undertake. Is is possible to > > make this requirement more tangible without sending the reader off to > > the OPES specification? > > > Another comment asked for an example of how one might run afoul of OPES. > Would be satisfactory? > > On a more philosophical note, these requirements are meant primarily to be > consumed by the people undertaking the analysys of existing protocols, and > as a measure against which to evaluate any protocol the WG proposes to the > IETF for adoption as a standard. As WG chair I would expect and indeed > demand that at least those folks in fact read and absorb the OPES documents > since they are relevant to the design of a SPEECHSC protocol and point out > many pits others have fallen into. > Agreed. > > > Section 5.5 > > 5. It's unclear whether this requirement implies that SpeechSC needs to > > be aware of Load Balancing mechanisms in order to perform Load Balancing > > or not. We hope this is not the case. > > > Could you restate this comment, please? If speechsc itself performs load > balancing it by definition needs to be aware of load balancing mechanisms. > If it does not perform load balancing itself, it may still need to be aware > that load balancing may occur, because there are known cases in which > protocols break, or perform in a highly suboptimal way when load balanced, > unless this was considered in the design. The intent of the requirement is > to say that Speechsc my take into account load balancing, but not replicate > the functions of load balancing protocols as part of its design. > > We'd appreciate any attempt you could make to capture this better than the > existing text. > > > Section 5.6 > > 6. The MUST requirement to permit multiple operations on a single stream > > may significantly affect SpeechSC design, but we do not believe the > > scenarios which are enabled by this are sufficiently compelling to make > > it a must-have. So we suggest this requirement should be a SHOULD. > > > In earlier list discussion and at the Yokohmam IETF meeting, the consensus > was this is a MUST requirement. Let's revisit this given we have a counter > view. > > WG members, please weigh in here. As I mentiioned in an earlier mail. I feel this is a MUST requirment for efficiency in big systems such as VoiceXML servers. But at the same time I don't see this MUSt requirment preventing clients from setting up separate sessions for each session or each resource within the session and sending them duplicate media. > > > > Section 6 > > 7. It is unclear what 'voicing' means in this section (in the world of > > phonology it refers to a specific phenomenon of pronunciation which is > > clearly not intended). Does it mean something along the lines of 'output > > voice selection'? > > > In fact my understanding it was precisely the pronunciation details in > addition to the gross aspect of selecting a particular speakers' voice > which were intended. I could of course be wrong. WG - help us out here - > which do you think was intended. I'll reword as needed once we have > consensus. > > > 8. Also the term 'reading' is somewhat confusing in this section. How > > about 'playback' or 'synthesis'? > > > Agree, and another set of comments pointed this out. I will change to > "playback", and note that "synthesis" is not quite right either because the > output my be just the result of matching a work or phrase in text to a > pre-canned audio file rather than actually doing synthesis. > > > 9. The case of mixed TTS and audio files in the same output is not > > addressed explicitly anywhere in this section. This is a common use case > > (eg 'please speak after the beep ', or 'here's your voice mail > > , what do you want to do now?'). The text seems to assume a > > disjunction, but especially since SSML can carry references to remote > > audio files, it may be useful to address this scenario more explicitly. > > > Agree. Could you please SUPPLY TEXT. Thanks. > > > 10. (paras 2, 3, 4) The subtle switch to explicit requirements on the > > TTS server is confusing. Surely we should be defining requirements only > > on the framework. The abilities of the components of the framework > > should be called out separately either as (a) conformance issues, or (b) > > assumptions on individual component capabilities. They should certainly > > be in a different section. In any case, we believe the requirements in > > these paragraphs should be requirements on the framework itself. > > > Hmmm, I suppose we could do a better job here. The intent is to highlight > how requirments on the protocol relate to things the servers are assumed to > be doing or not doing. While separating these out lexically might > ameliorate this problem it might cause other problems in understanding how > the various requirements relate to one another. I could go either way on > this. How strongly do you feel that the existing text/structure needs to > change? > > > 11. (para 6) The loose definitions in this paragraph render it hard to > > understand. We do not understand what is actually intended by the SHOULD > > and MAY capabilities here. > > > Ouch. You'll have to help me figure out what is wrong, since it's crystal > clear to me (I know this isn't too helpful). What we are trying to say is > that it is pretty important (SHOULD) that the protocol be able to keep its > control channel, and hence its basic control synchronization state, over > longer than one session (where session is loosely corellated with a "call", > SIP dialog, or session state of the associated voice application). We then > say that it would be perfectly OK but not required (MAY) if the protocol > was capable of a complete {setup/do work/shut down} cycle on shorter scale, > down to a single interaction for one utterance. > > > 12. (para 7) Again, point 10 on the TTS Server requirements. We also > > believe that such capabilities are not MUSTs in either case, but rather > > SHOULD for the framework (and correspondingly MAY for Server > > conformance). > > > The WG consensus was otherwise, but now you are the second set of folks > commenting that we ought to water this down to SHOULD. I am personally > inclined to keep this as a MUST, since adding this to the protocol later if > not accommodated in the design up front could be very difficult. On > apractical basis, a number of the candidate protocols (MRCP, RTSP) already > do this, so meeting the MUST may not in practice be all that difficult. > > Need WG feedback on this point so we can reach closure! I believe these are a MUST define for the protocol to address or specify. In the protocol definition though, as defined in an earlier comment(point 10), we could make a conformance choice and enumerate the individual features as a SHOULD or MAY. I have no problem with that. > > > > 13. (penultimate para) > > The term 'prosody' is not defined, but this is a crucial requirement on > > the framework (see also point 7 on 'voicing'). > > > Good point. Could you please SUPPLY TEXT. > > > Section 7 > > 14. Again, TCP seems to be ruled out in this section. A useful > > requirement may be to address 'guarantee of delivery' for ASR. > > > Where do you think TCP is ruled out in section 7? I can't find it, sorry. > > > 15. (para 5) The requirement to accommodate "all of the protocol > > parameters" of MRCP needs to be justified. We believe it is too strong, > > since it assumes that MRCP is an exact fit to SpeechSC, whereas we > > believe MRCP may be over-specialized for use in VoiceXML environments. > Au contraire. If MRCP met the requirements we likely would not even be > having this WG or this discussion; we would be having an MRCP WG or just > asking the IESG to bless MRCP as a proposed standard. > > To address the substance of your comment, there was WG consensus that none > of the parameters in MRCP could be eliminated without losing some > functionality that was deemed essential. This is not to say that the set in > MRCP is complete by any means. We know it's not. It would be helpful if you > could enumerate that parameters in MRCP that you do not believe are > essential, keeping in mind that we want the speechsc protocol to have wide > applicability which *includes* but is *not limited to* VoiceXML > environments. > > > This paragraph is also another case where crucial requirements are made > > by reference to another spec; we think these should be explicit in this > > document. > > > Would you suggest we do the same for everything in SMIL as well, which we > incorporate by reference. I'm sympathetic to the pain it causes a reader to > have to chase separate documents, but am reluctant to mass import text that > is easily available and be more understandable in context. > > If the WG wants to import this, I'll do it. Though I do sympathize with the comment, I'm fine with the way it is. > > > > 16. (para 7) Again, this is a requirements on a component, and it is > > unclear what it adds to the requirement on the framework in para 3. > > > I'm somewhat sympathetic to this view, but on balance I'm inclined to keep > these things because the do very much inform the protocol design, in this > case how important it is to presume caching of grammar definitions when > there is a long-lived control channel. I agree Sarvi > > > > Section 8 > > 17. (para 1) Again, assumption of RTP only. > > > > 18. (para 3) It is unclear what burden this requirement places on the > > framework. > > > It says that if the protocol is purely transactional with no > cross-transaction state it may run afoul of SV servers who fail to work > right if the protocol resets their state on each interaction. The > requirement is stated this way so that the protocol evaluators/designers > think about the underlying operation of the SV servers when considering the > interaction models that the protcol needs to support. > > Would you like to take a crack at expressing this better than the existing > text? > > > Section 9 > > 19. It took a couple of readings to decipher that there are two very > > different definitions of 'dual mode' at play here. Suggest they are > > called out in advance of the rationale. > > > Right. We'll to take a crack at this based on this comment and a similar > comment from someone else. One good suggestion is to pitch the term > "dual-mode" and say "full-duplex" instead, which may go a long way to > helping get across the substance. > > > Section 10 > > 20. (para 2) "Investigating' is a rather vague term for a > > non-requirement. Is the intention to say that the WG will not be > > 'defining' DSR coding schemes? > > > Yes. In addition we won't even discuss them or do any > investigation/evaluation of various DSR schemes. They're just anohter codec > to us :-) > > [fin] > Dave. > ------------------------ > David R. Oran > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc --------------F842077DC5616B196D38BFB0 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Sarvi tel;work:408-527-4875 x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Group adr:;;;;;; version:2.1 email;internet:sarvi@cisco.com title:Technical Leader fn:Sarvi Shanmugham end:vcard --------------F842077DC5616B196D38BFB0-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 14:18:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03062 for ; Fri, 20 Sep 2002 14:18:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KIJXv15408 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 14:19:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KIJXv15405 for ; Fri, 20 Sep 2002 14:19:33 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03010 for ; Fri, 20 Sep 2002 14:17:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KIJ1v15386; Fri, 20 Sep 2002 14:19:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KII7v15355 for ; Fri, 20 Sep 2002 14:18:07 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02960; Fri, 20 Sep 2002 14:16:12 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8KIHvhN049324; Fri, 20 Sep 2002 14:17:57 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8KIHpo60658; Fri, 20 Sep 2002 14:17:51 -0400 (EDT) Received: from research.bell-labs.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id OAA2439351; Fri, 20 Sep 2002 14:17:50 -0400 (EDT) Message-ID: <3D8B664E.F098DB38@research.bell-labs.com> Date: Fri, 20 Sep 2002 14:17:50 -0400 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: Jeff Kusnitz CC: "David R. Oran" , Eric Burger , Hsiao-Wuen Hon , Salvador Neto , speechsc@ietf.org, speechsc-admin@ietf.org, Stephen Potter Subject: Re: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Although Speaker Recognition has been used widely in academic world to refer both speaker identification (SI) and speaker verification (SV), In engineering or productization world, they have the following differences that need attention to define a protocol/interface to support them both: 1. SV is to authenticate a claimed user identity that is known to the system by the user registration. Basically, it is one user voiceprint matches to one pre stored voiceprint algorithm. Therefore, the search space of SV is quite limited and fast to process (less CPU cycles, small data footprint). This is similar to a text based (password, secure token) authentication system. But a practical system may need to process large amount of SV requests at one time. On the other hand, since SV is mostly used in security access applications, Security considerations on voiceprint storage and transport, authentication certification passing are required for a protocol to support it. 2. SI is to find the user identity via her/his voice samples in a community of users. The search space is larger compare to SV, unless you only want to identify a user from a group of few (which may not be a distributed system case). I don't have a good use case on this in my mind. I'd like to hear one if anyone have a story. One thing that I can think is to use SI to identify a user for a desktop computer. Another useful technology is called language identification that is speaker independent and doesn't need user enroll to the system. I don't think it will be big problem to put both SI and SV in Speaker Recognition category. But SR is a confusing acronym, as Jeff said. -- Qiru Jeff Kusnitz wrote: > > With respect to SR vs SIV, as the industry understands that Speaker Recognition means speaker identification and > verification, I don't see the motivation to coin a new phrase for it. The fact that it's acronym is misleading is a > separate issue (which I tend to agree with). > > Jeff > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Sep 20 15:48:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05961 for ; Fri, 20 Sep 2002 15:48:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KJndb19955 for speechsc-archive@odin.ietf.org; Fri, 20 Sep 2002 15:49:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KJndv19952 for ; Fri, 20 Sep 2002 15:49:39 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05943 for ; Fri, 20 Sep 2002 15:47:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KJn4v19940; Fri, 20 Sep 2002 15:49:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KJmnv19921 for ; Fri, 20 Sep 2002 15:48:49 -0400 Received: from ahuumrelay2.ams.ops.eu.uu.net (ahuumrelay2.ams.ops.eu.uu.net [195.129.70.155]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05936 for ; Fri, 20 Sep 2002 15:46:54 -0400 (EDT) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay2.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id g8KJlsf13933; Fri, 20 Sep 2002 19:47:54 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 6AA213B6BE; Fri, 20 Sep 2002 15:47:08 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'David R. Oran'" , "'Salvador Neto'" , "'Eric Burger'" , Cc: "'Hsiao-Wuen Hon'" , "'Stephen Potter'" Subject: RE: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt Date: Fri, 20 Sep 2002 21:43:20 +0200 Message-ID: <01b401c260de$7c8a2670$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <155109385.1032520994@ORANLT.cisco.com> Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit my 2c? worth (don't know if that's worth more or less that 2c$) below. [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > > Section 3 (and throughout) > > 1. The requirements document is clearly focused on telephony gateway > > scenarios. We suggest that an equally compelling scenario is mobile > > multimodal scenarios where wireless mobile devices can > attain ASR/SR/TTS > > services via network. If the group agrees that this is an important > > scenario to address, we would suggest modification or > addition of the > > requirements to reflect this. > I, for one agree, and suspect the Wg would not have any > problem with this. Can we explicit any exact requirements that flow from including such a scenario? (apart from the RTP discussion..) > > Specifically, we are concerned that saying > > SpeechSC depends on RTP may mean that it depends on UDP. [snip] > We could conceivably just write requirements that any media carriage > protocol have certain characteristics, but I would be > inclined to retain > the RTP dependency for the reasons cited above. IMHO we should stick only with RTP - given it can be carried over TCP, and can contain any payload you like via SDP definitions/rtpmap. I think we would need to see a specific case where a speechsc scenario didn't work to change this. We could add a note that RTP/UDP is suited for RT type use, and RTP/TCP for store-n-play type use scenarios? > > 2. The term 'speaker recognition' and its acronym SR are rather > > confusing, given the widespread use of SR to mean 'speech > recognition' > > (i.e. ASR), and the use of the word 'recognition' in both > concepts. We > > understand the meaning of the term to embrace both 'speaker > > verification' and 'speaker identification'. We would > therefore suggest a > > different phrase for these capabilities: Speaker > > Identification/Verification (SIV). > > > I like this suggestion (despite my proposing a different > acronym in my note > responding to anohter set of comments). If there are no > objections, I will > adopt this acronym in the next revision of the draft. Hmmm. Given points raised by others, I'd be more inclined to say SI/SV (to reinforce the point that its two potential different functions (and hence one may have an SI-only or SV-only server), but that may be considered to have simiar requirements. [snip] > On a more philosophical note, these requirements are meant > primarily to be > consumed by the people undertaking the analysys of existing > protocols, and > as a measure against which to evaluate any protocol the WG > proposes to the > IETF for adoption as a standard. As WG chair I would expect > and indeed > demand that at least those folks in fact read and absorb the > OPES documents > since they are relevant to the design of a SPEECHSC protocol > and point out > many pits others have fallen into. Agreed. One can't include all other related docs, but one can't ignore them either - if you don't want to run off and read related documentation maybe you're not up to speed enough to make a comment (a QUESTION, yes, to which the ANSWER might be a pointer to the relevant part of the relevant spec....) [snip] > > Section 5.6 > > 6. The MUST requirement to permit multiple operations on a > single stream > > may significantly affect SpeechSC design, but we do not believe the > > scenarios which are enabled by this are sufficiently > compelling to make > > it a must-have. So we suggest this requirement should be a SHOULD. > > > In earlier list discussion and at the Yokohmam IETF meeting, > the consensus > was this is a MUST requirement. Let's revisit this given we > have a counter > view. MUST for me... [snip] > > 11. (para 6) The loose definitions in this paragraph render > it hard to > > understand. We do not understand what is actually intended > by the SHOULD > > and MAY capabilities here. > > > Ouch. You'll have to help me figure out what is wrong, since > it's crystal > clear to me (I know this isn't too helpful). What we are > trying to say is > that it is pretty important (SHOULD) that the protocol be > able to keep its > control channel, and hence its basic control synchronization > state, over > longer than one session (where session is loosely corellated > with a "call", > SIP dialog, or session state of the associated voice > application). We then > say that it would be perfectly OK but not required (MAY) if > the protocol > was capable of a complete {setup/do work/shut down} cycle on > shorter scale, > down to a single interaction for one utterance. I think I already proposed clarification text (although given the resulting questions it maybe wasn't as clear as I thought...:-() > > 12. (para 7) Again, point 10 on the TTS Server requirements. We also > > believe that such capabilities are not MUSTs in either > case, but rather > > SHOULD for the framework (and correspondingly MAY for Server > > conformance). > > > The WG consensus was otherwise, but now you are the second > set of folks > commenting that we ought to water this down to SHOULD. I am > personally > inclined to keep this as a MUST, since adding this to the > protocol later if > not accommodated in the design up front could be very difficult. On > apractical basis, a number of the candidate protocols (MRCP, > RTSP) already > do this, so meeting the MUST may not in practice be all that > difficult. Keep it MUST. Also, generally speaking I'd avoid having too many SHOULDs/MAYs on such protocol design points as this is a great way to avoid interoperability if you get my point.... [snip] > > 15. (para 5) The requirement to accommodate "all of the protocol > > parameters" of MRCP needs to be justified. We believe it is > too strong, > > since it assumes that MRCP is an exact fit to SpeechSC, whereas we > > believe MRCP may be over-specialized for use in VoiceXML > environments. > Au contraire. If MRCP met the requirements we likely would > not even be > having this WG or this discussion; we would be having an MRCP > WG or just > asking the IESG to bless MRCP as a proposed standard. > > To address the substance of your comment, there was WG > consensus that none > of the parameters in MRCP could be eliminated without losing some > functionality that was deemed essential. This is not to say > that the set in > MRCP is complete by any means. We know it's not. It would be > helpful if you > could enumerate that parameters in MRCP that you do not believe are > essential, keeping in mind that we want the speechsc protocol > to have wide > applicability which *includes* but is *not limited to* VoiceXML > environments. Agree can't eliminate any of the parameters, rather IMHO the protocol needs to ensure a flexible and extensible way to add parameters in the future (cause we'll never anticipate them all). This could simply be like the rtsp/http/mrcp headers system (where you can add them as you want and the server ignores those it doesn't understand)..... In the speechsc protocol there should be a common basic set that all servers MUST understand.... [snip] [fin] _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 24 12:32:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04819 for ; Tue, 24 Sep 2002 12:32:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8OGXud12807 for speechsc-archive@odin.ietf.org; Tue, 24 Sep 2002 12:33:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OGXuv12804 for ; Tue, 24 Sep 2002 12:33:56 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04794 for ; Tue, 24 Sep 2002 12:32:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OGXLv12760; Tue, 24 Sep 2002 12:33:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OGSDv12502 for ; Tue, 24 Sep 2002 12:28:13 -0400 Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04567 for ; Tue, 24 Sep 2002 12:26:18 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g8OGS3S29774; Tue, 24 Sep 2002 12:28:04 -0400 (EDT) Reply-To: From: "Eric Burger" To: Cc: Subject: RE: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt Date: Tue, 24 Sep 2002 12:28:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D8B664E.F098DB38@research.bell-labs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I can easily see a difference in operation between Speaker Identification and Speaker Verification. However, my question to the speech community is, "Is there a protocol difference?" For example: 1. For Speaker Identification, the client needs to specify an individual speaker template. For Speaker Verification, the client needs to specify an individual speaker template. ==> They look the same to the protocol. 2. For Speaker Identification, the client needs to specify an individual speaker template. For Speaker Verification, the client needs to specify a set of potential individuals. ==> They could look the same to the protocol. 3. For Speaker Identification, the client needs to specify an individual speaker template. For Speaker Verification, the client needs to specify a set of groups, as well as indicate specifically that this is a Verification, not Identification, operation. ==> They are probably different operations. So, for the speech community: which one is it, really? > -----Original Message----- > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > Sent: Friday, September 20, 2002 2:18 PM > To: Jeff Kusnitz > Cc: David R. Oran; Eric Burger; Hsiao-Wuen Hon; Salvador Neto; > speechsc@ietf.org; speechsc-admin@ietf.org; Stephen Potter > Subject: Re: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt > > > Although Speaker Recognition has been used widely in academic world to > refer both speaker identification (SI) and speaker verification (SV), > In engineering or productization world, they have the following > differences > that need attention to define a protocol/interface to support them both: > > 1. SV is to authenticate a claimed user identity that is known to > the system > by the user registration. Basically, it is one user voiceprint > matches to one > pre stored voiceprint algorithm. Therefore, the search space of > SV is quite > limited and fast to process (less CPU cycles, small data > footprint). This is > similar to a text based (password, secure token) authentication > system. But > a practical system may need to process large amount of SV requests at one > time. > > On the other hand, since SV is mostly used in security access > applications, > Security considerations on voiceprint storage and transport, > authentication > certification passing are required for a protocol to support it. > > 2. SI is to find the user identity via her/his voice samples in a > community > of users. The search space is larger compare to SV, unless you > only want to > identify a user from a group of few (which may not be a distributed system > case). I don't have a good use case on this in my mind. I'd like to hear > one if anyone have a story. One thing that I can think is to use SI to > identify a user for a desktop computer. > > Another useful technology is called language identification that > is speaker > independent and doesn't need user enroll to the system. > > I don't think it will be big problem to put both SI and SV in Speaker > Recognition category. But SR is a confusing acronym, as Jeff said. > > -- Qiru > > > > Jeff Kusnitz wrote: > > > > With respect to SR vs SIV, as the industry understands that > Speaker Recognition means speaker identification and > > verification, I don't see the motivation to coin a new phrase > for it. The fact that it's acronym is misleading is a > > separate issue (which I tend to agree with). > > > > Jeff > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 24 14:37:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08512 for ; Tue, 24 Sep 2002 14:37:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8OIcjv19692 for speechsc-archive@odin.ietf.org; Tue, 24 Sep 2002 14:38:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OIcjv19689 for ; Tue, 24 Sep 2002 14:38:45 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08487 for ; Tue, 24 Sep 2002 14:36:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OIcAv19663; Tue, 24 Sep 2002 14:38:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OIbQv19644 for ; Tue, 24 Sep 2002 14:37:26 -0400 Received: from speechworks.com (valmiki.speechworks.com [63.113.17.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08421 for ; Tue, 24 Sep 2002 14:35:31 -0400 (EDT) Received: from vishnu.speechworks.com (mailhost.speechworks.com [206.234.64.17]) by speechworks.com (8.10.2+Sun/8.9.3) with ESMTP id g8OIgYF05898; Tue, 24 Sep 2002 14:42:34 -0400 (EDT) Received: from whitney (localhost [127.0.0.1]) by vishnu.speechworks.com (8.10.2+Sun/8.9.3) with SMTP id g8OIbJP05911; Tue, 24 Sep 2002 14:37:19 -0400 (EDT) From: "Brian Eberman" To: , Cc: Subject: RE: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt Date: Tue, 24 Sep 2002 14:37:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think speaker identification and verification can be done with exactly the same protocol. The operations are: 1) add the next utterance you see to the enrollment list to update the model 2) get the model so it can be centrally stored (maybe this isn't supported) 3) verify or identify an utterance against a set of speaker models. Frankly except for #2 verification and identification look a lot like speech recognition. -Brian -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Eric Burger Sent: Tuesday, September 24, 2002 12:28 PM To: qzhou@research.bell-labs.com Cc: speechsc@ietf.org Subject: RE: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt I can easily see a difference in operation between Speaker Identification and Speaker Verification. However, my question to the speech community is, "Is there a protocol difference?" For example: 1. For Speaker Identification, the client needs to specify an individual speaker template. For Speaker Verification, the client needs to specify an individual speaker template. ==> They look the same to the protocol. 2. For Speaker Identification, the client needs to specify an individual speaker template. For Speaker Verification, the client needs to specify a set of potential individuals. ==> They could look the same to the protocol. 3. For Speaker Identification, the client needs to specify an individual speaker template. For Speaker Verification, the client needs to specify a set of groups, as well as indicate specifically that this is a Verification, not Identification, operation. ==> They are probably different operations. So, for the speech community: which one is it, really? > -----Original Message----- > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > Sent: Friday, September 20, 2002 2:18 PM > To: Jeff Kusnitz > Cc: David R. Oran; Eric Burger; Hsiao-Wuen Hon; Salvador Neto; > speechsc@ietf.org; speechsc-admin@ietf.org; Stephen Potter > Subject: Re: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt > > > Although Speaker Recognition has been used widely in academic world to > refer both speaker identification (SI) and speaker verification (SV), > In engineering or productization world, they have the following > differences > that need attention to define a protocol/interface to support them both: > > 1. SV is to authenticate a claimed user identity that is known to > the system > by the user registration. Basically, it is one user voiceprint > matches to one > pre stored voiceprint algorithm. Therefore, the search space of > SV is quite > limited and fast to process (less CPU cycles, small data > footprint). This is > similar to a text based (password, secure token) authentication > system. But > a practical system may need to process large amount of SV requests at one > time. > > On the other hand, since SV is mostly used in security access > applications, > Security considerations on voiceprint storage and transport, > authentication > certification passing are required for a protocol to support it. > > 2. SI is to find the user identity via her/his voice samples in a > community > of users. The search space is larger compare to SV, unless you > only want to > identify a user from a group of few (which may not be a distributed system > case). I don't have a good use case on this in my mind. I'd like to hear > one if anyone have a story. One thing that I can think is to use SI to > identify a user for a desktop computer. > > Another useful technology is called language identification that > is speaker > independent and doesn't need user enroll to the system. > > I don't think it will be big problem to put both SI and SV in Speaker > Recognition category. But SR is a confusing acronym, as Jeff said. > > -- Qiru > > > > Jeff Kusnitz wrote: > > > > With respect to SR vs SIV, as the industry understands that > Speaker Recognition means speaker identification and > > verification, I don't see the motivation to coin a new phrase > for it. The fact that it's acronym is misleading is a > > separate issue (which I tend to agree with). > > > > Jeff > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 24 15:02:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09171 for ; Tue, 24 Sep 2002 15:02:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8OJ3aF20556 for speechsc-archive@odin.ietf.org; Tue, 24 Sep 2002 15:03:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OJ3av20553 for ; Tue, 24 Sep 2002 15:03:36 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09164 for ; Tue, 24 Sep 2002 15:01:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OJ33v20538; Tue, 24 Sep 2002 15:03:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OJ2Xv20510 for ; Tue, 24 Sep 2002 15:02:33 -0400 Received: from server1.omnistarinc.com (omnistarinc.com [209.61.189.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09133 for ; Tue, 24 Sep 2002 15:00:38 -0400 (EDT) Received: from xcelcorp.com (ool-43509cba.dyn.optonline.net [67.80.156.186]) (authenticated) by server1.omnistarinc.com (8.11.6/8.11.6) with ESMTP id g8OJ2KQ04787; Tue, 24 Sep 2002 15:02:20 -0400 Message-ID: <3D90E195.512A90E0@xcelcorp.com> Date: Tue, 24 Sep 2002 15:05:09 -0700 From: Jiten Organization: XCEL Solutions Corp X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: eburger@snowshore.com CC: brian.wyld@eloquant.com, "Speechsc (E-mail)" Subject: Re: [Speechsc] Updated list of contributors References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hmm... I don't see much activity on this topic. I was on vacation last week. Need to catch up with my mails. Rajiv, BrainM: Where do we stand for our RTSP and SIP responsibility. Please update me. I am thinking we can break down the activity into 4 segments for each protocol and each of us can take 2 items. I will write to u in detail. -Jiten Eric Burger wrote: > The timing is exactly correct. Having a draft out by the end of September > gives us 3 weeks of list discussion and 1 week for revision. The key point > is to have the document available for discussion in Atlanta. > > Also note that we cannot update a new -00 document to -01 after 10/27. > > -- > Signed, > "Brian" Burger :-) > > > -----Original Message----- > > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf > > Of Brian Wyld > > Sent: Tuesday, September 17, 2002 4:06 PM > > To: Speechsc (E-mail) > > Subject: [Speechsc] Updated list of contributors > > > > > > Hi, > > > > Updated list: > > > > RTSP : Jiten Goel, Rajiv Dharmadhikari > > SIP : Brian Marquette, Jiten Goel > > Web Services : Stephane Maes > > MRCP draft : Sarvi Shanmugham > > BEEP : Brian Eberman > > > > Cutoff date for the draft is apparently 10/27. I suggest we try to have > > first draft sections for review sent to the list by end Sept, to allow for > > comments/re-work and then integration into a whole. > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc -- /Jiten XCEL Solutions Corp ...Leading the Future _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Sep 24 16:57:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12367 for ; Tue, 24 Sep 2002 16:57:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8OKwdf26733 for speechsc-archive@odin.ietf.org; Tue, 24 Sep 2002 16:58:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OKwdv26730 for ; Tue, 24 Sep 2002 16:58:39 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12354 for ; Tue, 24 Sep 2002 16:56:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OKw4v26716; Tue, 24 Sep 2002 16:58:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OKvtv26689 for ; Tue, 24 Sep 2002 16:57:55 -0400 Received: from navgw.sandcherry.com (navgw.sandcherry.com [63.117.80.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12332 for ; Tue, 24 Sep 2002 16:55:58 -0400 (EDT) Received: from con-63-117-80-25.rocky.net ([10.20.1.32]) by navgw.sandcherry.com (NAVGW 2.5.2.12) with SMTP id M2002092415131829037 ; Tue, 24 Sep 2002 15:13:18 -0600 Received: by exchange01.sccorp.com with Internet Mail Service (5.5.2656.59) id ; Tue, 24 Sep 2002 14:51:35 -0600 Message-ID: From: Brian Marquette To: "'Jiten'" , eburger@snowshore.com Cc: brian.wyld@eloquant.com, "Speechsc (E-mail)" Subject: RE: [Speechsc] Updated list of contributors Date: Tue, 24 Sep 2002 14:51:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Jiten, I haven't had a chance to make much progress the last week. So the best approach is to segment the work as you noted. I should have time later this week to complete it. Rajiv, how does your week look? brian -----Original Message----- From: Jiten [mailto:jiten@xcelcorp.com] Sent: Tuesday, September 24, 2002 4:05 PM To: eburger@snowshore.com Cc: brian.wyld@eloquant.com; Speechsc (E-mail) Subject: Re: [Speechsc] Updated list of contributors Hmm... I don't see much activity on this topic. I was on vacation last week. Need to catch up with my mails. Rajiv, BrainM: Where do we stand for our RTSP and SIP responsibility. Please update me. I am thinking we can break down the activity into 4 segments for each protocol and each of us can take 2 items. I will write to u in detail. -Jiten Eric Burger wrote: > The timing is exactly correct. Having a draft out by the end of > September gives us 3 weeks of list discussion and 1 week for revision. > The key point is to have the document available for discussion in > Atlanta. > > Also note that we cannot update a new -00 document to -01 after 10/27. > > -- > Signed, > "Brian" Burger :-) > > > -----Original Message----- > > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On > > Behalf Of Brian Wyld > > Sent: Tuesday, September 17, 2002 4:06 PM > > To: Speechsc (E-mail) > > Subject: [Speechsc] Updated list of contributors > > > > > > Hi, > > > > Updated list: > > > > RTSP : Jiten Goel, Rajiv Dharmadhikari > > SIP : Brian Marquette, Jiten Goel > > Web Services : Stephane Maes > > MRCP draft : Sarvi Shanmugham > > BEEP : Brian Eberman > > > > Cutoff date for the draft is apparently 10/27. I suggest we try to > > have first draft sections for review sent to the list by end Sept, > > to allow for comments/re-work and then integration into a whole. > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc -- /Jiten XCEL Solutions Corp ...Leading the Future _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Sep 25 13:08:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03054 for ; Wed, 25 Sep 2002 13:08:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8PH9lt01336 for speechsc-archive@odin.ietf.org; Wed, 25 Sep 2002 13:09:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PH9kv01332 for ; Wed, 25 Sep 2002 13:09:46 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03025 for ; Wed, 25 Sep 2002 13:07:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PH9Cv01314; Wed, 25 Sep 2002 13:09:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PH8uv01286 for ; Wed, 25 Sep 2002 13:08:56 -0400 Received: from speechworks.com (valmiki.speechworks.com [63.113.17.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02997 for ; Wed, 25 Sep 2002 13:06:59 -0400 (EDT) Received: from vishnu.speechworks.com (mailhost.speechworks.com [206.234.64.17]) by speechworks.com (8.10.2+Sun/8.9.3) with ESMTP id g8PHE2F01875; Wed, 25 Sep 2002 13:14:02 -0400 (EDT) Received: from whitney (localhost [127.0.0.1]) by vishnu.speechworks.com (8.10.2+Sun/8.9.3) with SMTP id g8PH8km20681; Wed, 25 Sep 2002 13:08:46 -0400 (EDT) From: "Brian Eberman" To: "Brian Marquette" , "'Jiten'" , Cc: , "Speechsc \(E-mail\)" Subject: RE: [Speechsc] Updated list of contributors Date: Wed, 25 Sep 2002 13:08:46 -0400 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SWI won't be able to make progress until W3C meeting is over so next week we can make progress. -Brian -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Brian Marquette Sent: Tuesday, September 24, 2002 4:52 PM To: 'Jiten'; eburger@snowshore.com Cc: brian.wyld@eloquant.com; Speechsc (E-mail) Subject: RE: [Speechsc] Updated list of contributors Jiten, I haven't had a chance to make much progress the last week. So the best approach is to segment the work as you noted. I should have time later this week to complete it. Rajiv, how does your week look? brian -----Original Message----- From: Jiten [mailto:jiten@xcelcorp.com] Sent: Tuesday, September 24, 2002 4:05 PM To: eburger@snowshore.com Cc: brian.wyld@eloquant.com; Speechsc (E-mail) Subject: Re: [Speechsc] Updated list of contributors Hmm... I don't see much activity on this topic. I was on vacation last week. Need to catch up with my mails. Rajiv, BrainM: Where do we stand for our RTSP and SIP responsibility. Please update me. I am thinking we can break down the activity into 4 segments for each protocol and each of us can take 2 items. I will write to u in detail. -Jiten Eric Burger wrote: > The timing is exactly correct. Having a draft out by the end of > September gives us 3 weeks of list discussion and 1 week for revision. > The key point is to have the document available for discussion in > Atlanta. > > Also note that we cannot update a new -00 document to -01 after 10/27. > > -- > Signed, > "Brian" Burger :-) > > > -----Original Message----- > > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On > > Behalf Of Brian Wyld > > Sent: Tuesday, September 17, 2002 4:06 PM > > To: Speechsc (E-mail) > > Subject: [Speechsc] Updated list of contributors > > > > > > Hi, > > > > Updated list: > > > > RTSP : Jiten Goel, Rajiv Dharmadhikari > > SIP : Brian Marquette, Jiten Goel > > Web Services : Stephane Maes > > MRCP draft : Sarvi Shanmugham > > BEEP : Brian Eberman > > > > Cutoff date for the draft is apparently 10/27. I suggest we try to > > have first draft sections for review sent to the list by end Sept, > > to allow for comments/re-work and then integration into a whole. > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc -- /Jiten XCEL Solutions Corp ...Leading the Future _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sat Sep 28 05:01:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01268 for ; Sat, 28 Sep 2002 05:01:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8S92em19577 for speechsc-archive@odin.ietf.org; Sat, 28 Sep 2002 05:02:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8S92ev19574 for ; Sat, 28 Sep 2002 05:02:40 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01253 for ; Sat, 28 Sep 2002 05:00:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8S925v19559; Sat, 28 Sep 2002 05:02:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8S90cv19497 for ; Sat, 28 Sep 2002 05:00:38 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01220 for ; Sat, 28 Sep 2002 04:58:44 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8S90TLI021876; Sat, 28 Sep 2002 05:00:29 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8S90NI11875; Sat, 28 Sep 2002 05:00:23 -0400 (EDT) Received: from research.bell-labs.com ([135.104.20.74]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id FAA2673206; Sat, 28 Sep 2002 05:00:22 -0400 (EDT) Message-ID: <3D956F88.5D3A5CE8@research.bell-labs.com> Date: Sat, 28 Sep 2002 04:59:52 -0400 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh,zh-CN,zh-TW MIME-Version: 1.0 To: eburger@snowshore.com CC: speechsc@ietf.org Subject: Re: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It should be: For Speaker Verification, the client needs to specify an individual speaker template. For Speaker Identification, the client needs to specify a set of potential individuals (may plus other audio source identities), as well as indicate specifically that this is an Identification, not Verification, operation. ==> They are probably different operations. Based on what we defined in our research. Let me give use cases for SV and SI here: 1. Speaker verification: This is a two session process in most common SV usage: Enrollment: The SV application collects certain amount of speaker's voice samples (explicitly or implicitly) to build speaker template (or voice print. In Bell Labs technology, we build speaker dependent HMMs). In implicit case, multiple enrollment sessions may needed to collect enough samples to build the templates in good quality. Also you need to provide a user override mechanism if retrain the template is needed. Verification: The SV application collects a utterance sample from the speaker, and compare to the template that in the profile of the speaker claimed identity to see if it is the right match. This process require the server load the template of the claimed speaker from storage (database, etc.). And a compare template (in most of the HMM cases, we call it cohort model) is needed to perform a likelihood ratio test (in the scope of decision theory.) In general, SV may apply to large number of speakers. A voice print database interface abstraction (in BioAPI case, BioAPI DB section.) is required. Also a large number of SV applications use fixed phrases (per speaker) or digit strings for verification utterance. Please refer to BioAPI Consortium (http://www.bioapi.org) BioAPI 1.1 (ANSI/INCITS 358 standard) on this model. I believe it is a good API and model (Dave, this is the reference you want: "BioAPI Specification 1.1, The BioAPI Consortium, March 16, 2001".) 2. Speaker Identification: I have hard time to find a SI service application use case since its complexity to deal with large number of speakers. One of the commonly use case in research is speaker identification in audio indexing, where the speech signal is a multi speaker, spontaneous conversation scenario. The voice samples for building speaker templates and samples for SI are text independent in most of the cases. The LDC TSID database description (http://www.ldc.upenn.edu/Catalog/LDC99S83.html) gives a simple and good example on how to perform a SI experiment. There is no explicit user enrollments in this use case. In another SI use case, an application can use the same explicit enrollment process as SV to build N user's template. Then once a speaker in this N user group talk to the app, the app may prompt the speaker for a fixed pass phrase to compare all N template to see which is the best match. This case is a specific N-classification problem. Which is easy to cover by a SV protocol, with a different decision logic (could be outside the the speech server protocol). From protocol or API concerned, I consider both SV and SI be add-ons to base ASR(or SR) protocol/API. Since both of them can be presented as special cases of ASR, with extra decision logic. If we only care of the second SI use case, the same protocol with a minor extension can cover both. -- Qiru Eric Burger wrote: > > I can easily see a difference in operation between Speaker Identification > and Speaker Verification. However, my question to the speech community is, > "Is there a protocol difference?" > > For example: > > 1. For Speaker Identification, the client needs to specify an individual > speaker template. For Speaker Verification, the client needs to specify an > individual speaker template. > ==> They look the same to the protocol. > > 2. For Speaker Identification, the client needs to specify an individual > speaker template. For Speaker Verification, the client needs to specify a > set of potential individuals. > ==> They could look the same to the protocol. > > 3. For Speaker Identification, the client needs to specify an individual > speaker template. For Speaker Verification, the client needs to specify a > set of groups, as well as indicate specifically that this is a Verification, > not Identification, operation. > ==> They are probably different operations. > > So, for the speech community: which one is it, really? > > > -----Original Message----- > > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > > Sent: Friday, September 20, 2002 2:18 PM > > To: Jeff Kusnitz > > Cc: David R. Oran; Eric Burger; Hsiao-Wuen Hon; Salvador Neto; > > speechsc@ietf.org; speechsc-admin@ietf.org; Stephen Potter > > Subject: Re: [Speechsc] Re: Comments on draft-ietf-speechsc-reqts-00.txt > > > > > > Although Speaker Recognition has been used widely in academic world to > > refer both speaker identification (SI) and speaker verification (SV), > > In engineering or productization world, they have the following > > differences > > that need attention to define a protocol/interface to support them both: > > > > 1. SV is to authenticate a claimed user identity that is known to > > the system > > by the user registration. Basically, it is one user voiceprint > > matches to one > > pre stored voiceprint algorithm. Therefore, the search space of > > SV is quite > > limited and fast to process (less CPU cycles, small data > > footprint). This is > > similar to a text based (password, secure token) authentication > > system. But > > a practical system may need to process large amount of SV requests at one > > time. > > > > On the other hand, since SV is mostly used in security access > > applications, > > Security considerations on voiceprint storage and transport, > > authentication > > certification passing are required for a protocol to support it. > > > > 2. SI is to find the user identity via her/his voice samples in a > > community > > of users. The search space is larger compare to SV, unless you > > only want to > > identify a user from a group of few (which may not be a distributed system > > case). I don't have a good use case on this in my mind. I'd like to hear > > one if anyone have a story. One thing that I can think is to use SI to > > identify a user for a desktop computer. > > > > Another useful technology is called language identification that > > is speaker > > independent and doesn't need user enroll to the system. > > > > I don't think it will be big problem to put both SI and SV in Speaker > > Recognition category. But SR is a confusing acronym, as Jeff said. > > > > -- Qiru > > > > > > > > Jeff Kusnitz wrote: > > > > > > With respect to SR vs SIV, as the industry understands that > > Speaker Recognition means speaker identification and > > > verification, I don't see the motivation to coin a new phrase > > for it. The fact that it's acronym is misleading is a > > > separate issue (which I tend to agree with). > > > > > > Jeff > > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc