"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
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
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
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?
> 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'?
> 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 email@example.com Printing Software for UNIX http://www.easysw.com "Your logic is impeccable, Captain. We are in grave danger."