Err..umm... seems I remember making this point several years ago. Lot's of IPP
under the bridge since!
Harry Lewis
IBM Printing Systems
harryl at us.ibm.comdon at lexmark.com on 10/08/99 05:34:13 AM
To: Harry Lewis/Boulder/IBM at IBMUS
cc: imcdonal at sdsp.mc.xerox.com, ipp at pwg.org
Subject: Re: IPP> Proposal for change to notification content
No wonder the internet has bandwidth problems.... when something that can be
encoded in one strategically placed bit is instead turned into a 30 character
ascii string largely of underscores simply for human readability during debug
sessions with telnet......
**********************************************
* Don Wright don at lexmark.com *
* Director, Strategic & Technical Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
harryl%us.ibm.com at interlock.lexmark.com on 10/07/99 06:30:14 PM
To: imcdonal%sdsp.mc.xerox.com at interlock.lexmark.com
cc: ipp%pwg.org at interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
Subject: Re: IPP> Proposal for change to notification content
Ira, there was a day (it was back during development of the Job MIB)... when I
argued for keeping everything "tight" so it could all fit into one UDP packet.
In addition to laughing me out of the room for daring to mention SNMP traps in
the context of job monitoring... IPP went on to become quite verbose in it's
expression (stopping short of XML, of course ;-).
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 at us.ibm.com
Ira Mcdonald <imcdonal at sdsp.mc.xerox.com> on 10/07/99 08:25:32 AM
To: ipp at 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