Subject: [Sipping] Interim discussion of Application Interaction

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sat, 4 May 2002 16:57:26 -0700

Unfortunately I won't be able to make the Interim meeting. Bert Culpepper
will however be present to present our Application Interaction Requirements
draft. It is my hope that we can all reach agreement on the scope and
requirements for this problem space independently of the final mechanism.

The remainder of the email is a collection of comments on Jonathan
Rosenberg's mark-up draft (as I will be unable to present them personally at
the Interim).

I believe that the need for an application to use HTML (and other mark-ups
such as VOiceXML) for user interaction is not in dispute - HTML is a well
established technology with many browsers and tools available. However,
application interaction of the sort that we are proposing is quite different
to the normal pull-style "web browsing" which HTML is most commonly used
for. Specifically, there is a need for any application to update or close
user interface components created through this framework. So whilst I think
the draft is necessary and applaudable in addressing how mark-ups are used
for application interaction, I believe it needs to address these issues. 

I also believe that it still needs to be demonstrated that mark-up is the
best tool for representing non-trivial input-based user interface
components. The draft only presents DML (DTMF mark-up language) and
postulates that it is easily extensible to any interface component. DML is a
very trivial example: most applications will want to receive all supported
stimuli (i.e., all 12 keys), there are no initial states reported, button
states are binary where only one state is actually reported (depressed),
stimuli-generators (buttons) have no properties, stimuli do not have
parametric information (an example of this information could be current
state, time of occurrence or length) and all constituent buttons are known
beforehand (no user or device specific buttons). Additionally, there is no
mechanism whereby an application can request on-demand information about
individual physical stimuli-generators (e.g., current state or property
information) [which extends beyond was is reasonably definable as CC/PP]. 

These issues need to be addressed and mark-up needs to shown as a reasonable
solution to these more general problems. 

In the requirements document, we have divided user interface components into
three broad categories: media-based components (SIP SDP sessions),
presentation-based components (where the application presents its own
interface to the user, e.g. HTML or VoiceXML) and lastly input-based
components (where the physical interface is a property of the device not the
application).  Mark-up fits very well with presentation-base components but
I am yet to be convinced that beyond trivial, pre-determined interfaces
(such as a simple dialpad) that mark-up is the best approach to input-based
UI components. 

Regards,

Robert.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 6 May 2002 06:16:08 -0700

With regard to input-based app interaction, I would really like to see the
following questions answered by the SIPPING community in general:

a) Are people sufficiently interested in pursuing and solving the more
general problem of representing input-based UI components beyond the simple
telephone DTMF dialpad at all?

b) If so, do we want only one general key-based interaction mechanism where
DTMF dialpads are simply a particular key-instance within that mechanism; or
do people want multiple mechanisms: a very, very simple mechanism to just
handle DTMF (such as DML) and a more general (and possibly largely
unrelated) mechanism to represent more complex and dynamic input-based
components? 

The answers to these questions will guide how we all proceed in this area.

Regards,

Robert.

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: 05 May 2002 00:57
> To: [email-masked]'; [email-masked]
> Cc: 'Bert Culpepper'
> Subject: [Sipping] Interim discussion of Application Interaction
> 
> 
>

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 6 May 2002 06:33:43 -0700

Just to re-iterate: The questions I ask are *not* referring to media-based
or presentation-based application interaction mechanisms (covering for
instance voice, video, HTML, VoiceXML, etc) but rather to how we should
proceed in tackling input-based interaction (interaction stemming from the
use of physical interfaces such as dialpads, keyboards or device- & user-
specific buttons such as a "Transfer" or "Double Latte", volume controls,
etc).

Robert.

> Sent: 06 May 2002 14:16
> To: [email-masked]; 'Rosen, Brian'
> Cc: 'Bert Culpepper'
> Subject: RE: [Sipping] Interim discussion of Application Interaction
> 
> 
>