(registered 2025-01-02, last updated 2025-01-02) Media type name: application Media subtype name: vnd.kdl Required parameters: N/A Optional parameters: N/A Encoding considerations: 8bit The format is strictly UTF-8. Security considerations: 1. The format is pure data, and is not executable (unless a program would choose to execute its data). 2. No privacy or integrity services are necessary on its own, besides any desired data protection at the user/application level. Still, the data itself might be sensitive in its particular use case. 3. Transfer of KDL documents over the network can be secured through external means, such as TLS or SSH encryption. 4. There are no built-in linking facilities of any sort. KDL is a pure data language, much like JSON, and does not even provide cross-file referencing/imports or internal referencing. What you see is what you get. 5. Additionally, the format itself takes certain measures against superficial attacks, such as banning certain uses of "direction control" characters and various other control characters. 6. KDL accepts a very wide range of UTF-8 characters, including "invisible" unicode characters. While all unicode whitespace is considered actual whitespace by the language, non-whitespace invisible characters are treated just like anything else. That means that what might look to a reader as two separate items in a list might, in fact, be a single one. 7. Likewise, KDL reserves a very small number of characters as special syntax characters, but it is possible to craft documents with "lookalikes" (e.g. equals signs other than `=`, or "smart quotes") that would result in semantically different data than what might initially be perceived. 8. Even so, this is a vector shared by a very large number of similar formats, and it was decided that playing "whack-a-mole" with such characters would be ultimately unproductive, or even worse, give someone a false sense of security. Interoperability considerations: KDL provides a thorough specification (https://github.com/kdl-org/kdl/blob/23918bd55d13fb1e6d895a60db4f991e25887e8a/SPEC.md). It specifies format consumption down to what UTF-8 code points are acceptable. The main interop consideration is that it doesn't specify actual representation so, much like, JSON, there might be interchange issues should different implementations choose to represent their information differently (e.g. possibly representing all numbers as floating point numbers, as a JavaScript implementation might). Some facilities for this are provided, such as `#nan` `#inf` and `#-inf` for implementations which might choose to support those special IEEE 754 values. Published specification: N/A (not going into the spec tree). A non-"standards" specification is available at https://github.com/kdl-org/kdl/blob/23918bd55d13fb1e6d895a60db4f991e25887e8a/SPEC.md. Applications which use this media: KDL is primarily intended for human-readable configuration and data management. A wide range of applications are able to use the format for flat file config formats, such as package managers (Orogene), window managers (Niri), and terminal multiplexers (Zellij). Additionally, it has seem usage as a DSL base for things like IDLs (Stardust XR). Fragment identifier considerations: N/A Restrictions on usage: None Additional information: 1. Deprecated alias names for this type: none 2. Magic number(s): none 3. File extension(s): .kdl 4. Macintosh file type code: TEXT 5. Object Identifiers: none Person to contact for further information: 1. Name: Katerina Zoé Marchán Salvá 2. Email: iana&zkat.tech Intended usage: COMMON KDL is a general-purpose data and configuration language. Author/Change controller: Katerina Zoé Marchán Salvá