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:raylutz at cognisys.com
** El Cajon (San Diego Co.), CA 92020 USA http://www.cognisys.com
** http://www.mfpa.org
***********************************************************************/