attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0"> <TITLE>NOT - Updated notification extension posted</TITLE> </HEAD> <BODY> I've updated the notification proposal with the agreements from the San Diego meeting, Dec 16-17, 1998. They are in: <A HREF="ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118-rev.doc" TARGET="_blank">ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118-rev.doc</A> <A HREF="ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118-rev.pdf" TARGET="_blank">ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118-rev.pdf</A> <A HREF="ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118.doc" TARGET="_blank">ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118.doc</A> <A HREF="ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118.pdf" TARGET="_blank">ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118.pdf</A> Here is the change history: 1.1     Changes to the December 10, 1998 to make the January 19, 1999 version The following changes made to the December 10, 1998 to make the January 19, 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-device-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 "device-trigger-event", REQUIRED "job-id", and OPTIONAL "status-message" to the device event report content. 12.     Specified the "device-trigger-event" Printer Description attribute, naming each event. 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. There are 30 issues listed in the document highlighted.  Most of them are small.  We will go over them at the meeting this week and issue an updated spec immediately for mail list comment. Here are the issues: <UL><UL> ISSUE 1 - What is the default port for this method? ISSUE 2 - Are the origin and destination ports the same or not? ISSUE 3 - Ok that the notification recipient doesn't respond or acknowledge the event report? or should it? ISSUE 4 - Are these 3 SNMP notification delivery methods ok to keep? ISSUE 5 - What is the default port for this method? ISSUE 6 - Are the origin and destination ports the same or not? ISSUE 7 - Ok that the notification recipient doesn't respond or acknowledge the event report? or should it? </UL> 'ndps-notify': an IPP notification report is sent via NDPS notification mechanism.  See ???. <UL> ISSUE 8 - Need reference to NDPS documentation.  Also need more description here, such as which end opens, does the recipient acknowledge, and any salient information about the transport. </UL></UL> ISSUE 9 - This simplified proposal no longer includes returning the Printer MIB alert codes, but relies on "device-trigger-event' and IPP/1.0 [ipp-mod] "printer-state-reasons" keywords, which contain most of the Printer MIB alert codes, except for the generic ones.  Ok? ISSUE 10 - How can an event recipient tell the difference between a job event and a device event, if both have been subscribed to?  Is looking whether "job-trigger-event" versus "device-trigger-event" is present in the event content ok? ISSUE 11 - Which of the above attributes are sent as Operation Attributes and which are included as Job Attributes in the Get-Job-Attributes response format? ISSUE 12 - Should we define a new operation, say Send-Event (or Send-Job-Event?), which has a format that we specify and so that the event recipient can respond when required to using an IPP operation response depending on the subscription? ISSUE 13 - The data type of "job-trigger-date-time" (dateTime) is needed, so that there is no ambiguity when relaying notifications from server to server which may cross time zones?  Proper date and time is especially important when notification is used with IFAX.  However, for low end implementations, knowing the date is a burden, even though the date is sent by the client in every HTTP request header. ISSUE 14:  Do we agree to this small sub-set of attributes that MUST be sent in any job event report content?  <UL> job-printer-uri (uri)  - see [ipp-mod] section 4.3.3 job-id (integer(1:MAX))  - see [ipp-mod] section 4.3.2 job-trigger-event (type2 keyword)  - see section 6.1 job-trigger-date-time (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 status-message (text(255)) - see [ipp-mod] section 3.1.6 OPTIONAL job-impressions-completed (integer(0:MAX))  - see [ipp-mod] section 4.3.21 OPTIONAL </UL> ISSUE 15:  Do we agree to the ones that are REQUIRED for an IPP Printer to support if it supports notification at all?  ISSUE 16:  Do we agree to this small sub-set of attributes that MUST be sent in any device event report content?  <UL> printer-uri-supported (uri)  - see [ipp-mod] section 4.4.1 job-id (integer(1:MAX)) - the job id of the current job processing on the printer. device-trigger-event (keyword) - the event that caused this notification - device-trigger-date-time (dateTime)  - see section 7.1 printer-state (type1 enum)  - see [ipp-mod] section 4.4.10 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 status-message (text(255)) - see [ipp-mod] section 3.1.6   OPTIONAL </UL> ISSUE 17 - How can an event recipient tell the difference between a job event and a device event, if both have been subscribed to?  Is looking whether "job-trigger-event" versus "device-trigger-event" ok? ISSUE 18 - Which of the above attributes are sent as Operation Attributes and which are included as Job Attributes in the Get-Printer-Attributes response format? ISSUE 19 - Should we define a new operation, say Send-Event (or Send-Device-Event?) which has a format that we specify and so that the event recipient can respond using an IPP operation response when required to depending on the subscription? ISSUE 20 - The data type of "device-trigger-date-time" (dateTime) is needed, so that there is no ambiguity when relaying notifications from server to server which may cross time zones?  Proper date and time is especially important when notification is used with IFAX.  However, for low end implementations, knowing the date is a burden, even though the date is sent by the client in every HTTP request header. ISSUE 21 - Ok to omit the "job-id" attribute, rather than overloading the out-of-band 'no-value' which is only for when the system administrator has not configured a value?  See [ipp-mod] section 4.1. ISSUE 22 -  Do we agree to this small sub-set of attributes that MUST be sent in any event report content?  ISSUE 23 -  Do we agree to the ones that are REQUIRED for an IPP Printer to support if it supports notification at all?  ISSUE 24 - Ok to have changed the data type to dateTime, so that there is no ambiguity when relaying notifications from server to server which may cross time zones?  Proper date and time is especially important when notification is used with IFAX.  However, for low end implementations, knowing the date is a burden, even though the date is sent by the client in every HTTP request header. ISSUE 25 - Ok to have changed the data type to dateTime, so that there is no ambiguity when relaying notifications from server to server which may cross time zones?  Proper date and time is especially important when notification is used with IFAX.  However, for low end implementations, knowing the date is a burden, even though the date is sent by the client in every HTTP request header. 26.     Do we want a Mixed Format for event reports?  If so we can add 'multi-part/alternative' back in as a supported format. 27.     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? 28.     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?  29.     Note:  since job-independent subscriptions have the time-to-live parameter, there is no need to have Printer Description attributes that list the current job-independent subscriptions, correct? 30.     Should we combine the "Job Independent Subscription" paper with this paper, or leave them as separate specifications?  Tom Hastings (310) 333-6413 </BODY> </HTML>