The 'haptics' Top-Level Media Type
Extracted elements (19)
A dedicated 'haptics' top-level type enables streamlined registration of formats for multiple haptic sub-modalities (vibrotactile, kinesthetic, surface, spatial/ultrasound, thermal) that could not be naturally grouped under 'audio', 'video', or 'application'.
Haptics is designated as a top-level media type (analogous to 'audio' for hearing and 'video' for sight) because touch is an equally important human sense, haptic files can exist entirely independently of audio or video content, and 'application' implies executable code which carries inappropriate security connotations.
The 'application' top-level type is explicitly rejected for haptics because: (1) haptics connects directly to a sensory system; (2) 'application' is historically associated with executable code and carries heightened security scrutiny not applicable to haptic data; (3) haptics is a property of a media stream, not an application.
The 'haptics' top-level type is justified by haptics being standardized as a first-order track type in ISOBMFF (ISO/IEC 14496-12, 7th Edition, January 2022) at the same level as audio and video, and by widespread commercial deployment across smartphones, game controllers, and XR devices.
For ISOBMFF/mp4 files, the intended designations are: 'haptics/mp4' for files with haptic tracks only, 'video/mp4' for files with video, audio, and haptics, and 'audio/mp4' for files with audio and haptics, preserving consistency with existing mp4 registrations.
The HJIF format is designed as an interchange format for temporal and spatial haptic effects, allowing haptic rendering software to adapt effects to available hardware via a reference device description.
The IVS format is designed for interoperability between distinct physical endpoints, but not all devices may be able to render all effects present in an IVS file.
If an implementation does not recognize a parameter sub-value in the comma-separated list of subtype parameters, it should ignore the sub-value and continue processing the other sub-values in the list.
New haptics formats should be requested using the Application for a Media Type online form. RFC 6838 should be consulted on registration procedures; the haptics specification should preferably be freely available.
Unrecognized subtypes of 'haptics' should be treated as 'application/octet-stream'. Implementations may still pass unrecognized subtypes to the haptics subsystem and associated rendering hardware.
The 'haptics/hjif' subtype is a human-readable haptic effect coding based on JSON format (ISO/IEC 23090-31). Effects may target specific body parts and reference a device description for hardware adaptation. Encoding: 8bit (UTF-8) or binary (UTF-16/UTF-32). File extension: .hjif.
The 'haptics/hmpg' subtype is a streamable binary haptic effect coding (ISO/IEC 23090-31) for efficient coding of temporal and spatial haptic effects. Effects may target specific body parts and reference a device description. Encoding: binary. File extension: .hmpg.
The 'haptics/ivs' subtype is a device-independent haptic effect coding based on XML format (ISO/IEC JTC 1/SC 29/WG 2 N0072). Encoding is 8bit for UTF-8 or binary for UTF-16/UTF-32. File extension: .ivs.
The 'haptics' top-level media type indicates content that requires a haptics subsystem (low-level haptics APIs and hardware actuators) to render. It does not specify the underlying data format; subtypes name the specific haptic formats.
IANA has registered 'haptics' as a new top-level media type in the 'Top-Level Media Types' registry defined in RFC 9694, and added 'haptics' as an alternative value of 'Type Name' in the media types registration form.
Three initial subtypes registered under 'haptics': 'haptics/ivs' (IVS XML-based format), 'haptics/hjif' (HJIF JSON-based interchange format), and 'haptics/hmpg' (HMPG streamable binary format), all controlled by ISO/IEC JTC1/SC 29/WG 7.
Haptic data security is expected to mirror that of audio/video media. Descriptive haptic encodings (XML/JSON) may present risk if extensibility or injected executable data allows malicious instructions to execute arbitrary code in kernel space, bypassing system permissions and sandboxes.
Signal data in haptic encodings is typically not executed by processors and presents minimal security risk. Descriptive text is parsed into XML data structures and used to construct signals sent to hardware. OS and device driver implementors should ensure synthesis/rendering paths do not provide attack surfaces.
Thermal and kinesthetic haptic devices could injure users if heat or force are not properly controlled or inadvertently exceed safety levels; implementors must ensure adequate safety measures are in place.