[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes at London
Folks,
Sorry for the delay. Attached is the draft minutes at London.
It is difficult to satisfy all of you.
Some people support one thing, but others may oppose it.
I hope all of you accept it as much as possible.
But, if there are **fatal mistakes**, please let me know soon.
We have to submit it within **this week**.
Anyway, thanks again, Graham and Claudio.
BTW, Regarding TIFF-FX issue, the description here is old.
As you already know, there are already other options.
Regards,
--
Hiroshi Tamura, Co-chair of IETF-FAX WG
E-mail: tamura@xxxxxxxxxxxxxxxx
Minutes of Internet fax WG (fax) at IETF-51 London
19:30 - 22:04, August 6, 2001
Chaired by Hiroshi Tamura and Claudio Allocchio
Reported by Graham Klyne, Claudio Allocchio and Hiroshi Tamura
----------------------------------------------------------------------
1 Agenda bashing
----------------------------------------------------------------------
Hiroshi Tamura welcomed the participants and asked for eventual
modifications to the proposed agenda. As ther were no specific
change requests, the agenda was approved.
----------------------------------------------------------------------
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 needs to emphasize the generality could apply also to other
FAX wg documents, like the draft-ietf-fax-content-negotiation-05.txt.
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 are slowed down by a series of problems which
were detected during the process. ITU-T also needs a quick resolution
of the 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 should also be the start of the
"global messaging service".
The question now is: can we meet all these constrains?
Basic TIFF (TIFF 6.0) does not support colors, and different resolutions,
but it is compliant with the existing TIFF readers, and e-mail User Agents
(MUAs). It was not enough to accommodate color and higher quality ITU-T
encodings, consequently extensions were needed. These extensions were
specified in TIFF-FX, and ITU-T decided to adopt and reference it.
However, TIFF-FX functionality goes beyond that of Basic TIFF. There are
already de facto extensions to the basic TIFF specifications which are
publicly available, and widely deployed within both TIFF readers and MUAs.
All the de facto extensions are currently used in MIME type "image/tiff"
and most have no interoperability problems. The extensions introduced
into TIFF-FX are a superset, many are not viewable by most Ifax devices
and an even less amount by software applications.
To avoid interoperability issues arising from the extension, RFC2302
(currently, the draft-ietf-fax-tiff-regbis-02.txt) revised the image/tiff
MIME type to add application parameters. The image/tiff application
parameters serve to alert viewers to the presence of the TIFF-FX superset.
However, many readers do not pay attention to MIME application parameters.
Inconsistent use of application parameters is the main reason for the
incompatibility, although there may be other reasons.
The IESG and IAB would like the WG to review and document, as a condition
for advancing the TIFF-FX 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 the MIME sub-type should be image/tiff or image/tifffx
(or equivalent)"
- whether the interoperability profile is right given these issues
- and any other similar tradeoffs that might have been made
without full evaluation.
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 MRC encoding techniques
for all uses of TIFF, not just TIFF-FX, and 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.
It thus seems that a viable solution is currently in a deadlock waiting
for somebody to make the first move.
***** Consensus at the meeting *****
Some of the original reasons for using TIFF were lightweight,
extensibility, its ITU compatibility, and the ability of most MUAs
to understand its image/tiff MIME type. The TIFF-FX extensions were
needed to meet the current set of ITU-T encodings, but, the extensions
introduced compatibility issues with the existing image/tiff MIME type
and IPR issues.
A proposal was made to address the compatibility and licensing issues
with a slimed-down core specification (a "safe" subset). Portions outside
of the core set could be addressed separately and assigned a different
MIME type.
Attention remained focused on the reduced TIFF-FX subset and whether the
subset should be consistent with Basic TIFF and the original image/tiff
registration (i.e. RFC1528) or a new set determined by encodings that are
readable by current prominent viewers.
Considering the above, the members present agreed to "safe subset"
of TIFF-FX for Draft Standard consideration.
Final consensus will be established on the IFAX ML.
***** Additional summary and next steps *****
A summary of identified TIFF-FX options and WG next steps follows:
[[[Some of them were not directed at the meeting.]]]
[[[Other options are already discussed in ML.]]]
- Level of interoperability should be established by conducting a test
of RFC2301 (currently, draft-ietf-fax-tiff-fx-09.txt) using existing
mail user agents (MUAs) and tiff capable software applications
such as PhotoShop and other tiff viewers. The software viewer test
may be accommodated by saving the RFC2301 image/tiff stream to a file
with .tif or other appropriate tiff extension.
- An interoperability report should be generated and used to document
the set of image/tiff interoperable TIFF-FX encoding parameters,
such as coder, resolution, paper size and color components.
- Select a TIFF-FX option to move forward, some of the identified
options were:
1. Full TIFF-FX: - retain the currently defined TIFF-FX draft
without modification of the encoding set and define both a new MIME
type (e.g. image/tifffx or image/tifx) and a new file extension
(e.g. .tifx or .tfx). The new MIME type and extension would prevent
interoperability issues with image/tiff.
2. Interoperable TIFF-FX: - use the new interoperability document
to generate a TIFF-FX subset that is image/tiff interoperable and
retains the current image/tiff MIME type and file extension.
3. Interoperable and non-Interoperable TIFF-FX: - use the new
interoperability document to generate two subsets, a) Interoperable
TIFF-FX, as per #2, and b) non-Interoperable TIFF-FX, which is
composed of the remaining encoding subset. As with Full TIFF-FX,
define both a new MIME type and a new file extension for
the non-Interoperable TIFF-FX.
- The selected TIFF-FX option and the reason must be documented and
communicated to the ITU. Also, IPR issues should be communicated.
- Both the resulting specification and the Implementors Guide should
contain explanation of the interoperability issues and countermeasures.
Because, some manufacturers already have implementation that deal
with more than Profile S with image/tiff, such as Profile J and C,
according to RFC2301.
- The resulting specification may be resubmitted to the IESG for
Draft Standard consideration.
----------------------------------------------------------------------
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 ML only.
In particular, there is the reference to RFC1894 (DSN), and a reference
to RFC2301. We should thus solve TIFF issues, too. Regarding DSN,
the editors are preparing the new I-D.
----------------------------------------------------------------------
4 Targeted for Informational
----------------------------------------------------------------------
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
5 On-going Internet-Drafts
----------------------------------------------------------------------
----------------------------------------------------------------------
5.1 Gateway issue
----------------------------------------------------------------------
- draft-ietf-fax-gateway-protocol-05.txt
- draft-ietf-fax-gateway-options-03.txt
Katsuhiko Mimura 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.
A member 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 Allocchio 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.
----------------------------------------------------------------------
5.2 FFPIM
----------------------------------------------------------------------
- draft-ietf-fax-ffpim-01.txt
The specification has been updated today, and mailed to 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 Crocker and others 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 agreed 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
Toru Maeda, the author, were absent.
There were a number of comments on the list about this topic. As he was
not here, we will defer further discussion to the ML. However,
Claudio Allocchio asked for some opinion of the presents. We added
terminal mode to our milestones in the last Minneapolis meeting.
A member commented "draft-maeda-faxwg-fax-processing-status-00.txt"
could be used not only in terminal-mode but in existing ones.
A member objected, because RFC2542 already adresses 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.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 described the further JBIG2 extensions.
Toward the end of the Schema extension presentation, a member ask how many
had read the draft, there was no clarifications as which draft was being
referenced. He suggested the lack of interest could lead to a lack of
implementations.
There was acknowledgement from a member who had reviewed the Schema drat.
The requestor then asked whether the work should be continued,
without much response.
A member commented that the extension of resolution is important for
implementers. Because RFC2301 only support up to 400x400dpi.
No conclusions were made.
----------------------------------------------------------------------
6 PWG IPP Fax status report
----------------------------------------------------------------------
Lloyd McIntyre reported on behalf of the PWG IPP group. It 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.
----------------------------------------------------------------------
7 Miscellaneous
----------------------------------------------------------------------
Finally the fax charter was updated on the IETF web pages
(July 26th 2001). An applause came from the audience.
----------------------------------------------------------------------
8 Confirmation of milestone
----------------------------------------------------------------------
Here is the updated list of milestones.
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
Nov 2001 Submit final draft of ESMTP-CONNEG for Last Call
[[[The author of the followings was not here.]]]
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
----------------------------------------------------------------------
9 Close
----------------------------------------------------------------------
The meeting was closed.