IPP> NOT - Agreements to the IPP Notification Model

IPP> NOT - Agreements to the IPP Notification Model

IPP> NOT - Agreements to the IPP Notification Model

Hugo Parra HPARRA at novell.com
Fri Aug 20 13:40:02 EDT 1999


Tom wrote:

> 		13.	Defined the "subscription-id" attribute for use with
> Per-Job subscriptions as being the index of the 1setOf collection, starting
> at '1'.  Then a Notification Recipient can have a unique identification for
> each subscription whether it be Per-Job or Per-Printer, for use in catching
> duplicate or skipped notifications using the "request-id". 
	
If "request-id"s enable recipients to identify duplicate, skipped, and out-of-order notifications associated with the same subscription, and "subscription-id"s identify notification threads associated with the same subscription, shouldn't printers try harder to make subscription ids unique not just across its own subscriptions, but in the network?  I'm not suggesting that printers listen on the wire to try to come up with unique subscription ids, but simply generate them randomly (at least the first one).

If all printers start their subscription ids at '1', recipients are much more likely to get notifications from different printers with matching request ids (consider the scenario where a print server hosts several hundred printers: they all come up and down at about the same time and may experience similar usage patterns).  Recipients will be forced to examine the notification's printer-uri's each time to unequivocally determine the subscription associated with the notification.

-Hugo




More information about the Ipp mailing list