>| 6. When specifying a notification event, a Notification
>| Subscriber must
>| be able to specify that zero or more notification attributes
>| (or attribute
>| categories) be sent along with the notification, when that
>| event occurs.
>
>[Proposal]: For operations Print-Job, Print-URI, Create-Job, Validate-Job,
>and Subscribe, add operation attribute "notify-attributes" (or
>"notify-event-attributes"). To accommodate a different set of attributes
>for each event, it would be a 1setOf keyword for each "notify-events"
>keyword.
>
>[Issue]: Would this be better represented as a collection tying each
>"notify-event" keyword with "requested-event-attributes" 1setOf keyword? Or
>could this be solved without collections by using Bob Herriot's suggestion
>to add a SubscribeJob operation?
I think we should carefully consider the subscription management overhead on a
real time device who's primary purpose is to print vs. the complete flexibility
of allowing the client to subscribe to any arbitrary set of attributes. I prefer
to see "classes" of subscription such as "Completion", "Distress", and
"Progression" with defined attributes in each class (owner, JobID, JobSize,
%Complete...). If we want to define a means for subscription to arbitrary
notification content, I think it should be optional.
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com