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

Hiroshi,

I thought Claudio's summary was reasonably ok and I believe I 
followed his comments.  However, I am having some trouble with the 
items below.

At 5:52 AM +0900 8/10/01, Hiroshi Tamura wrote:
>Hallo Claudio,
>(and Folks)
>
>Lots of thanks for very, very detailed ****summary****.
>(Normally, one paragraph is enough within the meeting period).
>
>There are few things that I can do for our formal minutes!!
>
>Claudio,
>may I use most of them as they are, for our formal minutes,
>except for some items, which I comment below?
>
>Folks,
>As the formal minutes, I can rewrite what Claudio wrote here,
>although they will be almost the same. THerefore, please confirm and check
>the formal one again.
>
>>  Please drop comments and integrations to our ML. Thanks again o Graham
>>  Klyne who took the base notes.
>
>I also very much thank Graham.
>
>I comment and add below.
>
>TIFF-FX issue:
>
><snip>
>
>Claudio,
>Thank you for your thoughtful summary, regarding this issue.
>I would like to remove the following Claudio's comments from the 
>formal minutes,
>because this is not mentioned at all in our meeting.
>
>Claudio, is it acceptable to remove?

What is to be removed?

>
>Please reply to me.
>
>But, this is the starting point at which we have to solve TIFF-FX issue here.
>Therefore, I encourage all of the IFAX implementers to read them carefully.
>
>>  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.
>
>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.

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

>
>But, this is not decided. It depends on our future discussion.
>
>>   - 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.
>
>That's right. Therefore, please take them carefully.
>
>>  3 Targeted for Draft Standard
>>    3.1 Service
>>         draft-ietf-fax-service-v2-03.txt
>
>>  In particular, there is the reference to RFC1984 (DSN), and a reference to
>>  RFC2301. We should thus solve TIFF issues, too.
>
>I think Ned commented the editors of DSN is now preparing the new I-D.
>1984 -> 1894
>
>>  5 On-going Internet-Drafts
>>   5.1 Gateway issue
>>        draft-ietf-fax-gateway-protocol-05.txt
>>        draft-ietf-fax-gateway-options-03.txt
>
><snip>
>
>>  Larry M. objected that the security recommendations are unclear.  It is
>>  not explicit if the document suggest S/MIME as a MUST solution, or just a
>>  possibility. Claudio A. reminded that also the traditional problem of
>>  "credentials" (Sender's or Gateway's) needs to be clarified, or at least
>>  clearly stated. Maybe it's just fine if the wording is softened - "could
>>  be"  instead of "is". The WG agreed to issue a wg Last Call, considering
>>  the above points as the first comment into the Last Call.
>
>I remember that there was a comment about it.
>If my understanding is correct, updating the new ones are not necessary
>at that time for the WG LCs. Am I right?
>
>But, the modification is easy: "could be" instead of "is".
>
>>   5.5 TIFF-FX extension issue
>>        draft-ietf-fax-tiff-fx-Extension-1-02.txt
>>        (drtyre-tiff-fx-extension1-02.txt)
>>       darft-mcintyre-feature-schema-extension1-00.txt
>
><snip>
>
>>  Larry M. asked how many in the room read the draft:  One person. As such
>>  the question was raised if we should continue the work, if there is
>>  interest in doing it or not, provided that at a certain point the
>>  specification will have to undego interoperability tests, and the lack of
>>  interest could lead to a lack of implementations.  There was at the moment
>>  no conclusion to ths question, as we need to check first the status of the
>>  TIFF issue evolution.
>
>At the meeting, personally, I commented the extension of resolution are
>at least important for IFAX implenters. Because RFC2301 only supports up to
>400x400dpi.
>
>>  7 Confirmation of milestone
>
>>  Sep 2001	Submit final draft of gateway requirements
>
>Mimura-san,
>Do you modify your I-D as the above suggestion?
>
>Regards,
>--
>Hiroshi Tamura, Co-chair of IETF-FAX WG
>[email protected]