Summary

  • RFC 9695 makes haptics/* a routable media family, but an unknown subtype may fall back to application/octet-stream and may still be handed to a haptics subsystem; neither outcome proves exact-format support or safe physical rendering.
  • A defensible receipt follows the same object through subtype recognition, parameter loss, reference-device adaptation, local policy, safety limiting, actuator commands and a verified neutral state instead of treating a Content-Type header as the result.

The file arrives with Content-Type: haptics/hjif. That header answers a narrow question: which class of rendering system should consider the content? It does not say that this receiver implements HJIF, that every named effect is available, that the target body location exists on the device, that intensity maps linearly, or that an actuator moved at all.

RFC 9695 matters because it gives haptics a first-class place beside audio and video. It registers three initial subtypes—IVS, HJIF and HMPG—and describes a family whose content needs a haptics subsystem and associated hardware. The classification is real infrastructure. It lets gateways, stores and applications distinguish tactile media from a generic blob. Yet the label stops before the physical outcome, exactly where operational evidence becomes most important.

One label, two fallback paths

The standard separates the top-level type from the exact format. haptics announces the rendering family; the subtype names the representation. If an implementation does not recognize a subtype, RFC 9695 says it should treat the content as application/octet-stream. That is the conservative MIME fallback: unknown bytes do not acquire a decoder merely because the left side of the slash is familiar.

The same section also allows an implementation to pass an unrecognized subtype to its haptics subsystem and associated hardware. This is not a contradiction. Generic handling and local dispatch are different policy points. A file manager may store the object as opaque data while an application with a pluggable renderer offers it to a lower layer. A future subtype may be unknown to the front end but known to a device service. The permission preserves extensibility.

It also destroys a tempting shortcut in audit language. “Fell back to octet-stream” does not necessarily mean “could not reach a physical path.” “Sent to the haptics subsystem” does not mean “decoded according to the registered format.” A useful record must preserve both decisions: what the media layer recognized and what the application subsequently did with the bytes.

This is where RFC 9695 differs from the neighbouring governance question in RFC 9694. RFC 9694 explains why a new top-level media type deserves a rare name to the left of the slash. The present problem begins after that name exists. It asks which meaning survives the route from a valid family label to a particular actuator.

Success can mean that one constraint disappeared

RFC 9695 anticipates extensible parameters. A parameter may contain a comma-separated list of sub-values. When a processor recognizes the parameter but not one sub-value, it should ignore the unknown sub-value and continue processing the recognized values.

That rule is practical. A new device class should not make an otherwise usable object unreadable on an older endpoint. But a return value of “processed” now has several meanings. The endpoint may have honored all values, selected one supported value, discarded an unknown value, substituted a default, or accepted syntax without rendering the associated effect.

Imagine a parameter that names several intended device properties. The sender may regard the list as a description of one complete target environment. The receiver may read it as a menu and keep only the item it knows. Both can follow the continuation rule, while the physical result no longer carries the sender’s full constraint set. The missing sub-value is not merely parser noise if it described the actuator that was supposed to absorb force, deliver texture, or limit temperature.

The receipt therefore needs a parameter ledger. For each declared parameter, record the raw value, every recognized sub-value, every ignored sub-value, every default, and the resulting decoder configuration. A binary “valid/invalid” field cannot distinguish graceful extension from silent semantic contraction.

Device-independent does not mean device-equivalent

The initial formats make the distinction visible. IVS is an XML-based, device-independent interchange format. RFC 9695 immediately qualifies the promise: not every device can render every effect represented in IVS. Device independence lets the description travel without being hardwired to one product; it does not manufacture missing actuators at the destination.

HJIF uses JSON to describe temporal and spatial haptic material. HMPG is the binary MPEG representation. Both can associate effects with body locations and can include a reference-device description so rendering software can adapt the experience to actual hardware. That adaptation is an explicit transformation, not a transparent cable.

A reference device may have more actuators, different placement, a wider intensity range, a different force envelope, or a thermal channel that the endpoint lacks. The renderer must map, merge, omit, clamp or reschedule effects. Two receivers can accept the same object and produce different outputs without either one misrouting the media family. One may collapse a spatial sweep into a single vibration; another may preserve the sequence but lower amplitude; a third may omit it.

Official Apple Core Haptics documentation illustrates this local layer without establishing RFC 9695 support. Its engine exposes transient and continuous events, intensity and sharpness parameters, pattern players, and hardware capability checks. Its AHAP representation also shows that missing parameters can acquire defaults. These are examples of why a rendering receipt must name the actual engine and hardware. They are not evidence that an Apple format is IVS, HJIF or HMPG.

The evidence question is effect completeness. Start with a normalized list of requested effects. After parsing, compare the understood list. After adaptation, compare the realizable list. After policy and limiting, compare the command list. If an effect disappears, record the stage and reason. “Playback completed” is only the final control-flow fact.

Media, not code, is not a safety certificate

The RFC registrations say these formats are media rather than executable code. That classification helps software decide which handling model applies. It does not remove the software attack surface. RFC 9695 calls out XML and JSON parsing, descriptive structures, and code that can run through user-space and kernel paths. Malicious descriptive data can still exploit a vulnerable parser or lower-level implementation.

Nor does media classification tame the output. Haptic systems can produce vibration, kinesthetic force, temperature and texture-like effects. The RFC warns that thermal and kinesthetic devices can cause injury if limits are not controlled. The dangerous property is not whether the input is called code; it is whether interpreted data can command energy into hardware.

This suggests two independent safety cases. The software case asks whether the parser, decoder, allocator and driver safely handle hostile structure. The physical case asks whether duration, amplitude, force, temperature, slew rate, body location and repeated exposure stay inside device and user limits. Passing one case says nothing conclusive about the other.

The W3C Vibration API shows a separate admission layer: a user agent can restrict vibration based on document state and Permissions Policy. That API is not equivalent to RFC 9695 media. Its relevance is architectural. A syntactically valid request can be suppressed by local context, and such suppression should remain distinguishable from parse failure or hardware absence.

The physical chain needs its own evidence

The chain begins with an immutable object hash and its declared media metadata. It continues through registry knowledge, subtype selection, parameter interpretation, parser result, device-capability discovery, reference-device mapping, application policy, operating-system policy, safety limits and driver commands. Only then does it reach actuators and the body.

Each layer answers a different question. IANA’s current media-type registry shows which subtype names are registered. It cannot attest that an endpoint implements them. A decoder receipt can prove that a structure was accepted. It cannot prove that every effect was retained. A command trace can show what the driver received. It cannot, without measurement, prove displacement, force, temperature or sensation.

The endpoint should issue a structured rendering receipt rather than one success bit. It should bind the source hash to the recognized subtype; list ignored and defaulted values; identify the decoder, adaptation algorithm and capability profile; enumerate omitted, merged and clamped effects; record local consent and policy; capture limiter settings and actuator commands; and confirm stop or neutral state. Physical measurements and user reports belong in separate fields with a stated method.

That separation also prevents a category error around RFC 9993. RFC 9993 adds an RTP payload format, packetization rules and SDP parameters for MPEG-I haptics, and updates haptics/hmpg. It owns transport reconstruction and session negotiation. Reassembling the correct media unit is necessary, but it still precedes the subtype, adaptation and physical-output boundary examined here.

A minimum standard should leave local decisions visible

Lu Heng’s minimum-initial-specification doctrine offers the right governance shape. The shared layer should be narrow enough to interoperate: the family name, subtype registrations, parameter syntax and baseline fallback behaviour. Capability, adaptation, consent, safety limits and support for future effects remain local decisions. Locality is not a defect when the record makes it explicit.

Reality-layer discipline prevents a registry entry from borrowing the authority of an actuator trace. The Content-Type header is a symbolic claim about handling. Parser acceptance is an implementation fact. Adaptation is a transformation. A driver command is an attempted physical action. Measured force or temperature is a physical observation. User sensation is a reported experience. Collapsing them into “haptics worked” hides precisely the boundaries that govern risk.

Running-code primacy then changes the hierarchy of proof. A specification and registry establish what software should mean. The stronger operational evidence is what this endpoint, with this version and this hardware, actually recognized and commanded under this policy. The point is not to distrust standards. It is to stop asking a naming standard to certify a result it was never designed to observe.

Sources