IPP Mail Archive: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications

IPP Mail Archive: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications

Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications

Harry Lewis (harryl@us.ibm.com)
Tue, 24 Mar 1998 11:34:05 -0500

Well, yes, it gets pretty confusing...

>Well, here we go again...
>
>Is it just me, or are we running into the embedded printer requirement=
s
>versus the print server requirements. If we are talking about IPP, th=
e
>host to device protocol, then I agree that the device need only suppor=
t
>a limited number of notification clients. If we are talking about IPP=
,
>the print client to server protocol, then I believe that print server
>ought to be able to scale to 100's, even 1000's, of clients.
>
>...walker

Because we're talking less about IPP and more about a notification serv=
ice
where, as a potential ubiquitous print submission protocol, IPP needs a=

mechanism for registering clients for notifications, regardless of the
scalability of the notification server

I think we need to look at notification services both from the limitati=
ons of
an embedded device (where most notifications will originate), AND from =
the
point of view of a robust server implementation (like SENSE). The devic=
e is not
likely to accept the notion of give me e-mail on this message, pager fr=
om
noon-2pm and fog horn after dark. Oh, and I'd like specifically, and ON=
LY, the
following content with that notice. But, I'm hearing that we wish to co=
nsider
all this flexibility (and more) in our design.

If we break notification into "stages"... the "device originated notifi=
cation"
and the "server based notification"... I think it is likely that typica=
l
client-server-device breakpoints will result in several registered host=
s at the
device. It is also possible to create a limited peer-to-peer printing s=
ystem
with no notification server where print clients register directly with =
the
device. It is also possible to create a notification server that simply=
polls
the device, eliminating the need for a device notification protocol or
registration scheme.

Since, as Jim points out, we really are talking about (at least) two st=
ages of
notification, we should be careful to indicate which part of the proble=
m our
recommendation is addressing.

Harry Lewis - IBM Printing Systems
=