Subject: [Speechsc] Administrative Fiat

From: "Eric Burger" <[email-masked]>
Date: Thu, 24 Apr 2003 11:02:47 -0400

Date: 1 April 2003
[everything associated with speechsc seems to go out late]

Since there has been no progress on the protocol analysis document, I have made the following decisions:

1. We need a new protocol.

2. Since no one seems to care, the protocol will be based on BEEP and CORBA.

3. To ensure that people use the protocol, we will publish an ADA binding.

Unless I hear otherwise, this is the direction we will go.

--
- Eric

P.S.  If I don't hear otherwise, we can consider the work of the work group complete.

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Brian Wyld" <[email-masked]>
Date: Fri, 25 Apr 2003 10:46:07 +0200

Eric,

Sounds good to me...... although I believe there is still a significant base
of COBOL applications that may be critical to address.......

Or, I contra-propose:
1. the protocol will be RTSP extended to include the current MRCP messages
'natively', with addition of specific  messages for SR/SI, and to define the
'call session' mapping to the MRCP requests.

2. there will be a web services binding....

(sorry to be serious here)

Brian

[Brian Wyld] [[email-masked]]
[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 : [email-masked]
> [mailto:[email-masked]]De la part
> de Eric Burger
> Envoyé : Thursday, April 24, 2003 17:03
> À : IETF SPEECHSC (E-mail)
> Objet : [Speechsc] Administrative Fiat
>
>
> Date: 1 April 2003
> Since there has been no progress on the protocol analysis
> document, I have made the following decisions:
>

---

From: "Brian Eberman" <[email-masked]>
Date: Fri, 25 Apr 2003 06:43:58 -0400

Even simpler why not just fold the required SETUP/TEARDOWN and DESCRIBE
mechanism into MRCP and make it a first class protocol. Then move on to
figuring out how to do RECORD with recognition and speaker verification.

-Brian Eberman
Director Product Management and Services
SpeechWorks International
695 Atlantic Avenue
Boston, MA 02111
617 428 4444

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Brian Wyld
Sent: Friday, April 25, 2003 4:46 AM
To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)'
Subject: RE: [Speechsc] Administrative Fiat

Eric,

Or, I contra-propose:

Brian

---

From: "Brian Wyld" <[email-masked]>
Date: Fri, 25 Apr 2003 14:34:40 +0200

Sure, but then you blew the "reuse existing protocols, don't reinvent the
wheel" requirement....

Brian

PS> Shouldn't that be "Scansoft" in your footer....?

> De : Brian Eberman [mailto:[email-masked]]
> Envoyé : Friday, April 25, 2003 12:44
> À : [email-masked]; 'Eric Burger'; 'IETF SPEECHSC (E-mail)'
> Objet : RE: [Speechsc] Administrative Fiat
>
>
> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of Brian Wyld

---

From: "Brian Eberman" <[email-masked]>
Date: Fri, 25 Apr 2003 09:11:17 -0400

Yes I know I blew the don't reinvent the wheel requirement, but if the wheel
is the wrong size then it needs a new wheel.

Fitting it into RTSP would mean fitting TTS in to Play, and then adding lots
of messages for recognition, adding messages for verification, etc. Is it
really RTSP anymore?  What value does RTSP bring to the combination. Reading
the analysis it doesn't seem like very much and then there would be
confusion of what RTSP methods are supported by a recognizer/ TTS RTSP
server.

I think the same problem exists for SIP.

If we break this one requirement then we can deal with the major issues:
1) verification
2) recognition with recording
3) load-balancing
4) resource registration

-Brian

-----Original Message-----
From: Brian Wyld [mailto:[email-masked]]
Sent: Friday, April 25, 2003 8:35 AM
To: 'Brian Eberman'; 'Eric Burger'; 'IETF SPEECHSC (E-mail)'
Subject: RE: [Speechsc] Administrative Fiat

Brian