Although I'm always in favor of basic conservation of bandwidth and network
overhead, at this point in the life of IPP, I'm not sure it is meaningful to try
and package notifications for shipment in tight quarters. If we do focus on this
exercise, I think we should spend some time, first, agreeing on exactly what we
expect to accomplish with the UDP payload.
You have a good point regarding interoperability. Perhaps, then, if nothing
else, the UDP case leads us to definition of the minimum subset for
notifications. If this is the case, I think the entire current description of
payload is up for grabs.
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
Ira Mcdonald <imcdonal@sdsp.mc.xerox.com> on 10/07/99 08:25:32 AM
To: ipp@pwg.org
cc:
Subject: Re: IPP> Proposal for change to notification content
Hi Dennis,
I see the 'gas gauge' argument as reasonable. But the transporting
of static information in an event notification really isn't a very
good idea.
And it will also add three more attributes that must be packed into
restricted size messages for delivery through instant messaging,
pagers and PDAs, and any connectionless transport (like UDP)
no matter WHAT application layer protocol is used.
Or we leave these out of some transport mappings for IPP
notifications, right? Only this whole idea that it's
very transport mapping specific how much of the ten
tons of information you actually get in event
notification messages is a bad one. It totally breaks
interworking across differing notification schemes
(which could be important when a proxy is in the middle
talking IPP in both directions for job control).
So, on balance, I'd say I vote 'no' on these three additions.
(Note that the originating application or print driver
knows perfectly well how many pages are in the document
and doesn't need to ask the IPP Printer for that info
anyway to build a 'gas gauge'.)
Cheers,
- Ira McDonald
High North Inc