From dmsp-bounces@ietf.org Fri Dec 01 11:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqB56-0005IN-Oi; Fri, 01 Dec 2006 11:17:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqB56-0005IB-0Z for dmsp@ietf.org; Fri, 01 Dec 2006 11:17:44 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GqB54-0003uq-Ou for dmsp@ietf.org; Fri, 01 Dec 2006 11:17:43 -0500 X-VirusChecked: Checked X-Env-Sender: Jonathan.Engelsma@motorola.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1164989861!11665880!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 19446 invoked from network); 1 Dec 2006 16:17:41 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-10.tower-119.messagelabs.com with SMTP; 1 Dec 2006 16:17:41 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id kB1GHedr009266 for ; Fri, 1 Dec 2006 09:17:40 -0700 (MST) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id kB1GHdDC027718 for ; Fri, 1 Dec 2006 10:17:40 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Dec 2006 11:17:38 -0500 Message-ID: <6806C66D71ED9241BAECC0478173B71F01072D05@de01exm69.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarifications requested in draft-engelsma-dmsp-02.txt thread-index: AccVZDgtYZVvWjV7Rvy588x+cem5Ew== From: "Engelsma Jonathan-QA2678" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt X-BeenThere: dmsp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Multimodal Synchronization Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dmsp-bounces@ietf.org All, =20 We're working on another revision of the dmsp spec that we hope to complete in the next few days. Here is a summary of some of the areas that need correction/clarification in the current version. Please forward any comments you have on these or other areas=20 =20 While working on a C++ implementation of the client state machine, Jim Ferrans pointed out the following items that need attention: =20 Item 1 - Section 4.2.3.2 VXML Start Signal Message - currently only supports a dialog url. In certain situations it may be desirable for the client application to be completely self contained, and not dependent on a network-based application server. The VXML Start message should be able to include actual VoiceXML content instead of an url. =20 Comments: There are a couple of possiblities. 1) Add a flag to the message that indicates whether the string in the Dialog URL field is an URL or VoiceXML content. 2) Leave the message as it is, and let the VUA infer from the value of Dialog URL itself, what it is. For example, if the string begins with "; Fri, 1 Dec 2006 13:25:46 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB1IPjFC457140 for ; Fri, 1 Dec 2006 11:25:45 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB1IPjqD024638 for ; Fri, 1 Dec 2006 11:25:45 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kB1IPjFT024616 for ; Fri, 1 Dec 2006 11:25:45 -0700 In-Reply-To: <6806C66D71ED9241BAECC0478173B71F01072D05@de01exm69.ds.mot.com> Subject: Re: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt To: "Engelsma Jonathan-QA2678" X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Chris Cross Date: Fri, 1 Dec 2006 13:25:35 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 12/01/2006 11:25:44 MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: dmsp@ietf.org X-BeenThere: dmsp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Multimodal Synchronization Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1707142298==" Errors-To: dmsp-bounces@ietf.org --===============1707142298== Content-type: multipart/alternative; Boundary="0__=0ABBF8A4DFF2C4BF8f9e8a93df938690918c0ABBF8A4DFF2C4BF" Content-Disposition: inline --0__=0ABBF8A4DFF2C4BF8f9e8a93df938690918c0ABBF8A4DFF2C4BF Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable "Engelsma Jonathan-QA2678" wrote on 12/01/2006 11:17:38 AM: > All, > > We're working on another revision of the dmsp spec that we hope to > complete in the next few days. Here is a summary of some of the area= s > that need correction/clarification in the current version. Please > forward any comments you have on these or other areas > > While working on a C++ implementation of the client state machine, Ji= m > Ferrans pointed out the following items that need attention: > > Item 1 - Section 4.2.3.2 VXML Start Signal Message - currently only > supports a dialog url. In certain situations it may be desirable for= > the client application to be completely self contained, and not > dependent on a network-based application server. The VXML Start mess= age > should be able to include actual VoiceXML content instead of an url. > > Comments: There are a couple of possiblities. 1) Add a flag to the > message that indicates whether the string in the Dialog URL field is = an > URL or VoiceXML content. 2) Leave the message as it is, and let the = VUA > infer from the value of Dialog URL itself, what it is. For example, = if > the string begins with " confirm it's a fully qualified URL. Any preferences one way or the > other? > I prefer the additional field. Much cleaner data model at the cost of o= ne bit in the message. > Item 2 - Section 4.2.6.7 - 4.2.6.8. Originally, the Motorola > implementation of the server state machine, only reported the slots > corresponding to VoiceXML form items that have changed value during a= > given recognition cycle are reflected in the recognition result > messages. The motivation for this approach was to minimize message > size. However, application developers have argued convincingly that > this is not helpful, and its best for the recognition result to fully= > represent what the user actually said... > > Comments: We should add wording in these sections to clarify this > situation. Any additional or contrary thoughts from other server > implementors? > Interesting question. I've always read "field" in tables 7 and 8 to referring to VoiceXML fields;-) When the VUA is a VoiceXML processor, r= eco result can come from one of two situations: 1) when processing an individual field or 2) from a form level grammar for a mixed initiative= form. In the first case, by definition the reco result should just retu= rn the result for the field. In the second, the result should be returned = for all the fields that were filled. I believe if an implementation returns= more than the fields that were filled then it breaks the semantics of m= ixed initiative which allows for partial filling of a form with a single utterance that matches the form level grammar. This question requires a= careful reading of the VoiceXML spec. Re-reading Item 2, doesn't sendin= g only what changed "fully represent what the user actually said?" > In addition to these issues Jim raised, there were a couple of other > minor issues reported that need clarification/correction: > > Item 3: Table 11 - The 7th field in the table "Event Type" is actuall= y a > typo and will be eliminated in the next revision. > > Item 4: Section 4.2.4.9, Table 21. The 5th field listed in the table= > "Fields" is meant to be an array of strings, NOT an array of Fields > values as defined in Table 7. Hence the reference "see Table 7" in t= he > Value column in Table 21 is incorrect. This will be updated in the n= ext > revision. I concur with both corrections. Chris= --0__=0ABBF8A4DFF2C4BF8f9e8a93df938690918c0ABBF8A4DFF2C4BF Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

"Engelsma Jonathan-QA2678" <Jonathan.Engelsma@motor= ola.com> wrote on 12/01/2006 11:17:38 AM:

> All,
>  
> We're working on another revision of the dmsp spec that we hope to=
> complete in the next few days.  Here is a summary of some of = the areas
> that need correction/clarification in the current version.  P= lease
> forward any comments you have on these or other areas
>  
> While working on a C++ implementation of the client state machine,= Jim
> Ferrans pointed out the following items that need attention:
>  
> Item 1 -  Section 4.2.3.2 VXML Start Signal Message - current= ly only
> supports a dialog url.  In certain situations it may be desir= able for
> the client application to be completely self contained, and not > dependent on a network-based application server.  The VXML St= art message
> should be able to include actual VoiceXML content instead of an ur= l.  
>
> Comments: There are a couple of possiblities.  1) Add a flag = to the
> message that indicates whether the string in the Dialog URL field = is an
> URL or VoiceXML content.  2) Leave the message as it is, and = let the VUA
> infer from the value of Dialog URL itself, what it is.  For e= xample, if
> the string begins with "<?xml" treat it as VoiceXML c= ontent, otherwise
> confirm it's a fully qualified URL.  Any preferences one way = or the
> other?
>

I prefer the additional field. Much cleaner data model at the cost = of one bit in the message.

> Item 2 - Section 4.2.6.7 - 4.2.6.8. Originally, the Motorola
> implementation of the server state machine, only reported the slot= s
> corresponding to VoiceXML form items that have changed value durin= g a
> given recognition cycle are reflected in the recognition result > messages.  The motivation for this approach was to minimize m= essage
> size.  However, application developers have argued convincing= ly that
> this is not helpful, and its best for the recognition result to fu= lly
> represent what the user actually said...
>
> Comments: We should add wording in these sections to clarify this<= br> > situation.  Any additional or contrary thoughts from other se= rver
> implementors?
>

Interesting question. I've always read "field" in tables = 7 and 8 to referring to VoiceXML fields;-) When the VUA is a VoiceXML p= rocessor, reco result can come from one of two situations: 1) when proc= essing an individual field or 2) from a form level grammar for a mixed = initiative form. In the first case, by definition the reco result shoul= d just return the result for the field. In the second, the result shoul= d be returned for all the fields that were filled. I believe if an impl= ementation returns more than the fields that were filled then it breaks= the semantics of mixed initiative which allows for partial filling of = a form with a single utterance that matches the form level grammar. Thi= s question requires a careful reading of the VoiceXML spec. Re-reading = Item 2, doesn't sending only what changed "fully represent what th= e user actually said?"

> In addition to these issues Jim raised, there were a couple of oth= er
> minor issues reported that need clarification/correction:
>
> Item 3: Table 11 - The 7th field in the table "Event Type&quo= t; is actually a
> typo and will be eliminated in the next revision.
>
> Item 4: Section 4.2.4.9, Table 21.  The 5th field listed in t= he table
> "Fields" is meant to be an array of strings, NOT an arra= y of Fields
> values as defined in Table 7.  Hence the reference "see = Table 7" in the
> Value column in Table 21 is incorrect.  This will be updated = in the next
> revision.

I concur with both corrections.

Chris= --0__=0ABBF8A4DFF2C4BF8f9e8a93df938690918c0ABBF8A4DFF2C4BF-- --===============1707142298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Dmsp mailing list Dmsp@ietf.org https://www1.ietf.org/mailman/listinfo/dmsp --===============1707142298==-- From dmsp-bounces@ietf.org Fri Dec 01 16:34:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqG1V-0005wR-Ns; Fri, 01 Dec 2006 16:34:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqG1V-0005wK-7T for dmsp@ietf.org; Fri, 01 Dec 2006 16:34:21 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GqG1T-0004vA-Tx for dmsp@ietf.org; Fri, 01 Dec 2006 16:34:21 -0500 X-VirusChecked: Checked X-Env-Sender: James.Ferrans@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1165008858!15528783!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 13183 invoked from network); 1 Dec 2006 21:34:19 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-3.tower-119.messagelabs.com with SMTP; 1 Dec 2006 21:34:19 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id kB1LYIJu011930 for ; Fri, 1 Dec 2006 14:34:18 -0700 (MST) Received: from de01exm66.ds.mot.com (de01exm66.am.mot.com [10.176.8.17]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id kB1LYHXc005608 for ; Fri, 1 Dec 2006 15:34:18 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt Date: Fri, 1 Dec 2006 16:34:17 -0500 Message-ID: In-Reply-To: <6806C66D71ED9241BAECC0478173B71F01072D05@de01exm69.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt thread-index: AccVZDgtYZVvWjV7Rvy588x+cem5EwAJ+yLw From: "Ferrans James-JFERRAN1" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: dmsp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Multimodal Synchronization Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dmsp-bounces@ietf.org On Item 1, my preference would be to have a flag. This would enable better diagnostics if the VoiceXML content should have a missing xml line. On Item 2, the current semantics are defensible when the application is presenting a field-based interface and the user is filling them with voice utterances. The assumption here that if a value is unchanged, it's still sitting in the field and we shouldn't waste the bandwidth to resend it. But this optimization doesn't really buy us much, and in a command-and-control interface it makes less sense. For example, we recently wrote a multimodal game for a Linux phone, using its Qt GUI framework to show a collection of bouncing planets. You can grab one with the stylus and fling it around (very satisfying), and you can press the phone's PTT key and say "earth go slower", "everybody hide", "tethys jump", and so on. Under the current semantic if I say "earth slower" and "earth hide", my second utterances' "earth" is not sent back to the phone. This means the client has to do extra book-keeping, which is annoying. Jim Ferrans -----Original Message----- From: Engelsma Jonathan-QA2678=20 Sent: Friday, December 01, 2006 10:18 AM To: dmsp@ietf.org Subject: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt All, =20 We're working on another revision of the dmsp spec that we hope to complete in the next few days. Here is a summary of some of the areas that need correction/clarification in the current version. Please forward any comments you have on these or other areas=20 =20 While working on a C++ implementation of the client state machine, Jim Ferrans pointed out the following items that need attention: =20 Item 1 - Section 4.2.3.2 VXML Start Signal Message - currently only supports a dialog url. In certain situations it may be desirable for the client application to be completely self contained, and not dependent on a network-based application server. The VXML Start message should be able to include actual VoiceXML content instead of an url. =20 Comments: There are a couple of possiblities. 1) Add a flag to the message that indicates whether the string in the Dialog URL field is an URL or VoiceXML content. 2) Leave the message as it is, and let the VUA infer from the value of Dialog URL itself, what it is. For example, if the string begins with "