RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

["Burger, Eric" <[e-mail]>]

In-line

> ________________________________________
> From: Chris Cross [mailto:[e-mail]] 
> Sent: Tuesday, March 21, 2006 3:25 PM
> To: [e-mail]
> Subject: Re: [Dmsp] Comments on draft-engelsma-dmsp-01.txt
> 
> Eric,
> Thanks for your comments. It takes a bit of work to wade through a
spec this size and I appreciate the effort. 
> 
> "Burger, Eric" <[e-mail]> wrote on 03/20/2006 08:48:35 PM:
[snip]
> > User-Agent field in SIG_INIT: says for advertising capabilities, but
it
> > is just a string identifying the GUA. A better mechanism is to
advertise
> > capabilities.
> 
> Open to suggestion here. The intent is to provide an efficient
one-turn init event.

I would offer choosing to either have a bunch of protocol data elements
conveying what capabilities need to be conveyed, a parameterized string,
or a structured string.  I would offer that creating PDE's makes
extensions problematic and structured strings are doomed to
interoperability failure.  That leaves a string with (extendable)
parameters.


[snip]
> > Translating the real result into a DMSP result will be error-prone
and
> > is guaranteed to not supply what the application desires. What is
the
> > use case? It is not a VoiceXML browser in the handset; that is what
> > MRCPv2 is for. It is inconceivable that it is a network-based
VoiceXML
> > browser using a handset ASR engine; if the handset has the power to
run
> > ASR, it most likely has the power to run a VoiceXML browser.
> > 
> > For that matter, what does the GUA do with recognition results? Is
it to
> > populate fields or to help in low-confidence situations? If the
former,
> > then it isn't worth having confidence scores - there should not be
more
> > than one value. If the latter, what does the interaction look like?
I am
> > asking, because presumably the VoiceXML interpreter will go into its
"I
> > did not get that" portion of the form. I am assuming that the goal
is to
> > allow the user to visually pick from a list of results. I was
thinking
> > that it might be more compact to have the GUA send the VUA the
correct
> > pick by reference, but that is too much state to carry around (which
> > pick of which result are we referring to ). Thus the current model
where
> > the GUA pushes down the result string is a good way to go.
> 
> Don't assume that the application author will only want to
> handle n-best results in the voice modality. He may prompt
> the user with "what did you say?" and pop up a list to choose
> from. The same argument goes for the interpretation and/or
> recognition results. There's all kinds of creative things
> that the GUA can do with that information.
> 
> MRCP by definition does not support dialog level application
> programming. So your assertion that there won't be VoiceXML
> in a handset is incorrect. DMSP is designed to support a
> couple of broad use cases: Interaction Manager and
> peer-to-peer configurations. The latter includes an X+V
> multimodal browser where the VoiceXML is rendered by a
> remote VoiceXML server. Turn your assertion around: are
> there devices that could support a VoiceXML interpreter but
> not ASR/TTS?

That was my point exactly.  We violently agree here.

[snip]
> > Strings: most of the strings are or will need to be Unicode. For
> > example, arbitrary form text data can easily be non-Western.
Likewise,
> > expect International URI's to end up as Unicode or UTF-16. If every
byte
> > counts, then I would offer selecting the charset in SIG_INIT or
> > SIG_VXML_START, with a default to UTF-8.
> 
> Every byte counts so utf-8 is probably the default. Maybe
> string encoding is part of the initial session negotiation?

Sounds like a plan.

> > DOM keydown, keyup, keypress events: I don't have the DOM reference
> > handy. Do these refer to actual keyboard presses or ink strokes? If
so,
> > who would use a key-by-key protocol for a distributed, web-oriented
> > stimulus protocol?
> 
> Others in the multimodal community, such as some OMA members,
> have pressed for this level of granularity (no pun intended.)
> I don't think key-by-key protocol is practical on a real
> network and it is generally not necessary in dialog level
> interaction.

Ouch!  Hehehe.  Agreed :)

[snip]

_______________________________________________
Dmsp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dmsp