Both Notification documents (with dates of September 9 and 10) that were
posted on 9/13/99 have the same set of issues (issue 1-8). The Alternative
spec that aligns Per-Job subscriptions with Per-Printer subscription (Sept
10 spec) has an additional issue (see issue 5a below).
Carl-Uno will bring copies of this issues list to the meeting.
Issues 9 and 10 added during the 9/15/99 IPP telecon and issues 11-14 added
as a result of producing the MIB for IPP SNMP notification. The page
numbers and section numbers refer to the Notification Alternative spec,
dated September 10, 1999, since that alternative had considerable support
during the telecon. So agreeing to go with the alternative that aligns
Per-Job with Per-Printer subscriptions should be the first issue to be
considered. Therefore, I've numbered it ISSUE 0:
Pages 1-47:
ISSUE 0 - 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.
Page 19, section 5.1, lines 551-553:
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?
Page 22, section 5.3, lines 677-683:
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.
Page 22, section 5.3, lines 684-689:
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.
Page 23, section 5.5, lines 703-708:
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.
Page 25, section 6, lines 780-782:
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?
Page 25, section 6, lines 783-786:
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).
Page 34, section 8.2.1, lines 1027-1032:
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?
Page 34, section 8.2.1, lines 1036-1037:
ISSUE 7 - Should "notify-persistence-granted" be a Subscription object
attribute too, so that all attributes returned in a response are
Subscription object attributes?
Page 37, section 8.2.4, lines 1086-1089:
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?
The following issues are not listed in the Notification specification, but
were added later during email and telecon discussions:
Page 18, section 5, Table 2 (and a new 5.n section):
ISSUE 9 - 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.
Page 31, section 8.1.1 and Table 7:
ISSUE 10 - Should we remove the last use of collection in the notification
spec (see Ira McDonald mail suggestion), i.e., remove the "job-notify
(1setOf collection)" operation attribute in the Job Creation operations (and
Validate-Job)?
Alternatives:
a. Don't change. Keep "job-notify (1setOf collection)" as an operation
attribute (for the client to supply and the Printer to support) and
'collection' as a new attribute syntax.
b. Keep "job-notify (1setOf collection)" as an operation attribute (for the
client to supply and 'collection' as a new attribute syntax. However, allow
the Printer to be able to support the notification spec, but NEED NOT
support the 'collection'. Instead the Printer would return the "job-notify"
as an unsupported attribute, but would support the notification member
attributes. In this case, the Printer is only supporting one Per-Job
subscription in the Job Creation operations.
c. Remove the 'collection' attribute syntax all together (until another use
of it is justified). Instead of one "job-notify (1setOf collection)"
operation attribute in the Job Creation operations (and Validate-Job), we'd
make the 6 member attributes be operation attributes instead:
notify-recipient (uri)
notify-events (1setOf type2 keyword)
notify-content-type (mimeMediaType) [See ISSUE 3 which would remove this
one]
subscriber-user-data (octetString(63))
notify-charset (charset)
notify-natural-languages (1setOf naturalLanguage)
d. Same as c, but in addition, REQUIRE that an implementation that supports
notification also support the OPTIONAL Hold-Job and Release-Job operations
with at least the 'indefinite' value. Then a client could count on add
additional Per-Job subscriptions by submitting the job with "job-hold" =
'indefinite', perform additional Create-Subscription operations (up to the
limit of the number of Per-Job subscriptions supported per job).
Page 20, section 5.2, lines 573-579:
ISSUE 11 - Should the 'job-completed' event which is defined to be job
completion, job aborted, and job canceled be separated into three separate
events, i.e., replace the single 'job-completed' event with 'job-completed',
'job-aborted' and 'job-canceled'? In the current spec, there is no way to
subscribe just to aborted or canceled; the 'job-completed' event means all
three conditions. On the other hand, breaking them apart will increase the
number of events that are supplied in a subscription. The Notification
Recipient could filter between the three kinds of completions by looking at
the "job-state" attribute that is passed in the Notification content.
Pages 28-29, section 7.2, Table 4, "12. trigger-date-time" row:
ISSUE 12 - Shouldn't 12.trigger-date-time be OPTIONAL in 'job-progress',
rather than not specified, i.e., add "O" to the 'job-progress' column in the
12.trigger-date-time row? The trigger-date-time will be needed for
QUALDOCs, though maybe page level won't be REQUIRED for QUALDOCs.
Pages 28-29, section 7.2, Table 4, "15. subscriber-user-data" row:
ISSUE 13 - Shouldn't 15. subscriber-user-data be REQUIRED for
'job-progress', since it may be important for certain notification methods,
i.e., change the <blank> to "R" in the 'job-progress' column for the "15.
subscriber-user-data" row?
Pages 28-30, section 7.2, Table 4 and section 7.3 Table 5:
ISSUE 14 - Agreed that the following attributes are NOT sent in the
'job-progress' event notification (because the table entry is blank in the
"job-progress' column), since these attributes aren't likely to change from
one page to the next:
"printer-name"
"job-name"
"subscriber-user-name"
"job-state"
"job-state-reasons"