In SDM, revocation is possible even when the initiator does not know the endpoint a-priori. When an end-point (final target) receives a revocable delegation request, it registers with the initiator as being interested in receiving revocation notifications. Thus each of such end-points register themselves as DelegationStatusListeners to the initiator. The initiator in turn maintains a list of end-points to whom its delegation has propagated. These end points will implement the NotificationHandler interface, to handle any event notification.
If the end point contacts the initiator every time before servicing a delegated request, then the end point is considered to follow a pure pull mechanism to obtain the status information from the initiator. A common alternative is pure push mechanisms, in which the initiator continually broadcasts out revocation information. Analyses of similar protocols using Broadcast Disks [3] show that pure pull provides extremely fast response time for a lightly loaded server, but as the server becomes loaded, its performance degrades, until it ultimately stabilizes. The performance of pure push is independent of the number of clients listening to the broadcast. But if the number of interested clients (end points) is large, then its a wastage of resources to send irrelevant data. A more serious problem is that the servers might not deliver the specific data needed by clients in a timely fashion. One solution suggested by Zdonik [3], is to allow the clients to provide a profile of their interests to the servers.
In SDM, the clients are the end points who are interested in the revocation status of certain delegations (serviced by those end points). When an end-point receives a delegated request, the first time around it pulls information from the initiator about revocation status and at the same time registers itself to receive delegation-related events. The profiles of those end points of interest in SDM, are the details on whether they require periodic push or aperiodic push. A aperiodic push is event driven - a data transmission is triggered by an event such as data update (in SDM, it is a change delegation status). Hence, end points (and hence, the NotificationHandlers) are notified of any change in delegation or its privileges by the initiator (which might use a helper object that implements EventGenerator interface). A periodic push is performed according to some pre-arranged schedule. The end point, when it registers itself with the initiator, will specify the time interval of periodic updates (pushes). Hence, the initiator will push delegation details at specified time intervals to the registered end points. This leaves it to the end point to specify whether it needs aperiodic or periodic (if so, the necessary time interval) pushes. Thus the end point need not pull information after its initial ``pull'' as the initiator will ``push'' (revocation) data to registered listeners (end-points). Either periodic or aperiodic, this pull-once-push-many approach supports revocation where an end point receives revocation notifications from an initiator.
An end point will decide to specify its interest in periodic or aperiodic pushes from the initiator based on how critical the revocation affects its service and its resources. For example, if the end point is a TelephoneDirectory service then providing information to a requesting delegate (a secretary object) about a revoked number is not very crucial, as the delegate might not misuse the telephone number. In this case, periodic pushes from the service department is not necessary and the end point might settle in for aperiodic pushes only. On the other hand, if the requested service is providing classified information, then the end point needs to know the revocation of the delegate (for example, a secretary object) immediately. In this case, short-interval periodic pushes from the service department may be selected. The load on the server to keep pushing revocation status of its delegates becomes worth its cost when compared to the risk involved in providing classified information to any revoked delegate.