IPP Notification Issues, 7/22/1999, with suggested resolutions
From: Tom Hastings
File: ipp-notification-issues-990727-xr.doc
Date: 7/27/1999
I've added some suggested resolutions to all of these issues, preceded
by XR>. These suggestions have been generated by Pete Zehler, Mike
Shepherd,
Ira McDonald, Xavier Riley, Carl-Uno Manros, and myself.
We have also indicated agreements with Michael Sweet's 7/27 comments as
appropriate.
Here are the collected issues that are embedded in the "Internet Printer
Protocol/1.0 & 1.1: IPP Event Notification, 7/22/1999, that was posted
at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722-rev.pdf
Keith Moore wanted to see something as an Internet-Draft. Lets discuss
at next week's IPP telecon, 7/28/99, whether to make this one an
Internet-Draft. It has 27 issues highlighted in yellow in the .doc and
.pdf files.
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)? The Subscription object is contained in the Printer or Job
object for each Explicit Printer or Job subscription created. In the
case of Job Submission Subscription, the Subscription object is
degenerate and the Job has only the "notify-recipients" and the "notify-
events" attributes. The subscription-id is used in operations on the
Subscription object, in addition to the Job or Printer object target.
XR> Yes. See separate mail from Michael Sweet and response on 7/27/99.
We like the idea of adding Create-Subscription, Cancel-Subscription,
Renew-Subscription, Get-Subscription-Attributes, and Get-Subscriptions.
However, instead of having a subscription-uri as the means to target a
Subscription object, we suggest that the Subscription object is always
created as a contained object of the Printer object (just like Job
objects), and is uniquely identified by that Printer's "printer-uri
(uri)" and the "subscription-id (integer (1:MAX))" pair. Part of
Create-Subscription is to associate the Subscription object with the
containing Printer and/or one of the contained Job objects. Part of the
create job operations (Create-Job, Print-Job, Print-URI, Validate-Job)
is to associate the Job with one or more previously created
subscriptions and/or one supplied pair of subscription attributes.
ISSUE 2: Delete previous sentence that says that some delivery methods
can defined to not use some events?
XR> Yes. We can always add the sentence back if there is every a
delivery method that is restricted for some reason by definition.
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?
XR> We believe that we should use existing application level protocols
for delivering notifications: HTTP, SMTP, and SNMP. These layer on
TCP/IP, TCP/IP, and UDP, respectively. We can write a simple MIB as a
separate RFC that has only the SNMP trap bindings to the IPP
notification content.
ISSUE 4 . Move SNMP trap delivery methods to another document? Which
one?
XR> We believe that we should use existing application level protocols
for delivering notifications: HTTP, SMTP, and SNMP. These layer on
TCP/IP, TCP/IP, and UDP, respectively. We can write a simple MIB as a
separate RFC that has only the SNMP trap bindings to the IPP
notification content.
ISSUE 5 - Which URL parameters should we mention (which like SLP) are
removed before being used?
XR> So far we have no URL parameters. Remove this issue until we do
have URL parameters.
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.
XR> Yes. To answer Michael Sweet's concern, the attribute has a limit,
as with any attribute. We suggest that the operation attribute be named
"subscription-info (text(255))", since its purpose is for the subscriber
to pass information about this subscription to the Notification
Recipient. Then the Notification Recipient can be a general recipient,
such as Tool Talk, that in turn forwards notifications to users.
ISSUE 7 - Rather than adding the Subscribe-Job operation (and possibly
corresponding Renew-Job-Subscription and Unsubscribe-Job-Subscription
operations), why not go back to the original proposal that has a 1setOf
collection for the create job operations. The collection contains the
two simple "notify-recipients" (1setOf uri) and "notify-events (1setOf
type2 keyword). We could say that only one collection value is
sufficient for conformance to help the low end. Supporting additional
values would give the same functionality as the Subscribe-Job operation,
but would happen when the job was submitted.
XR> There is no need for 1setOf collection with the proposed Create-
Subscription operations. A client can create multiple instances of
subscriptions and then bind them in the create job operation using a
"subscription-ids (1setOf integer(1:MAX)) operation attribute.
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.
XR> We agree with Michael Sweet, that the Subscription object should
contain the sequence number. Xavier says that the Jini notification can
be used to implement a sequence number that is associated with the
subscription, instead of the event, using the opaque object that is
supplied by the client when creating a Jini subscription.
ISSUE 9 - A "printer-uri" plus "subscription-id" isn't enough to target
an Explicit Job Subscription? Do we really need both Renew-Printer-
Subscription and Renew-Job-Subscription, both which require a
"subscription-id", but the former has a Printer object target and the
latter has a Job object target?
XR> No. Only need the new Renew-Subscription operation on the
Subscription object which can be associated with either the Printer
object or the Job object.
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.
XR> Yes. Just the same as for jobs, i.e., implementation-dependent.
ISSUE 11 - Add way to the Unsubscribe operation to unsubscribe all
subscriptions? all "my" subscriptions?
XR> No, we don't think it is necessary to add a Purge-Subscriptions
Printer operation. A client can read all subscriptions using the new
Get-Subscriptions operation and could implement an Unsubscribe ALL
itself. Also the data type of the "subscription-id" is integer(1:MAX),
so we'd have to have an out-of-band value or special 0 or negative value
to mean all. Ugh!
ISSUE 12 - 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. Or does the lease and sequence number concepts mean that
only operators need to be able to Unsubscribe?
XR> Yes. And, like Get-Jobs, if the client doesn't supply "my-jobs",
then the Printer treats it the same as if the client supplied 'false',
i.e., all subscriptions, subject to the security policy in force (which
may require the user to be authenticated as an operator to access other
user's subscriptions).
ISSUE 13 - A "printer-uri" plus "subscription-id" isn't enough to target
an Explicit Job Subscription? Do we really need both Unsubscribe-
Printer and Unsubscribe-Job, both which require a "subscription-id", but
the former has a Printer object target and the latter has a Job object
target?
XR> No. We only need the new Cancel-Subscription operation that works
on Subscription objects whether they are associated with the Printer
object or the Job object (or not associated yet with either).
ISSUE 14 - Do we need a Get-Printer-Subscriptions operation that
returns a list of explicit subscriptions to the Printer object? Jini
has such an operation. This operation could be used by a client that
has forgotten the subscription id of a long standing subscription. On
the other hand, the lease concept was introduced to eliminate the need
for a Get-Printer-Subscriptions operation. Also the sequence number
mechanism also helps with filtering out duplicate subscriptions that
send the same event more than once, since the same sequence number is
send in each. If we do add a Get-Printer-Subscriptions operation, then
probably need to include a "which-subscriptions" operation attribute
with values: 'my-subscriptions' and 'all-subscriptions', just like Get-
Jobs?
XR> Ok, as long as it is OPTIONAL for a Printer to support, so that an
implementation can use a subscription service that does not offer a
query service. Change the name to agree with Michael Sweet's proposal
and call it Get-Subscriptions, analogous to the Get-Jobs Printer
operation.
ISSUE 15 - What happens to the event sequence numbers on Shutdown to
'suspend' versus 'power-down'?
XR> Subscription Ids are like job-ids, they SHOULD NOT be re-used
across power-down (or suspend).
Are they started over or do they continue?
XR> They SHOULD continue. So the next Subscription ID to be assigned
by the Printer SHOULD be in non-volatile RAM (or disk), so that the
Subscription ID doesn't match the value of a stale subscription that a
Subscriber or a Notification Recipient still thinks is valid.
What about a power failure?
XR> The next Subscription ID value to be assigned to Subscriptions by
the Printer SHOULD be kept in non-volatile RAM.
Are subscriptions automatically Unsubscribed on power up?
XR> No. Subscriptions, like Jobs, SHOULD be persistent. However, from
SNMP experience, allow the client when creating the subscription to
indicate whether the Subscription is to be persistent or not. Most
clients will indicate not.
What about Restart-Printer operation?
XR> No.
Or are subscriptions kept across power cycles? Subscription Id
shouldn't be re-used on power up, if possible.
XR> Subscriptions SHOULD be kept across power cycles, just like jobs.
However, from SNMP experience, allow the client when creating the
subscription to indicate whether the Subscription is to be persistent or
not. Most clients will indicate not. Job Subscriptions SHOULD be
automatically saved with the job on disk.
Or is either behavior implementation dependent?
XR> yes.
Any recommendations for which?
XR> RECOMMEND (but not REQUIRE) that subscriptions, like jobs, be
persistent across power cycles and that clients can request that they be
persistent or not.
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? Is having responses
a Quality of Service that the subscriber can specify?
XR> No. The IPP WG should not invent another application layer protocol
for delivery of notifications. Use HTTP (over TCP/IP), SMTP (over
TCP/IP), or SNMP (over UDP). The lower layers give responses or not
depending on the lower layer. See answer to Issues 3 and 4.
ISSUE 17 - Should we copy in the [ipp-prog] Job Progress notification
content into this Event Notification specification?
XR> No. Keep it as a separate 8-page spec and RFC. Progress them
together. Reference each document from the other. The IESG doesn't
like long specs. Keith Moore indicated 30-40 pages at most.
ISSUE 18 - How many notification recipients can be established to be
notified in a single subscription? The number of recipients should have
a minimum number required for support. What about the number of events
in a single subscription? 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.
XR> We agree with Michael Sweet that we need "subscription-max-events"
and "subscription-max-recipients" Printer Description attributes. Also
need error status codes: 'client-error-too-many-recipients' and
'client-error-too-many-events'. Since we currently have disjoint
errors, there is more of a need for multiple errors in a single
subscription. For example, we have 'job-created', 'job-state-change',
and 'job-completed' triple, same for Printer events. We suggest that
the minimum number the MUST be supported be 5 events and 1 Notification
Recipient per Subscription object.
ISSUE 19 - Should there be more job attributes in the 'job-completed'
notification content, such as "impressions-completed" and "sheets-
completed"?
XR> Yes. We agree with Michael Sweet. They will help job statistics
applications and these attributes are so basic. These attributes are
OPTIONAL for support, but they are REQUIRED in the notification content
if the implementation supports these Job Description attributes. So
there will be two different Job Notification Contents in this spec: One
for 'job-state-changed' events and one for the other events.
ISSUE 20 - Should 'job-state-changed' event be REQUIRED to support,
since 'printer-state-changed' is?
XR> We agree with Michael Sweet: Yes.
ISSUE 21 - any other job events to be defined and added?
XR> No.
ISSUE 22 - should any more events be REQUIRED to be supported?
XR> The 'printer-almost-idle' Printer event MUST be supported if the
Printer is a non-spooling printer and supports notification. The
'printer-no-longer-full' MUST be supported if the Printer is a spooling
printer and supports notification.
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'?
XR> We could have two different notification content formats, one for
'job-state-change' and the other for 'job-completed'. The former would
include the "job-state-reasons-added" and "job-state-reasons-removed"
attributes and the latter would have the "impressions-completed" and
"sheets-completed". Clarify that if no state changes have occurred,
that the 'none' value is supplied.
ISSUE 24 - Should we copy in the [ipp-prog] Job Progress Job Description
attributes and notification format into this Event Notification
specification?
XR> Yes, but it will add 8 pages to the spec, ok?
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'?
XR> Discuss.
ISSUE 26 - Can there be registered event extensions as well as private
event extensions?
XR> Yes. We agree with Michael Sweet on this. So clarify this. Also
that the notification content can contain additional attributes, so
replace the sentence on line 868 with a positive indication that an
implementation can include additional attributes, as is allowed in SNMP
traps.
ISSUE 27 - Waiting for security requirements in the IPP/1.1 Notification
Requirements, such as authorization and authentication for Renew-
Subscription and Unsubscribe.
XR> A subscription should be an object that is created just like a job
object. It should have an owner, just like jobs. It should also be
authenticated like jobs.
However, need more thought on the privacy of the notifications and the
authorization of subscribing for Notification Recipients.