snip...
3. I disagree with the (evidently) prevailing perspective regarding UDP.
> For "per page" event notification, it is suggested that
>TCP connections should be used.
The bad thing about per page notification is there are so many of them.
The nice thing about per page notification is there are so many of them.
The multiplicity of per page notifications provides a natural redundancy
such
that
a. If you drop a few you can always "catch up"... after all... it's just a
progress
indicator. How many times has your web browser given you misleading
"progress" (14 sec remaining for the last 2 minutes) yet you'd rather
have this than no progress at all
b. There are multiple opportunities to deliver the notification "payload".
Thus, information IN the payload that might be crucial to identifying
the job, user, etc... is insured by redundancy rather than by
session and packet guarantee.
c. These are small payloads. If congestion gets so bad that redundancy
is failing... we're probably not doing much printing, either.
TH> Some of us have suggested that what we should really be thinking of for
UDP, is an SNMP trap binding. We're working on such a "MIB" that contains
just an SNMP trap binding that contains the stuff we have in the current
Notification spec (with extra attributes allows as in SNMP traps). So
instead of inventing a bare UDP, we use standard SNMP to delivery the
notification trap (over UDP as SNMP is spec). How does that sound to you?
We'd probably need to register a URL scheme, something like SNMP-IPP, with
IANA.
How does that sound?
Tom