Ecosystem

Media types

The media types used by the ICF ecosystem. Both are proposed: not yet registered with IANA. Registration follows the two-step plan below; this page will state the registered status explicitly when it changes.

application/icf

StatusProposed (not IANA-registered)
Type / subtypeapplication/icf
File extension.icf
Character encodingUTF-8. A single leading byte-order mark is tolerated and ignored.
ParametersNone.
Fragment identifiersNot defined.
SpecificationICF Language Specification v1.1.1

application/icx

StatusProposed (not IANA-registered)
Type / subtypeapplication/icx
File extension.icx
Character encodingUTF-8.
ParametersNone.
Fragment identifiersNot defined.
SpecificationICX Index Specification v1.2
Relationship to ICFAn ICX file is a derived, optional companion index for one ICF file. It uses ICF syntax (@kind icx) and can always be regenerated from its source; the ICF document remains authoritative.

Registration plan

Unfaceted names in the IANA standards tree (application/icf, application/icx) require registration through the IETF or another recognized standards organization (RFC 6838 §3.1) — not available to an independent publisher directly. The plan is therefore two-step:

  1. Now — vendor tree. Registration templates for application/vnd.icformat.icf and application/vnd.icformat.icx are drafted and ready to submit: see the registration directory of the spec archive. Any producer of a format may register in the vendor tree; review by the IANA media-types reviewer typically takes a few weeks.
  2. Later — standards tree. The unfaceted application/icf remains the long-term goal via an IETF Informational RFC (the route application/yaml took in RFC 9512). A vendor-tree registration does not block this.

Until a registration is approved, the names on this page are proposals; software should treat .icf/.icx file extensions and the @kind directive as the practical identification mechanisms.

Security considerations

ICF and ICX documents are plain-text structured data. They contain no active or executable content, no external references that a processor is required to fetch, and no compression. The primary risks are those of any untrusted structured input: resource exhaustion from very large documents, very long lines, deeply indented structures, or very large numbers of records or index entries. Implementations should treat incoming documents as untrusted, may impose configurable resource limits, and should apply standard care to Unicode text (no normalization is performed by the format itself). Checksum directives (@checksum, @sourcechecksum) support integrity verification but are not an authentication mechanism.

Interoperability considerations

The normative definition of both formats is the published specification, not any implementation. Three official zero-dependency implementations (Java, Python, JavaScript) maintain behavioral parity, including identical diagnostic codes. ICF documents declare their language version with the @version directive; readers apply the compatibility rules of specification §74 to newer minor versions.