IPP> NOT - 27 ISSUES in Updated IPP Event Notifications spec posted, 7/22/99

IPP> NOT - 27 ISSUES in Updated IPP Event Notifications spec posted, 7/22/99

Michael Sweet mike at easysw.com
Tue Jul 27 08:43:26 EDT 1999


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

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



More information about the Ipp mailing list