Subject: Re: IPP> Re: ADM - IPP Charter and Slot in Memphis

From: Don Wright <[email-masked]>
Date: 7 Mar 97 8:13:31 EST

Keith:

First, let's talk about your initial response to my note.

I don't believe "deployed" = "available".  If one day I were
to replace every existing print server with a new IPP based
one and did nothing for the clients, I can guarantee that
there would be more PSERVER/RPRINTER and 
NETBEUI/SMB people screaming than there would be
LPR people screaming.  The IETF continues to have
UNIX blinders on.  While significant, UNIX remains a
niche market.  Clearly the commercial operating systems
like Windows (all flavors) and even OS/2 have significantly
more market then UNIX.  So tell me again, why  should we
worry about this?  This is clearly not a technical argument
but a political one.  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.

Secondly, let's address some of the follow-on notes
and comments.

If your concern is that all the functions of LPR are available
in IPP then I don't think there is a problem.  However the 
sentence you kicked this off with was:

>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.  Co-existance of LPR and IPP is not a
problem but attempting to match one with another is simply
not worth the effort, IMHO.

Don

To: Don Wright
cc: moore%cs.utk.edu @ interlock.lexmark.com (Keith Moore) @ SMTP, 
Harald.T.Alvestrand%uninett.no @ interlock.lexmark.com 
("Harald.T.Alvestrand%uninett.no") @ SMTP, ipp%pwg.org @ interlock.lexmark.com 
("ipp%pwg.org") @ SMTP 
From: moore%cs.utk.edu @ interlock.lexmark.com (Keith Moore) @ SMTP
Date: 03/06/97 06:27:05 PM
Subject: Re: IPP> Re: ADM - IPP Charter and Slot in Memphis

> Well, I guess I am going to hack off the IETF people but...
> 
> -- warning -- highly opinionated and caustic verbiage ahead
> 
> LPR is not a standard.  LPR is not as widely deployed 
> as many other protocols (pick Novell's PSERVER or RPRINTER
> or NetBEUI/SMB which are much more widely deployed) yet we 
> are making no effort to be compatible with those.  I think the
> request is unreasonable.  If a vendor wants to have a
> print server that supports both IPP and LPR as an inbound
> print mechanism -- great!  But to saddle IPP with LPR is 
> simply not reasonable.

LPR is not a standard, but it is widely available and both clients and
servers are implemented on every platform in existence.  The
alternatives you mention are platform-specific.  LPR is about the only
print protocol for which clients and servers are widely available for
almost every platform in existence.

If the WG feels that it's useful to show how to implement PSERVER,
RPRINTER, or SMB print protocols in terms of IPP, I'm sure IESG would
be happy to have those documents published as Informational RFCs.

There's no intent to "saddle IPP with LPR".  My idea is that the WG
should show how to implement LPR functionality on top of IPP (i.e. how
to translate LPR to IPP).  I agree that it wouldn't make any sense to
try to implement all of the IPP functionality over LPR, and there's no
requirement that this group do so.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Mar 1997 17:46:16 -0500

> While significant, UNIX remains a niche market.  
> Clearly the commercial operating systems
> more market then UNIX.  

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.

> 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