Subject: Re: IPP> Revised Charter Text for IPP

From: Raymond Lutz <[email-masked]>
Date: Sat, 28 Dec 1996 01:45:21 -0800

At 10:30 PM 12/27/96 -0500, Keith Moore wrote:

>I also suspect that supporting features of various printers (blank
>media types/sizes, paper trays, single/double sided, folding,
>stapling, collating, typefaces, etc) is of little concern to the fax
>group.  

Not completely. The following definitely overlap:
	Paper size/type (you call it "paper trays")
	Rendering interpreters (many "fax" systems offer Postscript, for example)
	Typefaces (AKA "Fonts")
	Character sets
	Text/plain rendering (margins, lines per page, etc.)
	Conversions from one paper size to another
	1/2/4/n-up printing
	Receiving print job to display for discretion of operator at local site.
	I'm sure others.

>Then there are the issues like security and billing, which --
>as they involve completely different scenarios -- seem likely to have
>very different solutions in the two groups.

I think we will find that the billing scenarios can be split into two clear
areas:
	billing for connections
	billing for hardcopy production and possible hardcopy routing (kinkos
example).
I imagine the security issues will line up similarly.

>It's fine with me if the two groups end up with similar solutions, but
>I'm not willing to constrain either group to bend to the other's
>wishes.  At this point, I'm far more inclined to let any
>cross-fertilization happen informally.

That may be the best approach as most of the ietf method is quite informal
anyway. But it means that I will have to continue to be a "stick in the
mud" (which I don't mind either, as many will attest).

>> I think if we set up some "design rules" we can insure that the
>> results of the two groups will at least gracefully interoperate. If
>> all interaction is handled as MIME objects, then these should also
>> be transportable via SMTP and "IPP". Would the message disposition
>> notice (MDN) appropriate for details of the success of the print job
>> submission via IPP?  If so, then this is easily ported to the SMTP
>> world.
>
>No, no, and no.  
>
>While SMTP can be used as-is for sending faxes, it would require
>extensive modifications to use it as a printing protocol.  If nothing
>else, it has no facilities to find out the status of a print queue, to
>list the characteristics of a printer, to list existing print jobs, to
>remove or hold a print job, etc.  Also, while it might be quite useful
>to be able to send a fax from an email user agent, it's not at all
>clear that you want to use such an interface for what people normally
>think of as "printing", or that you want your printer to have an email
>address.

Well, I certainly agree with you regarding "Intra-net" printing. But I
doubt that most "internet" printing will allow anyone to look into the
general status of a print queue except from an adminstrator level. Only the
user's specific job which was submitted will be allowed for inquiry. This
is the exact situation as for fax, since we need to know the disposition of
the document sent in that manner.

The printer group has suggested a URL for printing. If you email me
something, I may elect to print it. But, you are right that I don't want to
assign email addresses for intranet printers.

>Likewise, while I think it would be good to use MIME content-types to
>label types of media to be printed, I'm certainly not going to
>constrain a printer group to use them to label things like queue
>status, printer characteristics, or job completion.  

Maybe "suggest" is a better word than "Constrain". I certainly can see
nothing technically wrong with marking an object with a MIME media-type so
that it can be processed using SMTP or any other protocol. The stuff in the
media-type container is vitually unconstrained, so it could "hold" these
things.

>Nor would I
>expect most printers to accept and do reasonable things with MIME
>multiparts.

But that is an area that needs some work, and certainly is an area that I
would consider "in scope" to the printer group, at least to define how they
will gracefully ignore or process these multiparts.

>MDNs would be a lousy format to indicate job completion.  Why should
>we require print clients to parse MDNs when a one-line summary would
>do?

Why require the same for fax/email clients? If the syntax of MDNs presents
too much processing overhead (and I don't think it does), then maybe it
should be reviewed in general. At present this is the proposed scenario for
fax job completion information.

>Of course, if a network printer is willing to accept faxes over the
>Internet, in addition to print jobs, I have no problem with that.  I'm
>sure there will be many such 'dual use' products.  But the
>requirements for the two are likely to be quite different, and I
>suspect many users will want to be able to disable the fax receipt
>function while retaining the capability to accept print jobs.

If we view "print" as constrained to "intranet printing", I certainly agree
with you. However, if it is "internet printing" I don't think you will be
able to tell where it came from (it is not possible to tell "fax" from
"print") and I doubt that they will want to disable a specific popular file
format. I don't want to grind this point off, but I think that the
submission of print jobs to an internet print service which is out of the
"realm" of the client will result in a submission scenario quite similar to
that used in fax today, and is proposed for "internet-fax". Also, the
tightly coupled http proposal is also one that fax (i.e. scan/print)
submissions can benefit from.

Since you have clearly stated your current position, I don't expect you to
back down at this moment, but would appreciate continued evaluation of the
work of the groups. I contend that over time, "natural consequences" will
prevail and the two will blend in many respects.

Regards,
-Raymond

/***********************************************************************
** Raymond Lutz                             Voice: 619-447-3246
** Director R & D, Cognisys, Inc.           Fax:   619-447-6872 
** EC Chair, MFPA                           MFPA:  1-800-603-MFPA
** 1010 Old Chase Ave., Suite B             mailto:[email-masked]
** El Cajon (San Diego Co.), CA 92020 USA   http://www.cognisys.com           
**                                          http://www.mfpa.org
***********************************************************************/

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Dec 1996 13:39:24 -0500

> 	Receiving print job to display for discretion of operator at local site.

99.99% of the fax machines out there support none of these.
(with the possible exception of paper size)

Heck, most faxes are still sent using Group 3 protocols.
what this says to me is that -- for the way faxes are normally used --
all of this flexibility isn't needed.

> I imagine the security issues will line up similarly.

Nope.  I'm not going to use a credit card to pay for submitting print
jobs to my local laser printer.   My local printer is going 
to use something very stupid, foolproof, and easy to configure - like 
checking the source IP address - to decide whether I can print.  The
fax machine across the planet probably doesn't want to bill me at all,
but it does want to prevent denial of service attacks.  Kinko's, of course,
is going to want money, but they'll be happy to take visa or mastercard.

> mud" (which I don't mind either, as many will attest).

I'm interested in having groups produce useful results in finite time.  
Overgeneralizing their problems doesn't help.

> user's specific job which was submitted will be allowed for inquiry. 

surely the printer user wants to see the status of all of his print jobs?
surely the printer user wants to have an idea of how many jobs are ahead
of him (even if he can't tell what those jobs are) or have some idea as
to how long it will be until his jobs are printed?

> This

No.  For fax, it's not necessarily true that the document will even 
be printed on paper.  It might be sent to my email inbox, or displayed 
on the screen of my personal digital assistant.  

(Yes I'm aware that people widely assume that faxes get printed on paper 
and that there's real-time confirmation of delivery.  But this isn't
always the case even now.  As people go more mobile, they're going
to carry less paper around.)

> Maybe "suggest" is a better word than "Constrain". 

I'm not even going to suggest it.  I think it's a Bad Idea.

> I certainly can see

Yes it could.  But there's no point in doing so, and thinking of things
in that way makes the protocol unnecessarily complicated.  

If the printing protocol has a "get printer characteristics" command, and 
that command always returns the same data type (a list of characteristics), 
there's no point in labelling that data type.  And it's far better to make 
that list of characteristics extensible, and define what clients do with 
characteristics that they don't understand, than to rely on being able 
to negotiate the data type of the return value of the "get characteristics" 
command.  That way madness lies.

> will gracefully ignore or process these multiparts.

Well, maybe.  Printers accept whatever they accept.  They need to be 
able to say what types they accept, but we don't want to require printers
to accept things that users aren't likely to print.  I don't want to
require printers to accept any particular kind of data -- probably
not even text.

Someone could try to specify what it means to print a multipart,
but for the printing WG, it's quite possibly a rathole.

The fax group has a different task.  It has to answer the question:
if I want to send a MIME message to a fax machine across the planet,
how do I format it?
 
> should be reviewed in general. 

Mail user agents already have to be able to parse MIME.  And the fax service
is so similar to email that it's quite reasonable to use a mail user agent
to send (or receive!) a fax.  There's no way I'm going to use my MUA to
print a document when I can just pull down a print menu or type 
"lpr filename", and there's no good reason to burden my print client
with having to parse MIME. 

> format. 

I understand "fax" as a ubiquitous communications medium, similar
to email, which can transmit messages cheaply over long distances.

I understand "printing" as a media conversion of bits to paper, where
the printer is almost certainly within reasonable walking distance.
(or if you like, a rendering of bits on paper)

"internet printing" is not quite either of these, but is closer to the 
latter.  It's closer to "printing" than "fax", but it requires a lot
more protocol "stuff" to send a print job to Kinko's than it does to
send a job to my Canon BJ200.  Internet printing is neither as well
established, nor as well understood, as either "printing" or "fax".

All of these have utility, but I don't want to burden either a "fax" 
protocol or a "printing" protocol with having to support "internet 
printing".  I could see having "internet printing" be an extension
to the latter.  That's fine as long as:

a) my Canon BJ200 (or it's print queue) isn't burdened with having 
to support authentication, etc., models needed for "internet printing" 
If either the client or server code for printing to my BJ200 with
this new protocol isn't of the same order of complexity as their lpr 
counterparts, there's something seriously wrong.

b) the spec that defines the protocol for local "printing" isn't
delayed while trying to solve the "internet printing" problem.

> I don't want to grind this point off, but I think that the
> that used in fax today, and is proposed for "internet-fax". 

I'm not so sure.  There's a lot of differences between sending a 3 page
message to a colleague across the planet, and sending a 5000 copy, 
color cover, folded, and stapled print job to Kinko's.   I'm going
to want different user interfaces for each.  Until there's some
universal digital cash format, I'm going to pay for each service 
differently.  With the "fax" I expect more-or-less immediate confirmation
that the message got there; with printing I expect the job to be completed
in a day or two (depending on how many copies and how complex it is).

> prevail and the two will blend in many respects.

I believe "natural consequences" will cause the boundaries between these
services to shift, but there will still be significant stratification 
(or if you prefer, specalization) between these services that result.

Keith