"Herriot, Robert" <Robert.Herriot at pahv.xerox.com> wrote:
>>>> - I think you still need "suggested-ask-again-time-interval" and
>> "begin-to-expire-time-interval" to handle the case of really long idle
>> times; for example, when subscribing for Job notifications
>> on a Job with
>> "job-hold-until" specified.
>>Perhaps this case can be ignored. I was hoping to avoid this complexity, and
>I'm not sure if a Printer would want to guarantee to hold on to all Event
>Notifications for several hours. Suppose at noon, someone sets
>"job-hold-until" to 'night' and then at 4pm changes it to 'evening' or
>'no-hold'. If the Printer has told the client to query again at the
>beginning of the 'night' shift or even several hours before night shift, the
>Job may have completed with many Event Notifications by then.
Seems reasonable. Best to keep it simple. If you're submitting a job with
"job-hold-until" you'd be well advised to use a notification different
delivery method like email. But we probably need some way to "expire"
undelivered notifications, so they don't build up indefinitely if clients
go away. Could be a simple, specified maximum guaranteed retention time
for undelivered notifications, or an attribute (settable or not).