Subject: RE: [Sipping] I-D ACTION:draft-culpepper-sipping-app-interact-re qs-00.txt

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 17 Apr 2002 16:11:54 -0700

Just to provide a break in the monotony of Subject fields ...

Jonathan,

 I've given some more thought to a couple of your requirements:

> * The mechanism should allow a device to indicate support for multiple
> user interfaces, and allow the application to select which 
> one is to be
> used
>
> * The mechanism should allow a device to indicate relative preferences
> amongst the various user interfaces
> 

I don't think your requirement adequately answers the questions: what is a
"user interface" and what does it mean to have "multiple user interfaces"?
Assumedly a device normally has only one *physical* interface (be it keys or
display or whatever). Now we all agree that the mechanism must not force the
device's interface to be "taken over" by an application. 

One logical way to define multiple user interfaces or rather "virtual user
interfaces" is to create a virtual instance of the physical instance that is
active when the application/session is in focus to the user (much in the way
a multiline SIP phone may work). There are other approaches but most of the
ones I can think of are diminuitive cases of this general approach. In any
case, how this interface is selected or created will largely depend on the
user device and not this mechanism. 

It is my contention therefore, that it should not be a requirement on the
network application interaction mechanism to present multiple (prioritized)
permutations or instances of user interfaces to an application. Rather, the
relevant requirement should be:

* The mechanism should support the identification of a requesting
application identity [e.g. application name+version @ creator's domain] and
application instance [e.g. instance@ service perovider's domain]. 
* The mechanism should the ability for a user interface instance to be
shared between subscriptions (and probably applications when multiple
applications are co-operating). 

This allows a device to create and offer virtual user interfaces as it sees
fit. The application always operates on the "virtual" user interface
instance. This is also a MUCH, MUCH simpler problem - merely one of
identification - not presentation or negotiation (this is a highly
complicated area already). [This approach also allows the device to store
customized application-specific interfaces that can be recalled as required
whenever interacting with the same application.]

Just some thoughts.

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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 01:35:28 -0400

"Fairlie-Cuninghame, Robert" wrote:
> a multiline SIP phone may work). 

THis seems reasonable. 

> There are other approaches but most of
> the

There is a subtle problem here. You indicated that the user needs to put
a particular virtual UI into focus. Doing that is only possible if there
is some display to the user that allows them to know which one it is
they need. This means there has to be a way for the application to
provide some kind of display to the user. THus, it is an issue for the
mechanism. The mechanism has to have a way to provide a display to the
user.

> application instance [e.g. instance@ service perovider's domain].

OK.

> applications are co-operating).

In my model, there is a one-to-one mapping of "subscriptions" to
applications.

> whenever interacting with the same application.]

No - how can the phone create custom UI for an app when it doesn't know
what the app is ahead of time? The app presents the user interface. In
the case of a phone with buttons, that means the app provides labels
that should be associated with some of the buttons. In the case of a
voice recording app, there could be one button that is labeled "start
recording" and another "stop recording". The app needs a way to tell the
phone "label one button with 'start recording' and another with 'stop
recording'. Tell me when one of these is pressed, and tell me which".
The phone can decide whether to use the two top right buttons or the
bottom left buttons; I agree on that. But, the key idea is that the app
is telling the phone information it must render to the user in order to
provide context for the button.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com