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

"Brian Marquette" <BMarquette@sandcherry.com> Tue, 21 March 2006 20:21 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnMJ-00056k-3s; Tue, 21 Mar 2006 15:21:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnMH-00052k-Ar for dmsp@ietf.org; Tue, 21 Mar 2006 15:21:37 -0500
Received: from savgw1.sandcherry.com ([205.158.232.68] helo=savgw1.sccorp.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLnMG-0007Cg-VI for dmsp@ietf.org; Tue, 21 Mar 2006 15:21:37 -0500
Received: from EXCHANGE.sccorp.com ([10.20.1.33]) by savgw1.sccorp.com (SMSSMTP 4.1.9.35) with SMTP id M2006032113213102033 ; Tue, 21 Mar 2006 13:21:31 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Mar 2006 13:21:30 -0700
Message-ID: <16C66F7877B170458BE0B4714AF12F618DEB3B@exchange.sccorp.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dmsp] Comments on draft-engelsma-dmsp-01.txt
Thread-Index: AcZLWegFSIl8r7ahSyiEz4UGx6mj5QBL3LLwACYB7mA=
From: "Brian Marquette" <BMarquette@sandcherry.com>
To: "Burger, Eric" <EBurger@cantata.com>, <dmsp@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc:
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>
Errors-To: dmsp-bounces@ietf.org

Eric

As for some of your points, the main use case here is a thin client
handset that is attempting to run a Voice and Visual application.
VoiceXML browser is in the network and is most likely using MRCP for
interactions with ASR and TTS.  The connection however from the thin
client to the Voice server is over packet data and typically 2 to 2.5G.
So latency will become a huge issue if we try to communicate with XML. 

The result processing summary you wrote is basically correct. There are
a couple of use cases there, one for simple navigation and form filling,
and another for selecting from a n-best result. For example, you might
be using a map application and be looking for "Maple". The result should
allow the user to see the n-best list and visually select which address
he intended. 

Brian
 

-----Original Message-----
From: Burger, Eric [mailto:EBurger@cantata.com] 
Sent: Monday, March 20, 2006 6:49 PM
To: dmsp@ietf.org
Subject: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

Section 3.

Binary encoding - blech. Will anyone use XML if all of the normative
text describes the binary encoding? Conversely, given how much easier it
is to generate, parse, and debug XML, would it not be better to have the
normative text use XML, and have the mapping of tags to binary values in
the appendix?

Seems very VoiceXML-centric, to the point it may only work with
VoiceXML. Is that OK?

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.

RESULT: is there any reason not to simply tunnel EMMA or NLSML?
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.

SIG_VXML_START: which is not really going to be used, SIG_INIT or
SIG_VXML_START?

Can Dispatch: Which is more likely, a series of "can you do this?" or
"what can you do?" If the latter, then it would be better to have a
single OPTIONS message. If the former, then the mechanism as described
is OK.

Get/Set Cookies security and privacy considerations

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.

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?

General: Much easier to build parsers that have all of the fixed-length
data items up front. Take Table 36, for example. Having the Error Code
follow Correlation means I can immediately figure out the status without
having to parse the Node and Location fields. I might not care,
depending on the error. If I do care, there is no harm in having the
Error Code up front.

Need to explain how a loop could occur (Section 4.4)

_______________________________________________
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