7-May-02SIP/SIPPING Interim Meeting1 Application Interaction Requirements Draft-culpepper-app-interact-reqs-01.txt

7-May-02SIP/SIPPING Interim Meeting2 R5: A network entity desiring user indications must be able to request user indications from another network entity. The entity receiving a request must be able to respond with its capability/intent to transmit user indications. Comment was to change "entity" to "caller/callee" referring to a human. Response was that we're specifying behavior for the protocol agent. New text: The protocol mechanism must provide a means for a network entity to indicate its desire to receive user activity indications and/or to present an application interface on the User's UA. The protocol mechanism must provide a means for a SIP UA receiving a request to respond with its capability/intent to provide the requested services. Is this OK? App Interaction Requirements

7-May-02SIP/SIPPING Interim Meeting3 * The mechanism should support devices that possess a UI, and those which do not possess a UI. Reworded R8: The mechanism should support devices with a wide range of user interfaces for both the presentation-based and input-based interaction modes, for instance, it must support devices that possess a display UI component, as well as those that do not; from devices that only have physical buttons to those that only have display-based pointing devices. * The mechanism should be capable of handling UIs from simple screens with buttons, to voice input. * The mechanism should be capable of handling future user interfaces that may be defined down the road Reworded R10: The mechanism must be extensible so that some non key-based user activity indications can be supported now or in the future, for instance, sliders, dials, switches, local voice- commands, hyperlinks, biometrics, etc. App Interaction Requirements

7-May-02SIP/SIPPING Interim Meeting4 * The mechanism should allow the user to interface with multiple user interfaces for different applications within the same call (for example, a single call may involve a call recording application and a prepaid calling application, both of which might support a UI). Comment: Took this to mean that the mechanism should somehow dictate the user interface of the device. Added R18: The mechanism must support the ability for each user interface component to be associated with a separate virtual user interface. Each virtual user interface may be associated with the same or different applications. For example, a user may want to interact with a voice-recording application and a prepaid calling application within the same call but allow each application to use a different virtual user interface. App Interaction Requirements

7-May-02SIP/SIPPING Interim Meeting5 * The mechanism should allow the user to know which application is associated with which user interface/input. At least one author feel like this is "device rendering" issue, and outside of scope. However, hopefully R17 is sufficient here. R17: The Reporter must be able to identify and authenticate the Requestor for each user interface component. Specifically, in the case where the Requestor is an Application Entity, the User must be able to identify the application name & instance. An application instance consists of the application type [e.g., applications name, version & application designer name] and application instance [e.g., instance identifier & service provider's identity]. * 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. App Interaction Requirements

7-May-02SIP/SIPPING Interim Meeting6 RFC: Described his view of "virtual instance" of a device's physical UI that can be "placed in focus". BC: This is a device "thing" again. JDR: The mechanism must support providing a display. Added 3 new requirements, however they don't specifically state that providing a display is required. R18: The mechanism must support the ability for multiple virtual user interfaces to be associated with the same user session. Each virtual user interface may be associated with the same or different applications. For example, a user may want to interact with a voice-recording application and a prepaid calling application within the same call but allow each application to use a different virtual user interface. R19: The mechanism must support the ability for multiple applications to explicitly cooperate within the same virtual user interface. Specifically, each application may be associated with different UI components within the same virtual user interface. R20: The mechanism must allow user interface components created through this mechanism to be updated or removed as desired by the creating application entity. App Interaction Requirements

7-May-02SIP/SIPPING Interim Meeting7 * The mechanism must allow a user to have assurances that the user input it is providing is only to applications/servers on the call path between caller and callee. Reworder R16: The mechanism must allow for end-to-end security/privacy between the Requestor and Reporter. Specifically, the mechanism must allow the Reporter (if desired) to ensure that transmitted user activity indications can only be viewed by the Requestor. Reworded R17: The Reporter must be able to identify and authenticate the Requestor for each user interface component. Specifically, in the case where the Requestor is an Application Entity, the User must be able to identify the application name & instance. An application instance consists of the application type [e.g., applications name, version & application designer name] and application instance [e.g., instance identifier & service provider's identity]. * The mechanism must work with applications that are both proxy and b2bua. Comment was made that one party must be a user. Again, authors feel that the requirements are for the protocol agent. What's needed here? App Interaction Requirements

7-May-02SIP/SIPPING Interim Meeting8 New "Questions" 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? App Interaction Requirements