IPP Mail Archive: IPP> NOT - Updated notification extension posted

I've updated the notification proposal = with the agreements from the San Diego meeting, Dec 16-17, 1998.

They are in:

ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification= s-very-short-990118-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification= s-very-short-990118-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification= s-very-short-990118.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification= s-very-short-990118.pdf

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:

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? 

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? 

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