IPP Mail Archive: Re: IPP> NOT - 27 ISSUES in Updated IPP Event Notifications spec posted,

IPP Mail Archive: Re: IPP> NOT - 27 ISSUES in Updated IPP Event Notifications spec posted,

Re: IPP> NOT - 27 ISSUES in Updated IPP Event Notifications spec posted,

Michael Sweet (mike@easysw.com)
Tue, 27 Jul 1999 08:43:26 -0400

[Sorry - first chance I've had to look at the notification stuff in

"Hastings, Tom N" wrote:
> Here are the issues in the posted notifications spec. Lets start
> the discussion of them on the DL:
> ISSUE 1: Do we need to add a Subscription object that contains the
> "notify-recipients", "notify-events", "subscription-id", and
> "lease-time" attributes (and possibly the opaque subscription
> attribute, if we add it)?

I think we do need subscription objects, but not necessarily as part
of jobs & printers. Looking through the notification stuff it looks
like the current plan is to place "warts" (sorry, I can't think of
a better word for it...) on printer and job objects to support
notification, which will probably make implementation a pain - two
separate places for the notification software to look for
subscriptions, for example.

I would suggest the following alternative:

1. Create a "subscription" object that contains all of the
needed attributes, including printer-uri or job-uri that
associates the subscription with a particular printer or
job URI.

2. Add the following new operations:


3. Support automatic subscription for the create-job, print-job,
or print-uri operations using the current scheme.

4. Add the supported notification attributes and operations to the
get-printer-attributes operation.

The rest of the spec would then apply to the new subscription object
and how #1-4 tie everything together.

> ISSUE 2: Delete previous sentence that says that some delivery
> methods can defined to not use some events?

I don't see a need to limit notifications with any delivery method.
Implementers of clients will likely pick the most efficient method.

> ISSUE 3: For TCP/IP delivery, what about leaving the connection
> open versus having to reestablish a connection for each event? Who
> specifies: client in subscription, Printer implementation,
> Notification Recipient, Administrator?

There are at least two problems with this - notifications may come at
widely-spaced intervals (causes problems with non-permanent links),
and since the IPP notification by itself has no way of telling the
receiver what the total length of the message is (forget the end tag -
it could be lost in transit) a client could find itself waiting
indefinitely for the rest of a message that will never come.

Better to send a single IPP notification and close the link so there
is no doubt on the receiving end that the entire message has been
received or not.

> ...
> ISSUE 6 - Should we add a third operation attribute to Job
> Submission Subscriptions, Subscribe-Job, and Subscript-Printer that
> is an opaque octet-string that is passed to the Notification
> Recipient on every notification, as in Jini? This operation
> attribute would be OPTIONAL for the client to supply and the Printer
> to support.

If we make subcriptions objects of their own, then the subscription
ID or URI should be sufficient to identify things. Adding an opaque
octet-string might complicate implementations as well (what would be
the maximum size, etc...)

> ...
> ISSUE 8 - Should the event sequence number be associated with the
> event (see section 7.1) as in Jini, or with the Subscription object?
> If the latter, then notification batching could happen for the same
> subscription. Then "xxx-trigger-event" could be changed back to
> 1setOf to agree with the "notify-events" operation, Job Description,
> and Printer Description attributes. Then event sequence numbers
> always start with 1 for Explicit Printer Subscriptions, just like
> for Explicit Job and Job Submission Subscriptions and there is no
> need to return the starting sequence number for Printer events.

If we end up with subscription objects, then the sequence number
should/must be local to the object. The whole purpose is for the
client to be able to detect if it has missed an event, and if you
are using a single sequence number for all notifications, the number
will jump between events for different clients or subscriptions...

> ISSUE 10 - Can't we have authentication for subscriptions as we have
> for jobs? Then the owner of the subscription, i.e., the user that
> performed the Explicit Subscription can Renew or Unsubscribe.

It should be possible to renew any subscription; authentication should
be optional based upon the server configuration (just as it is now).

> ISSUE 15 - What happens to the event sequence numbers on Shutdown to
> 'suspend' versus 'power-down'? Are they started over or do they
> continue? What about a power failure? Are subscriptions
> automatically Unsubscribed on power up? What about Restart-Printer
> operation? Or are subscriptions kept across power cycles?
> Subscription Id shouldn't be re-used on power up, if possible. Or
> is either behavior implementation dependent? Any recommendations
> for which?

I think this has to be implementation dependent. It may be impossible
for a printer (or IPP-based printer server) to keep the subscription
and sequence numbers after power is lost.

> ISSUE 16 - Should a notification have a response that the
> Notification Recipient returns to the Notification Source like Jini,
> i.e., a notification is like an operation that has a request and a
> response, instead of just being a one way transfer of information?
> Should that depend on the URL scheme or a URL scheme parameter?

This should depend only on the method. SMTP, HTTP, etc. all require
responses; the ipp-tcp-notify and ipp-udp-notify methods should be
one-way (we're not out to make yet-another two-way protocol - that's
what HTTP is for with IPP!)

> Is having responses a Quality of Service that the subscriber can
> specify?

I don't think so, since most methods automatically define whether or
not a response is forthcoming.

> ISSUE 17 - Should we copy in the [ipp-prog] Job Progress
> notification content into this Event Notification specification?

Yes; make a single, unified notification mechanism. Otherwise IPP
ends up with warts...

> ISSUE 18 - How many individuals, recipients can be established to be
> notified of a particular event? The number of recipients should
> have a minimum number required for support. We did not agree on a
> such a number. This needs more discussion. If the maximum number
> required is 1, then clients might not bother supporting more than
> one recipient in a subscription.

I think this has to be implementation-dependent, but should be at
least 1 recipient per job and printer. We can add an attribute to
the get-printer-attributes operation that tells the client what the
maximum number of notifications/recipients is.

> ISSUE 19 - Should there be more job attributes in the
> 'job-completed' notification content, such as
> "impressions-completed" and "sheets-completed"?

Implementation dependent (put them there, but OPTIONAL.)

> ISSUE 20 - Should 'job-state-changed' event be REQUIRED to support,
> since 'printer-state-changed' is?


> ...
> ISSUE 23 - What meaning do the -added and -deleted job state reason
> attributes have for the 'job-completed' notification? Is that a
> problem? What about other events, besides 'job-config-change'?

This brings up a question I had - what if none of the reasons has
changed? For example, right now we only send out "none" for the
job-state-reasons, so no matter what the job (or printer) state is,
the reasons will never change. How would this be conveyed given that
the -added and -deleted attributes are required?

> ISSUE 24 - Should we copy in the [ipp-prog] Job Progress Job
> Description attributes and notification format into this Event
> Notification specification?

See #17.

> ISSUE 25 - What meaning do the -added and -deleted job state reason
> attributes have for the 'printer-shutdown' notification? Is that a
> problem? What about other events, besides 'printer-config-change'?

See #23.

> ISSUE 26 - Can there be registered event extensions as well as
> private event extensions?

I think we need to allow for both.

Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com
    "Your logic is impeccable, Captain.  We are in grave danger."