RE: TIFF-FX: technical changes since RFC 2301

> > (1) Addition of image/tiff-fx MIME type
> 
> This is a change since RFC 2301/2302 was published but not 
> since the RFC 2301/3302/3250 update. This document is 
> intended to be part of an update to the latter set of 
> documents, not the former.

Section 9 of -tiff-fx-11 contains normative language
about when image/tiff-fx vs image/tiff are to be used,
that image/tiff-fx MUST be used with profiles other than
S and F. This normative language doesn't appear anywhere
else. It differs from the rules for compliance in
RFC 2301: a compliant implementation of RFC 2301
might use "image/tiff" for a document with profile L.

> It is perhaps the case that 3250 should have stated
> that it updated 2301's reference to image/tiff.
> But it is too late to change that now, and I don't think
> it is reasonable to penalize the group for that omission.

I don't think it's reasonable to penalize anyone, either.

If your judgement is to allow what might otherwise be
considered a 'technical change' through to Draft Standard
as an exception, in order to make progress, that's fine
with me.  However, such exceptions should at least be coupled
with the "Draft Standard" level of demonstration of
interoperable implementations. 

Is it practical for an Internet Fax sender to use different
MIME types for different profiles, and for receivers, coded
according to this suite of documents, to interoperate
with them?

> > (2) FillOrder=1 mandatory for all readers except profile S
> > (3) elimination of ColorMap for profile L
> 
> Isn't this the removal of a feature, and hence allowed? Or am 
> I missing something?

When you make it mandatory that readers interpret FillOrder=1,
readers that previously didn't do this before would need to
add code, and the new code would have to be tested and
determined to work interoperably.

Similarly, in RFC 2301, the 'ColorMap' field was not optional
for profile L, it was mandatory. A compliant reader might have
insisted on the appearance of a ColorMap field.

But according to -tiff-fx-11, a profile L image can (and
should) appear without a ColorMap, and a reader that insisted
on one would no longer be compliant.

These are two areas where the implementations reported
don't clearly match the specification. The guideline
of 'only removing features' should correspond to
'implementation of previous spec is sufficient to
show implementation of new spec.' for the purpose
of documenting independent interoperable implementations.