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
- Re: Requirements for a network printing environme… Steve Smith
- Re: Requirements for a network printing environme… Brad Clements