open issues
Hierarchical Sub-components
Currently there is no hierarchy between the sub-components. While the
application may maintain a hierarchy, it is supposed to map them to independent
sub-components for transportation over RTP/I. So far we have found no reason
why this may cause problems. If you can think of a case where this may
be problematic, let us know!
Application Level Name Mapping
Currently RTP/I relies on the regular transmission of SUBREPs to announce
the mapping between sub-component ID's and application level names. While
the required bandwidth for SUBREPs is minimal this may prove to limit the
scalability of RTP/I. We are currently investigating this issue. A possible
alternative would be to use something similar to SNAP (used by SRM). However,
we fear that this may make RTP/I overly complex. We would be interested
in hearing your opinion. Maybe there are more alternatives?
Text Based RTP/I Header
Colin Perkins suggested that it might be worthwhile to investigate the
usage of a flexible text based header format for RTP/I. This is what he
wrote:
"I wonder if maybe a text-based packet format might not allow you more
flexibility, without the need for fixed size reserved fields? Maybe something
like an RFC822-style header, where additional header fields
can be defined as extensions? Compressed, if you worry about efficiency?
This format as it stands seems to embed a lot of assumptions about the
needed size of various header fields ..."
What do you think about this?
Enhanced Support for Consistency
In many cases it may be desirable to know the last couple of events
that influenced a state contained in an RTP/I state ADU. For example this
is useful to determine whether an event that arrives simultaneously with
a state is already included in this state. One possible way to support
this is the following: an optional list may be included in RTP/I state
ADUs. Each entry of this list is a pair of a participant ID and the sequence
number of the last event this participant has contributed to the state.
The list contains only entries for those participants that have recently
(to be defined by the medium) contributed to the state by means of an event.
Furthermore delta states should carry the participant ID and the sequence
number of the state they refer to. Any comments on whether this would be
desirable for RTP/I?
Volatile Events
In some media there may be a type of events that do not change the state
of the medium. Those "volatile" events are needed to transport visual cues,
such as dragging an item. Should we consider a fifth ADU type for volatile
events?