Don et al.,
My reaction of seeing Carl-Uno's message that the charter must address
compatibility between LPR and IPP was probably quite similar to Don's.
To impose a requirement on IPP that it be compatible with a very
loose, inconsistently implemented, and functionally deprived
application is totally unreasonable.
As Don points out, the existence of incompatible printing protocols
and print services is and will remain a fact. In addition to the
IP/IPX/AppleTalk etc. variations in underlying protocol, there are
incompatible print services within the same basic protocols. Just
look at the list of 'Channels' in the printer MIB. As a print server
provider, DPI must support a 'compromise' LPR, TCP/IP 'Port' printing
with selectable ports (since different host software use different
port numbers), and FTP, just considering the IP print services.
Since there is no consistency in IP print services now, it seems more
rational to define a new IP print service that leverages upon
something that is consistent across virtually all platforms using IP.
On reflection however, Keith Moore's request might not pertain to
compatibility at the protocol level, but might simply reflect the very
real requirement of a reasonable migration path at the application
level, so that users which now can initiate printing only via LPR/LPD
have some alternate method or some redirecter allowing them to print
via IPP. I believe that a reference to this consideration would
appropriate in the charter.
Bill Wagner, Osicom/DPI
______________________________ Reply Separator _________________________________
Subject: Re: IPP> Re: ADM - IPP Charter and Slot in Memphis
Author: Don Wright <don at lexmark.com> at Internet
Date: 3/6/97 5:39 PM
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.
Is HTTP compatible with FTP? -- no, but both transfer files.
Why didn't the IETF require HTTP to be backwards
compatible with FTP -- because the work was done outside
of the IETF and finally endorsed when HTTP was so widely
deployed it could not be ignored. I don't believe there is a
hard precedent that has been set that says every new
solution must be compatible with an older means used to
do something similar. Perhaps we should do the work and
deploy it into the market outside of the IETF's domain?
-- well, I said it and I bet a number of others feel the same way.
Any one else want to chime in?
Don
To: cmanros%cp10.es.xerox.com @ interlock.lexmark.com (Carl-Uno Manros) @ SMTP
cc: Harald.T.Alvestrand%uninett.no @ interlock.lexmark.com @ SMTP,
moore%cs.utk.edu @ interlock.lexmark.com @ SMTP, ipp%pwg.org @
interlock.lexmark.com @ SMTP (bcc: Don Wright)
From: moore%cs.utk.edu @ interlock.lexmark.com (Keith Moore) @ SMTP
Date: 03/06/97 05:14:03 PM
Subject: IPP> Re: ADM - IPP Charter and Slot in Memphis
> The IPP group is still eagerly waiting your feedback on the Charter
> business as well as confirmation on our slot in Memphis.
The IESG met earlier today and discussed the IPP charter. It decided
to approve the working group once the following changes are made to
the charter:
+ The WG has to make recommendations as to how to acheive reasonable
compatibility between ipp and lpr. IESG understands that lpr is
insufficient in its current form and basically non-extensible, that
its behavior varies widely between implementations and so does not
produce repeatable results, and that it lacks the security needed
for printing in a global Internet. 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.
+ There is a new requirement that all working group charters
explicitly address security, so we need to add this.
Just to be clear: the working group has been approved, but I have to
show that these things have been incorporated to the charter before
the group is formally created. So I'll add a paragraph or two to the
charter that reflects what IESG agreed to, and run it by the IPP
chairs before giving it to the IESG Executive Director.
> People are trying to make their reservations for Memphis and need to
> know at least which week-day that we can expect the IPP slot to be,
> as several experts will only come in for the IPP meeting rather than
> the full week. Remember that I asked you several weeks ago to get a
> slot early in the week, as we will hold an IPP meeting at the end of
> the week before the IETF in Memphis, and some people want to combine
> the two trips.
IPP is tentatively scheduled for Tuesday at 9:00 am.
Keith