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
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.
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.