mime-types-data 3.2024.1105 → 3.2026.0127

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,166 @@
+# Contributor Covenant 3.0 Code of Conduct
+
+## Our Pledge
+
+We pledge to make our community welcoming, safe, and equitable for all.
+
+We are committed to fostering an environment that respects and promotes the
+dignity, rights, and contributions of all individuals, regardless of
+characteristics including race, ethnicity, caste, color, age, physical
+characteristics, neurodiversity, disability, sex or gender, gender identity or
+expression, sexual orientation, language, philosophy or religion, national or
+social origin, socio-economic position, level of education, or other status. The
+same privileges of participation are extended to everyone who participates in
+good faith and in accordance with this Covenant.
+
+## Encouraged Behaviors
+
+While acknowledging differences in social norms, we all strive to meet our
+community's expectations for positive behavior. We also understand that our
+words and actions may be interpreted differently than we intend based on
+culture, background, or native language.
+
+With these considerations in mind, we agree to behave mindfully toward each
+other and act in ways that center our shared values, including:
+
+1. Respecting the **purpose of our community**, our activities, and our ways of
+   gathering.
+2. Engaging **kindly and honestly** with others.
+3. Respecting **different viewpoints** and experiences.
+4. **Taking responsibility** for our actions and contributions.
+5. Gracefully giving and accepting **constructive feedback**.
+6. Committing to **repairing harm** when it occurs.
+7. Behaving in other ways that promote and sustain the **well-being of our
+   community**.
+
+## Restricted Behaviors
+
+We agree to restrict the following behaviors in our community. Instances,
+threats, and promotion of these behaviors are violations of this Code of
+Conduct.
+
+1. **Harassment.** Violating explicitly expressed boundaries or engaging in
+   unnecessary personal attention after any clear request to stop.
+2. **Character attacks.** Making insulting, demeaning, or pejorative comments
+   directed at a community member or group of people.
+3. **Stereotyping or discrimination.** Characterizing anyone’s personality or
+   behavior on the basis of immutable identities or traits.
+4. **Sexualization.** Behaving in a way that would generally be considered
+   inappropriately intimate in the context or purpose of the community.
+5. **Violating confidentiality**. Sharing or acting on someone's personal or
+   private information without their permission.
+6. **Endangerment.** Causing, encouraging, or threatening violence or other harm
+   toward any person or group.
+7. Behaving in other ways that **threaten the well-being** of our community.
+
+### Other Restrictions
+
+1. **Misleading identity.** Impersonating someone else for any reason, or
+   pretending to be someone else to evade enforcement actions.
+2. **Failing to credit sources.** Not properly crediting the sources of content
+   you contribute.
+3. **Promotional materials**. Sharing marketing or other commercial content in a
+   way that is outside the norms of the community.
+4. **Irresponsible communication.** Failing to responsibly present content which
+   includes, links or describes any other restricted behaviors.
+
+## Reporting an Issue
+
+Tensions can occur between community members even when they are trying their
+best to collaborate. Not every conflict represents a code of conduct violation,
+and this Code of Conduct reinforces encouraged behaviors and norms that can help
+avoid conflicts and minimize harm.
+
+When an incident does occur, it is important to report it promptly. To report a
+possible violation, create a [private security advisory][advisory] — violations
+of this code of conduct are considered security vulnerabilities.
+
+Community Moderators take reports of violations seriously and will make every
+effort to respond in a timely manner. They will investigate all reports of code
+of conduct violations, reviewing messages, logs, and recordings, or interviewing
+witnesses and other participants. Community Moderators will keep investigation
+and enforcement actions as transparent as possible while prioritizing safety and
+confidentiality. In order to honor these values, enforcement actions are carried
+out in private with the involved parties, but communicating to the whole
+community may be part of a mutually agreed upon resolution.
+
+## Addressing and Repairing Harm
+
+If an investigation by the Community Moderators finds that this Code of Conduct
+has been violated, the following enforcement ladder may be used to determine how
+best to repair harm, based on the incident's impact on the individuals involved
+and the community as a whole. Depending on the severity of a violation, lower
+rungs on the ladder may be skipped.
+
+1. Warning
+   1. Event: A violation involving a single incident or series of incidents.
+   2. Consequence: A private, written warning from the Community Moderators.
+   3. Repair: Examples of repair include a private written apology,
+      acknowledgement of responsibility, and seeking clarification on
+      expectations.
+
+2. Temporarily Limited Activities
+   1. Event: A repeated incidence of a violation that previously resulted in a
+      warning, or the first incidence of a more serious violation.
+   2. Consequence: A private, written warning with a time-limited cooldown
+      period designed to underscore the seriousness of the situation and give
+      the community members involved time to process the incident. The cooldown
+      period may be limited to particular communication channels or interactions
+      with particular community members.
+   3. Repair: Examples of repair may include making an apology, using the
+      cooldown period to reflect on actions and impact, and being thoughtful
+      about re-entering community spaces after the period is over.
+
+3. Temporary Suspension
+   1. Event: A pattern of repeated violation which the Community Moderators have
+      tried to address with warnings, or a single serious violation.
+   2. Consequence: A private written warning with conditions for return from
+      suspension. In general, temporary suspensions give the person being
+      suspended time to reflect upon their behavior and possible corrective
+      actions.
+   3. Repair: Examples of repair include respecting the spirit of the
+      suspension, meeting the specified conditions for return, and being
+      thoughtful about how to reintegrate with the community when the suspension
+      is lifted.
+
+4. Permanent Ban
+   1. Event: A pattern of repeated code of conduct violations that other steps
+      on the ladder have failed to resolve, or a violation so serious that the
+      Community Moderators determine there is no way to keep the community safe
+      with this person as a member.
+   2. Consequence: Access to all community spaces, tools, and communication
+      channels is removed. In general, permanent bans should be rarely used,
+      should have strong reasoning behind them, and should only be resorted to
+      if working through other remedies has failed to change the behavior.
+   3. Repair: There is no possible repair in cases of this severity.
+
+This enforcement ladder is intended as a guideline. It does not limit the
+ability of Community Managers to use their discretion and judgment, in keeping
+with the best interests of our community.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public or other
+spaces. Examples of representing our community include using an official email
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 3.0,
+permanently available at <https://www.contributor-covenant.org/version/3/0/>.
+
+Contributor Covenant is stewarded by the Organization for Ethical Source and
+licensed under CC BY-SA 4.0. To view a copy of this license, visit
+<https://creativecommons.org/licenses/by-sa/4.0/>.
+
+For answers to common questions about Contributor Covenant, see the FAQ at
+<https://www.contributor-covenant.org/faq>. Translations are provided at
+<https://www.contributor-covenant.org/translations>. Additional enforcement and
+community guideline resources can be found at
+<https://www.contributor-covenant.org/resources>. The enforcement ladder was
+inspired by the work of [Mozilla’s code of conduct team][inclusion].
+
+[advisory]: https://github.com/mime-types/ruby-mime-types/security/advisories/new
+[inclusion]: https://github.com/mozilla/inclusion

data/CONTRIBUTING.md

@@ -0,0 +1,213 @@
+# Contributing
+
+Contribution to mime-types-data is encouraged in any form: a bug report, new
+MIME type definitions, or additional code to help manage the MIME types. New
+features should be proposed and discussed in an [issue][issues].
+
+Before contributing patches, please read the [Licence](./LICENCE.md).
+
+MIME::Types data is governed under the
+[Contributor Covenant Code of Conduct][cccoc].
+
+## Code Guidelines
+
+I have several guidelines to contributing code through pull requests:
+
+- I use code formatters, static analysis tools, and linting to ensure consistent
+  styles and formatting. There should be no warning output from test run
+  processes. I use [Standard Ruby][standardrb].
+
+- Proposed changes should be on a thoughtfully-named topic branch and organized
+  into logical commit chunks as appropriate.
+
+- Use [Conventional Commits][conventional] with my
+  [conventions](#commit-conventions).
+
+- Versions must not be updated in pull requests unless otherwise directed. This
+  means that you must not:
+
+  - Modify `VERSION` in `lib/mime/types/data.rb`. When your patch is accepted
+    and a release is made, the version will be updated at that point.
+
+  - Modify `mime-types-data.gemspec`; it is a generated file. (You _may_ use
+    `rake gemspec` to regenerate it if your change involves metadata related to
+    gem itself).
+
+  - Modify the `Gemfile`.
+
+- Type updates may only be performed on the YAML files in `types/`. This means
+  that no files may be modified in `data/`. Any changes to be captured here will
+  be automatically updated on the next release.
+
+- Documentation should be added or updated as appropriate for new or updated
+  functionality. The documentation is RDoc; mime-types-data does not use
+  extensions that may be present in alternative documentation generators.
+
+- All GitHub Actions checks marked as required must pass before a pull request
+  may be accepted and merged.
+
+- Add your name or GitHub handle to `CONTRIBUTORS.md` and a record in the
+  `CHANGELOG.md` as a separate commit from your main change. (Follow the style
+  in the `CHANGELOG.md` and provide a link to your PR.)
+
+- Include your DCO sign-off in each commit message (see [LICENCE](LICENCE.md)).
+
+Although mime-types-data was extracted from the [Ruby mime-types][rmt] gem and
+the support files are written in Ruby, the _target_ of mime-types-data is any
+implementation that wishes to use the data as a MIME types registry, so I am
+particularly interested in tools that will create a mime-types-data package for
+other languages.
+
+## Adding or Modifying MIME Types
+
+The Ruby mime-types gem loads its data from files encoded in the `data`
+directory in this gem by loading `mime-types-data` and reading
+MIME::Types::Data::PATH. These files are compiled files from the collection of
+data in the `types` directory.
+
+> [!WARNING]
+>
+> Pull requests that include changes to files in `data/` will require amendment
+> to revert these files.
+
+New or modified MIME types should be edited in the appropriate YAML file under
+`types`. The format is as shown below for the `application/xml` MIME type in
+`types/application.yml`.
+
+```yaml
+- !ruby/object:MIME::Type
+  content-type: application/xml
+  encoding: 8bit
+  extensions:
+    - xml
+    - xsl
+  references:
+    - IANA
+    - RFC3023
+  xrefs:
+    rfc:
+      - rfc3023
+  registered: true
+```
+
+There are other fields that can be added, matching the fields discussed in the
+documentation for MIME::Type. Pull requests for MIME types should just contain
+the changes to the YAML files for the new or modified MIME types; I will convert
+the YAML files to JSON prior to a new release. I would rather not have to verify
+that the JSON matches the YAML changes, which is why it is not necessary to run
+conversion for the pull request.
+
+If you are making a change for a private fork, use `rake convert:yaml:json` to
+convert the YAML to JSON and `rake convert:yaml:columnar` to convert it to the
+default columnar format.
+
+### Updating Types from the IANA or Apache Lists
+
+If you are maintaining a private fork and wish to update your copy of the MIME
+types registry used by this gem, you can do this with the rake tasks:
+
+```sh
+$ rake mime:iana
+$ rake mime:apache
+```
+
+#### A Note on Provisional Types
+
+Provisionally registered types from IANA are contained in the `types/*.yaml`
+files. Per IANA,
+
+> This registry, unlike some other provisional IANA registries, is only for
+> temporary use. Entries in this registry are either finalized and moved to the
+> main media types registry or are abandoned and deleted. Entries in this
+> registry are suitable for use for development and test purposes only.
+
+Provisional types are rewritten when updated, so pull requests to manually
+customize provisional types (such as with extensions) are considered lower
+priority. It is recommended that any updates required to the data be performed
+in your application if you require provisional types.
+
+## Commit Conventions
+
+MIMe::Types has adopted a variation of the Conventional Commits format for
+commit messages. The following types are permitted:
+
+| Type    | Purpose                                               |
+| ------- | ----------------------------------------------------- |
+| `feat`  | A new feature                                         |
+| `fix`   | A bug fix                                             |
+| `chore` | A code change that is neither a bug fix nor a feature |
+| `docs`  | Documentation updates                                 |
+| `deps`  | Dependency updates, including GitHub Actions.         |
+| `types` | Manually contributed MIME::Types                      |
+
+I encourage the use of [Tim Pope's][tpope-qcm] or [Chris Beam's][cbeams]
+guidelines on the writing of commit messages
+
+I require the use of [git][trailers1] [trailers][trailers2] for specific
+additional metadata and strongly encourage it for others. The conditionally
+required metadata trailers are:
+
+- `Breaking-Change`: if the change is a breaking change. **Do not** use the
+  shorthand form (`feat!(scope)`) or `BREAKING CHANGE`.
+
+- `Signed-off-by`: this is required for all developers except me, as outlined in
+  the [Licence](./LICENCE.md#developer-certificate-of-origin).
+
+- `Fixes` or `Resolves`: If a change fixes one or more open [issues][issues],
+  that issue must be included in the `Fixes` or `Resolves` trailer. Multiple
+  issues should be listed comma separated in the same trailer:
+  `Fixes: #1, #5, #7`, but _may_ appear in separate trailers. While both `Fixes`
+  and `Resolves` are synonyms, only _one_ should be used in a given commit or
+  pull request.
+
+- `Related to`: If a change does not fix an issue, those issue references should
+  be included in this trailer.
+
+## The Release Process
+
+The release process is completely automated, where upstream MIME types will be
+updated weekly (on Tuesdays) and be presented in a reviewable pull request. Once
+merged, the release will be automatically published to RubyGems.
+
+With the addition of [trusted publishing][tp], there should no longer be a need
+for manual releases outside of the update cycle. Pull requests merged between
+cycles will be released on the next cycle.
+
+If it becomes necessary to perform a manual release, IANA updates should be
+performed manually.
+
+1. Review any outstanding issues or pull requests to see if anything needs to be
+   addressed. This is necessary because there is no automated source for
+   extensions for the thousands of MIME entries. (Suggestions and/or pull
+   requests for same would be deeply appreciated.)
+2. `bundle install`
+3. Review the changes to make sure that the changes are sane. The IANA data
+   source changes from time to time, resulting in big changes or even a broken
+   step 4. (The most recent change was the addition of the `font/*` top-level
+   category.)
+4. Write up the changes in `CHANGELOG.md`. If any PRs have been merged, these
+   should be noted specifically and contributions should be added in
+   `Contributing.md`.
+5. Ensure that the `VERSION` in `lib/mime/types/data.rb` is updated with the
+   current date UTC.
+6. Run `rake gemspec` to ensure that `mime-types.gemspec` has been updated.
+7. Commit the changes and push to GitHub. The automated trusted publishing
+   workflow will pick up the changes.
+
+This list is based on issue [#18][issue-18].
+
+[cbeams]: https://cbea.ms/git-commit/
+[cccoc]: ./CODE_OF_CONDUCT.md
+[conventional]: https://www.conventionalcommits.org/en/v1.0.0/
+[dco]: licences/dco.txt
+[hoe]: https://github.com/seattlerb/hoe
+[issue-18]: https://github.com/mime-types/mime-types-data/issues/18
+[issues]: https://github.com/mime-types/mime-types-data/issues
+[minitest]: https://github.com/seattlerb/minitest
+[release-gem]: https://github.com/rubygems/release-gem
+[rmt]: https://github.com/mime-types/ruby-mime-types/
+[standardrb]: https://github.com/standardrb/standard
+[tp]: https://guides.rubygems.org/trusted-publishing/
+[tpope-qcm]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
+[trailers1]: https://git-scm.com/docs/git-interpret-trailers
+[trailers2]: https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---trailerlttokengtltvaluegt

data/CONTRIBUTORS.md

@@ -0,0 +1,54 @@
+# Contributors
+
+- Austin Ziegler created mime-types.
+
+Thanks to everyone else who has contributed to mime-types:
+
+- Aaron Patterson
+- Aggelos Avgerinos
+- Alessio Parma
+- Alex Balhatchet
+- Andre Pankratz
+- Andrey Eremin
+- Andy Brody
+- Arnaud Meuret
+- Bradley Meck
+- Brandon Galbraith
+- Chris Gat
+- Chris Salzberg
+- David Genord
+- Eric Marden
+- Garret Alfert
+- Godfrey Chan
+- Greg Brockman
+- Hans de Graaff
+- Henrik Hodne
+- Jeremy Evans
+- John Gardner
+- Jon Sneyers
+- Jonas Petersen
+- Juanito Fatas
+- Keerthi Siva
+- Ken Ip
+- Łukasz Śliwa
+- Lucia
+- Mark Young
+- Martin d'Allens
+- Mauricio Linhares
+- Mohammed Gad
+- Myk Klemme
+- nycvotes-dev
+- Postmodern
+- Richard Hirner
+- Richard Hurt
+- Richard Schneeman
+- Robert Buchberger
+- Samuel Giddins
+- Samuel Williams
+- Sergio Baptista
+- Shane Eskritt
+- Tao Guo
+- Thomas Leese
+- Tibor Szolár
+- Todd Carrico
+- Yoran Brondsema

data/{Licence.md → LICENCE.md}

@@ -1,6 +1,6 @@
 ## Licence
 
-- Copyright 2003–2024 Austin Ziegler and other contributors.
+- Copyright 2003–2025 Austin Ziegler and other contributors.
 
 The software in this repository is made available under the MIT license.
 

data/Manifest.txt

@@ -1,7 +1,8 @@
-Code-of-Conduct.md
-Contributing.md
-History.md
-Licence.md
+CHANGELOG.md
+CODE_OF_CONDUCT.md
+CONTRIBUTING.md
+CONTRIBUTORS.md
+LICENCE.md
 Manifest.txt
 README.md
 Rakefile
@@ -15,22 +16,9 @@ data/mime.encoding.column
 data/mime.flags.column
 data/mime.friendly.column
 data/mime.pext.column
+data/mime.spri.column
 data/mime.use_instead.column
 data/mime.xrefs.column
 lib/mime-types-data.rb
 lib/mime/types/data.rb
-types/application.yaml
-types/audio.yaml
-types/chemical.yaml
-types/conference.yaml
-types/drawing.yaml
-types/example.yaml
-types/font.yaml
-types/haptics.yaml
-types/image.yaml
-types/message.yaml
-types/model.yaml
-types/multipart.yaml
-types/text.yaml
-types/video.yaml
-types/world.yaml
+licences/dco.txt

data/README.md

@@ -1,8 +1,10 @@
 # mime-types-data
 
 - home :: https://github.com/mime-types/mime-types-data/
-- code :: https://github.com/mime-types/mime-types-data/
 - issues :: https://github.com/mime-types/mime-types-data/issues
+- code :: https://github.com/mime-types/mime-types-data/
+- changelog ::
+  https://github.com/mime-types/mime-types-data/blob/main/CHANGELOG.md
 
 ## Description
 
@@ -13,33 +15,34 @@ extensions to look up the likely MIME type definitions.
 
 ### About MIME Media Types
 
-MIME media types are used in MIME-compliant communications, as in e-mail or
-HTTP traffic, to indicate the type of content which is transmitted. The
-registry provided in mime-types-data contains detailed information about MIME
-entities. There are many types defined by RFCs and vendors, so the list is long
-but invariably; don't hesitate to offer additional type definitions for
+MIME media types are used in MIME-compliant communications, as in e-mail or HTTP
+traffic, to indicate the type of content which is transmitted. The registry
+provided in mime-types-data contains detailed information about MIME entities.
+There are many types defined by RFCs and vendors, so the list is long but
+invariably; don't hesitate to offer additional type definitions for
 consideration. MIME type definitions found in mime-types are from RFCs, W3C
-recommendations, the [IANA Media Types registry][registry], and user
+recommendations, the [IANA Media Types registry][registry], the
+[Apache httpd registry][httpd], the [Apache Tika media registry][tika] and user
 contributions. It conforms to RFCs 2045 and 2231.
 
 ### Data Formats Supported in this Registry
 
 This registry contains the MIME media types in four formats:
 
-- A YAML format matching the Ruby mime-types library objects (MIME::Type).
-  This is the primary user-editable format for developers. It is _not_
-  shipped with the gem due to size considerations.
+- A YAML format matching the Ruby mime-types library objects (MIME::Type). This
+  is the primary user-editable format for developers. It is _not_ shipped with
+  the gem due to size considerations.
 - A JSON format converted from the YAML format. Prior to Ruby mime-types 3.0,
   this was the main consumption format and is still recommended for any
-  implementation that does not wish to implement the columnar format, which
-  has a significant implementation effort cost.
-- An encoded text format splitting the data for each MIME type across
-  multiple files. This columnar data format reduces the minimal data load
-  substantially, resulting in a performance improvement at the cost of more
-  complex code for loading the data on-demand. This is the default format for
-  Ruby mime-types 3.0.
-- An encoded text format for use with [`mini_mime`][] (as of 3.2021.1108). This
-  can be enabled with:
+  implementation that does not wish to implement the columnar format, which has
+  a significant implementation effort cost.
+- An encoded text format splitting the data for each MIME type across multiple
+  files. This columnar data format reduces the minimal data load substantially,
+  resulting in a performance improvement at the cost of more complex code for
+  loading the data on-demand. This is the default format for Ruby mime-types
+  3.0.
+- An encoded text format for use with [`mini_mime`][minimime]. This can be
+  enabled with:
 
   ```ruby
   MiniMime::Configuration.ext_db_path =
@@ -50,24 +53,29 @@ This registry contains the MIME media types in four formats:
 
 ## mime-types-data Modified Semantic Versioning
 
-mime-types-data uses a heavily modified [Semantic Versioning][] scheme to
-indicate that the data formats compatibility based on a `SCHEMA` version and
-the date of the data update: `SCHEMA.YEAR.MONTHDAY`.
+mime-types-data uses a [Semantic Versioning][semver] scheme heavily modified
+with [Calendar Versioning][calver] aspects to indicate that the data formats
+compatibility based on a `SCHEMA` version and the date of the data update:
+`SCHEMA.YEAR.MONTHDAY`.
 
 1. If an incompatible data format change is made to any of the supported
-   formts, `SCHEMA` will be incremented. The current `SCHEMA` is 3, supporting
-   the YAML, JSON, and columnar formats required for Ruby mime-types 3.0.
+   formats, `SCHEMA` will be incremented. The current `SCHEMA` is 3, supporting
+   the YAML, JSON, columnar, and mini-mime formats required for Ruby mime-types
+   3.0.
 
-2. When the data is updated, the `YEAR.MONTHDAY` combination will be updated.
-   An update on the last day of October 2015 would be written as `2015.1031`,
-   resulting in the full version of `3.2015.1031`.
+2. When the data is updated, the `YEAR.MONTHDAY` combination will be updated. An
+   update on the last day of October 2025 would be written as `2025.1031`,
+   resulting in the full version of `3.2025.1031`.
 
 3. If multiple versions of the data need to be released on the same day due to
-   error, there will be an additional `REVISION` field incremented on the end
-   of the version. Thus, if three revisions need to be published on October
-   31st, 2015, the last release would be `3.2015.1031.2` (remember that the
-   first release has an implied `0`.)
+   error, there will be an additional `REVISION` field incremented on the end of
+   the version. Thus, if three revisions need to be published on October 31st,
+   2015, the last release would be `3.2015.1031.2` (remember that the first
+   release has an implied `0`.)
 
-[registry]: https://www.iana.org/assignments/media-types/media-types.xhtml
-[semantic versioning]: http://semver.org/
-[`mini_mime`]: https://github.com/discourse/mini_mime
+[registry]: https://www.iana.org/assignments/media-types/media-types.xml
+[semver]: http://semver.org/
+[minimime]: https://github.com/discourse/mini_mime
+[httpd]: https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
+[tika]: https://github.com/apache/tika/blob/main/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml
+[calver]: https://calver.org