Re: Requirements for a network printing environment

Brad Clements <bkc@murkworks.com> Fri, 24 July 1992 20:09 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab09213; 24 Jul 92 16:09 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09205; 24 Jul 92 16:09 EDT
Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa02312; 24 Jul 92 16:09 EDT
Received: by inet-gw-2.pa.dec.com; id AA03489; Fri, 24 Jul 92 13:09:23 -0700
Received: by nsl.pa.dec.com; id AA15878; Fri, 24 Jul 92 12:07:41 -0700
Received: by nsl.pa.dec.com; id AA15874; Fri, 24 Jul 92 12:07:40 -0700
Received: by inet-gw-2.pa.dec.com; id AA29627; Fri, 24 Jul 92 12:07:38 -0700
Received: by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)id AA21190; Fri, 24 Jul 92 14:25:06 -0400
Received: from anvil.murkworks.com by murkworks.com (4.1/3.2.083191-MurkWorks)id AA04141; Fri, 24 Jul 92 14:15:23 EDT
Message-Id: <9207241815.AA04141@murkworks.com>
To: Steve Smith <steve@next-s.lanl.gov>
Cc: print-wg@pa.dec.com
Subject: Re: Requirements for a network printing environment
In-Reply-To: Your message of "Fri, 24 Jul 92 10:59:59 EDT." <9207241659.AA07551@next-s.lanl.gov>
Date: Fri, 24 Jul 1992 14:15:21 -0400
From: Brad Clements <bkc@murkworks.com>

I can't speak for the WG, but my understanding is that this is an open forum
and all input is welcome.

I for one would like to see your "network printing for ICN2" document. I'm not
sure how the other one you mentioned would relate to the purposes of this group,
but you'ld know better than me.

Seems to me the objective of this group is to produce a recommended network
based printing protocol (lan, man, wan?) that satisfies the basic
requirements of all interested parties.

I suppose the most basic requirement (and the least interesting) is: node A has
output for printer B, how does it get there?

--

In the LAN environment (Novell) some interesting products have come out to solve
the issue of pairing print data requirements with available resources
(ie: sending documents of type A to printers of type A making sure that fonts
B and C are also sent, etc). Some of these products handle all of this stuff
transparently to the user (nice). Of course thats not hard in a homogenous 
networking environment. Or at least, not as hard as doing the same for a mixed
bag of platforms and systems.

--

I say, what the heck, shoot for the sky in the original proposal. A reality check
into the technical and financial requirements of development produce a
first-filtered design. Followed by a second reality check of `what does the market
really want' gets you to round two. The last step is `what do the vendors really
want to do'? (ie: what will sell).

I'm not saying that proposals from this group should be governed by vendors. But
I imagine that vendors are the ones most likely to have the resources required to
make any such protocol `wide-spread'. Perhaps thats a naive view on my part. Any
protocols from this group that are 1) useful, 2) actually work, 3) easy to
administer, and 4) have freely available reference implementations will probably
take off like other recent networking tools (archie, gopher, etc).

--

I do believe that this group has already acknowledged the need to move beyond the
spooler/no spooler issue. However after that point, the group seemed to just wither
on the vine.  I'd like to know who is in this group, and who wants to keep going.

Heck, if there are only three or four of us, then this group is effectively
defunct. Might as well run off and do an SMP vis SNMP coup!

-Brad