Subject: RE: [Speechsc] Protocol Analysis Document

From: "Stephen Potter" <[email-masked]>
Date: Sat, 19 Oct 2002 02:11:34 +0100

SRGS and SSML are not VoiceXML components. They may be used by VoiceXML
interpreters, but they are not part of VoiceXML per se. (SRGS and SSML
are also used by SALT interpreters, for example, along with XML result
formats such as NLSML).

I think this is an important point. The updated requirements document
(rightly) has a broad scope for a variety of speech service scenarios
and architectures, which go beyond VoiceXML and telephony. So it is in
this context that I think we should be considering the following
'payload' features in terms of all the major scenarios (e.g.
telephony/small-device/multimodal, VoiceXML/SALT/...):

- SRGS
- SSML
- recognition results
- all speech i/o events
- all speech service configuration properties

and ensure that we are targeting the right requirements and use cases. 

Please let me know if there is an action item I can help with here.

Stephen

> -----Original Message-----
> From: Qiru Zhou [mailto:[email-masked]] 
> Sent: Friday, October 18, 2002 5:28 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 'IETF SPEECHSC'
> Subject: Re: [Speechsc] Protocol Analysis Document
> 
> 
> Stephane,
> 
> Here VXML I referred are speech grammars, speech markup for TTS, and
> VXML properties that will change speech server behaviors. Apprently
> a speech server is a consumer of them. More precisely, they are some
> VoiceXML components (SRG, SSML, event returns, and VXML Properties)
> will interact with a speech server. Unless there is a translation
> layer to insulate entire VXML from a speech server. Which I'd like
> to avoid due to inefficiency.
> 
> I agree the VXML interpreter per se, it is a several layer high up.
> But the above components will be up/down from/to the server. If you
> have a different model in mind, please let me know.
> 
> -- Qiru 
> 
> "Stephane H. Maes" wrote:
> > 
> > Qiru,
> > 
> > A priori, I would expect that VXML is fundamentally at a 
> different level
> > (up to a few tags).
> > 
> > Stephane
> > 
> > _____
> > Stephane H. Maes, PhD,
> > Director of Architecture - Mobile, Oracle Corporation.
> > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948.
> > e-mail: [email-masked]
> > IM: shmaes (AIM) or [email-masked] (MSN Messenger)
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Qiru Zhou
> > 
> Sent: Friday, October 18, 2002 7:46 PM
> > To: [email-masked]
> > Cc: [email-masked]; 'IETF SPEECHSC'
> > Subject: Re: [Speechsc] Protocol Analysis Document
> > 
> > Brian,
> > 
> > I am wondering where the VoiceXML interface is covered in the list.
> > There was an obsoleted draft 
> "draft-rosenberg-sip-vxml-01.txt" related
> > VoiceXML to SIP. It was deleted from IETF site. I am 
> interested in this
> > since I am working with W3C VoiceXML WG as well.
> > 
> > -- Qiru
> > 
> > Brian Wyld wrote:
> > ?
> > ? Hi Qiru,
> > ?
> > ? Well, the assignation list was:
> > ? ? RTSP : Jiten Goel, Rajiv Dharmadhikari
> > ? ? SIP : Brian Marquette, Jiten Goel
> > ? ? Web Services : Stephane Maes
> > ? ? MRCP draft : Sarvi Shanmugham
> > ? ? BEEP : Brian Eberman
> > ?
> > ? Rajiv indicated he's still a 'go', but so far I haven't 
> had commitment
> > 
> > ? from the others.
> > ?
> > ? If you have a particular protocol in mind, let me know 
> and I'll ask
> > ? the current contributor to decide if they can do it or 
> not rapidly....
> > ?
> > ? thanks
> > ?
> > ? 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]
> > ?
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Stephane H. Maes" <[email-masked]>
Date: Fri, 18 Oct 2002 21:23:37 -0400

That is different from VXML on SIP etc... Carrying elements needed to
control and program engines that are part of the W3C Voice activity work
and used by VXML is of course the direction that we want to take. 

How we encapulate that (e.g. SRTP messages, versus SIP messages versus
Web service wrapper etc..) is what we have to determine and hence the
object of the present exercise.

Thanks

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephen Potter
Sent: Friday, October 18, 2002 9:12 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; IETF SPEECHSC
Subject: RE: [Speechsc] Protocol Analysis Document

- SRGS
- SSML
- recognition results
- all speech i/o events

Stephen

> VXML properties that will change speech server behaviors. Apprently a 
> speech server is a consumer of them. More precisely, they are some 
> layer to insulate entire VXML from a speech server. Which I'd like to 
> avoid due to inefficiency.
> 
> [email-masked] https://www1.ietf.org/mailman/listinfo/speechsc
> 
_______________________________________________
Speechsc mailing list
[email-masked] https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 21 Oct 2002 16:37:20 -0400

The requirements document definitely requires SSML for TTS.  SRGS makes
sense for ASR, too.

As Stephen points out, we said this to *support* VoiceXML, SALT, etc.
However, VoiceXML, SALT et. al. are things that *use* SpeechSC, not *are*
SpeechSC.

> From: Stephen Potter [mailto:[email-masked]]

---

From: Qiru Zhou <[email-masked]>
Date: Fri, 25 Oct 2002 12:01:51 -0400

This is what I mean in previous messages (sorry if I didn't spell out
clearly). The question is what level of VoiceXML or some other language
(for example, SALT) functional support that SPEECHSC will provide. I
never mean that SPEECHSC should *be*VXML. But I'd like to find out that
how many VXML required functions that SPEECHSC can support and what it can
not support. The reason I ask for VXML but not others is because it is emerging to be the application language of telco
applications.

-- Qiru

---

From: "Stephane H. Maes" <[email-masked]>
Date: Fri, 25 Oct 2002 14:26:04 -0400

Qiru,

Sorry I still do not understand this.

I would expect that a VoiceXML browser) or other would controle remote
engines though SPEECHSc and would not convey ANY VoiceXML syntax. It may
exchange data files and results in format also used by W3C.For
consistency, some of the SPEECHSC syntax may be similar to VoiceXML. But
that should be all. 

Isn't it?

Thanks

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: Qiru Zhou [mailto:[email-masked]] 
Sent: Friday, October 25, 2002 12:02 PM
To: [email-masked]
Cc: Stephen Potter; [email-masked]; [email-masked];
IETF SPEECHSC

This is what I mean in previous messages (sorry if I didn't spell out
clearly). The question is what level of VoiceXML or some other language
(for example, SALT) functional support that SPEECHSC will provide. I
never mean that SPEECHSC should *be*VXML. But I'd like to find out that
how many VXML required functions that SPEECHSC can support and what it
can not support. The reason I ask for VXML but not others is because it
is emerging to be the application language of telco applications.

-- Qiru

Eric Burger wrote:
> 
> The requirements document definitely requires SSML for TTS.  SRGS 
> makes sense for ASR, too.
> 
> However, VoiceXML, SALT et. al. are things that *use* SpeechSC, not 
> *are* SpeechSC.
> 
> > SRGS and SSML are not VoiceXML components. They may be used by 
> > VoiceXML interpreters, but they are not part of VoiceXML per se. 
> > (SRGS and SSML are also used by SALT interpreters, for example, 
> > along with XML result formats such as NLSML).
> >
> > > Here VXML I referred are speech grammars, speech markup for TTS, 
> > > and VXML properties that will change speech server behaviors. 
> > > Apprently a speech server is a consumer of them. More precisely, 
> > > they are some VoiceXML components (SRG, SSML, event returns, and 
> > > VXML Properties) will interact with a speech server. Unless there 
> > > is a translation layer to insulate entire VXML from a speech 
> > > server. Which I'd like to avoid due to inefficiency.
> > >
> > > I agree the VXML interpreter per se, it is a several layer high 
> > > up. But the above components will be up/down from/to the server. 
> > > If you have a different model in mind, please let me know.
> > >
> > > -- Qiru
> > >
> > > > I am wondering where the VoiceXML interface is covered in the 
> > > > list. There was an obsoleted draft