Re: [dispatch] [art] Status of Haptics I-D in DISPATCH?

[Yeshwant Muthusamy <[e-mail]>]

Ned,



Thanks for the note. My comments inline below, prefaced by ‘[YKM]’.



Regards,

Yeshwant



Yeshwant Muthusamy, Ph.D. | Senior Director, Standards



[e-mail] | [phone]



-----Original Message-----
From: Ned Freed <[e-mail]>
Sent: Monday, May 3, 2021 1:30 PM
To: Yeshwant Muthusamy <[e-mail]>
Cc: Ted Hardie <[e-mail]>; Ned Freed <[e-mail]>; Dispatch WG <[e-mail]>; [e-mail]; Applications and Real-Time Area Discussion <[e-mail]>; ART ADs <[e-mail]>; Claudio Allocchio <[e-mail]>; Francesca Palombini <francesca.palombini=[e-mail]>; [e-mail]
Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH?



> Folks,



> First off, glad to see some traffic on the haptics I-D. Thanks to

> Francesca for jump-starting the latest round of discussion.



> At the risk of sounding biased (as one of the authors of the I-D), I

> would second Ted’s latest proposal that we not overload the WG with

> other media type-related work, lest it end up de-prioritizing or

> delaying consideration of the haptics proposal.



This sort of thing is what WG charters are *for*. If the haptics work needs to come first, say that in the charter. If anything this increases the liklihood of your proposal getting some attention, because people interested in the other work items will be incentivized to help with the haptics work, in order to get to their items.



ADs have a vast array of things competing for their attention. WG chairs, not so much. As such, leaving your proposal as an AD-sponsored item is far less likely to produce timely results than doing it in a WG.

[[YKM]] Thanks for the explanation. I was not aware of the charter aspect. I was agreeing with Ted’s comment that a haptics-specific WG would be more expedient. Just for the record, at this point, I am completely OK with *ANY* of the three methods of progress being put forward by various commenters:

  1.  a haptics-specific focused WG,
  2.  a media-types WG, along the lines you have suggested, with a charter that prioritizes the haptics ID, or
  3.  AD sponsorship.

I will defer to the process experts on this list on the best way forward.



> I appreciate the importance of Ned’s list, but Ted is correct in that

> the time to get the haptics proposal reviewed (and hopefully, approved) is not unbounded.

> More on that below.



As I said before, not only are you talking about a new top-level type, you are talking about one that has the potential to interact with specific protocols, e.g., one that have specific slots for audio and video types where the top-level value is assumed, in complicated ways. As such, you are going to need involvment from a much wider range of people than you would for most of the other items on this list.

[[YKM]] Agreed. An RFC that is the result of a detailed review and robust discussion of all its implications is preferred, for obvious reasons.



> Setting aside the implications (inadvertent or otherwise) of Claudio’s

> comment that Apple or Google need to be on the authors list for IETF

> to even consider an ID  (or work on it expeditiously),  I would point

> to the following Draft Amendment of the ISO/IEC 14496-12 (ISO Base Media File Format) standard.

> It is the one that has our proposal to treat haptics as a top-level

> media type, akin to audio and video, in ISOBMFF files (like .mp4, .3gpp, etc.).



> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flink

> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso.org%252fst

> andard%252f81604.html%26c%3DE%2C1%2C-vk4rBtxMoK4ur1oekt8Obh00xBg8JJyrt

> r61SaxhHUXRJKNOFEFtcvO9JK3jxs0ntVdbZhfqdKhuMiHAGVKHTuSFeaeyjWVvObQv9Nl

> n9hQhzlmeRkG0A%2C%2C%26typo%3D1&amp;data=04%7C01%7C%7C45a931dec66449af

> 11ec08d90e66b02c%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C63755665

> 6481530290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI

> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=D%2FT08nJx%2BwXm%2FNc

> mIaqnTeVfg7a8PbuKsusVcobxpPk%3D&amp;reserved=0



> For those familiar with how MPEG works, a DAMD means that the proposal

> has gone through two rounds of balloting from various ISO National

> Bodies (including the US National Body). And yes, Apple and Google are

> indeed part of the US National Body 😊. We are happy to report that no

> objections were received to the haptics proposal in either the CD or

> DAMD ballot rounds from any of the 20+ National Bodies that voted on

> it. It has now moved to FDIS ballot (the haptics proposal having been

> merged with other updates to 14496-12 for a new 7th

> edition) that is expected to complete by July.



> MPEG has also issued a Call for Proposals on the Coded Representation

> of Haptics – Phase 1 at the just concluded MPEG134 meeting last week.

> The CfP seeks technologies that would help standardize a haptic coding

> format and a haptic decoder in MPEG. The press release and final CfP

> docs themselves should be available in a few days. Draft versions of

> the Haptics CfP documents from

> MPEG133 in January 2021 can be found here:

> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flink

> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.mpegstandards.

> org%252fstandards%252fExplorations%252f40%252f.%26c%3DE%2C1%2Cl1rsH_AU

> jXCnKF-OlTLsrJ4uP_kBdI7s21kYGwOfkdP3c9zs6X_JPYS-h1mgjsEGsnoRFp1_Q93IL8

> QSHYi5G5iwIdV6X6CQ6ghD763nawZq_g8%2C%26typo%3D1&amp;data=04%7C01%7C%7C

> 45a931dec66449af11ec08d90e66b02c%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C

> 0%7C0%7C637556656481530290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA

> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Gauah

> oAhke8VAqVolZNhzr5%2F3LTf%2Fh7iDS3LvN4vzsU%3D&amp;reserved=0



I could even begin to count the number of times I've been told that this or that is critical because of the actions of some other standards group, and for that reason the IETF needs to engage post haste. IME a common result of such pleas is to slow the work down, as people begin to argue about how the IETF should handle its interactions with other standards bodies, rather than focusing on the technical issues at hand.

[[YKM]] The point of providing those MPEG-related data points was not to accentuate any criticality as much as it was to update the IETF audience about the recent progress made in MPEG (the progress that has taken place since the I-D was last published in November 2020). As I’ve said before, I look forward to fielding comments on the technical merits of the content of the I-D.



                                                                Ned