"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:
create-subscription
cancel-subscription
renew-subscription
get-subscription-attributes
get-subscriptions
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?
Yes.
> ...
> 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."