RE: [Dmsp] RE: DMSP vs EMMA

Chris Cross <xcross@us.ibm.com> Wed, 19 April 2006 14:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWDRv-0008Aa-3l; Wed, 19 Apr 2006 10:14:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWDRu-0008AR-4G for dmsp@ietf.org; Wed, 19 Apr 2006 10:14:30 -0400
Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWDRt-0005lX-Ij for dmsp@ietf.org; Wed, 19 Apr 2006 10:14:30 -0400
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k3JEESv5016518 for <dmsp@ietf.org>; Wed, 19 Apr 2006 10:14:28 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3JEHpxd164722 for <dmsp@ietf.org>; Wed, 19 Apr 2006 08:17:51 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k3JEERlP003512 for <dmsp@ietf.org>; Wed, 19 Apr 2006 08:14:27 -0600
Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k3JEERoJ003496; Wed, 19 Apr 2006 08:14:27 -0600
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702AE200B@ATLANTIS.Brooktrout.com>
Subject: RE: [Dmsp] RE: DMSP vs EMMA
To: "Burger, Eric" <EBurger@cantata.com>
X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005
Message-ID: <OF75E068A0.F58D5548-ON85257155.004CE91C-85257155.004E193E@us.ibm.com>
From: Chris Cross <xcross@us.ibm.com>
Date: Wed, 19 Apr 2006 10:13:02 -0400
X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 04/19/2006 08:17:42
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae
Cc: dmsp@ietf.org
X-BeenThere: dmsp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Distributed Multimodal Synchronization Protocol <dmsp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dmsp>, <mailto:dmsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dmsp>
List-Post: <mailto:dmsp@ietf.org>
List-Help: <mailto:dmsp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dmsp>, <mailto:dmsp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1294365165=="
Errors-To: dmsp-bounces@ietf.org





Eric,
I think the subject line of this thread is a red herring. DMSP is agnostic
on the format of interpretation. It may well be that EMMA is the default
that implementors choose. Table 9 shows RESULT_EX type which inclide
SI_TYPE and SI. The intent is to allow the negotiation of semantic
interpretation type by the endpoints. I show SISR as an example type
because at the time of writing it was CR status in the W3C. EMMA is an
obvious alternative. But SI type is an application choice orthogonal to the
DMSP protocol. We may need to formalize SI_TYPE to include version...

thanks,
chris


Chris Cross
Multimodal Browser Architect
_________________________
IBM Boca Raton
xcross@us.ibm.com
voice 561.862.2102  t/l 975.2102
mobile 561.317.0700
fax 501.641.6727



                                                                           
             "Burger, Eric"                                                
             <EBurger@cantata.                                             
             com>                                                       To 
                                       "Ferrans James-JFERRAN1"            
             04/18/2006 05:50          <James.Ferrans@motorola.com>om>, Chris 
             PM                        Cross/West Palm Beach/IBM@IBMUS     
                                                                        cc 
                                       <dmsp@ietf.org>                     
                                                                   Subject 
                                       RE: [Dmsp] RE: DMSP vs EMMA         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I'm not a fan of tunneling MRCPv2.  If one needs MRCPv2, my guess is one
would use MRCPv2.

That said, I would offer the same approach to recognition results as we did
in MRCPv2.  Virtually any deviation from EMMA is bound to result in a loss
of functionality and you can bet that someone will want some extension that
gets into EMMA put into DMSP.

Can anyone give a value to having a proprietary DMSP format that differs
from EMMA?

The flip side is there are lots of benefits of reusing EMMA:

Same parser / generator
Same data format
Integrates directly with speech engines and browsers
Always "the latest": don't need to hack DMSP every time EMMA gets a new
feature

________________________________________
From: Ferrans James-JFERRAN1 [mailto:James.Ferrans@motorola.com]
Sent: Friday, April 14, 2006 2:02 PM
To: Chris Cross; dmsp@ietf.org
Subject: RE: [Dmsp] RE: DMSP vs EMMA

I strongly agree.
An interesting thought experiment would be to consider if CMD_LOAD_SRC
could contain an MRCP request and the result be an MRCP response.
According to our studies this is quite inefficient, but if it were possible
to (mis)use DMSP in this way, that would indicate that DMSP isn't making
assumptions about its payload, and that we're not duplicating MRCP's
functionality.
Jim

________________________________________
From: Chris Cross [mailto:xcross@us.ibm.com]
Sent: Friday, April 14, 2006 11:47 AM
To: dmsp@ietf.org
Subject: Re: [Dmsp] RE: DMSP vs EMMA
> DSMP messages are really closed to VoiceXML events / commands
> (NOINPUT, NOMATCH,...). Multimodal services can be done without
> VoiceXML browser (without VXML scripts) with only simple ASR/TTS
> ressources (only launch recognition or synthesis process). Do you
> plan to open / enlarge the DMSP protocol to "simple" Voice server
> (ASR+TTS without VoiceXML) ?

I agree with other's responses to Aurelien. However, we must take care to
not duplicate the function of MRCP. The domain we're working in is the
sychronization of modalities within a dialog. I think if all an application
wants to do is speech enable itself through a low level speech engine
interface then MRCP may be the correct route for that.

chris cross
_______________________________________________
Dmsp mailing list
Dmsp@ietf.org
https://www1.ietf.org/mailman/listinfo/dmsp