RE: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt

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"                                              
             <Jonathan.Engelsm                                          To 
             a@motorola.com>           <dmsp@ietf.org>                     
                                                                        cc 
             01/20/2007 10:31                                              
             AM                                                    Subject 
                                       RE: [Dmsp] clarifications requested 
                                       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 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,

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 message
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 "<?xml" treat it as VoiceXML content, otherwise
confirm it's a fully qualified URL.  Any preferences one way or the
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 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?

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 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 the
Value column in Table 21 is incorrect.  This will be updated in the next
revision.

Let us know if there are any further comments on these items, and if you
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 Cross/West Palm
Beach/IBM] _______________________________________________
Dmsp mailing list
Dmsp@ietf.org
https://www1.ietf.org/mailman/listinfo/dmsp

RE: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt

Attachment: graycol.gif

Attachment: pic31619.gif

Attachment: ecblank.gif