Here is the statement about the IPPFAX presentation that Lloyd made at the
Internet FAX WG at the IETF meeting:
5.4 PWG IPP Fax status report
Lloyd reported on behalf of the PWG IPP group. (see slides for a detailed
description of documents and status). Is was made clear that the activity
presetnte is carried on within the IEEE unbrella, and also that the IESG
did not accepted this activity as a possible IETF one, answering that
these activities were already covered by our wg. There was consensus from
the wg that there must be a better coordination with these external
efforts, in order to avoid any possible incomaptible products to be
developed.
Also included in the Internet FAX WG minutes are the discussions about:
A. Interoperability problems with the image/tiff MIME type and some existing
TIFF readers.
My summary/questions:
It seem likely that TIFF/FX will need a new MIME type, such as
image/tiff-fx, instead of image/tiff; application=faxbw and =faxcolor, at
least for the profiles that deployed TIFF readers can't handle (J, C, L, and
M).
If a new MIME type, will the MIME type have parameters to indicate the
profile or profiles that are inside? For example:
image/tiff-fx; profile=c,f
What MIME type will our Universal Image Format (UIF) use?
Can it be new parameter values for parameters on the (new) image/tiff-fx
MIME type, such as:
image/tiff-fx; profile=uif-c,uif-f
B. The Adobe IPR issue with the IETF over Atobe's license to the IETF to use
TIFF in producing TIFF/FX.
My summary/questions:
Adobe needs to resolve their issues with the licensing of TIFF to the IETF
and Xerox needs to resolve their issues with Adobe on licensing MRC for use
in TIFF.
Will the IEEE-ISTO need to get a license from Adobe for the IPP FAX WG's
Universal Image Format (UIF) which builds on TIFF/FX?
Would Adobe grant us one?
The Internet FAX WG is carrying on discussions about the notes on the
ietf-fax at imc.org mailing list, if you want to know more.
Tom
-----Original Message-----
From: Claudio Allocchio [mailto:Claudio.Allocchio at garr.it]
Sent: Thursday, August 09, 2001 09:26
To: ietf-fax at imc.org
Cc: klensin at jck.com
Subject: notes from the ietf FAX wg meeting at IETF 51
Hallo,
here are the notes from the meeting we had on monday evening. Sorry for
being late, but (apart from an "editing accident" which deleted the first
version of the notes) I tried to be as most precise as possible, as some
issues are very important to be understood also on the mailing list by
those who were not present at the meeting.
Please drop comments and integrations to our ML. Thanks again o Graham
Klyne who took the base notes.
Regards
Claudio Allocchio
----------------------------------
Short notes of the ietf FAX WG meeting - IETF 51 London, UK
------------------------------------------------------
At the meeting start the co-chair welcomed the participants, and asked for
eventual modifications to the proposed agenda. As ther were no specific
change requests, the agenda was approved.
Tamura-san announced that Maeda-san was unfortunaely not present at the
meeting, thus we would add more time to the discussion of the TIFF issues.
2. Status of Draft Standard consideration
2.1 Addressing
draft-ietf-fax-minaddr-v2-04.txt
draft-ietf-fax-faxaddr-v2-04.txt
These two documents were approved by IESG on July 19th 2001 and now are in
the RFC editor queue for publication. In the Applications Open Area
meeting there was the suggestion to find a way to explicitly state that
the specification draft-ietf-fax-minaddr-v2-04.txt is a general
specification which is valid in ANY application encoding GSTN (telephone)
numbers into an e-mail address. Also the FAX wg suggested to add such
note, possibly in the abstract. The editor will investigate with the ADs
if an IESG note in appropriate.
The same need to emphasize the generality could apply also to other FAX wg
documents, like the draft-ietf-fax-content-negotiation-05.txt ones and the
wg suggested the editors to consider it, too.
2.2 TIFF-FX
draft-ietf-fax-tiff-fx-09.txt
draft-ietf-fax-tiff-regbis-02.txt
The documents approval is slowed down by a series of problems which were
detected during the process. ITU-T also needs a quick resolution of there
problems as stated in the communication letter from ITU-T SG16 meeting.
The problem, detected at first as an IPR issue raised by Adobe in January
2001, was escalated to IESG and IAB which examined carefully all the
aspects,
and identified also some additional compatibility issues.
John Klensin (IAB) reported to the WG.
The TIFF Story, actually had many different steps and chapters. During the
analysis of the problem there were many iterations between the IESG and
the IAB which at the end pointed out two Separate Issues:
- WG responsibility for interoperability
- IPR questions
At first the interoperability. This is the "Main IETF Goal" to be
achieved, and its meaning should span forward and sideways. The main
principles are that:
- Implementations of one protocol must interoperate
Ð- Implementations of related protocols should interoperate
Ð- Deviations must make sense and have a clear rationale behind.
In its original goals (and as stated in the charter) the fax wg had to
create a Fax Model that should Interoperate with fax fabric and
Interoperate with e-mail fabric. More over it should avoid having to
choose between the two fabrics. For this reason TIFF was chosen because It
was widely believed that it would be interoperable with existing viewers
and editors, especially Viewers expected to be used with image/tiff in
e-mail. This shoud also be the start of the "global messaging service".
The question now is: can we meet all these constrains? Is TIFF the right
choice to accomplish them?
Basic TIFF does not support colors, and different resolutions, but is it
compliant with the existing TIFF readers, and e-mail User Agents (MUAs).
However, if we want to cover also the "extensions" that ITU-T is
requesting for fax service (e.g. colors, resolutions, etc...) Basic TIFF
is not enough, and it will need extensions. These extensions were
specified into TIFF-FX, and ITU-T decided to adopt and reference it.
However TIFF-FX is already beyond Basic TIFF.
Actually there are already de facto extensions to basic TIFF
specifications which are publicly available, and widely deployed within
both TIFF readers and MUAs. All there de facto extensions are currently
used in MIME type "image/tiff" and there are not interoperability
problems. However the extensions intriduced into TIFF-FX are a superset,
and thus only some Ifax devices can correctly handle them.
So, the IESG and IAB would like the WG to review and document, as a
condition
for advancing the TIFF specification to Draft Standard:
- Whether the choice of "interoperation with e-mail" versus "interoperation
with fax" is the right one
- whether a mostly-fax-only TIFF variation is the right choice
- Whether this should be image/tiff or image/tifffx (or equivalent)
- hether the interoperability profile is right given these issues
- and any other similar tradeoffs that might have been made without full
evaluation.
The IAB believes now it is late in the game, so these reviews may not
change anything, but they are important for learning, and context, and
predicting problem areas and determining whether the meta-qualifications
for Draft Standard are met.
John Klensin then reported on the IPR issues, which invove both Adobe and
Xerox.
Adobe: the solution appears to be to have Adobe include the new TIFF-FX
encodings in TIFF-7, but Adobe has not committed to produce TIFF-7 and It
is not clear what produces that commitment. Moreover, even if they do
TIFF-7, they will not commit to including the TIFF-FX features until at
least Xerox releases rights to the encoding techniques for all uses of
TIFF, not just fax and Xerox (or maybe IETF) apply formally to Adobe to
have the features and tags included. At last, but not the least, no one at
this IETF can commit Adobe.
Xerox: Xerox is willing to release rights for all uses in TIFF if Adobe
will adopt them and include them in TIFF-7. But no one here can commit
Xerox either.
Thus it seems a viable solution currently in a deadlock waiting for
somebody to make the first move.
At last, we have the ITU issue, who is referencing our documents. But ITU
approach to IPR is different, and a licence issued to the IETF might not
fully apply also to ITU. There is a strict need to coordinate with ITU
also on these IPR matters, to avoid future problems. It is in fact clear
that what was released to IETF is not automatically released to ITU (and
viceversa).
The discussion of the problem and the WG conclusions.
-------------------------------------------------
The original reasons for using TIFF were lightweight, extensibility and
its ITU compatibility, and it ability to be understood as a MIME type
image/tiff by most of the MUAs.
The extensions are actually needed to meet the new specification which
ITU-T had done, but the new extensions also introduce impatibility and IPR
possible clashes.
Dave Crocker suggest as a first prroximation solution to skim down the
core specification to a "safe" subset, and pursue the other issues
separately, with a separate MIME type.
Scott Forshee suggested also that other focus has been on JPEG-2000
specifications , and work is progressing on a different (planned) MIME
type including MRC capabilities. However igher level features of
JPEG-2000 are generally not widely deployed. He proposed the wg to
reconsider JPEG-2000 as an alternate to TIFF-FX. Moreover, part of the
reason for Adobe's objections are to keep the use of TIFF freely
available.
There were objections to this proposal, stating the JPEG-2000 is not yet
in good shape, has not yet a MIME type registered, too, and its wide
deployment is not existing at the moment.
A discussion followed, considering if one should simply use the version
label into MIME typ definition to define which level of TIFF is being
used, or just a totally new type.
Claudio Allocchio suggested that image/tiff should be used onlyfor minimum
interoperable features and anything else should have a different name and
label; this will have to happen for TIFF-7 in any case.
Lloyd McIntyre suggested as simple solution to revert to previously
registered version of TIFF, i.e. TIFF 6.0, excluding also any widely
deployed de facto extensions. There was a discussion on this, and Scott F.
stated that TIFF 6.0 was issued in 1992, with updates via by technical
notes, which are widely implemented. Thus RFC 2302 is OK with the way
that Adobe and others use TIFF. We should focus on the TIFF-FX spec, to
cut it back to non-controversial features.
At this point Claudio A. asked the wg members present at the meeting if
anyone strongly oppose the approach proposed by Dave C.?
Larry Masinter and Johm Klensin suggested that to be concerned with what
is practised is more important than compatibility with what is registered.
"The Right Thing to do is look at reality and try to get it right".
The wg expressed consensus on the above approach. This consensus need to be
confirmed by the mailing list.
Claudio A. summarised the conclusions to be reported into the minues, and to
facilitate the understanding of the approach by anybody including those not
present at the meeting:
- we must consider for interoperability test of RFC2301 also existing
mail user agents (MUAs), and they should be able to read image/tiff
bodyparts generated bu Ifax devices. Interoperability is the choice.
- we must also consider interoperability with existing tiff capable
software, e.g. saving the image/tiff to a file and reading it with ...
Photoshop, and other tiff files readers.
- we should produce a new interoperability report, and based on this
we should detail the revision of RFC2301, to fit any feature which
proved to interoperate in all above cases, even if not included in
basic TIFF 6.0 specification.
- thus existing tiff-fx Ifax devices go beyond this, as they my generate
extensions which do not interoperate correctly with the above
- thus we should define how to create a NEW format (both for files and
for MIME readers) with a different name which may be tiff-fx, or totally
different, to make clear to implementers and devices that "this is an
extended new format" (even if based on tiff in origin).
- the reason for removing from RFC2301 revision some features is
because they do not interoperate on the global service, even if they
proved to interoperate among Ifax implementaions.
- the "recuded set" specification will be submitted for Draft Standard
- we should, at the same time, produce a new "extended specification"
docuement, which includes the extensions existing in RFC2301 and
dropped in the Draft Standard document, and might also include the
further extensions proposed for "full mode". This document(s) should
also define a different MIME type registration for this extended
specification. This new specification should go as Proposed Standard
- we need to investigate if it is possible to declare RFC1301 "Updated"
by the new Draft Standard document, at least until the new "Proposed
Standard" document obsoletes RFC2301. ADs suggestions are expected.
- we should carefully inform ITU-T of the reasons of this choice.
- the Draft Standard version of the specification would also not have
(apparently) IPR issues related, and the extended mode one should
carefully consider IPR problems while being specified.
Furthermore, we should explain, probably in the new extended document, and
probably into the implementers guide, the compatibility reasons which led
us to this choice. In fact some manufactures already have more than
profile S(simple mode) implementations with MIME type image/tiff, for
example, Profile C(color) with image/tiff, according to existing RFC2301
and RFC2302.
After more than one hour, we closed the topic and moved forward.
3 Targeted for Draft Standard
3.1 Service
draft-ietf-fax-service-v2-03.txt
The document was sent to IESG on June 23rd with Interworking report
(published on June 18th); We added the request to wait for publication
until all normative dependencies are elevated to Draft Standard. We also
received AD comments which led to a new version circulated on our Mailing
List only.
In particular, there is the reference to RFC1984 (DSN), and a reference to
RFC2301. We should thus solve TIFF issues, too.
4 Targeted for Informational 1 min (25min)
4.1 Implementers Guide
draft-ietf-fax-implementers-guide-07.txt
The document was sent to IESG on Apr 10th and we had the letter from
ITU confirming that T.37 would refer the Implementer's guide. The IETF
Last Call on July 26th until August 26th.
It was clearly noted that also in this case we should quickly check if
there are specific references to RFC2301 which might be an issue (if
specifically refer to TIFF-FX features which could be dropped into the
Draft Standard skimmed version.
This very same revision and check is needed for the whole set of other
documents.
5 On-going Internet-Drafts
5.1 Gateway issue
draft-ietf-fax-gateway-protocol-05.txt
draft-ietf-fax-gateway-options-03.txt
Mimura-san described the main differences in the final version of gateway
documents: draft-ietf-fax-gateway-protocol-05.txt defines the minimum
requirements for Internet FAX Gateway. It defines a basic Function for the
Internet FAX Gateway, whereas draft-ietf-fax-gateway-options-03.txt
provides Information for Guideline of optional services. (See slides for
detailed differences)
Larry M. objected that the security recommendations are unclear. It is
not explicit if the document suggest S/MIME as a MUST solution, or just a
possibility. Claudio A. reminded that also the traditional problem of
"credentials" (Sender's or Gateway's) needs to be clarified, or at least
clearly stated. Maybe it's just fine if the wording is softened - "could
be" instead of "is". The WG agreed to issue a wg Last Call, considering
the above points as the first comment into the Last Call.
5.2 FFPIM
draft-ietf-fax-ffpim-01.txt
The specification has been updated today, and mailed to the wg ML; the
main actions were to remove all editor comments, to add citation and
pointer to draft-ietf-fax-esmtp-conneg-00.txt, to add an appendix
explaining the Direct Mode and to focus on need for ÒdirectÓ
configuration, including the use of ESMTP Timely and ESMTP Conneg
Apparently no further substantial work need to be done. In particular
about direct mode, some text was added to clarify that it needs some
unusual e-mail configuration to work properly. A short discussion if all
goals were met did not discovered any missing item. The question is to be
repeated to the ML before progressing to wg LC. The only question raised
was if this document should reference the "terminal mode" documents or not
at all. Dave and some other believe that there should not be any
reference, provided the fact that there is still no consensus if the
terminal mode documents should go forward.
draft-ietf-fax-content-negotiation-05.txt
The WG last call ended without comments, thus we sent the request for IETF
last call to IESG on July 21st. 2001. There were no further comments from
the WG at the meeting.
draft-ietf-fax-esmtp-conneg-00.txt
This specification allows content negotiation to take place at the SMTP
level (i.e. between MTAs). In particualr, this service extension is
intended for direct SMTP transfers and It can be used within an
enterprise's internal network.
A new keyword ("CONNEG") is added to the possible EHLO values, and the
server responds with a report of the content capabilities of the device or
system that embodies the target RCPT-TO address.
A revised version is expected by November 2001, aiming to the WG Last Call.
draft-ietf-fax-timely-delivery-03.txt
After some discussion with the ADs, Graham Klyne produced a new version.
In it the feature of allowing a message to be immediately rejected for
timely delivery will be dropped. Past experience with this kind of
feature is poor (X.400), and the use cases will generally not represent an
exacerbation of the congestion. As soon as the document is published, we
aggreed to go for the WG Last Call.
5.3 Terminal mode issue
draft-maeda-faxwg-terminal-mode-goals-00.txt
draft-maeda-faxwg-terminal-mode-protocol-00.txt
draft-maeda-faxwg-fax-processing-status-00.txt
There were wuite a number of comments on the list about this topic. As the
author is not here we will defer further discussion to the ML. However
Claudio A. asked for some opinion of the presents. We added to our
milestones the documents in the last Minneapolis meeting.
Larry M.objected that RFC2542 already discusses goals, so the new goals
document is largely redundant (apart from comments which are more like a
protocol specification), and asked if there is an intention to be more
specific about *requirements*? He also asked if anybody would object if we
did not pursue this document. As the author was not present, we deferred
further discussion to the ML.
5.4 PWG IPP Fax status report
Lloyd reported on behalf of the PWG IPP group. (see slides for a detailed
description of documents and status). Is was made clear that the activity
presetnte is carried on within the IEEE unbrella, and also that the IESG
did not accepted this activity as a possible IETF one, answering that
these activities were already covered by our wg. There was consensus from
the wg that there must be a better coordination with these external
efforts, in order to avoid any possible incomaptible products to be
developed.
5.5 TIFF-FX extension issue
draft-ietf-fax-tiff-fx-Extension-1-02.txt
(drtyre-tiff-fx-extension1-02.txt)
darft-mcintyre-feature-schema-extension1-00.txt
After remembering that all the issues in these documents are related to
the previous discussion about TIFF and TIFF-FX issue, and that IPR
problems should be clearly investigated also for these proposed
extensions, the presentation (see slies) described the further JBIG2
extensions.
Larry M. asked how many in the room read the draft: One person. As such
the question was raised if we should continue the work, if there is
interest in doing it or not, provided that at a certain point the
specification will have to undego interoperability tests, and the lack of
interest could lead to a lack of implementations. There was at the moment
no conclusion to ths question, as we need to check first the status of the
TIFF issue evolution.
6 Miscellaneous
Finally the fax charter was updated on the IETF web pages. (July 26th 2001).
An applause came from the audience.
7 Confirmation of milestone
Here is the updated list of milestones *** (please double check it !!!) ***
Apr 2001 Submit final draft of Implementers Guide for
Simple and Extended mode to IESG for publication as
Informational.
Done (see draft-ietf-fax-implementers-guide-07.txt sent to
IESG on June 2001)
Jun 2001 Submit final draft for content negotiaton to IESG
for publication as Proposed Standard
Done (see draft-ietf-fax-content-negotiation-05.txt sent
to IESG on July 21st 2001)
Sep 2001 Submit final draft for timely delivery to IESG for
publication
as Proposed Standard
Sep 2001 Submit final draft for FFPIM to IESG for publication
Sep 2001 Submit final draft of gateway requirements
Nov 2001 Submit final draft of TIFF-FX extensions
Nov 2001 Submit final draft of schema for TIFF-FX extensions
These two need further work - see discussion
Jul 2001 Submit second draft of Fax status information
??? 2001 Submit second draft of Goal for Terminal Mode
??? 2001 Submit second draft of Protocol for Terminal Mode
Dec 2001 Submit final draft of Fax status information
??? 2001 Submit final draft of Goal for Terminal Mode
??? 2001 Submit Final draft of Protocol for Terminal Mode
The meeting ended at 22:04
----------------------------------------------------------------------------
--
Claudio Allocchio G A R R
Claudio.Allocchio at garr.it
Project Technical Officer
tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio;
fax: +39 040 3758565 Research Network P=garr; A=garr; C=it;
PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09