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 1 '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. 2 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) 3 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): 4 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 5 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 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: 6 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 7 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? 8