At 10:48 AM 12/27/96 -0800, Carl-Uno Manros wrote:
>Ray,
>
>a number of comments to your suggestions, inserted in your text below.
>
>Carl-Uno Manros
>
>---
>
>At 03:03 PM 12/26/96 -0800, Raymond Lutz wrote:
>
>>The work envisioned by the IPP charter heavily overlaps with the work being
>>progressed by the internet facsimile group and charter. The functions of
>>the groups are remarkably similar.
>
>This is your personal interpretation. The fact that WG charters are
requested
>to be no longer than a page or two, hides many of the important details,
which
>may make the approaches look more similar than they really are.
Certainly this is my personal opinion and interpretation. However, I am
basing my opinion on much research into this very area and a thorough
knowledge of both printer technologies (I used to design laser printer
controllers and software) and facsimile technologies. The printer paradigm
for sending fax was suggested by your presentation as well. So, I am not
basing this point on a quick review of just the charter.
Indeed, by your same argument, short charters may hide potential overlap as
well.
>>The ietf-fax group is looking at devices
>>which will accept a MIME object and either print it directly or translate
>>it to T.30 (group-3 fax). One of the primary objects considered by the fax
>>group for printing is the image/fax-format-tbd which is possibly generated
>>by a legacy fax device. However, other formats, such as text/plain, and
>>probably html are to be accepted and "printed" by the internet-fax gateway.
>
>The emphasis on what document formats are of primary interest in the two
groups
>are obviously different, looking at the services the two projects try to
>replace.
>Both will deal with document types that are already defined as MIME types,
>hence none of the groups will do work here, unless important existing
document
>types which are not already a MIME type, need to be added.
To receive fax documents from legacy fax devices, we need a file format to
handle this. This is certainly appropriate for the ietf-fax group to work
on separately from what is generally in the scope of the ipp group. The
MIME type "image/g3fax" is certainly a far cry from what is desired by the
industry, and so a new one is needed. So far, it looks like one based on
tiff-f or RFC1314 is the course for this work. However, once this format is
imported from the facsimile infrastructure, it is a mime object that should
be printable on any internet "printer". Such a "printer" may elect to
retransmit the document to a legacy fax device as well. So, except for the
fact that your proposals have so far emphasized http as the protocol, the
work is fundamentally identical.
>>The new protocol proposed for printing has been defined by the fax group as
>>a session-oriented approach, as opposed to document-oriented store and
>>forward. I have no doubt that the fax work will be accepted since there are
>>real $ improvements in fax transmission costs that can be realized.
>
>As far as I know, the current proposal for the FAX group is to go ahead with
>the document-oriented approach and leave the session-oriented one for later
>(how much later - years?) and may not even be part of the FAX charter, which
>BTW is still to be written.
Oops... You're right, I goofed and said fax when I should have said
printer. Let me try again.
The new protocol proposed for printing has been drafted by the ipp group is
a session-oriented approach, as opposed to document-oriented store and
forward, which is the paradigm used for email, and is the current lead
proposal in the discussions of ietf-fax. I have no doubt that the fax work
will be accepted since there are real $ improvements in fax transmission
costs that can be realized.
The FAX charter I believe is already accepted since this was the 2nd BOF.
There was no discussion at the last meeting regarding whether the charter
was approved or not.. Maybe this was chairman "slight of hand", I'm not
sure. But your comments further to emphasize the overlap.. the main
difference being SESSION vs DOCUMENT STORE/FORWARD. Since this is the main
difference, I claim about 90% of the other work is the same. There are many
in the fax community that offer session-oriented fax.. Don't misinterpret
the current near-term focus of the working group to mean that there is no
interest. But, if the IPP group is going to work on such a thing, then it
is just the sort of animal needed for SESSION-oriented fax. Then the
overlap is complete, QED.
>>The comments about LPD having 28 implementations seems to support further
>>work to refine this and reduce the number of variations.
>
>Ray, you still do not get it. Who would specify and implement a revised LPD
>if none of the printer vendors show any interest? The FAX WG members?
>X/Open already looked at this approach and decided it was too messy to touch.
>Try to be real!
I'm only saying that the argument that there are many implementations is
not one that implies that it is not a good candidate for work. If LPD won't
fill the needs that the groups sees, then, this is a better argument for
not using it. I wasn't part of the consensus body of the X/Open group, so I
don't know why they are saying it is "too messy to touch". It sounds like
it is heavily implemented and there is significant experience to its use.
Maybe changing its name to IPP might be enough to inspire new interest... :)
>>I would like to propose that these groups are harmonized as follows:
>>
>>IPP group will focus on a mime object for printer control (such as paper
>>type, binding, etc.) which can be combined with any relevant MIME type,
>>including printer language media-types.
>
>This will certainly be included, but you make an oversimplification by
>omitting the important fact that IPP is oriented not only around printers
>but also around jobs, that can contain several documents, and that you will
>have features to check up on what happended to your job(s). You can also
>enquire about a printer's features and status, independent of jobs.
If you read the material originally proposed to the PWG by the MFPA several
years ago, you will agree that I am not ignorant of these details. Indeed,
these are things that everyone wants, including the "fax" group. They need
to know that the job was accepted, completed, and if possible read by the
intended recipient, and the various capabilities of the machine. In fact,
facsimile probably exhibits more of these traits that printers by far, and
T.30 comprises a complete negotiation and job submission protocol. So
again, there is significant overlap.
A printer's features and configuration status is covered by RFC1759 and
SNMP, is it not? (Does IPP obsolete that work !?)
>>This work can then be use in any protocol, such as SMTP or other simple
>>submission protocol, including by the facsimile group for transmission of
>>these hardcopy output suggestions to the receiving fax device or document
>>store. The hardcopy output suggestions can be maintained with the document
>>for future use. These controls are missing from popular terminal-oriented
>>media-types, such as html, PDF, etc.
>
>The IPP MIME types will be defined in such as way that they can be run over
>any "transport" protocol that can handle MIME, obviously including SMTP.
>If using the latter makes sense from a service point of view is still a
>separate matter.
Then, we can agree that rough consensus hasn't been achieved on the type of
transport protocol that will be used, if indeed SMTP is a separate matter.
It certainly seems reasonable to me that hardcopy material should be
email-able. And, if that is the case, it would be certainly handy if this
material could also be processed by an internet-fax gateway and then sent
to the installed base of about 80 million group 3 fax devices.
>I have had discussions with the proposed chairs of the FAX WG, and we are
>all of the opinion that there is sufficiently much work to be done in both
>areas to justify both groups. The initial focus of the groups seem to be
>quite different. The proposed use of MIME types in both projects gives a
>certain level of coordination already and if it turns out that a significant
>overlap between the projects should materialize over time, there will be
>several points in the standardization process where the projects could be
>joined. In the meantime, we should all keep informed about what the two
>groups are doing, so that any need for coordination can be spotted early.
>I am following the FAX DL discussions, and so far I have not seen any
>overlap of work between the groups.
I'm sorry, but your group does see overlap, in spite of your inability to
admit it. In your presentation, you mentioned that the "Printer" device
could be a fax device. I see nothing wrong with that point of view, and I
support the idea that the future of faxing using the internet is the
scan-here/print-there paradigm that has nothing to do with facsimile as we
know it.
Don't misinterpret my intentions. I'm not saying that the working groups
should not be formed. On the contrary, I am happy to see both the printer
and fax groups receiving a great deal of interest. But I do think it is
reasonable to carefully consider the desired result of these groups and how
they should best support the envisioned applications.
Let me make an important point for the printer community. To support the
transmissions of documents from the fax infrastructure a MIME media-type
will be developed. This file format will be similar to image/g3fax in that
it will be primarily a compressed bit image of the document. (for sake of
discussion, let's call it image/huffman). So, a fax/internet gateway will
translate from the T.30 protocol used by fax today into image/huffman, and
then it can be transported by whatever means. This means may be SMTP, or it
may be IPP (or maybe LPDng). So, once the fax is converted to a MIME
object, again there is complete overlap.
At the other side of the "internet" we have a gateway that translates from
MIME media-types, including image/huffman, to T.30 for transmission to a
legacy fax device, or printing to a nearby printer, or direct display. In
addition to the image/huffman media type, a certain -->limited number<-- of
other formats will be included as the mandatory set. I would imagine
text/plain;charset=XXX and encapsulated html will be included in these
formats.
As a result of the preponderance of these internet/fax gateways which will
support a given set of formats, these formats will become the minimal set
of printing formats. This has a major impact on the world of printing, I
would argue.
"Get real" Carl-Uno... There is overlap. Does this mean that your WG is
doomed? Not at all. I am only suggesting some harmonization and a split of
work that will benefit both groups to achieve the most results in the least
time for everyone, and avoid a duplication of effort.
-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@cognisys.com
** El Cajon (San Diego Co.), CA 92020 USA http://www.cognisys.com
** http://www.mfpa.org
***********************************************************************/