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.

I think having such a recommendation as a SHOULD NOT would be good.
Authors?

> (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.

OK, sounds like we're on the same page on this one too.

				Ned