> I wasn't proposing that they be combined. However, I contend that
> there is significant overlap and that the split should be handled
> differently. Perhaps this will occur as a result of natural
> consequences. The communities are heavily overlapped, and in fact, I
> predict that the scan-here/print-there paradigm will be the one used
> in the future for internet "fax". On the other hand, interworking
> with the installed based of fax devices is certainly a topic that is
> of little concern with the ipp group.
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. 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.
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.
> 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.
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. Nor would I
expect most printers to accept and do reasonable things with MIME
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?
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.
Keith