3.1.1 Abstract Data Model

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.

This protocol allows a host to propagate participant, application, and window lists and any updates to these lists. Updates to applications, windows, and participant lists are communicated to the clients via the same PDUs that are used to announce the creation of these elements. For instance, if an application title changes, the server sends an Application-Created PDU that corresponds to that application.

A client SHOULD maintain application, window, and participant lists. A client MAY instead choose to use the information in participant, application, and window messages only to display notifications or it MAY completely ignore the messages. For instance, if an application does not want to show the participant list to the user, it MAY silently discard Participant-Created and Participant-Removed messages.

A host MUST preserve each participant's current control level and the status on whether or not sharing is currently suspended.

Because the notifications for both created and updated applications use the same messages, clients SHOULD distinguish between the two. A client does this by checking whether it already has a record for the unique ID associated with the PDU.