Re: [media-types] [MEDIAMAN] Last Call response (NO) on draft-ietf-mediaman-haptics

[Yeshwant Muthusamy <[e-mail]>]

Hi Harald,



Regarding your comment:



>>- Section 4 does not ask IANA to register "haptics" in the top level registry (this is a side effect of referencing 6838).



It is not clear to me what my action here is; clearly I am missing something. Please bear with me.



This is what "Section 4. IANA Considerations" currently says:



This specification registers a new top-level type, 'haptics', in the

standards tree, adds it as an alternative value of "Type Name" in the

media types registration form [Media-Type-Registration], and

registers several subtypes for it.



What changes, if any, do I need to make to this prose? Or, were you suggesting that I add prose elsewhere in Section 4?



Please clarify.



Thanks,

Yeshwant



Yeshwant Muthusamy, Ph.D. | Consulting CTO

[e-mail] | [phone]



www.immersion.com

2999 N. E. 191st Street, Suite 610

Aventura, FL  33180







-----Original Message-----
From: Harald Alvestrand <[e-mail]>
Sent: Tuesday, July 18, 2023 4:58 PM
To: Yeshwant Muthusamy <[e-mail]>; [e-mail]
Subject: Re: [media-types] [MEDIAMAN] Last Call response (NO) on draft-ietf-mediaman-haptics



On 7/18/23 18:33, Yeshwant Muthusamy wrote:

> Hi Harald,

>

> Thanks for the valuable feedback.

>

> Regarding IVS, the specification has been divulged to MPEG and is effectively part of the ISO/IEC 23090-31 Haptic Coding standard (that is currently in DIS ballot and is expected to progress to FDIS - Final Draft International Standard at the October 2023 MPEG meeting). So making ISO the change controller for IVS is not an issue. Can make that change in v04 of the haptics I-D.

>

> Regarding HAPT, the specification has not been published anywhere and even if it were, having a vendor specification in a Standards Track RFC seems strange. Therefore, I would like to replace HAPT with either or both HMPG and HJIF - which are two haptic subtypes that are part of ISO/IEC 23090-31 DIS standard referenced above. HMPG is a binary streaming haptic format and HJIF is a JSON human-readable equivalent of HMPG.  When the haptics I-D draft was first published, these two subtypes were nothing more than a glint in my eye, hence could not include them. Now they are more mature and fleshed out and about to be part of an ISO standard, hence the change. Would this change satisfy your concern? I ask before taking the time to add these two subtype registrations to v04. The change controller for these new subtypes will be ISO.



Yes, that will satisfy my concern.

>

> Regarding referencing the TOPLEVEL procedure (that is currently under discussion in MEDIAMAN), what would the actual reference prose look like? Do I need to wait until it gets approved and gets a new RFC number, or do I just reference the latest toplevel I-D?



Just reference the toplevel I-D where you would otherwise use the RFC number. The RFC Editor will take care of replacing it. Remember to list it under normative references - if your doc reaches the RFC Editor before the -toplevel doc, the RFC Editor will hold it until the RFC number is available, and then substitute.



>

> I am fine with making the other non-substantive changes that you have raised.

>

> Would appreciate responses to my questions above at your earliest convenience so that I can get v04 ready in time for IETF 117.

>

> Thanks,

> Yeshwant

>

> Yeshwant Muthusamy, Ph.D. | Consulting CTO [e-mail]<mailto:[e-mail]> |

> [phone]

>

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

> protect.cudasvc.com%2Furl%3Fa%3Dhttp%253a%252f%252fwww.immersion.com%2

> 52f%26c%3DE%2C1%2CpBB4OqudvUJxQh1i2yMofC426_dEm1JBMkH-lLXwxovpMpRV-2DQ

> g3ms4g8a0u41ECN3MVd0xWw_HaFaTfrJOei6fc8pw2GKaKzNpLZKRPSBngvK%26typo%3D

> 1&data=05%7C01%7C%7Ccb3ed89b7215448efc4008db87da1a1f%7C4f05e41a59b8413

> aae19d5df3dfd0fb5%7C0%7C0%7C638253143094940215%7CUnknown%7CTWFpbGZsb3d

> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C

> 3000%7C%7C%7C&sdata=zb20%2Fg2BIb2OBKJiAQqSqjcwcyzeHIVFCM1NePYQ4Z0%3D&r

> eserved=0

> 2999 N. E. 191st Street, Suite 610

> Aventura, FL  33180

>

>

>

> -----Original Message-----

> From: media-types <[e-mail]<mailto:[e-mail]>> On Behalf Of Harald

> Alvestrand

> Sent: Tuesday, July 18, 2023 8:58 AM

> To: [e-mail]<mailto:[e-mail]>

> Subject: [media-types] [MEDIAMAN] Last Call response (NO) on

> draft-ietf-mediaman-haptics

>

> Apologies for the lateness of this response.

>

> I have read draft-ietf-mediaman-haptics -03, and I think it is NOT ready for publication as an RFC (or IETF Last Call).

>

> Two substantive issues:

>

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

> ub.com%2Fietf-wg-mediaman%2Fhaptics%2Fissues%2F4&data=05%7C01%7C%7Ccb3

> ed89b7215448efc4008db87da1a1f%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7

> C0%7C638253143094940215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC

> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qkQ

> J%2FzG79J%2BbNNoQ4hz7L6xlqUQsq5qXyc1gjR839UM%3D&reserved=0 - HAPT type

> definition needs more work (specification, name and change controller)

>

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

> ub.com%2Fietf-wg-mediaman%2Fhaptics%2Fissues%2F3&data=05%7C01%7C%7Ccb3

> ed89b7215448efc4008db87da1a1f%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7

> C0%7C638253143094940215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC

> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=C3L

> uzg56%2B9h75Z4NmQKHinZVwZdv1qgyu%2FqyqvQ4UaI%3D&reserved=0 - IVS type

> definition needs more work (specification and change controller)

>

> Once these are cleared up, I think the document is ready.

>

> Non-substantive issues that should also be cleared up while addressing the above:

>

> - Section 1 claims to register the subtype according to RFC 6838; it

> should be referencing [TOPLEVEL]

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

> hub.com%2Fietf-wg-mediaman%2Fhaptics%2Fissues%2F5&data=05%7C01%7C%7Ccb

> 3ed89b7215448efc4008db87da1a1f%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%

> 7C0%7C638253143094940215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL

> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eR

> PtIrQ1cDRyPGG4EB9gRh8u%2BbyVFAg10A%2FP9Qf1iZU%3D&reserved=0)

> - In section 3, the sentence starting "Ultimately, any coded representation..." adds no value and should be deleted.

> - Section 4 does not ask IANA to register "haptics" in the top level registry (this is a side effect of referencing 6838).

>

>

> _______________________________________________

> media-types mailing list

> [e-mail]<mailto:[e-mail]>

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

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

> ailman%252flistinfo%252fmedia-types%26c%3DE%2C1%2CLN4qkZGWCsxkGqz1WSxo

> bdWAwHNM65qPbAo0be74UPgooX7C6mHsndFw0nGvNWk3V1U1u5UWgj9kt5OQzBl0PmHfpb

> jEXob8sqCdM0Vb_Wv_MD_nX7Wus2Yex_Y%2C%26typo%3D1&data=05%7C01%7C%7Ccb3e

> d89b7215448efc4008db87da1a1f%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C

> 0%7C638253143094940215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ

> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YvsP

> pKNnaqs%2B7HZh1FPcTcDge8TGfUSsBJ1JAbG0nTw%3D&reserved=0