IPP> machine readable etc. - why Harry is right

IPP> machine readable etc. - why Harry is right

Herriot, Robert Robert.Herriot at pahv.xerox.com
Thu Aug 24 18:00:32 EDT 2000



> -----Original Message-----
> From: Carl Kugler/Boulder/IBM [mailto:kugler at us.ibm.com]
> Sent: Thursday, August 24, 2000 9:15 AM 
> 
> 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).
> 
>

When I suggested that the Printer not return the
"begin-to-expire-time-interval" attribute, I didn't mean that the Printer
shouldn't have an expiration time for Event Notifications.  Your idea of a
"notify-retention-time" Printer Attribute is what I had in mind. 



More information about the Ipp mailing list