At 09:07 PM 11/8/96 PST, Larry Masinter wrote:
>Of the various reasons to split a working group into parts, "separate
>applications" is a good reason, "separate expertise" is not. I think
>it would be counterproductive to split the group along the lines
>suggested by Raymond Lutz. If some folks want to go off and write a
>proposal for data formats, they're free to do so, and then we can
>review and discuss the proposal here.
>>Keep charter as is.
I guess I will need to spend some more time explaining this position, since
so far, I don't think anyone understands the point. I want to apologise
that this can't be condensed into a sound-bite sized email message.
Let me remind you that I have very little interest in this issue except
that I am attempting to represent what I feel would be the concensus of
companies making Multifunction devices. In such devices, there are indeed
multiple "applications" and distinct subsystems with customarily separate
groups of people operating as experts in those areas. I must say that I
rigorously disagree with Larry's point that separating work into separate
areas, (sometimes "layering" is the term) is not productive within a given
application. I don't think I havee to preach very long to this group for
people to agree that the layering concept has been a successful method of
suppressing complexity, and allowing groups of people to handle very
complex issues by splitting the problem into layers. Do systems always
exhibit these layers in implementation? No. They exist for several good
reasons, one of which is the reduction of complexity at any one level, and
the ability for humans to process complexity. Another benefit is the use of
one layers by various other layers. Certainly, it allows groups of
"experts" of each layer to exist. Most architects are sold on this idea today.
After playing with the MFP problem for the last 3 years, I am not a
newcomer to the problem of various expertise groups. In this case, we see
another group with very similar agenda starting, the "Internet Printing
Protocol" group, based on the idea that internet printing is a separate
application that needs a different group. I think this fits Larry's model.
So, OK, let's say that we take Larry's approach and use the application as
the justification for a separate group doing work which may or may not be
similar at all to the work of the ietf-fax mailing list. It is possible
that the internet printing protocol group will be working on similar
topics, since, let's face it, true "internet fax" is little more than
scan-here/print-there. If you are an MFP manufacturer, it is likely that
you will be required to support BOTH protocols, MIME and IPP, whatever that
winds up being. I know that most makers of these MFP devices are extremely
cost sensitive, and so the idea of needing to support both is hogwash, or
at least leaves a distinctly bad taste in your mouth regarding the
effectiveness of the standards process.
If you look at the recent Novell/Xerox proposal of "Light DPA" (LDPA) you
see a RPC style protocol with intervening spooler queues. If this is the
future of printing, then this doesn't map very well to the simple MIME
attachment for fax that apparently is the consensus of this mailing list. I
don't see why the MIME protocol improvements (such as comfirmation of
receipt, accounting concerns, etc.) can't be equally applied to the
"internet printing" problem, especially if we consider the spooler queues
in the LDPA model as email transfers of some format, and visualize the LDPA
protocol to be oriented to a intranet application.
Can we hope that the people in the Printer Working Group will decide that
"printing" is no longer a viable application and proceed to support "fax"
as the application of choice? Fat chance. Or, turn the problem around, and
consider "fax" as "printing" and abolish the ietf-fax list and use only the
ipp list. Again, fat chance.
To me, the separation of these issues due to the apparant and customary
separation of these applications is rediculous. The right direction to go
is to separate the LAYERS which all the groups can effectively use. Let's
look at this path more closely.
As I have asserted previously, the proper split is between PROTOCOL and
CONTENT. There are many different contents that should be transportable by
the same protocol. We have been discussing T.4 and T.6 (compressed image)
formats, but others, such as printer formats are indeed possible as well.
Clearly, for the fax application, we need an improved "Content", since I
know of no one that considers g3fax to be sufficient. This certainly
applies to the "fax" application, and to the support of the installed base
of g3 fax devices.
Some people have suggested that MIME+SMTP is the protocol to use for this
application. I don't think the ipp (LDPA) has the same protocol in mind.
But, I don't think this issue has been absolutely decided either either in
either forum.
If we consider the Internet Printing problem, we would consider that it
would be nice to be able to attach a print-oriented file to an email and
send it to a printer of a specific IP address. Is this a different
"application" from the fax application? Not from this vantage point.
It is my hope that splitting the problem along the lines of LAYERING
instead of APPLICATION will allow these groups to come together and use a
common base of technology instead of two vastly different approaches
depending on whether you see the device as a fax machine with a printer
inside or a printer that can receive fax format data content.
I think some people were thinking that I was proposing that the list
mfpa at mfpa.org should be responsible for part of the work. I don't, nor have
I ever asserted that position. I was looking for a basis for cooperation
among groups of experts in groups that are unlikely to give up their
identity. In light of this knowledge, the MFPA attempted to establish
web-based forums (http://www.mfpa.org/forums.html) as an experimental
method to handle various sub-projects. I haven't been able to resolve all
the technical issues with this method yet, but I think that such forums
will be a good approach in the future. That resource will continue to be
available if we should decide that it is a viable way to handle multiple
similar projects. As an experimental approach it is probably too new to
start with this project at this time until I work out more of the logistics
issues.
It is clear to me that DATA CONTENT issues exist for the facsimile
application. Improving the format of g3fax for transport as a MIME type is
clearly a requirement. Let's not confuse this with the protocol
enhancements that can be used for both the facsimile and printing
applications.
With all this said, I hope you understand my position. I think a split is
best at this time to allow both the protocol issues that can be applied
both to printing and faxing (probably both using MIME) to be separated from
the specific issues with regard to supporting the installed base of g3 fax
devices and T.4/T.6 compress image formats. I really don't know what
everyone is afraid of. Such mailing lists are created easily and allow nice
partitioning of the work.
However, I am also a realist, and will settle for possible future split of
the work in this fashion. In the meantime, I think I have already achieved
a change in the charter, specifically in the list by Larry, in that at
least the NUMBERING of the items should be removed. Fair enough?
-Raymond