Re: [ietf-types] Request for registration of application/gzip and application/zlib

[Ned Freed <[e-mail]>]

> * John R Levine wrote:
> >The draft is here:
> >
> >https://datatracker.ietf.org/doc/draft-levine-application-gzip/

> Thank you. The draft should mention that legacy applications have used
> application/x-gzip in the past, but that's discouraged, people should
> use the types you define instead.

> (Most of these comments apply to both types).

> >The zlib and gzip formats are defined in RFCs 1950 and 1952. This
> >defines MIME types for them.
> >
> >2.  The Application/Zlib Media Type

> I would prefer all lower-case for the type name.

> >    Type name: application
> >
> >    Subtype name: zlib
> >
> >    Required parameters: none
> >
> >    Optional parameters: none
> >
> >    Encoding considerations: needs base64 or other encoding that allows
> >    arbitrary binary data

> The value should be "8bit" (for both types).

???? These are binary formats, plain and simple. There's no encoding included
in them that would result in line-oriented output. 

I don't mind changing the wording to simply say "binary" if that is clearer,
but "8bit" is flat-out incorrect.

> >    Security considerations: See section [security] below
> >
> >    Interoperability considerations: none

> This should probably reference RFC1950.

Seems a little redundant, but whatever.

> >    Published specification: [RFC1950]
> >
> >    Applications that use this media type: anywhere data size is an issue

> Same here.

> >    Additional information:
> >
> >       Magic number(s): first byte is usually 0x78 but can also be 0x08,
> >       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.

> This is confusing.

Then suggest text. Not sure how else you can say this.

> >       File extension(s): none
> >       Macintosh file type code(s): none
> >
> >    Person and email address to contact for further information: see
> >    http://www.zlib.net/

> The form in RFC 4288 wants you to use "&" in place of "and".

No, really, it doesn't. Nothing says the form has to be followed to this
degree.

> >4.  Security Considerations
> >
> >    Zlib and gzip compression can be used to compress arbitrary binary
> >    data such as hostile executable code.  Also, data that purports to be
> >    in zlib or gzip format may not be, and fields that are supposed to be
> >    flags, lengths, or pointers, could contain anything.  Applications
> >    should treat any data with due scepticism.

> I would prefer simply referencing the two format RFCs, the types as such
> do not introduce additional security considerations.

This may need to be reworded to make it clearer, but AFAIK the point that these
formats decode automatically in some contexts and are therefore sometimes used
to get hostile code past overly simplistic scans is not mentioned in those
documents and *is* a known security concern. As such, it needs to be mentioned.

				Ned