MMUSIC V. Stirbu Internet-Draft J. Costa-Requena Expires: August 15, 2005 Nokia P. Shrubsole Philips Research February 11, 2005 Requirements for Scalable Remote Access to Applications draft-stirbu-mmusic-scal-sharing-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes the requirements for accessing graphical user interface (GUI) applications remotely, so that devices with different form factors and UI capabilities can scale and adapt the exported UI to their local platform UI look and feel (LAF). Stirbu, et al. Expires August 15, 2005 [Page 1] Internet-Draft Scalable Remote Access to Applications February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Functional and Architectural Requirements . . . . . . . . 4 2.2 Input Requirements . . . . . . . . . . . . . . . . . . . . 4 2.3 Output Requirements . . . . . . . . . . . . . . . . . . . 5 2.4 Transport Requirements . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 8 Stirbu, et al. Expires August 15, 2005 [Page 2] Internet-Draft Scalable Remote Access to Applications February 2005 1. Introduction Recent advances in technology now allow for a wide range of devices to become network enabled. They are usually equipped with one or several network interfaces, usually wireless (i.e. GPRS/WCDMA, wireless LAN, Bluetooth). This makes them ideal for use across varying environments. A mobile phone or a personal digital assistant can at the same time be connected into a home network via the WLAN/Bluetooth interface and to the cellular network via the GPRS/WCDMA interface. Such devices tipically have a rich set of user interface features such as a color display and a graphical user interface used for output and keypad, touch screens or pointing devices for input. These smart devices are intended for a diverse range of purposes and their capabilities can vary considerably; screen ratio, color depth, windowing system with various widget sets, input methods that make the environment highly heterogenous. A user interface may be composed of several widgets, wherein a widget is understood as an element of a user interface that displays information or provides a specific way for a user to interact with an application. Widgets may for instance comprise icons, pull-down menus, buttons, selection buttons, progress indicators, on-off checkmarks, scrollbars, windows, window edges, tongle buttons, forms and any other elements for displaying information, inviting, accepting, and responding to user actions. Therefore, when designing a protocol for accessing graphical user interface (GUI) applications remotely, provisions need to be made for customizing the remoted UI to match the characteristic display style (the so-called look & feel) of a device platform. This is of particular importance for ensuring that the user experience is not compromised from one device to another. The IETF architecture can be implemented on multiple platforms with its own UI framework for controling the rendering of local application(s) UI(s). Each platform has its specific appearance to provide the appropriate user experience. This platform customisation of the UI has to be replicated with the maximum fidelity on the new platform where the UI is remoted. Therefore, the remoting GUI protocol has to ensure a favorable user experience regardless of the underlying viewing platform, so that the user can perceive the GUI as a local application making it intuitively usable. However, existing remote UI protocols, like for instance T.120, do not allow for client devices to adapt a remoted UIs to their capabilities, nor do they allow for a customisation of remoted UI to match the characteristic display style of different remote device platforms. In this memo, we summarize some requirements that a scalable and and adaptive remote UI protocol or set of protocols Stirbu, et al. Expires August 15, 2005 [Page 3] Internet-Draft Scalable Remote Access to Applications February 2005 should satisfy, in order to accomodate both sharing and remote access to applications. Unlike previous systems, such as T120, scalable application sharing should be integrated into the existing IETF session model, encompassing session descriptions using Session Description Protocol (SDP) [1] or successors and the Session Initiation Protocol (SIP) [2]. However, in order to re-use the protocol in other environments such as home networks, we believe that a remote UI protocol should be independent to signalling and discovery mechanisms. The remote UI protocol can use the discovery and session setup service from SIP (i.e. in broadband networks) or other mechanisms, such as defined in the UPnP Remote UI [3] (i.e. in home networks). The remote UI protocol should allow remote users to interact with applications in remote systems. 2. Requirements 2.1 Functional and Architectural Requirements 1. Protocol negotiation is handled at session setup level, and is capability-based. 2. The protocol must have a modular architecture. 3. The protocol must scale to different device classes, where each class represents a particular set of UI capabilities. 4. Applications might not have any means of rendering the user interface directly on the host device. 2.2 Input Requirements 1. The protocol must support client initiated updates to the server in response to local widget events generated by the user. Such events could be triggered from user input such as keys (with various configurations) as well as touch/mouse interaction with drag and drop. 2. The protocol should allow for certain events to be prevented from being sent to the server when they are not relevant to the application. 3. The protocol must not restrict the number of simultaneous input sources. Stirbu, et al. Expires August 15, 2005 [Page 4] Internet-Draft Scalable Remote Access to Applications February 2005 2.3 Output Requirements 1. The application should be able to generate the UI in a descriptive format. For example, the description may define the part and the layout of the screen on the client that is used to render the remote UI or could provide additional styling hints to parts of the UI. 2. The protocol should allow the UI to be rendered on various screen sizes, which could be larger than the maximum visible screen size of the device running the application, without the need for scrolling and/or "magnification glasses". 3. The client should be able to adapt the UI provided by the application to the look & feel of the local platform. 4. Support for smooth updates on clients by facilitating incremental updates of UI data (to avoid always sending fullscreen updates). Incremental updates must support the grouping of server initiated UI updates before they are sent to a client when necessary, as well as supporting fine grain UI updates. 5. The protocol must support server-initiated updates to one or more clients to allow for important notifications from an application to be sent to the user. 6. The protocol must handle collocated AV streams and should allow for them to be integrated within a user interface environment. 2.4 Transport Requirements 1. Some applications require perfect reliability. 2. Some applications may export the UI to a large number of clients, so the posibility for relaxing reliability. 3. The protocol must be able to tolerate limitations in available bandwidth. 4. Latency must be minimised to maintain interactivity. 5. The protocol must have support for authentication and secure sessions. Stirbu, et al. Expires August 15, 2005 [Page 5] Internet-Draft Scalable Remote Access to Applications February 2005 3. Security Considerations Input and output data may be highly sensitive. For example input data may contain user's personal data, such as passwords. At the same time the user needs to be sure that the UI he want to interact with was not tampered. Other applications may not require confidentiality in their UI output. By taking into account the wide range of possible applications, the remoting protocol MUST support end-to-end confidentiality and integrity protection mechanism. 4. Informative References [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998, . [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002, . [3] UPnP Forum, "Remote UI Client and Server V 1.0", August 2004, . [4] Schulzrinne, H., Lennox, J., Nieh, J. and R. Barrato, "Sharing and Remote Access to Applications", Internet-Draft draft-schulzrinne-mmusic-sharing-00 (work in progress), September 2004, . [5] Lennox, J., Schulzrinne, H., Nieh, J. and R. Barrato, "Protocols for Application and Desktop Sharing", Internet-Draft draft-lennox-avt-app-sharing-00 (work in progress), December 2004, . Stirbu, et al. Expires August 15, 2005 [Page 6] Internet-Draft Scalable Remote Access to Applications February 2005 Authors' Addresses Vlad Stirbu Nokia Tieteenkatu 1 Tampere 33720 Finland Phone: +358 7180 60572 Email: vlad.stibu@nokia.com Jose Costa-Requena Nokia P.O. Box 321 NOKIA GROUP FIN-00045 Finland Phone: +358 7180 08000 Email: jose.costa-requena@nokia.com Paul Shrubsole Philips Research Prof. Holstlaan 4 Eindhoven 5656 AA The Netherlands Phone: +31 40 27 42102 Email: paul.shrubsole@philips.com Stirbu, et al. Expires August 15, 2005 [Page 7] Internet-Draft Scalable Remote Access to Applications February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Stirbu, et al. Expires August 15, 2005 [Page 8]