"IPP Event Notification (Very Short)", version 0.3:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701-re
v.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-980701-re
v.pdf
"Job-Independent Subscriptions for IPP", version 0.3:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701-rev.pdf
I'll bring copies with me to the Monterey meeting next week. They are still
short: 12 pages and 5 pages.
Summary of Changes
------------------
For "IPP Event Notification (Very Short)", version 0.3 (12 pages):
1. In Washington, we agreed to get rid of collections all together, and pass:
notify-event-groups (1setOf type2 keyword)
notity-recipients (1setOf uri)
as individual subscription operation attributes in a create job operation.
These are not parallel attributes. All event group apply to all recipients,
except:
2. Fix the events for the mailto: delivery method to just job-completion
(completed, aborted, canceled). Then other delivery methods can be used
with mailto and specify event groups for those other delivery methods.
Then the event groups only apply to the other delivery methods. This
ad hoc handling of mailto: allows us to get rid of using the collection
attribute syntax while allows a job to have multiple notification recipients,
some with mailto: and some not. All the others will be subscribed to the
same event groups.
[If this approach isn't satifactory, we could further simplify the very short
specification use of 'collection' and have each member attribute only
be single values, not multi-valued. If more than one event group is needed,
then supply another collection value. The "subscriptions" attribute would
be a multi-valued collection where each collection value is:
notify-event-groups (type2 keyword)
notify-recipients (uri) ]
4. Also we did agree in Washington to add 'ipp-udp-datagram' that didn't
have acknowledgement, because the 'sense-datagram' did.
5. We agreed to make the 'ipp-tcp-socket' and 'ipp-udp-datagram' delivery
methods REQUIRED for IPP Printer objects conforming to the notification
specification.
5. I also changed the word printer to device when it did not relate to the
IPP Printer object, so that we can use this for other types of devices
that the IPP Printer object might control, such as scanners and fax devices.
This is in alignment with the MIB access paper. Ok? If you disagree, I'll
change it back.
6. I added the fixed table of job and printer attributes to be included
in the notirfication content for job and device events and listed as an
issue whether there was agreement on these or not.
7. I removed half of the issues at the end and added one.
All issues are highlighted. Here they are:
ISSUE 1: Now that "notify-event-groups" and "notify-recipients" are
separately specified, we need to say what happens when each is specified
without the other. We could say that the "notify-event-groups" defaults to
'job-completion', but only if "notify-recipients" is supplied. If
"notify-event-groups" is supplied without "notify-recipients", then the IPP
Printer object rejects the create operation and returns the
'client-error-bad-syntax' status code. Ok?
ISSUE 2: Do we agree to the fixed attributes that come back in
notification content in Table 1 and Table 2?
ISSUE 3: Do we agree that these are REQUIRED for an IPP Printer to support?
Issues at the end of the document:
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 allow the client to specify the format of the event report
independent of the delivery method? If so, we can add
"notify-content-type" back into the "subscriptions" attribute.
3. 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?
4. Should we make "subscriptions" also be a Job Description attribute, 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?
For "Job-Independent Subscriptions for IPP", version 0.3 (5 pages):
I also updated the second short paper, "Job Independent Subscriptions for IPP"
based on the agreements reached in Washington:
1. Added a third operation: Renew-Subscription.
2. Added a third operation attribute for use with SubScribe only:
"notify-lease-time (integer(0:MAX)) - time to live in minutes before
subscription is automatically canceled.
3. Added 'client-error-not-found' status code is returned if the subscription
id is not found (or has expired).
4. Added 'server-error-temporary-error' status code is returned if the
Printer or subscription service is full or cannot otherwise accept the
subscription due to a condition that is likely to go away soon enough that
the client should try again shortly.
The following issues need to be addressed:
1. If the IPP Printer is forwarding Subscribe operations to a notification
service which rejects the subscription, is there any way the IPP Printer can
return that implementation specific error condition back to the client? Or
is
it better for the IPP Printer to map the error codes to standard IPP error
status codes for interoperability?
2. Should we allow for an "Unsubscribe ALL" feature in some operation?
3. Should we define subscription service events? Such as: "subscription-about-
to-expire", "subscription-expired", "are-you-alive" notification events as an
additional event group, say 'subscription-events'? The notification
recipient
would have to know to issue the Renew-Subscription operation, (not the
original
client). The 'subscription-events' event group would be one that is
available
with the Subscribe operation, but not create operations, correct?
I'll bring copies of these documents with and without revision marks.
They are short and we've seen them at previous meeting.
Tom