Subj: Comments on the Notification Specifications
From: Tom Hastings
Date: 7/10/00
File: ipp-not-comments.doc
1. IPP Event Notification Specification
1.1. Need "job-recipient" (name(MAX)) operation and Job Description
attribute
Section 11.1: After reading some of the delivery methods, it is clear that
when sending a job across a firewall to some other user, the client needs to
be able to specify that person in an operation attribute. The Printer can
then use that attribute to print on the banner page for example. So we need
to add a "job-recipient" (name(MAX)) operation attribute to the Job Creation
operations which the Printer copies to a Job Description attribute of the
same name. If the client omits this attribute, then the Printer assumes
that the "requesting-user-name" operation attribute (which [ipp-mod] says a
client SHOULD supply) is the intended job recipient. Both attributes would
be OPTIONAL to support.
1.2. Add 'job-stopped' and 'printer-stopped' REQUIRED sub-events
Page 20 and 22. After reading the mailto Delivery Method Document, the
'job-state-changed' and 'printer-state-changed' don't work very well for
mailto. There would be too many mail messages send. It would be very
helpful for a user to be able to supply a Per-Job Subscription with either a
'job-stopped' sub-event of the 'job-state-changed' to get a notification
(perhaps by a gateway to a beeper service) when the user's job stopped,
i.e., the job entered the 'processing-stopped' state. Or for the really
eager to supply 'printer-stopped' sub-event of the 'printer-state-changed'
to get a notification when any job (ahead of the user's job or the user's
job) stopped the Printer, i.e., the Printer entered the 'stopped' state.
This latter event would be useful for an operation to supply in a
Per-Printer subscription too, in order to be beeped when to fix the Printer.
Both of these events should be REQUIRED in order for Subscribing Clients to
be able to count on them.
1.3. The "notify-subscription-id" isn't used for 'snmpnotify' Method
Page 36, Table 5: REQUIRES the "notify-subscription-id" to be supported,
but the 'snmpnotify' doesn't. Should we change the MUST to SHOULD?
2. The 'indp' Notification Delivery Method Document
2.1. Notification might become REQUIRED in a future version of IPP
So line 22-23 should say OPTIONAL for IPP/1.0, IPP/1.1, and future versions.
2.2. Table specifying how the Delivery Method Document meets the
[ipp-ntfy] requirements
Table 1 on pages 6-8 lists the requirements from [ipp-ntfy] in column 1 and
how 'indp' meets each requirement. In the 'mailto', section 4 combines the
requirement and the answer into single statements.
2.3. Should we add Notification Recipient Conformance Requirements?
The [ipp-mod] has conformance requirements for clients and Printers, i.e.,
senders and receivers. So shouldn't indp have conformance requirements for
Printers (senders) and Notification Recipients (receivers)?
3. The 'mailto:' Notification Delivery Method Document
3.1. Shouldn't mailto be the REQUIRED Delivery Method?
Line 175, says 'mailto' is OPTIONAL.
3.2. "notify-mailto-text-only" (boolean) always include plain text,
correct?
Lines 198 and 208 seems to allow the 'false' (and default) value to omit
plain text. So do lines 316 and 319.
3.3. Does 'mailto' imply SMTP or not?
Line 218 (and else where) seem to allow 'mailto' to specify other protocols
than just SMTP.
3.4. Syntax of value would allow multiple mailto Notification Recipients
Line 220 and line 300: But [ipp-ntfy] became simpler when we only allowed
one recipient per Subscription. What about retrying some that failed? Gets
much more complicated for the Printer.
3.5. Who adds the date and time? Printer or mail server?
Line 253 says what the Printer MUST include and doesn't need to if the
Printer doesn't support "printer-current-time". However, if the mail server
adds the date and time, then it gets there.
3.6. Subject line should include the Printer's name
For completion, the examples should include the Printer name in the Subject
Line. Then all of the information is in the Subject line, making it much
easier for a user looking at the received mail messages without having to
open them.
3.7. Message body could be the same as Subject line
Also I suggest that the message body be the same as the Subject Line, i.e.,
a simple statement about what happened, not fields with field names and
colons that some Notification Recipients would be tempted to parse.