A few quotes from section 5 of RFC 2045 are relevant here:
The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type.
The Content-Type header field specifies the nature of the data in the body of an entity by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the media type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute=value notation. The ordering of parameters is not significant.
registered subtypes of text, image, audio, and video should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types.
MIME media types are registered with the IANA in accordance with a procedure defined in RFC 2048. Of particular relevance for the FITS MIME effort is the stipulation in section 2.1.1 that "top-level" media types (e.g., image/gif, image/jpeg, application/postscript, and other media types which do not have a "." as a namespace separator in the mime subtype) are registered in the IETF tree.
Registration in the IETF tree requires approval by the IESG and publication of the media type registration as some form of RFC.
Section 3.7 says
HTTP uses Internet Media Types in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation.
Use of non-registered media types is discouraged.Section 7.2.1 says
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource.
Section 3.6 says that a web server and web client may engage in a negotiation that permits the file to be compressed (or otherwise modified) during transfer.
Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity.The initial IANA registry of transfer-coding tokens is defined as
chunked, identity, gzip,
compress, and deflate.
The IANA publishes the
current state of the registry.
Note carefully that
HTTP transfer-coding
is distinct from
MIME transfer-encoding.
Section 14.11 gives the proper means of describing the HTTP transmission of a file which is already compressed
The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.Unfortunately it seems reasonably clear that Content-Encoding cannot be applied as if it were a MIME "Optional parameter" with the expectation that it could be used when transferring compressed files via e-mail. This observation is based upon section 19.4.4. It appears that a complete description of compressed files transmitted via e-mail requires a new RFC enhancing the MIME standard.
Section 3.5 says that the initial IANA registry of content-coding
tokens consists of gzip, compress,
deflate, and identity.
The IANA publishes the
current state of the registry. Note that a content-coding is
a permissible value of HTTP Content-Encoding and Accept-Encoding.
See
section 19.4.5 and note that a
MIME Content-transfer-encoding is
distinct from a
HTTP Content-Encoding.