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
Tue Aug 22 17:19:52 EDT 2000

I like it!

Some minor points:

- In 5. b) the server should terminate the response with a zero-length
chunk, if Transfer-Encoding: chunked.  On receipt of this termination, the
client should close the connection.

- 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.


P.S.  What is the current "ippget" spec?  And is it ipp-get or ipp-poll?  I
found a document called ipp-notify-poll on the outside, that is titled
"ipp-get" on the inside.

"Herriot, Robert" <Robert.Herriot at pahv.xerox.com> on 08/22/2000 02:39:24 PM

To:   pmoore at peerless.com, "McDonald, Ira" <imcdonald at sharplabs.com>
cc:   Harry Lewis/Boulder/IBM at IBMUS, bwagner at digprod.com, ipp at pwg.org,
      "Herriot, Robert" <Robert.Herriot at pahv.xerox.com>, Carl
      Kugler/Boulder/IBM at IBMUS
Subject:  RE: IPP> machine readable etc. - why Harry is right

There is a simple extension to "ippget" that does what Harry wants. I'll
call the solution "ippgetw" for "ipp get and wait"

1. The user subscribes for this Delivery Method in the same way as for
"ippget" but instead uses the "ippgetw" scheme in the

2. The Subscription tells the Printer what Events the listener is

3. The client obtains the Event Notifications by performing the
Get-Notifications operation with the same URL as in the
"notify-recipient-uri". This is just like "ippget" except that Event
Notifications keep coming in the response.

4. The Printer performs the Get-Notifications operation as follows
    a) it finds all Subscriptions associated with the specified
       "notify-recipient-uri" (like "ippget").
    b) it returns all Event Notifications that it is holding for the
       specified Subscription objects (like "ippget"). This means that
       the client doesn't miss any events between the time of Subscription
       and the Get-Notifications operation. This step could be omitted
       if it is OK to lose Event Notifications when the client is not
       performing the Get-Notifications operation.
    c) it returns Event Notifications as they occur (unlike "ipp-get").

5. The Get-Notifications operation terminates in the following ways:
    a) the client closes the connection. The Printer continues to save
       Event Notifications as specified in step 4b) until all Subscriptions
       associated with the "notify-recipient-uri" are canceled.
    b) the Printer closes the connection when there are no longer any
       Subscription Objects for the specified URL (in
       "notify-recipient-uri"), e.g. when a Job completes and associated
       Subscription Objects are removed.
    c) a time-out or failure occurs. The actions are the same as step 5a.

Note: unlike "ippget", the Printer doesn't need to return
"suggested-ask-again-time-interval" or "begin-to-expire-time-interval"
because the client performs the Get-Notification operation as soon as
possible. But according to step b), the Printer does keep Event
Notifications for a short period of time, at least when there is no
connection open.  The Printer need not keep Event Notifications after it
sends them if there is no requirement for two clients to use the same value
of "notify-recipient-uri" and no requirement for a client to get lost Event
Notification by reopening the connection.

More information about the Ipp mailing list