IPP> NOT - IPPGET Issue 11: idea to allow Printer to increase server-directed polling time (on a Subscription object basis)

IPP> NOT - IPPGET Issue 11: idea to allow Printer to increase server-directed polling time (on a Subscription object basis)

Hastings, Tom N hastings at cp10.es.xerox.com
Tue Aug 14 19:08:53 EDT 2001


Ron,

I agree with you that it is too complex for a corner use case.  However, it
seemed to be what was needed for an implementation to be able to direct the
client to poll at a slower rate for a period of time and then pick up the
pace again without confusing other pollers for the same Subscription
objects.  So I wanted to write it up, since the server being able to direct
the client to poll at a slower rate until things got interesting, was a
feature of "server directed" polling that Harry was advocating over a year
ago.

In talking with Bob Herriot last night, we came up with a really simple way
to allow an implementation to do this, but without requiring any additional
burden on either the client or the Printer, except if the Printer wants this
capability to be able to regulate the poll rate over time:

1. Its a completely hidden implementation strategy for a Printer to be able
to vary the polling rate over time, i.e., the Printer implements it with
hidden internal Subscription Object attributes.

2. So don't add either "notify-event-life" or "notify-get-interval"
Subscription Description attributes to the Subscription Object.  Indicate,
perhaps in an Appendix, how a Printer could implement this with these two
hidden attributes in the Subscription object.

3. Have the Printer return in the Get-Notifications response, the
"notify-get-interval" operation attribute when the Printer wants to
discontinue Event Wait Mode or the Client didn't request Event Wait Mode (as
we have had in the current ippget spec).  Clarify that the Printer MUST
return the minimum Event Life for any of the Subscription objects being
returned.

That's all!

Perhaps we should add the minimum and maximum interval
("notify-get-min-interval" and "notify-get-max-interval") as operation
attributes returned by the Get-Notifications Response as suggested by Carl
Kugler from our February 2000 version of the this spec, instead of just one
value:

ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000202.doc

Returning both would help with the Printer's that have longer periods during
which their implementations are unable to respond to Get-Notification
requests.  Returning two values would help with Marty's problem of losing
events when the Printer can't respond in a time that the client can predict.

Tom

-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
Sent: Monday, August 13, 2001 16:07
To: 'Hastings, Tom N'; ipp (E-mail)
Subject: RE: IPP> NOT - IPPGET Issue 11: idea to allow Printer to
increase server-directed polling time (on a Subscription object basis)


Tom,

It seems that this is too complex to be very useful.  I would prefer to keep
it simple and just use the Event Life time.  A better solution to reduce
traffic is to make the Event Life time be longer.

I will not be able to attend to conference call tomorrow.

	Ron

-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Sunday, August 12, 2001 11:35 PM
To: ipp (E-mail)
Subject: RE: IPP> NOT - IPPGET Issue 11: idea to allow Printer to
increase server-directed polling time (on a Subscription object basis)


My original proposal sent Friday, has the problem that once the Printer had 
increased the Subscription Object's "notify-event-life" value, it couldn't 
reduce it, since some client might be still using the older larger value and
not perform a Get-Notifications soon enough before an Event's (new lower) 
life expired.  However, this problem can be fixed by introducing two new 
Subscription Object Description attributes, instead of just one:

Subscription Object attribute as before:

  "notify-event-life" - the event life for Events associated with this 
Subscription Object - the Printer can increase its value from the Printer's 
"notify-event-life" value, but can never reduce it (because the Printer has 
no concept of which clients are "listening" to a particular Subscription 
Object's events.

New Subscription Object attribute:

  "notify-get-interval" - the current interval in seconds between successive
events that clients should use.  It can never be lower than the Printer's 
"notify-event-life" which is the minimum for all Subscription Objects, but 
can be lower than its Subscription Object's "notify-event-life", which the 
Printer MAY have increased due to the expectation that events are unlikely 
to happen any sooner than that.  Thus the Printer can raise both the 
Subscription Object's "notify-event-life" and "notify-get-interval", but 
then subsequently lower the latter, as events start to happen again.

For example, a Subscription Object's "notify-events" have 'job-completed' 
and 'job-progress' events, but the job is submitted when there was a long 
job queue, say a 10 minute queue (600 second) queue.  Suppose that the 
administrator has configured the Printer's "notify-event-life" to the 
recommended 60 seconds.  The Printer would return the Subscription Object's 
"notify-event-life" and "notify-get-interval" as 600 in the Job Creation 
operation, instead of just 60.  Then when the job starts processing, (which 
could be before or after 10 minutes), the Printer reduces the Subscription 
Object's "notify-get-interval" down to, say, the minimum of 15 seconds, 
since page completion events are wanted.

However, the Printer still has to keep the events around for the 600 
seconds, since, some hapless client might have just polled the Subscription 
Object moments before the Job started processing and got the Subscription 
Object's "notify-get-interval" value of 600, and so won't know to poll back 
any time sooner.  However, the client that sent the job would poll back 
around the time that the job started processing and would get the page 
completes as they occur.  

Probably, a Printer that increases the Subscription Object's 
"notify-get-interval" wouldn't increase it to the full amount when the Job 
is likely to start, but would increase it to, say, 60%, and reduce it 
further has the time arrives for the job to start, down to the minimum of 
15.

A Printer that didn't want to bother with any of this complication, would 
simply copy the Printer's configured "notify-event-life" to the Subscription
Object's "notify-event-life" and "notify-get-interval" and leave them 
unchanged.

Tom

So here is the complete updated proposal:

1. Rename the Printer's "ippget-event-life" (integer(15:MAX)) to
"notify-event-life" to be parallel (and possibly used in the future with
some other Delivery Method).

2. Add "notify-event-life" (integer(15:MAX)) and "notify-get-interval" 
(integer(15:MAX)) Subscription Description attributes to the Subscription 
Object for use with IPPGET Delivery method (and possibly used in the future 
with some other Delivery Method).  

3. Make these Printer Description attribute and Subscription Description 
attributes REQUIRED for a Printer to support, if it support the 'ippget' 
Delivery Method.

4. By default, the Printer MUST set both of the Subscription Object's
"notify-event-life" and "notify-get-interval" Subscription Description 
attributes from the configured value of the Printer's "notify-event-life" 
attribute.  However, at any time the Printer MAY set the
Subscription object's "notify-event-life" and "notify-get-interval" 
Subscription Description to a higher value, if it suspects
that the events that the Subscription object are waiting for are unlikely to
happen soon.  Once set to a higher value, the Printer can further increase, 
but can never reduce, the Subscription Object's "notify-event-life" 
attribute, but can lower the Subscription Object's "notify-get-interval" 
attribute as the Event liklihood of occurring comes closer.

5. The Printer MUST return Event Notifications until the Subscription
object's "notify-event-life" expires for each Event.  So if the Printer has
increased the Subscription object's "notify-event-life", then the Printer is
promising to return Event Notifications for Events for that Subscription
object for that longer life time (and can never reduce the promise, since
some client may be counting the Events not to expire for that time period).

6. As suggested by Marty, instead of returning the "notify-event-life" as an
operation attribute, return an "event-wait" (boolean) Operation attribute to
the Get-Notification (and Job Creation) Response, which indicates whether or
not the Printer is continuing Event Wait Mode.  This would mirror the
"event-wait" (boolean) Operation attribute that the client supplies in the
Get-Notifications (and Job Creation) request.  If the client supplies
'false' (or omits), the Printer MUST respond with 'false'.  If 
the client supplies 'true', the Printer MUST respond with 'true' or 'false',
depending on whether it is continuing Event Wait Mode or not, respectively.

7. For Get-Notifications response, whether or not the Printer is continuing
Event Wait Mode, the Printer always returns each Subscription object's 
current "notify-event-life" and "notify-get-interval" Subscription 
Description attribute values in each Event Notification Attributes Group.
The client then tries the Get-Notifications for the shortest value returned
for the "notify-get-interval" attribute and can regroup future 
Get-Notifications requests, if the values returned are different for
different Subscription Objects in the same response.

8. For Job Creation responses, the Subscription Attribute Group(s) are
returned, so the Printer includes the Subscription object's current
"notify-event-life" and "notify-get-interval" Subscription Description 
attributes in each group.

Comments?


Here is the ISSUE 11 and notes from the telecon:

ISSUE 11:  Should the Printer return a "end-wait" (boolean) attribute,
rather than a "notify-get-interval" (integer) with the number of seconds to
try again later?

<MJ> Regarding the whole try-again time issue, I don't think the Receiver
     should be sending that, and should indicate the desire to stop or not
     start wait mode with a boolean or a status code.  The Sender can do a
     Get-Printer-Attributes to learn how long events are retained.  The
     Sender knows by when it must issue another Get-Notifications to avoid
     the risk of losing events.  If it isn't in keep-alive mode, the Sender
     must take into account how long it might take to connect, so the
     returning of the number of seconds to wait before trying again is
     misleading.

<TH> Or we could clarify the "notify-get-interval" attribute that the
Printer is returning to be the value of the Printer's 
"ippget-event-life" Printer Description attribute and the client needs to 
take into the account the time to make the connection.

AGREED>  That the "notify-get-interval" operation attribute returned in the
response MUST be at least as long as the value of the "ippget-event-life"
Printer Description attribute.  

NOT AGREED>  However, if the value is greater than the Printer's
"ippget-event-life" value, then a Notification Recipient could miss an event
if it didn't poll at the "ippget-event-life" rate.  What to do?  

We are still debating whether it is possible for the Printer to return a
time to next poll that is ever larger than the Event Life time?  If the
Printer ever returns a larger value, the client could miss an event, unless
the Printer magically increases its Life for that (those) Subscription
object(s).

So is returning a boolean the best the Printer can ever do?



More information about the Ipp mailing list