Re: notes from the ietf FAX wg meeting at IETF 51

Scott,

> What is to be removed?

>From the next line,

Claudio says:
> Claudio A. summarised the conclusions to be reported into the minues, and to
> facilitate the understanding of the approach by anybody including those not
> present at the meeting:
>  
>   - we must consider for interoperability test of RFC2301 also existing 
>     mail user agents (MUAs), and they should be able to read image/tiff 
>     bodyparts generated bu Ifax devices. Interoperability is the choice.
> 
>   - we must also consider interoperability with existing tiff capable
>     software, e.g. saving the image/tiff to a file and reading it with ...
>     Photoshop, and other tiff files readers.
> 
>  - we should produce a new interoperability report, and based on this
>    we should detail the revision of RFC2301, to fit any feature which
>    proved to interoperate in all above cases, even if not included in
>    basic TIFF 6.0 specification.
> 
>  - thus existing tiff-fx Ifax devices go beyond this, as they my generate
>    extensions which do not interoperate correctly with the above
> 
>  - thus we should define how to create a NEW format (both for files and 
>    for MIME readers) with a different name which may be tiff-fx, or totally
>    different, to make clear to implementers and devices that "this is an
>    extended new format" (even if based on tiff in origin).
> 
>  - the reason for removing from RFC2301 revision some features is
>    because they do not interoperate on the global service, even if they
>    proved to interoperate among Ifax implementaions.
> 
>  - the "recuded set" specification will be submitted for Draft Standard
> 
>  - we should, at the same time, produce a new "extended specification"
>    docuement, which includes the extensions existing in RFC2301 and
>    dropped in the Draft Standard document, and might also include the
>    further extensions proposed for "full mode". This document(s) should
>    also define a different MIME type registration for this extended
>    specification. This new specification should go as Proposed Standard
> 
>  - we need to investigate if it is possible to declare RFC1301 "Updated" 
>    by the new Draft Standard document, at least until the new "Proposed
>    Standard" document obsoletes RFC2301. ADs suggestions are expected.
> 
>  - we should carefully inform ITU-T of the reasons of this choice.
> 
>  - the Draft Standard version of the specification would also not have
>    (apparently) IPR issues related, and the extended mode one should 
>    carefully consider IPR problems while being specified.
> 
> Furthermore, we should explain, probably in the new extended document, and
> probably into the implementers guide, the compatibility reasons which led
> us to this choice. In fact some manufactures already have more than
> profile S(simple mode) implementations with MIME type image/tiff, for
> example, Profile C(color) with image/tiff, according to existing RFC2301
> and RFC2302. 

By the above line.

These explain our current situation very well.
It comes from the mail and the talk between Cluadio and me, AFTER the meeting.
But, it is not discussed in the meeting.
Therefore, I propose to remove them in our minutes.

Claudio,
Please comment it.

> >I would like to add,
> >Among small talks, the new Proposed Standard (or recycle standard)
> >includes *all* features of the existing RFC2301 and the possiblity of
> >compatility issues with the use of image/tiff for more than Profile S.
> >The recycle one(the same number) is better.

Scott says:
> This paragraph was not clear to me.  I do not recall your comments as 
> part of the WG discussion.  Can you clarify?

This is just my comment to the Claudio's summary(the mail).
I did not comment there.
So, I do NOT put my comment in our minutes.
It is only one idea in small talks between Claudio and me AFTER our meeting.

Scott,
Please keep trying to solve this issue.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
[email protected]