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