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.

Section 4 of RFC 3250 comes pretty close IMO. In fact some of the language in
section 9 of -tiff-fx-11 appears to be copied directly from there.

> > 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?

It is demonstrably practical to dispatch to the same or different applications
based on the same or different MIME types. MIME itself would not have been
promoted to draft without this being the case.

So I guess I just don't see a problem here.

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

I wasn't referring to this point.

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

I see. You did not mention that it was mandatory before. I suppose this
could be an issue, especially if there's evidence such readers exist.

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.

				Ned