I've posted the issue resolutions to the Notification issues that Bob
Herriot wrote up from the 9/22 and 9/23 IPP WG meeting. They are posted at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-meeting-issue-resolutions-9909
22-th.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-meeting-issue-resolutions-9909
22-th.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-meeting-issue-resolutions-9909
22-th.txt
I've also attached the .txt version here. Send any comments to the mailing
list. I'll update the spec in the next few days, in time for the next IPP
telecon, 10/6/99. Please comments on issues 20-22 especially.
Thanks,
Tom
Resolution of Notification Issues
September 23, 1999
This document contains the resolution of each issue 1-20 as decided at
the IPP meeting in Denver, plus issues 21-22. This leaves only issues
1, and 21-22 left to resolve. Please check issue 20, since it was done
quickly at the end of the meeting.
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.
Resolution: We adopted the alternative notification mechanism.
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?
Resolution: Still an issue
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.
Resolution: We decided on a new solution. The notification
specification will specify the single machine-readable format for each
defined notify-scheme (i.e. delivery method). It is possible for a
notify-scheme to have no machine-readable format. The notification
specification will also specify whether there can be a human-readable
format for each defined notify-scheme. But it will not define them.
Rename "notify-content-type" to "notify-text-format" attribute. If the
client doesn't supply this attribute, the machine-readable format is
used that is defined for each notify-scheme, if defined for that notify-
scheme. If a machine-readable format is not defined for the requested
notify-scheme and the client fails to supply the "notify-text-format"
attribute, the Printer selects one of the value of its "notify-text-
format-supported" attribute in an implementation-defined manner for use
in the notification.
An implementation MUST support the attribute "notify-text-formats-
supported" (perhaps find a better name) if it supports any human-
readable format, e.g. "text/plain", or "text/html", or 'none'. The
value of this attribute is a 1setOf mimeMediaType. If an implementation
supports a particular human-readable format, it must support this format
for all notify-schemes that have a human-readable format.
A client can determine what formats are supported for a notify-scheme as
follows. The implementation contains a hard coding of the machine-
readable format (obtained from the specification). If the hard coding
(obtained from the specification) prohibits a human-readable format for
the notify-scheme, or the printer doesn't support "notify-text-format-
supported" attribute, there are no human-readable formats for any
notify-scheme. Otherwise, the attribute "notify-text-formats-supported"
specifies the supported mime types for those delivery schemes that are
supported and permit a human-readable format.
The rationale behind this decision is that the machine-readable format
seems easy to pick for each notify-scheme and thus easy to document. It
is easy for a printer to support most machine-readable formats. It is
much harder to support a human-readable format because of localization
issues. Once the code is written to support a particular human-readable
format, it is easy to transmit it on any of the supported notify-
schemes. Thus, if a vendor decides to support a notify-scheme, it has
already committed to implement the machine readable-format. This may be
simple if existing code can be reused, e.g. application/ipp and or more
difficult if new code must be written, e.g. it is SNMP.
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.
Resolution: See Issue 2 for the resolution of this.
Page 23, section 5.5, lines 703-708:
ISSUE 4 - Should the Subscription object attributes "notify-attributes-
charset (charset)" and "notify-attributes-natural-language
(naturalLanguage)" be renamed to simply "attributes-charset (charset)"
and "attributes-natural-language (naturalLanguage)" so that all IPP
requests and objects have the same names? Then the "notify-attributes-
charset (charset)" and "notify-attributes-natural-language
(naturalLanguage)" would only be operation attributes that set or
reflect the "attributes-charset (charset)" and "attributes-natural-
language (naturalLanguage)" Subscription object attributes.
Resolution: We changed the name for the Subscription object attribute.
Because these attributes specify the charset and language for whatever
goes in the event notification, and the event notification contents may
be attributes or may be text, we decided to name the attributes in the
subscription object and operation attributes to be "notify-charset" and
"notify-natural-language". The "attributes-charset" and "notify-
attributes-natural-language" remain as REQUIRED operation attributes for
all operation requests and responses.
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?
Resolution: No. We couldn't find a real use-case for this attribute.
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).
Resolution: No. We couldn't see any reasonable use cases, so "d" is the
choice.
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?
Resolution: We agreed that a subscription response should contain
"notify-printer-up-time" and not "notify-lease-time-granted" in order to
have uniformity.
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?
Resolution: We agreed to add "notify-persistence-granted" as a new
subscription object attribute.
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:
Resolution: Decision is the same as Issue 6, namely "yes".
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.
Resolution: No. We could see no reason for a client to need this
information because a client can only get subscriptions by asking for a
particular job-id. See issue 17 for more.
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)
Resolution: No. Use solution "a". We believe it is better to add the
general purpose "collection". In the internet environment we see a
potentially greater need for multiple subscriptions per job, e.g. a
person submitting a job might want to receive notification of completion
and might want the recipient notified too. We believe that the
collection is a better solution than one requiring a client to hold a
job and then to add job subscriptions, and finally to release the job.
All three of these operations are optional.
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.
Resolution: No. We could see no reasonable use-case where a person
doesn't want to be notified in all three cases. Normally a person wants
to know the job disposition, whatever it is. There might be exceptional
case where someone listens for errors and not normal cases. The client
could contain a filtering program for such cases.
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.
Resolution: No. We will wait for a real need before making this change.
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?
Resolution: Yes. We believe that subscriber-user-data should required
for all events if it is to be useful.
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"
Resolution: We agreed to delete the first 3 attributes above, but to
keep the last two "job-state" and "job-state-reasons".
The following issues were raised at the meeting in Denver.
ISSUE 15 . Should we require that a Printer always accept the number of
subscriptions that it advertises as its maximum. If not, how does it
inform a user about the rejection of a subscription.
Resolution: We decided that a printer might give higher priority for
jobs than subscriptions. Thus, it might accept a job and reject some
subscriptions. This means that a printer must be capable of rejecting
subscriptions that accompany a job. When a subscription is ignored, all
of the attributes in the subscription are returned in the unsupported
attributes. If a printer accepts some of the subscriptions and rejects
other subscriptions, only the attributes of rejected subscriptions are
in the unsupported attributes group in the response.
If the job is accepted and one or more subscriptions are rejected, the
status code returned is 'successful-ok-subscription-rejected'. This
status code is returned even if other job attributes are unsupported or
in conflict. That is, if a server finds warning that would allow it to
return 'successful-ok-subscription-rejected' and either "successful-ok-
ignored-or-substituted-attributes' or 'successful-ok-conflicting-
attributes', it must return 'successful-ok-subscription-rejected'. We
should add language in the model document explaining that if a server
finds warning that would allow it to return either "successful-ok-
ignored-or-substituted-attributes' or 'successful-ok-conflicting-
attributes', it must return 'successful-ok-conflicting-attributes'.
NOTE: This success code precedence needs an update to the Model and
Semantics document.
Rationale: We want to allow an implementation that wants to keep
Subscription objects separately from Job objects to be able to run out
of room for Subscription objects before running out of space for Jobs.
So an implementation can continue to accept jobs, even though it has
exhausted space for Subscription objects.
Issue 16: Should create-subscription be mandatory for job subscriptions.
Resolution: No. Create separate operations for printer subscription
creation and job subscription creation so that a user can determine
which are supported. Make printer subscription creation mandatory for a
printer to support and make job subscription creation optional for a
printer to support. This decision also means that a client MUST supply
the "job-id" in a Create-Job-Subscription operation and MUST NOT supply
it in a Create-Printer-Subscription operation, which follows a principle
we have for other Job versus Printer operations.
Issue 17: Should the get-subscriptions operation have an option for
getting all printer and all job subscriptions in a single operation?
Resolution: No. We could see no need to get all. We could barely see a
need to get job subscriptions, job by job. Getting printer subscriptions
is important.
Issue 18: What are the implementation requirements for "job-impressions-
completed" and "job-media-sheets-completed" as shown in Table 5.
Resolution: Make both "Conditionally required" (an "CR") for "job-
progress" and "job-completed" events, i.e., REQUIRED in a 'job-progress'
event notification if the implementation supports the corresponding
"job-impressions-completed" or "job-media-sheets-completed" Job
attributes. The group believed that these attributes were the ones
mostly likely to be implemented and should be consistent for "job-
progress" and "job-completed".
Issue 19: What do "R" and "O" mean in the tables.
Resolution: We would like a few sentences to be added to the document to
explain "R", "CR", and "O" in the tables. We assume that "R" means
"REQUIRED" if the implementation supports notification, "CR" means
"CONDITIONALLY REQUIRED", i.e. it is required in an event if the printer
supports the attribute in the Job or Printer object, and "O" means
OPTIONAL.
Issue 20: Should "subscriber-user-name" be in "job-progress" events.
Resolution: Yes. But it should be changed from REQUIRED ("R) to OPTIONAL
("O") for all events.
Issue 21: Should we change the Notification Model to allow notification
delivery methods that are request and response (in addition to the
current model which has only one-directional notification delivery using
the 'application/ipp' operation response format?
Issue 22: If the answer to Issue 21 is yes, should we change the
format of the notification content using 'application/ipp' to always be
a Send-Notification request, whether the scheme returns a response or
not?