Bob wrote:
>> -----Original Message-----
>> From: Carl Kugler/Boulder/IBM [mailto:kugler@us.ibm.com]
>
>... snip
>
>> 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).
>
>I assumed that we would use the same "lease" mechanism as in "ippget".
>Unlike "ippget", the Printer doesn't have to try to be intelligent about the
>lease time. It can always pick a small number, such as 30 seconds for all
>leases and assume that the client will perform Get-Notifications within a
>few seconds.
That's fine with me, but I thought the "lease" mechanism in "ippget" used
the "begin-to-expire-time-interval" attribute, which I thought you wanted
to remove. Maybe we need a different (optionally settable) Printer
attribute, like "maximum-guaranteed-notification-retention-time".
Alternatively, we could specify a fixed constant in the standard, similar
to TCP's TTL (maximum "Time To Live", specified as 2 minutes).
Also, [really getting into details now] if we remove the
"suggested-ask-again-time-interval" guidance, we should probably emphasize
that clients should follow the proper HTTP "8.2.4 Client Behavior if Server
Prematurely Closes Connection", which is "binary exponential backoff", so
that Printers in distress don't get overwhelmed with connections.
-Carl
This archive was generated by hypermail 2b29 : Thu Aug 24 2000 - 12:24:43 EDT