I have updated the Notification proposal from the Internet Draft version
resolving the issues as agreed to at the IPP September 1, 1999 telecon. The
revision marks show those changes:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990909.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990909.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990909-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990909-rev.pdf
Also there are a few more issues that have been added that need resolution
so that there are 8 outstanding issues. They will be discussed at the
upcoming IPP telecon, Wednesday, 9/15, at the IPP WG meeting, 9/22-23, and
on the mailing list.
The major work left for notification is the separate notification delivery
specifications, one for each method.
A separate mail message suggests how to make the Per-Job notification
mechanism almost identical to the Per-Printer notification mechanism, now
that we have agreed that both are REQUIRED if doing notification.
Here are the 8 issues:
ISSUE 1: Once a number of delivery solutions have been developed and
evaluated, we may want to make one or several of them REQUIRED for
implementation to ensure a minimum set of interoperability. Which one or
ones should be REQUIRED?
ISSUE 2 - Should "notify-content-type (mimeMediaType)" be changed to
notify-content-type (type2 keyword), with values: 'human-consumable' and
'machine-readable'? Then content types that are neither 'application/ipp'
or 'text-plain; charset=utf-8' could be handled without having to be
registered. For example, the 'snmp-ipp' is a trap MIB Machine Consumable
format wouldn't not need to be registered (or have some special rule since
the 'snmp-ipp' value doesn't have a registered MIME type and doesn't fit
either 'application/ipp' or 'text/plain'. Another advantage is that the
charset would always be indicated in the "notify-attributes-charset"
attribute, even for plain text.
ISSUE 3 - There is no good way for a client to discover which
"notify-content-type" values are supported for each delivery method
"notify-schemes-supported". Adding "notify-content-type-supported" doesn't
work, since the delivery methods have to be paired with the content types.
Instead, how about only having each scheme support one or the other content
type? Then we don't need "notify-content-type" as all. For the 'mailto'
scheme, we specify it is human-consumable, i.e., text, and then register a
'mailto-ipp' scheme which is the 'application/ipp' scheme.
ISSUE 4 - Should the Subscription object attributes
"notify-attributes-charset (charset)" and
"notify-attributes-natural-languages (naturalLanguage)" be renames to simply
"attributes-charset (charset)" and "attributes-natural-languages
(naturalLanguage)" so that all IPP requests and objects have the same names?
Then the "notify-attributes-charset (charset)" and
"notify-attributes-natural-languages (naturalLanguage)" would only be
operation attributes that set or reflect the "attributes-charset (charset)"
and "attributes-natural-languages (naturalLanguage)" Subscription object
attributes.
ISSUE 5 - Shouldn't we add a "number-of-printer-subscriptions" Printer
Description attribute, since the client is NOT assured that it can determine
the number of outstanding Per-Printer Subscriptions by doing
Get-Printer-Subscriptions because of access control?
ISSUE 6 - Instead of Create-Printer-Subscription response returning
"notify-lease-time-granted" which is NOT a Subscription object attribute, it
is cleaner for implementation to return the "notify-printer-up-time"
Subscription attribute instead, which is a Subscription object attribute.
The client subtracts the "notify-printer-up-time" from the
"notify-lease-expiration-time" to get the number of second remaining in the
lease, just as it would for a Get-Subscript-Attributes response. OK to
replace the "notify-lease-time-granted" with the "notify-printer-up-time"
attribute in the response?
ISSUE 7 - Should "notify-persistence-granted" be a Subscription object
attribute too, so that all attributes returned in a response are
Subscription object attributes?
ISSUE 8 - Instead of Renew-Subscription response returning
"notify-lease-time-granted" which is NOT a Subscription object attribute, it
is cleaner for implementation to return the "notify-printer-up-time"
Subscription attribute instead, which is a Subscription object attribute.
Ok to replace the "notify-lease-time-granted" with the
"notify-printer-up-time" attribute in the response?