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

On Mon, Feb 23, 2026 at 6:41 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
> * "compression-level"; requires an integer or floating point value with no
> more than six digits of precision.
>
> * "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, 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 a "charset"
> parameter. The encoder 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.
>

To what does "it" in the first sentence refer?  The payload?

If "compression-level" has a default, it's not a required parameter.  I
would move that to the "Optional Parameters" list.

We don't really have a provision for "required if", so I don't have a
strong opinion about whether "password" should be required or optional.
And I guess, given the prose below, that goes for "compression-level" too.


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

You can't list this as both required and optional.


> * "decoded-mimetype" (Stores the MIMEtype of a decoded file that has yet
> to be downloaded, is by default "application/octet-stream" in the HTML5
> version); a string expressed in the same encoding used by MIME for
> MIMEtypes.
>

The common parlance is "media type", not "MIME type".  (Specifically,
they're not just used for email anymore.)


> The password, like a non-default Compression Level, is optional in the
> browser version. The default value in the box in the HTML5 version is
> "Enter a password here before uploading." (even though the code is entirely
> client-side), 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.
>

I still don't understand why the media type specification needs to
stipulate a browser presentation aspect.  The media type registration is
meant to provide guidance to implementers that will either generate or
consume objects tagged with this media type; this seems very out of scope
to me.


> Also it 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, 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).


To what does "it" refer?


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

Suggest passive voice, e.g., change, "You can specify ..." to "It is
possible to specify ..."


> 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 it DOES try to tell
> browsers it is a UTF-16BE text document. This is a description of the
> "encoded-filename" parameter's function.
>
> 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 archaic (Hangul+Hanja) Korean
> characters with 93.75% efficiency. 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 when the character set is UTF-16, and by default it is
> UTF-16BE.
>
> Security considerations: The AES256-CTR implementation used has quirks and
> they make correct 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.
>

I suggest dropping all but the first sentence here.


> 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: 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 detailed. I also have some information on it at
> https://stgiga.itch.io/bwtc32key where it is mirrored.


I suggest using the passive voice, i.e., change "I have some information
..." to "More information can be found ..." and "I self-documented the file
type ..." to "The file type has been documented ..."


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


-MSK

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