RE: Recommendations on Comments to draft-ietf-fax-tiff-fx-11/12.t xt

Thanks for the feedback on the recommendations. Most of it I recommend be
used in the next draft. Detailed responses are inserted in the text below.

Regards,
Rob

> -----Original Message-----
> From: Larry Masinter [mailto:[email protected]]
> Sent: Wednesday, May 21, 2003 11:45 AM
> To: [email protected]
> Subject: Recommendations on Comments to 
> draft-ietf-fax-tiff-fx-11/12.txt
> 
> 
> Thanks for sending a reply (5/16/2003)
> 
>   http://www.imc.org/ietf-fax/mail-archive/msg02621.html
> 
> to my comments (12/2002, recap 1/13/2003)
> 
>   http://www.imc.org/ietf-fax/mail-archive/msg01512.html
> 
> 
> Here are my responses (8/21): 
> ========================================================
> (1) 'Addition of image/tiff-fx MIME type'
> 
> I accept the response of removing section 9 and instead adding a 
> pointer (non-normative) to the image/tiff and image/tiff-fx 
> registration documents.
> 
> In addition, in "Abstract":
>    Files formatted according to this specification use
>    the image/tiff MIME Content Type.
> 
> I suggest removing this sentence, since it is incorrect.
> 
> Section 1.2 "Approach":
> 
>    The MIME content type of the resulting file
>    will be image/tiff, with an optional Application
>    parameter [TIFF-REG]; see section 9.
> 
> I sugest removing this sentence, since it is incorrect.
> 

[Rob] Besides removing these two sentences, I recommend removing another
reference to the MIME content type in Section 1.3.

> 
> =======================================================
> With respect to
> (2) FillOrder=1 mandatory for all readers except profile S
> 
> the reply was
> "Multiple independent interoperable implementations documented of 
> FillOrder=1 for all profiles, except Profile S."
> 
> But several implementations which were compliant
> with RFC 2301 on this point but which are not
> compliant with this document.
> 
> I don't object to moving forward with this change, but
> I think it's worth noting more explicitly. For example,
> an effective way of addressing the point is to
> reorganize Appendix C, which lists changes to the
> document since RFC 2301. E.g.,
> 
>  ** Technical changes since RFC 2301
>    1. To insure interoperability, FillOrder=1 was
>     made mandatory for readers of all profiles except
>     profile S. Note that this change might cause
>     some implementations conforming to RFC 2301
>     to be considered non-compliant.
> 
>    2. The following changes were made based on
>    implementation results, to bring the document
>    in line with what was actually implemented:
>      (points (3) and (4)
> 
>    3. The following changes were made to clarify
>    the document or to bring one section in line
>    with other sections:
>     (e.g., point 5)
> 
>    A number of other editorial changes were made,
>    but are not listed here.
> 

[Rob] The technical change to Section 5.2.1 had the effect of aligning the
text with the table in Section 5.4. Identifying technical changes in Annex C
seems useful. Another way of doing so is flagging them in the current
layout, which would save having to reorganize Annex C. However, beyond that,
I wonder about even including Annex C in future versions of the document,
since when the draft issues as a Draft Standard, it will obsolete RFC 2301.
  
> 
> =======================================================
> (6) Orientation != 1 (optional for both
> readers and writers will result in non-interoperability
> for mirror-images), you replied:
> 
>    Orientation is an "informational" field: facsimile doesn't
>    typically generate mirror images.
> 
> Nothing in the document suggestions that Orientation
> is 'optional', and nothing in the document suggests that mirror images 
> shouldn't be generated. While many fax viewing programs have provision 
> for rotating, many do not have provisions for viewing a mirror image.
> 
> I suggest annotating the description of "Orientation"
> with the note 'Orientation is an informational field.'
> and 'Writers should not generate mirror images, because many readers 
> will not properly reverse the image before display or print.'
 
[Rob] The "Orientation" field is defined in Section 2.2.3, which lists the
fields that MAY be included, i.e. are optional, in all profiles. I agree
writers should not generate mirror images, but this is facsimile and a
viewer might feel bound to reproduce the data exactly as sent. Still, I
think a note alerting viewers and printers would only be helpful.

> 
> =================================================
> (7) PhotometricInterpretation=1 for profile F
> 
> I think I may have mis-read table 4.7 or the
> interoperability report; I apologize. 
> ==============================================
> (8) Comments from section 5.2.2 of RFC 3249
> in description of profile C => adding RFC 3249
> as a non-normative reference.
> 
> since RFC 3249 references RFC 2301 which is updated
> by this document, it may not be clear which recommendations in it 
> still apply. A direct reference to section 5.2.2 would be more useful. 
> I suggest adding to the description of profile C:
> 
>          Note section 5.2.2 of [RFC 3249].
 
[Rob] Your suggestion would make it be more useful. I recommend including
the note you propose in the definition of the Decode field in Section 6.2.3.

> ==============================================
> (9) and (10) applicability statement, and use of 'TIFF'
> 
> I think the main issue is that the document doesn't
> really mention the main reason why we went to
> the trouble to separate 'tiff' from 'tiff-fx':
> that while this specification uses "TIFF" as
> a baseline, widely deployed TIFF readers will
> not handle many of the extensions described
> here.
> 
> Your reply was "Should be OK as long as its
> use is confined to this document."
> 
> I suggest extending the paragraph
> 
>    This specification of TIFF for facsimile is
>    known as TIFF-FX (TIFF for Fax eXtended).
> 
> Perhaps you can come up with a better
> wording, but something like the following:
> 
>    Although this specification uses the terms 'TIFF'
>    and 'TIFF for Facsimile', files that
>    conform to some profiles in this specification
>    may not be interpreted correctly by
>    TIFF applications; references to the
>    format described by this specification
>    should always use the term "TIFF-FX".
>

[Rob] This seems like another good suggestion. I plan to add the text you
propose, or something in the same spirit, in Section 1.

 
> 
> Regards,
> 
> Larry
> --
> http://larry.masinter.net