[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IETF review of AS1
> So it looks like we have 3 choices,
> 1 - strongly suggest that we wish to use
> the content-encoding header inside a mime bodypart
As I explained before, this is not a viable option. Adding a new header whose
use changes the essential nature of the underlying content is intrinsicly
incompatible with the installed base. Speaking as an Area Director, I cannot
approve such a document, and even if I did, the chances it would pass
subsequent IESG review are for all intents and purposes nonexistant.
> 2 - create a new content-transfer-encoding method
This works because existing applications are required to examine this field
if present and there's a well defined way new values are to be handled.
> 3 - use one of the other acceptable headers to express compressed data.
> ex: Content-Description:
This has the same problem as content-encoding -- while content-description is a
known field, its semantics in email don't affect data interpretation.
> 4 - add a name value pair to the content-type line
> ex: Content-Type: application/xml; encoding=gzip
> or Content-Type: applicatoin/xml; conversion= gzip.
Again, this has the same problem.
> It is my preference to use a name value pair on the content-type line
> if we can not use the content-encoding header.
This is just as much of a nonstarter as content-encoding is.
You do have one other option here, and that is to drop the compression idea
entirely. But this and defining a content-transfer-encoding are the only
viable approaches I see to the problem.