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

> On Sep 14, 2024, at 7:21 AM, Darrel Miller <darrel@tavis.ca> 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 <mailto: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 <mailto:dclunie@dclunie.com>
> 
> Intended usage: COMMON
> 
> Author/Change controller: DICOM Standards Committee


DICOM is not an appropriate change controller for deflate, so the request should be rejected on those grounds alone. 

If DICOM wants to mint application types that are specific to its needs, then they should name them accordingly with a dicom prefix. If they want general-purpose media types to be minted, they need to work with the authorities for those general purpose formats, which in this case means convincing zlib's maintainers to register such a media type for them, or going through the IETF consensus process as an Internet Draft.

Regardless, creating a generic media type out of a generic compression algorithm is a bad idea. It loses the information processing intent of the sender's message, which is important for content filters.  I would expect that any such registration would have to include some form of metadata prefix before the compressed content, similar to the zlib container, just to prevent abuse.

....Roy