[media-types] Re: [IANA #1444004] application/prs.bw tc32key registration request

On Thu, Feb 19, 2026 at 6:21 PM Amanda Baber via RT <
[email protected]> wrote:

> > 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.
>

I would prefer if this started with the list of required parameters and
their syntaxes, and then prose can come afterwards.  For example:

* "charset"; as specified in RFC2045 for "text" types
* "compression-level"; requires an integer or floating point value with no
more than six digits of precision
* "password" (required for the NodeJS port); a string expressed in UTF-8

...and then whatever prose you want to describe them further.

> 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).
>

Same here:

* "password"; see above for syntax

...and then any relevant prose.

I don't understand what the "default value" sentence is saying; we're
talking about parameters to the media type here, but this is stipulating
how a password prompt box should be decorated.  I'm not sure that belongs
in a media type registration because it has nothing to do with the payload.

I also don't understand why SHA256 is mentioned when you said the password
is in UTF-8 format.  Do you want the hashed password in the parameter, or
the password itself?

How would one specify the media type for what the browser should save when
decoding?  Is that in another parameter that's not named here?

I don't understand the relevance of that "Downloading ..." sentence, nor do
I understand what that's saying in the first place.


> > 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.


You don't need any of this exposition.  What we're looking for is the
information you need consumers of this media type to have.


>  > 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.
>

This is relevant, so keep it.

> 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.
>

None of this is necessary either.  But you probably do want to say that
this media type provides no privacy protection or integrity checking
capabilities.


> > 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.
>

None of these appear to be a published specification.


> > 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.
>

I would just say "File compression programs".


> > 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.
>

This should just be "None".


> > 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.
>

This should just be "N/A".


> > 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.
>

This should just be "N/A".


> > 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.
>

I would omit this from the registration. It's better covered in the
published specification.

That first link is probably what you should use as the "Published
Specification".


> > 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.
>

This bit is also not required.

-MSK

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