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

[Ned Freed <[e-mail]>]

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

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

That also works for me, but frankly I don't think it is any clearer.

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

> Well, I look at it from a automated data extraction perspective, and
> little details like this make it harder to develop such tools. There
> being no good reason to use "&" sometimes and "and" other times, I'd
> prefer consistency, but I do agree that this is not a blocker.

Um, I doubt very, very much there's any automation involved...

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

> That is something the format RFCs should discuss, it's not a media type
> issue. With HTTP for instance you do not have automatic decompression
> based on the media type, but rather in a separate mechanism.

As John already pointed out, the RFCs say what they say and that isn't going
to change. Expecting someone to republish an RFC for no other reason than
to change a security considerion of this sort is simply not realistic.

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.

				Ned