IPP> Notifiaction spec [fixed contents]

IPP> Notifiaction spec [fixed contents]

IPP> Notifiaction spec [fixed contents]

McDonald, Ira imcdonald at sharplabs.com
Fri Jul 21 11:14:12 EDT 2000


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






More information about the Ipp mailing list