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)?
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.
ISSUE 2: Delete previous sentence that says that some delivery methods can
defined to not use some events?
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?
ISSUE 4 - Move SNMP trap delivery methods to another document? Which one?
ISSUE 5 - Which URL parameters should we mention (which like SLP) are
removed before being used?
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.
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.
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.
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?
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.
ISSUE 11 - Add way to the Unsubscribe operation to unsubscribe all
subscriptions? all "my" subscriptions?
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?
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?
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?
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?
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?
ISSUE 17 - Should we copy in the [ipp-prog] Job Progress notification
content into this Event Notification specification?
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.
ISSUE 19 - Should there be more job attributes in the 'job-completed'
notification content, such as "impressions-completed" and
"sheets-completed"?
ISSUE 20 - Should 'job-state-changed' event be REQUIRED to support, since
'printer-state-changed' is?
ISSUE 21 - any other job events to be defined and added?
ISSUE 22 - should any more events be REQUIRED to be supported?
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'?
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?
ISSUE 27 - Waiting for security requirements in the IPP/1.1 Notification
Requirements, such as authorization and authentication for
Renew-Subscription and Unsubscribe.
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Thursday, July 22, 1999 20:43
To: ipp
Subject: IPP> NOT - Updated IPP Event Notifications spec posted, 7/22/99
Mike Shepherd and I have updated the Notification spec according to the
agreements at the IPP WG Copenhagen meeting, 7/7/99-7/8/99 and the
subsequent telecon on 7/14/99:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722-rev.docftp://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.
Mike combined the two specs into one, but the Job Progress Notification spec
is still separate (and not updated, since it hasn't been reviewed at either
the IPP WG meeting or a telecon).
The agreements were posted 7/12/99 at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/notification-agreements-990708.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/notification-agreements-990708.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/notification-agreements-990708.txt
snip...