I've updated the Notification Specification as agreed at the February IPP WG
meeting and on the mailing list. The documents are available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000306.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000306.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000306-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000306-rev.pdf
There are 5 minor issues (and one major one). I'd like to resolve all but
ISSUE 02 before making the next Internet-Draft Wednesday or Thursday. We
want to do an IPP WG Last Call on that Internet-Draft.
Here are the issues:
ISSUE 01 - Ok to include the notification delivery scheme names 'ipp:',
'indp:', 'mailto:', and 'snmp:' that are in progress as example values of
the "notify-recipient" (uri) attribute?
ISSUE 02 - Once a number of delivery solutions have been developed and
evaluated, we may want to make one or several of them REQUIRED for
implementation to ensure a minimum set of interoperability. Which one or
ones should be REQUIRED?
ISSUE 03: OK to allow the "persistent-jobs-supported" (boolean) Printer
Description attribute to be settable?
ISSUE 04: OK to allow the "persistent-subscriptions-supported" (boolean)
Printer Description attribute to be settable?
ISSUE 05 - Can an implementation extend the Notification Content to include
an attribute that uses the 'collection' attribute syntax? If so, should we
REQUIRE that Notification Recipients that can accept Machine Consumable
Notifications, be able to accept the 'collection' attribute syntax?
ISSUE 06: Ok that "notify-charset" and "notify-natural-language" member
attributes don't follow the "xxx-supported" rule for collection member
attributes, since the "xxx-supported" attributes are "charset-supported" and
"generated-natural-language-supported", respectively, instead of
"notify-charset-supported" and "notify-natural-language-supported"?
18.1 Changes to the February 2, 2000 version to create the March 6, 2000
version
The following changes were made to the February 2, 2000 version to create
the March 6, 2000 version based on the agreements reached on the mailing
list, at the February IPP WG meetings, and reflected in the minutes:
1. Clarified that this extension is intended as an extension to
IPP/1.0, IPP/1.1, and future versions.
2. Allocated the operation-id 0x0016 to 0x001B values for the
Notification operations defined in the document.
3. Pre-pended the word "subscription-" on the front of the "request-id"
Subscription object attribute to distinguish it from the "request-id"
parameter that is sent in every request and response.
4. Added the term "settable" for describing attributes that are not
READ-ONLY.
5. Added the term "Subscription Creation operation" to stand for any
operation that can create a Subscription object: Job Creation operations
(Create-Job, Print-Job, and Print-URI), Create-Job-Subscription, and
Create-Printer-Subscription.
6. Changed the "subscriber-user-name" (name(MAX)) Subscription object
attribute from OPTIONAL to REQUIRED.
7. Changed the name and semantics of
"notify-printer-up-time(integer(1:MAX)) to notify-server-up-time so that it
can be either the Printer's uptime or a Notification Delivery Service
uptime.
8. Added the 'ipp:', 'indp:', 'mailto:, and 'snmp:' notification
delivery schemes to the definition of the "notify-recipients" to indicate
possible schemes.
9. Changed the name and semantics of "notify-text-format"
(mimeMediaType) to "notify-format" so that it can be used to specify either
Human Consumable or Machine Consumable formats where the implementation
supports both. Clarified that this attribute controls whatever variable
Notification Content that the implementation supports, which may be an
attachment to the fixed content format or the contents of the
"human-readable-report" (text(MAX)) attribute. Clarified that an
implementation NEED NOT support all of its supported Notification Content
formats with all of its supported delivery methods.
10. Added 'text/xml', 'application/ipp', 'application/postscript', and
'image/tiff' and additional example MIME media types for "notify-format"
(mimeMediaType).
11. Clarified that the recommend way for a client to determine whether
or not a Printer supports Per-Job Subscriptions is to query the Printer's
"max-job-subscriptions-supported" attribute, since Create-Job-Subscriptions
is an OPTIONAL operation.
12. Clarified that the recommend way for a client to determine whether
or not a Printer supports Per-Printer Subscriptions is to query the
Printer's "operations-supported" attribute to see if the
Create-Printer-Subscriptions operations is supported, since this is the
usual way to determine a Printer's capabilities.
13. Clarified that if "persistent-jobs-supported" (boolean) and
"persistent-subscriptions-supported" (boolean) are settable, then setting
them must affect whether or not jobs and subscriptions are persistent.
14. Allowed delivery methods to send operations with or without a
response, depending on the definition of the delivery method.
15. Indicated that a deliver method definition is free to REQUIRE that
the client supply the "subscriber-user-data" attribute.
16. Required that the Printer support the "job-uri" operation attribute
as a target, in addition to "printer-uri"&"job-id", i.e., keep consistent
with all Job operations.
17. Changed the 'none' out-of-band value to be a reference to the
collection document [ipp-coll], since the use for it in this document is
with the 'collection' attribute syntax.
18. Clarified that a conforming implementation MUST support the
'collection' attribute syntax, since that is required in Job Creation
operations.
19. Allocated the values to the new status codes defined in this
document.
20. Allocated the [ipp-pro] subscription-attributes-tag and
notification-attributes-tag delimiter tags to delimit Subscription
attributes and Notification Content attributes in requests and responses.
21. Changed the 'server-error-too-many-subscriptions' and
'server-error-too-many-events' to be client errors, i.e.,
'client-error-too-many-subscriptions' and 'client-error-too-many-events',
since other errors of this type are client errors.
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 20:24:12 EST