ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990807.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990807.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990807-rev.
doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-new-model-990807-rev.
pdf
This document is a new proposal to simplify the IPP Notification Model. It
uses Harry Lewis's suggested terminology of Per-Job subscriptions and
Per-Printer subscriptions. The Subscription object is defined only for use
as Per-Printer subscriptions. Per-Job subscriptions are done entirely with
Job attributes and use an exclude event mask (like SNMPv3 trap
subscriptions) in order to allow different recipients to get different
events. I've also added conformance requirements for operations and
attributes, so that we can more properly reason about the model, before
updating the specification document.
This document also includes the results of the 8/4/99 IPP telecon.
There are 17 issues highlighted like this that need to be resolved.
This paper uses object modeling techniques to describe the current IPP
Notification Specification object model (July 22, 1999):
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990722.pdf
Review of this object model before writing the complete spec will help speed
up the production of the spec and will also help with the understanding of
the semantics. I suggest that this modeling be kept in the final spec in
some form similar to this paper.
This paper also gives an outline of how the final spec might be presented,
including being divided into two parts. After describing the additional
object attributes for the Job, Printer, and Subscription objects, the order
of the spec is suggested to be:
1. the REQUIRED first part (sections 5, 6, and 7) defines the
extensions to the Job and Printer object and its operations for Per-Job
subscriptions of Job and Printer events and their notification content.
2. the OPTIONAL second part (section 8) defines the Per-Printer
subscription mechanism and the Subscription object and its operations and
attributes.
NOTE - Throughout this model document, the notation [ ] indicates
that the sender (client in a request, IPP object in a response, notification
sender in a notification) MAY omit the attribute inside the square brackets
if there is not data to send. In addition, IPP Printer conformance
requirements for operation and attribute support are indicated in this
document with the words and codes:
REQUIRED (R) to support notification at all
CONDITIONALLY REQUIRED (C) - REQUIRED if Per-Printer
subscription is supported
OPTIONAL (O) - not required for either Per-Job or
Per-Printer Subscriptions.
Therefore, the [ ] do NOT mean OPTIONAL support and should not be
confused with support requirements.