Subject: Final Minutes from Chicago WG Meeting

From: James Rafferty <[email-masked]>
Date: Wed, 16 Sep 1998 11:53:16 -0400

Folks, 

No comments were received on the editorial aspects of the minutes, so I'm
sending them ahead to the IETF secretariat.  In addition, some PPT
presentations made at the meeting will be posted to the ietf-fax web site.  

If there are any issues related to the results of the meeting on various
topics,  please start up new threads to discuss these.    Most of the
conclusions
consisted of guidance to the authors of various drafts, so as the drafts
are updated, comments can be made in response.     

Thanks again to Graham Klyne for recording a good set of minutes.  

Regards, 

James Rafferty 
Chair, Internet Fax Working Group

Final Minutes Follow:  

Internet Fax Work Group Meeting - August 26 and 27

Chair:  James Rafferty
Reported by Graham Klyne

ITU cooperation review - James Rafferty

(see slides "ITU Cooperation")

The chair reviewed the status of cooperation with the ITU Study Group 8.   The
groups cooperated to produce the simple mode specifications.   The clear
message from ITU is that they are pleased with the results  so far, which has
included direct participation by ISOC delegates at ITU meetings and want to
continue the ISOC/ITU relationship for the next level of Internet fax
standards.   

The "Communication" from ITU sets out ideas on full mode requirements, which
have triggered some further discussions.

Rafferty reviewed the ITU meeting schedule, which calls for meetings in early
November and next March.   The ITU would like to begin the approval process
for
the "full mode" of Internet Fax at the November meeting.    In line with this,
the chair proposes that the group focus its efforts and aim to submit and
stabilize WG core work on "extended mode" by the November ITU meeting in order
to help ensure a single coherent standard for Ifax.

In particular, the group needs to be clear about which extended mode
components
can be completed in this timescale, and which others which must be deferred
for
later consideration.

The work submitted in August will be the DSN, MDN RFCs and the -eifax- draft.
Final version(s) of -eifax- based work would be targeted for ITU submission by
October 1998. Also, a response to the ITU "communication" should be drafted by
the end of September 1998.  

The room was supportive of the direction outlined, and is prepared to work
aggressively to meet the deadlines over the next two months.
.
WG charter review - James Rafferty

(See slides "Charter Review".)

The chair reviewed plans to update the charter.   It is proposed that "Full
mode" be pared down to core essentials that can be agreed quickly.  This would
be followed by related work that would continue over the next several months.
There is also a need to review the "simple mode" documents, with view to going
to "draft standard" (also needing documentation of interworking
implementations).  The core documents targeted for completion within the WG
during September are : -eifax- and "-features-schema-".

An issue was raised that  this schedule may be held up by 'conneg'
documents schedule (especially -reg- and -media-features-).  It was noted that
the -reg- document is pending an IETF Last Call.   oncern was also expressed
that there should be time to take account of any comments that may come from
the ITU review.  The chair believes this can take place immediately following
the ITU November meeting.   In this scenario, the ITU would need RFC
numbers by
December 1998.

The Address extensions document is also approaching stability and is also
targeted for completion in the near term.    

The chair also reviewed items which are not on the immediate critical path,
but
could be addressed within the work group.   

(See "Charter review III" slide)

Some of the confirmation issues may require review of some aspects of
e-mail architecture, so must be dependent on other groups as well as our own.
The Mailcap BOF held this week is expected to result in a new WG, which may
provide  mechanisms that are useful for exchanging fax capabilities.  E164
resolution may also have some applicability to what the WG needs  in this
area.  

A question was raised about developing real-time fax standards in the WG, but
indications are that this is out of scope for the current Ifax working group,
especially since the ITU has already developed the  real time T.38
recommendation.   Another possible solution is IPP (looking somewhat like
real-time fax). From the AD: we would need substantial justification to
take on
work that competes directly with ITU T.38.

In another charter related item, there was  consensus in the room that the
-goals- document should be put to WG last call (as informational) to document
the problem we were trying to solve.

Revisions to the "simple mode" RFCs will be considered and related milestones
will be included in the updated charter. A comment was made  that a milestone
should be in the charter for completing security-related work, but it was
noted
that the ability to do so in a timely manner is dependent upon progress in
e-mail security. It was suggested that security is probably related to
capability exchange (e.g. key/certificate and capability distribution may be
combined).

There was support for the charter direction as outlined; the chair will
prepare
an updated draft charter for circulation to the mailing list.   

Store-and-forward extended/full mode - Dan Wing

Dan Wing outlined steps to be taken to reduce the -eifax- draft to a core
document.

(See slides used for Dan's presentation)

1.  Emphasis on describing standard operation of the "eifax system", which
consists of the 
Sender+receiver+infrastructure(MTAs). Thus compliance applies to the
overall system, not specific components.
-- Consensus OK.

2.  Reduce section discussing security and encryption, by using references to
other
documents and eliminating  overlap with RFC2305. The security section will be
retained, but simplified.
-- Consensus OK.

3.  Remove references to quick delivery, offramps. These will be addressed in
separate documents.   Plan to write separate
documents covering onramp/offramp behavior.   A separate document

will be written to clarify the roles -- this may be in the communication to
the
ITU,  followed up by a formal document. Terms will be described in the -goals-
document. Detailed wording is left to the document author(s).
-- Consensus OK.

Confirmation of Receipt  

Dan Wing reviewed proposed changes to the wording of the -eifax sections on
Delivery Confirmation and Processing confirmation.    The proposed wording
changes were first reviewed for understanding and then the chair conducted a
consensus check on each of the proposals.   

Slide 7 - There is new wording proposed for DSN/MDN requests tosimplify those
sections. "If EIFax sender wishes to receive processing confirmation it MAY
request an MDN".  (i.e. use of MDNs to learn about processing is part of the
standard, but is not
mandated).  References in the current draft to different behaviors depending
upon the type of recipient are eliminated.   

Consensus:  Yes

Slide 8 - Addition MDN: "If a recipient receives an MDN request ... MAY
indicate success ... SHOULD indicate processing failure". There are possible
problems here if multiple clients are used against a mailbox. There are ad-hoc
solutions to this scenario, but no "standard" solution was offered (apart
from,
possibly, user choice). There was a voice raised requesting "SHOULD" for
processing success. But "SHOULD" is a strong requirement, and there are
potential architectural issues. The wording deliberately talks about
"recipient" rather than "user agent" or other more technically specific terms,
to allow flexibility in overall system implementation.  Behavior of any single
component will generally need to vary (e.g. be configurable) depending upon
the
scenario in which it is deployed. It was suggested that the wording needs
strengthening, but MAY/SHOULD/MUST is not appropriate. Also, try for
consistency of wording style in the successive sections.

-- Consensus OK on the principle, with author(s) to find better form of words.

There was a plea to the e-mail community for a possible mechanism that can be
mandated to return (non-)processability information (unlike MDN). It was
indicated by Ned Freed that mandated processing-failure messages might be
achievable in the short term,  for automated recipients, but probably not for
human recipients. 

[[Further discussion and consensus gathering deferred until the next day,
where
these points were re-visited]

Slide 8 - Addition DSN: "If MTA knows that user will not process message, it
MAY generate delivery failure 5.6.x". The rationale is that an MDN response
cannot be unsolicited, but a DSN may be used to generate unsolicited notice of
non-processable messages. This is consistent with the existing Ifax (simple
mode) work. There was discussion suggesting that MAY should be SHOULD and that
a simplified wording was possible.  The author agreed to consider alternative
wording overnight.   .

On-demand SMTP 

Ned Freed provided a brief review of three possible options for using SMTP in
on-demand situations.  This may be applicable in Ifax for situations such as
for dialup or occasionally connected clients.   

SMTP is a "push" protocol (only). POP/IMAP are "pull" protocols, but not
appropriate for some uses

Three "pull" (on-demand) options:

1. TURN command -- in RFC821

This causes the client and server roles roles to be reversed, but it  is
wide-open to abuse. This option has been deprecated in the DRUMS updates to
RFC821, so it is not recommended.   

2. ETRN
...
1C: ETRN domain.com
2S: 220 service started

Host (2) then connects to host (1) as a client. This overcomes the
spoofing problem: a new connection is created, which is safer. The main
problem
is that it doesn't work with dynamic
address assignment (i.e. no domain name defined). 
This is defined in proposed standard, RFC 1985.  

3. AUTH + ATRN

Same as TURN in most ways on-the-wire, except:
(a) requires use of SMTP AUTH
(b) adds domain parameter to ATRN

This can be implemented without having a full SMTP server on the port (i.e.
the
software recognizes ATRN, then becomes a client.) The scope is for an entire
domain, not an individual mailbox. The author indicated this *could* be
addressed in the current proposal, but has not been to date.   

It was pointed out that ATRN (with SMTP pipelining) is a better choice than
POP
from a performance standpoint for single-mailbox downloads. 

The Mailing list for ATRN is <ietf-disconn-smtp[-request]@imc.org>
The current draft is: <draft-gellens-on-demand-04.txt>, which was scheduled
for
review in the mail extensions BOF the next day.   The implications and
requirements for using ATRN for Ifax need more discussion.   

** The meeting continued on Thursday, resuming where it left on the matters of
confirmation within the -eifax draft and proposed wording changes, before
continuing with the planned Thursday agenda.
Slide 7 (re-visited) Addition MDN: "If a recipient receives an MDN request ...
SHOULD respond to the MDN". Comments from after yesterday's meeting that
different MDN response criteria might apply to automated recipients vs human
recipients.  Suggested words: "If the recipient is an unattended terminal, the
MDN response MAY be automated".

-- Consensus OK on principle, with author(s) to find better form of words.

Slide 8 (re-visited) Addition DSN: "If MTA is able to determine that the
message cannot be processed, it SHOULD generate delivery failure with status
5.6.x".  Rationale: an MDN response cannot be unsolicited. Using DSN in this
way allows the possibility of unsolicited non-processable messages. It is
likely that a new status code will be defined, rather than using 5.6.x.

-- Consensus OK, wording may be simplified by author

Slide 9 - Miscellaneous changes were reviewed: 
- define processing
- add note that DSN is deterministic
- re-write intro and section 2 with emphasis on *system*
- Remove 7.1 (multiple POP clients)
- RFC 974 to implementation note

-- Consensus OK 

Reporting extensions

(See James' slide)

The chair noted that there is a reporting-extensions draft.   It appears that
extensions to the current DSN/MDN model may be needed, but
these must be done by the e-mail community and will take place over a
longer timeframe than the immediate -eifax work.

Capabilities/Identification

(See James' slide)

The chair noted a  strong requirement to report failure to process. This may
need some extension to the e-mail notification framework -- it doesn't fully
fit either DSN or MDN.

Dan Wing presented a single slide (slide 12) on proposed changes to the -eifax
draft related to capabilities.  

The mechanism is unlikely to  be finalized in current timeframes, therefore
manual configuration of sender is explicitly allowed.

The immediate focus will be on media features, not other T.30 capabilities.

There was a suggestion that the SDP protocol (Session Description Protocol.)
[RFC ????] should be considered for ideas.

(James' slide "Cap Exchange - Features" -- list of current drafts)

(James' slide "Cap Exchange - Features (2)")

Lloyd McIntyre discussed  T.30 capabilities and how it related to the -eifax
work.   Relevant items include TIFF profiles, paper size, resolution options,
coding and colour model options.

Toru Maeda announced a new draft was sent to the fax list that proposes an
alternative approach to capability exchange using a new MIME type and empty
message to trigger transmission. 

There was a comment on  a  "metadata" content-disposition draft. Content
features might be sent in a body part thus labeled. This suggests a new MIME
type for carrying media feature metadata. Some work is being initiated.
Contacts for this are Ted Hardie/Chris Newman. vCard specification was
suggested as a way of carrying this information, rather than a new MIME type.
There is also possible tie-in with LDAP and certificate access.

A straw poll was conducted on developing a draft for fax media feature schema
development, to capture ideas in T.30 as they relate to Ifax.

General consensus - OK

A straw poll was also conducted on the  definition of a related MIME type for
capabilities.

There was no consensus, so this question is to be deferred to the mailing
list.

Capabilities -- feature representation

Conneg chair Ted Hardie reported that the registration draft has gone through
WG last call, and is requested to go to IETF last call. The algebra draft
exists to define a framework for combining individual media features into
capability statements.

-- Consensus OK to use 'conneg' framework for fax feature schema

Capabilities -- Mechanisms

(James' slide "Cap Exchange - Mechanisms")

There was a comment from the room about  dependence on directory-based
mechanisms for distributing capability information, since there is evidence of
resistance to deploying
this kind of approach. It is suggested that the use of e-mail (e.g.
DSN,MDN,etc.) may be a more popular option for actual deployment -- at
least in
the near term.

Another comment is that a combination of directory and other methods may be
deployed. E.g. directory is local source of information, with e-mail used to
communicate across organization boundaries. This suggests that both MIME and
LDAP schema should be defined.

It was noted that the 'Mailcap' BOF (which is likely to become a work group)
may produce a useful mechanism. The Mailing list is <[email-masked]>; to
subscribe, send to <[email-masked]> with SUBSCRIBE in the body.).

The chair summarized by noting that the aggressive target for the
-fax-features-schema- WG last call is by September 15. This is 2nd core
document for EIFAX.  The choice of preferred mechanism probably must come
later.

Schedule - core documents

(James' slide "Proposed Schedule - Core Documents")

The chair reviewed the core documents with last call dates and schedule for
submission to ITU.  The timetable had been accepted by the room during the
charter agenda item.  

Review of Other drafts:

-fulladdr-03- (Claudio)

Claudio Allocchio reviewed the -fulladdr-03- draft.  The details in this
document are not fax-specific, but part of a generalization of the framework
adopted for simple mode.  The Mixer folks want to use this approach.   He
believes that it is nearly ready for last call.

There was some discussion on how the draft related to the use of fields for
cover page generation.   The framework of -fulladdr- is claimed to easily
support the common case of fax cover generation, with extensibility using
references to less common cases. This
is a tricky problem, without a clear single solution at this time. Also, It
was
noted that the cover page is really an offramp issue, to be picked up in a
later
document. 

Dan Wing reviewed ietf-fax-smtp-session-04.txt.  This document has been
declared out of scope for the Fax WG by the AD. There was a suggestion to
promote it as an experimental private contribution. Also may be useful as an
option for message tracking.

Toru Maeda reviewed draft-ietf-fullmode-application--00.txt with related
slides.   

He notes various applications in Group 3 fax, including 

Polling, Subaddress and password, 
Relay broadcast, and 
BFT transmission.  

There was only brief discussion.  It is not clear if direct support for these
applications is needed in the extended mode of Ifax.   For example, MIME is an
equivalent for BFT in e-mail, so BFT conversion to MIME may simply be an
onramp/offramp issue.    

Simple mode interworking
(James' slide "Simple Mode Interworking")

The chair noted that activities are beginning to address simple mode
interworking based on the standards track RFCs 2301-2305.    

Those interested should sign up for the following mailing lists.   

<imc-faxconnect[-request]@imc.org>
<<http://www.imc.org/imc-faxconnect>http://www.imc.org/imc-faxconnect>

The date and location have been determined. Detailed planning is to start
early
in September. This is an Engineering event, NOT a marketing event. It will be
attendee driven testing and may include some T.38 testing.

It was noted that moving to draft standard involves documenting
interoperability on each feature. There was a call for testing framework
submissions (to the mailing list) to help build framework for interoperability
documentation.

Lloyd McIntyre and Rob Buckley reviewed current activities in TIFF
interworking
based on RFC 2301.  TIFF profile testing has matured quickly. The concept
is to
start with known images, pass
through a TIFF writer and reader and then do a compare with the original. Test
cases are designed to cover all features and options. Prototype utilities have
been developed for a TIFF file validator, comparators, viewers. It is

anticipated that these would eventually are be available in a product form.

To date, profiles S,F,C,M have all been tested and interchanged. (M at
preliminary stages.)  The goal of the companies involved is that all of the
profile testing would  be complete by December 1998.

The chair then closed the meeting and thanked the participants for productive
efforts.  

------- End of Minutes ---------------------

*------------------------------------------------*
James Rafferty			
President, Human Communications 	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email:  [email-masked]
	 [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 16 Sep 1998 10:07:55 -0700

>presentations made at the meeting will be posted to the ietf-fax web site.  

They are there now. See <http://www.imc.org/ietf-fax/>.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Krish Chinnaswamy <[email-masked]>
Date: Sat, 19 Sep 1998 12:44:01 +0530

Here are the terms we use internally after grappling with the
same terminologies for quite some time.

Ifx  (or I-Fax) - for Faxes delivered via IP fax sessions
Efx  (or E-Fax) - for Faxes delivered via Email sessions

I-Fax and E-Fax  may be construed as imitations to skirt
around existing trademarks.

--
mailto:[email-masked]
Phone/Fax: +1-91-422-236762 or 233939
Time Zone: PST+12:30