I dont think we will have many to bake off anyway given then complexity of what
we have ended up with.
Maybe I am being naive but it doesnt seem to hard to come up with a set of event
paramters for all events
printer events:-
name,date time, printer state, printer state reason
Job events:-
jobid, job state, job state reason, current page number
I dontunderstand how making the paranter set variable helps UDP messages - I
would have though it made it worse. The client can request a huge number of
attributes that will overflow the packet. With fixed format events at least the
is a good chance of fitting them into one message.
"McDonald, Ira" <imcdonald at sharplabs.com> on 07/21/2000 08:14:12 AM
To: "'pmoore at peerless.com'" <pmoore at peerless.com>, ipp at pwg.org
cc: (bcc: Paul Moore/AUCO/US)
Subject: RE: IPP> Notifiaction spec [fixed contents]
Hi Paul,
A fixed set of notification contents is what we DID have
until recently - the set grew larger and larger by the
usual committee process - it became impossible to send
machine-readable conformant notifications in many existing
notification protocols (eg, SNMP) which typically operate
over connectionless transports.
So we threw OUT all the fixed bindings and let the client
request attributes. The IPP Printer always explicitly
advertises which attributes may be requested in the
notifications, so there is no ambiguity.
If we go back to fixed notification content, we'll take
another six months to agree on the list (if ever...) and
we won't have ANY notification delivery methods to test
at the IPP/1.1 Bakeoff in October 2000. That would be bad!
Cheers,
- Ira
-----Original Message-----
From: pmoore at peerless.com [mailto:pmoore at peerless.com]
Sent: Thursday, July 20, 2000 9:01 AM
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.
I would like to propose a significant simplification of the notifications
spec.
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:-
The subscription objects are variable in size
The validation of the subscription request is more complex
The generated messgaes have a varying structure
The size of events varies significatnly (for some notifiaction methods based
on
UDP this may be important)
We have to define the behavior of the system in the case where the requested
attribute(s) dont exist on the printer
For human readable messages it is not clear what this means exactly
Just thing of the 400 extra test cases that Tom is going to dream up :-)
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