IETF as a whole does not view the world in terms of markets.
Its mission is to encourage the growth and health of the Internet,
and to benefit Internet users, not to sell products. While
IETF people realize that the Internet will not be successful
unless people can make money providing Internet applications and
services, IETF measures its success in how well the Internet is
used rather than in terms of how much money is made.
Of course, many IETF participants work for companies who sell
products, and who have self-interest in having their companies do well
in the marketplace. But this won't be true of everyone there --
IETF participants are also users, and engineers, and people who
administer networks, internet service providers, etc. So you'll
get a different spectrum of concerns than you would from a purely
marketing perspective.
In particular, IETF would rather encourage one well-defined, published,
simple printing protocol that everyone can implement and solves
most people's printing problems, than either lots of protocols,
poorly defined or proprietary protocols, or complex protocols --
because that combination makes it easiest for everybodY to print things.
LPR isn't well defined, but many IETF people view it as sufficient
for most needs, and the closest approximation to the ideal that
actually exists. (Those people probably don't realize how
UNIX-centric LPR is, nor how difficult it is to extend it.)
> If the IETF is true to its mission to provide the best technical
> solution then there can be absolutely to reason to worry about
> something as poorly spec'ed and inconsistantly implemented as LPR.
The best is the enemy of the good. LPR isn't very good of course,
but it's sufficient for the needs of a great many people.
> >The WG has to make recommendations as to how to acheive
> >reasonable compatibility between ipp and lpr.
>
> and then you finished with:
>
> >However, IESG also recognizes that lpr is widely deployed,
> >and that a new protocol -- even a much better one -- could be
> >disruptive to the installed base.
>
> These statements clearly are looking for more than simply a
> capability match-up.
I think you're reading more in there than I intended. I don't see
any reasonable way to extend LPR to have anything similar to IPP's
capabilities, and I wouldn't waste my time trying. Neither would
it make sense to dumb down IPP to be equivalent to LPR.
But it is useful to document how to map LPR onto IPP, and
to document how to implement a minimal IPP server (obviously
not supporting much of the functionality of IPP) that translates
IPP to LPR. That is more than a capability match-up, but not a
lot more -- and I wouldn't expect it to be a long document.
Keith