# Your Full Name

Jehan Pagès

# Type Name

image

# Subtype Name

Standard Tree (no prefix)
xcf

**Note**: I wonder if XCF should actually be considered *vendor* tree
(even if there is no vendor per-se and no organism behind).
Our XCF format is clearly tied to GIMP and will evolve with it. Wouldn't it
be somehow the definition of a vendor format?

# Required Parameters

**Note**: no idea how to fill these. They give RFC 2046 §1, and RFC 6838
§4.3 as references but these sections discuss format and such, but not
really what these parameters are (I have not read the full RFCs).

# Optional Parameters

**Note**: same as above.

# Encoding Considerations

binary

# Security Considerations

No active content or action of any kind is contained in an XCF file.

XCF files may contain any possible metadata (Exif, XMP, IPTC, and a
generic comment), which are usually found in all common image formats.
This may reveal very sensitive information on author's name, address,
position, movements, owned material…

Compression is used to store image tile data. The 2 possible compression
formats so far are RLE and zlib compression. Image data can be enormous
once uncompressed, especially for work images, which can contains dozens
of layers. Since the format compresses the data per tile blocks of width
and height of up to 64 pixels, the reading software will uncompress
progressively, hence with the opportunity to quit at any time. This
should be enough to avoid any memory-consuming attacks.

The XCF format is an image work format, which may contain source images,
references and sensitive metadata. It is up to the users to handle its
data and metadata with copyright and privacy concerns, according to
local laws.

**Note**: I tried to fill in with some text I felt relevant after
reading RFC 6838 §4.6, but I'm not sure if maybe they are looking for
specific.

# Data Interoperability Considerations

XCF is a living format which evolves with the GNU Image Manipulation
Program. Deep care is taken into interoperability, allowing this program
(and any other wishing to) to load any past XCF file exactly with the
rendering which was intended at the time. The file version is included
the header (current XCF version for stable GIMP 2.10.x releases goes up
to XCF 13) and every changes of the format results in updates to the
documentation of the format.

Care is taken never to break interoperability while still evolving, by
always provide proper documentation of the changes. This way, a reading
client may not be able to read new versions of the format (if it didn't
update recently) but it should be able to read all old versions up to
its implementation version.

# Published specification

https://gitlab.gnome.org/GNOME/gimp/-/raw/master/devel-docs/xcf.txt

**Note**: RFC 6838 §4.10 says: "Media types registered in the standards
tree by the IETF itself MUST be published as RFCs.  RFC publication of
vendor and personal media type registrations is allowed but not
required."
I guess it seals the fact that the format has to be registered as
"vendor", right?

# Application Usage

The main application with a full support by nature is the GIMP Image
Manipulation Program. It is able to read any XCF, from version 0 to the
latest versions, exactly as initially intended.

Several other applications can read or write XCF at various levels of
support. Since the list would be too long and possibly not even
complete, I will refer to the "Software Support" list in Wikipedia
listing about 20 third-party programs: https://en.wikipedia.org/wiki/XCF_(file_format)

# Fragment Identifier Considerations

**Note:** I don't think it applies to XCF, right?

# Restrictions on Usage

XCF is not expected to be widely implemented.

It is a good idea to have support in preview renderers, allowing
browsing in the system's file browsing much easier.

An image viewer able to read XCF is of course an appreciated feature for
image workers, though it should not be considered absolutely needed. XCF
files are work images rather than finale render images.

Other raster image editors able to at least import XCF files would be of
great use for projects interchange, and even more if it can also export
XCF files.

Less specialized applications are not really expected to have support so
it is perfectly reasonable not to consider XCF a "common" format
expected to be widely implemented

# Provisional Registrations

**Note:** not appliable?

# Additional Information

## Deprecated alias names for this type

???

## Magic number(s)

"9,gimp xcf "

## File extension(s)

xcf

**Note**: GIMP can actually also save .xcfgz, .xcfbz2 and .xcfxz files.
As could be guessed from the name, these are actually just a .xcf
compressed in .gz, .bz2 and .xz respectively.
Since this is a very old usage of GIMP, `mimetype` detects these files
as "image/x-compressed-xcf" (except the .xz one which is more recent and
appeared in 2018).
Should we also register these? As separate mimetypes?

## Macintosh File Type Code(s)

??

## Object Identifier(s) or OID(s) — See RFC 1494

??

# Intended Usage

Common

**Note**: should we add text in the field? It seems obvious enough with
all previous comments I made.

# Other Information & Comments

…

# Contact Person

## Contact Name

Jehan

## Author/Change Controller (for standards tree registrations, this is typically the standards body)

GIMP team

**Note**: is it what the Author Controller is here? Reading the RFC,
it's not clear to me.