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

One minor change and I think this is good to go.

-MSK

On Thu, Feb 26, 2026 at 12:02 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:
>
> * "charset"; as specified in RFC2045 for "text" types
>
> * "password" (required for the NodeJS port or to encrypt); a string
> expressed in UTF-8.
>
> * "decoded-filename" (Stores the filename of a decoded file that has yet
> to be downloaded, defaults to "output.bin" in the HTML5 version); a string
> expressed in UTF-8.
>
> * "encoded-filename" (Stores the filename of an encoded file that has yet
> to be downloaded, defaults to "myFile.B3K" in the HTML5 version.); a string
> expressed in UTF-8.
>
> Essentially, as a text-based (albeit Unicode) format, though canonically
> UTF-16BE, BWTC32Key's output text 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 a "charset" parameter. The encoder in the original HTML5
> implementation has "Compression Level"/"compression-level" default as "9",
> relying on HTML's ability to have a default value in a <number> tag. For
> the NodeJS port it is strongly advised to specify a level (given argument
> placeholders in NodeJS in this situation being messy) 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:
>
> * "password" (required for the NodeJS port or to encrypt); a string
> expressed in UTF-8.
>
> * "compression-level"; requires an integer or floating point value with no
> more than six digits of precision, is 9 by default in the HTML5 version,
> MUST be specified in the NodeJS version.
>
> * "decoded-mediatype" (Stores the media type of a decoded file that has
> yet to be downloaded, is by default "application/octet-stream" in the HTML5
> version); a string expressed in US-ASCII.
>
> The password, like a non-default Compression Level, is optional in the
> original HTML5 implementation of BWTC32Key. The default password value in
> the HTML5 version is "Enter a password here before uploading." (even though
> the code in that implementation is entirely client-side), due to
> implementation reasons, and it is used for "unencrypted" (the encryption
> never truly is skipped) files, due to that statement being treated as a
> password if not overwritten, so it is in essence a default password that
> should be factored into decoders.
>

> Also, BWTC32Key uses SHA256 to turn the UTF-8 password into the AES256-CTR
> key so a blank password will also work as an unencrypted one (though not to
> the obsolete 2019 version of the HTML5 implementation, which follows the
> above paragraph but due to a bug behaves as "unencrypted" as described in
> that paragraph no matter what password value is used) using spaces or tabs
> for "blank" passwords is permitted, as are newlines in the HTML5 version).
>
> The password is UTF-8. The code already hashes the password, so the
> parameter IS the password, *not* a hash of it. There are NO length limits
> on passwords.
>
> It is possible to specify a MIMEtype for what the browser will save when
> decoding (What this means is that the filename and MIME type of the decoded
> file are set by the user, because they are NOT stored in the file), but in
> the HTML5 version it defaults to "application/octet-stream", and that same
> decoded file's default filename is "output.bin". The output filename MUST
> be specified in the NodeJS version. The HTML5 version is where the MIME
> types are most relevant.
>
> The way the encoded-filename parameter works is that saving a .B3K file
> from encoded output is done as a file with "myFile.B3K" as its name by
> default in the HTML5 version (it can be changed to anything, and it MUST be
> specified in the NodeJS version), and in the case of the HTML5 version it
> DOES try to tell browsers it is a UTF-16BE text document to ensure that it
> is handled as text.
>
> 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 for this) used to store
> AES256-CTR encrypted BWT-compressed data as common Unicode characters with
> up to 93.75% efficiency on just the binary-to-text component alone. None of
> its components already exist in the list of MIME types.
>
> The most important part of the above is that the format's space savings
> benefit MOST (as in, the binary-to-text encoding used gets its full 93.75%
> efficiency; the character set doesn't change how the compression or
> encryption steps work, and in fact those work just as well regardless of
> what UTF they are asked to compress) when the character set used to store
> BWTC32Key strings is UTF-16, and by default it is UTF-16BE.
>
> Security considerations: The AES256-CTR implementation used has quirks and
> they make correct (good AES256-CTR practice) usage consisting of assigning
> the counter value to the current time cause the issue of making decryption
> not work. The encryption key is generated from a UTF-8 password of any
> length via non-HMAC SHA256. The decompression buffer being uncapped could
> create overflows even though it does allow large files.
>
> 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 program doesn't have privacy protection or integrity checking
> services.
>
> 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.
>

Please change the last sentence to "It has been developed and tested across
all platforms in modern use".


> Published specification: In this case, fileformats.archiveteam.org's wiki
> article on it fits, as does https://github.com/stgiga/bwtc32key (the
> actual source code)
>
> Applications which use this media: File compression programs.
>
> Fragment identifier considerations: None
>
> Restrictions on usage: None
>
> Provisional registration? (standards tree only): N/A
>
> Additional information:
>
> 1. Deprecated alias names for this type: 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
>
> General Comments: The file type has been documented on the File Formats
> Wiki (by Archive Team) as well as on Github 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 detailed. Further information on it at
> https://stgiga.itch.io/bwtc32key where it is mirrored.
>
> MOST importantly (magic numbers ARE important) the file extension is .B3K
> and this format's files have 0xFEFF4D00 as the file header and 0x4D01 as
> the end marker (all assuming UTF-16BE). Inside the compression step there
> are the ASCII 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). A
> successful decode has to go through all this, so corruption is fairly easy
> to weed out.
>
> Person to contact for further information:
>
> 1. Name: Raja Fjords
> 2. Email: [email protected]
>
> Intended usage: N/A
>
> Author/Change controller: Raja Fjords, [email protected]

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