Re: [media-types] WG Last call comments on draft-ietf-mediaman-haptics-03

[Yeshwant Muthusamy <[e-mail]>]

Hi Martin,

Thanks for taking the time to make these detailed comments. They are very helpful. The timing is also perfect since I am about to address Harald's comments to generate a v04 of the haptics I-D. Your comments will be addressed in that update as well.

I have done just a quick review of your email. No issues with most of your comments. Just like to respond to three that stand out. I might have more responses to others later:

>> Introduction: "Haptics is": Shouldn't this be "Haptics are"? Just checking.

Haptics is considerable an uncountable noun. The plural is the same as the singular form (https://www.wordhippo.com/what-is/the-plural-of/haptics.html#:~:text=The%20noun%20haptics%20is%20uncountable,of%20haptics%20is%20also%20haptics).

I like this characterization from Merriam-Webster (https://www.merriam-webster.com/dictionary/haptics), a decidedly more erudite source:

                'haptics' is plural in form but singular in construction.

So, "Haptics is" is indeed the correct form.

>>"Haptic signals provide an additional layer of entertainment and sensory immersion for the user.": In addition to what? Maybe say something like "Haptic
>>signals provide an different kind of entertainment and sensory immersion for the user than video or audio signals."

The intent was to say that haptics provides an additional layer of entertainment and sensory immersion for the user *to augment* the audio and video "layers". Just as we humans need hearing, vision, and touch to fully comprehend the world around us. It is not different so much as it is additive. I will wordsmith accordingly to get the original intent through.

>>"Haptic signals are also part of media streams that use RTP, such as those for streaming games, XR, and wearables.": I understand "streaming games" and
>>"streaming XR", but I don't understand "streaming wearables", because for me, wearables are devices, not (streamed) data.

If you read that sentence ("...such as those for..."), it is actually referring to media streams for wearables, not "streaming wearables" per se. Regardless, the intent here is to address the increasingly important use case of media content streaming to headsets (like the Meta Quest 3, Meta Quest Pro, and Apple Vision Pro). Headsets or Smart Glasses are indeed considered wearables.
[Aside: eagle-eyed technophiles might argue that while the Quest devices have top-notch haptic controllers, haptics was egregiously conspicuous by its absence from the Apple Vision Pro, but I suspect that deficiency will be addressed in the next version.]

I invite other members who might have been meaning to provide comments, to do so at their earliest convenience.

Thanks,
Yeshwant


Yeshwant Muthusamy, Ph.D. | Consulting CTO
[e-mail] | [phone]

http://www.immersion.com/
2999 N. E. 191st Street, Suite 610
Aventura, FL  33180



-----Original Message-----
From: media-types <[e-mail]> On Behalf Of Martin J. Dürst
Sent: Friday, July 21, 2023 4:56 AM
To: IETF mediaman WG <[e-mail]>
Subject: [media-types] WG Last call comments on draft-ietf-mediaman-haptics-03

I'm sorry these comments are late.

I think the draft is mostly ready to move on, but I have a few comments.
Some of the issues may already have been discussed.

The main issue is that the document is still written for the future, whereas the final document should be written so that future readers understand what has happened in the past. There are various locations in the document where that comes up. The rest is mostly improvement of language,...; everything is given in document order.

An example of this is this sentence in the abstract:
"This document also serves as a registration application for a set of intended subtypes...". This should read as follows:
"This document also serves as a registration for a set of subtypes..."

When writing a draft for the first time, it may seem a bit preposterous to write it as if approval had already happened, but if the document gets published (which I of course support), the approval will have happened. To some extent, the RFC production center may adjust this kind of language, but it's better to do it to save them some work.

Introduction: "Haptics is": Shouldn't this be "Haptics are"? Just checking.

"This document defines a new top-level type 'haptics' according to Section 4.2.7 of [RFC6838].": What actually happened was that we were developing new process (in draft-ietf-mediaman-toplevel) and trying that process out with the -haptics draft. If it wouldn't be for the -haptics draft, we wouldn't have worked on the -toplevel draft. So it should say "This document defines a new top-level type 'haptics' according to draft-ietf-mediaman-toplevel." For first-time draft/RFC authors, that may look strange, but the RFC editor will make sure that the reference to draft-ietf-mediaman-toplevel gets replaced with a reference to the resulting RFC. Publishing two or more RFCs at a time is part of their job, they do that quite often. If you want to help them, you can look at how I referenced the -haptics draft in the -toplevel draft, with RFC XXXX.

2. Background and Justification
"Haptic signals provide an additional layer of entertainment and sensory immersion for the user.": In addition to what? Maybe say something like "Haptic signals provide an different kind of entertainment and sensory immersion for the user than video or audio signals."

The reference to [ISOBMFF-IS] should appear on first mention of ISOBMFF, not later (i.e. before 2.1).

"Haptic signals are also part of media streams that use RTP, such as those for streaming games, XR, and wearables.": I understand "streaming games" and "streaming XR", but I don't understand "streaming wearables", because for me, wearables are devices, not (streamed) data.

"This proposal was made ... in April 2020": Would be good to have a reference.

"Therefore, designating 'haptics' as a top-level media type would enable" -> "Therefore, designating 'haptics' as a top-level media type enables" (the published RFC will actually enable this!)

"There are multiple instances of existing haptic data formats that would live as sub-types" -> "There are multiple instances of existing haptic data formats that would live as sub-types" -> "There are multiple instances of existing haptic data formats that will live as sub-types"
or "There are multiple instances of existing haptic data formats that should live as sub-types". (it would be even better if some of these came with actual registry information in this document so that they could be registered directly, but for that, it's maybe too late now.)

"Once standardized, they will also live as subtypes under the proposed 'haptics' top-level media type": I don't like the image of subtypes that live and die, so what about "Once standardized, these types should also be registered as subtypes of the 'haptics' top-level media type".

Subsections 2.5/2.6: These sections essentially reserve certain subtype names, but we shouldn't dictate (or looking like we dictate) the actual subtype names to other standardization bodies. If these labels are already pretty much a done deal, then it might be fine. Otherwise, leaving in the information about the data formats, but without the labels is safer.

3 Security considerations:

"in XML/JSON or similar format" -> "in XML/JSON or a similar format"

The document definitely should mention the potential danger of things such as burns (from heat-producing haptic devices) and injury (from force feedback devices). While properly configured devices and correct software shouldn't be able to produce such things, it's definitely something that implementers should watch out for.

4. IANA Considerations

"Note that new parameter sub-values may be defined in the future."
The haptics top-level type currently has no parameters defined at all.
I'd therefore reword this, e.g. as follows:
"Note that new subtypes may define parameters." But sounds a bit too simple.

[twice]: "Security considerations: See Section 3." -> "Security considerations: See Section 3 of RFC YYYY.
[note to RFC editor: Please replace YYYY with the number of this RFC."
(registration templates should be independent of their location)

"Published specification: ISO/IEC JTC 1/SC 29/WG 2 N 72 "Encoder Input Format for MPEG Haptics" being developed by ISO/IEC JTC1/SC29 WG 2 [MPEG-Haptics-Encoder]." vs. "Change controller: Immersion Corporation":
I know the question of change controller has come up in previous email conversations. I'm surprised that change control is left with a company although it's (intended as) part of an ISO standard. Som for 4.3.2.


I'm again sorry this is late. It may look like a lot, but most things should be very easy to fix.

I think that with these fixes, the document should be ready to be sent to the IESG.

Regards,    Martin.








_______________________________________________
media-types mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/media-types