[media-types] Request for review of Media Type application/lzip

[Antonio Diaz Diaz <[e-mail]>]

Dear media types reviewers,

I'm trying to publish draft-diaz-lzip[1] as a RFC so that I can register at 
IANA a media type, a content coding, and a structured syntax suffix for lzip 
compressed data.

[1] https://datatracker.ietf.org/doc/draft-diaz-lzip/

I wrote to [e-mail] some time ago[2], but I didn't receive an 
answer, so I'm writing again here.

[2] 
https://mailarchive.ietf.org/arch/msg/media-types/3omIepWY_Fsjriy8GcrHoUk9C3Y

I'm posting the IANA part of the draft here for review. Could you please let 
me know if this media type proposal is OK? Thanks.

The type is widely deployed. Most archivers support the lzip format. Many 
browsers and package managers support the media type as application/x-lzip. 
The IANA Time Zone Database[3] is distributed in lzip format (and the IANA 
server identifies the tar.lz files as application/x-lzip).
[3] http://www.iana.org/time-zones

At least one application (GNU wget) has implemented 'lzip' as a content 
coding for http. In fact the maintainers of wget suggested me to register 
the type.

Thank you in advance,
Antonio Diaz.


Your Full Name:                 Antonio Diaz Diaz
Your E-mail:                    [e-mail]

4.1.  The 'application/lzip' Media Type

    The 'application/lzip' media type identifies a block of data that is
    compressed using lzip compression.  The data are a stream of bytes as
    described in this document.  IANA is asked to add the following entry
    to the standards tree of the "Media Types" registry:

    Type name:  application

    Subtype name:  lzip

    Required parameters:  N/A

    Optional parameters:  N/A

    Encoding considerations:  binary

    Security considerations:  See Section 5 of this RFC

    Interoperability considerations:  N/A

    Published specification:  this RFC

    Applications that use this media type:
       Any application where data size is an issue

    Fragment Identifier Considerations:  N/A

    Restrictions on Usage:  N/A

    Provisional Registrations:  N/A

    Additional information:

       Deprecated alias names for this type:  application/x-lzip

       Magic number(s):  First 4 bytes (0x4C, 0x5A, 0x49, 0x50)

       File extension(s):  lz, tlz (equivalent to tar.lz)

       Macintosh File Type Code(s):  N/A

       Object Identifier(s) or OID(s):  N/A

    Intended Usage:  COMMON

    Other Information & Comments:  See [LZIP]

    Author:  Antonio Diaz Diaz

    Change Controller:  IETF

4.2.  Content Encoding

    IANA is asked to add the following entry to the "HTTP Content Coding
    Registry" within the "Hypertext Transfer Protocol (HTTP) Parameters"
    registry:

    Name:  lzip

    Description:  A stream of bytes compressed using lzip compression

    Pointer to specification text:  this RFC

4.3.  Structured Syntax Suffix

    IANA is asked to add the following entry to the "Structured Syntax
    Suffix" registry:

    Name:  lzip

    +suffix:  +lzip

    References:  this RFC

    Encoding Considerations:  binary

    Interoperability Considerations:  N/A

    Fragment Identifier Considerations:
       The syntax and semantics of fragment identifiers specified for
       +lzip should be as specified for 'application/lzip'.
       (At publication of this document, there is no fragment
       identification syntax defined for 'application/lzip'.)

    Security Considerations:  See Section 5 of this RFC

    Contact:  See Author's Address of this RFC

    Author/Change Controller:  IETF

5.  Security Considerations

    Lzip is a compressed format.  Decompressing lzip data may expand them
    to a size more than 7000 times larger, risking an out-of-memory or
    out-of-disc-space condition.  Since both the gzip and lzip formats
    contain a single data stream, any steps already taken to avoid such
    attacks on application/gzip should also work on application/lzip.
    One possible measure, already implemented in some applications, is to
    set a limit to the decompressed size and stop the decompression or
    warn the user if the limit is surpassed.

    This media type does not employ any kind of "active content", but it
    can be used to compress any other media type (for example
    application/postscript) which could then be interpreted by the
    application.

    A lzip stream does not store any metadata.  Any non-lzip data
    appended to the end of the stream is easily detected, and an error
    can be signaled.  It is not apparent how this media type could be
    used to help violate a recipient's privacy.

    The lzip media type does not need itself any external security
    mechanisms.  But again, it can be used to compress other media types
    requiring them (for example a media type defined for storage of
    sensitive medical information).

    Because of the nature of the decoding algorithm used by lzip, it is
    easy to protect the decoder from invalid memory accesses caused by
    corruption in the input data (intentional or not).  Size limits need
    to be checked at just one place in the decompressor (the decoding of
    rep0) to prevent buffer overflows.  This inherent safety has been
    extensively tested in the reference implementation.

    The 'data size' field in the lzip trailer can be faked to be smaller
    than the actual decompressed data in an attempt to trigger a buffer
    overflow.  This is not a problem for most lzip decompressors
    (including the reference implementation) because they use 'data size'
    only to verify the size of the data produced, as an error detection
    measure.  However, any application that tries to decompress a whole
    member in memory must not trust 'data size' and must always avoid
    decompressing beyond the end of the buffer because, even if 'data
    size' is correct, decompressing corrupt data may produce more
    decompressed data than expected, and may cause a buffer overflow.

6.1.  Normative References

    [LZIP]     Diaz, A., "Lzip", <http://www.nongnu.org/lzip/lzip.html>.