RE: TIFF-FX: technical changes since RFC 2301

(3) image/tiff-fx as 'new feature':

In general, when features are optional for the reader
and not just the writer, it can lead to interoperability
problems, because writers can send files that readers
can't understand. In some cases, it is possible that
these are 'negotiated' features (writers know whether
the readers implement the features), but I was assuming
that all features to be negotiated were worked out
in RFC 2879 (Fax media feature registry).

In this case, the new feature in -tiff-fx-11 is:
'senders may use image/tiff-fx for profile S and F'.
Since there are a number of profile S implementations
that only accept image/tiff for profile S,
this change might lead to new incompatibilities.

I think this could be fixed by discouraging use of
'image/tiff-fx' with profiles S and F, for example.

(3) profile L removing ColorMap:

> The counter would be that it was necessary to remove this due
> to there being not being sufficient interoperable 
> implementations. And historically there has been some leeway 
> granted to feature removal.

I agree that removing the ColorMap from profile L
IndexedColor would be fine if it is supported
by implementation experience: readers & writers
of profile L IndexedColor where either there
is no ColorMap or where the ColorMap is ignored.

I think it's a technical change (changing how
profile L works) and not a 'feature removal', but
it doesn't matter as long as the (multiple,
independent interoperable) implementations
agree with the spec.

Larry