Re: TIFF-FX: technical changes since RFC 2301

> Folks,

> Thursday, December 19, 2002, 11:04:42 AM, you wrote:
> ned> What we have here is two MIME types: image/tiff and image/tiff-fx. The  former
> ned> is defined for use with two profiles of TIFF, S and F.
> ...
> ned> I therefore think it is entirely appropriate to say that image/tiff-fx SHOULD
> ned> NOT be used to describe material that is known to conform to the more
> ned> specific image/tiff type.

> ahh.  overlapping coverage.  yes.  always a problem.  (sorry I missed that
> this was the point.)

> Forgive another bit of confusion: I've lost track of where this
> recommendation is going to be put.

Well, one way to handle it would be to put the relevant text in the
revised tiff-fx registration document and eliminate the text from the
tiff/tiff-fx specification document entirely. Another would be to have
it in both places. I don't especially care which way this is done.

> Presumably there is a good reason to have tiff-fx contain this redundant
> capability.  So, presumably, there are times when it IS a good thing to use?

I wouldn't call it a good thing but I can see some theoretical situations where
it might be necessary. For example, suppose you have an agent that sends out a
MIME object in serial fashion but which doesn't know initially which profile of
TIFF will be used. Or one which knows but doesn't have the means of
communicating this information to the MIME agent -- perhaps it was designed in
line with the original expectation that a single type would suffice for all
profiles. Saying that the MIME agent needs to be upgraded to stamp things as
tiff-fx is one thing; saying that an additional communications path  is needed
goes quite a bit further.

The possible existance of such agents argues for a SHOULD NOT, I think.

> When is that?  And can we make the recommendation be clear about the
> circumstance in which -fx use of the redundant profiles is discouraged,
> versus when it is ok?

Perhaps something along the lines of tiff-fx SHOULD NOT be used to label
profiles S and F except when the specific profile isn't available to the
labelling agent.

				Ned