Hi, On Sat, Jul 31, 2021 at 2:10 AM Joel Hockey <joelhockey@xxxxxxxxxxxx> wrote: > Thanks Jehan, > > Debian will change this after their current release freeze. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991158 > > They have requested if gimp could register the mime type with iana? > Sure why not. Charles offered help if needed: plessy@xxxxxxxxxx > Definitely yes. I have started to fill the form ( https://www.iana.org/form/media-types), but they ask for a lot of information I'm not sure of (even looking at the RFC they link as references). So I would appreciate some feedback. Charles' email has been added in recipients of this thread. Attached is my first try at filling the form. Would anyone mind review and tell me if I misunderstood anything? I left a lot of notes here and there for reviewers because there were many stuff I was not sure of. Thanks! Jehan > On Sat, Jul 17, 2021 at 6:54 AM Jehan Pagès <jehan.marmottard@xxxxxxxxx> > wrote: > >> Hi! >> >> On Fri, Jul 16, 2021 at 9:49 PM Joel Hockey via gimp-developer-list < >> gimp-developer-list@xxxxxxxxx> wrote: >> >>> When I use GIMP in Chrome OS Linux environment, it does not automatically >>> associate *.xcf files with GIMP since there is a mismatch between the >>> /usr/share/applications/gimp.desktop file which registers to handle mime >>> types including image/x-xcf and the system /etc/mime.types file which >>> associates extension xcf with mime type application/x-xcf. >>> >>> I'm one of the developers on Chrome OS. I believe most linux desktops >>> are >>> using the xdg shared-mime-info database rather than /etc/mime.types, but >>> we >>> haven't yet implemented that. >>> >>> https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/47ca1dc530d356336ffe1b7a45dc5dc8f0e528ca/data/freedesktop.org.xml.in#L5568 >>> >>> I am planning to request debian media-types package to update their >>> /etc/mime.types to use image/x-xcf rather than application/x-xcf which >>> will >>> fix things for me if they are happy to change. >>> >> >> Indeed I think that image/x-xcf is the right one. I didn't even know of >> the application/x-xcf ! >> >> Does anyone know the history why these are different, or would there be >>> any >>> issue if /etc/mime.types did change? >>> >> >> Sorry I don't. If you find the source of this duplicate, please do not >> hesitate to come and tell us later. 🙂 >> >> Jehan >> >> >>> Thanks, >>> Joel >>> _______________________________________________ >>> gimp-developer-list mailing list >>> List address: gimp-developer-list@xxxxxxxxx >>> List membership: >>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >>> List archives: https://mail.gnome.org/archives/gimp-developer-list >>> >> >> >> -- >> ZeMarmot open animation film >> http://film.zemarmot.net >> Liberapay: https://liberapay.com/ZeMarmot/ >> Patreon: https://patreon.com/zemarmot >> Tipeee: https://www.tipeee.com/zemarmot >> > -- ZeMarmot open animation film http://film.zemarmot.net Liberapay: https://liberapay.com/ZeMarmot/ Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot
# 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.
_______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
