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

[Bjoern Hoehrmann <[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).

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

This should probably reference RFC1950.

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

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

>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.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/