I again acknowledge the force of your argument.
But mine's on a different wavelength.
As a design principle, static information shouldn't be included
in a notification, no matter what the methodology of delivery.
All IPP notifications are unacknowledged and NOT retried.
Any monitoring client practically speaking MUST do some
level of polling of relevant data from the Printer or Job
anyway. Static data should be acquired then.
I also agree with Harry that the whole question of the validity
of the current set of Printer and Job event bindings is open.
It's woefully easy to justify each little bit of baggage
individually. The proof is when you carry it a mile to
the train station...
Actually UDP is a big roomy constraint, by comparison to
Instant Messaging from AOL, and GSM SMS (Short Message
Service) in the public cellular infrastructure, and
other *small* payloads.
Harry's point that IPP chose the road of long, readable
(to English speakers) attribute names over the wire.
That may well have been a foolish choice. It certainly
cries out for a list of *short* tags for all the few
attributes that actually are considered for the Printer
or Job event bindings.
(By the way, an Internet standard OID for an SNMP binding
is about 10 octets long - one third the length of many
of the current event bindings names)
Cheers,
- Ira