Re: [IANA #1367781] application/deflate registration request

Martin,

I feel the same way about the loss of meaningful information with a media type that only describes the encoding, but there is some precedent with application/zstd https://www.iana.org/assignments/media-types/application/zstd hence why I am looking for some other opinions.

Darrel
________________________________
From: Martin Thomson <mt@lowentropy.net>
Sent: Saturday, September 14, 2024 4:43 PM
To: Darrel Miller <darrel@tavis.ca>; ietf-http-wg@w3.org <ietf-http-wg@w3.org>; httpapi@ietf.org <httpapi@ietf.org>
Cc: IETF Media Types <media-types@ietf.org>; iana-mime-comment@iana.org <iana-mime-comment@iana.org>
Subject: Re: [IANA #1367781] application/deflate registration request

The first question for me is: what does the deflate stream contain?

Part of the point of content types is to signify something about the format of the thing.  That something can be decompressed is information, sure, much more so that something like application/octet-stream, but it isn't *useful* information.  I guess, the fact that we have generic types carries the answer.

That this doesn't use a container doesn't bother me a great deal.  If there is a media type that is clearly defined, that definition can say to omit a wrapper.  In some ways, it would have been better for the content coding to omit the wrapper as well on the basis of it being redundant.  (Of course, not following an agreed standard is worse, but it would seem that the actual standard is *either* to include wrapper or not at the discretion of the sender.)

On Sun, Sep 15, 2024, at 00:21, Darrel Miller wrote:
> I am looking for feedback from the HTTP community on a proposed media
> type registration for application/deflate.
>
> The primary concern is the request defines the content to be a deflate
> stream that is not in a container.  This differs from the Content
> Coding "deflate" that is a deflate stream inside a zlib container
> https://www.rfc-editor.org/rfc/rfc9110.html#section-8.4.1.2
>
> I believe that having a media type "application/deflate" and a
> "Content-Encoding: deflate" that have two different content
> representations is going to be confusing.
>
> The requestor is of the opinion that the note in RFC9110 is sufficient
> to clarify the ambiguity.
>
> I have proposed the use of a slightly different term for the media type
> to clarify that the content is different than the deflate content
> coding. However, the requestor does not believe this to be appropriate.
>
> I think this audience has the appropriate experience to weight the pros
> and cons of this situation.
>
> Thanks in advance for your input,
>
> Darrel
>
>
> ----------------------------- Proposed Registration Request
> --------------------------------------------
> Name: David Clunie
>
> Email: dclunie@dclunie.com
>
> Media type name: application
>
> Media subtype name: deflate
>
> Required parameters: N/A.
>
> Optional parameters: N/A.
>
> Encoding considerations: binary
>
> Security considerations: deflate compression can be used to compress
> arbitrary binary data such as hostile executable code. Also, data that
> purports to be in deflate 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 skepticism.
>
> Also see the security considerations in the underlying format
> documents: Section 6 of [RFC1951].
>
> Also see the security considerations in the related zlib and gzip
> format documents: Section 5 of [RFC1950], and Section 4 of [RFC1952].
>
> Also see the security considerations in the related 'application/zlib'
> and 'application/gzip' Media Types documents: Section 4 of [RFC6713].
>
> The media type does not provide any privacy or integrity services, so,
> if needed these may be provided externally, e.g., through the use of
> TLS or Cryptographic Message Syntax (CMS).
>
> This media type employs compression, so users are warned that
> decompression may lead to significant increase in the size of the data.
> Theoretically, a maliciously crafted object could expand to many times
> its original size.
>
>
> Interoperability considerations: The primary utility of a content type
> for this encoding is as a means of conveying compressed data that is
> guaranteed to have been compressed with a specific compression scheme
> (deflate), and not as a container that may or may not have used deflate
> as the compression scheme (e.g., zlib). This allows the recipient to be
> assured (e.g., when negotiating an acceptable media type) that they
> have the necessary decoder for the compression scheme, as distinct from
> accepting a media type that they may later discover is compressed with
> a scheme that is unsupported.
>
>
> Published specification: [RFC1951]
>
> Applications which use this media: Anywhere data size is an issue.
>
> Though this submission is made by an organization specifically for the
> purpose of compressing image data of a form that is not well supported
> by image-specific encoding schemes or widely available implementations,
> it is generally applicable.
>
>
> Fragment identifier considerations: deflate encodes data as a
> compressed bit stream that is not fragmented and is decoded starting at
> the beginning of the bit stream. As such, no media type specific
> fragment identifier or fragment semantics are defined. In particularly
> no mechanism to selectively locate positions or sub-regions within the
> compressed data is defined.
>
>
> Restrictions on usage: None.
>
> Provisional registration? (standards tree only): No
>
> Additional information:
>
> 1. Deprecated alias names for this type: N/A.
> 2. Magic number(s): N/A.
> 3. File extension(s): dfl
> 4. Macintosh file type code: N/A.
> 5. Object Identifiers: N/A.
>
> Person to contact for further information:
>
> 1. Name: David Clunie
> 2. Email: dclunie@dclunie.com
>
> Intended usage: COMMON
>
> Author/Change controller: DICOM Standards Committee