These proposals look real good! Thanks for making the effort.
Several more issues for the IPP Event Notification paper to be added on
to the end of the list:
8. Which notification mechanisms for delivery should we require for
conformance in order to improve interoperability?
9. Should make the "subscriptions" attribute be a Job Description
attribute as well, so that the create operation copies the "subscription"
operation attribute to the job object.
10. As it says on lines 222-223, there are Printer events which are
not Printer MIB alerts. I suggest adding the "event keyword" for Printer
Events after line 274, just like there is for Job Events. Then there can
be other Printer events added in the future that are not Printer MIB
alerts too.
11. Also a client might be subscribing to multiple Printers, so need
to add printer-uri to both Job Events at line 270 and Printer Events
at line 274.
12. For Job events, the notification-recipient needs to know the job-id,
so add the job-id at line 272.
Several issues for the Printer Subscriptions for IPP to add to the
one about unscribing to a non-existent subscription:
2. Should we simplify Subscribe and only allow a single collection
value in the Subscribe operation? Then the error handling is much
easier; if there is only one subscription we can't have one value
succeed and one fail. Also the Printer can add the subscription-id as a
collection member attribute (to the single value).
3. Similarly, why allow multiple Unsubscribe subscription-ids in a single
call? It would also complicate the error return if some succeed and
some fail.
At 14:17 05/15/1998 PDT, Scott Isaacson wrote:
>Since there has been some fairly negative reaction to such a long,
detailed, all rolled up proposal for IPP Event Notifications, I have posted
some very short, overview descriptions of the concept that can be reviewed
in a matter of minutes (not hours or day).
>
>I also removed all features that were specified as "optional to implement"
and raised them as issues of the type "Do we even want to do specify this
feature independent of whether it is optional to implement".
>
>I took the files that Tom posted and simplified and shortened the basic
proposal into an 8 page document called IPP Event Notification (Very
Short) and posted it as:
>
>ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-very-short-980515.doc
>ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-very-short-980515.pdf
>
>I separated out the proposal for new Subscribe/Unsubscribe operations into
a separate 4 page document called "Printer Events for IPP" and posted it as:
>
>ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980515.doc
>ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980515.pdf
>
>I hope that these higher level, less detail oriented overviews are more
palatable to a wide audience and help in the communication process.
>
>
>Scott
>
>
>
>************************************************************
>Scott A. Isaacson
>Corporate Architect
>Novell Inc., M/S PRV-C-121
>122 E 1700 S, Provo, UT 84606
>voice: (801) 861-7366, (800) 453-1267 x17366
>fax: (801) 861-2517
>email: sisaacson@novell.com
>web: http://www.novell.com
>************************************************************
>
>
>
>