RE: option 5 for TIFF-FX

Tamura-san,
In line with your request and outline I have prepared a proposed plan,
please see below.

Lloyd

Option 5 Proposed Plan

  Draft DELIVERABLES
The following three specifications should be delivered to address the MIME
sub-type issue:
1) draft-ietf-fax-tiff-regbis-03
   revisions to existing draft draft-ietf-fax-tiff-regbis-02
2) draft-ietf-fax-tiffx-reg-00
   a new draft
3) draft-ietf-fax-tiff-fx-10
   revisions to existing draft draft-ietf-fax-tiff-fx-09

Rational for these deliverables are driven by the current image/tiff MIME
sub-type definition, see appendix below, and the recent WG consensus to 
a) retain the current single TIFF-FX specification,
b) limit the image/tiff MIME sub-type definition and .tif (.tiff) file
extension to TIFF 6.0 and the TIFF-FX profiles that are renderable by the
current viewer base (Profiles S and F),
c) define a new MIME sub-type and file extension (e.g. image/tiffx and .tfx
respectively) to refer to other TIFF-FX profiles.  

  TIMELINES
The progression timeline is as follows:
- The three drafts should be available for WG review prior to November. 
- Given the limited MIME sub-type scope, it may be possible to have
incremental versions of these drafts issued as appropriate in time for the
December IETF meeting. 
- A rough consensus check of the drafts should be targeted for the December
WG meeting. 
- A test plan draft for draft-ietf-fax-tiffx-reg-xx interoperability testing
and verification of that current viewers can successfully read Profile S & F
should be available for the WG meeting.
- End of January 2002 is the target for completion of the test plan and
sign-up of participants.
- End of February 2002 may then be a reasonable target for completion of
draft-ietf-fax-tiffx-reg-xx interoperability testing, along with Profile S &
F viewing confirmation.
- WG Last Call of the three drafts should be targeted for the March IETF
meeting.
- If all is smooth, it may be reasonable that Draft Standard or at least
Proposed Standard would be issued early during 2Q02, dependent on IESG
responsiveness.


  DELIVERABLES DESCRIPTION
1) draft-ietf-fax-tiff-regbis-03
The objective of tiff-regbis-03 draft is to constrain the image/tiff MIME
sub-type and file extension definition to TIFF 6.0 and TIFF-FX Profiles S
and F.
 
The most significant draft-ietf-fax-tiff-regbis-02 edits required to realize
this objective would take the form of:
a) section 6.1 "image/tiff" - changing the image/tiff definition to refer to
TIFF 6.0 and TIFF-FX Profiles S and F encoded image data, and deleting
reference to definition of a new "application parameter". The fixed content
defined by image/tiff makes retention of the application parameter
inappropriate.
b) section 6.2  "Application parameter" - deleting this section.
c) section 7. "IANA Registration" - changing the value for "Optional
parameters" from "application" to "none", and appending appropriate TIFF-FX
Profiles S & F reference to the Published specification.
The draft-ietf-fax-tiff-regbis-03 draft would retain its Best Common
Practice non-standards track.

An outline for readability verification of Profiles S & F by current viewers
should also be prepared.

Dependencies
Availability of draft-ietf-fax-tiff-regbis-02 authors.

2) draft-ietf-fax-tiffx-reg-00
The objective of this new tiffx-reg-00 draft is to define the new MIME
sub-type (e.g. image/tiffx) and file extension (e.g. .tfx) for TIFF-FX
Profiles J, C, L and M and any TIFF-FX extensions. It may be possible to
include optional provisions for Profiles S & F - value is a comprehensive
sub-type.

It is reasonable that the WG will agree to progress
draft-ietf-fax-tiffx-reg-xx on a non-standards track path (e.g.
Informational or Best Common Practices), similar to
draft-ietf-fax-tiff-regbis-xx. 

A test plan for an appropriate level of draft-ietf-fax-tiffx-reg-xx
interoperability testing should also be prepared.

Dependencies
The WG must agree whether optional provisions for Profiles S & F should be
included, allowing for a comprehensive MIME sub-type. WG decision on the
progression path of the document, standards vs. non-standards track, will
have the greatest overall schedule impact. Progressing as Proposed could add
a year to the schedule.  

3) draft-ietf-fax-tiff-fx-10
The objective of draft-ietf-fax-tiff-fx-10 is to reference both image/tiff
and the new MIME sub-type (e.g. image/tiffx) as being required and specify
the encodings to be used with image/tiff vs. the new MIME sub-type when
transported by MIME.

The section 9 paragraph of draft-ietf-fax-tiff-fx-09 should be revised to
reference both image/tiff and the new MIME sub-type as being required, along
with stipulation as to which should be used for Profiles S & F versus the
other profiles plus TIFF-FX extensions. Section 9.1, which defines the faxbw
and faxcolor application parameters, should be deleted.
Given that the changes are isolated to a small section of MIME sub-type
reference and no new TIFF features are added, it may be reasonable that
draft-ietf-fax-tiff-fx-10 will continue its current standards track path
pending maturation of draft-ietf-fax-tiffx-reg-xx.

Dependencies
The greatest schedule impact will be driven by whether TIFF-FX is required
to be recycled as a Proposed Standard or allowed to continue in its current
Draft Standards path. Recycling to Proposed could add a year to the
schedule. 


  APPENDIX: MIME sub-type definitions:
i) RFC 2302 and draft-ietf-fax-tiff-regbis-02, currently under consideration
to obsolete RFC 2302 as Best Common Practice, describe the current
image/tiff MIME sub-type registration. The image/tiff definition refers to
TIFF 6.0 encoded image data and adds a new "application parameter"
(definition of parameter values left to other RFCs) to enable identification
of specific subset of TIFF and TIFF extensions for the encoded image data. 

ii) Section 9 of RFC 2301 (aka TIFF-FX) and draft-ietf-fax-tiff-fx-09,
currently under consideration to obsolete RFC 2301 as Draft Standard,
defines two image/tiff application parameters, faxbw and faxcolor. The faxbw
application parameter value is used for TIFF-FX profiles define to support
encoding of black-and-white image data (Profiles S, F or J), while faxcolor
is used for TIFF-FX profiles define to support encoding of color image data
(Profiles C, L or M).

> -----Original Message-----
> From: Hiroshi Tamura [mailto:[email protected]]
> Sent: Wednesday, October 10, 2001 3:06 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: option 5 for TIFF-FX
> 
> 
> 
> Folks,
> 
> > As you already know, there are lots for favors for option 5.
> > Therefore, the conlusion is "option 5"
> 
> <snip>
> 
> > I think TIFF-FX editors and the people who support it should provide
> > somthing at first. Please do it.
> 
> No mails so far. I comment it.
> 
> At first, we need new two or more I-Ds.
> - Revised tiff-fx document
> - New or Revised registration document for image/tiff or/and
> new MIME type.
> At least, those documents should be available prior to 
> December IETF meeting.
> The sooner, the better.
> 
> Next, implementation tests.
> According to the I-Ds or revised I-Ds after getting some consensus
> at the meeting or in our ML, the tests should be done.
> New MIME type tests must be included.
> It may be better to include the test for Profile S and F
> with the use of image/tiff.
> At the earliest, they will be done in January or February, I think.
> 
> After that, the final I-Ds will be availble.
> 
> License issues should be clarified in parallel.
> 
> Again,
> TIFF-FX editors and the people who support it should comment for it.
> 
> Regards,
> --
> Hiroshi Tamura, Co-chair of IETF-FAX WG
> E-mail: [email protected]
>