[DMSP] Draft 0.1 - OMA Multimodal and Multi-device = Enabler document

Eric Burger

debajit@gmail.com
Welcome to new members:
raxit@phonologies.com

Raxit Sheth

dahl@conversational-technologies.com

Deborah Dahl

koigo@animo.co.jp

gk@ninebynine.org

thanks,

chris

Chris Cross

Multimodal Browser Architect

_________________________

IBM Boca Raton

xcross@us.ibm.com

voice 561.862.2102  t/l 975.2102

mobile 561.317.0700

fax 501.641.6727

Chris Cross wrote:

> Hi Everyone,

> I'm sending a note to your list to make the members aware of this<=
br>
> activity. The I-D "Distributed Multimodal Synchronization Pro=
tocol "

> (dmsp) can be found at

> 
http://www.ietf.org/internet-drafts/draft-engelsma-dm=
sp-01.txt
.

Chris,

Very interesting to see this pop up... I'm thinking about the web view<=
br>
synchronization problem in a couple of completely different contexts, a=
nd I note

that the diagram on page 7 of your Internet draft is almost exactly wha=
t I have

been proposing in another context [1].

But this draft seems to combine the basic event propagation model with =
details

of the specific events used for media synchronization, and I'd like to =
suggest

that, if this work goes ahead, that the event distribution protocol be =
defined

separately from the details of the events themselves (e.g. like SMTP/RF=
C2822 for

email).  Then other applications could use the same event distribu=
tion model for

completely different purposes.  (E.g. I have some similar event di=
stribution

requirements for web-based home-control applications.) I also note that=
 existing

work on publish/subscribe systems and/or instant messaging presence pro=
tocols

might be used for the protocol.

Turning to the events themselves, I think that to deploy in a Web conte=
xt it

would be sensible for event types to be identified by URIs rather than =
binary

codes.  In my own private work to date, I am using a simple event =
model that

consists of event type and event source, both URIs, and arbitrary addit=
ional

payload based on the event type.

Unfortunately, I shall not be present in Dallas to participate in the d=
ebate.  I

do think that the requirement that this proposal addresses is symptomat=
ic of a

wider gap in Web/Internet application architecture, and it would be goo=
d to see

a simple common solution emerge.  I seem to recall that, some time=
 ago, Lisa

Dussault was discussing some thoughts about notification systems for In=
ternet

applications, which may well have a part to play in this debate.

#g

--

[1] 
http://wiki.oss-watch.ac.uk/InterPortletCommun=
icationConsideredHarmful

Chris Cross wrote:

> Hi Everyone,

> I'm sending a note to your list to make the members aware of this<=
br>
> activity. The I-D "Distributed Multimodal Synchronization Pro=
tocol "

> (dmsp) can be found at

> 
http://www.ietf.org/internet-drafts/draft-engelsma-dm=
sp-01.txt
. We have

> a mailing list at dmsp@ietf.org and a twice monthly phone conferen=
ce.

> 

> Dmsp is being developed to enable distributed multimodal systems. =
I've

> been invited to present an overview at both the apps and rai gener=
al

> meetings in Dallas. We welcome your attendance at these presentati=
ons

> and interested individuals' participation in our mail list and
=

> conference calls.

> 

> At the bottom of this note is a draft charter we've discussed on t=
he

> list that gives a more detailed description of dmsp.

> 

> thanks,

> chris

> 

> 

> Chris Cross

> Multimodal Browser Architect

> _________________________

> IBM Boca Raton

> xcross@us.ibm.com

> voice 561.862.2102

> mobile 561.317.0700

> fax 501.641.6727

> 

> 

> The convergence of wireless communications with information techno=
logy

> and the miniaturization of computing platforms have resulted in ad=
vanced

> mobile devices that offer high resolution displays, application pr=
ograms

> with graphical user interfaces, and access to the internet through=
 full

> function web browsers.

> 

> Mobile phones now support most of the functionality of a laptop
> computer. However the miniaturization that has made the technology=

> possible and commercially successful also puts constraints on the =
user

> interface. Tiny displays and keypads significantly reduce the usab=
ility

> of application programs.

> 

> Multimodal user interfaces, UIs that offer multiple modes of

> interaction, have been developed that greatly improve the usabilit=
y of

> mobile devices. In particular multimodal UIs that combine speech a=
nd

> graphical interaction are proving themselves in the marketplace.
> 

> However, not all mobile devices provide the computing resources to=

> perform speech recognition and synthesis locally on the device. Fo=
r

> these devices it is necessary to distribute the speech modality to=
 a

> server in the network.

> 

> The Distributed Multimodal Working Group will develop the protocol=
s

> necessary to control, coordinate, and synchronize distributed moda=
lities

> in a distributed Multimodal system. There are several protocols an=
d

> standards necessary to implement such a system including DSR and A=
MR

> speech compression, session control, and media streaming. However,=
 the

> DM WG will focus exclusively on the synchronization of modalities =
being

> rendered across a network, in particular Graphical User Interface =
and

> Voice Servers.

> 

> The DM WG will develop an RFC for a Distributed Multimodal

> Synchronization Protocol that defines the logical message set to e=
ffect

> synchronization between modalities and enough background on the ex=
pected

> multimodal system architecture (or reference architecture defined<=
br>
> elsewhere in W3C or OMA) to present a clear understanding of the
> protocol. It will investigate existing protocols for the transport=
 of

> the logical synchronization messages and develop an RFC detailing =
the

> message format for commercial alternatives, including, possibly, H=
TTP

> and SIP.

> 

> While not being limited to these, for simplicity of the scope the<=
br>
> protocol will assume RTP for carriage of media, SIP and SDP for se=
ssion

> control, and DSR and AMR for speech compression. The working group=
 will

> not consider the authoring of applications as it will be assumed t=
hat

> this will be done with existing W3C markup standards such as XHTML=
 and

> VoiceXML and commercial programming languages like Java and C/C++.=

> 

> It is expected that we will coordinate our work in the IETF with t=
he W3C

> Multimodal Interaction Work Group.

> 

> The following are our goals for the Working Group.

> 

> Date Milestone

> TBD Submit Internet Draft Describing DMSP (standards track)

> TBD Submit Drafts to IESG for publication

> TBD 2006 Submit DMSP specification to IESG

> 

-- 

Graham Klyne

For email:

http://www.nine=
bynine.org/#Contact

_______________________________________________

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

_______________________________________________

Dmsp mailing list

Dmsp@ietf.org

https:=
//www1.ietf.org/mailman/listinfo/dmsp

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" <EBurger@cantata.com> wrote on 03/20=
/2006 08:48:35 PM:

> Section 3.

> 

> Binary encoding - blech. Will anyone use XML if all of the normati=
ve

> text describes the binary encoding? Conversely, given how much eas=
ier it

> is to generate, parse, and debug XML, would it not be better to ha=
ve the

> normative text use XML, and have the mapping of tags to binary val=
ues in

> the appendix?
This is just the first draft. There are different approaches to org=
anize the spec, e.g., whether we create seperate chapters or RFCs for e=
ach encoding. It is not our intent to have only one encoding serve as t=
he normative specification for other encodings. This first draft spring=
s from the fact we have implemented the binary encoding but not the XML=
 one. 

> 

> Seems very VoiceXML-centric, to the point it may only work with
> VoiceXML. Is that OK?
That's an accurate observation. We are looking to support a "d=
ialog level" programming model. The alternative is to work at the =
level of speech engines, which is covered by MRCP. I'm open to generali=
zing as long as we can hang on to a dialog level abstraction and contin=
ue to support a VoiceXML server as an endpoint.

> 

> User-Agent field in SIG_INIT: says for advertising capabilities, b=
ut it

> is just a string identifying the GUA. A better mechanism is to adv=
ertise

> capabilities.

Open to suggestion here. The intent is to provide an efficient one-=
turn init event.

> RESULT: is there any reason not to simply tunnel EMMA or NLSML?

See section 4.2.2.9.  Extended Recognition Result Type. The in=
terpretation is part of the payload of EVT_RECO_RESULTEX event=
. EMMA is anticipated to be one of the types.

> 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 wha=
t

> MRCPv2 is for. It is inconceivable that it is a network-based Voic=
eXML

> browser using a handset ASR engine; if the handset has the power t=
o run

> ASR, it most likely has the power to run a VoiceXML browser.<=
br>
> 

> 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 fo=
rmer,

> 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 i=
ts "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 thin=
king

> that it might be more compact to have the GUA send the VUA the cor=
rect

> pick by reference, but that is too much state to carry around (whi=
ch

> 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 argu=
ment goes for the interpretation and/or recognition results. There's al=
l kinds of creative things that the GUA can do with that information.

MRCP by definition does not support dialog level application progra=
mming. So your assertion that there won't be VoiceXML in a handset is i=
ncorrect. DMSP is designed to support a couple of broad use cases: Inte=
raction Manager and peer-to-peer configurations. The latter includes an=
 X+V multimodal browser where the VoiceXML is rendered by a remote Voic=
eXML server. Turn your assertion around: are there devices that could s=
upport a VoiceXML interpreter but not ASR/TTS?

> 

> SIG_VXML_START: which is not really going to be used, SIG_INIT or<=
br>
> SIG_VXML_START?

SIG_VXML_START was an optimization developed for a low bandwidth li=
nk. From the description:

	"The SIG_INIT message is use=
d when fine-grained control of which events the client will listen is n=
eeded, and latency is not an issue."

> 

> Can Dispatch: Which is more likely, a series of "can you do t=
his?" or

> "what can you do?" If the latter, then it would be bette=
r to have a

> single OPTIONS message. If the former, then the mechanism as descr=
ibed

> is OK.

OK :)

> 

> Get/Set Cookies security and privacy considerations

Understand there is work to do here. The point is that we'll need t=
o propogate session information when distributing to a VoiceXML server =
(or other dialog level VUA.)

> 

> Strings: most of the strings are or will need to be Unicode. For
> example, arbitrary form text data can easily be non-Western. Likew=
ise,

> expect International URI's to end up as Unicode or UTF-16. If ever=
y 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 en=
coding is part of the initial session negotiation?

> 

> DOM keydown, keyup, keypress events: I don't have the DOM referenc=
e

> handy. Do these refer to actual keyboard presses or ink strokes? I=
f so,

> who would use a key-by-key protocol for a distributed, web-oriente=
d

> 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.

> 

> General: Much easier to build parsers that have all of the fixed-l=
ength

> data items up front. Take Table 36, for example. Having the Error =
Code

> follow Correlation means I can immediately figure out the status w=
ithout

> 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 t=
he

> Error Code up front.

Good suggestion.

> 

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

We have a use case that illustrates this that I will dig up.

> 

> _______________________________________________

> Dmsp mailing list

> Dmsp@ietf.org

> https://ww=
w1.ietf.org/mailman/listinfo/dmsp

=

--0__=0ABBFBABDFFA28A38f9e8a93df938690918c0ABBFBABDFFA28A3--

--===============0990740117==
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

--===============0990740117==--

From dmsp-bounces@ietf.org Tue Mar 21 15:38:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLncj-0007qE-GP; Tue, 21 Mar 2006 15:38:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnci-0007q8-MD
	for dmsp@ietf.org; Tue, 21 Mar 2006 15:38:36 -0500
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnci-0007sn-8Q
	for dmsp@ietf.org; Tue, 21 Mar 2006 15:38:36 -0500
X-IronPort-AV: i="4.03,116,1141621200"; 
	d="scan'208"; a="30366711:sNHT58262328"
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] Comments on draft-engelsma-dmsp-01.txt
Date: Tue, 21 Mar 2006 15:38:35 -0500
Message-ID: <330A23D8336C0346B5C1A5BB19666647027B0B13@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dmsp] Comments on draft-engelsma-dmsp-01.txt
Thread-Index: AcZLWegFSIl8r7ahSyiEz4UGx6mj5QBL3LLwACYB7mAAAWyrgA==
From: "Burger, Eric" 
To: "Brian Marquette" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
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: ,

Errors-To: dmsp-bounces@ietf.org

I would offer that XML with SIGCOMP, TLS/gzip, or another
transport-layer compression scheme will be on the same order of a binary
protocol; when you start passing n-best lists I will bet megabucks that
the binary protocol will be LARGER than XML.

On the n-best responses, I would offer that if you are interested in
n-best, you are interested in EMMA.  "Translating" it to DMSP is
guaranteed to miss some critical parameter for somebody's application,
is error prone, uses resources unnecessarily, and does not have any
benefit.

-----Original Message-----
From: Brian Marquette [mailto:BMarquette@sandcherry.com]=20
Sent: Tuesday, March 21, 2006 3:22 PM
To: Burger, Eric; dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

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.=20

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.=20

Brian
=20

-----Original Message-----
From: Burger, Eric [mailto:EBurger@cantata.com]=20
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

From dmsp-bounces@ietf.org Tue Mar 21 18:45:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLqXd-0003oJ-OX; Tue, 21 Mar 2006 18:45:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqXb-0003mq-CW
	for dmsp@ietf.org; Tue, 21 Mar 2006 18:45:31 -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 1FLqXa-0001Xi-SD
	for dmsp@ietf.org; Tue, 21 Mar 2006 18:45:31 -0500
Received: from EXCHANGE.sccorp.com ([10.20.1.33])
	by savgw1.sccorp.com (SMSSMTP 4.1.9.35) with SMTP id
	M2006032116452502561 ; Tue, 21 Mar 2006 16:45:25 -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 16:45:24 -0700
Message-ID: <16C66F7877B170458BE0B4714AF12F618DEBB0@exchange.sccorp.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dmsp] Comments on draft-engelsma-dmsp-01.txt
Thread-Index: AcZLWegFSIl8r7ahSyiEz4UGx6mj5QBL3LLwACYB7mAAAWyrgAAGjoxA
From: "Brian Marquette" 
To: "Burger, Eric" 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
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: ,

Errors-To: dmsp-bounces@ietf.org

I am VERY interested in SIGCOMP, and I know Jonathan Engelsma at
Motorola is as well. We should definitely strongly consider that as an
option.  I will also do some reading on EMMA. Currently we are using
NLSML, which I think EMMA replaces.

=20

-----Original Message-----
From: Burger, Eric [mailto:EBurger@cantata.com]=20
Sent: Tuesday, March 21, 2006 1:39 PM
To: Brian Marquette
Cc: dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

I would offer that XML with SIGCOMP, TLS/gzip, or another
transport-layer compression scheme will be on the same order of a binary
protocol; when you start passing n-best lists I will bet megabucks that
the binary protocol will be LARGER than XML.

On the n-best responses, I would offer that if you are interested in
n-best, you are interested in EMMA.  "Translating" it to DMSP is
guaranteed to miss some critical parameter for somebody's application,
is error prone, uses resources unnecessarily, and does not have any
benefit.

-----Original Message-----
From: Brian Marquette [mailto:BMarquette@sandcherry.com]
Sent: Tuesday, March 21, 2006 3:22 PM
To: Burger, Eric; dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

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.=20

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.=20

Brian
=20

-----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

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

From dmsp-bounces@ietf.org Mon Mar 27 15:46:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNybD-0007br-TI; Mon, 27 Mar 2006 15:46:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FNybC-0007bm-5l
	for dmsp@ietf.org; Mon, 27 Mar 2006 15:46:02 -0500
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNyb9-0008Lb-Ns
	for dmsp@ietf.org; Mon, 27 Mar 2006 15:46:02 -0500
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2RL1wWQ007896
	for ; Mon, 27 Mar 2006 14:01:58 -0700 (MST)
Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25])
	by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k2RKxdGv022392
	for ; Mon, 27 Mar 2006 14:59:39 -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] Comments on draft-engelsma-dmsp-01.txt
Date: Mon, 27 Mar 2006 15:45:57 -0500
Message-ID: <6806C66D71ED9241BAECC0478173B71F6DEC24@de01exm69.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dmsp] Comments on draft-engelsma-dmsp-01.txt
thread-index: AcZLWegFSIl8r7ahSyiEz4UGx6mj5QBL3LLwACYB7mAAAWyrgAAGjoxAARxNJ5A=
From: "Engelsma Jonathan-QA2678" 
To: "Brian Marquette" ,
	"Burger, Eric" 
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
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: ,

Errors-To: dmsp-bounces@ietf.org

Guys:

Sorry for not responding sooner, I was out of the office last week
without email access.  Thanks for all the excellent feedback. =20

Yes, SIGCOMP or something equivalent would be desirable. For voice
content that returns a fair amount string data (e.g., n-best results)
this would likely yield more compact messages than the current binary
format, even when encoded in an XML format.

However, while this is fairly straightforward to support from the server
side, things aren't quite so easy on the terminal side.  For low to
mid-tier handsets, SIGCOMP would have to be supported as a firmware
service.  While that may very well happen in the future, there are
millions of handsets out there today that do not support it, and many
more that will ship in the future that won't either.  In terms of
alternatives, some of Motorola's handsets provide a proprietary zip
capability to J2ME developers, but in general, as far as I know this
sort of capability is not widely available to middleware and/or
application developers across handsets.  A third option would be to
implement a compression library and include it with the multimodal
application, however this increases the application's footprint which is
not a good thing in terms of over-the-air downloads, not to mention the
impact on performance (at least in the case of Java).

We are open to SIGCOMP, gzip, etc., where possible, but one of our
requirements is to be able to implement the protocol on the terminal
without requiring compression.  We realize there are trade-offs here, as
Eric has pointed out, but we see enormous utility in keeping the
protocol simple and compact enough to be implemented on handsets and
wireless networks that are widely available today.

-jre

-----Original Message-----
From: Brian Marquette [mailto:BMarquette@sandcherry.com]=20
Sent: Tuesday, March 21, 2006 6:45 PM
To: Burger, Eric
Cc: dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

I am VERY interested in SIGCOMP, and I know Jonathan Engelsma at
Motorola is as well. We should definitely strongly consider that as an
option.  I will also do some reading on EMMA. Currently we are using
NLSML, which I think EMMA replaces.

=20

-----Original Message-----
From: Burger, Eric [mailto:EBurger@cantata.com]
Sent: Tuesday, March 21, 2006 1:39 PM
To: Brian Marquette
Cc: dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

I would offer that XML with SIGCOMP, TLS/gzip, or another
transport-layer compression scheme will be on the same order of a binary
protocol; when you start passing n-best lists I will bet megabucks that
the binary protocol will be LARGER than XML.

On the n-best responses, I would offer that if you are interested in
n-best, you are interested in EMMA.  "Translating" it to DMSP is
guaranteed to miss some critical parameter for somebody's application,
is error prone, uses resources unnecessarily, and does not have any
benefit.

-----Original Message-----
From: Brian Marquette [mailto:BMarquette@sandcherry.com]
Sent: Tuesday, March 21, 2006 3:22 PM
To: Burger, Eric; dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

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.=20

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.=20

Brian
=20

-----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

_______________________________________________
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

From dmsp-bounces@ietf.org Mon Mar 27 16:21:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNz9Q-0002J2-G5; Mon, 27 Mar 2006 16:21:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FNz9P-0002Ih-JC
	for dmsp@ietf.org; Mon, 27 Mar 2006 16:21:23 -0500
Received: from mail119.messagelabs.com ([216.82.241.179])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FNz9P-00045Z-CQ
	for dmsp@ietf.org; Mon, 27 Mar 2006 16:21:23 -0500
X-VirusChecked: Checked
X-Env-Sender: Jonathan.Engelsma@motorola.com
X-Msg-Ref: server-8.tower-119.messagelabs.com!1143492881!11035969!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 20523 invoked from network); 27 Mar 2006 20:54:42 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-8.tower-119.messagelabs.com with SMTP;
	27 Mar 2006 20:54:42 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2RLAece009756
	for ; Mon, 27 Mar 2006 14:10:40 -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 k2RLAUFY021855
	for ; Mon, 27 Mar 2006 15:10:30 -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: Mon, 27 Mar 2006 15:54:40 -0500
Message-ID: <6806C66D71ED9241BAECC0478173B71F6DEC31@de01exm69.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: xml vs. binary encoding
thread-index: AcZR4KrommcKrIFuRzu9VO6lKAJuJA==
From: "Engelsma Jonathan-QA2678" 
To: 
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Subject: [Dmsp] xml vs. binary encoding
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,

I wanted to share a few additional comments/observations on the
discussion regarding XML vs. binary DMSP message encodings.

XML is typically easier to work with, but once again things are a little
different from the terminal perspective, particularly if you are working
with J2ME.  Handsets that implement MIDP 2.0 are not required to provide
XML processing capabilities (defined in the optional JSR 172). J2ME
Applications running on handsets without JSR 172 would have to provide
their own XML parser, which translates into larger midlets and more
latency.  At the same time reading/writing the binary messages defined
by DMSP is really straight-forward.  I'd post some code examples, but
you'd get bored real quick.  :-)

Chris and I did at one point discuss whether the normative text should
assume the XML encoding or the binary, but as Chris already mentioned,
our implementation experience was mostly with the latter, so that's what
we went with.  If the group's concensus is that referencing the XML
encoding in the normative text and moving the binary encoding to an
appendix would make the specification more readable and less
intimidating to implementors (and arguably more "future proof"), I don't
think I'd protest too loudly.  I'm fairly confident that implementors
trying to obtain snappy responses on a mid-tier handset/2.5G network
will go with the most compact encoding either way.=20

-jre

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

From dmsp-bounces@ietf.org Mon Mar 27 21:17:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO3lv-0001WX-Rw; Mon, 27 Mar 2006 21:17:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FO3lu-0001WS-NI
	for dmsp@ietf.org; Mon, 27 Mar 2006 21:17:26 -0500
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO3lt-0000sA-Eg
	for dmsp@ietf.org; Mon, 27 Mar 2006 21:17:26 -0500
X-IronPort-AV: i="4.03,136,1141621200"; 
	d="scan'208"; a="30698938:sNHT111379656"
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] Comments on draft-engelsma-dmsp-01.txt
Date: Mon, 27 Mar 2006 21:17:16 -0500
Message-ID: <330A23D8336C0346B5C1A5BB196666470287C4D3@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dmsp] Comments on draft-engelsma-dmsp-01.txt
Thread-Index: AcZLWegFSIl8r7ahSyiEz4UGx6mj5QBL3LLwACYB7mAAAWyrgAAGjoxAARxNJ5AAFrns0A==
From: "Burger, Eric" 
To: "Engelsma Jonathan-QA2678" ,
	"Brian Marquette" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
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: ,

Errors-To: dmsp-bounces@ietf.org

We went through this ad nauseam in lemonade, but we woke up and realized
that NONE of this will work on current handsets, so that objection
should be taken off the table.  You are going to be doing firmware
updates / new handsets to do even the basic binary capability anyway, so
might as well do the right thing rather than hack something for handsets
that will only be used in the lab.

Remember, the average time for a draft to go from -00 to RFC is 3 years.
That is two whole generations of phones...

-----Original Message-----
From: Engelsma Jonathan-QA2678 [mailto:Jonathan.Engelsma@motorola.com]=20
Sent: Monday, March 27, 2006 3:46 PM
To: Brian Marquette; Burger, Eric
Cc: dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

Guys:

Sorry for not responding sooner, I was out of the office last week
without email access.  Thanks for all the excellent feedback. =20

Yes, SIGCOMP or something equivalent would be desirable. For voice
content that returns a fair amount string data (e.g., n-best results)
this would likely yield more compact messages than the current binary
format, even when encoded in an XML format.

However, while this is fairly straightforward to support from the server
side, things aren't quite so easy on the terminal side.  For low to
mid-tier handsets, SIGCOMP would have to be supported as a firmware
service.  While that may very well happen in the future, there are
millions of handsets out there today that do not support it, and many
more that will ship in the future that won't either.  In terms of
alternatives, some of Motorola's handsets provide a proprietary zip
capability to J2ME developers, but in general, as far as I know this
sort of capability is not widely available to middleware and/or
application developers across handsets.  A third option would be to
implement a compression library and include it with the multimodal
application, however this increases the application's footprint which is
not a good thing in terms of over-the-air downloads, not to mention the
impact on performance (at least in the case of Java).

We are open to SIGCOMP, gzip, etc., where possible, but one of our
requirements is to be able to implement the protocol on the terminal
without requiring compression.  We realize there are trade-offs here, as
Eric has pointed out, but we see enormous utility in keeping the
protocol simple and compact enough to be implemented on handsets and
wireless networks that are widely available today.

-jre

-----Original Message-----
From: Brian Marquette [mailto:BMarquette@sandcherry.com]=20
Sent: Tuesday, March 21, 2006 6:45 PM
To: Burger, Eric
Cc: dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

I am VERY interested in SIGCOMP, and I know Jonathan Engelsma at
Motorola is as well. We should definitely strongly consider that as an
option.  I will also do some reading on EMMA. Currently we are using
NLSML, which I think EMMA replaces.

=20

-----Original Message-----
From: Burger, Eric [mailto:EBurger@cantata.com]
Sent: Tuesday, March 21, 2006 1:39 PM
To: Brian Marquette
Cc: dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

I would offer that XML with SIGCOMP, TLS/gzip, or another
transport-layer compression scheme will be on the same order of a binary
protocol; when you start passing n-best lists I will bet megabucks that
the binary protocol will be LARGER than XML.

On the n-best responses, I would offer that if you are interested in
n-best, you are interested in EMMA.  "Translating" it to DMSP is
guaranteed to miss some critical parameter for somebody's application,
is error prone, uses resources unnecessarily, and does not have any
benefit.

-----Original Message-----
From: Brian Marquette [mailto:BMarquette@sandcherry.com]
Sent: Tuesday, March 21, 2006 3:22 PM
To: Burger, Eric; dmsp@ietf.org
Subject: RE: [Dmsp] Comments on draft-engelsma-dmsp-01.txt

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.=20

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.=20

Brian
=20

-----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

_______________________________________________
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

From dmsp-bounces@ietf.org Tue Mar 28 10:00:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOFgL-0000iJ-MR; Tue, 28 Mar 2006 10:00:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFgK-0000iE-E9
	for dmsp@ietf.org; Tue, 28 Mar 2006 10:00:28 -0500
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOFgJ-0006XM-77
	for dmsp@ietf.org; Tue, 28 Mar 2006 10:00:28 -0500
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2SFGR9f025456
	for ; Tue, 28 Mar 2006 08:16:27 -0700 (MST)
Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25])
	by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k2SFGgES013176
	for ; Tue, 28 Mar 2006 09:16:43 -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: Tue, 28 Mar 2006 10:00:26 -0500
Message-ID: <6806C66D71ED9241BAECC0478173B71F6DEE3B@de01exm69.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: March 29 Telecon reminder
thread-index: AcZSeFkDIRbPRwzRRQiNTzs3IzFbcw==
From: "Engelsma Jonathan-QA2678" 
To: 
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [Dmsp] March 29 Telecon reminder
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

Hi all,

Here are dialing details for the DMSP telecon tomorrow.

Time: Wednesday, March 29, 2006, 10:00am Eastern.

US/Canada: +1-877-283-2663
France: 0800941694
Germany: 08001014510
Italy: 800781687
Japan: 00531160347
Norway: 80057408
UK: 08006920816
Other: +1.416.621.1671

Passcode: 0986279

Chris Cross will be providing the group an update on the reaction to his
DMSP presentation at the IETF meetings last week.

Regards,
-jre

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

From dmsp-bounces@ietf.org Wed Mar 29 11:23:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOdRy-0004vE-FT; Wed, 29 Mar 2006 11:23:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdRx-0004v9-Hz
	for dmsp@ietf.org; Wed, 29 Mar 2006 11:23:13 -0500
Received: from motgate5.mot.com ([144.189.100.105])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdRw-0004Rn-6f
	for dmsp@ietf.org; Wed, 29 Mar 2006 11:23:13 -0500
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234])
	by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k2TGYW5q015880
	for ; Wed, 29 Mar 2006 09:34:32 -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 k2TGYB9i001865
	for ; Wed, 29 Mar 2006 10:34:12 -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: Wed, 29 Mar 2006 11:23:11 -0500
Message-ID: <6806C66D71ED9241BAECC0478173B71F6DF2EA@de01exm69.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: meeting notes from 3/29/06 telecon
thread-index: AcZTTRKcAa3XubgaRWSoLsIKpV8bng==
From: "Engelsma Jonathan-QA2678" 
To: 
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Subject: [Dmsp] meeting notes from 3/29/06 telecon
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

Notes from March 29, 2006 DMSP Telecon

Present:

George Refseth, Opera
Chris Cross, IBM
David Pearce, Motorola
Jonathan Engelsma, Motorola
Andrew Wahbe, VoiceGenie

Chris reported on the IETF meetings he attended last week where he gave
a DMSP presentation at both the Apps and RAI Area meetings.=20

Positive response in general with regard to the need for this sort of
protocol.  Some concerns of possible overlap with existing activities
were voiced in both meetings.  From the widex WG in Apps, and one of the
SIP WG's in RAI.  Chris' impression was that the work fits best in RAI,
as the domain is related to SPEECHSC's which is in RAI.

Next steps are to continue to dialogue with contacts Chris made at IETF
meeting (preferably on the mailing list) and to hold a BoF at the next
IETF meeting.  (July in Montreal)

The group had a fair amount of discussion on Eric Burger's suggestion on
the list that on average it would take 3 years to go from -00 to RFC,
and we ought not contrain the specification with current mobile
handset/network limitations.

Chris suggested it really depends on what the group's goals are - i.e.,
if there is concensus for getting to RFC sooner, it can be accomplished.

David concurred and indicated it took less than a year for the DSR RTP
payload specs to go from draft to RFC.=20

Andrew suggested it really depends on the nature of the draft - i.e.,
payload spec is relatively simple.  Andrew felt DMSP is similar to MRCP
in terms of the level of complexity, and would likely take as long.

It was noted that there were tradeoffs here.  In general, even if it
takes longer, a specification based on broader participation that is
widely adopted is definitely preferred over an RFC few actually
implement.=20

The group agreed to have its next telecon on April 19, 2006, 10AM
Eastern.

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