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

["Martin J. Dürst" <[e-mail]>]

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.