> 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.
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.
> >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.
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.
> >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'm interested in having groups produce useful results in finite time.
Overgeneralizing their problems doesn't help.
> >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.
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
> is the exact situation as for fax, since we need to know the disposition of
> the document sent in that manner.
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.)
> 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'm not even going to suggest it. I think it's a Bad Idea.
> 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.
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.
> >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.
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?
> >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.
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.
> >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 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
> 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".
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).
> 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.
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