Re: NPA.PS has problems, don't get it yet

[Brad Clements <[e-mail]>]

The NPA spec does take a long time to print, mostly due to a fancy logo
printed at the top of every page.

Now, funny thing is that they send the bitmap for the logo on every page.

A spec put together by printer manufacturers... geesh, you'ld figure that they'd
know PS enough to send the bitmap only once and call it as a proc after that.

But, what the hey, its obviously the fault of the word processer they used
(feh!, they didn't use TeX). 

--

Enough tongue-in-cheek.

The spec was put together by printer manufacturers who've been taking a beating
by the software folks for  having ancient technology that doesn't talk. Well
this spec is pretty all-encompasing. Does anyone know when any manufacturer
will have out an NPA complient printer?

--

My interest in the spec was to see the type of management information that
`they' thought would be interesting. I'm not proposing the NPA spec for
this group, neither in a client-to-spooler protocol nor in the spooler-to-device
protocol. My point is that neither could be defined without a good grasp of
the kind of capabilities that users want (which is presumably gleaned from
what the manufacturers are willing to give).

One might say that we need three protocols

	client to spooler
	spooler to device
	management agent to device/spooler

Now my preference would be to have only one protocol that handles all
three of these conditions. This way those applications in which the client
must speak directly to the device could also be handled.

Perhaps the gravity of NPA will will `force' subsequent specs to follow their
lead. I suppose that depends on the market...


| Brad Clements, CCP     [e-mail]
| Sr. Network Engineer   Clarkson University              [phone]