INTERNET-DRAFT S. Isaacson Novell, Inc. J. Martin Underscore R. deBry Utah Valley State College T. Hastings Xerox Corporation M. Shepherd Xerox Corporation R. Bergman Dataproducts Corp. August 22, 1999 Internet Printing Protocol/1.0 & 1.1: IPP Event Notification Change History Copyright (C) The Internet Society (1999). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed as http://www.ietf.org/shadow.html. Abstract This document contains the change history for the development of the IPP Notification specification. The IPP Notification specification is an extension to the IPP/1.0 & IPP/1.1 model that allows clients to subscribe to printing related events. Subscriptions include "Per-Job Submission subscriptions" and "Per-Printer subscriptions". Either subscription may specify job and/or printer events. This specification has been developed starting in the Fall of 1997. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 1] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 The full set of IPP documents includes: Design Goals for an Internet Printing Protocol [IPP-REQ] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [IPP-RAT] Internet Printing Protocol/1.1: Model and Semantics [IPP-MOD] Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO] Internet Printing Protocol/1.0: Implementer's Guide [IPP-IIG] Mapping between LPD and IPP Protocols [IPP LPD] The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. A few OPTIONAL operator operations have been added to IPP/1.1. The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. The "Internet Printing Protocol/1.1: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport. It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues. The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs. Finally, this document defines interoperability rules for supporting IPP/1.0 clients. The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included. The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 2] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 Table of contents 1 Changed made to the August 17, 1999 version to make the August 22, 1999 version........................................................4 2 Changes made to the August 11, 1999 version to make the August 17, 1999 version:.......................................................5 3 Changes made from August 8, 1999 version to make the August 11, 1999 version.............................................................7 4 Changes to the August 2, 1999 version to make the August 7, version 10 5 Changes to the July 22, 1999 version to make the August 2, 1999 version............................................................10 6 Changes to the July 21, 1999 to make the July 22, 1999 (T Hastings) 10 7 Changes to the July 20, 1999 to make the July 21, 1999 (T Hastings) 10 8 Changes to the May 18, 1999 to make the July 20, 1999 (M Shepherd)11 9 Changes to the May 17, 1999 to make the May 18, 1999 (T Hastings, R Bergman)...........................................................12 10 Changes to the January 20, 1999 to make the May 17, 1999 version (M Shepherd)..........................................................13 11 Changes to the January 18, 1999 to make the January 20, 1999 version 14 12 Changes to the December 10, 1998 to make the January 18, 1999 version 15 13 Changes to the July 1, 1998 to make the December 10, 1998 version16 Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 3] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 IPP Notification Specification Change History The change history is maintained in reverse chronological order. Brief explanations for each change is often included. 1 Changed made to the August 17, 1999 version to make the August 22, 1999 version 1.Integrated the Attribute Summary and New Model documents into the Specification. Separated the Change History into this document. Put the attribute summary as an Appendix. Put each Notification Method description into a separate (short) document. 2.Added "notify-content-type" (mimeMediaType) so that the client can specify whether human consumable versus machine consumable. 3.Added "notify-content-type-supported" (1setOf collection) Printer Description attribute to represent which notification format types are supported for each supported delivery scheme. 4.Made Per-Printer Subscriptions and the Subscription object REQUIRED if notification is supported. So both Per-Job and Per- Printer subscriptions are REQUIRED. There is no longer any CONDITIONALLY REQUIRED indication in our spec. 5.Added "notify-attributes-charset" to represent "attributes- charset" in subscription requests and objects to distinguish it from the request's "attributes-charset" attribute. 6.Added "notify-attributes-natural-language" to represent "attributes-natural-language" in subscription requests and objects to distinguish it from the request's "attributes- natural-language" attribute. 7.Removed the concept of recording events, since there are no longer any Job or Printer attributes that record the last event, time, or date-time of the event. Only the Printer's "printer- state-change-time" and "printer-state-change-date-time" remain for recording events as the last Printer state change, so that an application starting up can determine how long the device has been in its current state. 8.Deleted notify-content-types-supported (1setOf collection). Require all (1 or 2) content types that are defined for a method to be supported, if the method is supported. 9.Added the 'server-error-too-many-events' status code. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 4] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 2 Changes made to the August 11, 1999 version to make the August 17, 1999 version: 1.Instead of the "notify-exclude-event-mask" (1setOf octetString(8)) attribute, we agreed to use introduce the new 'collection' attribute syntax that we have been talking about for over a year for use in the Job object to specify multiple subscriptions in a Job creation operation. So the "notify" operation attribute for Job creation operations will have the attribute syntax: '1setOf collection'. The member attributes of each collection value for Per-Job subscriptions are the same as the attributes of a Subscription object instance for Per- Printer subscriptions. For terminology a "subscription" is either a collection value of the "notify" operation attribute in a Job Creation operation or is a Subscription object. 2.Each subscription will contain only one multi-valued attribute: "notify-events" (1setOf type2 keyword). The remaining attributes will be single valued: "notify-recipients" (uri) "notify-user-info" (octetString(63)) "attributes-charset" (charset) "attributes-natural-language" (naturalLanguage) "request-id" (integer(0:MAX)) 3.The client supplies an "attributes-natural-language" in a subscription in order to get a different natural language than for the request that creates the subscription. However, the only time that the natural language has any bearing on the Notification content, is when that content is the Human Consumable form. The Machine Consumable form of the Notification content will have no localization in it. 4.The minimum number of notification recipients that are required to support is 1. Hence the minimum number of collection values is 1 and the minimum number of Subscription objects is 1, if Per-Printer subscriptions are supported at all. 5.Instead of inventing a special operation that sets the Job attributes related to notification, we will define a single Set- Job-Attributes operation for changing the values of any Job attribute that is not defined to be READ-ONLY. We will not define the corresponding Set-Printer-Attributes operation at this time, but will lump that operation with the other System Administration operations, since changing Printer attributes is an administrative function. Changing Job attributes is an end- user function for your own jobs, and an operator operation for other's Jobs. 6.A Printer can grant a larger or smaller least to that requested, including granting an infinite lease. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 5] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 7.Change "persistence (boolean)" operation attribute to "persistence-requested (boolean)" in the Create-Printer- Subscription. Keep it OPTIONAL to support. However, add a REQUIRED "persistence-granted (boolean)" operation attribute that MUST be returned in the response. While implementations are RECOMMENDED to make all Subscriptions persistence, same as for jobs, they MAY have a more limited number that are persistent, including none. 8.Add two Printer Descriptions attributes: "persistent-job- supported" (boolean) and "persistent-subscriptions-supported" (boolean). 9.The Get-Printer-Subscriptions and Get-Printer-Subscription- Attributes will return attributes Subscription attributes group, so there will be a new Subscription attribute tag assigned in the Encoding and Transport. 10. Changed the name of the "notify-lease-time" (integer(0:MAX)) in the Subscription object to "notify-least-expiration-time" (integer(0:MAX)) since it is the time at which the lease expires. 11. Eliminated storing the trigger-event, trigger-time, and trigger-date-time in the subscription and passed them only in the Notification content. 12. Add "printer-state-change-time" (integer(MIN:MAX)) and "printer-state-change-date-time" (dateTime) Printer Description attributes to record the time that the Printer last changed state. Then an application that come up after that can tell when the printer got into its current state by querying the Printer when the application starts up. Lesson from the Printer MIB alert table. 13. Defined the "subscription-id" attribute for use with Per-Job subscriptions as being the index of the 1setOf collection, starting at '1'. Then a Notification Recipient can have a unique identification for each subscription whether it be Per- Job or Per-Printer, for use in catching duplicate or skipped notifications using the "request-id". 14. Deleted the "delivery-failure-count" (integer(0:MAX)) from the Subscription object as not necessary. 15. Transports that have limited space, like SNMP, can truncate the "job-name" to less than 255 octets, in order to fit. 16. Added the "subscription-printer-uri" (uri) to the Subscription object to go along with the Job's "job-printer-uri" (uri) attribute. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 6] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 17. Added "job-k-octets-processed" (integer(0:MAX)) to the Job Notification content for 'job-progress' and 'job-completed' events. 18. Added the 'job-progress' attributes to also be in the 'job- completed' Job Notification content. 3 Changes made from August 8, 1999 version to make the August 11, 1999 version The following changes were made from the 99/08/07 version to make the 99/08/11 version as result of the IPP telecon, 9908/11: 1. Changed the name of the Replace-Job-Subscription operation to Set- Job-Subscription, since it can add, remove or change Job notification attributes, not just replace them. 2. Added the configuration pictures. 3. Reduced the size of "notify-user-data" from 255 octets to 63 octets, since it is also send in the Notification content which has a limit of 480 or so octets on some transports. 4. Changed the conformance requirements for the "notify-exclude-event- masks (1setOf octetString(8))" operation attributes in Job creation and Create-Printer-Subscription operations from OPTIONAL to REQUIRED, since their implementation means that clients can count on it. Also the minimum number of Per-Printer Subscriptions can be less, since a client won't be forced to use multiple subscriptions when recipients have different events. Finally, SNMPv3 has the exclude mask mechanism. 5. Added the OPTIONAL "notify-natural-languages" (1setOf naturalLanguage) Job Description attribute so that each Notification Recipient could get a requested natural language, instead of the one in the Job creation request. 6. Deleted the "job-trigger-message" Job Description attribute from Job object attribute. The client can localize the remaining Job attributes on its slow scan in case Notifications are dropped. 7. Added the "notify-request-ids (1setOf integer(0:MAX))" Job Description attribute to the Job object to indicate (and remember) the most recent request-id delivered for each Notification Recipient. 8. Deleted "previous-job-state (type1 enum)" and "job-state-reasons- added (1setOf type2 keyword)" and "job-state-reasons-deleted (1setOf type2 keyword)" from the Job object. The "job-state- reasons" value has enough information about why the Job is in the current state, so that we don't need the previous state and state Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 7] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 reasons for the slow scan polling Notification Recipient that is attempting to overcome possible dropped Notifications. 9. Added REQUIRED "max-recipients-supported (integer(0:MAX))" Printer Description attribute to the Printer object to indicate the max number of Per-Job and Per-Printer Notification Recipients supported in each subscription. REQUIRE a minimum of 3 recipients. 10. Added the requirement that at least 8 Per-Printer Subscription object instances MUST be supported, if Per-Printer subscriptions are supported. With the exclude mask, such a low number as 8 isn't too restrictive on clients and isn't too expensive for low end devices. 11. Added the OPTIONAL "persistent-subscriptions-supported" (boolean) Printer Description attribute to the Printer object to indicate whether or not the Printer supports persistent Per-Printer Subscriptions. 12. Changed the Printer support requirements for the "notify- exclude-event-mask" (1setOf octetString(8)) from OPTIONAL to REQUIRED, so that clients can count on it and to reduce the number of Subscription objects that a Printer MUST support. 13. Added the OPTIONAL "notify-natural-languages" (1setOf naturalLanguage) Subscription object attribute so that each Notification Recipient could get a requested natural language, instead of the one in the Create-Printer-Subscription request. 14. Added the "subscription-id" attribute to the Subscription object so that each object instance is identified in a manner analogous to Job objects. 15. Changed the name of "most-recent-request-id" to "notify- request-ids" for consistency in naming and to be the same as the corresponding Job Description attribute ("notify-request-ids"). 16. Changed the name of the "notify-lease-time-remaining" Subscription object attribute to "notify-lease-time". Changed the semantics from the lease time interval requested to the "printer- up-time" (time ticks) that the lease expires. The client can subtract the "printer-up-time" from the "notify-lease-time" to find out how much time is left on the lease. This change makes the attribute value be a constant, instead of having to be recomputed on each Get-Printer-Subscription-Attribute request. 17. Changed the name of the "notify-lease-time (integer(0:MAX))" Subscription object attribute to "notify-lease-time-granted (integer(0:MAX))" and indicated that it is set by the Printer not the client. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 8] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 18. Added 'printer-announce' event, so that the Subscriber can have the Notification Recipient be warned that other Printer events are forth coming. 19. Added 'printer-queue-changed' - so that an application that is monitoring the queue can re-fetch the queue with Get-Jobs. 20. Added "attributes-charset" and "attributes-natural-language" to the Job and Printer Notification content, since the content is an 'application/ipp' MIME type for an IPP response. 21. Added "printer-name (name(127))" and "job-name (name(MAX))" to Job and Printer Notification Content. These are helpful to end users to identify from whence came a notification. 22. Deleted the "job-trigger-message (text(255))" from the Job Notification content since the data is already available in other attributes that the recipient should localize to present to a human. Also the Human Consumable form will have many of the attributes when it is used. 23. Deleted "previous-job-state (type1 enum)" and "job-state- reasons-added (1setOf type2 keyword)" and "job-state-reasons- deleted (1setOf type2 keyword)" from the Job Notification content. The current "job-state-reasons" value has enough information about why the Job is in the current state, so that we don't need the previous state and state reasons. 24. Deleted the "printer-trigger-message (text(255))" from the Printer Notification content, since the data is already available in other attributes that the recipient should localize to present to a human. Also the Human Consumable form will have many of the attributes when it is used. 25. Added [job-id (integer(1:MAX))] and [job-name (name(MAX))] to the Printer Notification content for when the event is from a Per- Job subscription. 26. Deleted "previous-printer-state (type1 enum)" and "printer- state-reasons-added (1setOf type2 keyword)" and "printer-state- reasons-deleted (1setOf type2 keyword)" from the Printer Notification content. The current "printer-state-reasons" value has enough information about why the Printer is in the current state, so that we don't need the previous state and state reasons. 27. Added "printer-is-accepting-jobs (boolean)" attribute to the Printer Notification content, since it is a state variable and its change causes the 'printer-state-change' event. 28. Added the definition of the Set-Job-Subscription operation. 29. Changed the name of "notify-lease-time" operation attribute in the Create-Printer-Subscription operation to "notify-lease-time- Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 9] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 requested" to distinguish it from the "notify-lease-time" (uptime ticks) and "notify-lease-time-granted" returned in the response. 30. Added the "notify-persistence (boolean)" operation attribute to the Create-Printer-Subscriptions to indicate whether the notification content delivery is to make the Per-Printer Subscription be permanent. 4 Changes to the August 2, 1999 version to make the August 7, version 1.Changed the Subscription object to be used only with the Per- Printer subscriptions. Per-Job subscriptions are done with Job Creation operation attributes that are copied to the Job object as Job Description attributes. 5 Changes to the July 22, 1999 version to make the August 2, 1999 version 1. Introduced the Subscription object for use with both Job Subscriptions and Printer Subscriptions. A Subscription object is associated with a Printer object, a Job object, or is an unassociated Job Subscription waiting for the Job object to be created and a back association made to it. 2. Add the following operations on the Subscription object: Create-Subscription recipients, [events,] [user-data,] [lease-time,] [job-id or printer-uri] Get-Subscription-Attributes subscription-id, [requested- attributes] Renew-Subscription subscription-id, [lease time] Cancel-Subscription subscription-id 6 Changes to the July 21, 1999 to make the July 22, 1999 (T Hastings) 1. Added the REQUIRED "initial-sequence-numbers" (1setOf integer(1:MAX)) to the Subscribe-Printer response to indicate the sequence number to be used in the first notification for each event subscribed. 2. Added a number of issues and renumbered. 7 Changes to the July 20, 1999 to make the July 21, 1999 (T Hastings) The following changes were made to the July 20, 1999 to make the July 21, 1999 version: 1.Changed the "job-trigger-events (1setOf type2 keyword)" Job Description attribute "job-trigger-event (type2 keyword), since events cannot be batched in a notification. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 10] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 2.Changed the "printer-trigger-events (1setOf type2 keyword)" Printer Description attribute "printer-trigger-event (type2 keyword), since events cannot be batched in a notification. 3.Changed Subscribe-Job from REQUIRED to OPTIONAL if implementing "Explicit Subscription". 4.Clarified that events are defined to be disjoint, since the job- trigger-event is now single-valued. Thus only the 'job-created' event is generated even if job state reasons are added. Similarly, only the 'job-completed' event is generated even if job state reasons are added or removed. 5.Indicated which Job Description and Printer Description attributes are READ-ONLY, i.e., MUST NOT be settable with Set- Job-Attributes or Set-Printer-Attributes operations. 6.Clarified which Job attributes cause 'job-config-changed' event: "job-message-from-operator" and any non-READ-ONLY Job attributes. 7.Clarified which Printer attributes cause 'printer-config- changed' event: "printer-message-from-operator" and any non- READ-ONLY Printer attributes, except "media-ready" which has its own event. 8.Renamed 'ready-for-job' event to 'printer-is-no-longer-full' and clarified that it is generated only when a previous Print-Job, Print-URI, Create-Job, Send-Document, or Send-URI operation had been rejected due to no more room. 9.Renamed 'ready-for-just-in-time-job' to 'printer-almost-idle', to make it clearer how this event differs from 'printer-is-no- longer-full'. 10. Kept 'printer-shutdown' and 'printer-restarted' as separate and disjoint from 'printer-state-changed' event, so that they can be subscribed without having to get all state change events. Also parallel with 'job-created', 'job-state-change', and 'job- completed'. Also clarified that shutdown means either using the Shutdown-Printer operation with 'standby' or 'power-down' options or power-down by other means. Same for 'printer- restarted' being with the Restart-Printer operation or a power- up sequence. 8 Changes to the May 18, 1999 to make the July 20, 1999 (M Shepherd) The following changes were made to the May 18, 1999 to make the July 20, 1999 version: 1.Added new section Conformance Requirements 2.Changed 'event report' to 'notification' 3.Changed 'request-id' to be used as a sequence number inside each notification. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 11] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 4.Combined job-state-changed and job-state-reason-change into one notification trigger-event. 5.Combined printer-state-changed and printer-state-reason-change into one notification trigger event. 6.Added "job-config-changed" event 7.Moved "device-powering-down" event to be encompassed by "printer-state-change" 8.Combined this spec with the Job Independent Subscriptions spec (which was renamed to Explicit Subscriptions). 9.Added operation Subscribe-Job. 10. Added server-error-too-many-subscriptions to Status Codes. 9 Changes to the May 17, 1999 to make the May 18, 1999 (T Hastings, R Bergman) 1.Removed concept of event groups. Subscribe to individual events. Much simpler. The event determines what data is sent in the event report. Also allows the client to query the printer to see what events are supported, rather than which groups. 2.Replaced all of the job state transition events with a single 'job-state-changed' event. The report contains the old job state and the new job state. 3.Removed the notification-format attribute to keep the proposal simple. 4.Added the 'client-error-notify-uri-scheme-not-supported' status code. 5.Added REQUIRED "previous-job-state", "previous-job-state- reasons", previous-printer-state", and "previous-printer-state- reasons" Job Description attributes. 6.Removed the "job-impressions-completed" from the Basic Job Event Report Content. Bring it back with the "job-progress" events. 7.Removed the "printer-is-accepting-jobs" from the Basic Printer Event Report Content. Its changing is part of the "config- change" event. 8.Changed the 'job-state-changed' event, so that it doesn't include 'job-created', 'job-completed', or 'job-purged' events. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 12] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 9.Made the event names mostly consistent by being in the past tense to reflect the fact that events reports happen after the internal event has completed. 10. Combined the 'job-state-reasons-added' and 'job-state-reasons- removed' into a single event: 'job-state-reasons-changed'. Same for 'printer-state-reasons-changed'. 11. Changed 'mailto' notification method to REQUIRE 'multipart/report' which all mail agents understand, at least the text part. 12. Deleted the 'job-warning' and 'job-error' events, since they are covered by the 'job-state-reasons-changed, 'job-state- changed' and/or 'job-completed' events. 10 Changes to the January 20, 1999 to make the May 17, 1999 version (M Shepherd) 1. Changed references to IPP 1.0 to IPP 1.1 2. Implementing the notification specification is optional. 3. Refined the definition of Event 4. Changed 'notification report' to 'event report' for consistent terminology 5. Changed the terminology of an 'active' job to 'not-complete'. Included the 'pending-held' state in the 'not-complete' super- state. 6. Introduced notify-event-groups-default. 7. Changed job-trigger-message and job-impressions-completed to be CONDITIONAL in the event report, job-trigger-date-time to be RECOMMENDED, and job-state-reasons to be REQUIRED. 8. Changed printer-trigger-message to be CONDITIONAL in the event report, and printer-state-reasons to be REQUIRED. 9. Created a table to map job-trigger-events keywords to event-groups and required status. 10. Modified job-continued to be job-resumed-processing, and job- received to be job-created. Added job-purged, job-state-reason- removed, and job-state-reason-added keywords. 11. Modified job-trigger-time and printer-trigger-time to use values less than zero. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 13] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 12. Created a table to map printer-trigger-events keywords to event-groups and their required status. 13. Added ready-for-job and printer-state-reason-added to printer- trigger-events keywords. 14. Updated References section 15. Added notify-format and notify-format-supported attributes. 16. Added subscription-id to the event report attributes of job and printer. 17. Made job-errors-basic and printer-errors-basic REQUIRED to be supported. 18. Added printer-media-changed, printer-config-changed, and ready-for-just-in-time-job to printer events. 19. Added Author's Addresses. 11 Changes to the January 18, 1999 to make the January 20, 1999 version The following changes were made to the January 18, 1999 to make the January 20, 1999 version: 1. Made this an INTERNET-DRAFT. 2. Indicated that a new default port is needed for the delivery methods. 3. Added Appendices in which to put the registration information for the URL schemes for each delivery method. 4. Clarified which parameters, Operation attributes, and Job/Printer attributes are supplied in an event content: the request-id is 0, the status-code is new 'job-event' 0x600 or 'printer-event' 0x601. 5. Changed "job-trigger-event" and "printer-trigger-event" to be 1setOf so that multiple events that occur at the same time MAY be send as one event content. 6. Added "job-trigger-time" as a REQUIRED Job Description and event content attribute which is in seconds since power up. 7. Changed "job-trigger-date-time" and "job-state-reasons" to OPTIONAL. 8. Changed "status-message" to be an OPTIONAL "job-trigger-message" event content attribute and also made it a Job Description attribute. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 14] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 9. Added "printer-trigger-time" as a REQUIRED Printer Description and event content attribute which is in seconds since power up. 10. Changed "printer-trigger-date-time" and "printer-state- reasons" to OPTIONAL. 11. Changed "status-message" to be an OPTIONAL "printer-trigger- message" event content attribute and also made it a Printer Description attribute. 12. Removed the "job-id" attribute from the printer event content. 12 Changes to the December 10, 1998 to make the January 18, 1999 version The following changes were made to the December 10, 1998 to make the January 18, 1999 version: 1. Changed the names of the REQUIRED notify-recipient keywords from: 'ipp-tcp-socket' and 'ipp-udp-socket' to 'ipp-tcp-notify' and 'ipp- udp-notify'. 2. Added '-notify' to the OPTIONAL 'snmpv1', 'snmpv2', and 'snmpv3' delivery method names. 3. Changed the OPTIONAL 'sense-datagram' to 'sense-notify' to be consistent. 4. Added 'ndps-notify' as an OPTIONAL keyword. 5. Deleted the 'all-basic', 'all-job-events-basic', and 'all-printer- events-basic'. Clients should be explicit about which groups they want. If new groups are added, the clients won't know what to do with them, if they had subscribed to 'all-xxx' groups. 6. Changed the names of "job-last-event" and "job-last-date-time-of- event" to "job-trigger-event" and "job-trigger-date-time" events, since the events trigger the notification delivery, but the attribute values remain after the event has been delivered. 7. Added "status-message" as an OPTIONAL event report content attribute. 8. Changed "job-impressions-completed" to OPTIONAL. 9. Indicated that OPTIONAL attributes are not sent in the event report content if they are not supported. 10. Required that "status-message" and/or "job-impressions- completed" be sent in an event report content if they are supported as an Operation attribute and a Job Description attribute, respectively. 11. Added REQUIRED "printer-trigger-event", REQUIRED "job-id", and OPTIONAL "status-message" to the printer event report content. 12. Specified the "printer-trigger-event" Printer Description attribute, naming each event. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 15] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 13. Deleted the 'sheet-completed' and 'collated-copy-completed', since these events are not part of any 'xxx-basic' event group. They can be added back when we have an event group that uses them. 13 Changes to the July 1, 1998 to make the December 10, 1998 version The following changes made from the July 1, 1998 to make the December 10, 1998 version: 1. Clarified the terminology so that an "event" doesn't necessarily mean that a notification report is delivered. 2. Removed many of the job and printer attributes for being sent in a notification event report, so that we can get agreement on a basic set of event report content. Only attributes really needs are included, including what may be needed for FAX. Changed the names of the event groups by adding the suffix '-basic' to indicate that these event groups return only basic information. Additional event groups can be registered in order to get more attributes as needed for accounting and more detailed job monitoring purposes. 3. Deleted the "job-progress" event group. We can bring it back when we agree to all of the extra attributes. Its not very useful with only the basic attributes. 4. The printer events are indicted using the "printer-state-reasons" values, instead of the Printer MIB alert codes. Since most of the Printer MIB alert codes, except for the generic ones, have equivalent IPP keyword reason values, this should be a problem and makes IPP more readably implemented in a server that doesn't have the Printer MIB. 5. Added the "job-last-event" job description attribute to give the job event some persistence. 6. Changed the job's "time-at-event (integer)" to "job-last-date-time- of-event (dateTime)" to give an absolute date and time, in case events are being relayed back through multiple servers, such as in FAX. Also made it a Job Description attribute to give it persistence. 7. Changed the printer's "time-at-event(integer)" to "printer-last- date-time-of-event(dateTime)" to give an absolute date and time, in case events are being relayed back through multiple servers, such as in FAX. Also made it a Printer Description attribute to give it persistence. 8. Added the IPP/1.0 "printer-is-accepting-jobs" to the event report, since changes in its value are really printer state changes. 9. Added the complete semantics for each job event under the "last- job-event" Job Description attribute. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 16] Expires February 25, 2000 INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999 14 Prior work on Notification A general notification service and a reference implementation was developed during the 1995 and Spring of 1996. It is entitled: "System Event Notification System Environment (SENSE)". It used the publish and subscribe model with subscribers subscribing to the Notification Service directly, not the Print Service. [sense] Martin, J. et all., "System Event Notification System Environment (SENSE)", ftp://ftp.pwg.org/pub/pwg/sense/, work in progress, Spring 1996. Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 17] Expires February 25, 2000