We hurried the final proof reading a little too much in order to give people
copies of the spec before they left for vacations this Friday. We found a
small number of small glitches in what we posted yesterday. So we've
re-posted the documents tonight. Sorry about that. The issues and change
history are unchanged.
There is a version with revisions to show these minor fixes from the June 29
version posted yesterday. There won't be any further updates, except to
resolve the issues in the document and any other issues raised by you.
Please read this document. Initial feedback is that it is greatly improved
from the May version. It should significantly help implementers for the
interoperability bakeoff in October.
The files are available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000630.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000630.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000630-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000630-rev.pdf
Tom and Bob
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Thursday, June 29, 2000 02:37
To: ipp
Subject: IPP> NOT - Notification Specification posted
Bob and I have gone over the Event Notification Spec with a fine toothed
comb and have made an effort to shrink the size of the document. The
important part of the specification is contained in the first 55 pages.
There is no version with revision marks, since the document was edited so
heavily. The Change History is shown below. There are also 7 minor issues,
mostly asking to see if you agree with additions or changes we made in
carrying out the agreements from the NYC meeting and telecons.
The files are located at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000629.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000629.pdf
Changes to the May 10, 2000 version to create the June 29, 2000
version
The following changes were made to the May 10, 2000 version to create the
June 29, 2000 version based on the agreements reached at the May IPP WG
meetings and subsequent teleconferences:
1. Editorially reorganized and revised the document so that information
is stated only once. Moved supplementary material to appendices.
2. Cleaned up the terminology so that it is used consistently
throughout the document; capitalized such terms. Simplified the
descriptions of each term.
3. Recast the Subscription attributes to be Subscription Template and
Subscription Description attributes following the IPP/1.1 model for Jobs.
Therefore, a few attribute names were changed to make them consistent.
4. Reworked the operation descriptions to align with the style in
[ipp-mod].
5. Made the validation and processing of Subscription Template
attributes be the same for Job Creation Operations,
Create-Job-Subscriptions, and Create-Printer-Subscriptions operations (and
defined in one place) and as similar to validation of jobs as possible
(though there are some differences since one request can generate multiple
Subscription objects.
6. Clarified the error handling for all operations.
7. Removed the "notify-text-format" and "notify-additional-formats"
Subscription Template attributes and added the "notify-job-id" Subscription
Description attribute.
8. The client can supply one or more Subscription Template Attribute
Groups in all Subscription Creation requests and the printer returns
Subscription Object Attributes groups for each Subscription object created.
Consequently, an "s" was added to Create-Job-Subscriptions and
Create-Printer-Subscriptions operations.
9. Reorganized the Events, so that some of the Events represent a group
of events and the rest are sub-events. This reduces the number of
Subscribed Events that a Printer needs to support in one Subscription from 5
to 2. It also means that the event that is delivered is one of the
Subscribed events, not necessarily the trigger event, so
"notify-trigger-event" was renames to "notify-subscribed-event" in the Event
Notification.
10. Added the 'printer-full' and 'printer-not-almost-idle' Events to go
along with the 'printer-no-longer-full' and 'printer-almost-idle' Events.
Renamed the 'printer-queue-changed' Event to 'printer-queue-order-changed'.
11. Clarified what MUST be in a Delivery Method Document.
12. Removed "persistent-jobs-supported" Printer Description attribute,
since it has nothing to do with Notifications and is not needed to describe
Subscription object persistence.
13. Changed notify-max-printer-subscriptions-supported (integer(0:MAX))
and notify-max-job-subscriptions-supported (integer(0:MAX)) so that MAX
means no limit and 0 means no subscriptions are (currently) allowed, so as
to give a way to turn off accepting new subscriptions.
Here are the remaining issues:
ISSUE 01: OK that we changed the minimum number of events that a Printer
MUST support in a Subscription object from 5 to 2 because we have rearranged
the categories of Events to have group events?
ISSUE 02: OK that we added the 'printer-full' Event?
ISSUE 03: OK that we added the 'printer-not-almost-idle' Event?
ISSUE 04: it would be better for the "notify-persistence" (boolean)
Subscription Template attribute to be changed to be a Subscription
Description attribute instead, that the Printer sets to show whether the
Object is persistent or not. Agree?
ISSUE 05: OK that we added the REQUIRED "notify-job-id" attribute because it
is needed for a Notification Recipient to determine from a random
subscription-id whether a Subscription is Per-Printer or Per-Job and if the
latter which Job.
ISSUE 06 & 07: We changed notify-max-printer-subscriptions-supported
(integer(0:MAX)) and notify-max-job-subscriptions-supported (integer(0:MAX))
so that MAX means no limit and 0 means no subscriptions are (currently)
allowed, so as to give a way to turn off accepting new subscriptions. OK to
use MAX to mean no limit and 0 to mean that an admin has turned off
subscriptions?
Send comments to the mailing list.
Tom and Bob
This archive was generated by hypermail 2b29 : Fri Jun 30 2000 - 04:24:33 EDT