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

From: Harry Lewis <[email-masked]>
Date: 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 requirements
>versus the print server requirements.  If we are talking about IPP, the
>host to device protocol, then I agree that the device need only support
>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 service
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 limitations of
an embedded device (where most notifications will originate), AND from the
point of view of a robust server implementation (like SENSE). The device is not
likely to accept the notion of give me e-mail on this message, pager from
noon-2pm and fog horn after dark. Oh, and I'd like specifically, and ONLY, the
following content with that notice. But, I'm hearing that we wish to consider
all this flexibility (and more) in our design.

If we break notification into "stages"... the "device originated notification"
and the "server based notification"... I think it is likely that typical
client-server-device breakpoints will result in several registered hosts at the
device. It is also possible to create a limited peer-to-peer printing system
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 stages of
notification, we should be careful to indicate which part of the problem our
recommendation is addressing.

Harry Lewis - IBM Printing Systems