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

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Thu, 6 Mar 97 16:31:27 MST

Keith Moore:
>  ..................................  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.

Don Wright:
>........................  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.

I agree with Don. And, perhaps, this sort of explanation is all the
IESG is looking for (I hope).

Harry Lewis.

---

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

Harald T. Alvestrand said:

>Examples of cases that should be handled, or guidance should exist:
>
>- An LPR client talks to an LPR printer. You want to replace the printer
>  with an IPP printer, but can't change the client.

No problem, support both LPR and IPP in the printer.  We do that today
in our printers.  They simultaneously support LPR, FTP, TFTP, PSERVER,
RPRINTER, AppleTalk, etc., etc., etc.

>- An LPR printer is absolutely necessary for some purpose, but the client
>that used to access it is being upgraded to IPP-only. What to do?

See answer above -- add IPP support to the printer or add an IPP server
in front of it and use LPR to "spray the bits into the printer."  Support for 
multiple protocols will continue to be a marketplace requirements for printers.

Don

---

From: JK Martin <[email-masked]>
Date: Fri, 7 Mar 1997 12:06:26 -0500 (EST)

Harald,

> [...] or if you make it a requirement that every
> pixel must go onto the page before an acknowledgement can be sent back
> to the requester, even though the backend LPR-only printer has internal
> storage and no way to show its internal queue.
>
> (My HP Laserjet does that all the time....considerable time passes
> between "queue empty" and the time I can fetch the printout....)

Ah yes, we in the PWG know about this situation all too well.

The problems of reconciling related--yet independent--job queues is
a prime focus of the PWG's Job Monitoring MIB Project (aka, "JMP").

Be careful, though, that you don't try to start painting a picture
in which IPP is supposed to solve *all* of the myriad of problems in
the general printing environment.

It's a huge mess out there, and we had best bite off only what we can
successfully chew in the next 6-9 months, IMHO.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Patrick Powell <[email-masked]>
Date: Fri, 7 Mar 1997 18:10:49 -0800 (PST)

yes,  I this is,  I believe,  the intentions of the group,
as well as ensuring that a 'gateway' facility is possible.

Patrick

	From: "Steve Zilles" <[email-masked]>

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

	So, if I understand this correctly, you are asking we insure the
	functionality present in LPR is not lost in going to IPP and that we
	present an outline of one mapping of LPR functionality to IPP.

	        Steve

---

From: Patrick Powell <[email-masked]>
Date: Fri, 7 Mar 1997 17:36:50 -0800 (PST)

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

<<< Translation: look, it's terrible, but we have too much invested
<<< to drop it like the brick around our necks that it is
<<<

I spent an hour at lunch today working on how I would translate what the
IPP Model folks have presented into LPR/LPD protocol,  and strangely
enough there is not that much backing and filling to do.

The easiest way to do the translation would be to resurrect the old
job template stuff (don't hit me! don't hit me) and indicate that a
LPR spooled job would be translated into a IPP job via this template.

Similarly for status information - a 'reverse mapping' is even easier.

Job removal is almost trivial.

Patrick Powell

---

From: [email-masked] (Robert Herriot)
Date: Fri, 7 Mar 1997 18:44:59 -0800

> From [email-masked] Fri Mar  7 18:22:36 1997
> 
> 
> 

Doesn't the job template part of the job/printer attributes in the
current model do the job of defaulting that I think you may need. If
not, explain what facility you are thinking of.

Bob Herriot

---

From: Patrick Powell <[email-masked]>
Date: Fri, 7 Mar 1997 20:41:49 -0800 (PST)

Yes, that is it.  I knew it was there somewhere.

@ > From [email-masked] Fri Mar  7 18:22:36 1997
@ > 
@ > 
@ > 
@ > The easiest way to do the translation would be to resurrect the old
@ > job template stuff (don't hit me! don't hit me) and indicate that a
@ > LPR spooled job would be translated into a IPP job via this template.
@ > 
@ 
@ Doesn't the job template part of the job/printer attributes in the
@ current model do the job of defaulting that I think you may need. If
@ not, explain what facility you are thinking of.
@ 
@ Bob Herriot

---

From: JK Martin <[email-masked]>
Date: Sun, 9 Mar 1997 12:28:02 -0500 (EST)

Patrick,

With all due respect, I must ask you to qualify some of your statements.
Sorry, but you appear to be literally sweeping *everything* under the rug
with some of these statements:

> 1. LPD has no authentication.  That solves it in one direction.
>
> 2. Since you don't have authentication,  you need an 'anonymous' user to
>    map LPD stuff into.  That solves the other.

Actually, LPD has a *bit* of authentication, at least in several
implementations, whereby the client port must be within the range
of privileged ports.

However, the real issue is:  just because LPD has serious holes in its
security model, should this be necessarily propagated to IPP?

My apologies in advance if I am being dense here and not understanding
what you mean, exactly.  Can you provide us with a bit more insight here?

	...jay

---

From: [email-masked] (Bill Wagner)
Date: Mon, 10 Mar 1997 10:47:06 -0500

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 <[email-masked]> 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