Re: Requirements for a network printing environment (long?)

[Brad Clements <[e-mail]>]

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