Category Not Saving to XMP Subject for GIFs

[peter.avast]

Hello, before saying anything, I would like to apologize in advance for any basic misconceptions or asking-things-you-can-find-out-easily-through-google. I am very new to XnView and image organizing/editing in general, so any help would be greatly appreciated!

So I use categories to, well, categorize photos, and because I want to keep the category information on the image file itself, I use the "Export DB Category to XMP Subject and IPTC Keyword" option.
The trouble is, I want to do the same for GIF files. I understand that GIF file format does not support ITPC metadata, but I remember reading somewhere that it does support XMP (not entirely sure what that means though).
For jpegs and pngs, the category information gets embedded into the file very well. However, for GIFs, it doesn't. For ITPC, as aforementioned, it's obvious it doesn't, but shouldn't there be a field for XMP Subject to match the DB category?

So to summarize, why doesn't DB category save into XMP subject for GIF images?

Please do correct any misunderstandings or mistakes. Thank you!

[xnview]

i'm not sure that GIF support XMP

[XnTriq]

In a GIF 89a file, an XMP packet is in an Application Extension (see Figure 2). Its Application Identifier is 'XMP Data' and the Application Authenticator is 'XMP'. The Application Data consists of the XMP packet, which must be encoded as UTF-8, followed by a 258-byte “magic” trailer, whose values are 0x01, 0xFF, 0xFE, 0xFD .... 0x03, 0x02, 0x01, 0x00, 0x00. The final byte is the Block Terminator.

• NOTE The "Application Extension" mechanism used for XMP was added in the 89a revision of GIF; the GIF 87a standard does not support it. XMP should not be placed into GIF 87a files.

The XMP must be UTF-8-encoded, for the following reasons. GIF actually treats the Application Data as a series of GIF data sub-blocks. The first byte of each sub-block is the length of the sub-block’s content, not counting the first byte itself. To consume the Application Data, a length byte is read. If it is non-zero, that many bytes of data are read, followed by the next length byte. The series ends when a zero-length byte is encountered.

When XMP is encoded as UTF-8, there are no zero bytes in the XMP packet. Therefore, software that is unaware of XMP views packet data bytes as sub-block lengths, and follows them through the packet accordingly, eventually arriving somewhere in the magic trailer. The trailer is arranged so whichever byte is encountered there will cause a skip to the Block Terminator at the end.

Figure 2 shows how XMP is embedded in the GIF file format: