Zstd: IANA Media Type Registration

[ib]

Are there plans to register a media type for zstd and zstd compressed tar archives?

[ib]

Are there plans to register a media type for zstd and zstd compressed tar archives?

At least entries in shared-mime-info (application/x-zstd, application/x-zstd-compressed-tar?) would be desirable.

[Cyan4973]

Media type request is ongoing

[ib]

Media type request is ongoing

IANA or shared-mime-info?

[ib]

Can you already tell which types are going to be requested?

[Cyan4973]

Correction : the media type request has been delayed, it is now planned to be resumed alongside another ongoing normalization effort.

[ib]

Please keep us informed.

[Cyan4973]

The media type being requested is "to be used when transporting zstd-compressed via Multipurpose Internet Mail Extensions (MIME) ".

I'm not sure to understand the difference between IANA and MIME for this request.

[ib]

I'm not sure to understand you.

A Media Type can either be officially requested at IANA (which shall be requested for addition to shared-mime-info then) or - unregistered - directly at shared-mime-info. At least application/x-zstd and application/x-zstd-compressed-tar would be desirable there. (See the commits for lz4 and tar.lz4.)

[Cyan4973]

I believe it's an official request, so it should be IANA.

[ib]

Is there any news?

[Cyan4973]

Nothing special.
It's progressing.
The major task here is redacting the content of the RFC, to which the Media Type request will be attached.

[Cyan4973]

Process application for application/zstd Media Type is formally started :
https://tools.ietf.org/id/draft-kucherawy-dispatch-zstd-00.html

[Cyan4973]

https://www.ietf.org/id/draft-kucherawy-dispatch-zstd-01.txt

[ib]

I have no idea how long such an application can take, but it seems there is still no registration, isn't it?

[Cyan4973]

cc @mskucherawy

[mskucherawy]

There is no registration yet, correct. It's part of the document @Cyan4973 cited above. When that document is approved for publication by the IETF, the registrations will be made automatically.

@Cyan4973: IANA is the administrative body that maintains the registries. MIME is a protocol for encoding arbitrary content type in a content body. IANA maintains the registry of known media types, to which the MIME specification refers, and the MIME specification defines the rules by which the registry is modified. We're following the same path as other top-level application media types, which requires a standards action by the IETF.

Use of a media type with an "x-" prefix is discouraged by BCP178 (RFC6648), so we're not pursuing that here.

[yososs]

When reading README.md, the extension of Zstd can be read as ".zst", but when looking at draft it is ".zstd". Which will you adopt?

Also, please decide what to do with the extension when combined with tar.

long version => .tar.zstd or .tar.zst ?
short version => .t?

[Cyan4973]

That's a good point @yososs .
I guess it's a typo, as we have been supporting .zst only so far.
The 3 letters extension has been preferred to remain compatible with potential filesystems limited to 3 characters filename extension.
It wouldn't be hard for zstd cli to support both extensions,
but the IETF document is more a guidance for the larger ecosystem, and we fear that introducing 2 extensions for all programs to support would be confusing.

please decide what to do with the extension when combined with tar.

Currently it's .tar.zst .
There is no short version defined.

[ib]

I guess it's a typo, as we have been supporting .zst only so far.

I suppose the draft should probably be corrected then, because when it becomes effective (if ever) zstd is the official extension which will most certainly cause confusion.

[yososs]

Thank you for your quick reply.

In CLI, we can operate with only long version, but if there is no short version there will be problems with GUI application. I think someone needs to decide on a short version.

Specifically, when using the common file save dialog in the GUI application of macOS, when using the long version extension (*. tar.zst), there is a problem that does not work properly.

Referring to the existing archive file naming rules, tar + zst looks good at tzs.

• .tar + .gz => .tgz
• .tar + .bz2 => .tbz
• .tar + .xz => .txz
• .tar + .lzo => .tzo
• .tar + .lz4 => .tlz
• .tar + .sz => .tsz (Tar + Snappy)

[Cyan4973]

I'm totally fine with your suggestion @yososs, but I wonder who has the authority to decide a short equivalent extension for .tar.zst ?
Maybe the tar project directly ?

[yososs]

I am a developer of archiver applications that support many codecs.
If this rule determines the extension rule, it will be adopted as my GUI application first.

In the case of UNIX CLI, there is a way to connect with a pipe,
Users can use Tar's implementation without waiting for Zstandard to be integrated.
Tar developers will not decide extensions unless they plan to integrate.

[Cyan4973]

https://datatracker.ietf.org/doc/draft-kucherawy-dispatch-zstd/ballot/

[Cyan4973]

https://www.iana.org/assignments/media-types/application/zstd

[Cyan4973]

Zstandard is now published as __RFC8478__ .

It is also a fully registered IANA media type.

[stokito]

FYI: the file utility returns incorrect MIME type application/x-zstd. I created a ticket https://bugs.astron.com/view.php?id=103 so hope it will be fixed soon.

application/x-zstd-compressed-tar is used internally in KDE Ark, MATE Engrampa, GNOME File Roller, XArchiver for *.tar.zst and *.tzst files.