Re: IETF review of AS1

[ned.freed@xxxxxxxxxxxx]

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

				Ned