Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IANA Media Type Registration #767

Closed
ib opened this issue Jul 18, 2017 · 26 comments

Comments

@ib
Copy link

commented Jul 18, 2017

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

@Cyan4973 Cyan4973 added the question label Jul 18, 2017

@ib

This comment has been minimized.

Copy link
Author

commented Jul 18, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jul 18, 2017

Media type request is ongoing

@ib

This comment has been minimized.

Copy link
Author

commented Jul 19, 2017

Media type request is ongoing

IANA or shared-mime-info?

@ib

This comment has been minimized.

Copy link
Author

commented Jul 28, 2017

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

@Cyan4973

This comment has been minimized.

Copy link
Contributor

commented Aug 15, 2017

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

@ib

This comment has been minimized.

Copy link
Author

commented Aug 15, 2017

Please keep us informed.

@Cyan4973

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2017

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

@ib

This comment has been minimized.

Copy link
Author

commented Sep 9, 2017

Is there any news?

@Cyan4973

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 27, 2017

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

@Cyan4973

This comment has been minimized.

@ib

This comment has been minimized.

Copy link
Author

commented Mar 9, 2018

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

@Cyan4973

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2018

@mskucherawy

This comment has been minimized.

Copy link

commented Mar 9, 2018

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

This comment has been minimized.

Copy link

commented Jun 7, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2018

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

This comment has been minimized.

Copy link
Author

commented Jun 7, 2018

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

This comment has been minimized.

Copy link

commented Jun 8, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2018

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

This comment has been minimized.

Copy link

commented Jun 9, 2018

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

This comment has been minimized.

@Cyan4973

This comment has been minimized.

Copy link
Contributor

commented Jul 18, 2018

@Cyan4973

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2018

Zstandard is now published as RFC8478 .

It is also a fully registered IANA media type.

@Cyan4973 Cyan4973 closed this Oct 3, 2018

@stokito

This comment has been minimized.

Copy link

commented Sep 1, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.