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-notifications-very-short-990118-re
v.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118-re
v.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118.do
c
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118.pd
f
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 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?
'ndps-notify': an IPP notification report is sent via NDPS
notification mechanism. See ???.
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.
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?
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
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?
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/19990119/934d17a3/attachment-0001.html