I agree with Harry, that if the spec meets this requirement, it is an
OPTIONAL feature for a Printer to support.
Several questions about this requirement:
How important is meeting this requirement?
Can this requirement be met by specifying for each event a corresponding
standard set of attributes that are appropriate, including some OPTIONAL
attributes that MUST be sent if supported, as in the current spec? And then
allowing additional attributes not in the set to be requested to be sent,
but as an OPTIONAL feature, i.e., an OPTIONAL attribute in the subscription
request that names the additional attributes to be included in the event
report?
What applications would use this OPTIONAL feature? The most compelling
argument is for an accounting application to be able to specify which
attributes to include (in addition to the standard set for the
'job-complete' event). Another might be an operator's application. In both
cases, subscription is done with the Subscribe-Printer operation,
independent of job submission. Thus the optional "notify-event-attributes"
operation attribute would only need to be added to the Subscript-Printer
operation.
Nit,
Since this OPTIONAL attribute is specify the attributes to be sent in the
event report, how about the name "notify-report-attributes", instead of
"notify-attributes" or "notify-event-attributes"?
Tom
-----Original Message-----
From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Tuesday, June 29, 1999 12:56
To: Shepherd, Michael
Cc: Hastings, Tom N; ipp
Subject: RE: IPP> NOT - Requirements not met by the 5/18 Notification
spec
Regarding subscribtion to an arbitrary set of attributes with any job
notification...
>| 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 at us.ibm.com