PWG WORKING DRAFT ISSUES are highlighted like this. Scott Isaacson, Jay Martin, Roger deBry, Tom Hastings December 10, 1998 IPP Event Notifications (Very Short) Version 0.4 Abstract This document describes an extension to the IPP/1.0 model that allows end users to subscribe to printing related events as part of job submission. This type of subscription is called "Job Submission Subscription". See a companion white paper entitled: "Job Independent Subscriptions for IPP" [ipp-sub] for operations to subscribe to the same printing related events that is independent of job submission. With either subscription method, a subscription includes: - the names of groups of events that are of interest to the subscriber - the delivery methods and addresses to use for event reports (socket, email, etc.) A subscription does not include - complicated lists and sets of names of individual events that are of interest to the subscriber - arbitrary lists of additional attributes to be returned in the event report - specification of which format to use in the event report (the delivery method implicitly defines the format that is used) A simple method is provided for subscribing to printing related events: - Two new subscription attributes are supplied by the client as part of an IPP create request (Print-Job, Print-URI, Create-Job, Validate-Job) An event is some occurrence (either expected or unexpected) within the printing system. Events can be classified using two dimensions: - Either as Job Events or Device Events, and - Either as Errors, Warnings, or Reports When the event occurs, an event report is generated and delivered using the information specific to the job's subscription. Isaacson, Martin, deBry, Hastings [page 1] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 Table of Contents 1 Summary of the proposal..............................3 2 Terminology..........................................3 3 Model for Job and Device Event Notification..........5 4 New subscription Operation attributes................6 4.1Two subscription operation attributes................7 4.1.1 notify-recipients (1setOf uri) 7 4.1.2 notify-event-groups (1setOf type2 keyword) 8 5 Event Report Content................................10 5.1Basic Job event notification content................11 5.2Basic device event notification content.............11 6 Job Description Attributes..........................12 6.1job-last-event (keyword)............................12 6.2job-last-date-time-of-event (dateTime)..............13 7 Printer Description Attributes......................13 7.1printer-last-date-time-of-event (dateTime)..........13 7.2notify-recipients-schemes-supported (1setOf uriScheme)13 7.3notify-event-groups-supported (1setOf type2 keyword)14 8 References..........................................14 9 Issues..............................................14 10 Change History......................................15 10.1 Changes made from the July 1, 1998 to the December 10, 1998 version 15 [page 2] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 1 Summary of the proposal This proposal includes the following concepts: 1.Two new multi-valued subscription operation attributes are defined: attribute name Syntax ------------- ------ "notify-recipients" 1setOf uri "notify-event-groups" 1setOf type2 keyword The presence of the "notify-recipients" indicates that notification is desired. The values of "notify-recipients" are URIs that identify the delivery method and delivery address to use for event reports (See Section 4.1.1). The values for "notify-event-groups" are keywords representing job event groups, device event groups, or both (See Section 4.1.2). 2.These subscription operation attributes can be supplied by the client in any of the IPP job submission operations: Print-Job, Print-URI, Create-Job, and Validate-Job. Subscriptions that include interest in job event groups apply only to the job being submitted and no other job. 3.Each Printer object supports new attributes that describe the notification methods and the event groups that it supports: "notify- recipients-schemes-supported" and "notify-event-groups-supported" . As events occur, for each event the Printer searches the set of subscriptions for any interest in that event. As the Printer finds that some entity is interested in that event (the entity is subscribed to the group of events to which the event belongs), an event report is generated and delivered using the methods and target addresses identified in the subscription. 2 Terminology Job Submitting End User - A human end user who submits a print job to an IPP Printer. IPP Client - The software component on the client system which implements the IPP protocol. Job Recipient - A human who is the ultimate consumer of the print job. In many cases this will be the same person as the Job Submitting End User, but need not be. Job Recipient Proxy - A human acting on behalf of the Job Recipient. In particular, the Job Recipient Proxy physically picks up the printed document from the Device, if the Job Recipient cannot perform that function. Subscription- The set of attributes that indicate the "what, where, who, and how " for notification. Events Reports are generated for certain events (what) and delivered using various delivery methods (how) to certain addresses (where and who). [page 3] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 Notification Recipient - Any entity identified as a recipient within a subscription. Some notification recipients are Job Submitting End Users and others are interested third parties, such as the Job Recipient or Job Recipient Proxy. Notification Recipient Agent - A program which receives event reports on behalf of the notification recipient. Event - An event is some occurrence (either expected or unexpected) within the printing system. Events can be classified using two dimensions: - Either as Job Events or Device Events, and - Either as Errors, Warnings, or Reports A Job event is some interesting state change in the Job object, and a Device event is some interesting change in the Printer object. The Printer MIB alerts define the set of interesting Device events [RFC1759] and [draftprtmib]. A report event is purely informational, such as 'job-completed' or 'printer-accepting-jobs'. A warning is not serious and processing continues (e.g., Printer MIB alerts with the prtAlertSeverityLevel value set to noInterventionRequired). An error is serious and either the job is aborted or the device stops. An event occurs for a job or device whether any entity is registered to be notified for that event or not. Event Report - When an event occurs, an event report is generated that fully describes the event (what the event was, where it occurred, when it occurred, etc.). Event reports are delivered to all the notification recipients that are subscribed to that event, if any. The event report is delivered to the address of the notification recipient using the notification method defined in the subscription. Immediate Notification - Event reports that are delivered using a delivery method which is not store-and-forward (e.g. TCP connection, UDP datagram). Queued Notification - Event reports that are delivered using a delivery method which has some sort of store-and-forward mechanism (e.g., email). Human Consumable Event Report - Event reports that are intended to be consumed by human end users only. Machine Consumable Event Report - Event reports that are intended for consumption by a program only. Mixed Format Event Report - A mixed event report may contain both human consumable and machine consumable information. [page 4] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 3 Model for Job and Device Event Notification Figure 1 shows the model. Legend: A = Client and Notification Recipient B = Notification Recipient (subscription by some third party) O A +----------+ Create Request with ########### /|\ | client/ |----Subscriptions------------># IPP # / \ | notif. | # Printer # end- | recip. |<---Job and Device -----------# Object # user +----------+ Event Reports ########### / O B +----------+ / /|\ | notif. | / / \ | recip. |<---Job and Device -------+ end- | | Event Reports user +----------+ Figure 1 - Model for Job and Device Notification Note: This model does not mandate that the IPP Printer object implement the full semantics of subscription, report generation, and multiple delivery methods. A simple (embedded) implementation may be configured to use some notification service. Figure 2 shows this partitioning. [page 5] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 Create Request with ########### ----Subscriptions-------------------># IPP # # Printer # # Object # ########### | *******|********** * Subscriptions * * & Events * * | * +----v---------+ * | notification | <---Job and Device -------*---------| service | Event Reports * +--------------+ * * *** = Implementation configuration opaque boundary Figure 2 - Opaque Use of a Notification Service 4 New subscription Operation attributes This section specifies two new subscription operation attributes. A client subscribes to event groups by supplying these attributes in any create request (i.e., a Print-Job Request, Print-URI Request, Validate- Job Request, or a Create-Job Request). These attributes are multi- valued attributes; the client can supply more than one value. If the client does not supply these attributes in the operation, there is no subscription made (either implicitly or explicitly). The following rules apply: 1.Any subscription can contain job event groups, device event groups, or both. 2.The Job Submission Subscription is only valid while the job is "active". The job is "active" while it is in the 'pending', 'processing', and 'processing-stopped' states. The job ceases to be active when it enters the 'pending-held' state or until the time it is done processing and enters any of the 'completed', 'canceled', or 'aborted' states. The job becomes active again when it is released from the 'pending-held' state or is restarted using the Restart-Job operation (see [ipp-ops1]). Since no job is created for the Validate-Job operation, the only purpose of supplying the subscription operation attributes in the Validate-Job operation is to validate that the values are supported; the Printer object does not establish a notification subscription as a result of the Validate-Job operation. [page 6] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 3.Since a Job Submission Subscription is included within a job submission operation, any interest in job events is limited to only "this job" (the Job object created because of this job creation operation). There is no mechanism to subscribe to events for all jobs or specifically some job other than this job in a create operation. But see [ipp-sub] for such a mechanism to subscribe persistently for job and printer events independently of any particular job submission. 4.1 Two subscription operation attributes Two subscription operation attributes are OPTIONALLY supplied by the client in create operations: Print-Job, Print-URI, Create-Job, and Validate-Job. Both are REQUIRED to be supported by Printer objects that support this notification specification. 4.1.1notify-recipients (1setOf uri) The client supplies this operation attribute in a create request in order to subscribe for job events while this job is active. The Printer object MUST support this attribute if it supports the "notify-event- groups" attribute. This attribute describes both where (the address) and how (the method) event reports are to be delivered when any of the events specified in the "notify-events" attribute occur. If the client does not supply this attribute in a create request, the Printer object MUST not provide any job-based notification for this job. Some notification delivery methods imply a fixed event group, and so ignore the supplied values of "notify-event-groups". These methods may be used with other methods that do not have such restrictions. Unless specified otherwise, a delivery method may be used with any event group. IPP Printer objects MUST support the 'ipp-tcp-socket' and 'ipp-udp- datagram' methods in order to conform to this notification specification. Support of the other methods is OPTIONAL. Standard uriScheme values are: 'mailto': a message is sent via email to the specified email address. The "text/plain" content format is used for this method (see Section 4.1.2). This delivery method ignores the supplied values of the "notify-event-groups" attribute and implies the 'job- completions-basic' event group ('job-completed', 'job-aborted', 'job-canceled' events). The notification recipient does not acknowledge receipt of the mail message. 'ipp-tcp-socket': an IPP notification report is sent via a TCP/IP socket that is opened by the Printer object on the IP address specified in the URI using the specified port using the "host:port" HTTP convention. For example: ipp-tcpip-socket:13.240.120.138:6000 The "application/ipp" content format is used for this method (see Section 4.1.2). 'snmpv1': a notification report is sent as an SNMPv1 trap to the host specified as the address in the URI. The notification recipient [page 7] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 does not acknowledge receipt of the notification event report (trap). 'snmpv2': a notification report is sent as an SNMPv2 inform to the host specified as the address in the URI. The notification recipient does acknowledge receipt of the notification event report (inform). 'snmpv3': a notification report is sent as an SNMPv3 inform to the host specified as the address in the URI. The notification recipient does acknowledge receipt of the notification event report (inform). 'ipp-udp-datagram': an IPP notification report is sent via a UDP datagram that is opened by the Printer object on the IP address specified in the URI using the specified port using the "host:port" HTTP convention. For example: ipp-udp-datagram:13.240.120.138:6000 The UDP datagram contains the "application/ipp" content format (see Section 4.1.2). The notification recipient does not acknowledge receipt of the notification event report. 'sense-datagram': a notification report is sent as a SENSE UDP data gram [sense] that is opened by the Printer object or notification service on the IP address specified in the URI using the specified port using the "host:port" HTTP convention. The notification recipient does acknowledge receipt of the notification event report. 4.1.2notify-event-groups (1setOf type2 keyword) The client OPTIONALLY supplies this operation attribute in a create request. The Printer object MUST support this attribute if it supports the "notify-recipients" attribute. This attribute identifies the event groups for which a notification event report is desired. If the client does not supply this attribute in a create request, but does supply the "notify-recipients", the Printer object assumes the 'job-completions- basic' event group value. There are both job events and device events. Each job event is assigned a keyword to use in the event report. For device events, the various changes in "printer-state", "printer-state-reasons", and "printer-is- accepting-jobs" are used to generate events.. Each event is assigned to one or more event groups. Each event group is assigned a keyword. The '-basic' suffix indicates that only the basic set of attributes are to be included in the event report. Standard event group keyword values are: Special event groups: 'none': no notifications of any events (an IPP object can use this value to indicate that it has no support for event notification; a client would not subscribe to this group). 'all-basic': any and all events that the implementation is capable of detecting. 'all-job-events-basic': all job events (all errors, warnings, and reports). [page 8] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 'all-device-events-basic': all device events (all errors, warnings, and reports) Job Event Groups (See section 6.1 for a description of each job event) 'job-state-changes-basic': includes 'job-received', 'job-held', 'job-released', 'job-started-processing', 'job-stopped', 'job- continued'. 'job-completions-basic': includes 'job-completed', 'job-aborted', 'job-canceled' 'job-warnings-basic': includes 'job-warning' which are any implementation-specific job warning events 'job-errors-basic': includes 'job-aborted' and any implementation- specific job errors Note: The 'job-aborted' event appears in both the 'job- completions-basic' and 'job-errors-basic' event groups, since it is both a completion and an error. Device Event Groups 'device-reports-basic': includes any event that is not a warning or an error, i.e., an event that is providing information about the device. Device-report events include: 1.the Printer's "printer-state" transitions to the 'processing' or 'idle' state 2.removal of a value from the Printer's "printer-state- reasons" attribute, such as 'toner-low-warning' or 'media- jam' 3.change of the Printer's "printer-is-accepting-jobs" attribute to 'true' 4.the device is powered up. From [ipp-mod] section 4.4.11, device reports are indicated as "printer-state-reasons" keywords with a '-report' suffix. An implementation may choose to omit some or all device-reports. Some device-reports specify finer granularity about the printer state; others serve as a precursor to a warning. A 'device- report' event MUST not indicate anything that affects the printed output. Note: Printer MIB equivalent events that fall in this report group include the alertRemovalOfBinaryChangeEntry(1801) alert that indicates that a binary change event entry row has been removed from the Alert Table and any event with the prtAlertSeverityLevel value set to noInterventionRequired(7). 'device-warnings-basic': A device-warning event is any non- critical event, i.e., non-critical alert where the Printer object's "printer-state" attribute remains in the 'processing' state and the device(s) continue to operate. Device-warning events include: [page 9] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 1.addition of an 'xxx-warning' value to the Printer's "printer-state-reasons" attribute, such as 'media-low- warning' 2.change of the Printer's "printer-is-accepting-jobs" attribute to 'false' From [ipp-mod] section 4.4.11, device warnings are indicated as "printer-state-reasons" keywords with a '-warning' suffix. Note: Printer MIB equivalent examples of device warnings include: inputMediaSupplyLow(807) and markerTonerAlmostEmpty(1104) prtAlertCode values. 'device-errors-basic': A device error is any critical event, i.e., critical alert where the Printer stops processing. Device-error events include: 1.the Printer's "printer-state" transitions to the 'stopped' state 2.addition of an 'xxx-error' (or 'xxx' that indicates a device error) value to the Printer's "printer-state- reasons" attribute, such as 'media-empty-error', 'media- empty', or 'media-jam' 3.the device is powered down. From [ipp-mod] section 4.4.11, device errors are indicated as "printer-state-reasons" keywords with an '-error' suffix or with no suffix at all. For example, 'media-jam' or 'paused'. Note: Printer MIB equivalent examples of the device errors include: jammed(8) and markerTonerEmpty(1101) prtAlertCode values. ISSUE - This simplified proposal no longer includes returning the Printer MIB alert codes, but relies on IPP "printer-state-reasons" keywords, which contain most of the Printer MIB alert codes, except for the generic ones. Ok? 5 Event Report Content Event reports are generated using the following content formats: 'application/ipp' - machine consumable content using the 'application/ipp' MIME media type [ipp-mod] using the Get-Job- Attributes response encoding for job events and Get-Printer- Attributes for device events. The attributes listed in section 5.1 are sent in a notification report for job events. The attributes listed in section 5.2 are sent in a notification report for device events. For any string in any event report, the charset and natural language rules that apply to all IPP operations apply to the event report strings as well, since they are represented as operation responses. [page 10] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 'text/plain' - human consumable content type. The text message SHOULD include information about the attributes in section 5.1 for job events or in section 5.2 for device events. If the charset to be used in the mail message is other than US-ASCII, the /charset parameter must be included in the value of this content-type header and in the event notification content [RFC2046]. The notification method dictates the content type to be used. For example, email uses "text/plain" and "ipp-tcp-socket" uses "application/ipp". 5.1 Basic Job event notification content This section lists the notification content attributes that MUST be included in any notification content for each job event group. Additional event groups can be registered which include additional attributes. However, all job event groups MUST include the following job object attributes in any job event report. All job event reports MUST use the Get-Job-Attributes response syntax. If an IPP Printer supports "notify-recipients", then it MUST support all of the following Job Description attributes: job-printer-uri (uri) - see [ipp-mod] section 4.3.3 job-id (integer(1:MAX)) - see [ipp-mod] section 4.3.2 job-last-event (type2 keyword) - see section 6.1 job-last-date-time-of-event (dateTime) - see section 6.2 job-state (type1 enum) - see [ipp-mod] section 4.3.7 job-state-reasons (1setOf type2 keyword) - see [ipp-mod] section 4.3.8 job-impressions-completed (integer(0:MAX)) - see [ipp-mod] section 4.3.21 ISSUE 2: Do we agree to this small sub-set of attributes that MUST come back in any notification content? ISSUE 3: Do we agree that these are REQUIRED for an IPP Printer to support if it supports notification at all? 5.2 Basic device event notification content This section lists the notification content attributes that MUST be included in any notification content for each device event group. Additional event groups can be registered which include additional attributes. However, all device event groups MUST include the following printer object attributes in any device event report. All device event reports MUST use the Get-Printer-Attributes response syntax. If an IPP Printer supports "notify-recipients", then it MUST support all of the following Printer Description attributes: ISSUE 4: Do we agree to this small sub-set of attributes that MUST come back in any notification content? printer-uri-supported (uri) - see [ipp-mod] section 4.4.1 printer-state (type1 enum) - see [ipp-mod] section 4.4.10 [page 11] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 printer-state-reasons (type2 keyword) - see [ipp-mod] section 4.4.11 which includes most of the Printer MIB alert codes represented as keywords printer-is-accepting-jobs (boolean) - see [ipp-mod] section 4.4.20 printer-last-date-time-of-event (dateTime) - see section 7.1 6 Job Description Attributes The following Job Description attributes are REQUIRED to be supported if the "notify-recipients" attribute is supported: 6.1 job-last-event (keyword) This attribute indicates the most recent job event that has occurred for this job. The Printer object MUST support this Job Description attribute if it supports the "notify-recipients" attribute. The Printer object supplies a copy of this attribute in every notification report that it sends to a notification recipient. This attribute is also available to any client using a Get-Job-Attributes or Get-Jobs request for this job. The first job event for a job is the 'job-received' event, so this job attribute always has a value. The standard keyword values are: 'job-received': when the Printer object accepts the create operation (i.e., when the job is created no matter whether in the 'pending' or 'pending-held' states). 'job-held': when the job enters the 'pending-held' state using some protocol operation, such as Hold-Job (see [ipp-ops1]), or the system or device holds the job because of some requirement that cannot be met and other jobs could be processed, if there are any. 'job-released': when the job leaves the 'pending-held' state and enters the 'pending' or 'processing' states due to the user, operator, or system releasing the held job using some protocol operation, such as Release-Job (see [ipp-ops1]). 'job-started-processing': the Printer starts processing the Job (i.e., when the job leaves the 'pending' state and enters the 'processing' state). 'job-stopped': The Printer stopped processing the job and the job entered the 'processing-stopped' state. 'job-continued': The Printer continues processing the job, i.e., the job leaves the 'processing-stopped' state and enters the 'processing' state. 'sheet-completed': when each sheet in the job is completed (i.e., stacked in the output bin). 'collated-copy-completed': when each document copy in the job is completed (i.e., last sheet of a collated copy is stacked in an output bin) 'job-warning': when the job encounters a condition which does not abort the job and does not require human intervention, such as the interpreter encountering a request for a missing font, but for which it is able to perform font substitution. A device warning, such as 'toner-low', is a 'device-warning', NOT a 'job-warning'. [page 12] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 'job-completed': when the job completes processing (with or without errors or warnings) and enters the 'completed' state. 'job-aborted': when the job was aborted by the system while in the 'processing' or 'processing-stopped' state, due to some encountered problem that cannot be remedied by human intervention. 'job-canceled': when the job was canceled by the user or operator using the Cancel-Job operation while the job was in any state. 6.2 job-last-date-time-of-event (dateTime) This attribute indicates the point in time at which the most recent job event occurred for this job. The Printer object MUST support this Job Description attribute if it supports the "notify-recipients" attribute. The Printer object supplies a copy of this attribute in every notification report that it sends to a notification recipient. This attribute is also available to any client using a Get-Job-Attributes or Get-Jobs request for this job. The first job event for a job is the 'job-received' event when the job is created. Therefore, this job attribute always has a value. If IPP Printers relay jobs to other IPP Printers, the time of the event is intended to be at the IPP Printer object at which the event occurred, not subsequent times of relaying jobs in the forward direction or relaying notifications in the reverse direction. ISSUE - Ok to have changed the data type to dateTime, so that there is no ambiguity when relaying notifications from server to server? 7 Printer Description Attributes The following Printer Description attributes are REQUIRED to be supported if the "notify-recipients" attribute is supported: 7.1 printer-last-date-time-of-event (dateTime) This attribute indicates the point in time at which the most recent printer event occurred for this printer. The Printer object MUST support this Printer Description attribute if it supports the "notify- recipients" attribute. The Printer object supplies a copy of this attribute in every notification report that it sends to a notification recipient. This attribute is also available to any client using a Get- Printer-Attributes request for this Printer object. The first printer event for a Printer is when it is powered up. Therefore, this printer attribute always has a value. ISSUE - Ok to have changed the data type to dateTime, so that there is no ambiguity when relaying notifications from server to server? 7.2 notify-recipients-schemes-supported (1setOf uriScheme) This attribute describes the notification methods supported by this Printer object. Standard values are defined in Section 4.1.1). [page 13] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 7.3 notify-event-groups-supported (1setOf type2 keyword) This attribute describes the event groups supported by this Printer object. If no event groups are supported, then the Printer object either supports this attribute with only the 'none' value, or does not support this attribute at all. Standard values are defined in Section 4.1.2) 8 References [draft-prtmib] Turner, R., "Printer MIB", , work in progress, March 1998. [ipp-mod] deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P., "Internet Printing Protocol/1.0: Model and Semantics", < draft- ietf-ipp-model-11.txt>, work in progress, November 16, 1998. [ipp-ops1] Bergman, R., Hastings, T., Herriot R., Moore, P., "Internet Printing Protocol/1.0: Additional Optional Operations - Set 1", , work in progress, October 23, 1998. [ipp-sub] Isaacson, S., Martin, J., deBry, R., Hastings, T., "Job Independent Subscriptions for IPP", , work in progress, July 1, 1998. [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. [RFC2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed & N. Borenstein. November 1996. (Obsoletes RFC1521, RFC1522, RFC1590), RFC 2046. [sense] Martin, J. et all., "System Event Notification System Environment (SENSE)", ftp://ftp.pwg.org/pub/pwg/sense/, work in progress, Spring 1996. 9 Issues 1.Do we want a Mixed Format for event reports? If so we can add 'multi-part/alternative' back in as a supported format. 2.Do we want to extended the list of uriScheme values defined for standard delivery methods to include: 'ftp', 'pager', 'http', etc.? If so, they are easy to add. Should we add them now? Or register them later? [page 14] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 3.Should we make "notify-recipients" and "notify-group-events" also be a Job Description attributes, so that a user can query to determine what subscriptions were supplied (and help an implementation remember job submission subscriptions on the job object - useful whether the implementation is using a notification service or not), as we have done for attributes-charset and attributes-natural-language operation attributes? 4.Should we combine the "Job Independent Subscription" paper with this paper, or leave them as separate specifications? 10 Change History Changes are listed in reverse chronological order: 10.1Changes made from the July 1, 1998 to 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 notification 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 [page 15] IPP Event Notification (Very Short) Version 0.4 December 10, 1998 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 device state changes. 9.Added the complete semantics for each job event under the "last-job- event" Job Description attribute. [page 16]