headers
John R Levine | 21 Feb 2012 19:54

Request for registration of application/gzip and application/zlib

The draft is here:

https://datatracker.ietf.org/doc/draft-levine-application-gzip/

The zlib and gzip formats are defined in RFCs 1950 and 1952. This
defines MIME types for them.

2.  The Application/Zlib Media Type

    Type name: application

    Subtype name: zlib

    Required parameters: none

    Optional parameters: none

    Encoding considerations: needs base64 or other encoding that allows
    arbitrary binary data

    Security considerations: See section [security] below

    Interoperability considerations: none

    Published specification: [RFC1950]

    Applications that use this media type: anywhere data size is an issue

    Additional information:
(Continue reading)

Permalink | Reply |
headers
Bjoern Hoehrmann | 21 Feb 2012 21:29
Picon

Re: Request for registration of application/gzip and application/zlib

* 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).
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 22 Feb 2012 08:23

Re: Request for registration of application/gzip and application/zlib

> * 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).
(Continue reading)

Permalink | Reply |
headers
John R. Levine | 22 Feb 2012 09:15

Re: Request for registration of application/gzip and application/zlib

>>> The draft is here:
>>>
>>> https://datatracker.ietf.org/doc/draft-levine-application-gzip/

For comments, please see the draft, not just the excepts I posted.  Most 
of Bjoern's comments are already addressed in the current draft.

R's,
John
Permalink | Reply |
headers
Bjoern Hoehrmann | 23 Feb 2012 00:04
Picon

Re: Request for registration of application/gzip and application/zlib

* John R. Levine wrote:
>>>> The draft is here:
>>>>
>>>> https://datatracker.ietf.org/doc/draft-levine-application-gzip/
>
>For comments, please see the draft, not just the excepts I posted.  Most 
>of Bjoern's comments are already addressed in the current draft.

If you mean draft-levine-application-gzip-00 then the excerpts seem to
be quite equivalent to the draft, and I do not see a more recent draft.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Permalink | Reply |
headers
Bjoern Hoehrmann | 22 Feb 2012 23:55
Picon

Re: Request for registration of application/gzip and application/zlib

* Ned Freed wrote:
>> * John R Levine wrote:
>> >    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.

My apologies, I meant "binary". The nomenclature does confuse me, and I
looked the definitions up again when making the comment, but apparently
it came out wrong. The point is that RFC 4288 says "one of these key-
words", not free-form text.

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

I have not checked whether the above is all that can be said, but if it
is, something like "The first byte is one of ... where 0x78 is the most
common".
(Continue reading)

Permalink | Reply |
headers
John R. Levine | 23 Feb 2012 07:29

Re: Request for registration of application/gzip and application/zlib

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

I think I'll leave the current wording.

>>>>       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.
>
> I have not checked whether the above is all that can be said, ...

Why not?  It's RFC 1950, section 2.2.

>>>> 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.
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 23 Feb 2012 23:33

Re: Request for registration of application/gzip and application/zlib

> * Ned Freed wrote:
> >> * John R Levine wrote:
> >> >    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.

> My apologies, I meant "binary". The nomenclature does confuse me, and I
> looked the definitions up again when making the comment, but apparently
> it came out wrong. The point is that RFC 4288 says "one of these key-
> words", not free-form text.

The keyword absolutely needs to be included, but free form text is often
helpful in explaining various nuances, and I see nothing in RFC 4288 that
actually prohibits it.

> >> >    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.
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 23 Feb 2012 23:44

Re: Request for registration of application/gzip and application/zlib

> As such, the requirement that security considerations for standards tree
> registration trumps any "but there is a better location" argument that can be
> made, because said better location doesn't actually exist and isn't going to
> exist.

Sorry, this was supposed to read:

  As such, the requirement that security considerations for standards tree
  registrations be as complete as possible trumps any "but there is a better
  location" argument that can be made, because said better location doesn't
  actually exist and isn't going to exist.
Permalink | Reply |
headers
John Levine | 6 Mar 2012 17:45

Re: Request for registration of application/gzip and application/zlib

I've submitted a -01 version with a few changes.  See the change log
at the end.

>https://datatracker.ietf.org/doc/draft-levine-application-gzip/

--

-- 
Regards,
John Levine, johnl <at> iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
Permalink | Reply |

Gmane