ietf fax WG final minutes (December 2001).

IETF-FAX WG meeting notes - S. Lake City, Dec 10th 2002

The meeting starts with the Claudio Allocchio (CA) presenting
the apologies of Tamura-san to the WG for not being able to 
be present at the meeting this time, and reporting that similar apologies 
were received from other WG members which could not attend this meeting 
due to travel restrictions still in place at their organisations and 
companies. Two of the documents editor are among the absent ones, 
Toyoda-san and Maeda-san, but their comments were sent in prior to the 
meeting and will be reported later on.

CA reminds the group that the meeting is on multicast, thus also a large 
number of absent people can follow the meeting. Unfortunately it looks like 
the multicast in one-way only, thus the only way the remote members can 
interact with the meeting is sending in e-mails to the list.

The proposed agenda in modified (see below) in order to allow John 
Klensin to join the meeting, thus postponing item 2 after item 7. 

................................................

1. Agenda bashing                                

3 Targeted for Draft Standard
3.1 Service
- draft-ietf-fax-service-v2-05.txt

CA reports on behalf of Toyoda-san. 
The draft has been modified according to the suggestions of the Aread 
Director, in particular:

- the long summeay has been changed into a real short abstract

- the "scope" is changed to "introduction" and it includes the paragraph 
about intellectual property rights and keywords

- the formating of the appendix B is fixed

The I-D has 2 normitive references 

- RFC2301 update (File Format for Internet Fax)

- RFC1894 (An Extensible Message Format for Delivery Notifications - DSN)

With regards to RFC2301 update the iscussion is delayed after point 2 is 
dealt with. On the other hand Ned Freed (NF) confirms that the processing of 
DSN document is being finally done, and it is expected to have it 
approved by the end of January 2002. NF also suggests the WG not to delay 
document submission and procesing because of other normative documents 
waiting for approval, but the correct procedure should be to approve 
these documents, go through the IESG and let the RFC editor to correctly 
manage the dependencies queue for publication. The working group confirms 
that the WG last call for this document can now be done. Futher 
confirmation from the mailig list is expected.


4 Targeted for Proposed Stanadard             
4.1 Content Negotiation
- draft-ietf-fax-content-negotiation-05.txt

The document already went throught the IETF last call wich ended without
further comments on Nov 16th 2001. The WG thus confirms the document as it
is, and asks further confirmation on the mailing lists. We expect the IESG
to process it into its queue. The expected publication date is by March
2002. 


4.2 Timely Delivery                           
- draft-ietf-fax-timely-delivery-05.txt

Graham Kline (GK) confirms that the document is ready. The WG last call 
ended on Dec 6th 2001 without any futher comment. The WG express 
consensus to progress the document to the IESG for IETF last call. This 
will be confirmed on the mailing list.

4.3 Fax Gateway
- draft-ietf-fax-gateway-protocol-06.txt

CA reminds that the IETF last call was issued on Nov 26th, and is 
expected to close at the end of January 2002. If there will be no 
comments, the the documents will enter the IESG queue.

5 Targeted for Informational
5.1 Fax Gateway                          
- draft-ietf-fax-gateway-options-04.txt

Also for this document the IETF last call was issued on Nov 26th 2001, 
and it will end in late January 2002. CA reminds that the WG asked for 
the IETF last call even if not formally needed as the topic of FAX 
Gateways has a large number of implication and impact on existing 
implementations, and thus the document describing the service should have 
the largest consensus as possible.

6 On-Going Internet-Drafts
6.1 FFPIM                                   
- draft-ietf-fax-ffpim-01.txt

Dave Crocker (DC) apologies for the delay in eding the final version of 
the document and promises the issue the final version by X-mas 2001. The 
WG thanks for the X-mas gift... As the document is out, the WG will 
proceed with WG last call (to be confirmed on the list).

6.2 ESMTP-CONNEG                                
- draft-ietf-fax-esmtp-conneg-01.txt

Ca refers again on behalf th Toyoda-san. Te I-D was revised according to 
the comments reveived by Dan Wing, in particular:

- he term "target" and "server" is unified to "target"

- the backslash is not allowed in CONNEG ESMTP lines 

- CONNECG-capable clients MUST be able to process successfully CONNEG 
lines as long as 512 characters (RFC2821).

- the ABNF syntax has been added

- a sample of EHANCHEDSTATUSCODE is added

Thus the milestone date for submission (was November 2001) has been
confirmed, and the new milestone for the WG last call is set to January
2001. The WG agrees on the changes, which need to be confirmed on the 
mailing list.


6.3 Terminal mode issue                           
- draft-maeda-faxwg-terminal-mode-goals-01.txt
- draft-maeda-faxwg-terminal-mode-protocol-01.txt
- draft-maeda-faxwg-fax-processing-status-01.txt

Maeda-san again could not be present at the meeting, but he sent a 
message to the mailing list apologising for no work at all and no 
comments at all on the above documents. CA reminds that at the London 
meeting the WG agreed that:

- is was not the case to decide there if to drop the documents from the 
WG charter, and to wait until the next meeting to see if there were 
further progress and comments on them

- to let the editor have a chance to be present at the meeting to discuss 
this issue again.

However, not haing received any comment and not having seen any activity 
on them sine a long time, CA suggests the WG to drop these documents from 
the current charter. A discussion starts, where DC suggests that it 
does not seem tha case to keep documents in the boilerplate so long 
without any discussion and progress on them, and NF and JK remind that if 
interest arises again from the WG and the mailing list, the I-D can be 
take on board again, CA asks the presents if there is consensus to drop 
these documents. No objections to the proposal are made. The mailing list 
will be asked to confirm the decision to drop these documents, at least 
for the time being.

6.4 TIFF-FX extension issue                        
- draft-ietf-fax-tiff-fx-extension-1-01.txt
- darft-mcintyre-feature-schema-extension1-00.txt

Lloyd McIntyre (LM) very briefly informs the WG that in his opinion it 
makes no sense to work on these documents now, at least until the TIFF-FX 
issue is set and there are the relevant new documents in a stable status.
As such he proposes not ti discuss them now, and wait until the issue is 
solved. The WG express consensus on this proposal, which should be 
confirmed on the mailing list. CA also reminds tha a number of comments 
were received from the WG and implementors on the chances that some of 
the options will ever be implemented and asks the editor to pay 
attentions to these comments, in order not to introduce features which 
has very little change to ever exist in reality. The WG joins in the 
suggestions an LM agrees on it.


7 Miscellaneous                               
- draft-allocchio-gstn-01.txt

CA brielfly summarizes the idea behind this I-D. During a discussion after 
the London meeting with the ADs, it was realised that the specifiations 
on how to write a "dial-string" (which includes in itself also any E.164 
and generic telephone number) into a text string was existing, but it was 
spread all over a number of different RFCs along the Standard Track. This 
was creating problems for the new documents editors, and was making the 
task of the IESG quite hard in trying to keep the new specification 
coherent with existing standards. It was also realized that nobody ever 
did the attempt to check that all existing specification where absolutely 
coherent, and nobody ever wrote a single, short and unique reference 
document collecting the pieces available around the other documents. CA 
thus collected the existing information, and searched the existing 
specification to check for coherence. The resulting document was 
published and discussed into ietf-fax, vpim, enum and apps-discussion 
mailing lists, receiving a number of immediate comments, suggestions for 
clarification and also a syntax error correction. Revision -01 of it is 
available since some time. CA urges the WG to further comments on it, 
before the documents is progessed. Larry Masinter (LL) asks if the 
intention is to progress it to BCP or Standard track, and NF answers that 
the intention is to be in Standards Track, at first as Proposed (even if a 
large part of it comes from Draft Standard docs), and the moving it 
forward. CA suggest the end of January 2002 as a possible date for the 
IETF last call for it. It is also noted that the ABNF syntax error 
present in ths I-D is existing in the published version of RFC2846. The 
editor noted it down fo correction when RFC2846 will be submitted for 
revision.

- ITU-T                                             

CA reports on behalf of Tamura-san. Since the London meeting, no ITU-T
meeting was held, thus the status in ITU-T itself did not change. The last
letter from SG16 meeting in June 2001 included their concerns for the
status of RFC2301 (TIFF-FX) update, the need for reference to the
Implementers Guide in T.37 and the issue about the Terminal Mode
documents. 

Currently the ITU-T SG16 also expressed informally concerns about the 
e-mail they recevied from Scoff Foshee (SF) from Adobe, raising IPR 
issues on the use of Adobe license for TIFF within TIFF-FX and thus ITU-T 
documents. Tamura-san already reported back to ITU-T informally that the 
WG the IESG and IAB are working on this issue and they will receive ou 
formal answer in the next letter due by the February 2002 SG16 meeting.
More over in this letter (which will be prepared by the end of January 
2002) we will inform SG16 that the Implementers guide is done and is 
currently in the RFC editor queue, and the the WG (if confirmed on the 
mailing list) will drop the Terminal Mode documents, due to the lack of 
progress and discussion on them. John Klensin (JK) confirms that the IAB 
and IESG have reached a position on the issue (see net paragraph for 
details).


2. Status of Draft Standard consideration
2.1 TIFF-FX                                      
- draft-ietf-fax-tiff-fx-11.txt
- draft-ietf-fax-tiff-regbis-03.txt
- draft-ietf-fax-tiff-fx-reg-01.txt

CA introduces briefly the topic with a summary of the situation. A 
number of e-mail has been exchanged between the WG, the 
WG-chairs, the IESG and IAB and SF from Adobe about the topic. After a 
long disucssion among the IAB, the IESG and the WG-chairs we reached the 
consensus that the issues and claims expressed from Adobe seems at least 
incoherent with the records of the IETF meetings and the mailing lists of 
the WG and of the IETF. For these reasons the IAB and IESG believes that 
the WG should continue progressing the documents, as decided on the 
mailing list after the London meeting, and submit them for appropriate 
consideration to the IESG as soon as they appear to be ready. JK and NF 
confirmed this position and invite the WG to proceed on its plans.

CA thanks the IAB and IESG for their clear suggestion, and reminds 
briefly that the WG at the London meeting expressed the opinion to 
separate in 2 documents the TIFF and TIFF-FX specifications, but this was 
changed lately on the mailing list as what has been recorded as "option 
5", i.e.:

 Single TIFF-FX specification with 2 Content-type

 Lloyd then exposes the current status of the above documents, and the
progression plan for "option 5" (See also his slides)

There will be a single TIFF-FX specification, which will be progressed. A 
decision needs to be made on how exactly to reach the needed Draft 
Standard level. See later in these notes for a detailed discussion. 

There will be 2 different MIME content-types:
    
  image/tiff for profiles S and F, which is compatible with all current
             viewers
  
  image/tiff-fx for profiles J, C, L, M, and any future one. It might also
                allow profiles S and F.

There will be 2 corresponding file extensions (even if this is not a 
"strictly standard" decision, the WG believes that it is good practice to 
define:

  .tif (.tiff) for profiles S and F
  .tfx for all the other profiles

As a consequence there is a need for 3 documents:

 - a revised draft-ietf-fax-tiff-regbis which updates image/tiff content type

 - a new registration draft registering image/tiff-fx MIME sub-type and
   the corresponding file extension (.tfx)

 - a revised draft-ietf-fax-tiff-fx which defines which MIME type to use, 
   depending on the used profiles, and updates the rest of the  
   specification as appropriate.

In order to test implementations and interoperability, the following 
"Test Deliverables" are proposed to the WG:

- A new image-tiff-fx and .tfx validation test both for MIME transport and 
  viewers

- A new viewer validation for profile S and F and image/tiff

The proposed timemelines are:

During this December 2001 meeting:
 
- make available the 3 new drafts (action done)
- reach consensus on the content of the drafts
- reach consensus on the drafts progressions paths
- agree on the whole Option 5 plan.

Before December 31st 2001:

- update drafts as per the comments received during this meeting and from 
the mailing list
- correct inside the image/tiff registration the magic number ERROR

Mid January 2002:

- issue the WG last call for image/tiff registration as BCP
- issue the WG last call for image-tiff-fx registration ad Proposed Standard

Mid February 2002

- issue the IESG last call for image/tiff
- issue the IESG last call for image/tiff-fx
- finalize the interoperability test plan, and identify participants

At the March 2002 IETF meeting

- to have image/tiff published as BCP
- to have image/tiff-fx published as Proposed Standard
- to have the test report available

Mid June 2002

- issue the WG last call for image/tiff-fx registration and tiff-fx file 
format specification as Draft Standards

July 2002 IETF meeting

- issue IESG last call for image/tiff-fx registration and tiff-fx file 
format specification as Draft Standard

Mid Semptember 2002

- to have image/tiff-fx registration and tiff-fx file format 
specification approved by IESG as Draft Standards

NF and JK confirmed that normally the 6 month "wait" period between a 
Proposed Standard publication and its progression to Draft Standard is 
based on the date of IESG approval, and that the ADs will take particular 
care to speed up document processing, based on the existing dalay caused 
by external reasons.

CA asked if there were objections to the proposed plan, and as none was 
raised, the WG expressed is consensus to proceed as proposed. The mailing 
list will ba asked to confirm this decision.

LM presented then the status of the 3 drafts.

In image/tiff registration:

- tiff-regbis-03 removes S. Zilles from the authors lists
- tiff-regbis-04 is needed to correct tiff magic number error

In image/tiff-fx registration

- version 01 registers image/tiff-fx MIME sub-type and .tfx extension for 
profiles J, C, L, M and future extensions, and may be optionally used 
ALSO for profiles S and F

In itff-fx (version 11):

- the new MIME content-type and extension are added
- a detailed specification on when to use image/tiff and image/tiff-fx is 
provided
- application parameters are removed from the specification as they might
be a source of interoperability problems
- S. Zilles is removed from the author's list

After the presentation, the WG expressed consensus on the current 
content of the 3 I-Ds, and the mailing list is required to confirm this.

As a general point, Larry Masinter commented that the WG already has a 
number of issued documents, and a number of documents which were already 
processed (WG, IESG last calls, RFC editor queue), and that now that a 
new image/tiff-fx is introduced, the WG needs to check tham all. The only 
2 Draft Standard already issued (RFC3191 and RFC3192) do not mention the 
MIME type thus are ok as they are. The implementers guide needs to be 
revised, but it is already on the RFC editor queue, for example. NF 
commented that in such a case the WG is required to check where to make 
the modifications, and the, depending on the impact of the modifications 
themselves, the IESG will decide if consider acceptable the modification 
while in the RFC editor queue, or is some recycling is needed. In case 
tha latter solution is choosen, then the IESG will again speed up the 
document progress as possible. 

CA asked ALL the editors of current drafts to carefully check their 
documents (and the member of the WG to help them cross-checking, too) 
for places where image/tiff and image/tiff-fx split might be involved, 
and provide the needed corrections and updates ASAP. Again the procedures 
for the Implementers guide (i.e. the quickiest possible path) will be 
taken also for these other docments. NF confirms that the IESG will 
define the exact procedure to be folowed.

As again the question about the possible impat of external IPR issues 
could have on the tiff-fx specification, JK reminded that there is an 
appropriate boilerplate text to be included into documents where there 
"might" be IPR issues, and that this text will point the reader to the 
appropriate IETF web pages and repository there the IPR issues and claims 
are kept up to date. IAB is also considering wther this boilerplate 
should be included in ALL published RFCs, and suggest thus to do so 
whenver the WG feels it might help in progressing a document.

Then the Draft Progression Path Concurrence is again revised:

- image/tiff revised registration goes from I-D to BCP

- image/tiff-fx goes from I-D to Proposed Standard, waits 6 months, and
is updated as I-D which goes then for Draft Standard

The WG expresses consensus on the proposed paths, and the mailing list is 
asked to confirm it.

The issue of the tiff-fx image file format specification progression path 
is more complex, as the alternates are:

a) move from I-D to Draft Standard (waiting when dependencies are done)

b) move from I-D to Proposed Standard (recycling) and the issue the 
updated I-D and more this to Draft Standard.

As the WG does believe this is a question for the IESG (i.e. which of 
alternate a) or b) should be followed), NF will take it to the IESG which 
will advice the WG.

As a conclusion, the WG expects the whole set of documents about TIFF and 
TIFF-FX to be done within September 2002.


8 Confirmation of milestones
- FFPIM

Final draft due for X-mas 2001

- ESMTP-CONNEG

Nov 2001 final draft submitted (Done)

Jan 2002 IETF last call

- TIFF-FX extension

on hold until relevant new documents are at a stable state. Maybe February
2002. 

- Terminal mode

Documents dropped, and removed from milestones lists

- RFC2301 revision documents:

(see above the detailed timelines)...

AOB and Close:

the meeting closes at 10:20pm