We hope that these new issues could be considered as the IPP telecon,
Wednesday, 7/28, 10-12 PDT (1-3 EDT) and on the mailing list. Some of these
issues relate to the new Subscription object proposed by Michael Sweet
Thanks,
Tom
IPP Notification New Issues, 7/22/1999, with suggested resolutions
From: Tom Hastings
File: ipp-notification-new-issues-990727-xr.doc
Date: 7/27/1999
While reviewing the existing spec and issues, the following people have
generated a set of new issues: Pete Zehler, Mike Shepherd, Ira
McDonald, Xavier Riley, Carl-Uno Manros, Armon Rahgozar, Bob Sperry, and
myself. We've labeled the issues using letters to distinguish them from
the issues buried in the Notification spec. In many cases, we've also
suggested resolutions to the issues, preceded by XR>
ISSUE a - Who renews Explicit subscriptions (that are not associated
with a job), the Subscriber or the Notification Recipient?
Subscriptions that are associated with a Job do not need to be renewed
(whether created explicitly or as part of Job Submission), since they
last until the job completes (and are renewed automatically on Restart-
Job and Reprocess-Job).
XR> While it might seem more logical for the Notification Recipient to
renew the subscription, we think that it should be the Subscriber for
the following reasons:
1. Its easier to specify the authentication of the Renew-Subscription
operation if it is either the same entity that subscribed in the
first place or the Operator. Allowing the Notification Recipient
to Renew would require security delegation which is a hard problem.
2. There are two Use Cases: The Notification Recipient is Subscriber
and the Notification Recipient is different from the Subscriber.
In the first case, the issue is moot, since the Recipient and the
Subscriber are the same. In the second case, the Recipient is
receiving "unexpected" notifications. So it should be the
Subscriber that has the obligation to renew Explicit Subscriptions.
Also it is more reliable for the Subscriber to renew; the
Subscriber has to setup some sort of timer to cause the Subscriber
to perform the Renew-Subscription operation before the lease runs
out.
ISSUE b - Should part of any kind of subscription be to send an
"announce" notification to the Notification Recipient(s)? An announce
event is a specific event and would have a sequence-number of '1', since
it is the first notification for this subscription.
Having an announce event would accomplish several things:
1. The path to the Notification Recipient would be tested.
2. The Notification Recipient would be readied for the subsequent
notifications.
Such an announce event MUST be sent before any other notifications are
sent to the Notification Recipient. If there is an immediate event,
then the announce event need not be sent and that firs event would serve
as the welcome event (the sequence-number would be '1').
XR> We think an "announce" event would be a good thing to add.
ISSUE c - If an "announce" event is added, but a notification is not
able to be delivered to the Notification Recipient, what happens? Does
the Subscriber get told in any way?
XR> We think not. The "announce" event can be attempted to be delivered
after the Subscribe has completed and returned its status. So there is
no event or status to indicate the failure.
ISSUE d - When a Enable-Printer or Disable-Printer operation changes the
value of the "printer-is-accepting-jobs" Printer Description attribute,
a 'printer-state-changed' event notification should be delivered. But
how can the recipient tell that "printer-is-accepting-jobs" is the
event?
XR> We suggest that the "printer-is-accepting-jobs" attribute be added
back to the Printer notification, since that attribute is one of the
Printer state attributes.
ISSUE e - How can an end user monitor all the jobs on the system,
assuming that the security policy (such as Get-Jobs) allows all jobs to
be viewed, at least to some degree?
XR> We suggest that the Create-Subscription and associate with the
Printer object NOT require operator privileges, but be under the same
authentication regime as the Get-Jobs operation. So if a user can
perform a Get-Jobs and see other users' jobs, then Create-Subscription
and associate with the Printer object MUST be allowed as well. Then a
user can specify Job events, such as 'job-state-changed', and get all
state changes for the jobs that it can view.
ISSUE f - When subscribing to 'job-state-changed' event with the
Printer, so that all job state changes are sent as notifications, what
happens with changes to the "number-of-intervening-jobs" Job Description
attribute? When a job completes and there are 100 jobs in the queue,
all of the "number-of-intervening-jobs" attribute values are decremented
by 1 for all the 100 jobs. Are 100 notifications sent? One
notification for all jobs? Or no notification?
XR> We suggest that the "number-of-intervening-jobs" be a special case,
in that changes in it do NOT generate a notification.
ISSUE g - If the system gets behind on sending some notifications, then
what happens?
XR> We think that the definition of each event includes whether or not
the system can drop event notifications if it gets behind. For those
events defined not to be droppable, the system sends them when it can.
The 'page-complete' events are droppable, as are the 'job-state-changed'
and 'printer-state-changed'. Notification Recipients that care should
poll as well as use the notification, in case an event is dropped. The
'job-completed' event is not droppable.
Not sure whether events can be sent out of order. At least the sequence
number will help the Notification Recipient untangle re-ordered events.
ISSUE h - With the new Create-Subscription operation, there is an
attribute that the client supplies to associate the Subscription object
with the Printer object or a previously created Job object. Omission of
the attribute means that the Subscription object is not associated with
any object and will be associated with a future Job object when that Job
object is created. The problem is what is the data type of this
attribute passed in the Create-Subscription operation. The attribute
could be "subscription-association (uri | integer (1:MAX)" using the
former data type for associating with the containing Printer object and
the latter for associating with a previously created Job object. Or
there could be two separate attributes: "associate-with-printer
(boolean)", and "associate-with-job (integer(1:MAX))". Then the issue
of which Printer URI works is avoided. But it would be an error for the
client to supply both, if the former as a 'true' value, correct? In other
words, a Subscription object cannot be associated with its containing
Printer and a Job object at the same time, correct?
XR> We suggest the two attributes: "associate-with-printer (boolean)",
and "associate-with-job (integer(1:MAX))".
ISSUE i - A Job object can be associated with more than one Subscription
object, i.e., the "associate-with-subscriptions (1setOf
integer(1:MAX))". But can a Subscription be associated with more than
one Job object? If so then the Create-Subscription attribute would
become: "associate-with-jobs (1setOf integer(1:MAX))".
XR> Not sure.
ISSUE j - With the new Create-Subscription operation, should the
attributes being supplied and set be operation attributes or
Subscription attributes? I.e., should "notify-recipients (1setOf uri)",
"notify-events (1setOf type2 keyword)", "subscription-persistency
(boolean)", "subscription-info (octetString (255))", and either:
"associate-with-printer (boolean)" or "associate-with-job
(integer(1:MAX))" be operation attributes of the Create-Subscription
operation that are copied to Subscription Description attributes, or
should we make them like Job Template attributes that are copied to the
Job object, i.e., Subscription Template attributes? If the latter, then
the Printer automatically has corresponding "xxx-supported" and "xxx-
default" attributes, rather than having to be explicitly defined in the
spec.
XR> Keep them as operation attributes in the Create-Subscription
operation. Then these same attributes are also operation attributes of
the create job operations (Create-Job, Print-Job, Print-URI, and
Validate-Job, except for both: "associate-with-printer (boolean)" and
"associate-with-job (integer(1:MAX))" which are only allowed on the
Create-Subscription operation. The only drawback is that the
corresponding "xxx-supported" and "xxx-default" Printer Description
attributes are defined separately and explicitly, making the spec
longer.