rfc9695.original.xml   rfc9695.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
or - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-ietf-mediaman-haptics-05" subm
issionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/
XInclude" consensus="true">
<front> <!-- draft submitted in xml v3 -->
<title abbrev="The 'haptics' Top-level Media Type">The 'haptics' Top-level Media
Type</title><seriesInfo value="XXXX" stream="IETF" status="standards" name="RFC <!DOCTYPE rfc [
"></seriesInfo> <!ENTITY nbsp "&#160;">
<author initials="Y. K." surname="Muthusamy" fullname="Yeshwant K. Muthusamy"><a <!ENTITY zwsp "&#8203;">
ddress><postal><street>600 Longwood Drive</street> <!ENTITY nbhy "&#8209;">
<city>Allen</city> <!ENTITY wj "&#8288;">
<code>TX 75013</code> ]>
<country>USA</country>
</postal><phone>+1 469-854-9836</phone> <rfc version="3" ipr="trust200902" docName="draft-ietf-mediaman-haptics-05" numb
<email>yeshwant@yeshvik.com</email> er="9695" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://ww
</address></author> w.w3.org/2001/XInclude" consensus="true" tocInclude="true" obsoletes="" updates=
<author initials="C." surname="Ullrich" fullname="Chris Ullrich"><address><posta "" symRefs="true" sortRefs="true">
l><street>311 Court Ave</street>
<city>Ventura</city> <front>
<code>CA 93003</code> <title abbrev="The 'haptics' Top-level Media Type">The 'haptics' Top-level M
<country>USA</country> edia Type</title>
</postal><phone>+1 805-320-0774</phone> <seriesInfo name="RFC" value="9695"/>
<email>chrisullrich@gmail.com</email> <author initials="Y. K." surname="Muthusamy" fullname="Yeshwant K. Muthusamy
</address></author> ">
<date/> <address>
<area>Internet</area> <postal>
<workgroup>MEDIAMAN</workgroup> <street>600 Longwood Drive</street>
<city>Allen</city>
<region>Texas</region>
<code>75013</code>
<country>United States of America</country>
</postal>
<phone>+1 469-854-9836</phone>
<email>yeshwant@yeshvik.com</email>
</address>
</author>
<author initials="C." surname="Ullrich" fullname="Chris Ullrich">
<address>
<postal>
<street>311 Court Ave</street>
<city>Ventura</city>
<region>California</region>
<code>93003</code>
<country>United States of America</country>
</postal>
<phone>+1 805-320-0774</phone>
<email>chrisullrich@gmail.com</email>
</address>
</author>
<date year="2024" month="December"/>
<area>ART</area>
<workgroup>mediaman</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t>This memo serves to register and document the 'haptics' top-level <t>This memo registers and documents the 'haptics' top-level
media type, under which subtypes for representation formats for haptics media type, under which subtypes for representation formats for haptics
may be registered. This document also serves as a registration for a set of subt ypes, which are representative of may be registered. This document also serves as a registration for a set of subt ypes, which are representative of
some existing subtypes already in use.</t> some existing subtypes already in use.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"><name>Introduction</name> <section anchor="introduction"><name>Introduction</name>
skipping to change at line 48 skipping to change at line 75
in a device or interface. Haptics is widely used in consumer devices in in a device or interface. Haptics is widely used in consumer devices in
order to provide touch-based feedback to users. The most common use of order to provide touch-based feedback to users. The most common use of
haptics is in mobile devices, where it is used to provide feedback to haptics is in mobile devices, where it is used to provide feedback to
users interacting with the touchscreen, e.g., typing on a virtual users interacting with the touchscreen, e.g., typing on a virtual
keyboard. Haptic technologies are unlike audio and visual enabling keyboard. Haptic technologies are unlike audio and visual enabling
technologies in the sense that they require some form of actuation in technologies in the sense that they require some form of actuation in
order to create a tactile sensation. For mobile phones and game order to create a tactile sensation. For mobile phones and game
controllers, these actuators are typically small vibrating motors. controllers, these actuators are typically small vibrating motors.
For large touchscreens in vehicles, these actuators can be specialized For large touchscreens in vehicles, these actuators can be specialized
piezoelectric materials. Haptic capabilities are found in nearly every piezoelectric materials. Haptic capabilities are found in nearly every
modern smartphone and game and virtual reality controller, making these modern smartphone, game, and virtual reality controller, making these
devices an ideal target for enhanced media experiences.</t> devices an ideal target for enhanced media experiences.</t>
<t> <t>
Internet Media Types <xref target="RFC6838"></xref> are used to label content ca rried over Internet Media Types <xref target="RFC6838"></xref> are used to label content ca rried over
Internet protocols. This document defines a new top-level type 'haptics' Internet protocols. This document defines a new top-level type, 'haptics',
according to <xref target="TOPLEVEL"></xref>. This top-level type indicates according to <xref target="RFC9694"></xref>. This top-level type indicates
that the content specifies haptic data. Under this top-level type, that the content specifies haptic data. Under this top-level type,
different representation formats of haptics may be registered.</t> different representation formats of haptics may be registered.</t>
<!-- [rfced] We do believe the capitalized keywords are used in the RFC. Please
review and let us know if any of the capitalized keywords should be used. Other
wise, we will remove the Terminology section and related references.
Original:
1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD,SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in
this document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
-->
<section anchor="terminology"><name>Terminology</name> <section anchor="terminology"><name>Terminology</name>
<t>The keywords <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</b cp14>, <bcp14>SHALL</bcp14>, <bcp14>SHALL NOT</bcp14>, <t>The keywords <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</b cp14>, <bcp14>SHALL</bcp14>, <bcp14>SHALL NOT</bcp14>,
<bcp14>SHOULD</bcp14>,<bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>, <bc p14>NOT RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and <bcp14>OPTIONAL</bcp14> in this document are to be interpreted as described in BCP 14 <xref target="RFC2119 "></xref> <xref target="RFC8174"></xref> when, and only when, they appear in all capitals, as shown here.</t> <bcp14>SHOULD</bcp14>,<bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>, <bc p14>NOT RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and <bcp14>OPTIONAL</bcp14> in this document are to be interpreted as described in BCP 14 <xref target="RFC2119 "></xref> <xref target="RFC8174"></xref> when, and only when, they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="background-and-justification"><name>Background and Justificatio n</name> <section anchor="background-and-justification"><name>Background and Justificatio n</name>
<t>Haptic signals provide an additional layer of entertainment and sensory <t>Haptic signals provide an additional layer of entertainment and sensory
immersion for the user, when combined with audio and video signals. Haptic track s, in separate files, can be combined immersion for the user, when combined with audio and video signals. Haptic track s, in separate files, can be combined
with audio/video files and played back in sync to provide an overall with audio/video files and played back in sync to provide an overall
immersive media experience (audio, visual, tactile) for the user. More immersive media experience (audio, visual, tactile) for the user. More
recently, haptic tracks embedded in standard file formats such as ISOBMFF recently, haptic tracks embedded in standard file formats, such as ISOBMFF
(ISO Base Media File Format), enable playback of the haptic signals (ISO Base Media File Format), enable playback of the haptic signals
over one or more actuators, simultaneously with audio and video playback <xref t arget="ISOBMFF-IS"></xref>. Haptic signals are also part of over one or more actuators, simultaneously with audio and video playback <xref t arget="ISOBMFF-IS"></xref>. Haptic signals are also part of
media streams that use RTP, such as those for streaming games, XR, and wearables .</t> media streams that use RTP, such as those for streaming games, XR, and wearables .</t>
<section anchor="mpeg-isobmff"><name>MPEG ISOBMFF</name> <section anchor="mpeg-isobmff"><name>MPEG ISOBMFF</name>
<t>Historically, there has not been a registration of formats for haptics. <t>Historically, there has not been a registration of formats for haptics.
However, haptics was proposed as a first-order media type (at the However, haptics was proposed as a first-order media type (at the
same level as audio and video) in ISOBMFF in April 2020. The proposal has since progressed to International Standard, and was published in same level as audio and video) in ISOBMFF in April 2020. The proposal has since progressed to International Standard, and was published in
January 2022 <xref target="ISOBMFF-IS"></xref>. Haptics is January 2022 <xref target="ISOBMFF-IS"></xref>. Haptics is
officially part of the ISO/IEC 14496-12 (ISOBMFF) standard, 7th Edition. Given t his development, officially part of the ISO/IEC 14496-12 (ISOBMFF) standard, 7th Edition. Given t his development,
a strong case can be made for haptics to be added to the list of top-level a strong case can be made for haptics to be added to the list of top-level
media types recognized by the IETF.</t> media types recognized by the IETF.</t>
<t> <t>
We envision the following designations for haptics in mp4 files, once We envision the following designations for haptics in mp4 files, once
the top-level type 'haptics' is registered:</t> the top-level type 'haptics' is registered:</t>
<ol> <ul>
<li>'haptics/mp4' - mp4 files with just haptic tracks and no audio or video in t hem (e.g., <li>'haptics/mp4' - mp4 files with just haptic tracks and no audio or video in t hem (e.g.,
streaming games, haptics files for haptic vests, belts, gloves, etc.)</li> streaming games, haptics files for haptic vests, belts, gloves, etc.)</li>
<li>'video/mp4' - mp4 files with video, audio, and haptics (to ensure <li>'video/mp4' - mp4 files with video, audio, and haptics (to ensure
consistency with existing mp4 files with video content)</li> consistency with existing mp4 files with video content)</li>
<li>'audio/mp4' - mp4 files with audio and haptics (to ensure <li>'audio/mp4' - mp4 files with audio and haptics (to ensure
consistency with existing mp4 files with audio content without any video)</li> consistency with existing mp4 files with audio content without any video)</li>
</ol> </ul>
</section> </section>
<section anchor="haptic-sub-modalities"><name>Haptic Sub-modalities <section anchor="haptic-sub-modalities"><name>Haptic Sub-Modalities
</name> </name>
<t>There are multiple sub-modalities of haptics:</t> <t>There are multiple sub-modalities of haptics:</t>
<ul> <ul>
<li>Vibrotactile (touch, vibration)</li> <li>Vibrotactile (touch, vibration)</li>
<li>Kinesthetic (force feedback)</li> <li>Kinesthetic (force feedback)</li>
<li>Surface (surface friction)</li> <li>Surface (surface friction)</li>
<li>Spatial, non-contact (ultrasound)</li> <li>Spatial, non-contact (ultrasound)</li>
<li>Thermal (temperature)</li> <li>Thermal (temperature)</li>
</ul> </ul>
<t>Therefore, designating 'haptics' as a top-level media type enables the defini tion of data formats pertaining to these sub-modalities <t>Therefore, designating 'haptics' as a top-level media type enables the defini tion of data formats pertaining to these sub-modalities
in a more streamlined manner. This would not be possible if 'haptics' in a more streamlined manner. This would not be possible if 'haptics'
were to be placed under other top-level types like 'audio', 'video', were to be placed under other top-level types like 'audio', 'video',
or 'application'.</t> or 'application'.</t>
</section> </section>
<section anchor="another-human-sense"><name>Another Human Sense <section anchor="another-human-sense"><name>Another Human Sense
</name> </name>
<t> <t>
The top-level media type 'audio' pertains to the human sense of hearing, The top-level media type 'audio' pertains to the human sense of hearing;
the top-level media type 'video' pertains to the human sense of seeing, the top-level media type 'video' pertains to the human sense of seeing;
so it only makes sense for the (equally important) human sense of touch so it only makes sense for the (equally important) human sense of touch
to be represented by another top-level media type 'haptics'. Placing to be represented by another top-level media type 'haptics'. Placing
'haptics' under 'audio' or 'video' is not reflective of the kinds 'haptics' under 'audio' or 'video' is not reflective of the kinds
of files or use cases that would need haptics but have nothing of files or use cases that would need haptics but have nothing
whatsoever to do with audio or video.</t> whatsoever to do with audio or video.</t>
</section> </section>
<section anchor="commercial-uptake"><name>Commercial Uptake</name> <section anchor="commercial-uptake"><name>Commercial Uptake</name>
<!-- [rfced] Would you like to include references for the sales data listed?
Original:
* iPhone (206+ million units sold in 2020): native support for
haptic encoded data
* Android (1.38+ billion units sold in 2020): API support of haptic
buffers
* W3C (HTML vibration API [W3C-Vibration]): Optionally supported in
mobile web browsers. W3C has also defined vibration extensions
for gamepads [W3C-Gamepad]
* Game consoles (39+ million units sold in 2019): MS Xbox, Sony
PlayStation, Nintendo Switch, etc.
* XR devices (9+ million units sold in 2019): OpenXR haptic API
-->
<t>Haptics is rapidly becoming a standard feature of consumer electronic <t>Haptics is rapidly becoming a standard feature of consumer electronic
devices. For example:</t> devices. For example:</t>
<ul> <ul>
<li>iPhone (206+ million units sold in 2020): native support for haptic <li>iPhone (206+ million units sold in 2020): native support for haptic-encoded
encoded data</li> data</li>
<li>Android (1.38+ billion units sold in 2020): API support of haptic <li>Android (1.38+ billion units sold in 2020): API support of haptic
buffers</li> buffers</li>
<li>W3C (HTML vibration API <xref target="W3C-Vibration"></xref>): Optionally su pported in mobile web <li>W3C (HTML vibration API <xref target="W3C-Vibration"></xref>): Optionally su pported in mobile web
browsers. W3C has also defined vibration extensions for gamepads <xref target="W 3C-Gamepad"></xref></li> browsers. W3C has also defined vibration extensions for gamepads <xref target="W 3C-Gamepad"></xref></li>
<li>Game consoles (39+ million units sold in 2019): MS Xbox, Sony <li>Game consoles (39+ million units sold in 2019): MS Xbox, Sony
PlayStation, Nintendo Switch, etc.</li> PlayStation, Nintendo Switch, etc.</li>
<li>XR devices (9+ million units sold in 2019): OpenXR haptic API</li> <li>XR devices (9+ million units sold in 2019): OpenXR haptic API</li>
</ul> </ul>
<!-- [rfced] May we expand CE as Customer Edge?
Original:
Since they represent the majority of CE devices, a strong
case can be made for 'haptics' as a top-level media type.
-->
<t>Haptic media is expected to be commonly exchanged between these devices. <t>Haptic media is expected to be commonly exchanged between these devices.
Since they represent the majority of CE devices, a strong case can be made Since they represent the majority of CE devices, a strong case can be made
for 'haptics' as a top-level media type.</t> for 'haptics' as a top-level media type.</t>
</section> </section>
<section anchor="haptic-sub-type-in-use"><name>Haptic Data Formats in Use <section anchor="haptic-sub-type-in-use"><name>Haptic Data Formats in Use
</name> </name>
<!-- [rfced] The text indicates the the subtypes have not been registered by IAN
A, but ivs is being registered by this document. Please consider whether update
s are needed. Is it correct that ivs is the only type mentioned in Section 2.5
being registered at this time?
Note: likely different, but we see ogg has been registered as an application sub
type (see https://www.iana.org/assignments/media-types/application/ogg).
Original:
While these subtypes have *not* been registered with IANA or
standardized (yet), the prevalence of these haptic data formats in a
large number of devices around the world, pre-dating the
standardization of haptic tracks in ISOBMFF, provides a compelling
argument for 'haptics' to be designated as a top-level media type:
Perhaps remove mention of "not been registered with IANA?
While these subtypes have *not* been standardized (yet),
the prevalence of these haptic data formats in a
large number of devices around the world, pre-dating the
standardization of haptic tracks in ISOBMFF, provides a compelling
argument for 'haptics' to be designated as a top-level media type:
-->
<t> <t>
There are multiple instances of existing haptic data formats There are multiple instances of existing haptic data formats
that will live as sub-types under the proposed 'haptics' top-level media type. that will live as sub-types under the proposed 'haptics' top-level media type.
While these subtypes have *not* been registered with IANA or standardized While these subtypes have *not* been registered with IANA or standardized
(yet), the prevalence of these haptic data formats in a large number of (yet), the prevalence of these haptic data formats in a large number of
devices around the world, pre-dating the standardization of haptic tracks devices around the world, pre-dating the standardization of haptic tracks
in ISOBMFF, provides a compelling argument for 'haptics' to be in ISOBMFF, provides a compelling argument for 'haptics' to be
designated as a top-level media type:</t> designated as a top-level media type:</t>
<ul> <ul>
<li>'ahap': The AHAP haptic data format <xref target="AHAP"></xref> is currently the standard <li>'ahap': The AHAP haptic data format <xref target="AHAP"></xref> is currently the standard
encoding on all iOS devices + iOS connected game peripherals. The format has encoding on all iOS devices + iOS connected game peripherals. The format has
seen usage and adoption beyond Apple devices as well, with decoders available seen usage and adoption beyond Apple devices as well, with decoders available
for Android and other XR systems.</li> for Android and other XR systems.</li>
<li>'ogg': Google has introduced a proprietary extension to the OGG format <li>'ogg': Google has introduced a proprietary extension to the OGG format
in the latest version of Android 11. This encoding enables haptic media to be in the latest version of Android 11. This encoding enables haptic media to be
stored in OGG files.</li> stored in OGG files.</li>
<li><t>'ivs': The IVS haptic data format [MPEG-Haptics-Encoder] is in use:</t> <li><t>'ivs': The IVS haptic data format <xref target="MPEG-Haptics-Encoder"/> i s in use:</t>
<ul> <ul>
<li>In mobile phones from LG Electronics (specifically, the models V30, <li>In mobile phones from LG Electronics (specifically, the models V30,
V40, and the newest V50) that are sold worldwide</li> V40, and the newest V50) that are sold worldwide</li>
<li>In gaming phones from ASUS (specifically, models ROG, ROG Phone II, <li>In gaming phones from ASUS (specifically, models ROG, ROG Phone II,
ROG Phone 3) that are sold worldwide</li> ROG Phone 3) that are sold worldwide</li>
</ul> </ul>
</li> </li>
<li><t>'hapt': The HAPT haptic data format is currently a vendor-specific format that is in use:</t> <li><t>'hapt': The HAPT haptic data format is currently a vendor-specific format that is in use:</t>
<ul> <ul>
<li>In mobile haptic advertising (for W3C devices)</li> <li>In mobile haptic advertising (for W3C devices)</li>
<li><t>The following Japanese game developers use the HAPT format as part <li><t>The following Japanese game developers use the HAPT format as part
of Immersion's TouchSense SDK:</t> of Immersion's TouchSense SDK:</t>
<ul> <ul>
<li>KLAB: <eref target="https://www.klab.com/en/">https://www.klab.com/en/</eref <li>KLAB: <eref target="https://www.klab.com/en/" /></li>
></li> <li>Craft&amp;Meister: <eref target="http://www.crafts-meister.co.jp/pc/company_
<li>Craft&amp;Meister: <eref target="http://www.crafts-meister.co.jp/pc/company_ en.html" /></li>
en.html">http://www.crafts-meister.co.jp/pc/company_en.html</eref></li>
</ul> </ul>
</li> </li>
<li>Tencent is using the TouchSense SDK for their popular social media <li>Tencent is using the TouchSense SDK for their popular social media
application QQ and live streaming application NOW: application QQ and live streaming application NOW: Immersion-Announces-Tencent-L
<eref target="https://www.businesswire.com/news/home/20171026006443/en/Immersion icenses-TouchSense-Technology-Deliver
-Announces-Tencent-Licenses-TouchSense%C2%AE-Technology-Deliver">Immersion-Annou (<eref target="https://www.businesswire.com/news/home/20171026006443/en/Immersio
nces-Tencent-Licenses-TouchSense-Technology-Deliver</eref></li> n-Announces-Tencent-Licenses-TouchSense%C2%AE-Technology-Deliver" />)</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>Given the widespread use of these subtypes, it makes sense for 'haptics' <t>Given the widespread use of these subtypes, it makes sense for 'haptics'
to be a top-level media type.</t> to be a top-level media type.</t>
</section> </section>
<section anchor="haptic-sub-types-envisioned-standards"><name>Haptic Subtypes (e <section anchor="haptic-sub-types-envisioned-standards"><name>Haptic Subtypes (E
nvisioned standards)</name> nvisioned Standards)</name>
<!-- [rfced] hmpg and hjif are being registered by this document. Please consid
er how this text can be updated for accuracy.
Original:
These
codes are not registered yet, but the plan is indeed to standardize
these haptic coding formats in the near future. Once standardized,
these types should also be registered as subtypes of the 'haptics'
top-level media type:
-->
<!-- [rfced] For ease of the reader, we have updated "FourCC codes" as "FourCCs
(four-character codes)". Alternatively, may we replace "FourCC" with "four-char
acter codes", because this is the only place FourCC is used? Please review.
Original:
The MPEG ISOBMFF proposal included an informative annex of known
haptic coding formats with proposed FourCC codes for them.
Current:
The MPEG ISOBMFF proposal included an informative annex of known
haptic coding formats with proposed FourCCs (four-character codes)
for them.
-->
<t> <t>
The MPEG ISOBMFF proposal included an informative annex of known haptic The MPEG ISOBMFF proposal included an informative annex of known haptic
coding formats with proposed FourCC codes for them. These codes are not coding formats with proposed FourCCs (four-character codes) for them. These code s are not
registered yet, but the plan is indeed to standardize these haptic registered yet, but the plan is indeed to standardize these haptic
coding formats in the near future. Once standardized, these types should also be registered as subtypes of the 'haptics' top-level media type:</t> coding formats in the near future. Once standardized, these types should also be registered as subtypes of the 'haptics' top-level media type:</t>
<ul> <ul>
<li>'hmpg': the MPEG-I haptics streamable binary coding format described in ISO/ IEC DIS 23090-31: Haptics coding <xref target="MPEG-Haptics-Coding"></xref> </li > <li>'hmpg': the MPEG-I haptics streamable binary coding format described in ISO/ IEC DIS 23090-31: Haptics coding <xref target="MPEG-Haptics-Coding"></xref> </li >
<li>'hjif': the MPEG-I haptics JSON-based interchange format described in ISO/IE C DIS 23090-31: Haptics coding <xref target="MPEG-Haptics-Coding"></xref> </li> <li>'hjif': the MPEG-I haptics JSON-based interchange format described in ISO/IE C DIS 23090-31: Haptics coding <xref target="MPEG-Haptics-Coding"></xref> </li>
<li>IEEE P1918.1.1 vibrotactile coding standard <xref target="IEEE-P191811"></xr <!-- [rfced] Should "URLL" be "URLLC"? If correct, may we expand URLLC as "Ultr
ef> being developed under the IEEE Tactile a-Reliable Low-Latency Communication (URLLC)"? If not, please indicate how URLL
should be expanded.
Original:
* IEEE P1918.1.1 vibrotactile coding standard [IEEE-P191811] being
developed under the IEEE Tactile Internet initiative as part of
the 5G URLL profile.
-->
<li>IEEE P1918.1.1 vibrotactile coding standard <xref target="IEEE-191811"></xre
f> being developed under the IEEE Tactile
Internet initiative as part of the 5G URLL profile. Format name is yet to be fin alized. </li> Internet initiative as part of the 5G URLL profile. Format name is yet to be fin alized. </li>
<li>Enumerated effects haptic coding format (based on MIDI). Format name is yet to be finalized.</li> <li>Enumerated effects haptic coding format (based on MIDI). Format name is yet to be finalized.</li>
<li>Audio-to-vibe haptic coding format (automatic audio <li>Audio-to-vibe haptic coding format (automatic audio-to-vibration conversion
to vibration conversion algorithms). Format name is yet to be finalized.</li> algorithms). Format name is yet to be finalized.</li>
</ul> </ul>
</section> </section>
<section anchor="application-top-level-type-not-suitable"><name>'application' to p-level type not suitable</name> <section anchor="application-top-level-type-not-suitable"><name>'application' To p-Level Type Not Suitable</name>
<t>From the above arguments, it is clear that haptics does not really <t>From the above arguments, it is clear that haptics does not really
belong under any other media type. To reiterate, there are three main reasons belong under any other media type. To reiterate, there are three main reasons
why the 'haptics' media type does not fit under the 'application' top-level why the 'haptics' media type does not fit under the 'application' top-level
type:</t> type:</t>
<ul> <ul>
<li>haptics connects to a sensory system, touch/motion, directly, and is <li>haptics connects to a sensory system, touch/motion, directly, and is
more specific than the abstract 'application' type, and</li> more specific than the abstract 'application' type, and</li>
<li>'application' has historically been used for applications, i.e., code, <li>'application' has historically been used for applications, i.e., code,
which means it is viewed and treated with great care for security. which means it is viewed and treated with great care for security.
'haptics' is not code, just as 'audio' and 'video' are not code 'haptics' is not code, just as 'audio' and 'video' are not code
skipping to change at line 237 skipping to change at line 350
different media rendering instructions intended to be decoded and rendered different media rendering instructions intended to be decoded and rendered
on target device hardware. Haptic data can be represented as collections on target device hardware. Haptic data can be represented as collections
of signal data and/or descriptive text in XML/JSON or a similar format. Signal d ata of signal data and/or descriptive text in XML/JSON or a similar format. Signal d ata
is typically not executed by endpoint processors and represents minimal is typically not executed by endpoint processors and represents minimal
security risk. Descriptive text is typically parsed and represented security risk. Descriptive text is typically parsed and represented
in memory using standard XML data structures. This data is utilized in memory using standard XML data structures. This data is utilized
to construct one or more signals that are sent to the endpoint device to construct one or more signals that are sent to the endpoint device
hardware.</t> hardware.</t>
<t> <t>
Because of the media/rendering nature of the data path for haptic coded Because of the media/rendering nature of the data path for haptic-coded
data the security profile of haptic data is expected to be largely data, the security profile of haptic data is expected to be largely
consistent with the security profile of visual and audio media data.</t> consistent with the security profile of visual and audio media data.</t>
<t> <t>
As with any synthesized media data (audio, video, and haptics), there As with any synthesized media data (audio, video, and haptics), there
is a security risk associated with execution of commands based on the is a security risk associated with execution of commands based on the
descriptive encoding either through its inherent extensibility or descriptive encoding either through its inherent extensibility or
through the insertion of arbitrary executable data in the descriptive through the insertion of arbitrary executable data in the descriptive
format itself. Indeed, media rendering systems are normally implemented format itself. Indeed, media rendering systems are normally implemented
with a mix of user and kernel space execution since these media must with a mix of user and kernel space execution since these media must
ultimately make their way to a hardware system. In theory, malicious ultimately make their way to a hardware system. In theory, malicious
skipping to change at line 267 skipping to change at line 380
surfaces for malicious payloads.</t> surfaces for malicious payloads.</t>
<t> <t>
Thermal haptic devices (that provide a sensation of heat) and kinesthetic haptic devices (that provide force feedback) could potentially injure users if the hea t or force, respectively, are not properly controlled or inadvertently exceed sa fety levels. Implementors need to ensure that adequate measures are taken to pre vent such scenarios.</t> Thermal haptic devices (that provide a sensation of heat) and kinesthetic haptic devices (that provide force feedback) could potentially injure users if the hea t or force, respectively, are not properly controlled or inadvertently exceed sa fety levels. Implementors need to ensure that adequate measures are taken to pre vent such scenarios.</t>
<t> <t>
These security considerations apply to the subtype registrations described in th is document as well as all future haptics registrations.</t> These security considerations apply to the subtype registrations described in th is document as well as all future haptics registrations.</t>
</section> </section>
<section anchor="iana-considerations"><name>IANA Considerations</name> <section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This specification registers a new top-level type, 'haptics', <t>IANA has registered 'haptics' in the "Top-Level Media Types" registry
and requests IANA to add it to the registry of top-level types specified in <xre defined in <xref target="RFC9694"></xref> and registered several subtypes. IANA
f target="TOPLEVEL"></xref>, adds it as an alternative value of has also added 'haptics' as an alternative value of
&quot;Type Name&quot; in the media types registration form <xref target="Media-T &quot;Type Name&quot; in the media types registration form <xref target="Media-T
ype-Registration"></xref>, ype-Reg"></xref>.
and registers several subtypes for it.</t> </t>
<section anchor="definition-and-encoding"><name>Definition and Encoding</name> <section anchor="definition-and-encoding"><name>Definition and Encoding</name>
<t>'haptics' as the primary media content type indicates that the <t>'haptics' is the primary media content type that indicates the
content identified by it requires a certain haptics subsystem such content identified by it requires a certain haptics subsystem such
as low-level haptics APIs, which in turn will require hardware as low-level haptics APIs, which in turn will require hardware
capabilities such as one or more actuators to render the haptics media. capabilities such as one or more actuators to render the haptics media.
The 'haptics' media type does not provide any specific information The 'haptics' media type does not provide any specific information
about the underlying data format and how the haptics information should about the underlying data format and how the haptics information should
be interpreted -- the subtypes defined within a 'haptics' tree name be interpreted -- the subtypes defined within a 'haptics' tree name
the specific haptic formats. Unrecognized subtypes of 'haptics' the specific haptic formats. Unrecognized subtypes of 'haptics'
should be treated as 'application/octet-stream'. Implementations should be treated as 'application/octet-stream'. Implementations
may still pass unrecognized subtypes to the haptics subsystem and may still pass unrecognized subtypes to the haptics subsystem and
associated rendering hardware.</t> associated rendering hardware.</t>
</section> </section>
<section anchor="registration-procedure"><name>Registration Procedure</name> <section anchor="registration-procedure"><name>Registration Procedure</name>
<t>New haptics formats should be registered using the online form <t>New haptics formats should be requested using the Application for a Media Typ
<xref target="Media-Type-Registration"></xref>. <xref target="RFC6838"></xref> e online form
should be consulted on <xref target="Media-Type-Reg"></xref>. <xref target="RFC6838"></xref> should be
consulted on
registration procedures. In particular, the haptics specification registration procedures. In particular, the haptics specification
should preferably be freely available.</t> should preferably be freely available.</t>
<t> <t>
Note that new subtypes may define parameters. If Note that new subtypes may define parameters. If
an implementation does not recognize a parameter sub-value in the comma- an implementation does not recognize a parameter sub-value in the comma-separate
separated list, it should ignore the sub-value and continue d list, it should ignore the sub-value and continue
processing the other sub-values in the list.</t> processing the other sub-values in the list.</t>
</section> </section>
<section anchor="subtype-registrations"><name>Subtype Registrations</name> <section anchor="subtype-registrations"><name>Subtype Registrations</name>
<t> <t>
In this section, the initial entries under the top-level 'haptics' In this section, the initial entries under the top-level 'haptics'
media type are specified. They also serve as examples for future media type are specified. They also serve as examples for future
registrations.</t> registrations.</t>
<section anchor="ivs-haptics-type"><name>IVS Haptics Type</name> <section anchor="ivs-haptics-type"><name>IVS Haptics Type</name>
<t>Type name: haptics</t> <dl newline="false">
<t>Subtype name: ivs</t> <dt>Type name:</dt> <dd>haptics</dd>
<t>Required parameters: N/A</t> <dt>Subtype name:</dt> <dd>ivs</dd>
<t>Optional parameters: N/A</t> <dt>Required parameters:</dt> <dd>N/A</dd>
<t>Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32</t> <dt>Optional parameters:</dt> <dd>N/A</dd>
<t>Interoperability considerations: The IVS format is a device-independent hapti <dt>Encoding considerations:</dt> <dd>8bit if UTF-8; binary if UTF-16 or UTF-32<
c effect coding based on the XML format. It is designed to enable interoperabili /dd>
ty between distinct physical endpoints. Not all devices may be able to render al <dt>Interoperability considerations:</dt> <dd>The IVS format is a device-indepen
l effects present in an IVS file.</t> dent haptic effect coding based on the XML format. It is designed to enable inte
<t>Security considerations: See Section 3 of RFC XXXX.</t> roperability between distinct physical endpoints. Not all devices may be able to
<t>[Note to RFC Editor: Please replace XXXX with the number of this RFC.]</t> render all effects present in an IVS file.</dd>
<t>Published specification: ISO/IEC JTC 1/SC 29/WG 2 N 0072 "Encoder Input Form <dt>Security considerations:</dt> <dd>See <xref target="security-considerations"
at for MPEG Haptics" <xref target="MPEG-Haptics-Encoder"></xref>.</t> /> of RFC 9695.</dd>
<t>Applications that use this media type: All applications that are able to cre <dt>Published specification:</dt> <dd> ISO/IEC JTC 1/SC 29/WG 2 N0072 "Encoder I
ate, edit, or display haptic media content.</t> nput Format for MPEG Haptics" <xref target="MPEG-Haptics-Encoder"></xref>.</dd>
<t>Additional information:</t> <dt>Applications that use this media type:</dt> <dd>All applications that are ab
<ul> le to create, edit, or display haptic media content.</dd>
<li>File extension(s): Haptic file extensions used for IVS files: .ivs</li> </dl>
<li>Macintosh file type code(s): (no code specified)</li> <dl newline="true">
<li>Macintosh Universal Type Identifier code: N/A</li> <dt>Additional information:</dt>
<li>Fragment Identifier: N/A</li> <dd><dl newline="false" spacing="compact">
<li>Deprecated Alias: N/A</li> <dt>File extension(s):</dt> <dd>Haptic file extensions used for IVS files: .
</ul> ivs</dd>
<t>Person &amp; email address to contact for further information: Yeshwant Muthu <dt>Macintosh file type code(s):</dt> <dd>(no code specified)</dd>
samy(yeshwant@yeshvik.com)</t> <dt>Macintosh Universal Type Identifier code:</dt> <dd>N/A</dd>
<t>Change controller: ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Haptic Codin <dt>Fragment Identifier:</dt> <dd>N/A</dd>
g)</t> <dt>Deprecated Alias:</dt> <dd>N/A</dd>
</dl>
</dd>
</dl>
<dl newline="false">
<dt>Person &amp; email address to contact for further information:</dt> <dd><br/
>Yeshwant Muthusamy(yeshwant@yeshvik.com)</dd>
<dt>Change controller:</dt> <dd>ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Ha
ptic Coding)</dd>
</dl>
</section> </section>
<section anchor="hjif-haptics-type"><name>HJIF Haptics Type</name> <section anchor="hjif-haptics-type"><name>HJIF Haptics Type</name>
<t>Type name: haptics</t> <dl newline="false">
<t>Subtype name: hjif</t> <dt>Type name:</dt> <dd>haptics</dd>
<t>Required parameters: N/A</t> <dt>Subtype name:</dt> <dd>hjif</dd>
<t>Optional parameters: N/A</t> <dt>Required parameters:</dt> <dd>N/A</dd>
<t>Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32</t> <dt>Optional parameters:</dt> <dd>N/A</dd>
<t>Interoperability considerations: The HJIF format is a human-readable haptic e <dt>Encoding considerations:</dt> <dd>8bit if UTF-8; binary if UTF-16 or UTF-32<
ffect coding based on the JSON format. It is designed as an interchange format f /dd>
or temporal and spatial haptic effects. The haptic effects may target specific p <dt>Interoperability considerations:</dt> <dd>The HJIF format is a human-readabl
arts of the human body and may be associated with a reference device description e haptic effect coding based on the JSON format. It is designed as an interchang
allowing haptic rendering software to adapt the effects to available hardware.< e format for temporal and spatial haptic effects. The haptic effects may target
/t> specific parts of the human body and may be associated with a reference device d
<t>Security considerations: See Section 3 of RFC XXXX.</t> escription allowing haptic rendering software to adapt the effects to available
<t>[Note to RFC Editor: Please replace XXXX with the number of this RFC.]</t> hardware.</dd>
<t>Published specification: ISO/IEC DIS 23090-31: Haptics coding <xref target=" <dt>Security considerations:</dt> <dd>See <xref target="security-considerations"
MPEG-Haptics-Coding"></xref>.</t> /> of RFC 9695.</dd>
<t>Applications that use this media type: All applications that are able to cre
ate, edit, or display haptic media content.</t> <dt>Published specification:</dt> <dd>ISO/IEC DIS 23090-31: Haptics coding <xre
<t>Additional information:</t> f target="MPEG-Haptics-Coding"></xref>.</dd>
<ul> <dt>Applications that use this media type:</dt> <dd>All applications that are ab
<li>File extension(s): Haptic file extensions used for HJIF files: .hjif</li le to create, edit, or display haptic media content.</dd>
> </dl>
<li>Macintosh file type code(s): (no code specified)</li> <dl newline="true" spacing="normal">
<li>Macintosh Universal Type Identifier code: N/A</li> <dt>Additional information:</dt>
<li>Fragment Identifier: N/A</li> <dd><dl newline="false" spacing="compact">
<li>Deprecated Alias: N/A</li> <dt>File extension(s):</dt> <dd>Haptic file extensions used for HJIF files:
</ul> .hjif</dd>
<t>Person &amp; email address to contact for further information: Yeshwant Muthu <dt>Macintosh file type code(s):</dt> <dd>(no code specified)</dd>
samy(yeshwant@yeshvik.com)</t> <dt>Macintosh Universal Type Identifier code:</dt> <dd>N/A</dd>
<t>Change controller: ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Haptic Codin <dt>Fragment Identifier:</dt> <dd>N/A</dd>
g)</t> <dt>Deprecated Alias:</dt> <dd>N/A</dd>
</dl></dd></dl>
<dl newline="false" spacing="normal">
<dt>Person &amp; email address to contact for further information:</dt> <dd><br/
>Yeshwant Muthusamy(yeshwant@yeshvik.com)</dd>
<dt>Change controller:</dt> <dd>ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Ha
ptic Coding)</dd>
</dl>
</section> </section>
<section anchor="hmpg-haptics-type"><name>HMPG Haptics Type</name> <section anchor="hmpg-haptics-type"><name>HMPG Haptics Type</name>
<t>Type name: haptics</t> <dl newline="false" spacing="normal">
<t>Subtype name: hmpg</t> <dt>Type name:</dt> <dd>haptics</dd>
<t>Required parameters: N/A</t> <dt>Subtype name:</dt> <dd>hmpg</dd>
<t>Optional parameters: N/A</t> <dt>Required parameters:</dt> <dd>N/A</dd>
<t>Encoding considerations: binary</t> <dt>Optional parameters:</dt> <dd>N/A</dd>
<t>Interoperability considerations: The HMPG format is a streamable binary hapti <dt>Encoding considerations:</dt> <dd>binary</dd>
c effect coding. It is designed to enable efficient coding of temporal and spati <dt>Interoperability considerations:</dt> <dd>The HMPG format is a streamable bi
al haptic effects. The haptic effects may target specific parts of the human bod nary haptic effect coding. It is designed to enable efficient coding of temporal
y and may be associated with a reference device description allowing haptic rend and spatial haptic effects. The haptic effects may target specific parts of the
ering software to adapt the effects to available hardware. </t> human body and may be associated with a reference device description allowing h
<t>Security considerations: See Section 3 of RFC XXXX.</t> aptic rendering software to adapt the effects to available hardware. </dd>
<t>[Note to RFC Editor: Please replace XXXX with the number of this RFC.]</t> <dt>Security considerations:</dt> <dd>See <xref target="security-considerations"
<t>Published specification: ISO/IEC DIS 23090-31: Haptics coding <xref target=" />
MPEG-Haptics-Coding"></xref>.</t> of RFC 9695.</dd>
<t>Applications that use this media type: All applications that are able to cre
ate, edit, or display haptic media content.</t> <dt>Published specification:</dt> <dd>ISO/IEC DIS 23090-31: Haptics coding <xre
<t>Additional information:</t> f target="MPEG-Haptics-Coding"></xref>.</dd>
<ul> <dt>Applications that use this media type:</dt> <dd>All applications that are a
<li>File extension(s): Haptic file extensions used for HMPG files: .hmpg</li ble to create, edit, or display haptic media content.</dd>
> </dl>
<li>Macintosh file type code(s): (no code specified)</li> <dl newline="true" spacing="normal">
<li>Macintosh Universal Type Identifier code: N/A</li> <dt>Additional information:</dt>
<li>Fragment Identifier: N/A</li> <dd><dl newline="false" spacing="compact">
<li>Deprecated Alias: N/A</li> <dt>File extension(s):</dt> <dd>Haptic file extensions used for HMPG files:
</ul> .hmpg</dd>
<t>Person &amp; email address to contact for further information: Yeshwant Muthu <dt>Macintosh file type code(s):</dt> <dd>(no code specified)</dd>
samy(yeshwant@yeshvik.com)</t> <dt>Macintosh Universal Type Identifier code:</dt> <dd>N/A</dd>
<t>Change controller: ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Haptic Codin <dt>Fragment Identifier:</dt> <dd>N/A</dd>
g)</t> <dt>Deprecated Alias:</dt> <dd>N/A</dd>
</dl></dd></dl>
<dl newline="false" spacing="normal">
<dt>Person &amp; email address to contact for further information:</dt> <dd><br/
>Yeshwant Muthusamy(yeshwant@yeshvik.com)</dd>
<dt>Change controller:</dt> <dd>ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Ha
ptic Coding)</dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references><name>Normative References</name> <references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"
xml"/> />
<reference anchor="TOPLEVEL" target="https://datatracker.ietf.org/doc/draft-ietf
-mediaman-toplevel/03/"> <!-- [I-D.ietf-mediaman-toplevel] RFC 9694 -->
<reference anchor="RFC9694" target="https://www.rfc-editor.org/info/rfc9694">
<front> <front>
<title>Guidelines for the Definition of New Top-Level Media Types</title> <title>Guidelines for the Definition of New Top-Level Media Types</title>
<author initials="M. J." surname="Dürst" fullname="Martin J. Dürst"> <author initials="M." surname="Dürst" fullname="Martin J. Dürst">
<organization>Aoyama Gakuin University</organization> <organization>Aoyama Gakuin University</organization>
</author> </author>
<date month="March" day="26" year="2023"/> <date month="December" year="2024"/>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mediaman-toplevel-03"/> <seriesInfo name="RFC" value="9694"/>
<seriesInfo name="DOI" value="10.17487/RFC9694"/>
</reference> </reference>
</references> </references>
<references><name>Informative References</name> <references><name>Informative References</name>
<!-- [rfced] [ISOBMFF-IS] This reference is the most current
version of this standard, but there is a note on this version that states
"Expected to be replaced by ISO/IEC DIS 14496-12.2 within the coming
months." Please let us know if publication of this document should be delayed u
ntil
ISO/IEC DIS 14496-12.2 is formally published (see https://www.iso.org/standard/8
5596.html).
Original:
[ISOBMFF-IS]
"ISO/IEC 14496-12 (7th Edition) Information technology —
Coding of audio-visual objects — Part 12: ISO base media
file format", <https://www.iso.org/standard/83102.html>.
-->
<reference anchor="ISOBMFF-IS" target="https://www.iso.org/standard/83102.html"> <reference anchor="ISOBMFF-IS" target="https://www.iso.org/standard/83102.html">
<front> <front>
<title>ISO/IEC 14496-12 (7th Edition) Information technology — Coding of aud <title>Information technology - Coding of audio-visual objects - Part 12: IS
io-visual objects — Part 12: ISO base media file format</title> O base media file format</title>
<author/> <author>
<date/> <organization>ISO/IEC</organization>
</author>
<date month="January" year="2022"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="14496-12:2022"/>
<refcontent>7th Edition</refcontent>
</reference> </reference>
<reference anchor="MPEG-Haptics-Encoder" target="https://www.mpegstandards.org/s tandards/Explorations/40/"> <reference anchor="MPEG-Haptics-Encoder" target="https://www.mpegstandards.org/s tandards/Explorations/40/">
<front> <front>
<title>Encoder Input Format for MPEG Haptics</title> <title>Encoder Input Format for Haptics</title>
<author/> <author>
<date/> <organization>MPEG</organization>
</author>
<date day="15" month="May" year="2021"/>
</front> </front>
<refcontent>MPEG 134 Meeting Document</refcontent>
</reference> </reference>
<reference anchor="AHAP" target="https://developer.apple.com/documentation/coreh aptics/representing_haptic_patterns_in_ahap_files"> <reference anchor="AHAP" target="https://developer.apple.com/documentation/coreh aptics/representing_haptic_patterns_in_ahap_files">
<front> <front>
<title>Apple Haptic Audio Pattern</title> <title>Representing haptic patterns in AHAP files</title>
<author/> <author>
<date/> <organization>Apple Inc.</organization>
</author>
</front> </front>
<refcontent>Apple Developer Documentation</refcontent>
</reference> </reference>
<reference anchor="MPEG-Haptics-Coding" target="https://www.iso.org/standard/861 22.html"> <reference anchor="MPEG-Haptics-Coding" target="https://www.iso.org/standard/861 22.html">
<front> <front>
<title>ISO/IEC DIS 23090-31 Information Technology — Coded representation of <title>Information Technology -- Coded representation of immersive media --
immersive media — Part 31: Haptics coding</title> Part 31: Haptics coding</title>
<author/> <author>
<date/> <organization>ISO/IEC</organization>
</author>
</front> </front>
<seriesInfo name="ISO/IEC" value="FDIS 23090-31"/>
<refcontent>Final Draft International Standard</refcontent>
</reference> </reference>
<reference anchor="W3C-Vibration" target="https://www.w3.org/TR/vibration/">
<reference anchor="W3C-Vibration" target="https://www.w3.org/TR/2016/REC-vibrati
on-20161018/">
<front> <front>
<title>W3C Vibration API (Second Edition)</title> <title>Vibration API (Second Edition)</title>
<author/> <author>
<date/> <organization>W3C</organization>
</author>
<date day="18" month="October" year="2016"/>
</front> </front>
<refcontent>W3C Recommendation</refcontent>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/vi
bration/" brackets="angle"/></annotation>
</reference> </reference>
<reference anchor="W3C-Gamepad" target="https://w3c.github.io/gamepad/extensions .html"> <reference anchor="W3C-Gamepad" target="https://w3c.github.io/gamepad/extensions .html">
<front> <front>
<title>W3C Gamepad Extensions</title> <title>Gamepad Extensions</title>
<author/> <author>
<date/> <organization>W3C</organization>
</author>
<date day="9" month="August" year="2024"/>
</front> </front>
<refcontent>W3C Editor's Draft</refcontent>
<annotation>Latest version available at <eref target="https://w3c.github.io/ga
mepad/extensions.html" brackets="angle"/></annotation>
</reference> </reference>
<reference anchor="IEEE-P191811" target="https://standards.ieee.org/project/1918
_1_1.html"> <!-- [rfced] [IEEE-P191811] The original URL redirected to the
search page for IEEE Standards: https://standards.ieee.org/standard/.
We have updated the reference as described on
https://ieeexplore.ieee.org/document/10555007. The status is marked as "Inactiv
e - Draft". Please review and let us know if any updates are needed.
[IEEE-P191811]
"P1918.1.1 - Haptic Codecs for the Tactile Internet",
<https://standards.ieee.org/project/1918_1_1.html>.
-->
<reference anchor="IEEE-191811" target="https://ieeexplore.ieee.org/document/100
42202">
<front> <front>
<title>P1918.1.1 - Haptic Codecs for the Tactile Internet</title> <title>IEEE Draft Standard for Haptic Codecs for the Tactile Internet</title
<author/> >
<date/> <author>
<organization>IEEE</organization>
</author>
<date month="March" year="2023"/>
</front> </front>
<seriesInfo name="IEEE" value="P1918.1.1/D3"/>
</reference> </reference>
<reference anchor="Media-Type-Registration" target="http://www.iana.org/form/med <!-- old reference
ia-types"> Note to PE: If authors accept changes, I recommend changing the cite tag from
[IEEE-P191811] to [IEEE-191811] or something similar. XML for the draft
standard if the authors object to the update:
<reference anchor="IEEE-P191811" target="https://ieeexplore.ieee.org/document/10
555007">
<front> <front>
<title>IANA, Application for a Media Type</title> <title>IEEE Standard for Haptic Codecs for the Tactile Internet</title>
<author/> <author>
<date/> <organization>IEEE</organization>
</author>
<date month="June" year="2024"/>
</front>
<seriesInfo name="IEEE Std" value="1918.1.1-2024"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2024.10555007"/>
</reference>-->
<reference anchor="Media-Type-Reg" target="http://www.iana.org/form/media-types"
>
<front>
<title>Application for a Media Type</title>
<author>
<organization>IANA</organization>
</author>
</front> </front>
</reference> </reference>
</references> </references>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the following should be updated:
native
Perhaps "built-in" would work?
-->
</back> </back>
</rfc> </rfc>
 End of changes. 61 change blocks. 
200 lines changed or deleted 439 lines changed or added

This html diff was produced by rfcdiff 1.48.