Subject:
Draft Minutes from Oslo Fax WG
Date:
Sun, 08 Aug 1999 16:55:11 -0700
From:
James Rafferty <jrafferty@worldnet.att.net>
To:
IETF Minutes <minutes@ietf.org>, Ietf-Fax <ietf-fax@imc.org>
Folks,
Attached are the draft minutes from the WG.
We have run into the deadline (which slipped past me
while I have been on the road during the past week),
so I am sending the draft version to the IETF proceedings
people NOW.
If there are any proposed edits, please send to me and/or
the ietf-fax list ASAP; if needed, I'll send out a corrected version
at the end of day Monday.
For slides presenters, please send me your slides if
you have not already. I will send the ones I have to the
IETF and to Paul Hoffman to be posted onto our web site.
For issues related to the content of the meeting, please
start new threads.
Regards,
James Rafferty
Chair, Internet Fax WG
The draft minutes of the Internet Fax WG meeting follow:
Minutes - IETF Fax WG meeting, July 13, 1999
Chair, James Rafferty
Reported by Graham Klyne
AGENDA
------
- Agenda Bashing
- ITU cooperation review
- Simple Mode progress to Draft Standard status
- Current/planned drafts
- Response to ITU SG8 communications
- Conneg WG status
- Milestone update, closing the WG
Agenda Bashing
--------------
The agenda was presented by the chair and accepted.
ITU cooperation review
----------------------
James reported on the ITU cooperation status. James and David Crocker
went to ITU-T SG8 on behalf of ISOC/IETF in March-April, 1999.
T.37 amendment 1 ("full mode") has been proposed which references the IETF
Internet Fax "extended
mode" RFCs. The amendment Was not accepted due to procedural issues with
some ITU
country members. But these appear to be minor issues that can and will be
resolved,
hopefully for approval at the ITU SG8 meeting in September (or February 2000).
As noted on the slides, the next steps are to 1) Submit the Conneg RFCs as
contributions and 2) Submit any other related documents (future items).
Simple Mode progress to Draft Standard status
---------------------------------------------
The current drafts were reviewed as follows:
Service: RFC2305 (revisions at <draft-ietf-fax-service-v2-01.txt>)
TIFF: RFC2301 (revisions at <draft-ietf-fax-tiff-fx-01.txt>)
It was noted that there is a need for TWO interworking implementations of
EACH feature in order to progress to draft standard. There is
also a need to look closely at normative references to other documents,
which must
also be at least at the draft standard level).
Hiroyuki Ohno reviewed the update of the service document (RFC2305
is the current proposed standard). The main
change from the -00 to -01 draft was to add the full copyright notice.
The 2nd FaxConnect event was generally successful, with demonstrated
interoperability between 13 vendorsand held simultaneously in San Jose and
Tokyo. The event was held in collaboration between the Internet Mail
Consortium and the Internet Fax Study Association (Japan).
For related information about the Fax Connect II event and future related
events, see: <www.imc.org>, www.ifax.or.jp, as well as
www.ifaxbus.org (new Internet Fax and Business Communications Association)
and
http://tanuki.ohnolab.org/info/FAX-Connect2/.
Most important parts of simple mode (RFC 2305) are well implemented, with
good interworking. One area that still has
limited support is the use of the DSN format for non-delivery reports.
There were significant improvements in interworking for the simple mode
between FaxConnect 1 and FaxConnect 2.
+ James Rafferty and Lloyd McIntyre reported on the status of the update
to the TIFF document (RFC2301 is the current proposed standard)
Good interworking demonstrated for S profile at Fax Connect II among 10
companies. Interworking of all other profiles has been demonstrated in
other venues. (Roughly: S profile - near universal; F profile - 50%; other
profiles - few)
Lloyd McIntyre noted changes in the draft from revisions -00 to -01, which
were
one technical change and several editorial.
(for details: see LLoyd's slides)
The technical change is to designate that the JBIG compression method is
defined by T.82 and that T.85 is a constraint
profile of JBIG. Accordingly, compression=9 will designated T.82 and T.85
will be designated by a new T.82 options tag extension. There was
some discussion about recycling at proposed or incorporating this change in
a move to draft standard. Area Director Keith Moore asserted that small
changes of this nature do not require recycling, even though "bits on the
wire" may change.
It was further noted that the dangling reference to ITU T.44 is now fixed:
T.44 (MRC) is now approved and stable.
In editorial changes, a wording clarification is needed concerning
equivalence of inch- and metric- based resolutions, such that
implementations are REQUIRED to accept both (200/204, etc) and MAY treat
them as equivalent, for consistency with the rules for 200x100 and 200 x
200 resolutions in T.30.
Regarding IPR issues, it was noted that the disclosure of licence
information is very sensitive. At least one interoperability test
participant has an appropriate licence for use of JBIG, and two more are in
progress of obtaining a licence. Disclosure of specific licencee
information is commercial-in-confidence, and is not currently available.
Two interoperability test participants are in the process of obtaining
licences for MRC (the basis for TIFF profile M).
Keith Moore noted that statements may be made to the IETF secretariat, but do
not need to be made public.
An interpretation of RFC 2026 is that implementations forming part of
the interoperability test must also assert they independently meet
licensing requirements where needed.
See http://www.ietf.org/ipr.html for the status of ipr claims.
+ James Rafferty and Claudio Allocchio reported on the status of the
addressing drafts (updated to current proposed standards RFC2303 and RFC2304)
Rafferty stated that he need more evidence about support for specific
features of these documents in order to meet the draft standard
interworking requirements. The chair requests that
any implementers with implementations of these specifications advise him of
their implementations. (Offline private
information is OK.)
It was reiterated that the call for Draft standard requires that
accompanying documentation of interworking evidence
be submitted to IESG.
Current/planned drafts
----------------------
Cover Page: <draft-ietf-fax-coverpage-02.txt>
Graham Klyne reported on the status of the cover page draft. The focus of
this draft is on the message and its primary content. There is also the
concept of "distinguished content" in the message which is not part of the
primary message.
Three different cover page cases were noted(see slides):
1) NO cover
2) Probably cover infor (prob fax onramp case)
3) The cover information is embedded or explicit via manual or automated
cover generation
Embedded content means that the cover content is part of the primary
content, whereas explicit implies a separate MIME part of a multi-part
structure.
Open issues include 1) disposition of VPIM multipart constructs for Unified
Messaging and 2) Is a particular multipart structure required when cover
information is present.
Keith Moore suggested that he would meet with a small group of fax, VPIM
and email people during the week to review the mechanism for multiparts
related to "primary content" types (i.e. primary content type is fax, also
other content)
T.30 mapping < draft-ietf-fax-feature-T30-mapping-01.txt>
This document is targeted for informational status and covers how to map
T.30 DIS bits to Internet fax content feature
expressions. It seems nearly ready for last call as informational.
Implementers' guide (no current draft) : There is much desire for this but
the chair is looking for an author(s). Some potential sources for material
from previous drafts such as "FPIM" were noted.
Response to ITU SG8 communications
----------------------------------
The ITU has no technical issues with T.37 Amendment 1 as is. However, per
the first "communication", they would like to see some improvements and
"fleshing out" going forward.
The chair believes that the Fax WG should have consensus on a written
response for ITU SG8 by September
1999.
+ Full mode:
Maeda-san reported on the ITU communication. He notes that
there is a need to reconcile differing cultures (e.g. in Japanese culture,
it is proper form for a fish to be placed on a plate with its head to the
left). We need to be sensitive to differences in culture between IETF and
ITU. RFC2530, 2531, 2532 meets ITU requirements for time being. But the ITU
culture requires:
- (2.1) capability exchange and confirmation, and clarification on how this
should be achieved.
- (2.2) information to indicate the total number of pages received.
- (2.3) MDN response should provide more fine-grained information final
message disposition in an MDN response.
The ITU request further study and discussion and more complete solutions
for addressing these requirements.
A discussion on a response was led by James Rafferty:
(2.1) there is no specific mechanism for DSN/MDN to explicitly request
capabilities as well as confirmation.
It was noted that SHOULD is a very strong requirement, and should not be
disregarded
without a very good reason. However, the chair noted that
the request is to strengthen the request requirement.
Ryuji Iwasaki-san provided a brief presentation on a capabilities exchange...
He noted that if a sender does not know receiver's capability, it must
send TIFF-FX Profile S.
If a sender needs to send higher capability, the message must be sent (and
printed) twice (first time TIFF-S, then higher capability).
His proposal is to send a new "request header" with the image AND request
capabilities. -- IF receiver is capabale of handling extended
capabilities they can choose NOT to print
the TIFF-S, but request enhanced document.
(2.2) need a more complete (i.e. universally available) mechanism for
confirmation
It was concluded that MDN message extensions should be discussed on the list.
(2.3) MDN response to indicate status of attachment processing. Require to
indicate status of body part or parts vs message as a whole.
In discussion, it was suggested that the likely route is some kind of
extension of MDN response. This is feasible,
but might make MDN responses quite long so probably any extensions should
be sent only if explicitly requested. There is a need to work with VPIM on
this, as they are looking at addressing some similar issues. This is
another topic for the small ad-hoc with Keith, as well as for followup on
the list.
+ Communication 2 on Synchronization:
It is stated that there is a need for synchronization between ITU T-series
fax recommendations and IETF RFCs, especially where
they cross-reference each other. When new T.30 features are added, how are
updates to TIFF and fax feature schema handled?
The chair presented 4 cases and their potential handling.
[[see James' slides for more details]]
1) Revision to T.30 -> New fax feature tags
Discuss: Needs IETF review to incorporate (per Conneg rules) (?)
2) New values for existing fax feature tags (based on approved amendments
to T.30)
Discuss: More streamlined process may be possible to update valid values
and IANA registry
3) Revision to T.30 attributes which may affect TIFF (RFC 2301) profiles
Discuss : appears to need IETF technical review
+
4) no change to feature schema is required; maybe just update T.30 mapping.
The potential solutions were presented to the group, but further discussion
is deferred to the list, due to time constraints. After discussion, the
chair will draft a response on this communication to the ITU for early
September review by the WG.
Conneg WG status
----------------
This item was skipped, but would be reviewed in the conneg meeting later in
the day.
Milestone update, closing the WG
--------------------------------
The chair presented a proposal for updated milestones. Key items were:
- Implementers' guide: initial draft by August 1999.
- Simple mode to Draft Standard last call: August 1999
- Cover page to last call: September 1999.
The chair targeted completion of all open items by the year end and a
potential close of the WG after the November meeting.
In brief discussion, it was suggested there is a need to look at (a)
immediate delivery and (b) security, citing security
mechanism RFCs, which might delay a WG close beyond end of year.
The chair noted that the latest revision of RFC2305 does reference new
IETF security RFCs, but they are at the proposed standard level.
Keith Moore stated that the WG should not put security on the critical
path for the main fax documents.
Possible alternatives are to 1) do a separate document of applicability of
e-mail security for
Internet fax (Call for author(s).) or 2)
maybe just put something in the implementers' guide.
Keith Moore suggest that regarding immediate delivery, what about the
"deliver by" proposed
extension to SMTP (now approved)? It was questioned whether this is really
a good idea since it seems to
invoke session semantics and consequent difficulties already identified on
the list.
It was concluded that it is possible, but not clear, that the WG will close
this year (even if there is some ongoing work to be addressed).
The meeting was then closed at 11:55.
------------ (End of Minutes) --------------
*------------------------------------------------*
James Rafferty
President, Human Communications LLC
12 Kevin Drive
Danbury, CT 06811-2901
USA
Voice/Fax: +1-203-746-4367
Fax to email: +1-603-925-5753 (Current Preferred Fax Number)
Email/Internet Fax: JRafferty@worldnet.att.net
Alternate email : jrafferty@humancomm.com, j_rafferty_hc@csi.com
HC Web Site: http://humancomm.com
*---------------------------------------------------