From dmsp-bounces@ietf.org Sat Jan 20 12:31:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8K4L-00019X-9H; Sat, 20 Jan 2007 12:31:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8K4K-00018f-83 for dmsp@ietf.org; Sat, 20 Jan 2007 12:31:56 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8K4D-0000d7-3a for dmsp@ietf.org; Sat, 20 Jan 2007 12:31:56 -0500 X-VirusChecked: Checked X-Env-Sender: Jonathan.Engelsma@motorola.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1169314307!177232!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 825 invoked from network); 20 Jan 2007 17:31:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 20 Jan 2007 17:31:47 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0KHVgWQ026332 for ; Sat, 20 Jan 2007 10:31:46 -0700 (MST) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l0KHVgds026392 for ; Sat, 20 Jan 2007 11:31:42 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C73CB8.D90020B2" Subject: RE: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt Date: Sat, 20 Jan 2007 12:31:39 -0500 Message-ID: <6806C66D71ED9241BAECC0478173B71F0122F415@de01exm69.ds.mot.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt thread-index: AccVZDgtYZVvWjV7Rvy588x+cem5EwAJ+yLwCcsOR6A= From: "Engelsma Jonathan-QA2678" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f44ec0621adcbdd156592e56527b232 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C73CB8.D90020B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 All, I've incorporated the comments on the items discussed below along with a few minor editorial changes. Attached is an 03 revision, please review and let me know if there are any addition comments.=20 Thanks, -jre -----Original Message----- From: Ferrans James-JFERRAN1=20 Sent: Friday, December 01, 2006 4:34 PM To: dmsp@ietf.org Subject: RE: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt 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 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 "; Mon, 22 Jan 2007 19:31:54 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0N0Vsmh549834 for ; Mon, 22 Jan 2007 17:31:54 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0N0VspO021382 for ; Mon, 22 Jan 2007 17:31:54 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0N0VrYh021371 for ; Mon, 22 Jan 2007 17:31:53 -0700 In-Reply-To: <6806C66D71ED9241BAECC0478173B71F0122F415@de01exm69.ds.mot.com> Subject: RE: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt To: dmsp@ietf.org X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Chris Cross Date: Mon, 22 Jan 2007 17:31:44 -0700 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/22/2007 17:31:53 MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 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="===============0434304779==" Errors-To: dmsp-bounces@ietf.org --===============0434304779== Content-type: multipart/related; Boundary="0__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3" --0__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3 Content-type: multipart/alternative; Boundary="1__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3" --1__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Jonathan, I'm happy with this draft and agree to its submission with no further revision. Well done! thanks, chris Chris Cross Multimodal Browser Architect _______________________ IBM Boca Raton xcross@us.ibm.com office 561 862 2102 fax 501 641 6727 = "Engelsma = Jonathan-QA2678" = = = cc 01/20/2007 10:31 = AM Subj= ect RE: [Dmsp] clarifications reques= ted in draft-engelsma-dmsp-02.txt = = = = = = = All, I've incorporated the comments on the items discussed below along with = a few minor editorial changes. Attached is an 03 revision, please review= and let me know if there are any addition comments. Thanks, -jre -----Original Message----- From: Ferrans James-JFERRAN1 Sent: Friday, December 01, 2006 4:34 PM To: dmsp@ietf.org Subject: RE: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt 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 pres= s the phone's PTT key and say "earth go slower", "everybody hide", "tethy= s 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 Sent: Friday, December 01, 2006 10:18 AM To: dmsp@ietf.org Subject: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt 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. Please 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 - 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 messag= e 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 VU= A infer from the value of Dialog URL itself, what it is. For example, if= the string begins with "

Jonathan,
I'm happy with this draft and agree to its submission with no further r= evision. Well done!

thanks,
chris


Chris Cross
Multimodal Browser Architect
_______________________
IBM Boca Raton
xcross@us.ibm.com
office 561 862 2102
fax 501 641 6727

3D"Inactive"Engelsma Jonathan-QA2678" <Jonathan.Engelsma@motorola.co= m>


=
          "Engelsma Jonathan-QA2678" <Jonath= an.Engelsma@motorola.com>

          01/20/2007 10:31 AM

 =
3D=
To
3D""
<dmsp@ietf.org>
3D=
cc
3D""
3D=
Subject
3D""
RE: [Dmsp] clarifications requested in draft-engelsma-= dmsp-02.txt
3D=3D""

 
All,

I've incorporated the comments on the items discussed below along with = a
few minor editorial changes.  Attached is an 03 revision, please r= eview
and let me know if there are any addition comments.

Thanks,
-jre

-----Original Message-----
From: Ferrans James-JFERRAN1
Sent: Friday, December 01, 2006 4:34 PM
To: dmsp@ietf.org
Subject: RE: [Dmsp] clarifications requested in
draft-engelsma-dmsp-02.txt

On Item 1, my preference would be to have a flag.  This would enab= le
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 unchange= d,
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, w= e
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 pres= s
the phone's PTT key and say "earth go slower", "everybod= y 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
Sent: Friday, December 01, 2006 10:18 AM
To: dmsp@ietf.org
Subject: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt<= br>
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 a= reas
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, Jim<= br> Ferrans pointed out the following items that need attention:

Item 1 -  Section 4.2.3.2 VXML Start Signal Message - currently on= ly
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 m= essage
should be able to include actual VoiceXML content instead of an url. &n= bsp;

Comments: There are a couple of possiblities.  1) Add a flag to th= e
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 t= he VUA
infer from the value of Dialog URL itself, what it is.  For exampl= e, if
the string begins with "<?xml" treat it as VoiceXML conten= t, otherwise
confirm it's a fully qualified URL.  Any preferences one way or th= e
other?

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 messag= e
size.  However, application developers have argued convincingly th= at
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<= br> implementors?

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= 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 the ta= ble
"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 the
Value column in Table 21 is incorrect.  This will be updated in th= e next
revision.

Let us know if there are any further comments on these items, and if yo= u
have any addition issues that are not addressed here.

Thanks,
-jre

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

_______________________________________________
Dmsp mailing list
Dmsp@ietf.org
https:= //www1.ietf.org/mailman/listinfo/dmsp
[attachment "draft-engelsma-dmsp-03.txt" deleted by Chris Cro= ss/West Palm Beach/IBM] _______________________________________________=
Dmsp mailing list
Dmsp@ietf.org
https:= //www1.ietf.org/mailman/listinfo/dmsp

= --1__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3-- --0__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=08BBF8FFDF913DC38f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3 Content-type: image/gif; name="pic31619.gif" Content-Disposition: inline; filename="pic31619.gif" Content-ID: <2__=08BBF8FFDF913DC38f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=08BBF8FFDF913DC38f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=08BBF8FFDF913DC38f9e8a93df938690918c08BBF8FFDF913DC3-- --===============0434304779== 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 --===============0434304779==--