[media-types] [IANA #1444004] application/prs.bwtc32ke y registration request

Hi Murray,

Sending a reminder for this request from February 12th (PST).

thanks,
Amanda

On Fri Feb 13 00:53:45 2026, amanda.baber wrote:
> Hi Murray,
> 
> Could you review this one by February 26th?
> 
> I've pasted in some follow-up notes from the requester after the
> author/change controller field.
> 
> thanks,
> Amanda
> 
> =====
> 
> Name: Raja Fjords
> 
> Email: [email protected]
> 
> Media type name: application
> 
> Media subtype name: prs.bwtc32key
> 
> Required parameters: Essentially, as a text-based (albeit Unicode)
> format, though canonically UTF-16BE, it CAN have multiple byte
> representations given how varied Unicode UTFs are (even UTF-9 and
> Lotus Multi-Byte Character Set, which are not exactly mainstream
> UTFs), so it would be prudent to involve charset. The encoder has
> Compression Level default as 9, but mainly using HTML's ability to
> have a default. For the NodeJS port it is advised to specify a level
> and a password is needed. The Compression Level can be any value that
> can result in an integer when multiplied by 100,000, though negatives
> and 0 are unwise, as are extremely high values well past 9. Basically,
> the section in the BWTC part (so pre-Base32768 and pre-AES256-CTR) has
> a finite length for its storage of the Compression Level.
> 
> Optional parameters: The password, like a non-default Compression
> Level, is optional in the browser version. The default value in the
> box is "Enter a password here before uploading." (even though the code
> is entirely client-side), and it is used for unencrypted files. Also
> it uses SHA256 so a blank password will also work as an unencrypted
> one (though not to the 2019 version, and same for using whitespace).
> The password is UTF-8. You can specify a MIMEtype for what the browser
> will save when decoding, but it defaults to "application/octet-
> stream", and the filename for that is "output.bin"
> Downloading a .B3K file from encoded output is done as a file with
> "myFile.B3K" as its name, and it DOES try to tell browsers it is a
> text document (because it IS, it's just UTF-16BE).
> 
> Encoding considerations: binary
> 
> This format is special in that it IS 8-bit text (specifically UTF-
> 16BE, at least that is the INTENDED form of Unicode) used to store
> AES256-CTR encrypted BWT-compressed data as archaic (Hangul+Hanja)
> Korean characters with 93.75% efficiency. None of its components
> already exist in the list of MIME types.
> 
> Security considerations: The AES256-CTR implementation used is from
> aes-js by ricmoo / Richard Moore on Github, because it was the only
> one that outputted Uint8Arrays correctly for combining with Tinygma's
> Base32768 code (the only one that runs in a browser) and trying to do
> AES256-CTR correctly via assigning the counter value to the current
> time in JavaScript had the issue of making decryption not work. Also I
> had to use direct HTML getElementById calls for the encryption key and
> compression level values due to them not registering when changed
> unless I did this. The encryption key is generated from a UTF-8
> password of any length via non-HMAC SHA256. The decompression buffer
> maximum length is set to JavaScript's "undefined" as if it were left
> blank, because I didn't want to impose an artificial size limit for
> files. The JavaScript's newest feature is Blob in the HTML version,
> the NodeJS version of course works differently, and it requires
> dependencies not in the HTML5 version and of
> note is that the MooTools in the HTML5 version makes the UI not work
> at all if removed. There's no Adobe Flash in the program but MooTools
> of the era I did the UI has code for it that is just dead code and
> nothing more and it isn't in the NodeJS version. I'm disclosing all of
> these just to make sure there are no nasty surprises.
> 
> In regards to whether this media type has active or executable
> content, it does not. It's a file compressor that takes in one file at
> a time (unless TAR is used) and doesn't store its name or attributes.
> 
> To the best of my understanding this program doesn't need privacy or
> integrity services, in spite of the SHA-256 used being without HMAC
> (the original SHA256 code used didn't do it or UTF-8, and to fix the
> Compression Level and the encryption I changed it to one that does
> both but I had to not break old files via HMAC. Oh and I tried salts
> and they weren't usable. I had wanted to use LZMA and PBKDF2 but
> neither library was usable. This file format's simplicity shows (it
> even allows non-integer and beyond-9 compression levels but they have
> quirks) given it isn't quite AES-GCM. But because of no HMAC integrity
> isn't involved but this program is itself an encryption program
> If you use this, setting a long Unicode password, and doing multiple
> runs to increment the counter (neither Date() or Math.random functions
> work) it is at least able to mitigate some of the bugs and of note is
> that in terms of compression the program uses what is effectively BZip
> 1 but without the bugged first RLE (which can turn what should be size
> reduction into size inflation) and with a Fenwick Tree range coder
> instead of Arithmetic coder use, and it uses math a bit better.
> 
> Interoperability considerations: This program is cross-platform but it
> does require Unicode support and favors UTF-16BE. The characters used
> are well behaved. I've sent it and developed and tested it across all
> platforms in modern use.
> 
> Published specification: In this case, fileformats.archiveteam.org's
> wiki article on it fits, and the program is a single HTML file so on a
> place like http://b3k.me/b3k.htm or http://stgiga.3b1.org/b3k.htm or
> https://b3k.sourceforge.io it is available to peruse, unminified and
> unobfuscated.
> 
> Applications which use this media: File compression programs are the
> main use but I can also see it being used as a chunk format in other
> new formats, and I *have* done this in my own testing, like using it
> to make a hypothetical WOFF3.
> 
> Fragment identifier considerations: If somehow you treat it as a text
> format, ideally a fragment identifier (like "+b3k") should be used to
> clue environments in that it is a text file containing data.
> 
> Restrictions on usage: It may not be ideal for governmental usage
> given how its implementation is, but I have no qualms about it. The
> program is GPL2.
> 
> Provisional registration? (standards tree only): No
> 
> Additional information:
> 
> 1. Deprecated alias names for this type: N/A with the exception of
> trying to omit prs. or using x prefixes, or none at all, or text
> rather than application. Originally the code was assigned
> application/octet-stream even though technically it is
> penta/hexadecets involved. "b3k" instead of "bwtc32key" was also
> considered but I thought better of it so people could search it
> better. File extension is canonically uppercase.
> 2. Magic number(s): 0:0xFEFF4D00, 4:"bwtc", 8:"nomo", 12:"dfsm",
> 16:"fenw", 20:0x4D01
> 3. File extension(s): .B3K
> 4. Macintosh file type code: ".B3K"
> 5. Object Identifiers: N/A given this format's hybrid nature making
> assigning one ambiguous.
> 
> General Comments: I self-documented the file type on the File Formats
> Wiki (by Archive Team) as well as my Github repository at
> https://github.com/stgiga/bwtc32key but the File Formats Wiki entry
> (which has changed URLs but is searchable on Google in part due to its
> distinct name) is most accurate but may or may not be perfect seeing
> as I may have missed it. I also have some information on it at
> https://stgiga.itch.io/bwtc32key where it is mirrored.This format is
> special in that it IS 8-bit text (specifically UTF-16BE) used to store
> AES256-CTR encrypted BWT-compressed data as archaic (Hangul+Hanja)
> Korean characters with 93.75% efficiency. None of its components
> already exist in the list of MIME types. The file extension is .B3K
> and this format's files have 0xFEFF4D00 as the file header and 0x4D01
> as the end marker. Inside the compression step there are the magic
> numbers of "bwtc" (assuming successful decoding with the correct key),
> and the block size divided by 100,000 followed by "
> nomo" (short for NoModel), and if the compression level is 5 or
> higher, the magic number "fenw" (referring to Fenwick Trees), but if
> less than 5, the magic number for this fast mode is "dfsm" (short for
> Deferred-Sum). These compression-step magic numbers are in ASCII. A
> successful decode has to go through all this.
> 
> Person to contact for further information:
> 
> 1. Name: Raja Fjords
> 2. Email: [email protected]
> 
> Intended usage: COMMON
> 
> File compression programs are the main use but I can also see it being
> used as a chunk format in other new formats. It is intended for
> general interchange. Do note that it may not be the best for
> governmental usage. As intended, the UTF is UTF-16BE, and the file
> extension is uppercase. I've not decided on what a tarball extension
> would be, though .tar.B3K is fine, but .tb3, .t3k, .b3t, .tbk, and
> other such extensions (in uppercase) were considered but are not
> unclaimed last I checked.
> 
> Author/Change controller: Raja Fjords
> 
> =====
> 
> Additional notes (possibly related to provisional message header "x-
> face," the only occurrence of that string in the registries; see
> https://www.iana.org/assignments/message-headers):
> 
> I want to tie up some loose ends with a friend's MIME header
> submission of X-Face, because in the time since, I found that 24-bit
> color is possible and was done in Japan in 2002. AND, this individual
> didn't actually define a MIMEtype for .xface/.face files (which are
> the headers shoved into a TXT. That said, X-Face IS a compressed image
> format. And yes, I HAVE tried to make an X-Face sequel with BWTC32Key
> [which I've named `B3Face` and it is BMP or a similar raw image format
> shoved into a .B3K file, akin to how WOFF3 is shoving a TTF/OTF into a
> .B3K file, both with applicable changes to file extensions [this is
> what I meant by it can be used as a chunk format in other formats, for
> the record] as needed), assuming 8BitMIME, but I think that it is a
> big can of worms, and WOFF(2) is more defined than .xface currently,
> but I don't know if it needing 8BitMIME disqualifies it.) And I'm not
> sure what the policy is on sending demo text, either for BWTC32Key or
> X-Face, due to them creating quite a few lines of text only computers
> can understand, and annoying anyone is the last thing I want to do.

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]