Re: Requirements for a network printing environment (long?)
Brad Clements <bkc@murkworks.com> Fri, 24 July 1992 16:09 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04520; 24 Jul 92 12:09 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04516; 24 Jul 92 12:09 EDT
Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa20697; 24 Jul 92 12:09 EDT
Received: by inet-gw-2.pa.dec.com; id AA19126; Fri, 24 Jul 92 09:09:11 -0700
Received: by nsl.pa.dec.com; id AA12053; Fri, 24 Jul 92 08:43:40 -0700
Received: by nsl.pa.dec.com; id AA12049; Fri, 24 Jul 92 08:43:39 -0700
Received: by inet-gw-1.pa.dec.com; id AA06779; Fri, 24 Jul 92 08:43:15 -0700
Received: by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)id AA27705; Fri, 24 Jul 92 11:30:17 -0400
Received: from anvil.murkworks.com by murkworks.com (4.1/3.2.083191-MurkWorks)id AA03867; Fri, 24 Jul 92 11:05:49 EDT
Message-Id: <9207241505.AA03867@murkworks.com>
To: Steve Smith <steve@next-s.lanl.gov>
Cc: print-wg@pa.dec.com
Subject: Re: Requirements for a network printing environment (long?)
In-Reply-To: Your message of "Thu, 23 Jul 92 13:12:33 EDT." <9207231912.AA07009@next-s.lanl.gov>
Date: Fri, 24 Jul 1992 11:05:49 -0400
From: Brad Clements <bkc@murkworks.com>
Steve, Your ideas sound great, do you have any kind of written proposal? One thing to keep in mind is that part of the original target for this group was (as I recall) taking into consideration so called resource-poor clients (aka PCs) and servers (aka Netports, etc). Any kind of design that we come up with should probably take into consideration components of this type. A so-called grand design, with a subset implementation now and full blown implementation later sounds nice in theory. I wonder how well it could be done in practice. How many projects go into the implementation phase, only to find that the design wasn't up to snuff. Is it possible that this type of approach to a printing protocol might put us into a position later which is similar to the LPR spec problem today? As mentioned previously on this list, the LPR protocol was designed for line printers, but a few extensions moved it into supporting other media. Today we find that the protocol isn't much good for either application because the way we address output devices today is different from when the spec was first designed. Could an extensible specification be written today (as you propose) which could stand up to new media types in the future, as well as new ways of using such media? Its not just the devices and the print information that needs to be addressed, but also the way they are used and accessed. -- Other IETF WGs have run into tar pits over similar design questions. If we attempt to design in everything from the start, the spec will be outdated before anyone can implement it. If we make some modules optional, implementations might not interoperate correctly unless a least common denominator is defined. Even then, if the LCD is too weak to be useful, the spec won't get far. If we define a spec that is extensible (that'd be nice), but don't clearly define how extensions are added (ie: that they should go through the same proposal process as the original spec), then we could run into a problem similar to the telnet environment option. That spec defined how certain client environment variables could be requested by the server, defined a few common variables that probably should be supported, and left it wide open for any new ones to be `defined'. A lot of good things have been attached to these environment variables, but quite a few duplicate and cloudy items have been attached as well. With no body governing the extension of this feature, its every-person for themself. In the end there will probably be many implementions of similar, but slightly different variables, and no one will be able to interoperate. -- So, for as much as I think the `big plan' sounds good, I'd like to see everyone keep the above comments in mind when proposing or designing a spec that will hopefully solve all our problems (and make you famous to boot). These are my comments, what are yours? -brad