IPP Mail Archive: IPP> NOT - 17 Issues for the New Proposed Simpler IPP Notification Mod

IPP> NOT - 17 Issues for the New Proposed Simpler IPP Notification Mod

Hastings, Tom N (hastings@cp10.es.xerox.com)
Mon, 9 Aug 1999 23:42:01 -0700

We will process these issues at the IPP telecon, Wed, 8/11/99, and on the
mailing list. I've copied out the 17 issues embedded in the New simplified
IPP Notification Mode and included them in this mail message. These 17
issues are from the IPP New Model specification:

ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990807.pdf

Most of these issues are relatively minor. If there is support for the
basic model, we are making good progress. Then I'll update the IPP
Notification specification accordingly this Wednesday/Thursday, so we will
have it for next week's IETF IPP WG meeting in Alaska.

If we finish these 17 issues, we can look at the spec and resolve any
remaining issues embedded in it:

ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722.pdf

Thanks,
Tom

17 New Issues from the IPP Notification New Model Proposal, 8/7/99
From: Tom Hastings
Date: 8/7/99
File: ipp-notification-issues-990807.doc

ISSUE 1 - is 255 octets too long for "notify-user-data (octetString(255))",
since it also has to be sent in the notification content? How about 64
octets?

ISSUE 2 - Should "notify-exclude-event-masks (1setOf octetString(8))" be
REQUIRED if the number of Notification Recipients supported in a Per-Job (or
Per-Printer) Subscription in greater than 1 (as specified in the Printer's
"max-notification-recipients-supported" attribute)?

ISSUE 3 - why not just "previous-job-state-reasons" instead of
"job-state-reasons-added" and "job-state-reasons-deleted" attributes as Job
Description attributes?

ISSUE 4 - Should we disambiguate the 'job-xxx' events and double the number
by renaming to 'my-job-xxx' and 'all-job-xxx' events for use in both Per-Job
and Per-Printer subscriptions?

ISSUE 5 - Add a 'job-announce' event which is sent to the Notification
Recipient(s) when the subscription is accepted to prepare/warn them?

ISSUE 6 - Add a 'printer-announce' event which is sent to the Notification
Recipient(s) when the subscription is accepted to prepare/warn them?

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.

ISSUE 9 - is 255 too long for "job-trigger-message (text(255))", since it
also has to be sent in the notification content?

ISSUE 10 - How to include user friendly data, like job-name, job-owner,
printer-name, date, time, and event name in a Job event notification?

ISSUE 11 - Should we REQUIRE the "printer-trigger-message" to contain the
user friendly data localized information about this event, namely: like
job-name, job-owner, printer-name, date, time, and event name and REQUIRE
"printer-trigger-message"?

ISSUE 12 - in a Job notification why not just "previous-job-state-reasons"
instead of "job-state-reasons-added" and "job-state-reasons-deleted"?

ISSUE 13 - Most transports only allow 500 to 1000 octets in a packet so we
have too much stuff here.

ISSUE 14 - is 255 too long for "printer-trigger-message (text(255))", since
it also has to be sent in the notification content?

ISSUE 15 - How to include user friendly data, like printer-name, date, time,
and event name in a Printer event notification?

ISSUE 16 - Should we REQUIRE the "printer-trigger-message" to contain the
user friendly data localized information about this event, namely:
printer-name, date, time, and event name and REQUIRE
"printer-trigger-message"?

ISSUE 17 - in a Printer notification why not just
"previous-printer-state-reasons" instead of "printer-state-reasons-added"
and "printer-state-reasons-deleted"?