MMUSIC H. Schulzrinne
Internet-Draft J. Lennox
Expires: March 27, 2005 J. Nieh
R. Baratto
Columbia U.
September 26, 2004
Sharing and Remote Access to Applications
draft-schulzrinne-mmusic-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 March 27, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
We describe requirements for accessing general graphical user
interface (GUI) applications remotely, either by a single remote user
or embedded into a multiparty conference.
Schulzrinne, et al. Expires March 27, 2005 [Page 1]
Internet-Draft Sharing September 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Overall Functional and Architectural Requirements . . . . 4
2.2 Input . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Video Output . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Audio and Full-Motion Video . . . . . . . . . . . . . . . 6
2.5 Transport Usage and Requirements . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
5.2 Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Schulzrinne, et al. Expires March 27, 2005 [Page 2]
Internet-Draft Sharing September 2004
1. Introduction
While two-party and multi-party conferencing using standards-based
protocols is now common and well-developed, protocols for sharing
applications are largely proprietary or based on the aging T.120
suite of protocols. In this draft, we summarize some requirements
that a protocol or set of protocols for application sharing should
satisfy.
We note that there are large similarities between remote access to an
application ("remote desktop") and by multiple users sharing an
application within a collaboration setting such as a multimedia call
or multiparty conference.
Remote access differs from the transmission of screen video pixels in
the type of encoding needed. In particular, screen encoding may need
to be lossless and typically operates on artificial rather than
natural (photographic) video input. The video input is characterized
by large areas of the screen that remain unchanged for long periods
of time, while others change rapidly. (However, rendering the output
of a modern computer-generated animation application such as video
games blurs the distinction between traditional motion video output
and screen sharing.)
Unlike earlier systems, such as T.120, we believe that application
sharing should be integrated into the existing IETF session model,
encompassing session descriptions using SDP or successors and the
Session Initiation Protocol (SIP). Application sharing needs many of
the same control functions as other multimedia sessions, such as
address binding and session feature and media negotiation. We
believe that use of the session model is also beneficial for the
remote desktop case, as it allows to re-use many of the
well-developed session components and easily supports hybrid models,
such as the delivery of desktop audio to the remote user.
We distinguish between local and remote users. The local users
employs normal operating system mechanisms to interact with the
running application. Remote users interact via the delivery protocol
whose requirements are outlined here.
The application sharing problem can be divided into four components:
(1) setting up a session to the node running the application, (2)
transporting user input events from the remote viewers such as
conference participants to the application, (3) delivering screen
output from the application to the participants, (4) moderating
access to shared human interface devices such as pointing devices
(e.g., mice, joystick, trackball) and text input (keyboard). We
refer to components (3) and (4) as the "remoting protocol". It is
Schulzrinne, et al. Expires March 27, 2005 [Page 3]
Internet-Draft Sharing September 2004
the focus of this document.
Session negotiation and description can be provided by existing
session setup protocols; user input access can be moderated by a
floor control protocol. Thus, these two components are beyond the
scope of this document, although they are important for an acceptable
overall user experience.
Applications are more than just windows; they are likely a stack of
related windows which serve the same task and are usually associated
with the same process on the server. Some applications impose
special constraints on the user input, e.g., through modal dialogs
and floating (always-on-top) windows.
We believe that filtering what a remote user of a desktop is allowed
to do with their control of an application or desktop keyboard and
mouse input is out of scope; it's the same as the local user.
However, it may be necessary to sandbox applications in some cases,
with sandbox control outside the view of the remoting protocol.
2. Requirements
2.1 Overall Functional and Architectural Requirements
F-1 There are two use cases, namely application sharing and remote
desktop. For application sharing, a user wants to show another
user an application, e.g., to work within the application
collaboratively. For remote desktop sharing, the user wants to
manipulate a desktop or GUI-based application from somewhere
other than where the applications are running.
F-2 Both whole desktops (screens) and applications must be shareable.
Applications may display one or more windows, with the number and
position of these windows possibly changing during the session.
F-3 Any numbers of viewers should be able to watch the same
application or desktop. Evolving floor control mechanisms
determine determine who gets to send input to them and, thus,
negotiation of user input is beyond the scope of the protocol.
F-4 In most cases, applications cannot be modified to work with the
remoting protocol. Thus, application sharing tools intercept
windowing system APIs at some level. Modifications would most
likely be required to applications to allow sending full-motion
video separately.
F-5 Any protocol negotiation occurs at the session setup level, and
is capability-based, not version-based.
F-6 Modular architecture: the components (session negotiation, floor
control, graphical output delivery, user input conveyance) should
be independent so that they can be replaced separately.
Schulzrinne, et al. Expires March 27, 2005 [Page 4]
Internet-Draft Sharing September 2004
2.2 Input
I-1 A desktop or applications might or might not have an actual
monitor, keyboard or mouse attached.
I-2 Input needs to be private, authenticated, integrity-protected,
and access-controlled.
I-3 In most cases, at most one remote user at a time can provide
input; however, remote and local input might occur
simultaneously. The protocol must not restrict the number of
simultaneous input sources.
I-4 The remoting protocol needs to be able to convey user input
hints, such as modal input. (In model input, input focus is
forced into a specific window within a set of windows belonging
to an application.)
I-5 The application should be able to indicate which window has
focus, to allow appropriate rendering of the window decoration at
the remote host.
I-6 Relative timing information for user input may be needed for some
applications, such as video games.
I-7 Internationalization: Two end systems may not have the same kind
of keyboard.
I-8 Open issue: Can copy-and-paste be supported between the
application and the remote user?
2.3 Video Output
V-1 The receiving end system may have a different color depth or
screen resolution than the application host.
V-2 The application video output may consist of different types of
video, some of which may be able to tolerate lossy encoding. For
example, a video streaming application consists of a set of user
interface elements that need to be rendered without distortion,
while the motion video itself may well tolerate some encoding
loss.
V-3 The remoting protocol must be able to convey window layering
hints, such as forcing a window to be always on top.
V-4 Some windowing systems allow semi-transparent windows, with
varying alpha.
V-5 Relative timing information between updates may be needed to
render smooth motion.
V-6 Absolute timing information may be needed to synchronize video
output with other remote-source output, such as audio.
V-7 Since different encoding algorithms have different
efficiency-complexity trade-offs, the remoting protocol must
allow a variety of encoding techniques.
Schulzrinne, et al. Expires March 27, 2005 [Page 5]
Internet-Draft Sharing September 2004
V-8 Two end systems may not have the same set of fonts installed or
available.
2.4 Audio and Full-Motion Video
A-1 Applications that are being shared also must be able to share
audio streams, time-synchronized with the visual aspects of the
application.
A-2 Some applications may also want to send full-motion video
directly from the application, time-synchronized with the GUI and
the audio stream.
A-3 Due to bandwidth constraint, the receiver may choose not to
receive all screen updates. (Example: an area of the screen may
contain full-motion video.)
2.5 Transport Usage and Requirements
T-1 Some remoting applications require perfect reliability, flow- and
congestion control, for both input and output.
T-2 Some applications need to deliver output to a large number of
receivers, possibly relaxing reliability. Thus, support for a
variety of transport protocols, including reliable multicast, is
needed.
T-3 Applications may be remoted across networks with different
bandwidth characteristics.
T-4 Latency, for both input and output, must be minimized to maintain
interactivity.
T-5 The protocol must support both high-latency and low-latency
environments.
3. Security Considerations
Both input and output data may be highly sensitive. For example,
input data may contain user passwords. Thus, encryption of all user
input is likely to be required. For some applications, such as
sharing slides during a public lecture, confidentiality for user
output may not be required. Given the broad set of applications, the
remoting protocol MUST support or be able to leverage end-to-end
confidentiality and integrity protection mechanism.
Application sharing inherently exposes the shared applications to
risks by malicious participants. They may, for example, access
resources beyond the application itself, e.g., by installing or
running scripts. It may be difficult to constrain access to specific
user data, e.g., a specific set of slides, unless the user
application can be run in some kind of "jail".
Schulzrinne, et al. Expires March 27, 2005 [Page 6]
Internet-Draft Sharing September 2004
4. IANA Considerations
There are no IANA considerations for this document.
5. References
5.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
5.2 Informative References
Authors' Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs+mmusic@cs.columbia.edu
URI: http://www.cs.columbia.edu
Jonathan Lennox
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7000
EMail: lennox@cs.columbia.edu
URI: http://www.cs.columbia.edu
Schulzrinne, et al. Expires March 27, 2005 [Page 7]
Internet-Draft Sharing September 2004
Jason Nieh
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7000
EMail: nieh@cs.columbia.edu
URI: http://www.cs.columbia.edu
Ricardo Baratto
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7000
EMail: ricardo@cs.columbia.edu
URI: http://www.cs.columbia.edu
Appendix A. Acknowledgements
TBD
Schulzrinne, et al. Expires March 27, 2005 [Page 8]
Internet-Draft Sharing September 2004
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 (2004). 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.
Schulzrinne, et al. Expires March 27, 2005 [Page 9]