IPP> machine readable etc. - why Harry is right

IPP> machine readable etc. - why Harry is right

IPP> machine readable etc. - why Harry is right

Carl Kugler/Boulder/IBM kugler at us.ibm.com
Thu Aug 24 12:15:28 EDT 2000


Bob wrote:
>> -----Original Message-----
>> From: Carl Kugler/Boulder/IBM [mailto:kugler at 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




More information about the Ipp mailing list