SNMP trap binding sounds like the right approach to me.
IBM Printing Systems
harryl at us.ibm.com
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 08/04/99 10:59:36 AM
To: Harry Lewis/Boulder/IBM at IBMUS, "Manros, Carl-Uno B"
<cmanros at cp10.es.xerox.com>
cc: IETF-IPP <ipp at pwg.org>, "Moore, Keith" <moore at cs.utk.edu>,
?iso-8859-1?Q?F=E4ltstr=F6m at westrelay02.boulder.ibm.com, <paf at swip.net>
Subject: IPP> Re: NOT - UDP binding for notification: lets spec a simple SNMP M
IB trap binding
From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Wednesday, August 04, 1999 08:13
To: Manros, Carl-Uno B
Cc: IETF-IPP; Moore, Keith;
=?iso-8859-1?Q?F=E4ltstr=F6m at westrelay02.boulder.ibm.com; _Patrik?=
Subject: Re: IPP> ADM - Meeting Minutes from IETF45 - IPP WG Session -
July 14, 199 9 in Oslo
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
a. If you drop a few you can always "catch up"... after all... it's just a
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
How does that sound?