There are 14 issues listed that we will progress at the Alaska meeting.
I'll bring copies and one on transparencies for the meeting.
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990811.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990811.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990811-rev.
doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990811-rev.
pdf
Here are the 14 issues and the Change History:
ISSUE 1 - If IPP is generalized to multi-function devices, will we regret
having "Printer" in the names of these Subscription operations that could
work for any type of device?
ISSUE 2 - Is there value for a Notification Recipient (or other client) to
be able to query the Job and determine the most recent sent Event
Notification and the time (and date-time) that it was sent or should these
three Job Description attributes (job-trigger-event (type2 keyword),
job-trigger-time (integer(MIN:MAX)), and job-trigger-date-time (dateTime))
be removed from the spec?
ISSUE 3 - OK to add the OPTIONAL "notify-natural-languages" (1setOf
naturalLanguage) to the Job object and the Job Creation operations, as long
as it is OPTIONAL for a Printer to support?
ISSUE 4 - It isn't necessary to add a "persistence (boolean)" attribute to
the Subscription object in order to record the value passed in the
Create-Printer-Subscription operation and to allow it to be queried?
ISSUE 5 - OK to add the OPTIONAL "notify-natural-languages" (1setOf
naturalLanguage) to the Subscription object and the
Create-Printer-Subscription operation, as long as it is OPTIONAL for a
Printer to support?
ISSUE 6 - Should we provide a way for the client to get the
"printer-up-time" in a Get-Printer-Subscriptions operation, so that the
client doesn't have to make two requests (like we did in IPP/1.1 for
Get-Job-Attributes and Get-Jobs)?
ISSUE 7 - How is the User Friendly notification represented, such as is used
with the 'mailto:' notification delivery scheme? What parts gets translated
into the Natural Language of the subscriber (presumed to be the same as the
recipient), besides the "job-trigger-message" and "printer-trigger-message"?
The idea of using multipart/report has problems going through firewalls
because of attachments, so maybe we need a single text message that can be
read by humans, and still be parsed by programs for some of the
(un-translated) keywords attribute names. Perhaps, the trigger-message
contains user friendly stuff like job-name, printer-name, and the translated
job-state and state-reasons values and the rest of the message is a series
of lines of the form:
keyword: text
where 'keyword' is the un-translated (i.e., U.S. English) attribute keyword
name and the text is the representation of the attribute values. Which
attributes would be required beside the "job-trigger-message" and
"printer-trigger-message"?
ISSUE 8 - Most transports only allow 500 to 1000 octets in a packet we have
too much stuff.
(There is no ISSUE 9)
ISSUE 10 - Most transports only allow 500 to 1000 octets in a packet so we
have too much stuff here.
ISSUE 11 - or should canceling a Per-Job subscription be done by supplying
the out-of-band 'no-value' value for "notify-recipients" in a
Set-Job-Subscription operation, instead of 'none' to "notify-events", since
"notify-recipients" is the attribute that indicates that there is
notification in a job creation operation?
ISSUE 12 - Ok to have added the OPTIONAL "notify-persistence" (boolean)
operation attribute to the Create-Printer-Subscription operation?
ISSUE 13 - What happens if the client supplies a 0 for the
"notify-lease-time-requested" operation attribute? Does that result in a
canceling of the Subscription? Is that ok? Ok to keep
Cancel-Printer-Subscription operation too?
ISSUE 14 - Ok that Renew-Printer-Subscription doesn't allow any modification
of the Subscription object attributes, except the "notify-lease-time"
attribute? If we need a way to change other attributes would we add it to
this same operation and rename it to Set-Printer-Subscription? Having a
Set-Printer-Subscription operation would allow a client/server to set the
"notify-events" to 'none' and thereby reserve a slot using the lease time,
but not have any Notifications until a subsequence Set-Printer-Subscription
operation was done that set some events.
Changes made from 99/08/07 version to make the 99/08/11 version
The following changes were made from the 99/08/07 version to make the
99/08/11 version as result of the IPP telecon, 99/08/11:
1. Changed the name of the Replace-Job-Subscription operation to
Set-Job-Subscription, since it can add, remove or change Job notification
attributes, not just replace them.
2. Added the configuration pictures.
3. Reduced the size of "notify-user-data" from 255 octets to 63 octets,
since it is also send in the Notification content which has a limit of 480
or so octets on some transports.
4. Changed the conformance requirements for the
"notify-exclude-event-masks (1setOf octetString(8))" operation attributes in
Job creation and Create-Printer-Subscription operations from OPTIONAL to
REQUIRED, since their implementation means that clients can count on it.
Also the minimum number of Per-Printer Subscriptions can be less, since a
client won't be forced to use multiple subscriptions when recipients have
different events. Finally, SNMPv3 has the exclude mask mechanism.
5. Added the OPTIONAL "notify-natural-languages" (1setOf
naturalLanguage) Job Description attribute so that each Notification
Recipient could get a requested natural language, instead of the one in the
Job creation request.
6. Deleted the "job-trigger-message" Job Description attribute from Job
object attribute. The client can localize the remaining Job attributes on
its slow scan in case Notifications are dropped.
7. Added the "notify-request-ids (1setOf integer(0:MAX))" Job
Description attribute to the Job object to indicate (and remember) the most
recent request-id delivered for each Notification Recipient.
8. Deleted "previous-job-state (type1 enum)" and
"job-state-reasons-added (1setOf type2 keyword)" and
"job-state-reasons-deleted (1setOf type2 keyword)" from the Job object. The
"job-state-reasons" value has enough information about why the Job is in the
current state, so that we don't need the previous state and state reasons
for the slow scan polling Notification Recipient that is attempting to
overcome possible dropped Notifications.
9. Added REQUIRED "max-recipients-supported (integer(0:MAX))" Printer
Description attribute to the Printer object to indicate the max number of
Per-Job and Per-Printer Notification Recipients supported in each
subscription. REQUIRE a minimum of 3 recipients.
10. Added the requirement that at least 8 Per-Printer Subscription
object instances MUST be supported, if Per-Printer subscriptions are
supported. With the exclude mask, such a low number as 8 isn't too
restrictive on clients and isn't too expensive for low end devices.
11. Added the OPTIONAL "persistent-subscriptions-supported" (boolean)
Printer Description attribute to the Printer object to indicate whether or
not the Printer supports persistent Per-Printer Subscriptions.
12. Changed the Printer support requirements for the
"notify-exclude-event-mask" (1setOf octetString(8)) from OPTIONAL to
REQUIRED, so that clients can count on it and to reduce the number of
Subscription objects that a Printer MUST support.
13. Added the OPTIONAL "notify-natural-languages" (1setOf
naturalLanguage) Subscription object attribute so that each Notification
Recipient could get a requested natural language, instead of the one in the
Create-Printer-Subscription request.
14. Added the "subscription-id" attribute to the Subscription object so
that each object instance is identified in a manner analogous to Job
objects.
15. Changed the name of "most-recent-request-id" to "notify-request-ids"
for consistency in naming and to be the same as the corresponding Job
Description attribute ("notify-request-ids").
16. Changed the name of the "notify-lease-time-remaining" Subscription
object attribute to "notify-lease-time". Changed the semantics from the
lease time interval requested to the "printer-up-time" (time ticks) that the
lease expires. The client can subtract the "printer-up-time" from the
"notify-lease-time" to find out how much time is left on the lease. This
change makes the attribute value be a constant, instead of having to be
recomputed on each Get-Printer-Subscription-Attribute request.
17. Changed the name of the "notify-lease-time (integer(0:MAX))"
Subscription object attribute to "notify-lease-time-granted
(integer(0:MAX))" and indicated that it is set by the Printer not the
client.
18. Added 'printer-announce' event, so that the Subscriber can have the
Notification Recipient be warned that other Printer events are forth coming.
19. Added 'printer-queue-changed' - so that an application that is
monitoring the queue can re-fetch the queue with Get-Jobs.
20. Added "attributes-charset" and "attributes-natural-language" to the
Job and Printer Notification content, since the content is an
'application/ipp' MIME type for an IPP response.
21. Added "printer-name (name(127))" and "job-name (name(MAX))" to Job
and Printer Notification Content. These are helpful to end users to
identify from whence came a notification.
22. Deleted the "job-trigger-message (text(255))" from the Job
Notification content since the data is already available in other attributes
that the recipient should localize to present to a human. Also the Human
Consumable form will have many of the attributes when it is used.
23. Deleted "previous-job-state (type1 enum)" and
"job-state-reasons-added (1setOf type2 keyword)" and
"job-state-reasons-deleted (1setOf type2 keyword)" from the Job Notification
content. The current "job-state-reasons" value has enough information about
why the Job is in the current state, so that we don't need the previous
state and state reasons.
24. Deleted the "printer-trigger-message (text(255))" from the Printer
Notification content, since the data is already available in other
attributes that the recipient should localize to present to a human. Also
the Human Consumable form will have many of the attributes when it is used.
25. Added [job-id (integer(1:MAX))] and [job-name (name(MAX))] to the
Printer Notification content for when the event is from a Per-Job
subscription.
26. Deleted "previous-printer-state (type1 enum)" and
"printer-state-reasons-added (1setOf type2 keyword)" and
"printer-state-reasons-deleted (1setOf type2 keyword)" from the Printer
Notification content. The current "printer-state-reasons" value has enough
information about why the Printer is in the current state, so that we don't
need the previous state and state reasons.
27. Added "printer-is-accepting-jobs (boolean)" attribute to the Printer
Notification content, since it is a state variable and its change causes the
'printer-state-change' event.
28. Added the definition of the Set-Job-Subscription operation.
29. Changed the name of "notify-lease-time" operation attribute in the
Create-Printer-Subscription operation to "notify-lease-time-requested" to
distinguish it from the "notify-lease-time" (uptime ticks) and
"notify-lease-time-granted" returned in the response.
30. Added the "notify-persistence (boolean)" operation attribute to the
Create-Printer-Subscriptions to indicate whether the notification content
delivery is to make the Per-Printer Subscription be permanent.