Subject: Draft Minutes for Internet Fax March WG Meeting

From: James Rafferty <[email-masked]>
Date: Wed, 07 Apr 1999 03:12:19 -0300

Folks,   

Please review the draft minutes and comment as needed.   Comments on
editorial/substance matters related to the minutes should be sent in response
to this message.   

Debate on points raised in the meeting is best handled as separate threads.   

Please submit any comments ASAP, since the IETF proceedings folks need the
minutes in by tomorrow.    

My apologies for the delay in releasing these while I was submerged in the ITU
work in Geneve.   

My thanks also for Graham Klyne for his excellent work on the minutes
onsite at
the meeting.   

Regards, 

James

Draft Minutes follow:    

Draft Internet Fax WG Minutes - March 18, 1999

Chair:  James Rafferty
Reported By:  Graham Klyne

The agenda was reviewed and accepted.   The chair noted an aim to be able to
close the work group by the end of the year, but further discussion on this
was
deferred to the milestone review later in the meeting.   

Status review, planned reference by ITU 
--------------------------------------- 
The chair reviewed the status of cooperation with the ITU Study Group 8.   He
noted that  
working with ITU SG8 gives a somewhat unique flavor to the nature of the WG
work. ITU agreed in principle to reference our work, subject to the
availability of completed  documents  RFC2530, RFC2531 and RFC2532.  
The documents have been submitted as contributions to ITU, and are due to be
discussed by 
them at the Geneva SG8 meeting, end of March 1999.

A question was raised about cooperation with the new VPIM activity and it was
felt that this is likely, especially since the VPIM work is starting to look
like UPIM -- Unified messaging.

Review requirements to progress simple mode documents 
----------------------------
The chair noted that documents with normative references to other standards
track documents cannot be progressed unless the referenced documents are also
progressing to the same level.   This means that a document like RFC 2305
cannot progress to the draft standard level unless referenced documents RFC
2301, 2303 and 2304 are also ready to progress.    There is a need to examine
interworking for in order to enable progress of these documents to draft
standard status.  Some interworking has been confirmed, but more work remains
to be done.   One IMC interworking event has been held, and another is
planned.

>> RFC 2305 revisions 
The updated simple mode service document <draft-ietf-fax- service-v2-00.txt>
was presented by co-author H. Ohno.    
.
Interoperability has been tested in US and Japan, with 17 implementations at
FaxConnect 1 in San Jose.  Changes from V1 to V2 are anupdated IPR notice,
updated references (notably to new IETF security standards), as well as 
clarifications and editorial revisions.   

In the area of intellectual property which may apply to simple mode, the chair
noted that  
IETF director Steve Coya  has approached patent holder Biscom for potential
submission of an IPR statement,  but to date no response has been received.  
As part of the progression to draft status (for the case where there are IPR
claims), at least 2 companies with 
interoperable implementations need to assert that they have independently
licensed any applicable technology required for their implementations.   
It was noted that a Matsuhita patent holder has informally  indicated that
their patent does not apply directly to RFC 2305.

There was a reminder from the chair that participants who are aware of IPR
claims are required by IETF 
procedure to declare that knowledge, OR to withdraw from working group
participation.  No position on the validity of the IPR claims is implied by
the
mention of the Issue in this meeting.

There was some discussion on the RFC 2305 revision process and the proposed
timetable of 2-3 months.   It was clarified that the  ITU process does not
impose any requirement that the documents are at a particular level (for
example draft standard), but that progress to draft standard status does
enhance a perception of stability.

The  target of 2-3 months is to allow reasonable period of time for completing
the 
interoperability testing. The timing is not driven by other requirements.
Hopefully, IPR issues will be resolved in the period.  The chair asked if 
anyone thought that this was an unreasonable 
timescale?  One attendee stated that it was not long enough.   Regarding the
procedural details on IPR policies, the applicable reference is RFC2026
section
10.3.2..

>> RFC2301 revisions 
Co-author Lloyd McIntyre presented the status of RFC 2301 revisions.   A 
revised version has been submitted as I-D, but was not available in time to be
posted prior to the meeting. The main changes are clarifications based on
received comments and interoperability tests - (see slides for details of
changes).   

The chair asked if the 
 T.44 dangling reference will be  addressed.  The T.44 recommendation was
still
pending final approval as of this meeting, but McIntyre indicated that
approval
is quite likely on April 1, 1999 at the SG8 meeting.  This follows  a long
awaited response to ITU from a JPEG registration authority (JURA) on marker
segments required by T.44.  
In addition, a statement of intentions regarding IPR from Xerox was disclosed.
(see slides for details).    Xerox owns IPR related to profile M of RFC 2301
and is working on a more formal statement to the IETF on this matter. 

>> RFC 2303, RFC 2304 (addressing) 
Author Claudio Allocchio presented the status of work in progress to provide
updated drafts for the RFC 2303 and 2304 minimal set addressing documents.   
There was some editing work done on these documents by a small group earlier
this week.   

The planned revisions  include clarification of text, the addition of a
terminology and syntax conventions section, and the addition of  IANA
considerations for registration of tokens used in addresses
It was noted  that the full addressing and minimal addressing documents
currently have 
circular references, but that this mainly pertains to registration issues. 
It was suggested that pulling IANA registration procedure into a separate
document might solve this issue.  The author will continue to work on the IANA
procedural issues to be resolved.  

Interworking of Simple Mode

 Allocchio went on to review needs for interworking testing on RFC 2303 and
RFC
2304.    
For validation of the spec, the following test environment is proposed:

submit       SMTP                            G3fax 
UA ------> submit and relay ------> offramp ------> G3 fax 

>> RFC2301 interoperability report

McIntyre reviewed a report on RFC 2301 interoperability.     Collectively,
implementers have tested interoperability of all profiles 
(see slides for details).   
The chair asked about the 
independence of these implementations.
McIntyre noted that there is a report produced by the testing companies
containing a history of the various codesets tested, which could be submitted
with the updated RFC 2301 document at the time of a request for progress  to
draft standard status.    Further details about the testing are available at: 
<<http://www.xerox.com/research/xac/tiff-fx/index.htm>http://www.xerox.com/
research/xac/tiff-fx/index.htm>.    
The companies used a pre-release of TIFF test tools from  Genoa Technologies
for this testing.

In other related matters, it was noted that the WIDE consortium has
published a
freeware version of Internet fax software and tools.  It was agreed that
having
Internet fax test services available on the Internet is very useful.
Paul Hoffman noted that IMC hopes to provide such a service hosted on BSDI,
using the WIDE freeware.
It was also noted that implementors of the J profile need to make assertions
about licensing of JBIG (ITU T.82) for the IETF interworking purposes.

Other Current Internet drafts 
------------
Author Allocchio reviewed the status of the full addessing draft
<draft-ietf-fax-fulladdr-05.txt>.   
He noted that the document has been updated to include an IANA considerations
section and 
related registrations. Service-selectors and qualif-type1 elements must be
registered.
Allocchio proposes that registrations must reference a standards track RFC;
experimental tags must 
use X- names.  

The question was raised on 
why a standards track RFC was being proposed, rather than any RFC?
Allocchio stated that he had received this advice from IANA.   

The chair and others suggested that 
if we feel strongly that a less struct requirement is OK, IANA will 
probably accept our judgement.

It was suggested that the WG  needs to be clear about what level of quality
control to apply and  
then select the appropriate mechanism.  The chair suggested that the final
details on the IANA requirements be 
taken to the discussion list, and that the WG try to resolve it quickly.  He
felt that the next revision  
of this document with the changes applied should be suitable for last call.

It was noted that the service-selector element registration has needed review
by other 
communities, but this process has been ongoing for an extended period of time.
It was suggested that the author select a mechanism from IANA considerations
RFC, discuss this with the group on the mailing list and then the WG 

will need AD concurrence with the choice.
** The chair made a call for consensus on taking the  next version of the full
addressing draft to last call and there was general support.

Glenn Parsons reviewed a draft on VPIM addressing
<draft-ema-vpim-address-00.txt>.   
He noted that in VPIM V2, no specific structure was suggested for addressing,
other than permitting phone 
numbers to appear as mailbox name in a mail address.  Some voice mail systems
can accept only numbers in the mailbox name (LHS of e-mail address).

The proposed draft uses (a) arbitrary mailbox name as per VPIM V2 (b) fax
addressing work 
for structured address formats.
VPIM= 
VOICE= 
AMIS= 
FAX= 
An attendee stated that 
it has been alleged that any mechanism that uses structure in e-mail LHS to 
determine message routing is patented. The chair noted that the addressing
documents are related to syntax and that 
behavior is not specified. Parsons also reviewed a draft on multi-part
addresses for fax and voice <draft-ema-vpim-um-01.txt>.    

The documents introduce the concept of "primary" content type, leading to
development of a 
unified messaging concept.   Other elements include selection of an
appropriate
viewer and the provision of  
meaningful "discard" rules.   For example, for  the purpose of MDN
generation, 

an e-mail client may claim message is "read" even if 
voice part has not been read, depending upon the "primary" content type
It is proposed to add semantics to multipart/voice-message (already defined
for

VPIM) and devise a new multipart/fax-message, to indicate primary content
type 
(from the choice of voice or fax).

Cover-page draft 
---------------- 
Author Mike Ruhl reviewed the Fax cover page draft <
draft-ietf-fax-coverpage-01.txt>

The purpose of this draft is to provide a way to indicate the presence of a
cover page.  The method used in the draft is to include a cover page as
part of
a "multi-part fax" MIME media type.        There was a discussion on the
requirements for cover pages and there were several different views in the
room.   It was felt that current practice in GSTN based fax will carry over
into Internet fax and that there will often be cover pages.   It was suggested
that three situations may apply: cover page not present, likely present,
definitely present.  There was also a desire to distinguish between a separate
cover page and an embedded one.   A question was raised on cover page content,
but Ruhl stated that this was outside the scope of this draft and had been
deliberately omitted.   There was also a question on whether cover pages might
be generated based on the content of mail headers.    The key issue is to
define the problem to be solved.  Further discussion is deferred to the
list.    

MDN fullmode 
------------
T. Maeda reviewed a draft on MDN fullmode
(draft-ietf-fax-mdn-fullmode-03.txt):

He reviewed his ideas about goals of I-fax: (see slides) and made a
distinction
between "eifax" and full mode fax devices.   "FullMode" is intended to be
interoperable with new fax devices and the draft's concept is to implement fax
as terminal functions over the Internet 

Four additional requirements beyond "eifax" are stated: 
- capability exchange (MDN request/mandatory response) 
- fax capability format (T.30 DIS bits, etc.) 
- fax status report (includes total pages and error page number)
- use existing infrastructure

An issue was raised suggesting that the capabilities exchange would not  work,
because scanning must wait for capabilities to be identified.   The author
replied that scanning is accomplished before transmission, and conversion
performed later when capabilities are known.   

He also stated that two manufacturers are undertaking a "fullmode" feasibility
trial. 

New conneg drafts 
----------------- 
Graham Klyne briefly described 3 drafts in process within the Conneg 
working group and noted that more detailed discussion will take place in 
the Conneg working group.   The key drafts that may be of interest for fax
are:  

content features - draft-ietf-conneg-content-features-00.txt
feature hash - draft-ietf-conneg-feature-hash-00.txt
features at URLs - draft-ietf-conneg-feature-sets-at-urls-00.txt

Review charter milestones 
------------------------- 
(see slides from Chair)

The chair suggested that the practical approach for the working group was to
review potential changes to milestones now that the simple mode and extended
fax RFCs have been published, rather than attempt to do a re-chartering.
Time
was limited, so that this was a short discussion.   

Onramp/offramp draft, targeted for informational

The chair asked if the room felt that this is important? There is a rough
consensus (but not 
unanimity) for doing this. . 

**  Later, there was a proposal that the WG focus on the 
completing Internet specific work ASAP and having the onramp/offramp work be a
separately chartered effort.  There was general consensus in the room in favor
of this approach.    
 
-    Advance Simple Mode drafts to Draft Standard  by June? The group
agreed to
shoot for this.  .

- An Implementer's guide is felt to be important.

Other items for consideration in milestones are:  
-  On-demand SMTP, for DSN to dial-up devices.
-  Submit cover page draft (standard track)

There was a brief discussion on security as it pertained to Draft Standard
status.   Some felt the WG  may need to address security better to move to
Draft Standard.  
It was suggested that there is a need to distinguish issues unique to
fax-over-email, as opposed to email in 
General, and that the WG should look for unique aspects of fax over  the
Internet. Security 
must be discussed to create a profile for global service, but this may not 
be critical path for current work.

The question of where security fits in the milestones is left for
discussion on
the list.

Combine drafts/security? 

There was no time left to discuss these items any further, so the meeting was
closed.   
--end--

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

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