Both Notification documents published on 9/13/99 have the same set of
issues. The Alternative spec that aligns Per-Job subscriptions with
Per-Printer subscription has an additional issue (see 5a below), plus issues
9 and 10 added during the 9/15/99 IPP telecon:
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 5a - Shouldn't we add a "number-of-job-subscriptions" Job Description
attribute, since the client is NOT assured that it can determine the number
of outstanding Per-Job Subscriptions by doing Get-Subscriptions because of
access control and since there are no Job Descriptions attributes associated
with notification.
During the 9/15 telecon, there were four alternatives for Job Description
attributes for notification:
a. "number-of-job-subscriptions (integer(0:MAX))" - the number of Per-Job
subscriptions for this job
b. "job-subscriptions (boolean)" - whether or not this job has any Per-Job
subscriptions
c. "job-subscription-ids (1setOf (integer(1:MAX))" - the set of Per-Job
subscription ids for the Subscription objects associated with this job. In
order to indicate that there are no Per-Job subscriptions, we need to decide
on several alternatives: (1) don't return this attribute, (2) return this
attribute with the 'no-value' out-of-band attribute value (see [ipp-mod]
section 4.1), (3) return this attribute with a single integer 0 value (since
0 isn't a legal Subscription ID value), (4) return new '0setOf' attribute
syntax in which 0 or more values can be represented.
d. Don't have any Job Description attributes for notification (as in the
current alternative spec).
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?
ISSUE 9 - Should we adopt the alternative Notification which aligns the
Per-Job subscription mechanism with the Per-Printer subscription mechanism
and uses Subscription objects for both? Both of the Notification specs
posted on 9/15 (with 9/9/99 and 9/10/99 dates in the document) are at the
same level of development, so switching to the alternative does not require
any additional specification writing.
ISSUE 10 - Should we add the "job-id" Subscription Description attribute to
the Subscription object? Or is it better to leave it out, so that
implementations that need such a link would do so internally? The client
doesn't need such a link, since when it queries using Get-Subscriptions, it
supplies either the "job-id" it wants Per-Job subscriptions or it omits the
"job-id" and gets all of the Per-Printer subscriptions. If we do add the
"job-id" to the Subscription object, what about Per-Printer Subscription
objects? See choices in issue 5a: Don't return "job-id", return "job-id"
with a 0 (invalid subscription id value), return 'no-value' out-of-band
value.