1.3 Overview
The Print System Asynchronous Notification Protocol serves two primary functions:
A print server sending status notifications to a print client.
A print server receiving the client's response to the notifications.
This protocol has two modes of operation:
In bidirectional communication mode, data can flow in two directions between a server and client. After a client registers with a server, the client requests a bidirectional notification channel from the server. The client uses the channel to request predefined print status notifications from the server. When the client subsequently receives a notification, the client also uses the channel to send a response back to the server.
In bidirectional communication mode, if multiple clients open the same bidirectional notification channel and attempt to respond to the channel's initial notification, the server accepts only the first response received and continues to send further notifications only to the client whose response was accepted. Subsequent exchanges of notifications and responses on the channel take place only between the server and that client. Because bidirectional notifications each require a response, the initial notification intended to be transmitted on a bidirectional notification channel cannot be discarded before a registered client sends a response on that channel (or the channel is closed).
The following diagram shows bidirectional communication.

Figure 1: Bidirectional communication
In unidirectional communication mode, multiple clients can register for the same notifications. The server sends a given notification to all clients that have registered for it. Because unidirectional notifications do not require a response, the server can discard the notifications in the absence of an appropriately registered client.
The following diagram shows unidirectional communication.

Figure 2: Unidirectional communication
Server-resident notification sources create, on behalf of print clients, notification channels to send notifications as printing events occur. Each channel is created to send only a given notification type in a single communication mode, unidirectional or bidirectional.
Each notification channel is created to send notifications to registered clients, irrespective of their authenticated user identity, or to send notifications to the subset of registered clients with associated authenticated user identity matching that of a specific print client. When registering for notifications, clients specify the notification type identifier, communication mode, and user identity filter for the notifications they are interested in receiving.
Unidirectional notification channels are closed only by the notification source that created the channel. Bidirectional notification channels can be closed by the client that acquired the channel or by the notification source that created the channel. The interaction with notification sources is described in 3.1.1.6.
The Print System Asynchronous Notification Protocol is based on the RPC Protocol, and it defines the following two RPC interfaces, which are called by the client and implemented by the server:
IRPCAsyncNotify, which is used to register and deregister clients, establish notification channels, and send data back and forth between the client and the server.
IRPCRemoteObject, which is used to create and destroy remote objects that refer to printers.
This specification also defines the AsyncUI notification type, which exists to support a client component that receives and interprets notifications from server-hosted notification sources, such as printer drivers. The AsyncUI client component can be used to display an informative message, send user input back to the notification source on the server, or trigger the execution of printer driver code on the client computer. The following diagram illustrates the relationship between a notification source and an AsyncUI client.

Figure 3: Relationship between a notification source and an AsyncUI client