Prompt and scenario
Your team needs to exchange haptic tracks through downloads, live media, and device-to-device transfer. Existing audio, video, and application types only partly express the semantics. Using RFC 9694, evaluate whether a new haptics top-level media type is justified and cover subtypes, content negotiation, unknown implementations, evolution, and security boundaries.
What the interviewer is assessing
- Whether you distinguish a top-level type, concrete subtype, parameter, and file format instead of treating a MIME string as a complete protocol.
- Whether you apply clear scope, at least one meaningful subtype, a public specification, interoperability, and IANA registration requirements.
- Whether you design downgrade paths for unknown types, old clients, proxies, caches, and content negotiation.
- Whether you identify interpreter, hardware-actuation, resource-exhaustion, privacy, and physical-safety risks rather than discussing registration alone.
Clarifying questions to ask first
Confirm whether the data represents an independent sensory medium, whether multiple interoperable formats already exist, whether it must synchronize with audio or video, and whether clients can safely ignore unknown capabilities. Ask about transport, file encapsulation, latency, caching, device capability discovery, and failure UX. If there is only one private format for one application, prefer an application subtype or private registration rather than creating a top-level type.
A 30-second answer framework
I would first show that existing top-level types cannot express the semantics accurately and verify multiple interoperable subtypes and real deployment needs. RFC 9694 asks for clear scope and subtype criteria, at least one described subtype, and complete security considerations. If the evidence holds, I would propose haptics while keeping a compatibility path in existing containers. I would define negotiation, unknown-subtype behavior, parameter registration, and rollback. Implementations would reject dangerous capabilities by default, separate parsing from hardware rendering, and bound energy, duration, and intensity parameters.
Step-by-step deep dive
1. Decide the type level first
A top-level type expresses cross-format content semantics; a subtype identifies a concrete encoding or interchange format; parameters add negotiation information. Do not request a top-level type for every new file extension. Check whether the content fits audio, video, image, or application semantics and whether it has capabilities shared across implementations.
2. Test the RFC 9694 bar
The proposal must state what belongs in the type and what explicitly does not, so future subtype boundaries remain clear. It needs at least one useful subtype; an empty top-level name has no interoperability value. Include a publicly reviewable specification, encoding and interoperability details, and security considerations covering every subtype or important common risk.
3. Use haptics as the case study
RFC 9695 defines haptics as an independent sensory media type and registers subtypes such as ivs, hjif, and hmpg. Haptic data can stand alone or synchronize with audio and video; placing it under application would lose media semantics. The case also shows that a top-level type describes content class, while each subtype defines how an encoding is interpreted.
4. Design negotiation and fallback
The sender selects a subtype from Accept and device capabilities; the server declares the relevant Vary dimensions to avoid cache pollution. When an old client cannot understand the new type, provide an audio or video container, a static alternative, or an explicit unavailable state. Unknown subtypes are not executable code; parsers reject unsupported parameters and record the reason.
5. Bound parsing and hardware
Separate decoding, policy checks, and hardware rendering. Bound file size, duration, sample rate, amplitude, and concurrent jobs to prevent resource exhaustion. Haptic data can control actuators, so it must run within user consent, device capability, and safety limits. The server must not treat Content-Type as a trust boundary.
6. Plan registration and evolution
Prepare the IANA template, subtype naming rules, parameters, and security section, including the stable specification version and change controller. Define backward-compatible behavior for new parameters; unknown parameters are ignored or rejected according to the specification. Track negotiation failures, fallback rate, parse errors, cache hits, and device safety rejections before expanding deployment.
High-quality sample answer
I would build three tables: semantics, ecosystem, and risk. If the data is a private encoding for one application, use an application subtype. If it is an independent sensory medium with multiple interoperable formats and cross-file, live-stream, and device exchange needs, use RFC 9694 to justify a top-level type. The proposal needs clear boundaries, at least one useful subtype, a public specification, interoperability details, and security considerations for shared risks. RFC 9695’s haptics case shows that the top-level type carries media semantics while ivs, hjif, and hmpg define concrete encodings. The server negotiates a subtype, gives old clients a compatible container or explicit fallback, and varies caches on the actual negotiation dimensions. Parsing, policy checks, and hardware rendering are separate; size, duration, intensity, and concurrency are bounded, and device capability and user consent are required. Unknown subtypes or dangerous parameters are rejected by default. Content-Type is not a trust boundary. After launch I would track negotiation failures, fallback, parse errors, and safety rejections before growing the ecosystem.
Common mistakes
- Creating a top-level media type for every new file format.
- Writing only an IANA name without scope, subtype rules, or a public specification.
- Treating the top-level type as an encoding format and mixing parameter and interoperability responsibilities.
- Letting unknown clients treat data as executable content or ignoring proxy and cache differences.
- Validating only Content-Type while leaving parsing resources, hardware capability, and user consent unbounded.
Follow-up questions and responses
When is an application subtype better?
Use it when the structure is application-specific, has no independent media semantics, and has one or a few tightly controlled encodings. Revisit a top-level type when cross-vendor formats, independent negotiation, and stable shared capabilities appear.
How do you avoid breaking old clients?
Have the sender offer a compatible container or alternate representation, and negotiate from Accept and device capability. Old clients receive an explicit unavailable state or a representation they can render. Include the actual negotiation dimensions in cache keys.
What is the security boundary for haptic data?
The parser bounds size, duration, frequency, and intensity; the renderer clips to device safety limits. Require user consent and capability checks. Authentication, authorization, and content validation remain independent of the media type; a haptics value does not make a payload trusted.