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

Hi Murray,

We have a revised request for you.

thanks,
Amanda

=====

I've edited my application to better fit the instructions, though most significantly I left in parts like Magic Numbers which have relevance, and you are right in that I had missed properly defining parameters so I added in the parameters related to the decoding, and I properly defined them beyond just in prose.

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.

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

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

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.

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.

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. 

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]


I hope that this clarifies things, and if you have any further questions I would be happy to address them. And my apologies for any confusion there may have been. You aren't the first party to be confused by what I write, so don't worry, I wasn't trying to cause any confusion. Oh and yes, I know that the format IS a bit... quirky, but it isn't a joke. At least I'm trying to do the right thing. Anyways, I'm glad I got the news I got.

Also, yes, the mention of X-Face in earlier correspondence was because that very same provisional message header was historically ALSO saved as a dedicated file, and I am involved with the person who submitted the application for it, before we later found in 2025 that even 24bit color was supported, via three arrays of X-Face: + X-Face-1: through X-Face-7: headers, and what controlled all of these headers was X-Face-Type: which has several parameters related to image modes, namely MONO/GRAY/RGB [color modes], geometry=NxN [how many 48x48 cells build up a larger image], depth=N [declaring grayscale bit depth or RGB channel max bit depth], and animate=N [how many seconds per frame, CAN be a decimal], and X-Face-Version: which is a header whose contents contain version info about the generator and/or intended decoder, some forms having Easter eggs).
 My format being usable as a spin on the X-Face concept was also mentioned as a way to at least remain relevant. Anyways, the X-Face mention was in part to amend new discoveries (24bit) to it, and describing future plans for not just entering it as a new header but also maybe applying for a MIMEtype for it. But that's all for later. What matters is the current matter.

Now then, BWTC32Key was always going to have a complex proposal due to how exotic it is, and for that I apologize if I had accidentally turned any heads, which wasn't my intent. Never mind all the wild uses I found for it. I hope I've provided enough clarification and a "that's why I did what I did" for everything to go well, and if you have more questions, I'd be all ears to answering them as best as I can. I just want to do the right thing.

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