Paul,
Here are some replies to your comments, preceded by TH>.
Tom
-----Original Message-----
From: pmoore at peerless.com [mailto:pmoore at peerless.com]
Sent: Thursday, July 20, 2000 09:01
To: ipp at pwg.org
Subject: IPP> Notifiaction spec
I apologize if a) this is too late or b) if this is the wrong list.
TH> This is the right list. The spec has changed in the direction of your
comments during the past year.
I would like to propose a significant simplification of the notifications
spec.
TH> See below, since your simplification boils down to remove 3 values from
Job events and 3 other values from Printer events and send only the 10
REQUIRED pieces of data.
In the current spec it is possible for the subscriber to say what info they
want
in the notification. The adds many layers of complexity that are I beleive
unnecessary:-
TH> Section 5.3.3 says "notify-attributes" MAY be supported by the Printer
and only for Machine Consumable. It is NOT required by [ipp-ntfy] and
neither 'indp' nor 'mailto' Delivery Method REQUIRES it.
The subscription objects are variable in size
TH> Yes, there is some variation depending on whether the event is a Job or
Printer event (and for Job events whether it is
'job-completed'/'job-progress' add another item).
The comparison for Machine Consumable can best by seen in
'ipp-not-spec-for-IIG-000714-rev.* (in .zip and new_NOT):
10 always REQUIRED (SNMP has 6 which are supplied by SNMP headers or are
fixed)
3 extra for all job events (job-id, job-state, job-state-reasons)
plus "job-impressions-completed" for 'job-competed' (REQUIRE event) and
'job-progress' (OPTIONAL event)
(SNMP has a lot more for the OPTIONAL 'job-progress' event)
3 extra for all printer events (printer-state, printer-state-reasons, and
printer-is-accepting-jobs).
The validation of the subscription request is more complex
TH> The validation is the same for all Subscription Creation Operations and
for all Delivery Methods. It was a goal that the validation could be
independent of the Delivery Method, so that Delivery Methods could be
plug-in modules.
The generated messgaes have a varying structure
TH> True, but we reduced the variability considerably and made it OPTIONAL
for the Printer to support "notify-attributes" which causes greater
variability (if supported).
The size of events varies significatnly (for some notifiaction methods based
on
UDP this may be important)
TH> True, but the SNMP Delivery Method fits with the shortest UPD packets of
487(?) octets.
We have to define the behavior of the system in the case where the requested
attribute(s) dont exist on the printer
TH> They are returned in the response as Unsupported attributes, like all
other IPP operations.
For human readable messages it is not clear what this means exactly
TH> Section 5.3.3 says that "notify-attributes" is only for Machine
Consumable, so mailto will ignore it.
Just thing of the 400 extra test cases that Tom is going to dream up :-)
TH> I won't, but Quality Logic should.
My proposal is to simplify by defining the attributes (a minimal set) that
each
event always sends. In many cases I expect this to me nothing extra beyond
the
set that are always required (printer name , subscription id, job id, etc.)
If
the client wants more it can query
TH> You are saying always send the 10 REQUIRED ones, but not the 3 extra
ones (4 for 'job-progress' and 'job-completed'. Is this really a big enough
gain?